https://www.youtube.com/watch?v=bT90D0GKZRM
Systemd supremo Lennart Poettering leaves Red Hat for Microsoft
To considerable amusement in the Linux community, the infamous lead developer of systemd has a new job – at Microsoft. The news surfaced on a Fedora mailing list when someone found that they were unable to tag Poettering in a bug report because his Red Hat Bugzilla account was disabled, to which Poettering responded that he …
COMMENTS
-
-
-
-
Friday 8th July 2022 10:33 GMT Liam Proven
Re: one step forward
[Author here]
Linux is a UNIX.
Not UNIX-like: an actual, certified UNIX. The Open Group says so:
https://www.opengroup.org/openbrand/register/
As such, yes, it's a 1970s design: a late-1960s OS modernised and made portable.
And I think you're right. The design does need to be modernised.
And here is that modernised version, right now:
https://github.com/inferno-os/inferno-os
-
Friday 8th July 2022 13:18 GMT Jamie Jones
Re: one step forward
There is no mention of Linux on that list you posted!
Anyway, it's nothing but branding nowadays.
FreeBSD is more "UNIX" than Linux due to it's history, but that's not allowed to be called "Unix" either, though amusingly, Mac OS (which is the least "Unix" of the lot) is!
-
-
Friday 8th July 2022 20:05 GMT Michael Wojcik
Re: one step forward
But it has USS, which implements the Single UNIX Specification. And that's the technical requirement for certification.
The point of the transfer of the UNIX trademark to TOG was to clean up the mess that originated in the AT&T / BSD split. Both SVR4 and BSD4 had strengths, but they also had different semantics for some system calls and some that were exclusive to one family or the other; and they had numerous differences in the system utilities. Then there were various vendor extensions.
POSIX cleaned up some of that, and added some other needed improvements – the pthreads synchronization mechanisms are a lot better than the SysV "Columbus" ones for most use cases, for example. And the Austin Group meetings cleaned up more. The SUS has done more with each revision to make various UNIX flavors more compatible and sensible. Making the UNIX trademark a branding carrot for complying has made porting among multiple UNIX platforms (and Linux-based ones, even if there's only one Linux-kernel OS on the list) a lot easier.
I've been developing and supporting commercial software on multiple UNIXes since the late 1980s, and I'm glad the UNIX trademark is being used by TOG this way.
-
-
Friday 8th July 2022 20:04 GMT Peter Gathercole
Re: one step forward
No. EulerOS is a branded UNIXtm, not GNU/Linux in general.
It doesn't run the other way, unless Huawai made no changes to their Linux distro.
There's nothing on Huawai's home page that explains whether they did anything to get it through UNIX 03 branding, but I suspect that they had to do something. I suspect that they have a number of possibly non-open source additions that provide the parts of the verification suite that standard GNU/Linux doesn't pass.
If Linux kernel+standard toolset passed UNIX 03, then I pretty much guarantee that Red Hat, Suse et.al. would have paid for the verification tests.
As the other vendors have never have, I suspect that Huawai did some tweaking before submitting to the test. Does anybody know someone who is using EulerOS to ask for the source code?
-
-
-
-
-
-
-
Friday 8th July 2022 09:29 GMT Alan Brown
Re: Motive found.
Having interacted extensively over the years with Redhat: Yes, you're right
Under IBM: Yes, you're right
There's good reason scientific linux users are jumping ship to Debianesque distros
WRT Systemd: sysvinit definitely needed replacing with something capable of parallelising process startups, but dropping an elephant on a peanut is not the way to do it
-
-
Tuesday 12th July 2022 11:59 GMT teknopaul
Re: Race condition
Word.
Jboss (also by redhat) mimicked systemd design and created a parallel boot system that to this day in production environments ensure you never know if a reboot will work or not.
Boot speed in a laptop of phone is important but in most server environments reliability and testability are significantly more important.
Reliable shutdown is equally important and systemd still, to this day, does not provide that.
Lost alot of money from that in prod environments.
-
-
Friday 8th July 2022 15:52 GMT Anonymous Coward
Re: Motive found.
Having used systemD and SMF before it, I'm less than convinced that the much-ballyhoo'd parallel startup is really all it's cracked up to be. Or even that beneficial.
Not if the cost is such complexity and obfuscation, anyway.
My (perhaps unfair) impression is parallel startup was a thing poettering wanted so his laptop would start faster -- or at least give him the login prompt, whether it was really open for business or not.
I believe many of the so-called features of systemD were poetteringisms that he wanted so he wouldn't have to deal with someone else's system designs or config or code.
-
-
-
-
Thursday 7th July 2022 19:57 GMT blah@blag.com
Re: A Useful Link ...
NP.
Benno makes the point that Windows NT had/has a proper service management interface (I started with v3.5) and MacOS + variants has Launchd since Tiger. Systemd is an attempt to give Linux a similar level of accessible service interaction.
That's not to say it's perfect, but what software is?
I rewatched that vid recently and tied a knot in something to remind myself to have a look at Freebsd & OpenRC.
-
Thursday 7th July 2022 22:32 GMT Anonymous Coward
Re: A Useful Link ...
If it stuck to service management I could maybe accept it.
But why does an init system need to replace my NTP, DNS, Network Configuration, Logging, etc etc etc and why does an init system have to have 69(? I think that's right) different modules which are now so embedded that you can't replace the init system at all easily, which to my mind totally goes against several philosophies:
* Do one job and do it well
* in FOSS have freedom of choice - no walled gardens
Just a personal opinion.
-
Friday 8th July 2022 00:34 GMT blah@blag.com
Re: A Useful Link ...
It makes sense to me to have a system layer inbetween kernal and userland. If you watch the vid you'll see Benno talk about this and how as a FreeBSD dev he would have done the same in principle but differently. This was back in 2019 so I don't know how the conversation went within the FreeBSD community, would be interesting to find out.
-
-
-
-
-
Saturday 9th July 2022 07:43 GMT blah@blag.com
Re: A Useful Link ...
If you look at at linux.conf.au on youtube you'll find none of their vids have comments allowed. Nothing to see here ...
linux.conf.au is an awesome resource for linux & FOSS subjects.
An interesting viewpoint on init/systemd and Debian ... https://lwn.net/Articles/698822/
-
-
-
Thursday 7th July 2022 16:22 GMT nematoad
Depart, I say, and let us have done with you.
It looks like he is following in the footsteps of Miguel de Icaza.
Come in, bugger Linux about and then piss off to Microsoft.
Gnome and systemd seem to share traits. The developers seem to be doctrinaire, resistant to constructive criticism and have the attitude "If you don't like it, lump it."
Systemd may still be with us but at least there is a chance that the rot will stop with Poetterings departure.
-
-
Thursday 7th July 2022 17:27 GMT TVU
Re: Depart, I say, and let us have done with you.
"Still, if systemd is so universally despised, why is it so universally integrated into linux distros?"
Because of Red Hat's overbearing influence on Linux in general and an unfortunate, and surprising, decision by the Debian community to switch to the ill-conceived SystemD as the default init system back in 2014.
-
Thursday 7th July 2022 18:39 GMT Throatwarbler Mangrove
Re: Depart, I say, and let us have done with you.
"Still, if systemd is so universally despised, why is it so universally integrated into linux distros?"
I think this question deserves more serious answers than it's gotten. Why have the Great and the Good at various major distros decided to adopt it, despite the wailing and gnashing of teeth? I certainly don't know, as I'm not embedded in the politics of distro creation, but I would love to hear more of an answer than "They suxx0r LOL" or the standby "Poettering suxx0r LOL."
-
Thursday 7th July 2022 18:54 GMT jake
Re: Depart, I say, and let us have done with you.
Only two major distros adopted it (RedHat and Debian). RedHat did it because they were trying to be Windows. In Debian's case, it was an accident of history, in essence fall-out from a large internal power struggle.
The rest of the distros to implement it, being mostly clones of those two, blindly followed due to ignorance and/or apathy, with a pinch of sheer lazyness on the part of the devs. They certainly didn't spend any time thinking about the ramifications, beyond "I use that software repository, so I must comply".
-
Thursday 7th July 2022 20:41 GMT steelpillow
Re: Depart, I say, and let us have done with you.
The special piece of shite about the Debian road was that they allowed/connived in the active shafting of older init systems. Many utilities and apps consequently grew dependent on SystemD and so its use snowballed across all the distros that were neither RH nor Deb derived, just to run standard Linux stuff.
The Devuan *nix gurus spent many a happy hour automating a return-to-sanity service before the rot could be stabilised. In some cases the only answer was to fork the tool. Devuan even still keeps an empty file called systemd because there are a fair number of tools/apps which imagine it is a dependency and check for it, even though they never do more than touch it. They would not fire up if it was not there, even though there is nothing in it. Talk about lazy programming!
While Debian nominally allows you to install an old-style init setup, the Devuan experience proves the futility of doing so. OTOH it is reasonably straight forward (if utterly pointless) to do a systemd build of Devuan.
All this forced choice was achieved, as noted, through simple laziness and swallowing systemd advocacy because it was easer than thinking.
-
-
This post has been deleted by its author
-
Thursday 7th July 2022 22:54 GMT unimaginative
Re: Depart, I say, and let us have done with you.
I suspect the fast boot is important to people running large numbers of cloud servers they scale up and down rapidly.
It also standardises the boot system, whereas if RH had gone for one and Debian for another it would have complicated things.
-
Friday 8th July 2022 04:21 GMT Anonymous Coward
Re: Depart, I say, and let us have done with you.
"fast boot" is an oft-heard claim, but my experience with systemD is the opposite -- it didn't make boot noticeably faster, certainly fiddling small change relative to the hardware doing POST, and in some cases made shutdown dramatically worse / slower.
How many of us have seen systemD stall on shutdown while some annoying and all but pointless timer counts down, while systemD presumably is trying to end some branch of its dependency tree and has apparently gotten itself into some confused state.
Asking poettering's lot about it results in "you're doing it wrong" or similar unhelpfuls. Gee thanks.
The attitude and feature creep are even worse than the technology.
Damage done, but good riddance anyway.
-
Friday 8th July 2022 06:30 GMT Kabukiwookie
Re: Depart, I say, and let us have done with you.
It also standardises the boot system, whereas if RH had gone for one and Debian for another it would have complicated things.
If you want something that looks less complicated there's alreay 2 choices for desktop.
People who have trouble understanding sysV init, will not touch any of my servers. Ever.
-
Friday 8th July 2022 09:29 GMT Doctor Syntax
Re: Depart, I say, and let us have done with you.
"It also standardises the boot system, whereas if RH had gone for one and Debian for another it would have complicated things."
There was a widely accepted boot system, sufficiently widely accepted to be looked on as a de facto standard. It was RH that changed that with the introduction of systemd. Preference for a standardised boot system is an argument against Red Hat and systemd.
-
Friday 8th July 2022 13:24 GMT Jamie Jones
Re: Depart, I say, and let us have done with you.
Obvious xkcd: https://xkcd.com/927/
-
-
-
Friday 8th July 2022 15:58 GMT Smartypantz
Re: Depart, I say, and let us have done with you.
Systemd is made for automated deployments in the cloud for organizations having the resources to maintain this approach, and, crucial, the resources to control the automated administration.
SysV init is usable by humans on systems run by humans. This enables independent computing, which runs contrary to the interest of the cloud vendors.
That's it. Sad but true
Incidentally, the same motivation is behind the insane release schedule of software like the chrome browser.
-
-
This post has been deleted by its author
-
Thursday 7th July 2022 21:10 GMT Anonymous Coward
Re: Depart, I say, and let us have done with you.
Because no one else stepped up to build a replacement modern init system during the window where it mattered. The limitations with init were bad enough that people put up with early systemd because it WAS better in a lot of ways that mattered.
Unfortunately, due to the influence of Red Hat as a source of so many distros, it had trickled down pretty far by the time the problems were becoming apparent. The problems being that Pottering codes like an animal and never looks back, so after a couple of years, it would have taken a huge team to untangle his signature spaghetti bowl of inter dependencies, incompatibilities and mistakes.
This issue isn't that he can't code. The issue is that he seldom listens, never asks, and couldn't care less about maintaining compatibility with anything he didn't build or code. That personality profile is actually toxic in software and project management. He also seems to have a total disdain for the part of the community that isn't on the coding teams. The ones who run the systems in the real world. That includes the ones who also pay the bills.
It will be interesting to see how he does at Microsoft, but it won't change the team he built and ran at Redhat. They drank the flavor-aid already. So I'm not holding my breath for any quick change of heart from the systemd team. They are still trying to mutate Linux into a monolithic desktop operating system that developers run on their personal laptops. If you work on servers, I'd look at other UNIX options, but who knows, maybe RH will take the chance to put an actual systems person on the job.
At least Sat may be able to keep Pottering busy for a few years.
-
-
-
Friday 8th July 2022 09:35 GMT Doctor Syntax
Re: Depart, I say, and let us have done with you.
It doesn't serve the needs of this laptop. The arguments I seem to hear are that it's to serve the interests of admins who want to bring up servers quickly (presumably so quickly they aren't going to spend time doing memchecks?). That seems to be where I hear the defences coming from.
-
-
Friday 8th July 2022 09:38 GMT Alan Brown
Re: Depart, I say, and let us have done with you.
"Red Hat's focus is on servers."
No, Red Hat's focus is on a half dozen very large customers who generate 80-90% of its income and a large part of what THEY want boils down to "modernised Xterms"
This is why academic users have been increasingly jumping ship to distros which accomodate their needs
-
Friday 8th July 2022 11:31 GMT r0land
Re: Depart, I say, and let us have done with you.
There where several interesting contenders, for being our new init system, 10-15 years ago. The competition was definitely not lacking.
But Lennart Poettering had a driving vision, that the people behind the other systems lacked, he wanted to include most everything regarding basic infrastructure from logging to DNS resolving. Among other things that systemd engulfed was D-BUS. Since he promised a brighter and better future for the D-BUS system (and I think also for udev, which also may helped convincing both KDE and Gnome) the major desktop environments (especially Gnome and KDE) decided they wanted that. Accordingly the major distros had to follow their decision, if they wanted to continue to be relevant on the desktop.
-
Friday 8th July 2022 14:02 GMT Missing Semicolon
Re: Depart, I say, and let us have done with you.
"couldn't care less about maintaining compatibility with anything he didn't build or code" Yes, this!
Cases in point:
* The change for mounting on boot, where by default failing to mount swap causes the machine to hang in the useless systemd console, that requires a human at the console (or on ILO) to fix the problem. Principle of least surprise is failed, when you move the swap around, you get an unbootable system.
* The change to default of killing all user processes on logout. This was done because Mr Poettering had leftover Gnome processes on logout, and thought that was the most important use case. Everybody running a long-running backup or something using gnu screen or tmux is therefore due for disappointment.
-
-
Friday 8th July 2022 11:30 GMT r0land
Re: Depart, I say, and let us have done with you.
Well the major desktop environmenst needed a better D-BUS implementation, since systemd included such a thing, both Debian and KDE (and several other desktops) made systemd a requirement. Hence making systemd obligatory, may have been a painful decision, it still was the only sensible way forward, if you wanted to make your distro compatible with the major desktop environments.
Getting a proper service manager was an added bonus, and all the feature creep, with systemd taking over everything from logging to anything that Lennart laid his hands on, was more of the price we had to pay, for the joy of getting both a better D-BUS and modern service manager.
Please never forget that the first name that Lennart suggested for systemd was not systemd but actually "Baby Love", maybe the only love systemd ever got...
/r
-
Tuesday 12th July 2022 12:11 GMT teknopaul
Re: Depart, I say, and let us have done with you.
Same reason a lot of code is used.
Instead of write good new compatible code that wins by superiority. What devs do is write something and they go about trying to get people to use it.
I see this daily in my line of work and it's really annoying. People who do it do damage. They don't necessarily do it for money they do it for all sort of ego/brogrammer reasons but it has the same effect no matte r the reason for it.
Microedont deprecate support for Windows xxxx for any other reason other than there are alot of devs in the company that want you to use the new code they wrote.
Good developers work with other people's code all day.
-
-
-
-
Thursday 7th July 2022 17:04 GMT karlkarl
> Am I the only one who still compiles everything from scratch to suit the hardware?
I think it is at least important to know *how* if push comes to shove.
It is pathetic to see consumers say how something is "not user friendly" just because they aren't willing to learn. Having to learn and being user friendly aren't mutually exclusive ideals or you end up with an iPad that can't actually achieve anything useful... but is easy for the "less technically able".
-
Thursday 7th July 2022 20:05 GMT ClockworkOwl
Whilst I wholeheartedly agree with what you say.., I'm also getting quite tired of all the pointless things I have to learn, only for someone to randomly decide "it's all change, relearn the old skills...'cos!"
I mean, how much space is left now? Surely without an MIB style eraser, I'm gonna run out!
Randomised eraser>
-
Friday 8th July 2022 06:56 GMT claimed
Let me come and rewire all the light switches in your house so you have a single clapper that can be controlled from anywhere, but you have to clap the correct number of times for the room you require, or the fridge. We'll have a hell of a time and you can harangue your pathetic guests if they complain!
-
-
Thursday 7th July 2022 19:30 GMT John Sager
I think if I felt I needed to do that I would go back to Gentoo. I used it on some of my test machines back in the day, but I got a bit fed up of the rebuild almost every day aspect. If I left it too long then I started to get sync issues between what I had and what the current build was. There's a lot to be said for LTS versions, and it's not very often that something I want to do needs stuff that's a bit more recent. As always YMMV.
-
Thursday 7th July 2022 21:24 GMT Anonymous Coward
Yeah, not compliling whole systems from source on a regular basis
It's slow, it's a waste of electricity in most cases, and in the real world, mistakes are common, and performance gains tend to be small and infrequent. So it's not a great flex.
That said, there may be individual apps that benefit greatly from a tweaked compile, so it's not that people shouldn't ever do it, it's that they should really weigh the benefits first.
Most hardware isn't exotic enough to justify it on that basis, but you will probably know when you have some that is. That is a case where when you gotta, you gotta. Smart NIC with custom on die firmware optimizations? Off to the make files with you.
But the issue is that once you start, you have to keep going to keep up with the inevitable patching train. So I really avoid compiling packages that perform adequately if they are part of the boxes public surface. Better to build it on an LTS release of a popular distro so the patches come down faster than my news feeds, and less likely to have me screw up the patching train trying to manually merge a patch.
Ditto for modifying the source in most cases. Think about it hard, because once you make your own fork, forever will you need to merge to maintain it.
That way likes madness.
-
-
Friday 8th July 2022 13:31 GMT Jamie Jones
"Am I the only one who still compiles everything from scratch to suit the hardware?"
I do that too. It was more relevant in the later i386 days, but is becoming more relevant now with amd64 as newer chips get extra features.
It also means I can include my own source patches (done automatically, barring a refactoring being required)
-
-
-
Thursday 7th July 2022 16:35 GMT HeadPlug
Not an expert, but...
I for one am sad - I do believe we need distros with lots of knobs and going a certain way, but at the same time, we've never had a proper modern distro to compete with commercial OSes on UX. As controversial as his contributions were, I can't help but feel they were necessary if we were ever to have a polished, "just works" distro.
I don't get why systemd is so controversial anyways - yes, it's a lot of eggs in one basket, but if so many distro maintainers decided to adopt it anyways, just like other 'scandals' like Wayland and Flatpak, maybejustmaybe it actually solved bigger problems and made things slicker?
In other words, we can have both Devuan and Debian, so why fight a purity war? We've had power user distros for decades, maybe it's time for a distro that the community hates, but at least ticks UX boxes so we can at least fight Window$ and Tim Apple.
-
Thursday 7th July 2022 19:05 GMT jake
Re: Not an expert, but...
"so why fight a purity war"
It's not a purity war. Most of us are init-agnostic.
However, the systemd-cancer actively and intentionally breaks software. One should be able to switch inits on any given system without breaking software compiled for that system.
In essence, the systemd-cancer is an answer to a problem that nobody had. Throw in the fact that it's sticking its tentacles[0] into places where nobody in their right mind would expect an init as a dependency (disk partitioning software? WTF??), can you understand why us "old guard" might question the sanity of people singing it's praises?
[0] My spall chucker insists that the word should be "testicles". Tempting ...
-
-
-
Friday 8th July 2022 12:38 GMT Jonathan Richards 1
Re: Not an expert, but...
> just an init system, takes care not to break stuff and is transparent about what it's doing
I think this is why I *still* prefer SysV init to systemd. It's the "do one thing and do it well" principle, which systemd definitely does not observe. It could be said that init didn't do it well, or well enough, and that would be arguable, but systemd, as jake said above, has tentacles and tentacles are, in principle, the wrong way to go about OS architecture. Oh, and failing to write accessible and human-readable log files. I understand how systemd-journald works, I just don't like it.
-
-
-
Thursday 7th July 2022 19:09 GMT jake
Re: Not an expert, but...
"at least ticks UX boxes so we can at least fight Window$ and Tim Apple."
Have you not noticed that Microsoft is selling *nix solutions?
And of course the free-tards in Cupertino have been *nix based for decades.
They are coming over to the light side, there is no reason for us to move to the dark.
-
Thursday 7th July 2022 21:50 GMT Anonymous Coward
And the trolls weigh in.
That was never the problem. People have said over and over the problem was not that Linux didn't need, or should have modernized parts. The problem was that systemd's development, design, and implementation was flawed, needlessly violated UNIX and Linux design principals and broke compatibility in ways it didn't need to. These things happened because Pottering personally didn't care, and couldn't be bothered to ask before making changes or listen to the concerns of people his changes impacted.
The other issue with your post is the suggestion that we need to endure the mess he made to have a modern Linux system with a decent UI. Systemd didn't make that happen. What we have isn't that, and the big D isn't a reason it would succeed, but it set a bad example for the other projects that helped them miss making it over the bar. A new deterministic init system was necessary, systemd was not. Most of his other work fits the same pattern, where it fixes some things he didn't like, broke things he couldn't be bothered to think about, and could have been build better by someone else but wasn't, mostly because of the mess of systemd dependencies.
It's not a purity war, it never was, that's a troll trash-talking point to bait fools and other trolls into a flame war where there are no real facts or arguments. Splitting already limited communities in smaller distros into warring political factions may entertain trolls but hurts everyone as wastes people time. It the systemd team acted like professionals they could have controlled the dependency sprawl and allowed a single Debian community to exist. Instead, the amateurs ruled the day. So instead you call for people to just stop complaining, not fix any of the problems, and spend all day fixing the same problems of a dozen different forks, because that somehow is the reason we don't have a shiny polished Linux distro to play desktop OS for you so you won't have to pay for a Mac or a copy of Windows?
Good luck with that.
-
Friday 8th July 2022 13:38 GMT Jamie Jones
Re: Not an expert, but...
Repeat after me:
Linux isn't the only UNIX-like OS in existence.
Linux isn't the only UNIX-like OS in existence.
Linux isn't the only UNIX-like OS in existence.
Linux isn't the only UNIX-like OS in existence.
Linux isn't the only UNIX-like OS in existence.
These sorts of changes are pushing software to be Linux-only. I'm old enough to remember when Linux users used to moan about Microsoft that the third-party software should be "cross-platform".
Linux has even less of a technological excuse to build walls than Windows did,
-
-
-
Friday 8th July 2022 11:18 GMT Electronics'R'Us
Re: I couldn't be happier ...
Many years ago (early to mid 80s) I was at Raytheon in Virginia Beach.
The chief engineer got a request from a government department for a reference for a person he had fired.
He wrote that 'the Commonwealth of Virginia and <name> deserve each other'.
I think the same sentiment applies here.
-
-
Thursday 7th July 2022 17:18 GMT tekHedd
The Skunk
When I was in college, the college radio station was broadcasting alternative music, and run by students who were absolutely dedicated to high fidelity music. One year, a new station manager was appointed, and proceeded to do everything possible to alienate the staff. I call him The Skunk. His stink drove everyone away. Nobody considered that this move might be calculated, but the next year, after basically 100% of the student staff had quit, the university quietly took over the station and turned it into a university mouthpiece, broadcasting "safe" music, school propaganda, and sportsball games.
So, if Poettering is The Skunk, and the radio station is Linux...
-
-
Friday 8th July 2022 11:56 GMT Anonymous Coward
Re: The Skunk
From a Post I'd bookmarked from a month back by Oiseau [my emphasis]:-
> Systemd is a virus.
> It works just like the registry does in MS operating systems.
>It's a developer sanctioned virus running inside the OS, constantly changing and going deeper and deeper into the host with every iteration and as a result, progressively putting an end to the possibility of knowing/controlling what is going on inside your box as it becomes more and more obscure.
> Systemd is nothing but a putsch to eventually generate and then force a convergence of Windows with or into Linux, which is obviously not good for Linux and if unchecked, will be Linux's undoing.
> So it does not seem as there's nothing new here: it's the well known MSBrace at work.
> Now go and tell me that Microsoft has absolutely nothing to do with how systemd is crawling inside/infecting the Linux ecosystem.
Sounds even more on the money in the context of this.
Interestingly, I now notice that Oiseau has also joined in this thread.
-
-
Thursday 7th July 2022 18:15 GMT VoiceOfTruth
SMF
-> richer systems-management tools on modern xNix systems, such as SMF in Solaris
A small bone to pick with this sentence. SMF does not have its tentacles in the OS to the same extent as systemd. It doesn't replace syslog or cron, for example. Systemd does much more than SMF, and in my opinion it does far too much.
-
Friday 8th July 2022 11:00 GMT Down not across
Re: SMF
I think that may have been the point the author was trying to make.
If systemd, rather than being the cancer it is, had truly been FOSS implementation of SMF, I don't think anyone would've objected. I run a lot of Solaris boxen and for any homecooked stuff, I pick either simple init script or SMF with its manifests if I really need the contracts and milestones.
-
-
-
Thursday 7th July 2022 22:00 GMT Anonymous Coward
Re: What makes you so sure he won't continue to fcuk up Linux
Not a single thing, but it is unlikely to improve his efficiency, and the quality of his work is on par with his new employer. I doubt it will fix anything, but it may not make it any worse then him having another 15 years of seniority at Red Hat.
-
Friday 8th July 2022 09:50 GMT Alan Brown
Re: What makes you so sure he won't continue to fcuk up Linux
The problem is that there are many _MANY_ more like him at Redhat
This is a particular problem the further up the food chain you go.
Mediocre programmers end up being pushed into management to keep them out of the way, where they end up causing even more damage as they end up with more free time to throw bad ideas around and more power to make them happen
The good guys are either too busy coding, firefighting or hating having been promoted into management and away from the work they loved
-
-
-
Thursday 7th July 2022 21:53 GMT Anonymous Coward
People are awful
Came to read the comments here. I wonder if any of the people talking about him have actually met him, talked to him, chatted about this stuff over a beer or bottle of Mate?
He's a very approachable guy, and has done the conference circuit for decades. Easy enough to do that if you weren't all so busy being keyboard warriors.
The kind of hate spewed out in many if these comments goes way beyond technical differences of option. It's just bullying, plain and simple. You should be ashamed of yourselves.
-
Thursday 7th July 2022 23:24 GMT Doctor Syntax
Re: People are awful
If I were to meet him (assuming I could find someone to pay for me to go on "the conference circuit") would that somehow undo the damage? The primary issue is not actually him, it's the utter mess that he's produced, or at least that's generally attributed to him and which, AFAIK, he hasn't denied responsibility for. There are others to share the blame of foisting this stuff on us in the way Jake has outlined above. Nevertheless the responsibility stops with him.
It matters not whether he's approachable or not. For all i know "he" could have been a group of people hiding behind a nom de plume and it wouldn't have made any difference. It is the technical differences that matter.
-
Friday 8th July 2022 04:46 GMT steelpillow
Re: People are awful
There is a grain of truth in that - the hate has been earned as much by the Debian winners who rewrote
historyinitialisation in the teeth of opposition from the wider community and still refuse to listen.But Poettering an angel with feathered wings under his T-shirt? I don't think so.
-
Friday 8th July 2022 06:51 GMT Kabukiwookie
Re: People are awful
This very approachable guy has wasted countless hours of my life that I will never be getting back and I am far from the only one working with Linux that's in the same situation.
Not only that, his 'legacy' will waste many more of my hours in the coming future as I unfortunately have to deal with that pile of crap that's systemd.
Why would it matter if someone who has wasted so much of other people's time is 'approachable'?
-
Friday 8th July 2022 09:56 GMT Alan Brown
Re: People are awful
Amen
I've learned to live with systemd, that doesn't mean I like it - and I'm adamantly opposed to it stepping outside the boundaries of process management
Unix philosophy is "small simple units". Systemd is neither - and it cannot justify the added complexity in the way that (say) PostgreSQL can trivially do so over MySQL (My Cow Orkers refuse to migrate to Postgres for large setups, resulting in man-years of scripting tweaks being needed which are simply not needed for Psql - they refuse to even TRY it)
-
-
Friday 8th July 2022 10:39 GMT Liam Proven
Re: People are awful
[Author here]
Quite so. I have met him, and I rather liked the man. He seemed friendly, approachable as you say, very very smart, and I came away favourably impressed.
And I speak as someone who has been told to go kill themselves for daring to say that C is not a good language.
-
-
Saturday 9th July 2022 02:21 GMT Sitaram Chamarty
Re: People are awful
because you didn't "approach" him right :-) (sarcasm there, just to be clear)
I had a boss like this for several years. A very learned man (though I won't list his qualifications). Very smart, mind like a steel trap, and when you meet him as a relative stranger he would be so amazingly friendly and empathetic and all that.
Sadly, none of that applied if you worked with him or for him. He was easily the worst boss I ever had.
-
-
-
Friday 8th July 2022 13:49 GMT Anonymous Coward
Re: People are awful
Posts here have criticised his coding methodology, his refusal to listen, his dogged marking of things as "won't fix".
These are not personal attacks.
Not one post has called him an arsehole who kills fluffy kittens,
I think you, Mr Poettering, are being too sensitive.
-
-
This post has been deleted by its author
-
Thursday 7th July 2022 23:35 GMT Doctor Syntax
"I have a news flash: Linux went corporate 15 years ago and the image of the talented lone programmer contributing to the init system after putting their kids to bed just for the fun of it are long, long past."
Yes we know that. Some of us fought the battles to get Linux into corporate use.
And it wasn't just Solaris & HP-UX in the 1990s. There were a few others about as well; I used some of them back then. They also were corporate and they didn't have this mess.
The difference, I think, is an influx of admins who expect systems to be black boxes with a few things to click on, who don't have the skills to write a shell script if they need one, don't recognise they need one because they don't expect the system to handle anything that hasn't been pre-cooked and don't expect long uptimes (and hence the prattling about cattle not pets).
-
Friday 8th July 2022 04:25 GMT Pirate Dave
"...an influx of admins who expect systems to be black boxes with a few things to click on, who don't have the skills to write a shell script if they need one, don't recognise they need one because they don't expect the system to handle anything that hasn't been pre-cooked and don't expect long uptimes (and hence the prattling about cattle not pets)."
Eh, didn't we used to call those guys "Paper MCSEs"? Guys who could follow the cookbook, but couldn't write their own recipes. I mean, God bless 'em, as Corporate needed exactly that when Windows started ballooning in the late 90's early 2000's, and the bean counters didn't want to pay beardie-level salaries just to manage a bunch of overblown Windows machines. But yeah, same thing has infected Linux to some extent, I think, and part of that is because systemd made everything very beige (after the red-haze of rage wore off).
Funny corollary to this - it's sometimes hard to find a decent "How-to" on some things these days because the SNR has gotten way out of whack. Used to be you had to dig through maybe a dozen before you found the gem. Now it seems if there even IS a gem, it's on the third page of Google results.
Mine are still pets. A job wrangling cattle would probably get dull pretty quick - you'd be doing the "higher value" stuff, not the fun stuff. I used to love messing with salesmen about this. "But that's MY JOB your software automates..."
-
-
Friday 8th July 2022 12:38 GMT Pirate Dave
Ah, yeah, I let all the magic smoke out a couple of times. Always a fun time.
Pro tip: if you've befouled a network card to the point that a chunk of the black plastic housing has blown out of the very center of the main chip, don't touch that void to see if it's hot. It is. Very much so, and that blister on the very tip of your finger will last for a couple of days.
-
-
-
Friday 8th July 2022 09:27 GMT theOtherJT
I mean, I agree with all of that - but to be fair the "Cattle not pets" approach is still a good one. It prevents the occasional smartass sysadmin who thinks they're above such tedious things as following standard processes - or even just writing things down - from buggering about with a box by hand so that no one else on the team knows what state it's in or why it's doing whatever weirdass thing it's doing the next time they go on leave and you have to look after it.
-
Friday 8th July 2022 09:53 GMT Doctor Syntax
Those weren't really pets anyway. They were reliable long-lived work horses, reliably running businesses day in, day out, week in week out.
But the real problem with your comment is that the bulk of tit is the inversion the actuality. The virtue of Sysv init is its transparency. What it's doing is written down. It's written down where it matters. It's writen down unambiguously. It's written down in the init scripts. There can be no conflict between what might be written down in some ambiguous or out-dated document and what's running. If there's any perceived weirdness it's in the mind of the perceiver who can't grok shell scripts.
-
Friday 8th July 2022 10:43 GMT Liam Proven
[Author here]
> The virtue of Sysv init is its transparency.
Personally, as a former sysadmin type myself, I never found that. I always found the BSD init system made more sense to me.
A lot of people say they like the SysV stuff nowadays, but Unix System V was just an earlier round of inter-vendor standardisation, keeping everyone happy by incorporating a little bit of everything into a bloated mess.
Then a few decades went by, everyone forgot this, and now it's praised for elegance and clarity.
I think that view is through rose-tinted bifocals.
It really wasn't. It was a mess then and it still is.
IMHO.
-
Friday 8th July 2022 20:32 GMT Kabukiwookie
incorporating a little bit of everything into a bloated mess.
Last time I checked, init clocked in around 140k, a few scripta, some directories and symlinks.
How can this be described as a 'bloated mess'?
It's possible to exactly follow what happens at boot. I have no idea how you would come to that conclusion. I would call it lean and transparent...
Don't know enough to compare it with BSD init myself, but 'bloated mess'?
-
Friday 8th July 2022 22:09 GMT Alan Brown
I resisted going to SysVinit and stuck with BSDinit for a long time
Once faced with no choice and having to RTFM, it actually made sense and works at least as well as BSDinit
That can't be said about systemD. Yes, it solved a number of issues for desktop systems, but its desktop single-user origins are glaringly obvious in a number of areas. It's not well-suited to heavy lifting
-
-
Monday 11th July 2022 13:22 GMT theOtherJT
I think you misunderstand me - I agree with all of that, and I'm certainly more a fan of sysv than I am systemd.
But the principle of "no pets" is still a good one. Sysv init scripts aren't pets. Messing around in the init scripts by hand instead of doing the decent thing and logging all changes in git or similar and making everyone peer review the changes is the problem.
-
-
-
-
Friday 8th July 2022 03:55 GMT Sitaram Chamarty
El Reg continues to be the only place online whose users generally reflect my own well-considered antipathy to Poettering...
Most other forums have a somewhat different ratio of like/hate than here. It is also quite possible that El Reg readers also have a higher average age than the others (and I am sure my contribution to that average is also high!)
One thing you'll often hear is that shell scripts are baroque, hard to debug, and what not. That may well be true, but you can pick another one if you wish. Meanwhile, those same people fail to mention that this "declarative syntax" has hundreds of keywords. Many of them look very similar, with subtle differences that can trip you up. The values are not always intuitive, but even if they are, you had better RTFM to make sure you're using the right one.
How the hell this is supposed to be easier to learn I do not know -- 90% of the help messages I see on systemd get responses that say "use this [boilerplate]".
A shell script is much more immediately understandable without having to refer to manuals.
-
Friday 8th July 2022 07:49 GMT Paul Crawford
A good example of systemD stupidity I suffered was it failing due to a non-ASCII character in a configuration file/service comment FFS!
What sort of moron parses non-command stuff for syntax errors against some nominal design aspect?
But that is typical of Pottering's approach, basically you did it his way and anything else was a "won't fix" even if it went against established behaviour, or broke other services. Have you tried reliably using a VPN with NetworkManager? Another example where one of his projects behaves poorly but the design team don't care.
-
Friday 8th July 2022 09:28 GMT Anonymous Coward
"Have you tried reliably using a VPN with NetworkManager?"
Yes, every day for the past 2 and half years, it Just Worked™ (as long as the endpoint was actually up, and not down for scheduled maintenance).
But I'm sure that I'm wasting my keyboard when I say that Your experience is not the only possible experience, and is not necessarily experience of majority of users and admins. Because what I see is that Poettering bashers are incapable of empathy.
-
Friday 8th July 2022 10:57 GMT Paul Crawford
Your experience is not the only possible experience
Not to mention numerous VPN provider who recommend not using NetworkManager, some have even had to write an alternative to get round the bugs (or "working as designed") and other privacy issues like DNS leaking, due to how it manages stuff.
https://airvpn.org/forums/topic/25263-how-to-stop-dns-leaks-in-linux-network-manager/
-
-
Sunday 10th July 2022 03:22 GMT Pirate Dave
Re: lurking about since the 90s...
There was a time when I wasn't sure if I wanted things to be Registered or Inquired. I finally settled on Registered, as it seemed a friendlier place (once they got the forums worked out).
I lost my original handle (Darklurker) in the late-noughties when I switched ISPs and lost access to that email account. Had to start all over in 2008 as Pirate Dave (was at the height of the Pirates of the Caribbean movies, nothing to do with downloading warez, honest...).
There are times I still miss some of the old sites, mostly varlinux.org. That was my favorite.
-
-
-
Friday 8th July 2022 04:35 GMT steelpillow
I had this nightmare last night
Dreamed that Linux had become a minor fork of PAWS OS - PulseAudio, Wayland and SystemD, Poettering had changed his name to Ballmer and was stalking Linus with a semi-automatic of dubious legality. Scratched on the butt was the legend "Do one thing and do it dead".
-
Friday 8th July 2022 08:35 GMT Anonymous Coward
So, which poor sod is going to have the unenviable task of taking on and maintaining his source? Who would want to? Or is MS gonna pay him to do it from the outside?
Simpler, much more maintainable tools instead of Poettering's efforts I would suggest would appear to be a viable way forward, just as all the greybeards have said all along.
-
-
Friday 8th July 2022 09:24 GMT Anonymous Coward
Re: Here are alternatives
All fine, with the minor problem that commercial linux distros use systemd, and applications sit on top of it that have dependencies on their "supposed" init system.
It could certainly be considered an anticompetitive tactic adopted by RedHat.
Anticompetitive free software. Who knew?
-
Friday 8th July 2022 10:43 GMT Steve Graham
Re: Here are alternatives
In my case, just running a home network with 4 Linux devices, I don't really need an alternative to SysV because uptimes are typically 6 months or more*. When I do need to reboot, usually after a new kernel compile, I don't mind whether it takes 10 seconds or 30.
And I don't need anything to do process management or service management.
*(When a laptop comes out of RAM hibernation, it isn't a reboot as such.)
-
-
Friday 8th July 2022 11:32 GMT r0land
There is no doubt that Lennart Poettering is a brilliant programmer, regardless of other things that has been said about him.
It will be very interesting to see what will happen to systemd now, if mr Poettering is leaving for Microsoft to abandon systemd or if it is because Microsoft is so much in love with Linux that they are planning on sponsoring his work on systemd, is something that we will have to find out in the near future.
If he actually is leaving the future of systemd up for others to decide upon, then we may see something akin to the development of PulseAudio which, under his supervision, was going to revolutionize the linux multimedia experience. Beside from introducing new (and, at that point, unseen) magnitudes of complexity in the configuration department, it still provided a modern sound experience. We could enjoy sounds from various and simultaneous sources at the same time, an unheard of luxury at that point. At the start of the project the promise was low latency sound at the same level of flexibility as on both Windows and Macos. PulseAudio was intended to take over everything from juggling the bits with the audio adapters to communicating with the programs that needed sound. Lennart invented many interesting use cases, for his subsystem, many involving sound over the network. What happened was that PulseAudio became such a feature rich system that it got ported to both Windows and Macos, regardless of the claims that both those systems where the main sources of inspiration for PulseAudio.
After that Lennart Poettering abandoned PulseAudio, the project has given up some of the original visions, for instance nobody seems to want to replace the ALSA audio adapter drivers for "native" PulseAudio modules.
We will probably see a similar development regarding systemd, some of the less useful functions will get removed from systemd, the interfaces will get more stable and the various systemd modules will become actual modules, that can (and will) be implemented by other programs when needed.
We may see some rethinking regarding session management, compared to service management; what is good for service management may not be (even) useful for session management. There has been a lot of confusion about what simple commands like su are supposed to do under systemd, those things should be easily sorted, with a more pragmatic leadership. Another similar note is how systemd figures it needs to do something about my desktops sound output when my screen saver activates. With systemd its seems like a major headache setting up your desktop in a way that you can play music in your speakers, while you are fixing yourself a nice cup of drink. On a general level, systemd becoming more stable and less of a moving target will definitely save us all a lot of work. Systemd may never become an alternative to either LXC, OpenVZ, or Docker, but most of us will not be sorry for that.
-
Friday 8th July 2022 13:12 GMT Jamie Jones
"it still provided a modern sound experience. We could enjoy sounds from various and simultaneous sources at the same time, an unheard of luxury at that point. At the start of the project the promise was low latency sound at the same level of flexibility as on both Windows and Macos. "
Those are all things that the OSS driver did natively in the kernel on other systems for years. FreeBSD had all of that - no need for some kludgy userspace addon.
Any sane advancement for Linux at that point would have been to fix your crippled OSS implementation, not add workaround hacks, or new feature-incomplete drivers like ALSA.
"With systemd its seems like a major headache setting up your desktop in a way that you can play music in your speakers, while you are fixing yourself a nice cup of drink."
I didn't know this, but it demonstrates the issue perfectly. What the hell is systemd doing messing around with your audio?
-
Friday 8th July 2022 23:17 GMT r0land
On a broader level I do agree, Pulse is far to big and complex for 95% of the users. There are some special cases where the extra features might be usefull, but those could easily be satisfied with special tools in a perfect world.
The answer to your question about why systemd is messing with my audio, as far as I have been able to figure out, indeed there could be security implications if I leave my computer locked while strangers in the vicinity of my machine could both hear voice messages intended for my ears only and they could even give some nasty answers in my mic. That is the official status for this issue; but for 98% of the users this view makes no sense at all.
The easy solution is to disable the screen saver ,-)
-
-
-
Friday 8th July 2022 12:57 GMT Jamie Jones
" If some people's aversion for these tools drives them to switch to FreeBSD or the other BSDs, that will be good for those OSes."
The problem, though, is that when enough software relies on these "tools", it ends up making things harder to port. The number of hacks to get "linux" programs working on FreeBSD is increasing.
For instance, some programs need things like pulseaudio installed just because that's the API they use, despite being unnecessary hacks in the BSD world.
systemd compatibility shims are also becoming more necessary.
P.S. Wayland isn't Linux only. It has native FreeBSD support.
-
Friday 8th July 2022 13:07 GMT Jamie Jones
"Despite all the furor, systemd is merely one example of a trend towards richer systems-management tools on modern xNix systems,"
I don't know anyone who moans about any of the features that systemd offers, just the way it does it.
There are far better ways to improve the init system, and other core services, without making such poor design choices. (And when I say "poor", I mean, in the eyes of most people. I can see it not being a poor choice for the authors who want to control the entire ecosystem.)
"sansva" has already posted here a list of alternate init sytstems that exist: https://forums.theregister.com/forum/all/2022/07/07/lennart_poettering_red_hat_microsoft/#c_4490007
-
Friday 8th July 2022 13:53 GMT tatatata
The main argument for systemd used to be that we need something "modern". And of course, people that don't like systemd are "Luddite", they "are afraid to learn", "go away, you’re clueless, we know better than you, and besides, we have commit privs and you don’t, so go away".
For me, the problems with systemd were mostly system hangs and NFS troubles. Oh, and somehow, most of the trouble needed a systemctl --system daemon-reload to solve them. So, I went back to Slackware.
The animosity towards Poettering is, imho, mainly caused by het reaction to bugs. Won't fix, because, on his laptop, it works.
I would be interested to see if Kay Sievers (mostly known for the kernel-debug issue) follows him.
-
Saturday 9th July 2022 15:45 GMT hayzoos
Slackware not immune
Even though Slackware is a systemd free Linux distribution, it has to deal with dependency expectations in userland. The problem worsens as you try to add applications with systemd dependencies. And as pointed out elsewhere in these comments, the so called dependency is nothing more than a check for the presence of systemd.
-
-
Friday 8th July 2022 14:10 GMT Jamie Jones
It's not about a better UX
Many posts here are sticking up for systemd, saying it improves the users experience, and makes things easier to manage,
That's missing the point. It's not the issue.
You can make lovely and helpful management software for all aspects, but ultimately, all these things need to do is alter the already-existing config files. (often text files, unless there is a good reason not to do so)
Granted, some config and startup files may need to be tweaked if it removes unnecessary complexity in the updating tool (there's no need to be too anal), but generally, all a nice flashy piece of software should do is alter a file that can be altered any other way the administrator wants.
This has always been the main design philosophy difference between Windows and Unix - One make convoluted programs you have no choice to use, the other generally improves things for users by including things that run ON TOP of the system. systemd is firmly in the "replace" rather than "run on top" category.
How do you modify users accounts on a Unix system? I'm sure there are nice GUI's and web interfaces to do the job, whilst others may use "pw" on the command line, or even "vipw" to lock and "vi" the password file.
Ultimately, these tools do the same thing: They alter the password file (and shadow/master files as appropriate) - and not necessarily manually - your nice GUI could use the "pw" command under the hood.
There is no need to rewrite the fundamental way the OS manages users!
-
-
Friday 8th July 2022 18:50 GMT that one in the corner
Re: It is about a better UX
Can we get some concrete examples of what these bits of "basic modern functionality" are and how, say, systemd (or PulseAudio or whatever) does them better?
In all honesty, looking at the boxes around me, the newest tech I see is USB that actually works (all wired LAN btw, anyway WiFi is hardly new) - everything else is just "the same as it was decades ago, only more of it and it goes faster". I now need 64 bit addresses to use all the RAM, so that is new-ish, I guess?
Now, this is probably just because I'm simply not hip and with-it, but if you don't actually clearly give some examples of what I'm missing then comments like this are about as useful as "'cos I say so, no takebacksies".
-
Saturday 9th July 2022 00:47 GMT Jamie Jones
Re: It is about a better UX
I suggest you read the post again.
"Modern functionality" can and is added. That's got nothing to do with how things are configured. That has NOTHING to do with the user interface.
Unix has survived so long because it's modular approach makes it easy to extend and it's design principles mean it can adapt and make the most of new technologies easily.
Unix is the most common OS on the planet. It also powers the fastest computers in the world. This is no accident; this isn't because people are too stupid to learn new stuff; this isn't because people are too cheap to "upgrade". Sure it has issues, but they are not fixed by replacing the guts with a monolithic all-controlling suite of software that removes many of the things that made UNIX so extensible in the first place.
-
-
-
Sunday 10th July 2022 23:44 GMT Anonymous Coward
Arch Linux reasons for changing to systemd were not religious in nature.
https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
Timing:
We don't have a date yet, but we have a list of blockers (we need the next releases of util-linux and sysvinit at least, and we need full coverage of systemd service files for all packages that have rc scripts). So I guess the best I can say is "when it is ready". There is also the added wish to do it "as soon as possible" as it will make the packaging of the next versions of certain packages (gnome, polkit at least, but probably many others that I'm not aware of) much easier.
Transition:
We have tried to make this smooth.
0) The best approach is to first bring your rc.conf up-to-date according to the recommendations in "man rc.conf". It should essentially only contain your DAEMONS array (and a few other things, depending on your setup, see manpage for details). This will work both with initscripts and systemd so it is safe to do ahead of time, and make sure everything works as it should.
1) Install systemd, but you do not need to remove initscripts. You can now chose between the two at runtime (by adding init=/bin/systemd to your kernel commandline). If you do this systemd will keep respecting rc.conf and use rc scripts if systemd unit files can not be found.
2) Then you can move your system (hopefully seamlessly) over to a native systemd configuration: do (0) if you did not already, then find the corresponding systemd service file for every daemon in your daemons array and enable it using "systemctl enable <daemon>.service". Once this is done rc.conf is not needed by systemd at all anymore. Go through rc.local and rc.local.shutdown and turn them into service files (or, if you intend to keep them as they are, copy /usr/lib/systemd/system/rc-local{,.shutdown}.service to /etc/systemd/system/).
3) Once the above works ok, and you are confident that you don't need to revert to initscripts, then you can install systemd-sysvcompat, which will conflict (and hence remove) sysvinit+initscripts (and pacsave rc.conf, rc.local and rc.local.shutdown). You can now also remove init=/bin/systemd from your kernel commandline as /sbin/init will now be a symlink to systemd.
Benefits:
I have spent too much time arguing against the perceived deficiencies of systemd (such as: "it is not written in bash", "it was started by Lennart Poettering", "I don't like the (optional) on-disk format of the journal", "it uses dbus", "systemd's PID1 does more and is bigger than sysvinit's PID1", "I think there might be this other project that possibly is doing something similar. I don't really know anything about it, but I'm pretty sure it is better than systemd" and I'm sure there are many more). I strongly believe that 1) all of these perceived deficiencies are not deficiencies, but are actually benefits 2) even if I'm wrong, these things are not hugely important. So, with that out of the way: let's ignore all of those old boring arguments and I'll outline a few things that I find awesome about systemd, and why I think we should all be very excited about soon being able to use it. In no particular order:
0) it is hotplug capable: systemd assumes that all resources may appear and dissapear at any time. If you plug in your external harddrive after systemd has booted, it will be fsck'ed and mounted correctly. This is unlike initscripts which relies on all disks being enumerated and ready when it starts fsck, and then it relies on fsck of all disks being finished before it starts mounting any of them. Hotplug is important, not only because it is convenient to be able to insert/remove hardware while the system is running, but also because that's how the linux kernel does boot: every device appears to be "hotplugged" as the kernel becomes aware of it, so with a very fast boot we can no longer assume that all devices are ready and waiting for us when we need them (even if they were plugged in when the computer started). In reality this is often not a problem, but if you ever had your rootfs on an external USB harddrive you might have experienced problems (and as things become faster and faster more problems like this will crop up).
1) we can know the state of the system: systemd keeps track of all daemons, and all processes that are started, and who owns what, and when something fails, etc. Also, using the (awesome) journal all syslog() entries and writes to stdout/stderr by all processes are captured by systemd. These are stored with enough meta-data so that you can very easily retrieve say "all entries from a certain service/binary/pid" or "all entries written by the kernel regarding a given device", etc. In addition to logging this information, and showing it to you, systemd will allow you to specify (easily) what to do in a wide range of possible error-scenarios: "a service shuts down normally/with an error/ on a signa" or "a service has not sent its watchdog signal in the designated time" or "a service has shutdown with an error 10 times in the last half hour". The recent addition of hardware watchdog support also allows you to say "restart the machine if systemd itself is not responding".
2) it is modular: all of what is now rc.sysinit is split out into many independent services, each of which is well documented and easy to understand. I.e., if you don't like how systemd e.g. does it's fstab handling, then you can write your own little helper (in bash if you wish) to replace the official one. Doing this in the old initscripts is much harder because 1) it is not so clear which parts of rc.sysinit are dependent on eachother 2) any changes you do you'll have to merge on every update.
3) it allows dbus/udev to go back to doing the task they are meant to do: both udev and dbus are currently (mis)-used to start daemons/long-running services on demand. In the case of dbus this is by design, but in the case of udev it is not. Either way, it is not what those daemons were built to do, so in keeping with the UNIX principle of one task per daemon, it is great that we can now let systemd (whose job it is to manage daemons) take this over. That is, udev and dbus can both signal systemd to start a certain daemon, and it will behave like if it was started in any other way (you have the logs, status etc). One problem that this solves is the inherent race-condition in some daemons (I think bluetoothd was guilty of this at some point) allowing both being started as soon as possible on boot (say by putting it in DAEMONS), and to be started on-demand by dbus. Systemd makes sure that both these things can happen, and if they do happen at the same time you will only end up with one instance of the daemon as expected.
... see the OP for the rest