Hacker News Reader

Comment by rubber_duck | Hacker News Reader

>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

View on HN

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.

> 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

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.

Guix / Nix might be a solution to this problem.

containers are pretty cool

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.

Reply on news.ycombinator.com