3 ms·

I'm sorry to say you're in a minority. At least for the past 5 years commercial libraries assume you are running RHEL (usually one major release behind) or Ubun

by Paul_S 10y ago

I'm sorry to say you're in a minority. At least for the past 5 years commercial libraries assume you are running RHEL (usually one major release behind) or Ubuntu (LTS). It used to be Debian before that. If you're not you are going to have a bad time. Of course if you're determined with a lot of work you can recreate the environment by compiling the exact versions of tools and libraries required (if you're lucky the library will specify that, otherwise you'll have to divine it through magic). But when you're doing this for a living you probably have better things to do. It's a lot easier to use the distro that already has the correct deps and just get a newer version of a tool that you want to use if you really think that the one in the distro repo is too stable for you. So much less work.

krisdol 10y ago
> If you're not you are going to have a bad time That's quite a jump from your previous sentences and I don't find that true at all. I've had no worse of a time on Debian, arch, or Manjaro for developing when compared to Ubuntu (and its various flavors and derivatives). I never used distro deps because of how horribly out of date, misconfigured, or incompatible they are
- Paul_S 10y ago
  Say you buy a some platform to develop on. This will normally come with a toolchain and some libraries. The library was developed on LTS. Now you try and compile that and it doesn't compile. Woe is you. You can't just ask the seller because he just told you to use LTS so good luck figuring out why it doesn't work. OK, so you've spent some time and figured out the problem - it needs this particular version of this obscure tool. OK. No problem, I'll just compile it myself. So after tracking down the source you download it and try to compile it yourself. That tool has it's own dependencies. OK. 10 recursions later (I hope you're keeping all this crap in a local dir and not just blindly overwriting your distro version!) and you compiled the tool. make Another library that needs compiling from source - see above. Repeat for each one and its dependencies. make Nope! Your python is too new! OK, fix the script to you use the correct (older) python. make Nope, GCC defaults have changed! You fix the makefiles. make Success! You've wasted a week of your time you could've spent working on your product.
  - rickycook 10y ago
    containers are pretty cool
  - absorber 10y ago
    Guix / Nix might be a solution to this problem.
rubber_duck 10y ago
I guess it's true that I use mostly OSS stuff when I dev on Linux, I switch to Windows if I need to work with proprietary software, it's usually much less hassle. I disagree about it being easier to upgrade tools, it's exactly what you described for backporting, you need to upgrade entire dependency chain because the repo versions are ancient.

by Paul_S 10y ago

krisdol 10y ago

> If you're not you are going to have a bad time That's quite a jump from your previous sentences and I don't find that true at all. I've had no worse of a time on Debian, arch, or Manjaro for developing when compared to Ubuntu (and its various flavors and derivatives). I never used distro deps because of how horribly out of date, misconfigured, or incompatible they are

Paul_S 10y ago
Say you buy a some platform to develop on. This will normally come with a toolchain and some libraries. The library was developed on LTS. Now you try and compile that and it doesn't compile. Woe is you. You can't just ask the seller because he just told you to use LTS so good luck figuring out why it doesn't work. OK, so you've spent some time and figured out the problem - it needs this particular version of this obscure tool. OK. No problem, I'll just compile it myself. So after tracking down the source you download it and try to compile it yourself. That tool has it's own dependencies. OK. 10 recursions later (I hope you're keeping all this crap in a local dir and not just blindly overwriting your distro version!) and you compiled the tool. make Another library that needs compiling from source - see above. Repeat for each one and its dependencies. make Nope! Your python is too new! OK, fix the script to you use the correct (older) python. make Nope, GCC defaults have changed! You fix the makefiles. make Success! You've wasted a week of your time you could've spent working on your product.
- rickycook 10y ago
  containers are pretty cool
- absorber 10y ago
  Guix / Nix might be a solution to this problem.

rubber_duck 10y ago

I guess it's true that I use mostly OSS stuff when I dev on Linux, I switch to Windows if I need to work with proprietary software, it's usually much less hassle. I disagree about it being easier to upgrade tools, it's exactly what you described for backporting, you need to upgrade entire dependency chain because the repo versions are ancient.