Hacker News Reader

Comment by deith | Hacker News Reader

If Debian offered the same things Ubuntu does, people wouldn't use Ubuntu. But, alas, they don't.

As someone who's worked heavily with both Debian and Ubuntu - they do.

There are differences between them but I am 100% confident that I can do everything that an Ubuntu system can, especially if we're talking about infrastructure.

Of course any open source system can be changed into any other. But the question is how the default experience works for people who don't want to tinker much.

For sure, but in the case of Debian/Ubuntu the configuration to make Debian a bit more friendly is not difficult at all...

ie: Enabling non-free and installing sudo gets you most of the way there for the majority of users.

One thing I'm really missing from Debian is zfs.ko.

It was always a big one for me, I ran with ZFS root for 2+ years and every kernel/zfs update was a bit of a Russian roulette (I did have to perform elaborate recovery once or twice). Even if it was 100% guaranteed to compile and work, there was 1. a very scary window during which if the system hung, you're semi-bricked; 2. the long build.

Running a desktop/laptop without a time-traveling file system is quite simply not an option (especially once you get used to it).

Root zfs isn't worth it IMO.

It's a integration / packaging / polishing problem (caused by a licensing problem), technically it's 100% viable and desirable.

As a FreeBSD user that has had root zfs for a while, and used zfs on solaris before that doing the same thing. Explain how it isn't worth it?

Made backing out of patches easy mode, snapshot, patch, reboot, if its effed up, go back to the snapshot with a reboot. The only thing I've seen that comes close is NixOS, but it takes a completely different take on those kinda things. Better in some ways. But zfs root is great, means you can just set compression on for log dirs and don't need to worry about compressing logs. Fs takes care of that for ya, now grep works fine, no zgrep etc... needed.

I honestly can't see why you wouldn't want to boot off it. Hell I just upgraded my FreeBSD nas box at home, took a snapshot of the entire pool before I did just in case things went south. It may not be as performant as some filesystems, but to be honest, with nvme ssd's, its a non issue.

So explain how it isn't worth it in your opinion? Experience for myself has proven otherwise. And made me loathe BTRFS for being so behind zfs of even 10 years ago. (I've had BTFS zero out data for a Makefile I had open while running make, if it wasn't in a git repo I would have been super pissed off)

I have a similar requirements out of my OS, but using a different approach.

I essentially boot Docker images bare-metal, directly from Grub.

https://godarch.com/

My recipes: https://github.com/pauldotknopf/darch-recipes

It's not a big win because the OS shouldn't have much data of any value, for similar reasons we don't generally back up our OS installs.

It certainly shouldn't be in the same pool as your actual data, the stuff you back up. /home can live in that pool though.

I have to squint really hard to see the upside of snapshotting anything other than things like /etc - I have in the past put /etc in git just to track ad-hoc changes.

Overall, for the base OS, a minimal set of defaults + a provisioning script does me.

The kernel version supported by zfs is available on the release page.

0.8.2 is Compatible with 2.6.32 - 5.4 Linux kernels

You have to combine out of date zfs with bleeding edge kernels to have a difficulty.

Basically you just check the zfs release page before upgrading x.y to x.y+1

This could be trivially avoided with packaging

This is theory vs practice at its best, I've been running zroot from January 2017 until April 2019 on my primary machine, and got lots of empirical data (aka scary stories) to back up my claim ;)

a version 1 only works with b version >= 1 and <=17 is pretty basic stuff. If someone isn't doing it than submit an issue and run your own repo that does

Hmm, this seems like a solvable problem - install the kernel on disk, but don't promote it to the default kernel on reboot until all the DKMS modules have built.

At that point, you might even be able to optionally background the compile process and have it run asynchronously and update your kernel only once it builds successfully.

Alternatively, teach GRUB to be able to boot "the most recent kernel with all of this set of modules available".

Try getting Debian working on a laptop. Those "non-free" packages in Ubuntu make a huge difference.

On servers, not so much difference. Well unless you are using k8s, etcd, juju and all that jazz

> Try getting Debian working on a laptop. Those "non-free" packages in Ubuntu make a huge difference.

I'm typing this on my "workstation" but, sitting here on my desk, there's a laptop running Debian on either side of it (and there's another one across the room).

I can't read your mind so I'm not sure what issues you've encountered attempting to run Debian on a laptop. Apparently I have already figured out how to workaround them (but I've also been using Debian for ~23 years so perhaps that has something to do with it).

Getting things like wifi and GPU acceleration working on laptops can be problematic with pure Debian.

You _can_ do it but on Ubuntu it just works.

I have several laptops, all of which run vanilla Debian.

"non-free" is an official Debian repo. It's not enabled by default, but that's a single line edit in sources.list. And it has all those non-free video drivers etc.

There's also an unofficial Debian CD image that includes non-free packages, for those cases where you need that stuff during installation time.

I'm typing this from an LG Gram 17 laptop running current Debian. Before this laptop, I used a Dell Inspiron N7110 for many years, also running Debian stable. I basically never need to use anything else to get work done.

I will grant that a few things are a bit fiddly -- touchpads are iffy sometimes (and infuriating on the LG Gram because it's got a new one) and function keys sometimes don't work. The Gram had a booting problem that has since been resolved (https://bugzilla.kernel.org/show_bug.cgi?id=203617) but also had workarounds pretty quickly. So for some hardware, yeah, it's not a good experience for people used to just running Windows.

But there's also lots of hardware for which it works just fine out of the box, and for experienced Linux people, it's not usually that hard to deal with the sharp edges.

And modern KDE is brilliant.

I bought a cheap Dell laptop in 2017 and installed Debian stable on it and it worked out of the box.

> Try getting Debian working on a laptop. Those "non-free" packages in Ubuntu make a huge difference.

Ah, you mean the ones in the Debian non-free apt repo?

I am using it on my laptops without any trouble. You simply enable the non-free repo and the only difference becomes how much purple you have in the default themes.

I use both, but prefer Debian. Care to elaborate on what you miss in Debian?

Many things. Mostly PPAs. I can install Ubuntu Stable and use the most recent version of PHP, which has been built and is stored in Canonical's servers. With Debian, that's a gamble: either wait until the Debian developers stop bikeshedding and upload a new version of PHP to experimental, breaking all my system if I install it, or I have to add a repo from some guy I don't know or trust.

> ... or I have to add a repo from some guy I don't know or trust.

The Debian PHP maintainer, Ondřej Surý, maintains his own repo:

* https://deb.sury.org

* https://packages.sury.org/php/README.txt

* https://qa.debian.org/developer.php?login=ondrej%40debian.or...

Okay, you've shot down my example, but that was not the point.

What is your point? That Debian doesn't churn versions of software very quickly? Some of us view that as a good thing.

I still don't understand why folks don't just build things like PHP from source. On either my desktop or production servers building a package missing from APT has never been a problem (on either Debian or Ubuntu, but I strongly prefer Debian). Then you don't have to trust anyone... /shrug

And what's even worse, if you install Docker containers you don't build and manage yourself, you're pretty much right there again with "I don't know or trust" as your means of security.

Not a downvoter, but if you think that compiling from source means you don't have to trust anyone, then I encourage you to read a paper called "Reflections on Trusting Trust" by Ken Thompson.

It's a very famous computer science paper, pretty easy to read. Nothing niche or controversial. I'm sure you'll find it interesting.

The point is that you don't have to trust anyone outside the source given by the official project you are downloading.

The fact that you can't achieve the ideal does not mean we should claim defeat.

Just to expand on the "build from source" bit, apt-get can not only download packages in source form but also build binary packages in literally one single command.

This makes the cases where you want the full Debian build but with a patch or just stepping the version easy. That's useful when you need to patch a package or can't wait for an upstream security fix.

Too often I see people building upstream packages "by hand" in those cases. The packaging tools are great and any Linux user is greatly helped by taking a few minutes and learning the basics of apt preference files, package selection and source packages.

What's the difference between a PPA and a repo from some guy you don't know or trust?

With a PPA you can't upload binaries, you upload sources that can be audited, and Canonical builds them.

I strongly suspect they don't audit the sources.

They're not saying that Canonical audits the sources. They're saying that because the person running the PPA uploads the source and Canonical's servers build the packages from there, as long as you trust Canonical you don't have to worry about the binary matching the source. For the majority of us who aren't qualified to audit the source itself directly, being able to trace the binary we're running to source that someone could audit is the best we can hope for.

Of course in the years since the PPA system was introduced we've seen a lot of projects push in to reproducible builds which somewhat negates that concern, but there are still a lot of us who would rather not go through that process for every random binary we want to run. Having a third party that we inherently trust because they built the rest of the operating system building the random packages we want has an appeal. Also for the devs/packagers free hosting by the OS vendor is nice too.

> The act of wasting time on trivial details while important matters are inadequately attended is sometimes known as bikeshedding.

Never heard that term before, but it does, in fact, seem to describe a lot of Canonical's issues in the past decade.

See "Why should I care what color the bikeshed is?" [0] for the reference, if you're interested (and/or "Law of triviality" [1]).

---

[0]: https://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.h...

[1]: https://en.wikipedia.org/wiki/Law_of_triviality

Do you have an example of bikeshedding from a FLOSS mailing list?

PHK's e-mail from 20 years ago (included/linked above) is the canonical example.

I, personally, don't have any examples ready to provide you but I no longer subscribe to any "general discussion" lists.

Reply on news.ycombinator.com