Agent P waxes lyrical about 14 years of systemd FOSDEM returned to Brussels for the first weekend in February – not without some controversial people. "It's now the biggest FOSS event in the world, in terms of the number of streams, program items and talks, and in terms of virtual attendees," co-organizer Richard "RichiH" Hartmann told The Reg. We spoke to him just before …
The (modern) human genome at least 100,000 years is unquestionably old and it is still maintained - an onerous task no doubt but I do believe many receive some pleasure from the undertaking.
Systemd by analogy would correspondingly be an upgrade offered by Lumic's Cybus Industries.
"The (modern) human genome at least 100,000 years is unquestionably old"
Chicken and egg.
The human genome is just as old as any other and that's zillions of years old - at some point genes (DNA and that) came into being. However unless you are a 4004 BC noddy, the notion of genome "creation" is smeared across a vast expanse of time - it evolved. Real life is far messier than prissy nomenclature.
It is useful to slap labels on things but we do have to allow that labels do not necessarily imply absolute precision. That way lies madness and probably hair loss and a weak handshake and we can't have that 8)
So, which came first: chicken or egg? (hot tip - there is no controversy)
I almost spit out my tea when I read that.... I is not modular in the sense that you can actually swap out modules with other modules, e.g. for sound. I would really encourage anybody to compare how difficult it is to make some daemon run at system start in sysV (copy or heck even write the init file, it is not hard, make a link in the runlevel you intend it to run, with the correct startup order in the name, f' just put it on 90) and replacing e.g. pulseaudio with pipewire....
Also: has systemd "won"? Wow, "winning" at that is... a messed up comment.
Modular as in process 1 spreads out like a spider-web though the system encroaching on every aspect of system startup invoking module after module, service after service and timer after time both at the system-level and user-level in a way that reminds you of another OS from Sir Bill. If that's what he means by "modular" I'll gladly give him that.
And therein is the rub. When it works, I've got no technical complaint about systemd, but when it doesn't, the average user is stuck either having to hunt through an encyclopedia worth of documentation hoping to stumble upon a rabbit trail leading to why -- or many times, is just stuck. I'm not sure that is good for Linux or open-source as a whole as it eliminates "choice". It's become a take-it, or write your own distro proposition in many cases.
On the when it doesn't work from, take the recent little hiccup with loginctl that for some display managers caused logind not to set seat0 causing a litany of obscure issues. It got fixed, but it wasn't as if the user had hope of an easy (or any) work-around. So I'm not sure that "modularity" is something to point to as a benefit. Modularity may mean memory efficiency during init, but that doesn't mean a whole lot when when the added complexity makes it unwieldy and difficult to fix.
As in RJ45 plug - when the weak plastic bit that locks the plug into the socket is (easily) broken off and the plug floats about in the socket but of course the patch isn't replaced so you are thereafter plagued by intermittent, impossible to diagnose faults....
Methinks t'is very like Poettering's pride and joy.
Yeah, but that guy twists words and its not worth arguing with him. Better just disengaging with his crap. BSD and non-systemd operating systems are actually flourishing.
I mean, check out this issue log:
https://github.com/systemd/systemd/issues/2402
P, the sodding idiot didn't know the difference between hosing the install, vs bricking the system.
He is a fool, and the community is filled with them. Just ignore them; the great thing about open-source is choice. You can skip the broken and replace it with something workable.
As a musician and DJ, I say THANK GOODNESS (and apparently also redhat) FOR PIPEWIRE. Because pulseaudio is garbage. Or rather "was" because I don't run garbage if I don't have to. Can you taste the vitriol? That's what people get, when people come in heavy handed with insider support and force over-engineered "solutions" that just make things "broken in a different way" and "much harder to fix" on the world.
Now, if we had a pipewire equivalent for systemd, the world would be a lovely place, with much less vitriol.
Yeah we've been there, a long time ago, it sucked.
Sound was one of the classic Linux problems along with wifi.
These days I just want Linux to work, I love using Linux...but I don't yearn for the old days...it's already the best OS (no matter your opinion on init system, sound subsystem etc)...we've fucked about for long enough. We've reached a point where things just work (mostly)...which is good...I'm all for choice for those that want it...but for mass adoption and any shot at the "year of Linux" we have to accept that things working is more important than philosophical debate.
The spirit of Linux isn't creating "the one great distro"...the spirit of Linux is "if you don't like it, make your own distro"...complaining about the decisions distros make is like shouting at clouds...it's a waste of your time.
Thankfully, there aren't really that many people that complain, the ones that do are just loud...and the ones that do complain are the ones that aren't capable of customising their own distro. There is a bell curve in Linux that has new users that just want a distro that works, they don't care whats in it...then the bell curve peaks at people who do nothing but complain, who want the good stuff but aren't capable of implementing it, then the curve tapers off again into people that don't care what's in a distro, because they're capable of making it do what they want anyway.
Fuck the inbetweeners man.
You're aware that you don't need either? Just run jack on plain ALSA. Unless you're trying to watch Youtube vids and stream whatever at the same time. Which you just shouldn't - and if you really think you must then don't run it on the same audio device as your production apps. If you run all this shit through pipewire on the same interface you'll inevitably end up with internal software resampling, mashing x different sample rates from y different sources to an awful stream of mud. Maybe that's OK for you - it won' be for anyone else on a different setup. Before you call me an idiot who doesn't know what he's talking about: I've produced title tracks for international cinema productions (one even got a golden palm in Cannes), jingles for ads and radio stations, played live radio shows and gigs - all besides releasing my own stuff.
In one thing, however, you make a point: the same kind of people aggressively supporting systemd are the loudest supporters of pipewire.
In that throbbing vein, istr FOSDEM 2025 had a couple updates on Redox OS (Non-Linux Posix Rust), Shepherd (PID 1 in LISP), and the FPGA OpenXC7 (PL bitstream built on the PS itself, on Zynq 7000) ... any chance of a medley TFA, or separate ones, on those, as updates to recent pieces (maybe webassembly too, if warranted) ... pretty please!
This post has been deleted by its author
I have seen that talk and it is excellent.
It explains what both sides in debates about systemd seem to often miss.
Systemd is not an init system. it is a system layer somewhere between the kernel and user space that includes an init system. That is what is good about, and that is what is bad about it.
It's not very good. It is, in fact, really bad; that talk is just a repetition, almost word for word, of lennie P's infamous "systemd myths" blog post. Including the stupid, idiotic lie pretending not to understand that "The unix way" is a basic engineering principle, very close to KISS - "do one thing and do it well", and not, as P made up, "all in the same repository". Which apparently P repeated at fosdem and was applauded by all the other wannabe microsoft employees in the audience.
linux.conf.au went really out of their way to first, delete all comments on that video, then forbidding new ones. Seems that whomever was paying them for it didn't like that everyone else was pointing out that all the crap spewed by Benno on that talk had been comprehensively answered way before - by Jude C Nelson in 2014. Here - https://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html. Indeed, Benno was just parroting a bunch of fallacies, and sounding just like another cult member without a clue. I hope he got properly rewarded for his part in the farce.
When someone claims that talk is anything but parroting a bunch of lies, it makes me think that that either they have bought at leat partially into the cult, or are grossly misinformed about anything systemd/lennart.
From the article: We don't want encrypted drives, TPM modules, sealed validated boot processes, managed home directories that aren't actual directories anymore, or pretty much any of these features
Poettering's view of the future is (apparently) to turn Linux into Windows, and to re-re-invent DBus etc. (again) so that the BSD's and non-systemd-infected Linux flavors are broken, and to have that [another LOTR reference, you're welcome] "One Init to RULE THEM ALL" (etc.)
Not now - he's been lying like that since the beginning. Almost everything is parroting the infamous "systemD's biggest myths" blog post (by P themselves). As I put above, all that crap was answered way back in 2014 by Jude C Nelson, but some people, like apparently Liam, still don't get it.
I've been writing Rust, intensively, for the better part of a decade and I will be the first to agree that Cargo is not perfect. Don't even get me started on "features" – what they were, what they are, what they were intended to be and how people abuse them across the ecosystem. But the truth is that Cargo is actually bloody brilliant when one considers it, objectively, and thinks back to Autotools or CMake. Cargo works well enough right "out the box" and it works pretty much the same way for every project that applies it, correctly, on every supported platform. Rust is "nice" because you *can* just `git clone` most code-bases and Cargo will usually build them, run their tests and executables and their examples. You can edit those examples' `main.rs` source and start to hack right away and Cargo keeps running them so you can play. The on-boarding process to try out something in the Rust & Cargo ecosystem is easily the best I know by a million miles, chains, cables, furlongs or what-have-you.
But let's just take a step back: you're making an "init system". That is: a system that runs to spawn other processes, monitors them over their life-time, killing some and restarting others if they die. If the structure is, indeed, so convoluted that it can't be built with Cargo, you're inept or you're wildly out of scope and I wouldn't want to touch what you're making with a ten-foot pole.
I think the mention of Meson is apt, though. Meson is basically the systemd of build tools: it is extremely opinionated and hostile to every other build system, offering heavily begrudged support for integration with CMake out of necessity (because everything else either uses or supports CMake – it being the industry-standard incumbent) but holding the line that interoperability means "just port everything to Meson".
Do you want to link SDL in a Meson project? Great! You've got the flagship demo for that specific case. Oh: you want to use a version of the SDL that doesn't match the demo's current "wrap" version? Good luck, then, because SDL builds with CMake in a non-trivial way so you'll be patching the official demo "wrap" (and it is exceedingly verbose, being a complete reproduction of the SDL build mechanism), writing something entirely new or hacking together some very cursed solution that will never be supported because you're using Meson in a way that contravenes their "philosophy". Ditto for every other non-trivial dependency that doesn't coincide with an official "wrap": it's all just "port to Meson" because that is the only supported way. (Edit: citation: https://mesonbuild.com/Mixing-build-systems.html)
Agent P chose to compare the number of lines-of-code of systemd with that for glibc – an implementation of the C standard library and not actually an init system – or that of bash (a shell, not actually an init sytem) or wpa_supplicant (a wifi thing, also not an init system) and so some crazy, off-spec, non-conformist part of my brain wondered if, just maybe, a more interesting comparison would be to – you know! – another init system.
But maybe he was trying to suggest that systemd isn't actually an init either. I'm sure it contains a complete implementation of a C standard library, a shell and a wifi layer, too, by now. Maybe those are written in fewer lines of code, too, for all I know.
Actually, I do wonder why he's bothered that Cargo doesn't meet their requirements. That seems a little off-brand; I'd have expected him to just add an entire Rust build toolchain to systemd and roll with it.
I'm still trying to understand why I'm meant to hate it so much. I know it rather breaks the "do one thing and do it well" philosophy, and I know it forces certain ways of interacting; but it does solve some problems and brings the whole service management game up to date. I have no particular attachment to the ancient ways, even though I "should" as an old skool Unix bod (cut my teeth on Solaris in the 90s before Linux took over). Let's hear it for the positive aspects of systemd.
For me, broadly it seems to work fine if I don't have to interact with it at all. But, and like the poster just below you, I once tried to get it to do a thing (in my case - more or less to automatically run something once networking was up), and I couldn't work out how to do it, and I found the documentation incomplete (or maybe I just couldn't find the right doco), and because the things that look like they should have worked (based on available doco/examples), didn't.
So there's different sorts of "works" here: (a) working ok in the background as setup by your distro, and (b) working when someone wants to make it do something beyond that .
2 things:
1) SystemD re-implements some features. But it does so in an unexpected and worse way. For example, fstab mounts used to fail-soft, leaving you with a system which while broken, could at least be logged in to to fix it. Now, mount fails are fatal. Ands since the mounting (for swap files) happens in initrd, just patching fstab frm a rescue disk doesn't fix it.
2) It does not work like it's documented. I was trying to implement a script that runs on shutdown before the users are logged out. It seems that the user sessions are ended, and their processes killed, before any unit shutdowns are processed.
2.1) Oh, yes, changed defaults to suit LP's desktop. It used to be that processes started by users lived after the user logged out. Because he got fed up with Gnome desktop processes being left over on session end, he unilaterally changed the default to kill all processes on logout. You can disable this, but it surprises you when you first upgrade from SysVinit.
"but [systemd] surprises you when you first upgrade from SysVinit."
Yes. IME POLA abuse is common with systemd. We experienced a trend of escalating complexity and, ultimately, breakage from CentOS 6 -> 7 -> 8 . After a while it didn't feel much like "upgrade" from SysVinit, or anything else for that matter.
Fortunately the long delay (block, stall, whatever) that happened sometimes during shutdown seems to have eventually been sorted out, one way or another. I still don't really know if there's a proper way to "start this after the network is up", though.
I fear the other new features that poettering et al are talking about will be similarly unstable, unpredictable, and/or undocumented, at least for a while.
.."couldn't work out how to do it.."
Really? Take an existing service file. Copy it. Edit the line that tells it which excutable to run. Save it. Job done. I worked this out in about 5 minutes. Never managed to figure out how sysvinit worked at all.
I'll agree the documentation is crap, but the service files are so trivial and self-explanatory that you don't need it.
> but the service files are so trivial and self-explanatory that you don't need it.
Maybe if you're copying (cut-paste, whatever) something which is just like the new thing you want to do, with the same pre-reqs and dependencies and whatnot. Maybe.
But if you actually need something a bit different, perhaps with different dependency order or other conditions that systemd doesn't account for ("launch this service after the network is up"), then it's bollocks.
And the docs don't usually help in that case either, not entirely because they're just crap, as you say, but also because they're kinda all over the place, and useful examples can be scarce on the ground. And if you can lay your hands on the pertinent docs, don't be surprised if the documented behavior doesn't match reality.
"These are software tools, not objects of religious devotion"
This is *open source*. Religious devotion was open-source developed and is widely popular here.
The fundamentally undeniable point: this, indeed *is* open source. All the distros are free to choose anything else besides systemd yet here we are, with systemd being the most popular choice among the largest Linux distros.
So [devout tech-head] users loathe it, yet system devs and distro creators seems to [accept/love] it. So, there's a disconnect between the hardest-core tech users...and, mostly, everyone else, as forum boards covering distros from Debian to Ubuntu aren't DDoS'ing over systemd.
So, why? As some of the posts here describe, some people are very focused on ethos of *nix rather than if the OS plain works for most people. "Do only one thing, and do it well" was all and good 30 years ago, during Unix's limited-use hayday, but pushing the ethos on widely-supported, unknown hardware and beginner-to-intermediate level users - is that still the best idea? 30 years ago you didn't have sophisticated kernel-level GPU drivers, sound drivers, muti-kernel and multi-thread virtualization, and more. Was it becoming too much of a patch-together hodgepodge for devs, never mind users, to debug and administer? Sounds like it from Poettering's view, and sounds like it from the open adoption of systemd by the developers of distros themselves.
icon: flamesuit. Because this is a fierce and heated topic here, but this seems to be the minority opinion ("He received a rapturous welcome, with a massive round of applause, and not a single rotten tomato was flung") and they'll never admit that to themselves.
I'm inclined to say "of course there is". (Some/Many/but not all) system devs and distro creators accept it - well, probably because they have managed to get it to do what they want (or presumably they wouldn't have switched their distro over).
But that's not the only use case - many other linux users, such as the techy ones, might also want to get systemd to do something, but unlike the system-devs (etc) don't necessarily have the time to get to grips with the non-trivial ins-and-outs of how you get it to do things. But they do know that the old scripted system might've been clunky, but was otherwise dead easy, because even a vaguely techy linux users can write a script. So your techy user wants to make systemd do some particular task, but then hits what seems like a wall of poorly documented systemd blocking their way. And when they could've put together a simple bloody script to do it in 15 minutes. How is that not going to be annoying?
I can see that complaint but how often does this need to happen, and therefore do the kernel devs need to organize the init system to compensate for that fact rather than create a system that is cohesive and manageable from their end?
I guess this is the equation that they must compute, and it seems that the figures go in systemd's direction. My guess is, is that modern modules that need to be init managed are just so interdependent, so needing organization and cohesive management, that the issue of user adjustment to the init handling simply can't be reasonably factored in.
I notice that "figures" here is vague. If you mean a "used in distributions/installs" count then you may well be right, but "liked by users", then .. who knows? I imagine many or most users haven't noticed systemd at all, because they've never had to have any need to tweak its operation. But those same users would also most likely never have noticed the script-based system either. Should they count in the "figures that go"?
The thing is that it's not end users who get any significant say in deciding, since most likely they just find that systemd has been put there by distribution devs (as I did, when wearing my debian-user hat). If you want a *meaningful* say, you probably have to start cultivating a presence in your distribution's dev community, which would be a rather big step for some miscellaneous user who occasionally needs some kind of init-dependent auto-thing to be set up in their computer.
I would strongly suspect that the number of devs who choose/chose to set their distribution to systemd is vastly exceeded by the number of users who have interacted with it and dislike it -- but solely because the number of distribution devs is likely to be such a tiny fraction of the number of *any* user, so that even small fraction of dissatisfied users would be the larger count.
I think we might need to agree on what "figures" is being meant before deciding which direction they go in.
"because even a vaguely techy linux users can write a script."
And that, IMO, was one of the reasons systemd was pushed. STOP WRITING SCRIPTS! We hate scripts. Windows doesn't have scripts (Well, there's this powershell thing. But nothing to see here. Move along now.) Oh and pipes are out as well. Use Dbus.
Back when systemd was being sold (pushed in dark alleys, whatever) the biggest argument I got from its proponents was the number of process IDs the bash scripts it took to boot up Linux. So what? It's not resource limited like Windows. It just recycles the PIDs. So when I took a look at systemd, I just said, "No problem. It looks like I can put my init script in the service file and have it do the daemon initialization stuff just like in the old days. And I can even read/write to Dbus from a bash script and make myself look just like a proper systemd service.
"Nooooooooo! You can't DO THAT! The whole point was to get you techy people to forget about scripts. Bash, gone. Strings of simple, modular utilities all piped together? Gone. Command lines? Gone."
It looked to me like systemd was nothing more than a big social engineering ploy to get us to forget about Ken Thompson's Unix philosophy. And get us to "You will have nothing. And you will be happy."
Does it work? Who can say? What does it work *at*? If that question were simple, I – too – would honestly not care very much about it because I do not count "init systems" amongst my areas of interest, particularly. I do consider myself to be a systemd hater, however. I'll own it!
I can't answer the question of what systemd works *for* or at because it seems that systemd is trying to be everything: it is not just init. Every other news story about systemd concerns its creeping into yet another domain it has no reason to touch.
So, I ask: who can say it works? We can't even define what its scope is or what it will be, tomorrow, so who can define whether it is fit for purpose or not?
I hate it because I can't ignore it as long as I'm a Linux user. The way it creeps into every domain makes it necessary for me to know about it and care about whether it is fit for purpose or compromised. The more systems it touches, the more irreplaceable it becomes and the more I need to care about it.
I run Gentoo, on OpenRC, and don't even use systemd and yet, still, I have to care about it because of its outsized impact on the whole Linux ecosystem – that's why I hate it.
I don't know a damn thing about how sysvinit looks on the inside, or how OpenRC's upstream code-base truly is to hack on, but I do know that I can define their standard operating conditions and the job they're supposed to perform and I can answer that question: do they work? If I determine that either one is lacking, I can implement my own replacement to meet my needs because their scope is contained. It is nearly impossible to "replace systemd" in the ecosystem, today, and only becomes more difficult with every new development in this farce.
To judge that it works would require confidence that it succeeds at what it claims to do which I've argued is ineffable but it is easy to prove that it does NOT work because one only needs to find the stuff it breaks. I use Gentoo almost exclusively on desktops and servers, today, but I have used systemd-based distributions often enough to see it break, frequently, often rendering Linux mechanisms that should be 100% independent of init, like `sudo`, totally inoperable or introducing new supply-chain attacks, like the way the whole `xz` thing transpired.
Should the OpenSSH developers have cared about whether the supply-chain of `xz` should form part of their threat model because of how distro package maintainers at Debian might link things to satisfy the requirements of agent P's "init system"? That would be totally absurd but, yet, that actually happened. That actually came to pass. That is why I care. That is why I'm a raving, frothing lunatic with rage whenever I read about systemd. This situation *is* absurd.
… and it threatens our operating system: Linux. I actually like to be able to use computers that run a sane operating system.
Does it work? Who can say? What does it work *at*?
that's the core of the issue : systemd is a lie, and thus Poettering a liar, and I cannot trust a liar. SystemD was initially introduced as an init system, which is fair game. But it has evolved into way more things beyond any reasonable target (WTF is an init system doing with $HOME directories ???) yet the liar is still using the init argument. This is the first page of his presentation :
What is systemd again? “systemd is a suite of basic building blocks for building a Linux OS. It provides a system and service manager that runs as PID 1 and starts the rest of the system.”
That he now works for Micro$oft only makes things worse. So the question is not only whether "it works" for some undefined field, but "can I trust that it will not get in my way as Windows does now" ? While I don't have much arguments for the init part, even contemplating to touch MY home directory where I store MY data is an absolute nonnegotiable red flag.
You do realize that he has written/is writing/will continue to write - systemd - for his trivially replacable laptop. For example, problems with suspend/wake are not actually issues for servers because SANE people don't power servers off. We run redunand systems and patch/boot them monthly. The amount of time it take for the systems to boot does not matter in the least because we don't do it 10 times a day.
I CBA to find the link, but it's been explained very well how the vote was rigged to get that result. In reality, there wasn't a majority vote for SystemD, but because of the way the options were presented, and how some responses were taken as supporting SystemD, it got passed.
There were also what I would consider to be lies. Again, CBA to find links right now, but it was made quite clear that running SystemD as the Init would be optional and SysVInit would still be a supported option. It didn't need much understanding of SystemD to see that such a policy wasn't going to happen (not for long anyway).
Let's face it though it'snot a great fit...as mentioned it is not as it is clamed to be,.. modular or an init app.
Yes it does work mostly and I'm happy for you that you can get on with...stuff.
However I'm still weary about it's over reach... the facr that other than bsd not much has been done to make it more unix like.... the attitude that it is /was adopted just so readly by so many os's , and get over it does not satisfy. Also he has not endeard himself and at times has been quite hostile which wrankles me.... But the fact tht he now works for m$ positivly freaks me out!
been using mx without systemd ... as daily for the past few months and it does work well... although not sold on kde plasma
I find it staggering that almost all the Linux distributions adopted this crap so readily. Did they all get a bump on the head at the same time or something? Thank goodness there are several non-systemDread options out there (I’ve used Void for years now) but I do worry that there will come a point that this cancer is so widely used that many normal applications simply will not run without it - which I’m sure is P’s intent
I curse Prickhead for making this abhorrence. I also curse the distro heads for having a “duh ok” attitude and forcing it in the world
I tried to write a script to upload images from my camera when it was plugged in.
Simple enough task, right?
I fought systemd for about 4 weeks. Systemd did things like killing the script I ran to pop up an X Windows notification about what files were uploaded.
I gave up, moved from Debian to Devuan, and wrote a working udevd script in about an hour, which included learning how udevd worked.
The single WORST feature is how "out of the box" systemd attempts to turn even a simple embedded device into a general use laptop computer. You have to SHUT DOWN at least 2 "services" to use a serial port to control a device that is NOT a modem or get random CRAP inserted into your control protocol. You have to JUMP THROUGH HOOPS to make your device configurable as EITHER a wifi client OR an access point, ON THE FLY. You have to SHUT THINGS OFF for systemd, then write scripts of your own to turn stuff on and off without rebooting. It is a PAINFUL WASTE and Raspberry Pi (and similar board makers) made a HUGE MISTAKE in NOT going with DEVUAN as soon as they could!!!
Systend is like an UNNECESSARY WALL that REAL engineers (not just hackers) would rather BLOW HOLES IN than go through its RIDICULOUS BUREAUCRACY!!!
and all I want is a touch screen that makes things turn on and off and displays metrics and stuff... with an OS that supports the latest hardware.
This post has been deleted by its author
@Gene_Cash
....I wrote a script in Python3.......
.....to upload new images from my laptop to my server. (Note: the server environment also includes a database which catalogued the images).
.....Yup....23K of Python3 script.....works like a charm..........
.....running on pretty much vanilla Fedora 41/XFCE machines.............
.....everything involved uses X-Windows, ssh, sshd, F41, systemd.....and who knows what else.........
.....written in Python3...................
Please give me a break.........NO ONE needs to move to Devuan.......ALMOST no one gives a rat's ass about systemd................
"Poettering began to realize that he was running out of time, and as he moved to the section titled "Goals and Challenges for the Future," he started skipping more and more slides, while also speeding up, and things started to become a bit less coherent."
There is a metaphor in there somewhere.
Agent P might want to present the roadmap first next time. The history is all out there is it not?
> Agent P might want to present the roadmap first next time.
A suspicious and/or cynical person might think he avoided that intentionally.
Seems like most times poettering announces yet another new so-far-beyond-init-functionality-that-you-can't-even-see-PID1-from-here feature, it results in a bunch of backlash and controversial coverage.
Unfortunately he keeps doing stuff anyway, perhaps hoping the experienced people won't notice this time, knowing the burned-out regulars have already thrown up their hands, and his fans will go along with it like they always do.
I was surprised to see Dorsey blacklisted for selling Twitter and making "a massive profit" from it. Firstly, he reinvested most of the sale money back into shares of New Twitter, so he has actually lost over half that value. Secondly, every anti-Musk activist I heard at the time was vehemently opining that Musk must stick to his original too high offer and not be allowed to back out of the deal. Go back and check the comments on the reg and ars technica.
Now he is a founder of Blue Sky, which is open source and quite big, so a talk seems reasonable.
I worry about the activist left poisoning itself with trigger finger cancellation as a substitute for policy.
> "Sorry, but my printer is not a file!"
Hmmm. He can't be at the front of the room if he is that stupid, or that aphasic. So WTF is he on about??
Mesopotamian merchants made marks on clay tablets and FILED them on shelves. Has he really confused the stylus for the data?
When I "send text to the printer to file it", I expect to get marks on paper or other artifact suitable for FILING storage, retrieval.
When my wine business gets huge, and I have many stylus-scribes working under me, I'll probably assign accounts or divisions to them by name. Akaru, Bob, Con:, LPT (1,2,3) so I know who to promote or fire.
A printer is a really bad example of a device that can't be handled as a file.
For most printers, you can actually treat their interface as files. You write stuff to them, you read stuff back if you have to. UNIX like operating systems have been doing this for decades.
The problem now with printers is not that they can't be treated as files, but that the name space that you use to access them is not like a filesystem any more.
The better example, and this actually does cover modern network connected printers, is communication devices and anything else that may make connections to a system in an unpredictable manner.
In the past, everything connected to a system was known about, or latterly could be discovered at boot time. This is because systems were largely static. With the introduction of networking (and to a slightly lesser extent hot-plugging of devices using USB), things needed to become more dynamic, because a system could not know everything about the wider environment that it sat in or how it was going to change. For example, in even in a simple network involving DHCP, with dynamically allocated IP addresses, things come and go, and you need to find some way of addressing this. People tried to make DNS cope by attempting to integrate the DHCP servers with the DNS servers, so you could use a name-space to try to address things. But it does not always work, so other methods involving the use discovery methods like mDNS were invented, and suddenly the world no longer looked like a filesystem.
I understand that there needed to be another abstraction layer to cope with this, but the mechanisms that were invented are largely opaque, and involve namespaces that are difficult for a mere human to understand.
Going back to printers. In the olden days, a printer was attached to a serial line, or some form of parallel interface, or in some cases more complicated connections like IBM Channels (yes, I've used channel connected printers on UNIX). In all of these cases, you had a kernel level device driver or module that was normally presented to the users as an entry in /dev, named appropriately for the type of device, and you could open this device as a file and write (and read) from it.
When things like USB became common, the configuration of a plugged in device was handled by a system such as udev that often created an entry in /dev, which was named appropriately for the type of device, and you could open this device as a file and write (and read) from it. And USB printers were handled this way. It was important for the older printing systems on Linux that a device plugged in always resolved to the same name, a real limitation, but this has changed with later versions of Cups which are somewhat more dynamic by hashing together various pieces of information to create a resource locator.
But now, you have to run a mdns discovery service to find things like printers. And to my dismay, I've just found out that Agent P was one of the co-developers of Avahi, which is one of the Zeroconf systems used by Linux! And even USB connected printers plug into this system, so you no longer get entries in /dev for printers.
The name space used by these services is not like a filesystem, and the way to access the devices discovered is less like opening a file and writing to it, and more like opening a connection to a network device and writing to it (which it really is). But this is complicated, and quite obscure (do you know the connection address of your WiFi printer? Do you care? What if you want to access it outside of Cups?), and in my view is not suitable for things like USB connected printers.
So I would say that it is not the printer that does not look like a file, it is the way that the printer is discovered and addressed that makes it look not like a file.
This software obeys the letter of the GPL licence, but fails to take the sprit of open source software. Sort of like a monopoly state run store. The bazar has only one stall and one product here. Your choices are “yes” and “not no”.
The problems that systemD solves were not mine and indeed I need not repeat the problems that it has created. 5 seconds faster booting is a saving rarely. Unexplained “features” kill my time so much more frequently.
Slackware since, oh gawd, I forgot when. But have dallied with other distributions.
"! 5 seconds faster booting is a saving rarely. "
That alone labels P. as a patentable, self-centered moron: 5s every .... what, exactly? Every 6 months? Even windows machines are booted only once per month nowadays.
"Slackware since, oh gawd, I forgot when. But have dallied with other distributions."
I remember, version 3.1, 1996. Two boot floppies and machine had a network, then the rest from university repository via glorius 10Mbps Ethernet, piece of cake.
I'm quite sure I still have the floppies somewhere. No idea if they still are readable.
I have several! When I dispose of systems, I tend to remove anything that I think may be of use, so I have boxes of hard drives, memory, floppy drives and interface cards.
I while back I realised that all the mobo's I had were PCI, so out went all of the ISA adapter cards.
The last time was involved in a build of a larger deskside system with an ATX mobo (just over a year ago), I noticed that they still have connectors for floppy disks, although the smaller systems and laptops have lost them, and for those you would need to use a USB connected floppy, which may not work for all purposes. Almost certainly not for booting floppy versions of Slackware, as these probably pre-date USB chipset support.
That sentence is true, but not in the way most of you think. Those who don't UNDERSTAND Unix, but just WORSHIP it blindly, are incapable to understand its many design flaws and mistakes, so are doomed to repeat them, and reinvent a poor operating system alike it, just it was done with Linux, instead of deigning a better one. So we are still here with a fifty year old design showing all its outdated designs, like its tty interfaces.
And speaking about printers, the author of the article shows exactly that. If as a low level device a printer gets a stream of bytes - it's at the of a USB or Ethernet connection, how could you send that to it otherwise? - from an application point of view a printer is not a file, it's much more alike a graphic card, it's a "canvas" where the application set the page size and draws upon it. Then sure, some process has to convert that in a stream of data to be sent to the printer, but if you want a true high level printer API that cannot be a file-like API. That's something Windows got right with GDI in 1990 - thirty years ago. Linux got CUPS, which will be even worse in the upcoming version, because advanced printer features are "garbage" for their maintainers. And many actual high-end photo printers don't use Postscript-
Of course in 1970 printers were just teletypes printing lines, time to move on from there - even for CLI windows.
This should be straightforward, but no chance it WILL EVER WORK!
sudo mount --bind /home/grunchy/libvirt\ images /var/lib/libvirt/images
This works fine! But it won’t work in /etc/fstab:
#work, damn you!
/home/grunchy/libvirt\040images /var/lib/libvirt/images none bind
Why?! Who the hell knows? Incidentally, the clue is that / is 200GB non-encrypted and /home is 3.3TB encrypted. <-- this makes sense to do!
sudo mount -a
Yep that works, but NEVER on boot up.
crontab -e
@reboot * /opt/scripts/stupid.sh
Not a chance!
/etc/systemd/system/stupid.service
Not a chance!
This is on Mint, btw.
/etc/rc.local
No Go.
There’s a hundred ways to skin the cat and they ALL FAIL.
My suspicion is that the /home hasn’t decrypted and mounted yet causing the other mount to flop, so you would think sleep 10 might give it a chance, or dmesg might throw a clue, and NO, nothing works!
Gave up and reconfigured virt-manager json config thingy to just point to /home by default.
(I could never remember where the heck /var/lib/libvirt/images had put all my Qcows anyways.)
</flame>
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
