4 ms·

>Reality is if you're a developer you either use RHEL because that's what corporate chose or you use Ubuntu because that is the platform chosen by library devs

>Reality is if you're a developer you either use RHEL because that's what corporate chose or you use Ubuntu because that is the platform chosen by library devs and unless you use it as well you will waste time sorting out issues. My experience is completely opposite, I like to prototype and test stuff and both distros are shipping heavily outdated libraries and tools, even if I need to compile on some old compiler to deploy why would I miss out on compiler perf/usability improvements, run outdated debugger, etc.? The CI can let me know if I broke anything in the target environment, but I prefer to have my tools up-to-date, and updating on Ubuntu/RHEL is a PITA

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.

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.