EEVblog Electronics Community Forum
Products => Computers => Topic started by: PKTKS on October 15, 2021, 09:30:36 am
-
Thanks for all those serious folks that can not bear such aberration...
We have a new release of a systemd free Debian...
Thanks!
According to...
https://www.phoronix.com/scan.php?page=news_item&px=Devuan-4.0-Released (https://www.phoronix.com/scan.php?page=news_item&px=Devuan-4.0-Released)
and go here to read absolute awesome comments from serious people...
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1284496-devuan-4-0-released-as-debian-11-without-systemd/page2 (https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1284496-devuan-4-0-released-as-debian-11-without-systemd/page2)
QUOTED
I think the main point is always missed in most discussions.
Systemd is not an Init system, neither its a friednly Open Source alternative for some other OSS tools and solutions. And it had never been such a thing from the start.
1. Systemd is an extreme commercial marketing invasion from the ground up. It's all about aggressive commercial marketing and politics. Not free software for kind home hackers.
2. It had never been planned to be an init, it was planned to become a Complete Operating System under the Linux kernel. Init - was just a clever Entry point.
3. Why? To eat all well-known linux distributions. To get a huge amount of free beta testers.
4. Why next? To build a commercial product for End user devices - for mass market. Gnome going the same way. All this stuff like Wayland, Gnome, Systemd, Firefox to have an independent from Microsoft/Apple - commercial devices with glass screens. Some still call them PC''s.
5. Why else - and mostly this - commercial services on the the data center side. Those who collect and still our data. This is probably the number one systemd mission for now, it is build just to fit those needs.
6. It is being marketed extremely unpleasant, with the whole corporate culture and methods behind. Starting from blog posts, blog texts, crafted comments, supporters and speakers.
7. From the software point of you - it's architecture and usage is really brain-damaged. It is extremely over-engineered, uncomfortable, authoritarian.
So nothing here about free software, computer hobbiests, linux lovers, distros, good new software.
It's a pure corporate killer from the very start, it's about corporate revenue, and all the hate is reasonable.
I am sick of these filthy POTTERIX thing..
thankfully I am not the only one.. :wtf:
Paul
-
Downloads, development, and more info at the distro home, dev-1.org (https://dev-1.org/) (will always redirect to https://www.devuan.org/ (https://www.devuan.org/).
The current stable release (as of 2021-10-14) is Devuan Chimaera 4.0 (https://www.devuan.org/os/announce/chimaera-release-announce-2021-10-14).
-
D-Day, celebration day ;D ;D ;D
-
Downloads, development, and more info at the distro home, dev-1.org (https://dev-1.org/) (will always redirect to https://www.devuan.org/ (https://www.devuan.org/).
The current stable release (as of 2021-10-14) is Devuan Chimaera 4.0 (https://www.devuan.org/os/announce/chimaera-release-announce-2021-10-14).
They were also clever and kind enough to ditch PulseAudio...
Which is very much like Wayland a deliberate hack to be used under systemd management..
a total crap for serious use...
The de facto DAW Audio tool is JACK.
Nothing related with PulseAudio.
Good to have back a clean systemV DAW equipped with JACK and pure ALSA.
Thanks these folks :-+
Paul
-
Great news! :-+
Does this means the default Debian distributions from now on will be without systemd?
-
Great news! :-+
Does this means the default Debian distributions from now on will be without systemd?
No my friend.. it never was...
Since day one when systemd was forced through everybody lives without an option several ones clever enough debated that countless and very raged times...
Due to the monetized (sponsorhship) aspect of systemd it became clear to be impossible to compete with that kind of financial power.. Behind them there are those corps with the clear aim to monetize not only linux but the whole aspects of privacy and property..
Dvuan is a FORK of DEBIAN because the "leaders" are more or less kin to sponsors..
(Aka everybody knows who loves Linux.)
Same apply to at least all major distros (Except Gentoo and Slackware)..
Each one was forked by people that can realize the nasty tragic show that lies underneath POTTERIX
Using every possible own resources...
Many Thanks these folks!!!
Paul
-
Then why the blogged article says in the title Devuan 4 released "as Debian 11"?
Will it be released with the name Devuan 4, or with the name Debian 11?
-
Then why the blogged article says in the title Devuan 4 released "as Debian 11"?
Obviously written by a non-native English speaker. It should have been "Debian 11 without systemd released as Devuan 4.0", which is not exactly hot news.
Of course our dear old PKTKS had to repost here with the same garbled title |O
Dont think so...
I track and mirror Devuan since day one.
They have always used that nomenclature while trying to reference a stable Debian with the current stable Devuan
That makes sense
So you can use any package not crippled by systemd in both
Obviously using your own tracking
This is not an error
It is a method of the forking
Makes sense
Paul
-
Much exuberance.
-
ehhhhhhh
I am not sure what is better or worst... ???
I rather prefer using a sane snapshot numbering system..
Like this one cross relating a stable Debian with a stable Devuan...
than.... using that funky shitty "naming" Bull... Rat.. Mysss..
Can not figure out why they have to put names like these on distros.. :o
never could ::)
Why one would name a distro like a PET? a loved (or cursed) chick?
or a FUK*** disease more or less...
Paul :horse: :popcorn:
better use numbering
-
Releases use names for the exact same reason storms have names. (They even use the exact same method, just with a different name lists.)
Most developers and meteorologists would be happier using numeric references, or perhaps date-based labeling; myself included.
It's when dealing with users that those break down; non-technical/non-scientific people never get them right.
With names, there's a better chance of knowing what the users are referring to (and easier for newspeople to talk about, without confusing listeners about whether they're talking about currently active stuff or past stuff).
Don't forget, the majority of humans are rather stupid, and prone to magical thinking (https://en.wikipedia.org/wiki/Magical_thinking) and anthropomorphisms (https://en.wikipedia.org/wiki/Anthropomorphism).
-
Also antimagical thinking - refusing to see patterns which are plain to see.
"Hey dude, we just fix that new bug in a jiffy while you get used to that one new feature and you will have no trouble with systemd*** ever again" :-DD
-
Though, names are very useful when googling something about a certain version.
Numbers tend to be ignored by search engines, or at best they are considered but not associated with the word preceding them.
-
Slackware never ever had a problem with a plain simple numbered releases..
If you google slackware-3 or slackware-14 you got sane results...
IMHO that kept the "brand" Slackware clean and organized..
Not to mention it is still the most *NIX of all.. faithful and trusty..
Besides FreeBSD and OpenBSD of course...
although they are being forced to adopt some "modern" shit from some distros
Paul
-
Slackware never ever had a problem with a plain simple numbered releases..
No, but they didn't have to deal with masses of non-technical users either.
If it matters, I don't know the release names of even the distros I use; I don't find them useful either. I wasn't trying to advocate for using them, just trying to explain why they're used. Even I, when talking to non-techie users about some specific distro and its version, will look the version "name" up, because non-techie users just grasp things better if they have a clearly distinguishable name as opposed to just a version number. In the other direction, when trying to glean technical information out of them, errors in the names are also easier to detect.
In particular, I've managed a complete non-techie relative to run cat /etc/deb*ion and cat /etc/issue when talking over the phone, to find out approximately what distro they were running –– and yes, they did misread the version number in /etc/issue.
-
Slackware never ever had a problem with a plain simple numbered releases..
No, but they didn't have to deal with masses of non-technical users either.
(..)
Perhaps...
But probably by the time they appeared (circa early 90s) the goal was pretty much to have anything better than blue screens of death... and alternative to SCO/AIX or HPUX
Precisely my case when dumped the SCO to a much better Slackware.
soon Debian and RH evolved and the distro fever started...
The obvious twist to commercial interest w/systemd made the forks..
Back to the point who needs commercial crippled windooze like NIX?
Technical users?
I doubt. All serious capable ones will ditch (yet again) that crap (again...) :palm:
back to the ground zero
Paul
-
That's exactly the reason I personally want there to be not only different Linux distros, but other free/libre OSes like FreeBSD and OpenBSD, too. No need to start from scratch (https://linuxfromscratch.org/), just pick and choose what one sees best for the task at hand; at least as long as there is still choices to be made, and customization is not forbidden by some inane license, policy, or political law.
Which reminds me: OpenBSD 7.0 (https://www.openbsd.org/) was also released very recently (2021-10-14). No systemd there, either.
If one wants to set up a small server –– not just x86-64, but many arm64 boards are also supported; including Odroid-C4 and Odroid-HC4 (for a NAS, for example) –– running OpenBSD on it might be an excellent idea.
-
Dont think so...
By 2000s I tried Debian..then RedHat (both *BEFORE*) the crappy systemd...
Then realized that being held on their "distribution cycle" is more a problem than a solution
Got back to full Slackware on all changed server..
But I had an utmost need to have a operating NAS with:
- full hardware support
- capable to adapt to whatever change in hard/soft needed
- capable to scale wo any license or soft restriction...
Then came LFS - implemented my NAS based on it.
Never stopped.
later changed the core to Busybox so to operate diskless from RAM only..
so far it works up to today on rolling basis..
The thing w/LFS..
You are 200% free to mount your base system.
no more no less. Pick EACH item yourself...
bye bye distros
It just works
Paul
-
Poor Derek.
https://www.youtube.com/watch?v=QsuI-nLqwhg (https://www.youtube.com/watch?v=QsuI-nLqwhg)
-
https://www.youtube.com/watch?v=QsuI-nLqwhg (https://www.youtube.com/watch?v=QsuI-nLqwhg)
That's a waste of time. A tormented 30 minutes rant. :-//
The Ubuntu install was just fine, except the snap repos application. That window was not populated with packages by categories, and doesn't show any feedback,while installing something, maybe a bug, I don't know.
Then he starts a snap install, then seconds later he starts another snap install for the same program, the GUI tells him it can not do the second install because it's busy with the first install that was still in progress. He doesn't bother understanding the message or even reading it, let alone looking up for its meaning.
Other than that, nothing looked different at Ubuntu, same like in the last 3 years or so, except this time the installer can install on a ZFS file system, and the apt does automatic ZFS snapshots at install, which is great.
-
Then he starts a snap install, then seconds later he starts another snap install for the same program, the GUI tells him it can not do the second install because it's busy with the first install that was still in progress. He doesn't bother understanding the message or even reading it, let alone looking up for its meaning.
The OS is meant to invite users over to Linux. It's hard to ignore the fact it's offensive that a company like canonical could drop such a release into the wild in 2021.
-
I just tried to uninstall an app on Windows while another app was uninstalling and OMG it told me it couldn't because it was busy uninstalling the first!
The OS is meant to invite users over to Windows. It's hard to ignore the fact it's offensive that a company like microsoft could drop such a release into the wild in 2021.
-
I'm just here to see if anyone has somehow found a way to blame Micro$oft Windoze for this yet.... you didn't let me down. ;D
-
I've been using Devuan since the Jessie alpha releases, and prior to that using Debian on the desktop and back end since about 1996.
I know and understand Debian and its package management, but when systemd came along it broke things in a way I had neither the time nor inclination to figure out. Thankfully a group of people make a reliable derivative using the same init system whos source code floated to the surface inscribed on wooden tablets when Noahs ark sank. It might be old, but it's simple and I can fix it when it breaks.
I'm not religious about it, just lazy.
-
It is not a question of being lazy... :o
The folk on phoronix summarizes the problem very well
It is all about a nasty shitty business hidden underneath systemd..
I am not willing to be held hostage on yet another shitty buz of some corp..
I had enough of it in the 80s 90s... enough. :-\
On the other dark side... WTF!
Who in hell today! in the 20s ...
Is willing to pay a garbage OS like windooze...
If they do not insist on their "bundled in manufacturer" business they are doomed..
You can see "discounts" of more than 90%! (go figure) to sell this shitty OS..
https://www.godeal24.com/windows-10-professional-32-64-bit-1-pc.html?g24=sgo23 (https://www.godeal24.com/windows-10-professional-32-64-bit-1-pc.html?g24=sgo23)
Who is willing to pay for a dead crawl shitty OS that requires you logged on their telemetry servers.. just drop the shit hard and move on..
A hundred other distros can replace that shit..
Anyone can even craft a simple one..
Paul
-
Most developers working on systemd components do not have any nefarious intent at all. It is therefore natural, albeit incorrect, to infer that there is nothing nefarious in the entire project either.
The problem is, no pun intended, systemic. Let me give an example.
A lot of users "know" that sudo and su are security-sensitive, and know to be suspicious about changes to related packages.
Very few users know that PolicyKit (https://wiki.debian.org/PolicyKit) package is even more security sensitive, because it allows privilege escalation without user intervention. Compare to sudo, which is configured to ask the users own password unless recently executed in the same session (terminal connection) exactly to avoid such from happening, and stops compromised user processes from escalating their privileges automatically.
Many of those reading this have checked and modified their /etc/sudoers policies to suit their needs, but how many have ever looked at PolicyKit policy files? Or even know where to look for them? And know that there is *more than one* set of those, both used? (In Debian derivatives, /etc/polkit-1/ and /var/lib/polkit-1/; this kind of configuration file sleight-of-hand being rather typical of systemd components, especially when compared to traditional Unix, which kept system service configuration under /etc/.)
There is a reason why even the Debian Wiki page for PolicyKit (https://wiki.debian.org/PolicyKit) has a "ToDo: explain how it works." and it is not that it is so obvious everyone knows. By controlling the component and keeping it within a small circle of developers, those developers are essential to system security. Job security for subpar developers. It is in their best interest for the component to stay quiet, and keep the developer count small.
I'm not convinced there is anything more evil than "by doing things this way, we ensure we'll have good jobs for ourselves for the foreseeable future" by programmers who really do not understand security at all, but I do believe systemd is a bigger turd than even PHP. Like PHP, systemd gets used because it is popular and available. Like PHP, it is at its core an insecure, impossible to secure or make robust, "design" –– and it isn't even designed properly, just agglomerated together like a dirty snowball.
At least it is a known issue that core security services like OpenSSH and core security libraries like OpenSSL and other TLS implementations, need more resources, especially eyeballs, for the free/libre software stacks to remain viable. But, almost nobody looks at the systemd security components, because its a socially closed domain governed by subpar developers (who have been rejected from other projects due to the low quality of their submissions).
(And I do fear, without any proof, that that might be one of the reasons the companies behind largest Linux distros are so keen to back systemd, including paying the developers well.)
TL;DR: I don't believe there is any conspiracy that hopes to get their hands in everybodys Linux systems. I think systemd subsumes other components, because their developers want to be the ones everyone has to rely on; they want to be as indispensable as the Linux kernel is to Linux distributions. My problem with that is that not only are those developers not very skilled, but the structure of their design is horribly bad, unfixable; and that that much power in the hands of a few cloistered fringe developers is easily exploitable at the human level via money, extortion, manipulation.
And don't tell me I should just gather more people to expose these security risks by looking at the code in the public repositories. That is useless, because the fundamental design, the ways the components interact and work together, is impossible to make as secure and robust as the alternatives. A turd is a turd, no matter how hard you polish it. And, as long as the largest distros back systemd with hard money for unclear reasons, it is not possible to compete with it on purely technical terms: there are business and politics involved.
Devuan avoids systemd, and for the subsumed components, uses non-systemd forks.
Do not think that FreeBSD and OpenBSD are completely untouchable wrt. these issues, either. Just like in Linux initially, there is now an "init-only" systemd (fork), InitWare, that is reported to run on the *BSDs. It is being touted with exactly the same key points as were used when systemd-init was introduced to various Linux distros. Nothing new here, yet almost nobody notices when the history keeps repeating itself... "Oh, nobody could have predicted it would come to this!"
-
I don't think of some sort of conspiracy... ::)
Business with that kind of budgets are not mindless.
There is a strategy although hidden ... it may be seen clearly ahead
The only possible way to "absorb" (BORG style) all *NIX into the already establishment is to boot a summary kernel into a simple VM as fast as possible to run whatever "applet" as a "subthing"
Things in place:
- a systemd style fast boot
- all services asasp no security no hassles of admin. setups..
- a compatible layer of pipelines audio and video..
PUFF!! you have assimilated all *NIX into a crap VM with a single click
No conspiracy - but a hell damn nasty strategy.
All CLOUD services (already provided that systemd uses now USER Daemon)
will charge or rent you monthly fees..
to rent space.. CPU power.. ..
All already based "services" of adverts. profiling your life will continue.
As soon as the business ditch all PCs into that business..
As said..
systemd is a clever entry port..
Will gradually obliterate the PC as we know.
For these account based point click and pay for as you go
Things are in place..
Paul
-
Things in place:
You missed Snap packages (https://en.wikipedia.org/wiki/Snap_(package_manager)), which are essentially filesystem images mounted on loopback devices as needed, making them almost independent of the installed libraries on the system; relying on PolicyKit configs to get proper low-level access, and other systemd provided services only. Unlike e.g. Debian packages, Snap packages are designed to work across distributions.
Essentially, because snap packages can be used across distributions, they by default avoid any scrutiny by distro maintainers.
No conspiracy - but a hell damn nasty strategy.
Very good for the provider companies, and fully backed by huge international organizations like World Economic Forum (https://en.wikipedia.org/wiki/World_Economic_Forum), who profess their purpose is to merge governments/governance and enterprises. As WEF's own Agenda 2030 says, "You'll own nothing, and you'll be happy."
-
My dim view of it was the way that it was touted and hyped among the distro maintainers. Here is this shiny new thing that will once and for all tidy up the problems(?) with the existing init systems. Upon closer inspection, it seemed to be implemented like every other project with that same goal. It begins by sitting on top and wraps the commands though the existing mechanism until someone gets around to actually writing the stand alone code.
-
It's always fun to read discussions about systemd. Almost triggers religious opinions in some way.
systemd has the merit of existing, and quite frankly, from my part, it has worked well enough. I'm no Linux guru nor some kind of warrior, so bear with me. But there's a reason why most distros adopted it: there just wasn't anything equivalent available.
I rather like this talk, which goes into some details while trying to be balanced and honest:
https://www.youtube.com/watch?v=o_AIw9bGogo (https://www.youtube.com/watch?v=o_AIw9bGogo)
-
But there's a reason why most distros adopted it: there just wasn't anything equivalent available.
Not true at all. Even today, if you bothered to go look at the Debian bugzilla or older CTTE discussions, you'd see the systemd developers consistently pushed that view, and now religiously object to any kind of interoperability with non-systemd alternatives. Even going as far as actively removing features used for interoperability, changing package dependencies from virtual packages to systemd implementations of those virtual packages, and so on.
Yeah, there is "balanced and honest", and then there is factual.
In Devuan, the init system is indeed up to the user to decide, as the later-subsumed subsystems are implemented using non-systemd alternatives. In Debian, systemd is the only choice, because if you allow eg. automatic package updates (because of aforementioned changes in package dependencies) sooner or later everything will be replaced by systemd anyway.
Users don't care, because they don't see the downsides. I remember a time when I didn't have to reboot my system due to updates, and when my desktop environment didn't crash just because the messaging bus (now dbus) daemons were updated and changed the protocol.
You do you, though. I would like to point out how objections to systemd even in this thread are insinuated to be unreasonable, even in the face of easily obtained evidence (debian bugzilla and debian-ctte mailing list about init system "freedom"). This kind of effective community management is enviable, and isn't free.
-
I rather like this talk, which goes into some details while trying to be balanced and honest:
https://www.youtube.com/watch?v=o_AIw9bGogo (https://www.youtube.com/watch?v=o_AIw9bGogo)
I'll qualify that video as propaganda. Dude finds excuses for all the pitfalls of systemd, his argument over the entire video is "there was no other way than systemd to solve all these problems", which is not true. And the title suggest something tragic about systemd. And the comments and youtube ratings are disabled. That's propaganda to me.
-
Linux user since 1998. YellowDog Linux for my PowerBook G3. Fine if you had an english keyboard. Not my case. Then I bought my first PC to have an easier Linux ride with it. Following the advice on all computing publications, tried RedHat first, 6.x
I replaced Debian for RedHat 7.0 when it came out, then realized that all the hype on computing publications about Debian being "difficult" against "easy" RedHat was bullshit. I have never bought any computing publication since.
Never had any problems with SysV init, so i never, ever felt any need to change it. However, since Debian migrated to it (and PulseAudio :-- ), and realizing that expurgating systemd from Debian would be such a huge task, I resigned myself to use it, and lost track of any possible alternatives. So thank you guys for the notice about Devuan
Systemd looks the same shit to me. It could be that it gives some advantages. Certainly my machines seem to turn on and off faster. But I don't like it rammed down my throat, and while it could be a bona fides effort, I somewhat doubt it. So I think it's time to install Devuan on a spare machine to see how it does.
-
Certainly my machines seem to turn on and off faster.
I find the system boots to a prompt much faster with systemd, but it takes the same amount of time to actually do anything useful as it's still starting services in the background. I have a hell of a time getting the system to shutdown properly with systemd. It's always waiting for something for minutes.
Thankfully I only have it on a couple of VMs for specific software that requires specific operating system versions (usually Ubuntu). My experiences with it on the bare metal have been woeful.
To me it just feels like an answer to a question nobody really ever asked.
-
Before systemd, Ubuntu used upstart, which booted just as fast as systemd does. Some non-systemd distros use OpenRC, which is older than systemd, and is still actively in development. SysV init was never the only choice, only the most popular choice.
On servers, since the turn of the century, I used a mix of SysV and daemontools or runit to manage services. (The servers tend to have very slow BIOS bootup times anyway, on the order of half a minute to a minute, so speeding up the boot is not that important.) Both daemontools and runit will auto-restart a crashed service, and can detect a repeatedly crashing service (instead of looping forever).
Customization was always the key feature I loved about Linux. It never imposed an approach on me; instead, I could always adapt it to my own needs and workflow.
At the user level, systemd is a serious block to that: it does not allow you to customize the core services much anymore. You can change their configuration, but you cannot swap a core service to another, since systemd won't allow you to, unless you reimplement a systemd component yourself. Which is kinda silly, as it is exactly the reason why the Linux kernel does not have a stable internal API: to truly redesign a component, you must be able to adjust its internal APIs accordingly, otherwise you're tied to the same design.
Users who do not do nor need that kind of deep customization, will probably be quite happy with systemd. They'll have to reboot their machines more often, they have more security issues (especially so in the future, when the extent of systemd security holes finally reveals itself), but nothing that really impacts their day-to-day stuff.
I know, because the machine I'm typing this does have systemd. So I'm not being paranoid, just realistic about the tools I use.
How many of you do not complain when the tools you used to rely on switch to inferior quality materials? They still work; it's just annoying, and risky.
-
What's this about systemd requiring more reboots? All my multiple desktops are systemd systems and I reboot exclusively for kernel updates, I've never had a need to reboot for anything else that I can recall, and I don't see why systemd would require that any more than any other service manager would. Ditto for the fleet of servers I manage.
That said, none of them are using systemd out of any intent of mine, as this thread goes into. However I'm not even the least bit upset about it. It's far more convenient as a user / administrator than any of its predecessors that I have experience with (Debian's SysV init scripts, upstart, BSD rc.d). It does away with a ton of boilerplate repeated all over the place and is much more featureful, flexible, and easy to use. I don't believe there is any conspiracy. It's convenient for distro maintainers, it's convenient for users, it's popular, it's a significant improvement on the previous situations, and it works reasonably well. The choice should not be surprising.
And since it keeps coming up, the same is true of PulseAudio. There were some teething pains, but there's no way in hell I'd go back to pure ALSA, it's just plain better in every way, and JACK cannot fit the role of system audio server well. Frankly, Linux on the desktop wouldn't really be usable for me without it having come around and gotten integrated. Using pipewire these days, but that's only possible because of PA, and both work fine, just trying out the new hotness.
I'm not super happy about systemd subsuming a bunch of random stuff, as it seems to be antithetical to the UNIX philosophy, but most of it is not really 'rammed down your throat'. Don't like systemd-resolved or systemd-timesyncd or systemd-networkd, then replace them with your preferred alternative (I have for all of these), no big deal at all, and no reason to expect the alternatives are going anywhere.
If one distribution is making 'political' decisions that exclude alternatives, then fork it, that is the open source way, but I don't see that being systemd's fault. I also don't see any reason that it's reasonable to expect Debian to maintain parallel options for something that is so integral to the system. The choice and setup of init, service manager, and package manager is a big part of what makes one distro different from another. You may not like their choices, and that is what is great about open source - choose a different distribution more closely aligned with you and move on.
-
What's this about systemd requiring more reboots? All my multiple desktops are systemd systems and I reboot exclusively for kernel updates, I've never had a need to reboot for anything else that I can recall, and I don't see why systemd would require that any more than any other service manager would. Ditto for the fleet of servers I manage.
Prior to systemd, I applied even kernel updates without having to reboot. I had uptimes on the order of a year, but still running completely up to date kernels. I even did a few local hotfixes for bugs without an immediate accepted fix.
Any update to core systemd components also requires a system reboot. Without the reboot, you'll risk crashes, because those core components assume all of them run the same version, and have basically no error checking. A typical symptom is your desktop environment crashing, because your (user) dbus-daemon process has crashed.
While systemd began as an init system and a service manager, it is a helluva lot more than that today. Perhaps you should actually go and have a look at all the things it has incorporated, from service management to privilege separation to interprocess communication, before you assume you know the facts – even if you are a system administrator, and believe you already know all you ever need to know.
-
My problem with systemd is that its developers are reinventing the wheel the Microsoft way and also have strange ideas how things should be done. It has some neat little features, but also makes some things more complicated and cumbersome at the same time. Summa summarum I don't see any real benefits. And I'm annoyed that many linux distros forced systemd upon users (quite Microsoft-like).
-
Prior to systemd, I applied even kernel updates without having to reboot. I had uptimes on the order of a year, but still running completely up to date kernels. I even did a few local hotfixes for bugs without an immediate accepted fix.
If you're doing live patching using kpatch or ksplice or similar, I'm not sure why systemd comes into it, both work fine on systemd systems, and systemd shouldn't care about the kernel, it is completely userland. Care to elaborate?
Any update to core systemd components also requires a system reboot. Without the reboot, you'll risk crashes, because those core components assume all of them run the same version, and have basically no error checking. A typical symptom is your desktop environment crashing, because your (user) dbus-daemon process has crashed.
The only one that could be problematic to restart is init, PID 1, which can be restarted with systemctl daemon-reexec. What am I missing?
While systemd began as an init system and a service manager, it is a helluva lot more than that today. Perhaps you should actually go and have a look at all the things it has incorporated, from service management to privilege separation to interprocess communication, before you assume you know the facts – even if you are a system administrator, and believe you already know all you ever need to know.
I guess you are referring to polkit as 'privilege separation' (of course the kernel is, as ever, managing privilege separation)? This isn't part of systemd, though systemd does depend on it, so I guess the confusion makes sense, and of course if you don't trust polkit or systemd that offers some system-level actions, you will see this as an issue. However it does provide much more granular and specific permissions, enforced by the kernel's privilege separation, than sudo (which also was not trusted by recalcitrant admins for a long time, but most have come around by now). This allows more things to run as a user and never escalate, which is ultimately a better situation. I'm not sure how difficult it is to replace this with the old way of just running things as root either through setuid or sudo as a practical matter, but something *like* polkit was definitely needed and it makes sense for the community to pick one as it requires integration on the application side.
dbus is used for IPC, which has been around much longer than systemd, and was already all-but-required on a modern Linux system when it was chosen for systemd. I believe systemd may provide an implementation of the service side, but there are at least 3 viable options, and the distributions I use are using the standard dbus-daemon as ever.
I think I have a pretty good understanding of what systemd does and does not do, and it is clear to me that the 'old way' needed to go. Is systemd and its pulled-in dependencies the best way forward? Eh, maybe not, but it is an improvement and there tends to be, even in the Linux community, a 'default' option for everything that is chosen by most distributions and users. I'm sure if that was OpenRC+polkit+something (what is the replacement to dbus, I don't think there really is one), there would be people complaining when distros switched, and others forking things to run on systemd. There's nothing wrong with that, and nothing stopping alternative implementations and distributions using them, but man the zealotry, accusations of malfeasance, and intentional or conveniently accidental conflation of ideas gets tiresome.
What the hell incentive does the Debian team have to choose systemd for vendor lock-in or whatever it is being accused of here?? It's one of the most legitimately-open distributions out there and has virtually no commercial footprint, and stuck to SysV init for longer than most.
-
Any update to core systemd components also requires a system reboot. Without the reboot, you'll risk crashes, because those core components assume all of them run the same version, and have basically no error checking. A typical symptom is your desktop environment crashing, because your (user) dbus-daemon process has crashed.
The only one that could be problematic to restart is init, PID 1, which can be restarted with systemctl daemon-reexec. What am I missing?
You're missing the fact that desktop update managers do ask/require reboots whenever a systemd-subsumed core service package is updated. If you do not reboot, and e.g. dbus-daemon binaries are updated, it is common for the desktop manager (gnome or cinnamon for example) to crash at some point.
If you're doing live patching using kpatch or ksplice or similar, I'm not sure why systemd comes into it, both work fine on systemd systems, and systemd shouldn't care about the kernel, it is completely userland. Care to elaborate?
Prior to systemd, when e.g. dbus-daemon was updated, it sufficed to restart just the updated daemon (or for nontechnical users, to log out and back in achieved the same) to ensure the updated binaries were being executed. It no longer works, because of the tight integration of the daemons to the root systemd.
(After updating core system packages, it used to suffice to restart the affected binaries; I did this in a staggered manner, to minimize the effect on provided services, but for users, told them to simply log out and back in, to ensure they were using the updated binaries and applications. This often still works on server machines without desktop environments, but isn't anymore what the developers recommend: they assume everyone reboots the machines after core system updates.)
As an example, after a few days of uptime, log out of your desktop session, then observe the process list. Very often, say 10-25% of the time, some of your user service processes (dbus-daemon etc.) are still running. This is a problem, and instead of fixing it, distro maintainers decided just to set the update managers to asking the user whether they wanted to reboot; and changed the documentation to recommend rebooting as the first "fix" to everything.
I guess you are referring to polkit as 'privilege separation' (of course the kernel is, as ever, managing privilege separation)? This isn't part of systemd
Yes, it is (https://wiki.debian.org/PolicyKit).
polkit manages privilege escalation to user services that need it. In practice, it means that an application can use polkit to elevate its privileges without user intervention.
I'm sure you want to quibble about "privilege escalation service is not 'privilege separation'", but I disagree.
Its freedesktop gitlab README describes itself as "polkit is a toolkit for defining and handling authorizations".
The problem with polkit is not exactly what it does –– the problem, fine-grained permission/privilege control, is real and sudo is designed for human users, not to be used by services –– but its implementation and how the developers try to avoid being noticed by users. Consider polkits Changelog (https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/ChangeLog) (it's empty), or a typical comment by one of the polkit contributors (Simon McVittie): "It should generally not be necessary for users to contact the original maintainer."
dbus is used for IPC
and has been subsumed by systemd. There are still non-systemd dbus implementations (that e.g. Devuan uses).
The core issue with the standard dbus-daemon is that it no longer forks processes itself, it only tells systemd to fork and execute them. Don't you see that no matter what you say about project organization, that is by definition subsumption of functionality: the dbus-daemon no longer performs the action, only delegates it to systemd.
it is clear to me that the 'old way' needed to go.
Sure, that I do completely agree with. I personally only used the 'old way' for the initial bootup, not for runtime service management, on servers I maintained, since 2001 or so. On desktops, I wasn't happy with the service IPC (what is essentially now dbus) approaches, because of their complexity.
(I also loved to use LDAP for larger organizations, as its configuration and inter-server-operability suited my needs very well. Then, Active Directory came along, and skewed everything so that now everything is Windows-oriented, and Unix/POSIX support is a second-tier citizen. Annoying as hell for someone who only uses Linux and BSDs, and not Windows at all.)
However, the service management side was already a solved problem (as shown by runit, daemontools, and other service managers), as was init (as shown by e.g. upstart).
There is absolutely no sane reason to require system services to use dbus to report their status –– neither the protocol or its implementation is at all robust. Do you recall the kdbus debacle, when they (well, Greg KH, who is a reliable and responsible developer, but really didn't think before submitting it) tried to push it into the kernel? Even then, a lot of people pointed out much better ways to implement the same in user space. The dbus developers main objection was that it was too much work, and what they have now works fine for them.
It would have been much better to simply continue forward with the dependency-based inits, with a very simple sub-init service manager using Unix Domain sockets to maintain connections to each service. This would have required adding a library and library status calls for every daemon, but at that point it was seen as "too much work" or "infeasible". Yet, that's what eventually did happen with dbus anyway.
(Why Unix Domain? Because on Linux and BSDs, it provides a way to both authenticate the communicating processes (PID, UID, GID), as well as pass new descriptors. Why not? Because it is not supported in Windows. I wonder why that would matter to dbus developers? I do not know.)
As shown by daemontools and runit in practice, they were much more robust in managing long-running services.
nothing stopping alternative implementations
Except systemd developers in e.g. Debian. They very actively object to any kind of interoperability with non-systemd components.
Just go look at debian-ctte mailing list and the bugzilla; such discussions are extremely common.
What the hell incentive does the Debian team have to choose systemd for vendor lock-in or whatever it is being accused of here??
There is no "Debian team". It is a community with extremely well defined rules, including very strict voting.
One of the core principles there is that maintainers are assumed to know what they're doing. In case of disputes and problems, the Debian Technical Committee (CTTE) can be asked to provide an opinion.
When Debian switched from SysV init to systemd, the idea was that maintainers would work together to ensure "init freedom". In 2014, Ian Jackson called for a general resolution (basically a vote by all Debian maintainers), to preserve the choice of init systems for the users. This kinda-sorta failed, because most maintainers felt it would have forced maintainers to maintain stuff they weren't interested in.
The systemd component maintainers took that as a carte blanche for rejecting all interoperability between init systems, and started actively blocking contributions to allow users to switch from systemd to another init system. Such actions have been taken to Debian CTTE many, many times now, but they're unwilling to override a specific maintainer exactly because they do not want to force maintainers to maintain code only others need (compare to e.g. out-of-kernel drivers, for example).
I understand the viewpoint, but I disagree, because I consider respecting the user freedom and interoperability more important than maintainer freedom, for core components of the system. I do systems level programming myself, and have contributed fixes and patches to everything from the Linux kernel to glibc and gcc, so I'm not saying here what others should do; I'm describing how I see our responsibilities and freedoms as core system developers/contributors.
stuck to SysV init for longer than most.
Do not forget, that the question in Debian was NOT whether to stay with SysV or switch to systemd.
It was whether to switch from SysV to upstart or systemd. The competition was between upstart and systemd, not between SysV and systemd.
-
You're missing the fact that desktop update managers do ask/require reboots whenever a systemd-subsumed core service package is updated. If you do not reboot, and e.g. dbus-daemon binaries are updated, it is common for the desktop manager (gnome or cinnamon for example) to crash at some point.
Of course you need to restart your desktop session when the underlying services are affected. This is the case regardless of whether you are updating dbus-daemon in a systemd system or one that does not use systemd. Restarting dbus-daemon may require a lot of services to be restarted, up to and including init, but it does not require a reboot.
Again, of course, package managers trying to resolve runtime dependencies and determine what actually needs to be restarted is nontrivial, and rebooting is always going to be safe, so that is what they recommend. Many systems also recommend rebooting after a glibc or other core library updates, for similar reasons; it's not required, it's just guaranteed to work and simple. This has nothing to do with systemd. dbus-daemon is not a part of systemd, and has been a dependency of desktop Linux systems since well before systemd even existed. This is not new. I don't know why restarting it doesn't work for you, but it works fine for me.
polkit manages privilege escalation to user services that need it. In practice, it means that an application can use polkit to elevate its privileges without user intervention.
I'm sure you want to quibble about "privilege escalation service is not 'privilege separation'", but I disagree.
That is not what polkit does. It provides a framework for describing and evaluating access policies to services offered by other processes, as the name and project description suggests. An unprivileged process accessing services offered by a privileged process is not escalation, and in fact it is exactly the point of privilege separation - to separate the privileged and unprivileged elements of the system with a clean interface between them. The unprivileged process never gains privileges, it accesses the services of another process. You may take issue with the privileged services that systemd offers this way or something, and indeed that may extend to process escalation, but it is not the only way to do that.
Privilege management itself, ie. what an individual process is actually allowed to do on the system) remains handled by the kernel's privilege system / cgroups.
Consider polkits Changelog (https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/ChangeLog) (it's empty)
The changelog appears in the NEWS file, from the git history it seems reasonably complete.
and has been subsumed by systemd. There are still non-systemd dbus implementations (that e.g. Devuan uses).
It seems like maybe you consider any project managed by freedesktop.org to be 'part of systemd' or something? As far as I know nothing has changed in the management of the dbus project, and it predates systemd by many years. It remains a separate project and separate system process that is not dependent on systemd. systemd, of course, requires dbus, though not specifically the freedesktop.org implementation (it can also use the in-kernel kdbus for example). This seems like fine separation of responsibility, compatible with the unix philosophy to me.
The core issue with the standard dbus-daemon is that it no longer forks processes itself, it only tells systemd to fork and execute them. Don't you see that no matter what you say about project organization, that is by definition subsumption of functionality: the dbus-daemon no longer performs the action, only delegates it to systemd.
dbus is a message bus. I don't have any idea what you mean by 'telling systemd to fork and execute processes'. It shouldn't be forking and executing processes or doing any actions at all, it's a daemon that passes messages. If it once did (though I don't think so, this would normally be started as part of your user session setup by your desktop environment or whatever), to aid session management, I would consider that is not its job, and systemd or something else with that purpose is the correct place to be doing that.
However, the service management side was already a solved problem (as shown by runit, daemontools, and other service managers), as was init (as shown by e.g. upstart).
Kind of 'solved' but not in a holistic and elegant manner. I know you don't like the fundamental idea of 'holistic', but it is IMO the cleanest and most flexible solution of any of these for process management.
There is absolutely no sane reason to require system services to use dbus to report their status –– neither the protocol or its implementation is at all robust. Do you recall the kdbus debacle, when they (well, Greg KH, who is a reliable and responsible developer, but really didn't think before submitting it) tried to push it into the kernel? Even then, a lot of people pointed out much better ways to implement the same in user space. The dbus developers main objection was that it was too much work, and what they have now works fine for them.
On the one hand you are complaining about a particular implementation being dominant, and on the other you are dismissing attempts to create diverse implementations. Which is it?
And systemd does not require services to do anything at all with dbus, it works with simple shell-scripts, or whatever other unmodified process just fine.
It would have been much better to simply continue forward with the dependency-based inits, with a very simple sub-init service manager using Unix Domain sockets to maintain connections to each service. This would have required adding a library and library status calls for every daemon, but at that point it was seen as "too much work" or "infeasible". Yet, that's what eventually did happen with dbus anyway.
I strongly disagree. Tracking the actual state of the processes is a huge improvement, and another process' state is not the only thing that you may want to depend on. Having dependencies actively managed is a big step forward over a bunch of shell nearly-but-not-quite-identical scripts returning their execution status (maybe).
On the one hand you complain about systemd requiring services to implement something in dbus (which it simply does not), and then in the other you are suggesting that services that are unmodified simply won't work with your system, which is both worse and the same kind of tight coupling that you are railing against. This is just plain inconsistent.
(Why Unix Domain? Because on Linux and BSDs, it provides a way to both authenticate the communicating processes (PID, UID, GID), as well as pass new descriptors. Why not? Because it is not supported in Windows. I wonder why that would matter to dbus developers? I do not know.)
Railing against attempts at improving portability are not going to win me over.
Except systemd developers in e.g. Debian. They very actively object to any kind of interoperability with non-systemd components.
Just go look at debian-ctte mailing list and the bugzilla; such discussions are extremely common.
Trying to keep this technical, because the political aspects just don't interest me and I really don't care. This is part of what makes open-source great. If you don't like the decisions of the project, you fork, and either continue in obscurity, or the community agrees and adopts the new project. IMO the system init and process management is core to the system, and I see no reason that Debian should be expected to support multiple solutions. You would never expect Debian to have proper support for RPM packages in the core system, why do you expect it to include multiple init options? Maybe if someone wanted to take it on it could be a different operating system a la Debian GNU/HURD.
There is no "Debian team". It is a community with extremely well defined rules, including very strict voting.
Yes, that is my point.
You have made a lot of accusations about people having malicious intent in pushing systemd, and that is what I am pushing back on when I am even willing to get into the politics here. What is their motivation? It just sounds like everyone involved is making sensible decisions for the project and themselves, and the overseers don't see any real problems with those decisions, which is more or less where I am sitting. But like I said, I don't really care to get into the politics.
I understand the viewpoint, but I disagree, because I consider respecting the user freedom and interoperability more important than maintainer freedom, for core components of the system. I do systems level programming myself, and have contributed fixes and patches to everything from the Linux kernel to glibc and gcc, so I'm not saying here what others should do; I'm describing how I see our responsibilities and freedoms as core system developers/contributors.
Core components of the system are the ones that are least likely to be interoperable and interchangeable. This shouldn't really be surprising. Those core parts of the system are what makes the system what it is.
Do not forget, that the question in Debian was NOT whether to stay with SysV or switch to systemd.
It was whether to switch from SysV to upstart or systemd. The competition was between upstart and systemd, not between SysV and systemd.
Upstart is objectively terrible, and is now basically abandoned. Canonical developed it, were the only notable distro to ever use it, and even they quickly migrated away. If that was what the Debian team was evaluating as an alternative, they made the right decision.
-
You're missing the fact that desktop update managers do ask/require reboots whenever a systemd-subsumed core service package is updated. If you do not reboot, and e.g. dbus-daemon binaries are updated, it is common for the desktop manager (gnome or cinnamon for example) to crash at some point.
Of course you need to restart your desktop session when the underlying services are affected.
I wrote "reboot", then explained that *it used to suffice* to restart ones desktop session, for example logging in and logging out, but no longer does (as it leads to instability).
Perhaps you should read some tutorials to understand the difference between rebooting a machine and restarting a desktop session.
I do not believe that that anyone can say or show you anything that will affect your opinions, which you state as facts without any basis, so discussing any of this with you is objectively worthless.
-
It would have been much better to simply continue forward with the dependency-based inits, with a very simple sub-init service manager using Unix Domain sockets to maintain connections to each service. This would have required adding a library and library status calls for every daemon, but at that point it was seen as "too much work" or "infeasible". Yet, that's what eventually did happen with dbus anyway.
I strongly disagree. Tracking the actual state of the processes is a huge improvement, and another process' state is not the only thing that you may want to depend on. Having dependencies actively managed is a big step forward over a bunch of shell nearly-but-not-quite-identical scripts returning their execution status (maybe).
On the one hand you complain about systemd requiring services to implement something in dbus (which it simply does not), and then in the other you are suggesting that services that are unmodified simply won't work with your system, which is both worse and the same kind of tight coupling that you are railing against. This is just plain inconsistent.
I agree. The old init scripts are no good for a modern day system where services can start / stop at any time and have strong dependancies (for example: don't start an application before Wayland is up & running as it needs Wayland for output). From an operational perspective systemd makes life a lot easier. For starters: Being able to query the status of a service (which can be totally unaware of being run from systemd) using systemctl status <service name> makes life a lot easier compared to digging through one of the many system log files and filtering out the messages you are interested in. As a user I really don't care about politics are how something is built. As long as it does what it should. Given the fact that most distros have switched to systemd shows that it is better than 1) what was before 2) what else is out there. And likely it will be replaced by something else at some point.
-
I agree. The old init scripts are no good for a modern day system where services can start / stop at any time and have strong dependancies (for example: don't start an application before Wayland is up & running as it needs Wayland for output).
That only applies to SysV init, and I didn't use it for service management after 2001 or so; I used daemontools and runit.
Both daemontools and runit track the state of the daemon (primary process, in particular).
The system level interface for dependency tracking should be implemented as a library interface; for example,
int service_report(const char *svc, const int state);
could be a thread-safe, async-signal safe interface to report the service daemon facilities and state to the service manager (which does not need to be the init), and something like
int service_provide(const char *svclist, const double timeout);
could be a thread-safe but not async-signal safe interface to wait for a specific set of services to become available, and
int service_query(const char *svc);
a thread-safe but not async-signal safe blocking (but fast) interface to query the state of some specific service.
The underlying mechanism is similar to how the C library implements PAM and resolver support for even static binaries. Essentially, even static binaries support overriding the above at runtime, using one of the libraries (depending on the init and service manager used) that all provide the same API. The binaries themselves are compiled with do-nothing stubs of the above. How the library communicates with its init and/or service manager is up to the library; only the API is important here, because the same API must work across all sort of service daemons. A particularly large difference is between multiprocess and multithreaded single-process daemons.
The idea is that instead of the service manager trying to decide when to start each service, the service daemons can manage the dependencies themselves, and report all state changes (knowing that the library calls are expected to be extremely lightweight, robust, and available in different contexts, including signal handlers). The API matters most to service developers, so init system and service manager developers would have to just deal with the interface, even if they "know" some specific interface most assuredly suffices for everybody. You know, like 640k of RAM.
To even suggest a proper API, I would have to do a lot of preliminary work, and examine say the hundred most used base service daemons, to suss out the different needs. The above are just the simplest possible examples I can think of, that should give one an idea how simple the interface could be, and how easy the changes to existing daemons.
Note how the other direction, the way a service manager tells a service daemon to change state, is a completely separate facility. It will annoy the framework-oriented people to even think of keeping the above service state reporting separate from service state controls, but exactly this kind of modularity (per Unix philosophy and the KISS principle) has been proven since the origins of Unix to just work better. Fewer single point failures, for one.
All this kind of development or experimentation is essentially killed from entering Debian (including Ubuntu) and RedHat derivatives, because the init system maintainers absolutely reject any patches to allow interoperability with non-systemd core components. It is not a technical discussion, but a social one: you'd need community managers and human-oriented public relations tech people (the kind that write articles and blogs and talk to the devs regularly over social media and/or email) to change that, before there could be any development along this track. Even just getting the state-tracking hooks into the code is near impossible, because of lack of interest in supporting anything except systemd.
With Devuan, this kind of experimentation is possible, but only if you patch and recompile all the affected services yourself, and even if accepted as Devuan, the full changeset is likely outside the maintainer resources of the Devuan community. For the above reason, many upstream service developers and maintainers will not be interested in accepting any such patches, because any code change is a maintenance burden, and there must be a net positive for the maintainers to accept a patch; all that work would be limited to Devuan only. I'm not sure it is worth that much effort.
Perhaps the saddest fact is that when Debian adopted systemd, basically all modular init and service management work outside systemd was killed. Not by design, but by fiat: it just happened that way. Yes, there are still projects like OpenRC, and even Runit hasn't bit-rotted too badly yet, but there is absolutely no interest in companies to support such development, and this kind of widely-affecting changes requires support and money; that's why upstart development was dropped like a hot potato when Debian (and therefore Ubuntu and derivatives) switched to systemd.
Fact is, systemd does not give anything that I didn't have already in 2005 or so. I only lost modularity, options, and choice. None of what I wrote in this is new, and was known and discussed before the turn of the century. Yet, we're still stuck at the same state, except with a single-point failure-prone monolithic subsuming glob, instead of the modularity we used to have. To me, that is a net loss.
In another thread I've mentioned that there hasn't been any serious software engineering developments in the last two decades or so, either. Yes, GCC and Clang for example are much better at optimizing code; we have much better algorithms for e.g. video compression; we even have a couple of new programming languages, and definitely a lot of new libraries; but nothing big, only small incremental developments. Which means I'm not surprised at all that systems development has stagnated. I've looked at the sources of quite a few Linux appliances, and to me, it seems like the quality is definitely not going up there either.
-
I agree. The old init scripts are no good for a modern day system where services can start / stop at any time and have strong dependancies (for example: don't start an application before Wayland is up & running as it needs Wayland for output).
That only applies to SysV init, and I didn't use it for service management after 2001 or so; I used daemontools and runit.
Both daemontools and runit track the state of the daemon (primary process, in particular).
The system level interface for dependency tracking should be implemented as a library interface; for example,
int service_report(const char *svc, const int state);
could be a thread-safe, async-signal safe interface to report the service daemon facilities and state to the service manager (which does not need to be the init), and something like
int service_provide(const char *svclist, const double timeout);
could be a thread-safe but not async-signal safe interface to wait for a specific set of services to become available, and
int service_query(const char *svc);
a thread-safe but not async-signal safe blocking (but fast) interface to query the state of some specific service.
The underlying mechanism is similar to how the C library implements PAM and resolver support for even static binaries. Essentially, even static binaries support overriding the above at runtime, using one of the libraries (depending on the init and service manager used) that all provide the same API. The binaries themselves are compiled with do-nothing stubs of the above. How the library communicates with its init and/or service manager is up to the library; only the API is important here, because the same API must work across all sort of service daemons. A particularly large difference is between multiprocess and multithreaded single-process daemons.
Where this goes wrong is the fact that not every program you want to run from an 'init' like facility is a daemon. It might even be a shell script. Systemd supports this use case. In my particular case I start a regular program from a shell script on a bare bones Linux system (which doesn't even have a Window manager) using systemd to manage the dependancies.
-
Where this goes wrong is the fact that not every program you want to run from an 'init' like facility is a daemon. It might even be a shell script. Systemd supports this use case.
So does pretty much every *nix and init variant since time began.
-
Where this goes wrong is the fact that not every program you want to run from an 'init' like facility is a daemon. It might even be a shell script. Systemd supports this use case.
So does pretty much every *nix and init variant since time began.
Yep
And judging by some comments i think some folks have no clue how SysV can do anything systemd can... plus safer and 1000x lighter faster
Systemd is a tragic business made to remove users and sys admins from real boot control
Master piece of it putting a resolver and home user daemon in init.. wtf
Paul
-
Where this goes wrong is the fact that not every program you want to run from an 'init' like facility is a daemon. It might even be a shell script. Systemd supports this use case.
So does pretty much every *nix and init variant since time began.
Yes and no. What Nominal Animal is aiming at is that automatically started daemons comply to a specific C style software API (like Windows services have to do) which is a much less flexible solution.
In my particular case systemd doesn't start the application program until Wayland is up & running. With the systemV init scripts from the old days, this would be a lot harder to accomplish because you'd need to take care of the dependancies yourself.
-
Where this goes wrong is the fact that not every program you want to run from an 'init' like facility is a daemon. It might even be a shell script. Systemd supports this use case.
So does pretty much every *nix and init variant since time began.
Yes and no. What Nominal Animal is aiming at is that automatically started daemons comply to a specific C style software API (like Windows services have to do) which is a much less flexible solution.
Fuck no!
I said that is what suffices to provide both dependency-based inits, and service tracking, for C-based service daemons. I picked C as the example, because most service daemons are written in C. The C API is the only "fixed" part of competing/alternate implementations, and is dictated by the service daemons, NOT service managers or init systems. Don't you see how this is exactly opposite to what Windows and systemd does?
With such an API for C-based daemons, the same additions to the code base would cater to ALL init systems. No dependency on any specific one, not systemd, nor "mine"; even the API would be dictated based on the needs of those daemons, and not init systems. You would not even need to recompile anything to switch inits or service managers. The maintenance burden on everybody is minimal, almost zero, after the API stabilizes. I know me fail English, but how hard is this to understand?
Optimally, this API would be incorporated into POSIX, similar to say syslog() (https://man7.org/linux/man-pages/man3/syslog.3.html) interface. Instead of logging errors and warnings, this API would just report service status changes, and query other service statuses. It would solve the whole fucking init mess in one stroke, and allow robust dependency-based automatics.
At the desktop, the same interface could be used for user-specific services (desktop services et cetera), using a per-user service/application manager.
This kind of standardization track is not unprecedented, either. Cairo, for example, got adopted into the C++ standard, and its development history is rather similar, except that it never encountered the kind of opposition that systemd developers pose for init system and service manager development.
Obviously, a C API alone would not suffice. However, every single ELF binary you run in a standard Linux distribution, already has a dependency on the standard C library (that includes binaries compiled from C++, Rust, Go, and others). The C API would only be the common denominator. I'd expect bindings to all programming languages, as well as shell utilities (perhaps even Bash built-ins for efficiency?). This stuff was extensively discussed before and around the turn of the century, but since then, all development has stalled due to everyone shifting to systemd, which itself has not provided anything new that did not already exist in use in 2005 or so. Nothing in this is my "invention", although any mistakes are mine since it has been a couple of decades since I was heavily invested in this kind of development.
(For example, daemontools and runit both use a pipe or socket in a high-numbered descriptor to track if the service daemon process –– be it single-process or multi-process –– completely dies. There is absolutely zero action or code or code changes on the part of the tracked process; they are completely unaware of the existence of the descriptor. When the last process that has that descriptor open exits, the service manager immediately sees an end-of-input on the other end of the pipe or socket, so the service crash is immediately detected. No polling of /proc etc. needed. This all is well known stuff among us non-systemd init developers and tinkerers. At the time, the main question was whether daemons do, or should, close all "unknown" descriptors when they start. Hah, times were so much simpler then.)
The core idea is that instead of init determining dependencies, the core services would all be started in parallel, and they themselves handle the dependencies. The code needed to do that should be simple, as shown by the API example above, if designed to cater to the needs of the daemons, as opposed to init system developers.
In my particular case systemd doesn't start the application program until Wayland is up & running. With the systemV init scripts from the old days, this would be a lot harder to accomplish because you'd need to take care of the dependancies yourself.
Eh? With my example, all you'd need is add a single shell command to your script, blocking the execution until you have X11 or Wayland available.
If you wanted a timeout with that, then it would be a shell if ! utility... --timeout seconds ; then fail ; fi clause.
If you wanted applications to be started when a specific service or another application is started, then you use a service or application manager for that stuff. You'd configure that manager to do what you want it to. I'm only describing here an example of the very simple API that would suffice for the interprocess communication between monitored services and daemons and such application/service managers; you don't need the kind of obscure spaghetti mess that systemd+dbus is to achieve this.
Systemd is imposing a dependency on either itself or dbus to system services, and I consider that a bigger problem than attempting to standardize an API consisting of just a few functions (that compile to do-nothing stubs, that are replaced at run time like standard C resolver or Linux PAM functionality; ordinary, reliable, already well known approach) designed based on daemon developers needs. I am frankly amazed and horrified that you think such an API – that lets anyone write their own implementation to work best with their own init and/or service management – is somehow a step backward compared to systemd. Even though it would mean that service daemons currently dependent on a specific dbus implementation could drop that dependency, without losing any functionality, and possibly even gain better portability to non-Linux systems (like *BSDs).
-
What the hell incentive does the Debian team have to choose systemd for vendor lock-in or whatever it is being accused of here?? It's one of the most legitimately-open distributions out there and has virtually no commercial footprint, and stuck to SysV init for longer than most.
Sorry man. I'm not accusing Debian, but systemd. I like Debian almost as much as I like my girlfriend, for the very same reasons you mention. That's why I didn't change to another distro without systemd at the time.
However, after reading about how Poettering admitted that the borg-like approach in systemd is there by design, I can't like that. If somebody need to do this way to succeed in the competition, probably there's something bad somewhere (I think). What that bad thing could be is everybody's guess. However, I didn't switched from MacOS to Linux to get locked in again, if at all possible. Unfortunately, it looks like the borg approach succeded, or is close to success. So much for the better, fairer darwinist approach.
I bet that, should systemd not require such by-design extensive integration, Debian probably would have continued to support some alternative. Obviously, there were developers interested in that alternative, or Devuan wouldn't exist. I guess that would have implied doubling infrastructure, etc, and, being non-commercial, probably Debian does not have the resources to do that. Just my thought, and I'm sure I could probably be proven wrong. Or maybe not.
That systemd borg-like approach is a bad idea in itself, that there weren't so-urgent reasons to switch from SysV to systemd, and that we would be better by making sure there is a not so intrusive alternative, remains just my personal opinion, and opinion is like the anus: we all have our own. However, opinion is the base of politics, and that init war is all about politics. No need to argue interminably about any advantage systemd could give: some of us are worried about what it takes. I think we all agree that linux init could be better than SysV. But we don't all agree that systemd is the way to go.
Now, having Devuan at hand, I think it's worth the hassle to give it a try on some spare machine, and possibly give the pure darwinist approach some air to breath.
-
In my particular case systemd doesn't start the application program until Wayland is up & running. With the systemV init scripts from the old days, this would be a lot harder to accomplish because you'd need to take care of the dependancies yourself.
Eh? With my example, all you'd need is add a single shell command to your script, blocking the execution until you have X11 or Wayland available.
If you wanted a timeout with that, then it would be a shell if ! utility... --timeout seconds ; then fail ; fi clause.
But why should I bother if I can let systemd deal with that? And what if Wayland stops? systemd will restart both! The big picture is that systemd makes things like these easier compared to using scripts or messing with inter process APIs.
The core idea is that instead of init determining dependencies, the core services would all be started in parallel, and they themselves handle the dependencies. The code needed to do that should be simple, as shown by the API example above, if designed to cater to the needs of the daemons, as opposed to init system developers.
Wanting applications/daemons to deal with dependancies themselves is putting functionality in the most worst wrong place possible as applications have very limited knowledge of their surroundings. Doing it right would mean that every application would need dependency configuration. Think about this a bit longer because you are on the wrong track here; your approach will create a huge convoluted mess. In the end won't be simple at all because so many different cases need to be catered for. The devil is in the details. If a truly simple approach is possible then someone would have made it already and systemd wouldn't be used.
Handling dependencies in a single place is a much better approach because it has the necessary oversight and gives users flexibility to configure dependencies (if necessary) in a uniform way. They only need to know how to deal with the configuration of the application that handles the dependencies / startup order.
-
At the same time you can run into problems with systemd based services if you need a special setup/init for a daemon. Easy to implement with an init.d script, while the systemd service file is too limited. There are pros and cons for systemd, It ain't only sunshine.
-
At the same time you can run into problems with systemd based services if you need a special setup/init for a daemon. Easy to implement with an init.d script, while the systemd service file is too limited. There are pros and cons for systemd, It ain't only sunshine.
Nothing stops you from running such a daemon/application from a shell script which does some setup. Been there, done that.
-
But why should I bother if I can let systemd deal with that?
You shouldn't. Nothing I've suggested would change anything user-visible in systemd. Even if my wildest dreams were accepted, systemd would still provide all the functionality it now does, and might even be a bit more stable and robust, too. Systemd development would continue just as it has thus far, with the exception that they'd have to support a small C API at the lowest level, instead of subsuming it into an internal project, or doing an embrace-extend-extinguish (https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish) trick on it. Very little effort involved in total, for major gains across the entire Linux and POSIX system scape.
If you're happy with systemd, go ahead and be productive! The same goes with any other tool or operating system –– yes, even Windows and Macs.
What I do not understand, is why you are so adamant that systemd caters all possible needs, when people like I are complaining it doesn't and therefore desire alternatives.
I would never suggest alternatives that make systemd impossible, exactly because it is useful to many users.
However, people like you are a big part of the reason why systemd developers can block any suggestions or patches –– not just to systemd, but socially among developer communities when talking about individual service daemons ––: you insist systemd can do everything a reasonable person can expect, and therefore any suggestions for allowing alternatives is by definition unreasonable. Using you as the example of "users voice" gives them a powerful emotional weapon to avoid discussing technical matters: "there is no need to do any of that, because users say thus; see e.g. here". We never even get to the technical merits of the issues!
Fuck that, and fuck your opinion: it is based only on your own experience, and you're trying to claim any other experience must be wrong because yours differs.
I'm pretty sure that you and ve7xen are perfectly good people –– there will never be any animosity from my part towards you, or anyone else here (or elsewhere); only towards some of your opinions, because the effects of spreading those opinions that I see are misinformed and not supported by verifiable facts, are making users less powerful than they were, and subject to increased risk and worse tools. From my viewpoint, those opinions hinder development, and cause serious stagnation. The results of such innocuous-seeming opinions are horrible.
Your attitudes are extremely common, very human, really; but the fact that you cannot even notice yourself doing it, is a huge part of the problem. Yes, it is a pet peeve of mine.
-
But why should I bother if I can let systemd deal with that?
Fuck that, and fuck your opinion: it is based only on your own experience, and you're trying to claim any other experience must be wrong because yours differs.
I'm pretty sure that you and ve7xen are perfectly good people –– there will never be any animosity from my part towards you, or anyone else here (or elsewhere); only towards some of your opinions, because the effects of spreading those opinions that I see are misinformed and not supported by verifiable facts, are making users less powerful than they were, and subject to increased risk and worse tools. From my viewpoint, those opinions hinder development, and cause serious stagnation. The results of such innocuous-seeming opinions are horrible.
Your attitudes are extremely common, very human, really; but the fact that you cannot even notice yourself doing it, is a huge part of the problem. Yes, it is a pet peeve of mine.
Well, the pattern I'm spotting at your side (with the thread you started about alternative string functions in mind) is that you focus very much on technical details but completely lose sight of the big picture. I'm quite sure I have been around working on software for much longer than you have. For example: in the past few decades I have seen your improved string handling functions (made by other software engineers) pass by several times already. Your idea is not new and you probably won't be the last. And yet the majority of the C programmers continue to use the standard C library string functions.
Bottom line: One of the things I have learned is to very carefully look at why people are using certain software libraries / routines and why they discard others. The reasons are not always technical or even quantifiable. There are more variables to the equation than you are aware off and that makes you arrive at the wrong conclusion. My advise: a good experience for you would be to become part of a group of software engineers (preferably ones that are not like minded) and work on a project together. Sure this will create a lot of debate but it will also teach every one in the group to think beyond their own horizon.
-
Well, the pattern I'm spotting at your side (with the thread you started about alternative string functions in mind) is that you focus very much on technical details but completely lose sight of the big picture.
No, I'm completely aware of the human side (what you call "the big picture"); I just choose to ignore it (other than acknowledging it exists, and describing the technical hindrances it causes), for personal reasons.
I did not participate in SiliconWizard's Design a better "C" (https://www.eevblog.com/forum/programming/design-a-better-c/) discussion exactly because such an undertaking is really more social than technical: programming languages need to be designed for humans.
I do like designing and creating tools, but I do that by observing the task at hand first, the ways the humans go about it, and then implement a tool that I believe lets them perform the task and achieve desired results with less resources and time spent. I do not discuss what the tool should be like with them; I only discuss how they believe the task is best performed, what the bottlenecks and issues are, and so on. I rely on others to do that squishy human negotiation stuff; the irrationality of it burns me out. The stuff I do in user testing is observing and measuring what is happening, and recording why the user thinks that is happening. I use those, and not the opinions and beliefs of the user (or indeed myself as an user –– one sample is way too small a set to base anything on) to base my designs on.
Perhaps the best demonstration of my stance is the fact that I am completely uninterested in the popularity of Linux, or any specific Linux distribution.
My advise: a good experience for you would be to become part of a group of software engineers (preferably ones that are not like minded) and work on a project together.
I've mentioned before (here and elsewhere) that I've done my best work in a team with very different members, each one with their own domain of expertise. Don't make the mistake of believing that I am (or anyone else here is) only what you can infer from my output here. I do not have as much experience as some of the older guys here, but I have worked on every rung of the ladder from code monkey to CEO since 1991, in different environments (commercial, military, scientific, and visual arts), in different sized teams, and in half a dozen to a dozen different programming languages. I used to do cross-platform development and support, but switched to Linux-only in 2005 or so, after switching career from business to research.
There are very valid technical reasons to avoid systemd. You've ignored all of them: "because it works for me, you are wrong, and it is useless to even discuss this" and "changing any of this involves so many people, that you should first concentrate on the human non-technical stuff, and work with other developers".
I'm not interested in discussing the social reasons (except to describe actual real-world observations), nor working in the various communities to change the social stance on systemd.
As to e.g. the Constructing short C strings in limited or constrained situations (https://www.eevblog.com/forum/programming/constructing-short-c-strings-in-limited-or-constrained-situations/), I hopefully sufficiently expressed that these are not "new" nor "my inventions"; what was mine was the division into two categories, and the attempt to describe these in a way that would help others who needed such tools, especially those now/recently entering into the embedded programming field. Everything else is known, and has been rediscovered over and over again. I specifically invited others to comment, if they had discovered something different/better.
Even in the Mind over bugs: C pointer edition (https://www.eevblog.com/forum/programming/mind-over-bugs-c-pointer-edition/), you hopefully saw that my only goal was to help those who find using C pointers difficult/bug-ridden/problematic/more effort than they're worth, to better understand them, and that way, better utilize them as a tool. The only thing in it I consider truly "mine" is the way I attempted to describe and explain stuff; all the facts and model are well known (although not agreed to by everyone).
In no case am I trying to sway anyone to align their opinion with mine, only that they acknowledge the facts instead of ignore them because they appreciate their own opinions over observable facts. I like that others disagree, and although I am not interested in their opinions, I'm very interested in the reasons and experience that opinion is based on. Similarly, I want to show the reasons and experience behind my own opinions, not my opinions per se. I do get quite angry when someone declares their opinion as fact, or acts as if they were already accepted as facts, without going into the basis.
-
It appears to me that nctnico is very experienced above-average but not genius-level engineer who has seen a lot of technical failures from others and also seen his own limitations. As a result, his default suggestion, in every possible instance, is to rely on something he personally have good experience on, and wary of anything he has seen someone (including himself, and others in teams he has worked with) struggle with.
Even just the possibility that someone could well manage to do something he has seen someone else struggle with doesn't even seem to cross his mind, as evidenced by all those times things like utilizing multi-MCU solutions being sometimes the right tool for the job are discussed. No, because nctnico has seen some problems, and he knows he is right about those problems (which is usually 100% true) means it can never work in any case.
He is also ignoring the fact that someone can be more capable or productive than him, or have different kind of skill set, this bias is likely because he is clearly above average himself and has seen a lot of average work, working in teams.
As a result, I'm sure nctnico is an exceptionally good consultant for businesses involved in technology because he can immediately say which technical decisions carry higher-than-average business risk, and suggest more failsafe / idiot proof alternatives. I'd definitely hire him if he said he can do the job and I wanted to have it delivered on time.
Following this same logic, I think nctnico completely missed your point about standardized interfaces giving options to do things differently, because nctnico thinks about the least-risky way of forcing one single solution. And indeed, if company X wanted to start using linux on their desktops for development work, and no one there would have any experience on linux, then the right solution would be to just download some recent distro, which runs systemd, and get it running and start doing work on it. Suggesting Devuan "because it doesn't use systemd" would be a more risky movement, likely, in that "big picture". It's obvious to me that's not what you mr. Nominal suggested but this kind of simplification is the result of nctnico being "practical".
-
I was trying explicitly to avoid giving that kind of impression, by mentioning that even the machine I currently use does have systemd.
It is only a tool for me, and I like the idea of people having lots of tools to pick from based on their particular needs.
I myself have observed that the quality of this tool is in certain ways degrading, I'm losing options I used to have, and only gaining new (security) risks.
Although some parts of this tool – Linux as a desktop environment – are becoming better, some are degrading too fast to make up the difference.
I am, fundamentally, a tool developer, and problem solver. I see problem, I look at, observe and analyze, and talk about problem. I don't make it my business, because in the business world, giving a solution is not as good business as providing a service to work with the problem.
In my opinion, just as important as Devuan is to Linux distributions, FreeBSD and OpenBSD are to open source operating systems in general; and Linux is to desktop operating systems. Just because most desktop users are satisfied with Windows, does not mean it should be only one, or that it is even the best tool for the job.
I see people also often complain about Linux having many different distributions, and that they only want there to be one so that development costs are minimized.
I do not understand that either, because I've never had any trouble packaging anything, even proprietary software, to run on most if not all Linux distributions. Even dynamic library dependencies are easily fixed using a wrapper shell script (to prep the execution environment, including library paths), and is what e.g. Firefox and Chromium do. I can only imagine that it stems from a culture of targeting a specific version of Windows, without any idea how to create real-world portable code. (And that does not mean following the standards religiously; it is a much more practical approach, which acknowledges that nothing is perfect, only something that can be worked with.)
The demands that Linux developers need to do X "for Linux to become more popular on the desktop" are utterly silly to me, because it is a tool I use and develop for myself, my colleagues, and my users; and its popularity among others is absolutely irrelevant to me. It only matters in the psychological sense, and if I wanted to do something about that sort of stuff, I'd become a therapist instead.
It does annoy me to no end to have opposition against developing this tool further, to make it provably better. It feels, I dunno, medieval? Like suddenly encountering the inquisition, because I uncovered an uncomfortable set of facts. The first thing is always being labeled as "unreasonable" or "conspiracy theorist". Here, "you need to work with others, to learn how to be reasonable".
-
I wrote "reboot", then explained that *it used to suffice* to restart ones desktop session, for example logging in and logging out, but no longer does (as it leads to instability).
Perhaps you should read some tutorials to understand the difference between rebooting a machine and restarting a desktop session.
I do not believe that that anyone can say or show you anything that will affect your opinions, which you state as facts without any basis, so discussing any of this with you is objectively worthless.
Perhaps you should actually read my post, where I explain to you in baby steps why systemd has nothing to do with updates 'requiring' reboots. If you aren't even going to bother reading my posts, then discussing with you is, indeed, worthless.
But perhaps my pointing the untruths that you are claiming is worthwhile to other readers, because you have made many dubious and several completely untrue statements here. That is really my only desire to be involved here, to correct the falsehoods you are claiming.
If you wanted a timeout with that, then it would be a shell if ! utility... --timeout seconds ; then fail ; fi clause.
While this approach is viable, the elimination of boilerplate like this is a big advantage to modern systems like systemd. As dependencies get more complicated, you end up with spaghetti shell code a la SysV init. Putting this code in one place and describing it in meta-fashion is much more sensible.
Your model leads to much more coupling to a particular approach than systemd does; you're talking about modifications to POSIX and changes to every service in existence (at least every one that has dependencies), ffs. You also need some system-agnostic standard way to actually describe those dependencies (since dependency control now moves to the application instead of the system), which is yet another thing that would be difficult about this approach and require at the least an ad-hoc standard if not some body managing this. Not to mention that you are creating a whole new area of portability problems for application developers.
Your attitudes are extremely common, very human, really; but the fact that you cannot even notice yourself doing it, is a huge part of the problem. Yes, it is a pet peeve of mine.
:palm:
In no case am I trying to sway anyone to align their opinion with mine, only that they acknowledge the facts instead of ignore them because they appreciate their own opinions over observable facts. I like that others disagree, and although I am not interested in their opinions, I'm very interested in the reasons and experience that opinion is based on. Similarly, I want to show the reasons and experience behind my own opinions, not my opinions per se. I do get quite angry when someone declares their opinion as fact, or acts as if they were already accepted as facts, without going into the basis.
:palm: :palm:
I will continue to correct the factual inaccuracies that you present, but I'm not interested in discussing further with you, this attitude from someone spouting so much that is either wilfully misunderstanding the situation or outright untrue is too :palm: for me. Never mind your abject dismissal of alternative models to solve this problem that have different tradeoffs, you don't even seem to understand the difference between systemd and dbus. You are not qualified to speak on this, yet you are convinced you know better than the vast majority of actual system administrators and distribution developers, and that you're so much smarter than everyone else that is blocking your brilliant ideas.
-
That is really my only desire to be involved here, to correct the falsehoods you are claiming.
Then prove your counterclaims, and stop making this personal. Declaring something a 'falsehood' has zero value, if you provide zero verifiable facts, only your own opinions.
To make my own basis for my opinons clear, not just for you but any other member who has slogged through this thread thus far:
D-Bus is a message bus designed for communication between desktop processes. The protocol spec (https://dbus.freedesktop.org/doc/dbus-specification.html) is frozen since 2006. There was an abortive attempt to push dbus implementation into the Linux kernel in 2015, but it failed, because the bus is more properly implemented in userspace, as discussed in the kdbus: to merge or not to merge (https://lkml.org/lkml/2015/6/23/22) thread. (That thread also shows the kind of social pressure set upon the kernel developers by the systemd developers to include kdbus, for non-technical reasons. I claim that that kind of pressure is the main reason for friction between systemd developers and 'competing' projects, and causes technically inferior solutions to be accepted simply to avoid the social repercussions a rejection would cause.)
D-Bus originally had nothing to do with systemd. The current reference implementation at dbus.freedesktop.org (https://dbus.freedesktop.org/) has a lot of systemd-specific behaviours, as can be seen e.g. from the NEWS (https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/NEWS). Its gitlab membership list (https://gitlab.freedesktop.org/dbus/dbus/-/project_members?sort=access_level_desc) shows that among the two owners and six maintainers are Lennart Poettering (systemd lead) and Colin Walters (systemd contributor). By "subsumption", I refer to how systemd has a special status in the project, and how Lennart Poettering was granted maintainer status in the dbus source repository.
dbus (https://packages.debian.org/source/sid/dbus) is the software package based on this in Debian and RHEL derivatives, and has a direct dependency on systemd (specifically, a build dependency on libsystemd-dev), and cannot be built or used in Debian or RHEL without systemd.
Devuan uses a fork of the freedesktop Git repo, so that any changes can be backported while removing any added systemd dependencies. The reason for the Devuan fork from Debian is clearly stated in the announcement (https://www.devuan.org/os/announce/), and is centered on two things: the behaviour of the systemd developers, and the design and central/monolithic role of systemd in a Linux system. The first one is subjective; but the latter is contrary to the Unix philosophy (https://en.wikipedia.org/wiki/Unix_philosophy) and modular design (https://en.wikipedia.org/wiki/Modular_design), both found reliable and useful for several decades now. Even more importantly, the more I view systemd sources or get notified of its issues (https://github.com/systemd/systemd/issues), the more I am convinced that its developers do not have the necessary skill to even implement their own design without critical security issues and creating new single-point failure modes.
More about this further below.
Your model leads to
It is just one of the examples discussed a couple of decades ago how the bootup problem (completely sequential in SysV init) could be fixed.
The other approach to dependency-based inits was describing the conditions a process has before it is launched, but that approach does not include any way for the process to report service availability, and it makes a faulty assumption that just because a service daemon was started, its service should be available.
For booting, the description method kinda-sorta works –– a delay is assumed between starting a process and the service it provides being available ––, but for a true dependency-based service manager, it doesn't work at all. Systemd relies on such descriptions, with the end result that just like Windows, from a cold boot, it takes a while before the system is truly usable. Since users can however log in faster, they perceive the systems to boot faster. A true dependency-based init and service manager would yield even faster startup, yet know exactly which services are active, and not guess based on which binaries are running already. (Subsecond boot times are achievable with embedded hardware, and have been for well over a decade now.)
However, true dependency-based service management does require source-level changes.
The reason I showed the API needed for true dependency-based init and service management, was to show how minimal the source-level changes are.
The changes made to various core services due to systemd are much more extensive, and make those services dependent on systemd: to use that same source in a system without systemd, you need to do changes. At best, those are just build configuration, but often require patching. udev, the device manager used in Linux is an excellent example of this. It was initially designed by Greg KH and Kay Sievers as part of the kernel, but was later subsumed/incorporated into systemd. udev is an excellent design, but because of its subsumption to systemd, users who don't want to use systemd have to use something else; typically eudev (https://github.com/eudev-project/eudev) (which is to udev what Devuan is to Debian: tries to keep up with the good stuff, but drop the systemd dependency).
So, in the case of dbus and udev –– in my opinion, very important core services! ––, the choice is currently whether you use them with systemd, or with anything else except systemd (like OpenRC, runit, SysV, or something else).
The API approach I described does not make that distinction at all. The reason for incorporating it into POSIX would be the same why the GNU getline()/getdelim() got incorporated into POSIX: because it is something that is needed and useful in systems programming.
In the cases where you'd run a daemon that relies on that API on a system without dependency support, the API calls would do-nothing, and the service would still work as it would under SysV init or systemd.
However, only the core services that other services depend on need to report their running, status to enable the true dependency-based init and service management. But like I said, that API is just a rough sketch of what I remember talked about, and not something I'd even propose as-is.
To have something I would be willing to propose, I would first have to go through all core services not just in Linux, but on the *BSDs as well, to form a good picture of what exactly do the services need, how they are structured (so that the API could cater to all), and talk to some security-hats about the possible exploitation scenarios.
The only true kernel-imposed task an init –– technically, the process running as PID 1, responsible for starting the rest of the userspace –– is to never exit, and to reap any zombie processes. Failure to reap zombie processes will lead to resource starvation, but having the init exit or die will halt the system with a kernel panic.
Having more and more features in that process makes it fragile, and the vast number of reported issues (https://github.com/systemd/systemd/issues) indicates it is not getting any better. In other words, I see no way to "fix" systemd, but by replacing it with something else that does not require core services to be exclusively connected to it, and instead uses the Unix philosophy and modular design to let the users choose. The competition alone between software projects will drive "evolution".
The history of free/open source computing is replete with examples.
Never mind your abject dismissal of alternative models to solve this problem that have different tradeoffs, you don't even seem to understand the difference between systemd and dbus.
The 'abject dismissal' is 'that has been tried, and does not work well/reliably enough'. Your counterclaim is "but it does for me, so you're wrong", and makes no sense.
The difference you seem to insist on, to me, looks semantical. What matters, is the practical relationship.
D-Bus –– the protocol –– is not inherently systemd, and since it has been "locked" years ago, is not in danger of being subsumed by any project, unless someone does an Embrace-Extend-Extinguish on it. The lack of documentation on how exactly systemd uses dbus makes me a bit suspicious that it might happen, but I don't think it is likely. However, as I've shown above, dbus the project, the reference implementation, definitely has a special relationship with systemd.
Have you considered whether you understand their relationship? Or have you just assumed that because they use separate git trees, and don't share too many maintainers and members, is proof enough that my characterization must be incorrect?
you are convinced you know better than the vast majority of actual system administrators and distribution developers
No, that is just a side effect of my peculiar deficiencies in writing English. I only do technical English, and nowadays neither speak nor listen to it socially, so any such subtext anyone assigns to my output is incorrect: there should be none (except for self-deprecating dad jokes when emoticons are used), and the text interpreted with as little emotional content as possible. Any observable subtext otherwise is an error on my part, but I assure you, it is NOT INTENTIONAL. If you care to, you can find posts on this forum where I discuss exactly this problem a year or two ago.
The only fraction of system administrators and distribution developers that 'I think I know better', is the fraction that says "but it works for me, so you're wrong". And the reason there is that they don't seem to know anything to back their opinions, just personal beliefs.
I do think I know a lot, because I've done a lot (again, if you use Linux, you almost certainly run something I've contributed to), but I do not think I know better. As I've explained, to compare opinions, I use the basis behind those opinions, not the opinions themselves; and do not place much weight on my own opinions either. Only the observables really matter, as opinions cannot be rationally argued about otherwise.
You have provided nothing but your own opinion, no reason to consider your opinions valid or even relevant.
I've described to you that I've observed that when installing updates to systemd or dbus, the update manager requests a system reboot, and if one declines, sometimes the desktop session (gnome or cinnamon on the machines I've looked at) crashes: first you see glitches, then it becomes unresponsive, and either just spins or crashes. Because of the dependencies of these system components, logging out and logging back in is not sufficient to avoid the effect; a reboot is needed.
To me, this indicates a clear relationship between the three components: the desktop environment (various services running as the user, connected using dbus), dbus itself, and systemd. In my experience, this is a serious step backwards in the system reliability, and something I would like to correct or avoid.
On Debian derivatives, kpatch (https://github.com/dynup/kpatch) can still be used to patch kernels, but why bother if you have to reboot your desktop/laptop every week or so anyway.
As to how the init system saga on Debian actually occurred, I recommend looking at the Debian-ctte (Debian Technical Committee) mailing list from Oct 2014 onwards (https://lists.debian.org/debian-ctte/2014/10/); starting at the bug #765803 report (https://lists.debian.org/debian-ctte/2014/10/msg00001.html), and on following months sampling the posts with 'systemd' or 'init' in the title. These are the actual discussions among Debian maintainers at the time, and the proper source to use for facts. You can also use the search facility on the list page (https://lists.debian.org/debian-ctte/) to look up how often systemd dependency or developer issues are raised at the Technical Committee compared to other projects.
-
Then prove your counterclaims, and stop making this personal. Declaring something a 'falsehood' has zero value, if you provide zero verifiable facts, only your own opinions.
I refuted most of them in my second-last post, and you responded to only one of them. I am not making this personal, I am presenting the facts as I am aware of them, and expect you to either counter my refutations, or by not responding, admit that you are have no response and were wrong.
I claim that that kind of pressure is the main reason for friction between systemd developers and 'competing' projects, and causes technically inferior solutions to be accepted simply to avoid the social repercussions a rejection would cause.)
Okay, I have said, I don't care about the politics, and don't care to learn the history. However engineers tend to be strongheaded people. There are more than a few democratic technical selection committees that have chosen this path, and I think your assertion that the same inferior solution has become accepted among so many separate communities of such people is dubious at best. The corollary of course is that these people must be either incompetent or malicious, and you have repeatedly alluded to that being your point here.
By "subsumption", I refer to how systemd has a special status in the project, and how Lennart Poettering was granted maintainer status in the dbus source repository.
dbus (https://packages.debian.org/source/sid/dbus) is the software package based on this in Debian and RHEL derivatives, and has a direct dependency on systemd (specifically, a build dependency on libsystemd-dev), and cannot be built or used in Debian or RHEL without systemd.
It is rather common for maintainers of ports to be granted maintainer status. The systemd functionality is there for effective use on systemd systems. There is also Windows-specific code in dbus, so that it can be built and used effectively there. Do you object to that? How about the optional X11 code? dbus does not require systemd as a build dependency, though it can integrate with it on systems where it is present, such as Debian and RHEL, and when built as such, it will obviously be a runtime dependency. You can easily see in the Gentoo ebuild for example that it can be built without systemd and works just fine that way.
This should be pretty obvious because lots of *nix-y stuff, especially for the desktop, uses dbus, yet works just fine on *BSD or even Windows where systemd is obviously absent. Your claim that systemd has 'subsumed' dbus is just categorically incorrect; at best the two are loosely coupled.
Devuan uses a fork of the freedesktop Git repo, so that any changes can be backported while removing any added systemd dependencies. The reason for the Devuan fork from Debian is clearly stated in the announcement (https://www.devuan.org/os/announce/), and is centered on two things: the behaviour of the systemd developers, and the design and central/monolithic role of systemd in a Linux system. The first one is subjective; but the latter is contrary to the Unix philosophy (https://en.wikipedia.org/wiki/Unix_philosophy) and modular design (https://en.wikipedia.org/wiki/Modular_design), both found reliable and useful for several decades now. Even more importantly, the more I view systemd sources or get notified of its issues (https://github.com/systemd/systemd/issues), the more I am convinced that its developers do not have the necessary skill to even implement their own design without critical security issues and creating new single-point failure modes.
Great, the more ports the merrier. If it has technical merit, it will succeed and displace Debian and other distributions that have been taken over by these malicious and incompetent actors. I'm all for that, this is what open source is all about. But don't promote it with false claims and drama.
However, true dependency-based service management does require source-level changes.
The reason I showed the API needed for true dependency-based init and service management, was to show how minimal the source-level changes are.
A way to advertise more granular service availability would be nice, but I don't think it displaces the need for a meta-description of the dependencies (in other words, decoupling the application and the system setup). I would like to see the advertisements side of this, but consumed by systemd or similar as part of the dependency graph. It would be pretty straightforward to implement on top of dbus, and I'm kind of surprised it doesn't exist. Nothing stopping someone from working on this, of course.
As I described, if you want the dependencies described within the application, that means that we need some kind of central authority to enumerate how particular 'abstract' dependencies are to be described in this system (e.g. how does 'the X11 server is ready' get described in a system-agnostic way, allowing for different implementations of X11, different locations of its unix or network sockets etc). This creates a lot of management overhead and friction, and seems needlessly...bureaucratic and centralized. I think it is a lot less flexible if all your dependency nodes ultimately trace back to some central management authority.
Or you do it in an ad-hoc way that would be very fragile, tightly coupled between applications, and not very portable. As nctnico outlined, this depdendency resolution really needs to be managed by the packagers / system administrators, it's not practical to push it into the hands of the application developers that should not need to know much or care about the configuration of the system they are running on and creates a bunch of new problems and makes this opaque and rigid to the user.
There are a lot of other technical tradeoffs here too. You end up with a ton of long-lived processes that sit with their code in RAM indefinitely. It makes dependency loops and race conditions impossible to catch without a supervisor that is aware of the entire dependency state of the system - and then we are back where we...well...are. It puts the dependencies and services opaquely behind the binary, and not in an easily administrator-viewable fashion. Current state is difficult to interrogate without a supervisor. It leads to a lot of boilerplate code in applications. It doesn't help at all with managing things like network/mount namespaces, capabilities, permissions and the like. It's certainly a viable approach as part of a larger system, but to claim that it is *the* approach is arrogant as all get out. There are good reasons that this has not been widely adopted as the primary way of solving these problems, despite it being an old idea.
The changes made to various core services due to systemd are much more extensive, and make those services dependent on systemd: to use that same source in a system without systemd, you need to do changes. At best, those are just build configuration, but often require patching. udev, the device manager used in Linux is an excellent example of this. It was initially designed by Greg KH and Kay Sievers as part of the kernel, but was later subsumed/incorporated into systemd. udev is an excellent design, but because of its subsumption to systemd, users who don't want to use systemd have to use something else; typically eudev (https://github.com/eudev-project/eudev) (which is to udev what Devuan is to Debian: tries to keep up with the good stuff, but drop the systemd dependency).
It's the *only* example of this, and I'm not happy about it either, but it is not really a technical problem. There's no reason for packaging it with systemd, but it can still be built and used without systemd on the system, as far as I know, and Gentoo offers this and no patches are required to do it. But yeah, this is not very cool.
So, in the case of dbus and udev –– in my opinion, very important core services! ––, the choice is currently whether you use them with systemd, or with anything else except systemd (like OpenRC, runit, SysV, or something else).
If someone wanted to maintain it, it would not be difficult to provide alternate builds of dbus and udev (and likely some others) that do not have a runtime dependency on systemd, for use on such systems. The issue here is that nobody wants to maintain an alternate init on these distributions, not that it would be difficult to implement or that systemd is blocking it. On a dynamically built system like Gentoo it is more or less trivial, and lo and behold, it's a 'supported' (as it goes on Gentoo) option there.
The API approach I described does not make that distinction at all. The reason for incorporating it into POSIX would be the same why the GNU getline()/getdelim() got incorporated into POSIX: because it is something that is needed and useful in systems programming.
In the cases where you'd run a daemon that relies on that API on a system without dependency support, the API calls would do-nothing, and the service would still work as it would under SysV init or systemd.
I think you're missing the big picture here. Yes, implementing the advertising of services this way would not be difficult or a big change, but for it to actually be useful for system management, there would be a ton of infrastructure that would need to be built up around it *and actively managed* which is not really something that POSIX does, it gets updated what every 10 years or so? I'm not opposed to adding something like this to what we have today in a holistic manner, used where it makes sense for things like 'network is up' or 'X server is running', but we already have all the pieces in place. All that is needed is a standardized dbus interface to pass these messages.
The competition alone between software projects will drive "evolution". The history of free/open source computing is replete with examples.
Agreed, we will see what happens here.
The 'abject dismissal' is 'that has been tried, and does not work well/reliably enough'. Your counterclaim is "but it does for me, so you're wrong", and makes no sense.
In your view your solution is perfect, and the solution that the vast majority of people have settled on (it is not just me that it works for, clearly) is suitable to be dismissed without due consideration. You will need a much stronger argument than 'I don't like it' or 'I don't like how it is managed' or even 'it is limited in this way' to dismiss it as you have. And part of that will include addressing the shortcomings of your own proposals and how the tradeoff favours your solution. You have not acknowledged that your solution is limited in any way.
The difference you seem to insist on, to me, looks semantical. What matters, is the practical relationship.
Precisely, and practically speaking, dbus is completely independent from systemd. It can build and work fine on any *nix, as well as Windows, whether or not systemd is present. It is a clear refutation of your claim that it has been 'subsumed' by systemd. Yes, it has systemd-specific code, as it does for Windows, or as glibc does for FreeBSD.
Have you considered whether you understand their relationship? Or have you just assumed that because they use separate git trees, and don't share too many maintainers and members, is proof enough that my characterization must be incorrect?
Your claim can be dismissed on its face, because there is ample evidence of dbus-daemon working as designed on systems without systemd. Ergo, it must not depend on systemd.
No, that is just a side effect of my peculiar deficiencies in writing English. I only do technical English, and nowadays neither speak nor listen to it socially, so any such subtext anyone assigns to my output is incorrect: there should be none (except for self-deprecating dad jokes when emoticons are used), and the text interpreted with as little emotional content as possible. Any observable subtext otherwise is an error on my part, but I assure you, it is NOT INTENTIONAL. If you care to, you can find posts on this forum where I discuss exactly this problem a year or two ago.
The only fraction of system administrators and distribution developers that 'I think I know better', is the fraction that says "but it works for me, so you're wrong". And the reason there is that they don't seem to know anything to back their opinions, just personal beliefs.
No, this is not a language deficiency. It follows directly from your assertions that systemd is not appropriate and that better solutions should be chosen, and that distributions should not have allowed systemd to become integral to their systems. By making those claims, you are calling the decisions of the vast majority of distribution maintainers and system administrators that actively chose to use or implement systemd in their systems into question. Sure, you are only directly deriding the systemd team, as far as I can tell, but you are also insisting that their approach is incorrect and that anyone supporting it is also incorrect in choosing it.
You have provided nothing but your own opinion, no reason to consider your opinions valid or even relevant.
We are starting to get to a point where you are admitting that the technical assertions you have made are mostly untrue. I have described how what much of you are saying about systemd's architecture is untrue or at least misrepresented. I have described limitations of your proposed approach, and problems it creates. Your posts however have been full of opinion, accusation, and descriptions of 'your way' but little (and many factual inaccuracies) to back up your opinion.
I've described to you that I've observed that when installing updates to systemd or dbus, the update manager requests a system reboot, and if one declines, sometimes the desktop session (gnome or cinnamon on the machines I've looked at) crashes: first you see glitches, then it becomes unresponsive, and either just spins or crashes. Because of the dependencies of these system components, logging out and logging back in is not sufficient to avoid the effect; a reboot is needed.
To me, this indicates a clear relationship between the three components: the desktop environment (various services running as the user, connected using dbus), dbus itself, and systemd. In my experience, this is a serious step backwards in the system reliability, and something I would like to correct or avoid.
On Debian derivatives, kpatch (https://github.com/dynup/kpatch) can still be used to patch kernels, but why bother if you have to reboot your desktop/laptop every week or so anyway.
And you didn't read my response, where I described why this dependency exists, and how to address it, but you ignored that. You should not have to reboot after a systemd or dbus update, but you will have to restart many processes, as you would when updating any other system-level package like libc. If the package manager is prompting a reboot, it is a limitation of the package manager (or a choice by its maintainers to err on the side of caution), and has nothing to do with systemd. In most cases this requirement is based on dbus anyway (almost all of a typical desktop userland does not depend on systemd directly), and as we have already discussed, dbus != systemd and you will run into the exact same thing on a non-systemd system.
-
I think the big issue with systemd is that it's the opposite of the UNIX philosophy and users are afraid that it will take their freedom away. And it does that already to some extend.