Hacker News Reader

> If you get behind with upgrades you are screwed.

Why? You shouldn't rely on system files for development... you probably want a proper dev environment that can later be replicated into production or staging (eg. containerization, VMs, virtualenv, etc). Just stick with Ubuntu LTS releases, and enjoy the consistent updates (eg. security) and the massive support benefits (eg. forums) associated with running one of the most popular distros.

Personally, I love the consistent Ubuntu updates. Granted... I always switch to xfce for the desktop environment.

> Why?

Because if you miss three releases then you have to do three upgrades. If you setup a system and then come back to it a couple of years later and find you need to upgrade you can plan on fighting through multiple system braking upgrades. Yes I know you can mitigate this with LTS but that's a big compromise.

But it's a dev machine, right...? So you just nuke the install and then `git pull` all your key configuration files and dev environment, and then you're right back up and running. Same as if you switched to a new machine or one whose harddrive died. I still don't see the problem.

Reinstalling is a sorry solution. I haven't had to reinstall my dev machine in about a decade.

Where do you buy your HDDs? You're sitting a couple standard deviations beyond MTBF.

I have upgraded to an SSD but just copied the OS and boot sectors to the new device.

One of my friends asked me how often I reinstall my operating system.

I told him I haven't installed a new OS on my primary PC in 10 years. I just DD it from one drive to another.

DD is by far the easiest way of making bootable media on a flash drive as well. I use that method to create install media for my other computers.

> Yes I know you can mitigate this with LTS but that's a big compromise.

Genuine question as a Ubuntu user, where do you win using Debian on a laptop? I totally understand using it on servers, as it is the definition of 'rock solid' and you can ensure that it will work 100% of the time.

Admittedly I don't pay a huge amount of attention to the differences, but isn't using Ubuntu LTS compromising in the same way as Debian stable? Specifically, packages are oriented for stability. Consequently, you don't get improvements to the kernel, or other packages you may use frequently. On my laptop, I don't want to use Kernel 3.6 that doesn't have the latest improvements to work with Intel processors, direct rendering management, and power saving. I don't particularly want to use quite outdated versions of GNOME either. Six months, to me, is a solid amount of time to sit on a release.

Some people suggest (misguidedly, according to Debian volunteers) using Unstable on a workstation / laptop, which caused my system to outright break entirely because I was using a Nvidia graphics card, so I just installed Ubuntu and it worked from first boot.

Using testing is sworn against by almost everybody, as it's the worst of both worlds - it's not stable and it's not fixed quickly.

Stable plus backports, suggested elsewhere in these comments, sounds nice only if you consider ensuring that water drains out of each hole in a colander equally an adequate use of your time. You then have what I'm fairly sure it's explicitly listed as "don't do this" on the DontBreakDebian[0] page.

[0] https://wiki.debian.org/DontBreakDebian

If you run Debian on your servers then having the same software, and the same versions available, is a good for consistency.

There's something to be said for running multiple distributions so you spot binaries in different places, etc, but really running the same system "everywhere" has more value to me.

My laptop/desktop run Debian stable, my servers run Debian stable, and so I know what to expect.

When I need things that aren't available, or have to be backported, I know how to do that. For extreme changes I can use containers, or virtual machines. But for the past few years I've not been convinced in the feature-churn or value added by Ubuntu. (Especially when you see that their "universe" isn't really supported by anybody - hell even looking at bug reports for their supported packages is often depressing. Bugs open for very long time with no updates because of lack of people willing/able to fix them - combined with forum advice which is often the blind leading the blind.)

> Using testing is sworn against by almost everybody, as it's the worst of both worlds - it's not stable and it's not fixed quickly.

Nonsense. Testing is stable and up to date. Ubuntu is based off of testing. Debian's rolling release system makes upgrades easy.

The issues I had whenever I strayed from Debian weren't technical deficiencies of yum, etc, but rather the choices made by other distros. Installing "vim" and unexpectedly getting some sort of "minimal" version of vim. Packages which symlink or install large binary files or log files into /etc (suddenly grepping /etc becomes problematic). In general, lots of little decisions which make me exclaim the distro equivalent of "Did anyone even play-test this?"

> Packages which symlink or install large binary files or log files into /etc

wtf? who is actually incompetent enough to do something like this?

This was something like ~8 years ago, but here's an excerpt from my notes when using Redhat:

    # ls -l /etc/httpd/
    conf
    conf.d
    logs -> ../../var/log/httpd
    modules -> ../../usr/lib/httpd/modules
    run -> ../../var/run

Reactions:

    * Why is 'grep -r /etc' taking so long?
    * Why am I seeing log entries in the output?
    * Why am I seeing 'permission denied' on a bunch of socket files?

Debian seems to have the most respect for the FHS. http://www.pathname.com/fhs/

A few more, from my notes:

These were the default permissions of the apache log dir:

    # ls -ld /var/log/httpd/
    drwx------ 2 root root 4096 Jan 18 12:09 /var/log/httpd/

I guess their expectation is that only root should ever need to read a log file? Contrast this with Debian, which gives read access to admins:

    $ ls -ld /var/log/apache2
    drwxr-x--- 2 root adm 4096 Jan 16 06:25 /var/log/apache2

Redhat also decided to stick wsgi sockets into the log dir. If you try to run a wsgi process as anyone other than root, you get a permissions error:

    (13)Permission denied: mod_wsgi (pid=31431): Unable to connect to WSGI daemon process 'bob' on '/etc/httpd/logs/wsgi.1965.3.1.sock' after multiple attempts.

To fix this problem, you have to tell wsgi to stick its socket files somewhere more reasonable, like /var/run (which is what Debian does by default).

When you look up the modwsgi "Common Problems" page, the very first entry describes exactly this issue... https://code.google.com/archive/p/modwsgi/wikis/Configuratio...

'cfdisk' was removed from the distro because it was "a pile of junk". Really? That's funny -- I've used it to create dozens of Debian partitions and never had a problem. https://partner-bugzilla.redhat.com/show_bug.cgi?id=53061

> These were the default permissions of the apache log dir

Since systemd came along, you're supposed to use journalctl though.

That applies to Debian and Ubuntu too.

Side note: What do you use to keep detailed notes, to enable you to quickly refer back to stuff 8 years later?

My problems on rpm systems are always about some packager using different versions of dependencies than what ships with my OS.

Nobody has the QA force Debian has.

> Even after all these years it's hard to beat apt-get.

I would say Fedora's dnf has it beat quite objectively, but to each their own.

After almost 20 years Fedora is only just catching up with where apt-get was long ago.

DNF uses delta updates, apt-get still doesn't AFAIK.

See debdelta

> dnf has it beat quite objectively

You mean even though the slightest care was not given to reliability while coding it?

https://lists.fedoraproject.org/archives/list/devel@lists.fe...

Depends on your definition of reliability I guess.

If I have two scripts running in parallel which both wants to install packages, using apt will cause one of the scripts to fail, because apt is already locked.

dnf however will be just fine, because instead of failing it will just queue and wait for the lock to be released.

There's small things like that all over which to me, as an end user, makes relying on dnf feel much safer.

> Depends on your definition of reliability I guess

No, not at all. Not doing the elementary work to design the package manager in a way that it will keep the system in a consistent state as it is reasonably possible is unreliable. On top of that, if the developers of the said software are ignoring the issue, denying it is their responsibility and tell people to use a different program instead, I will personally not touch it with a 10 foot pole.

Refusing to run when a concurrent copy is already running on the other hand, is just a comfort issue.

> makes relying on dnf feel much safer

So you are OK with ignoring a real reliability issue and a trivial UX behavior is enough for creating an illusion of safety? Check the thread I've posted, Fedora developers are more than happy to recommend not using DNF and using offline updates thing instead.

Now try running multiple instances of "offline update" thingy and see how far it goes in your pet scenario ;)

> so you are OK with ignoring a real reliability issue and a trivial UX behavior

Reliability has many dimensions.

If I can't trust that the package manager handles all the issues you can encounter when managing packages, I cannot trust any component which interacts with the package manager to be reliable either.

dnf does a lot of right things(tm) which apt doesn't, which means I can trust that scripts I write to work with the package manager will work reliably.

Apt outsources approximately 2 out of 3 failure-modes to its users meaning every automated attempt to interact with it, is bound to fail on stupid shit it shouldn't.

And then you can't rely on apt. Apt is not reliable.

To me it seems like a misinformed version of "KISS"/"YAGNI", because you do need a package manager to handle and abstract all those things. That's what it's for.

OK, now I understand what you mean by reliability and I appreciate that. Thanks for explaining it.

I'm just not comfortable you claiming it is more reliable than apt because then some people will think it is a package manager with minimal amount of importance was attached to its design so that it won't leave the users system in an inconsistent state even in most easily correctable scenarios when that's actually not the case.

You can not safely install two packages concurrently. apt-get's choice to refuse to run is a much simpler solution that better adheres to the KISS principal and is therefore less prone to error. You could queue apt installs of you really wanted to with a simple for loop on the command line.

Which is why dnf doesn't.

But dnf doesn't break your script or force every script in the universe to reimplement the same polling loop, because it's implemented one place, centrally, so everyone else can forget this problem even exists.

dnf clearly does the right thing here, while apt causes breakage. I don't see how anyone can argue anything else.

It's not KISS if everyone else has to work around your shortcomings. Then it's just inadequacy.

I agree that Debian is a great developer platform, I use it myself. But as a note on the Ubuntu's 6 month cycle, it is easy to just ignore it and only use the LTS releases and upgrade every 2 years. This makes it very similar to Debian stable in release cadence and the LTS releases tend to be of better quality.

Yum has been replaced by dnf in Fedora.

Is it any better?

I never had problems using yum. dnf has the same interface but works faster, and does more things (e.g. Copr/repository management and `whatprovides`) and better.

I've found yum to be slow and prone to breaking. Part of the problem is that CentOS packages are often far behind. EPEL is a symptom of the problem more than it is a solution. Invariably, when building software which builds easily on Debian based systems, on CentOS, I end up compiling many packages from source because either they are not available or are horribly out of date.

This was solved long ago: https://access.redhat.com/documentation/en-US/Red_Hat_Develo...

100% agree with this. Debian is stable and highly supported.

> Don't get me started on Fedora/CentOS/RedHat. yum/rpm is just horrible if you've used nearly anything else.

Your experience may support such a statement, but without any context it doesn't really help the question at hand. Sharing specific criticisms of rpm-based distributions or rpm package managers would go a lot further towards arguing why they would be a poor choice for a development laptop.

> I think the only reason this OS family is still alive is because RedHat managed to sell so many copies to big corps and universities. I think people still use it mainly because they were exposed to it at school or work and don't know any better.

Do you really think there are no situations where running Red Hat/CentOS or Fedora would be a suitable choice?

> Do you really think there are no situations where running Red Hat/CentOS or Fedora would be a suitable choice?

Fedora is IMO a great desktop distro, but for some reason consistently underrated in the wider community.

> I find Arch, Gentoo and many others to be a lot of work. I don't have time to spend fiddling around with the OS.

I agree, first install was boring and confusing. I installed it once and didn't touch it since then, haven't touched it for 6 years, it's still running. In fact that's the last time I installed an OS.

edit: I'm running Arch.

I use debian but I'm not sure I'd recommend it for devs who don't want to fiddle with their desktop. Stable is great for servers and simple desktop computing, but is too stale for developers. Testing and Sid are both rolling updates, so if you don't keep updated, things can break (or more usually, change in workflow) sometimes when you do update. Ubuntu and Mint are snapshots of these rolling setups, so they stay more consistent over time.

If you don't like fiddling with your OS once you get set up, then you should be using some sort of LTS distro like Ubuntu or perhaps a BSD. Things like debian, arch, and fedora require a modicum of maintenance (not much, but it's there). If you don't mind (or like!) fiddling, then a rolling release distro is best.

Having spent years on debian, and having run stable and sid, the only really sustainable arrangement is to use stable+backports. Don't run sid! Gradually your system will become a mess and you'll end up doing a reinstall.

If you need a library that isn't in backports, just compile from source and install to /usr/local, it's not hard!

Datapoint to support you: this conversation reminded me to do an update on this debian sid laptop, which is a couple of months un-updated. about a gig of downloaded updates... and I came back to my lockscreen which had a whole new look, and my desktop wallpaper had changed (I think I was just using the default before, so understandable).

It's fine because I understand what Sid is about and this is to be expected, but I wouldn't suggest this to a naive user. And since Testing gets these changes in short order, I'd stay away from that as well if the user isn't comfortable fiddling.

So yes, stable + backports, unless you're comfortable with change/fiddling (same with any rolling distro).

> Debian and I'm surprised more people aren't saying so. Ubuntu or Mint, which are built on Debian do not add much value these days, IMO and Ubuntu's 6 month release cycle is intolerable. If you get behind with upgrades you are screwed.

Ever tried to install Debian on a Macbook without an Ethernet-to-USB cable? I take it not, because then you would know how completely retarded it is that you need a second USB stick with the broadcom-wl driver on it to do a proper install. Debian's 'free software' zealotry makes for a horrible UX.

Edit: and here come the 'free software' zealots. Keep downvoting, but everyone out of your echo chamber can see how rabidly sticking to ideology completely destroys usability.

Actually, one of my main machines is a Macbook running Debian. Works great. Admittedly, I had a few driver issues in the beginning but that is common with cutting edge hardware with any OS that was not shipped with the hardware. Now I'm running stock Debian with no issues.

You can use these images.

https://cdimage.debian.org/cdimage/unofficial/non-free/cd-in...