Fitting Everything Together
0pointer.net
external-link
Posts and writings by Lennart Poettering

built from traditional distribution packages, but deployed via images.

Hell no. https://nixos.org and https://guix.gnu.org ftw

Arthur Besse
creator
link
fedilink
722d

i don’t see why the concept of building immutable images using existing distro packages and tools shouldn’t apply equally well to nixos and guix as it does to deb and rpm distros.

@Ferk
link
fedilink
2
edit-2
20d

My problem with this idea is that I generally do not like the defaults most distros use, I like experimenting and I often switch desktop environment or uninstall / clean up stuff I don’t need.

I’d be ok if the image is just kernel + init system + shell, and maybe some small core components / tools… but if the OS comes preloaded with huge software libraries, like typical KDE / GNOME distros do, then it’s gonna be a lot of dead weight that I’d have to keep updated even if I do not use it.

Immutable images are great for devices with specific purposes meant for a particular software stack (like Chrome Books, the Steam Deck or so) but for a more general purpose computer where I actually want to deeply customize the UI for my workflow, I don’t want to carry around whatever popular software the maintainers of the popular distro might have decided to include.

@hfkldjbuq@beehaw.org
link
fedilink
2
edit-2
22d

Nix and Guix are already reproducible and have immutable store; no need for images in that case, and they more flexible. I’d need to read the article more throughfully for the deployment argument

@ClumsyHacker
link
fedilink
220d

His view is perfect for appliances, or devices where you don’t want the user in control (e.g.: kiosk machines, steam decks, corporate laptops, supermarket checkouts).

But it’s terrible for the linux machines that we love to tinker with, machines for developers of OS tools and alike.

@jbowen
link
fedilink
221d

Lennart’s influence over Linux distros are why I’ve been moving more to the *BSD camp.

I think the focus must be on an image-based design rather than a package-based one. For robustness and security it is essential to operate with reproducible, immutable images that describe the OS or large parts of it in full, rather than operating always with fine-grained RPM/dpkg style packages. That’s not to say that packages are not relevant (I actually think they matter a lot!), but I think they should be less of a tool for deploying code but more one of building the objects to deploy.

How is this different from any linux distro with docker installed on it?

poVoq
link
fedilink
722d

Its the opposite. What he is talking about is images based OS, like Ubuntu Touch is doing it, also the Steam Deck and stuff like CoreOS. I think Android and ChromeOS are also doing that. Its not a bad idea in general.

Can you explain what image based OS means?

poVoq
link
fedilink
722d

The core operating system is a single read-only file (ROM, as in custom ROM on Android) and all the user files and customizations are on a different partition or such. Since the core system is fixed you can just swap it with a newer ROM when updating (and also go back to the old one if the update fails somehow.).

@brombek
link
fedilink
222d

There is something sinister about his vision. I think it is fine for server OS to all be identical (docker is that already) - probably what you want, although less flexible. But for personal computing… that makes it very impersonal, to force bit-to-bit conformance on people.

poVoq
link
fedilink
822d

This is not what this is about. You can customize it without problem, see Steam Deck. Its about the core system files being read only and easy to upgrade.

LPWaterhouse
link
fedilink
221d

Ah yes, the guy who funfamentally objects to the unix philosophy and is doing everything to make GNU/Linux the exact opposite of it… Yeah, no. Not interested.

Arthur Besse
creator
link
fedilink
421d

in what way(s) specifically do you think he objects to the unix philosophy?

have you read his rebuttal to that claim (point #10 here)?

(disclaimer: i am using systemd on some, but not all, of my gnu/linux systems today… and after years of finding it irritating I am actually coming around to appreciate it.)

@pickle
link
fedilink
-123d

Who?

@onlooker
link
fedilink
623d

The systemd and pulseaudio guy.

@pickle
link
fedilink
-322d

The guy that made the terrible audio stack? Got it.

Lennart Poettering

Interesting. I read a bit and point 6 conflicts with 12. It’s counter intuitive but minimal software once corrected to a reasonable extent becomes completely bug free. So softwares which update actually are inferior. However they provide a newbie with psychological reward that wow, now, my software is better. Nope, it isn’t, it was designed poorly.

@jokeyrhyme
link
fedilink
823d

I think Poettering’s assumption here, which I agree with, is that it’s difficult to produce software without bugs, and it’s even difficult to patch those bugs without ever introducing new bugs

But, let’s pretend that we’ve accomplished this and never have to fix any bugs: we’ll still have to update firmware and other software components when a new CPU or other device needs to be supported

Although, admittedly, a user might not decide to install a hardware-enablement update if they know in-advance that they’ll never upgrade their hardware or plug in a new device

that it’s difficult to produce software without bugs

When you build software like Poettering build software, it is. Large, monolithic, kitchen-sink systems are going to be bug-ridden. It’s much easier to verify small, independent, focused, Unix-philosophy software. This is the singular reason why people object to systemd.

I like systemd. It made things easy for me… until it didn’t, and until parts started breaking. I migrated to dinit (and back to all of the independent components systemd has absorbed over time), and there are gaps. Some things are harder; the init part of systemd was nice, if only it could be isolated… but it can’t, and this is why Poettering thinks bug-free systems are hard. Because he builds giant monolithic edifaces and (for all his talent) doesn’t know how to isolate.

He’s a good programmer, but a lousy architect.

Helix 🧬
link
fedilink
322d

the init part of systemd was nice, if only it could be isolated… but it can’t

Which other “parts” of systemd are needed if you only needed the systemd init “part”?

journald. cron. systemd core does these, whether or not you succeed in hacking around them and run one of the standard daemons independently.

The systemd ecosystem is increasingly fragile unless you use all of the parts. resolved is becoming increasingly necessary for DNS lookup stability on systemd distros on things like laptops. homed is being pushed pretty hard; arch boot logs complain about not having homed if it isn’t being used, although it still works.

Leonard has argued that, just because systemd isn’t one giant binary, it isn’t monolithic. However, the parts of the systemd ecosystem that take over logging, cron, daemon control, logind, and so on are tightly coupled. The elogind effort spends most of its effort decoupling elogind from systemd (c.f. seatd). I’ve read (but haven’t tried) that you can’t replace logind with something else on systemd installs. You can run it alongside, but removing systemd-logind breaks login. I suspect thats less systemd and more a distribution thing, but the tendancy to tightly couple these packages is concerning. It’s something which doesn’t tend to happen in Arch for other systems… there are usually alternatives providing a capability to choose from, but the systemd components are so tightly coupled that, if you want to use, say, syslog-ng, you basically have to switch distributions.

@Ferk
link
fedilink
1
edit-2
20d

deleted by creator

Arthur Besse
creator
link
fedilink
522d

minimal software once corrected to a reasonable extent becomes completely bug free

lmao, [citation needed] - what in the desktop OS space is sufficiently minimal to be “completely bug free”?

OS and software are 2 different words my friend. But I think it should be possible to make a minimal software bug free.

Arthur Besse
creator
link
fedilink
422d

the gulf between what should be and what is can be quite large. can you name any software you use which you think is likely to be bug free and/or unlikely to need any updates in the next few years?

but anyway, the discussion was about operating systems

GPA. GNU Privacy assistant.

Arthur Besse
creator
link
fedilink
221d

GPA. GNU Privacy assistant.

what makes you pick this, of all programs? just because it hasn’t had a release in four years?

Skimming the commit log one can see it certainly has had some bugs, and given that it is written in C it is reasonable to assume it has had some security-relevant ones. (eg, i’m not certain but this commit from a few months prior to the latest release looks like it could be fixing an actually exploitable bug?)

Currently there are 13 commits newer than the latest release. From a quick glance none appear to be obviously fixing security bugs (i guess there will be a new release when they next find some) but there are actually as-yet unreleased commits there fixing bugs… such as this one, made two days after the last release, which fixes searching being left-anchored.

I get it that programs would be big and have bugs. Minix creator said irrespective of language, there have been found typically 1 bug per 1000 LoC. I believe that bug free software is certainly possible. I have my hopes in microkernels with less than 15k LOC, and softwares made by suckless. Updates provide psychological reward that wow, my software is better now but I don’t think such a thing is possible. If for a minimal software like dwm, st, with no unnecessary feature, it could be bug free with zero bugs.

Helix 🧬
link
fedilink
422d

minimal software once corrected to a reasonable extent becomes completely bug free. So softwares which update actually are inferior.

Please show me an example of a perfect software which does not have a single bug.

@Ferk
link
fedilink
2
edit-2
20d

Even for the most minimal oneliner you’ll have to depend on complex library code under the hood which you’ll have to keep up to date as part of the OS. And/or depend on the compiler itself to not introduce bugs into the resulting binary you are distributing.

Either that or you write your software in pure assembler (which will end up exposing a lot of internal complexity anyway, resulting in asm files that are far from “minimal”).

These are just some known vulnerabilities in libc (we don’t know how many “unknown” ones there might be, or if new fixes will introduce new problems): https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word “Linux” in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

  • Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
  • No misinformation
  • No NSFW content
  • No hate speech, bigotry, etc

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

  • 0 users online
  • 8 users / day
  • 43 users / week
  • 74 users / month
  • 254 users / 6 months
  • 6.12K subscribers
  • 1.86K Posts
  • 5.37K Comments
  • Modlog