PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat (phoronix.com) 148
To much surprise, the lead developer of systemd Lennart Poettering who also led the creation of PulseAudio, Avahi, and has been a prolific free software contributor has reportedly left Red Hat. Michael Larabel writes via Phoronix: So far no public announcement appears to have been made, but according to a source has been reportedly removed from Red Hat's internal employee database. Yesterday Lennart did comment on the public Fedora devel mailing list to having now created a personal Red Hat Bugzilla account for his Fedora contributions after it was raised in bug reports and brought up on the mailing list that Lennart's Red Hat account is disabled. Emailing his Red Hat address this morning indeed yields an auto-response that it's no longer in use.
He's still active in systemd world with new commits made as of today, so it will be interesting to see where he ends up or his next moves with his vast Linux ecosystem expertise and pivotal role in spearheading systemd's direction.
He's still active in systemd world with new commits made as of today, so it will be interesting to see where he ends up or his next moves with his vast Linux ecosystem expertise and pivotal role in spearheading systemd's direction.
Popcorn time (Score:3)
I'm sure there will many fine comments to follow.
Re: Popcorn time (Score:5, Funny)
Sorry. Popcorn maker is stuck waiting for a startup process to complete.
Something something kernel joke.
Re: (Score:3)
...there's a conf file for that.
updatedb, then locate -i systemd and its under that tree. or that one. one of those.
good luck.
(sigh, I hate what unix has become under this kind of direction. I want my old init back, please)
Re: (Score:2, Flamebait)
Re: (Score:3)
There should be plenty of daemons poking him with forks, interrupting his processes.
Systemd is Awesome! (Score:3, Interesting)
Systemd made Linux system administration much easier and nicer. Is it perfect? No. Is it 1000 times better than sysv scripts. Yes.
Avahi is awesome too!
PulseAudio I was never thrilled about, has some cool bits, but I'm not sad to see it slowly replaced by PipeWire.
Re: (Score:3, Informative)
SystemD turned Linux in to a professional OS and brought it up to modern computing standard.
Pulseaudio was always and still is a disaster. I remember when all audio debugging instructions included as the first line, "disable pulseaudio."
Re:Systemd is Awesome! (Score:4, Funny)
> SystemD turned Linux in to a professional OS and brought it up to modern computing standard.
Compared to what?
Re: (Score:2)
Compared to the mess of scripts and chaos it was before.
Systemd has made the way I deploy systems so much more linear and repeatable.
Re: (Score:2)
Compared to the mess of scripts and chaos it was before.
The "mess" wasn't actually very messy, and it was easy to modify.
The issue was defaults, really. Systemd's real advantage was that by creating a monoculture then everyone knew what the defaults were. But that's an advantage of standardisation, not specifically of systemd which brings with it many issues of its own, not least of which is the massive, and often rather poor, codebase.
Re: (Score:3)
> SystemD turned Linux in to a professional OS and brought it up to modern computing standard.
Compared to what?
Windows of course.
Re: (Score:3, Informative)
> SystemD turned Linux in to a professional OS and brought it up to modern computing standard.
Compared to what?
Windows of course.
Actually, while Window's implementation of many concepts is sub-par, the concepts themselves are sound and better that Unix's traditional way of doing things.
For example: The registry.
The concept:
A centralized database where the configuration of the system and every single program in it is stored in a standarized, programaticaly accesible way.
Unix way: one or more files in one or more directories, each with differing standards and conventions, that need regexes and/or a parser to be analized programatically
Re:Systemd is Awesome! (Score:5, Interesting)
Since systemd operates only with the Linux kernel and ignores the basics of the File System Hierarchy, it's deliberately non-standard and has been on a campaign to ingest features I've tried to unfurl what introducing systemd did to various init procedures, it's often been exceptionally ugly to unwork.
Re:Systemd is Awesome! (Score:4, Informative)
It is a sad indictment of your understanding that you think that human readable files that can be read and manipulated using normal text-handling tools are inferior to binary blobs that are dependant on special tools.
Re: (Score:2)
Exactly this -
So many people don't understand what a giant leap backward those blobs are. The whole reason for the most part to use binary data is to make it more efficent to store and process FOR THE COMPUTER.
Text is the most user friendly thing you can do because it means users are free use any tools they wish to maintain or view it. Even if its not 'self documenting' its at least probably understandable or reasonably possible to workout what is going on with. Its also a lowest common denominator interfa
Re: (Score:2, Troll)
It is a sad indictment of your understanding that you think that human readable files that can be read and manipulated using normal text-handling tools are inferior to binary blobs that are dependant on special tools.
I know! I mean why aren't all files just human readable instead of binary?! They should all be human readable because if they aren't then they are inferior!
When the server is in the midst of a mental breakdown, yes they are. Binary logging and configuration files are all downside and no upside, unless you are clueless about standard Unix tools. In which case you should not be touching any live service in the first place.
Re: (Score:2)
But Linux has grown up. It's not a hobbyist's toy, any more.
What you really mean is corrupted by corporate greed. Something RedHat in particular very obviously stood for even in 1995 (they *REALLY* wanted to be the Microsoft of Linux... I doubt anyone saw Microsoft doing it instead).
Re:Systemd is Awesome! (Score:4, Insightful)
Are you serious?
Have you ever experienced what happens when the windows registry gets corrupted? You might just as well perform a clean install, if that happens.
If my /etc/fstab (for example) gets corrupted, I simply rewrite it. Why can I do so? 1) It's actually documented, 2) It's a plain text file.
I took fstab as an example, but this basically goes for any file in /etc.
You try recreating the corrupted parts of the registry. Oh, you can't? How about reinstalling windows (which is bound to leave behind a mess on your precious C drive)?
Re: (Score:2)
Are you serious?
Have you ever experienced what happens when the windows registry gets corrupted?
How often does that happen?
Re: (Score:2)
Let my give you an analogy, to clarify the idiocy of your remark.
Car accidents don't happen *that* often, so seat belts are completely unneeded.
Re: (Score:2)
standarized logs and config, in binary, standarized, and programatically accesible form
I am inclined to think that binary formats tend to be inaccessible, except through a specific API. One of the advantages of configs and logs being in text files is that the content can be analysed and edited using standard tools. You can do a nifty bit of script writing to add functions that a pre-conceived API did not provide.
I noticed this when writing some Python to automate work on PCB CAD files that I produce. The CAD file format is text, with some similarity to Lisp. It is no trouble to pick out data
Re: (Score:2, Informative)
That's *still* the first step to all audio debugging instructions.
Re: (Score:2)
Reminds me of a classic Microsoft work-around. In Windows 7 it was impossible to replace the software MIDI synth with something better, because each sound device only supported one software synth and Microsoft's one bound itself to every device.
When asked how to disable the Microsoft synth, the answer was to disable your sound. All of it.
Re: (Score:3)
SystemD turned Linux in to a professional OS and brought it up to modern computing standard.
You're kidding yourself.
I think what you mean is that systemd made Linux look more like Windows, which you already knew and so felt more comfortable with. It really brought nothing to the table except a monolithic* approach which appeals to a certain type of mind.
*Yeah, I know it's modular, but at the same time it isn't. It's a nest of potential failure points for one thing.
Re: (Score:2)
SystemD turned Linux in to a professional OS and brought it up to modern computing standard.
No. It made clueless ElCheapo "system administrators" a reality in the *nix space. I count that as a huge step backwards.
Re: (Score:2)
Why? Except for "I'm not making as much money as I used to, because there's competition instead of scarcity".
Re: (Score:2)
Why? Except for "I'm not making as much money as I used to, because there's competition instead of scarcity".
Hahaha, no. I am not a system administrator. But have a look at, for example, ransomware losses. They are by now large enough to affect the GDP in western countries. Incompetent sysadmins are getting very expensive.
Re: (Score:3)
Unix wasn't a professional OS?
Re: (Score:2)
"SystemD turned Linux in to a professional OS"
You mean SystemD turned Linux in to an Enterprise OS.
Re:Systemd is Awesome! (Score:4, Interesting)
Whether systemd is an improvement or not depends on what you are doing. I have never seen any advantages, and many disadvantages. But I don't do any remote administration.
Re: (Score:2)
Whether systemd is an improvement or not depends on what you are doing. I have never seen any advantages, and many disadvantages. But I don't do any remote administration.
Right you are!
Thing is, RedHat, Suse, Canonical et al are the guys paying the top Linux contributors' salaries. And for those companies, SystemD solves many problems, and solves them well. Cloud is the name of the game, and SystemD is designed with elastic/cattle/cloud Linux instances in mind.
In the year of our lord 2022, your Linux "pet type" server/desktop/laptop is just along for the ride...
Re: (Score:2)
Re: (Score:2)
Unfortunately, it created an isolated "must be systemd to sit in front of the bus" approach to open source development, and it wasted enormous amounts of time doing so. The network stack didn't need replacement. Neither did automounting. Neither did the File System Hierarchy.
Re: (Score:3)
I do plenty of remote admin and thanks to systemD and it's pals, it is now imperative that back door serial access be available (as opposed to just being really damned useful).
Re: (Score:2)
Whether systemd is an improvement or not depends on what you are doing. I have never seen any advantages, and many disadvantages. But I don't do any remote administration.
I do remote administration. I also rip out the systemd crap as early as possible from all my systems or do not even install it when possible. Have yet to find any problems caused by that approach.
Re: (Score:3)
For many chosen is an extreme exaggeration.
For most of us, it was rammed down our unwilling throats. I have used Unix like OSÅ since 1978, and sysv has init worked fine for me since the day sysv was released. and still does on OpenBSD and Devian.
OTOH SystemD continues to fuck with DNS on various versions of Ubuntu on a daily basis.
If Poettering is now in hell, its not a day too soon.
More reliable and easier manage
Re: (Score:2)
Ah, no it is not.
Different is not necessarily better.
For those neckbeards still here...well we have explained why many times before and in this place.
Re:Systemd is Awesome! (Score:5, Interesting)
Systemd made Linux system administration much easier and nicer. Is it perfect? No. Is it 1000 times better than sysv scripts. Yes.
Avahi is awesome too!
PulseAudio I was never thrilled about, has some cool bits, but I'm not sad to see it slowly replaced by PipeWire.
Right you are. Many people who dislike systemD approach it from the desktop user/small server point of view. Not from a more modern view.
Imagine y'all that you do not care for a few a linux desktops, or a few small servers, but thousand of server instances in a cloud (if it makes y'all happier, the cloud is openstack, using KVM). Elastic instances, cattle servers.
Your cloud provider is charging y'all when an instance powers on, so, the sooner the boot finishes, you are saving money, and those savings add on quickly. Ditto for shutting down instances when the spike is over, the sooner a clean shutdown, more savings.
If a server malfunctions, the solution is shoot it down (or stop it for an autopsy) and start another instance (remember, cattle, not pets). The sooner the new instance boots, the sooner the services resume...
Do I really needed to explain why in a cloud world booting fast and shooting down fast is important? Sadly, the answer is yes, and sader still, some people can not wrap their heads arond it...
Them logs are now binary and standarized, instead of human readable and with a specific systax per application... which means that is easier to analize them programaticaly, by machine. Is not like as an admin y'all are reading the logs of thousands of instances... Are you?
Instead of re-inventing the parser for every single program whose logs y'all are interested in, because each program has a different way to write their human readable logs, now there is an unified log format, and no parser involved.
Y'all can now use the brainpower that before was devoted to parsing and reg-exing/YAPing/YACCing human readable logs can now be devoted to program autiomatic responses/actions when the binary logs signal something, this lowers response time, some times to below human reaction times (10's of miliseconds instead of minutes).
If the machine signals something interesting that a human should see, there are Binary-systemD to Verbose log translators available...
All the config info for all SW is now centralized and standarized, and programaticaly accesible without a parser for automation? Again, What's not to like?
Tell me again what's not to like? Oh, sytenD is big? Ok. So is X.11. What? Is new and y'all do not want to learn new things in your old age? ... I think that's PEBCAK, not SystemD
PS: Sorry for all the y'all. English does not have usted and ustedes, so I used y'all in lieu of ustedes.
Re:Systemd is Awesome! (Score:5, Informative)
Yeah it's not like anyone was ever deploying commercial unix or Linux at large scale until systemd came along...
Great a new system to organize and manage events. Why is it concerned with DNS resolution?
The booting argument is bullshit in datacenter. Big iron takes a long time to boot. Who cares if the OS takes another 10 seconds on top of 5 minutes of memory checks?
Re: (Score:2)
Yeah it's not like anyone was ever deploying commercial unix or Linux at large scale until systemd came along...
Great a new system to organize and manage events.
Yes, is true that servers were deployed at scale long before systemD came along. One of my former employers had a Top200 machine (an HP superdome runnig HP-UX). But compared to sysV init scripts, systemD is much betetr for our new cloudy environments.
Why is it concerned with DNS resolution?
NPI
The booting argument is bullshit in datacenter. Big iron takes a long time to boot. Who cares if the OS takes another 10 seconds on top of 5 minutes of memory checks?
Oh, but the more time passes, the less you are booting big iron in your datacenter, you are booting instances on one or more 3rd party clouds... Wrap your head around it ;-P
Re: (Score:2)
Yeah it's not like anyone was ever deploying commercial unix or Linux at large scale until systemd came along...
Great a new system to organize and manage events.
Yes, is true that servers were deployed at scale long before systemD came along. One of my former employers had a Top200 machine (an HP superdome runnig HP-UX). But compared to sysV init scripts, systemD is much betetr for our new cloudy environments.
Why is it concerned with DNS resolution?
NPI
WTF is NPI? My /. does not come with subtitles.
The booting argument is bullshit in datacenter. Big iron takes a long time to boot. Who cares if the OS takes another 10 seconds on top of 5 minutes of memory checks?
Oh, but the more time passes, the less you are booting big iron in your datacenter, you are booting instances on one or more 3rd party clouds... Wrap your head around it ;-P
What do you think those instances run on? Good intentions? Pleasant ideas? Sometimes those BIG MACHINES need to be rebooted.
Re: Systemd is Awesome! (Score:2)
Those instances run on top of hypervisors. And therefore, boot faster than the big iron the hypervisor resides on.
if the big iron needs to be rebooted, the instances will be moved to other hypervisors while thisone takes its sweet time to reboot.
What? You were not aware this is the way 99% of clouds work?
Are you still running your "cloud" workloads on bare metal on someone else' s datacenter? Then, in most cases, you are getting the worst of both worlds
Re: (Score:2)
you are booting instances on one or more 3rd party clouds... Wrap your head around it ;-P
Then you are doing it wrong. VMs were and are a crutch. They exist fundamentally because the operating systems we use don't really provide the level of isolation need, and don't have a sane way to manage library components.
Processes and services ought to be containerized and they ought be able to be migrated from machine to machine running or stopped, and the only thing that should need to 'restart' if there is a problem is the process in question. If Boot times are concern in the world of your public facin
Re: (Score:3)
Datacentres don't run big iron. Boot time matters because you aren't waiting for the motherboard to POST, you are waiting for the VM to start up on an already running hypervisor.
Re: (Score:2)
> Tell me again what's not to like?
Just the other day I found a bug that had been fixed in 240 so I updated my distro to the newest and the problem went away. Yay. People on the first 239 releases of systemd didn't have a workaround - I just got lucky.
Log routing recently got enhanced to do everything I need, finally.
Just the other day I wrote a set of services mounts and cryptsetup generators to mount a file loopback, load the luks key, and mount it. Wants, Before and After work nondeterministically on
Re: (Score:2)
> Tell me again what's not to like?
Just the other day I found a bug that had been fixed in 240 so I updated my distro to the newest and the problem went away. Yay. People on the first 239 releases of systemd didn't have a workaround - I just got lucky.
Log routing recently got enhanced to do everything I need, finally.
Just the other day I wrote a set of services mounts and cryptsetup generators to mount a file loopback, load the luks key, and mount it. Wants, Before and After work nondeterministically on various boots so I have puppet come by and clean up any problems 20 sec later. The delay is totally acceptable for this case but something is still buggy. And it's too complex for a simple task. And don't bother with bug reports on distro versions.
The semantics of ExecKill and ExecKillPost are very subtle and require groking man page sections that require some expertise. Same with the new simple service types which are essential for many scenarios yet had been missing.
It's quite helpful and always improving but let's not pretend it's perfect.
I never pretended is perfect, but warts and all, is much better that SysV scripts in this modern age
Re: (Score:3, Informative)
Except, after years of release, it still hasn't implemented an rc.local that works like SysV init. That has traditionally run last during the boot process (in SysVese: "S99local") --- not whenever the hell SystemD decides to run it (which is never last) which makes it fairly useless for any local startup commands you might need to run at the end of the boot process.
Re: (Score:3)
Re: (Score:3)
I approach from the "I design and maintain projects each with over 1000 servers to support, and have since before Red Hat was a company". Whose work can I rely on to avoid unwelcome surprises? Certainly not Lennart's. They _still_ cannot hash out what to do if someone breaks the symlink for /etc/resolv.conf pinting deep into the systemd network architecture, especially if it's broken by careless use of tools like puppet or chef or ansible.
Re: (Score:3)
The only real annoyance of systemd for me is the network interface names - a server/PC with a single NIC will have that NIC named in a way that's different from other PCs (compare to "eth0") and getting back to using the old names requires a bit of hacking. The new names are also longer and more confusing (ens7s0f1, ens7s0f0 and so on - much works to put into tcpdump than eth0, eth1 and so on).
Everything else seems to get out of the way and let me ignore it. There is the binary log that I never use, because
Re: (Score:2)
Everything else seems to get out of the way and let me ignore it. There is the binary log that I never use, because there are also old-style logs that can be cat'ed and grep'ed and so on.
The efforts to neuter SystemD are the reason distros including it remain useful in the real world.
Re: (Score:3)
Those funky NIC names have a reason for being...it is based on how the BIOS sees those interfaces.
The funky parts, like 'enp' and 'ens', are a programming invention, translating the BIOS view of various system buses & ports into a name.
Barring any hardware changes within the machine...those funky names are NOT SUPPOSED TO CHANGE across reboots.
'eth-whatever' names for NICs can change, except in a 1 NIC machine; "been there & done that". Imagine a multi-port router. Which port is 'eth-whatever' if th
Re: (Score:2)
--And the recommended workaround if you want to keep eth0 and eth1 the same, is to tie them to their MAC addresses. We didn't really need to change the names of the network ports.
Re: (Score:3)
In older versions of Debian, the eth-whatever names got assigned at "random" during install, but the assignments then were tied to the MAC addresses in /etc/udev/rules.d/70-persistent-net.rules file. If I do not like the assignment I can modify it here, including changing the name to something arbitrary (dmz0 etc).
So yeah, NIC names changing each reboot was not a problem at all. If I replaced a NIC, it got a new name and if I moved the same NIC to another slot, it kept its name.
Later versions of Debian stop
Re: (Score:3)
Nothing you mentioned can't be done with scripts. In fact, it has been done with scripts.
Few would have actually objected to systemd if it had been sensibly designed to play nice with others. For example, why not have init invoke it and let it then bring up whatever subsystems it was allowed to handle?
The only reason SystemD hasn't destroyed Linux is that all of the distros have partially neutered it.
Re: (Score:2)
That actually had a reason. sysemd also took over logging, and allows logging the kernel boot process, before initd started.
There were other alternatives to initd, such as upstart and daemontools. Red Hat made an unfortunate choice of allowing Lennart Pottering to create a towering edifice designed to do _everything_. It's taken some time for the sheer size and complexity of the result to show the flaws some of us were concerned about much earlier in its progress, but they've become apparent.
Re: (Score:2)
PS: Sorry for all the y'all. English does not have usted and ustedes, so I used y'all in lieu of ustedes.
You can just say 'you'.
e.g
Y'all can now use the brainpower...
could be written
You can now use the brainpower...
Re: Systemd is Awesome! (Score:2)
Re: (Score:2)
That's the thing. Linux has been captured by corporate interests. It's not longer the regular user friendly OS it used to be. The vast majority of changes being made benefit multi-thousand machine use cases. I don't need or want "Enterprise Linux" and all of the baggage, complexity and code bloat that comes along with it. I need small-medium business Linux.
Re: (Score:2)
Re: (Score:2)
It is not horrible as an init system, but it tries to be much more, which is what I dislike... E.g. systemd-resolved attempts to fix the problematic DNS caching (which likely belongs in nscd) in the completely wrong place (the right place would be in libc / nscd or systemd-resolved own nss module (which exists, but is mostly not used)) breaking DNS tools (by specifying resolved in /etc/resolv.conf and then messing with the requests, which results in things like dig +trace only working with explicitly specif
Re: (Score:2)
PulseAudio I was never thrilled about, has some cool bits, but I'm not sad to see it slowly replaced by PipeWire.
It's so strange that after 30 years or so we still don't have a default sound system that works out of the box more than 99% of the time. In my case it's less than 10%. When I was young I would try and tweak stuff until it worked. Nowadays I just disable sound on the motherboard en further accept the fact that after a while I get crackling sound. Restarting pulseaudio does the trick then. But really, I don't think my friends on windows ever have these issues.
It has always surprised me that pulseaudio and sy
Re: (Score:2)
How do you replace PulseAudio with PipeWire? Surely, they're two different levels in the sound architecture. PipeWire is usually talked of as equivalent to JACKd, a connection system not a server.
Re: (Score:2)
"Easy" is the opposite of "good". It lets people that have no clue do work they do not understand.
Re: (Score:2)
I've always wondered what the point of Pulseaudio was. As a software designer I can appreciate how much more flexible a networkable client/server architecture is, I just wonder who actually needs those capabilities.
Re: (Score:2)
Here's the thing though. Systemd made Linux administration easier for those that didn't already know Linux system administration. Those that had been with it would MUCH rather deal with the easy to edit conf files and start/stop scripts of sysvinit. Yes, I realize that someone, somewhere will be able to say that just because it's always been done that way doesn't make it right. But come on. The mess that systemd is is better? Really? Some nimrod making a candy shell for sysvinit probably did more to make th
Pardeee! (Score:3)
Party time, folks. This has lightened up my night so much. Soooo much. God exists! [lol I'm an atheist]
Don't sleep where you shit. (Score:2, Insightful)
If you can't say something nice (Score:3)
Good news for Linux users... (Score:2)
In my experience, Pulseaudio finally became usable (as in, not unstable buggy garbage) shortly after Poettering moved on to screwing up bigger and better things. Hoping that this will shift systemd development to where it's needed -- rather than blindly attempting to absorb every aspect of the system under the systemd umbrella.
Wow (Score:5, Interesting)
So while I personally dislike both systemd and pulseaudio, and kind of meh on avahi...one does have to recognize that all of these projects did in fact fix/improve a good number of things. These were very heavy lifts for which nobody else had shoulders big enough to push through. His impact and leadership I'm sure will not disappear, in spite of many who hate on the projects mentioned.
I could fully understand SysV; but I clearly recognize the benefits and more modern setup of systemd. I don't particularly trust it, and think it might have gone a bit too far...but it is still better than the alternatives. Similar with pulse...I haven't had actual trouble with pulse for quite a few years, and allows simple things like multiple sound streams at once which was sorely lacking in prior implementations. Avahi is a fine implementation of mdns...I hate mdns...but nothing wrong with Avahi itself. I feel about Avahi like I feel about nice guns...it is a perfect tool for the undesirable job of shooting things.
I hope he lands a nice position somewhere with less controversial projects. Probably good for the sanity. :)
Re: (Score:2, Interesting)
Disagreed. systemd should have never been started, after Dan J. Bernstein lightened up his peculiar licensing SysV init scripts should have been replaced daemontools. Instead, they were replaced by Pottering's work with Linux proprietary wibbley-timey-wimey tools to which his only answers about problems were "I'll tell you later!"
We don't quaint British fiction in our program management system.
Going... (Score:2, Funny)
Re: (Score:3)
So Lennart Pot-Head gets to try out what "Work From Home Full-Time" really means....
Inside scoop: (Score:5, Funny)
So management was finally had it with Poettering neglecting his duties. At the time, it seemed like they were about to get back to normal (after Poettering took a small diversion into a replacement for nano) when he stood up and exclaimed, "Of course! AN EMAIL CLIENT!" and ran out the door. He wasn't fired or anything, he just hasn't been seen for a few months.
Despite no longer being employed, rumor has it that systemd-versenden will be part of the next big release.
Re: (Score:3)
Zawinski's Law [wikipedia.org]
Not so fast (Score:5, Funny)
Don't celebrate too soon. I offer a personal guarantee this is because he felt RedHat was holding him back and he can do more damage with the weapon known as systemd, and let his ego expand more.
Re: (Score:2)
You joke, but as a former Fedora contributor who meet the guy a few times, I can attest such thinking fits him.
Re: (Score:3)
I've seen some videos of him interrupting talks because he didn't like that someone was criticizing systemd or Pulseaudio. In one he takes over the talk from the audience and the speaker is too nervous or inexperienced to stop him, and it derails the entire thing. Google and YouTube refused to return this result or discussions about it, but I had it bookmarked: ([FOSDEM 2013] Eudev) https://www.youtube.com/watch?... [youtube.com]
I've met a few arrogant-as-fuck developers in my time and his conduct there and in other vid
Re: (Score:2)
Where in the video? It's an hour long...
Re: (Score:2)
Where in the video? It's an hour long...
I believe Poettering takes part in the discussion at 44:49 and then again at 59:49. My description of the events would differ from OP.
IBM wised up? (Score:2, Insightful)
Lennart has been using Red Hat to shove some very unwelcome changes down various throats. He had a "big picture" of "immutable Liux", which wasn't immutable. It just meant "everyhting is based on systemd", and he kept breaking the basic configuration tools of even Red Hat's own architecture and like FreeIPA, sssd, DNS, background jobs, and since ansible.com was re-absorbed by Red Hat, ansible configuration tools.
There was no point to systemd as an initialization tool, except that being women into the kernel
ew (Score:4, Interesting)
THINGS, SYSTEMD FORCES YOU TO DO:
systemd is tied to a specific kernel and a specific libc and specific device manager and specific journaling daemon, basically, having systemd means you're locked in to a whole lot of other things
systemd is renowned for locking up during startup and boot when you have network filesystems
systemd hardcodes quite a lot of the booting and shutdown process in C which other systems place in easily editable scripts
systemd in practice requires quite a lot of things: ACLs, PAM, dbus, polkit, these are not hard requirements but without this the above advantages are lost so all distributions enable them at compile time
logind starting to do retarded shit like user sessions and having retarded power management, in theory you can disable logind, but no distribution again does this
systemd is very monolithic and comes in one configuration compared to being able to piece your system together yourself, this sounds bad except that unless you run something like Gentoo or Exherbo you were already submitted to this, while the distribution was able to pick the choice of lower level system components before they switched to systemd, you had no choice in this and just used what your distribution stuffed you with. If your distribution used whatever cron daemon, you used that, if your distribution used consolekit1/2 you used that, if your distribution used acpid/Upower, you used that, you used whatever device manager, syslogger, init and RC your distribution used. While systemd replaces all those things and thus leaves the configuration no longer a choice for the distribution, unless you ran a meta distro that allowed you to choose those things you didn't loose much choice now did you?
Re: (Score:2)
Pretty nice list. I am always gratified to see what I win by not running systemd. Have yet to find anything I lost. Of course I am able to write simple shell-scripts and hence have no problems adding my own boot-scripts. Apparently many wannabe "system administrators" do not have that minimal skill-level and hence welcome a tool that covers for their deficiencies.
Mount (Score:5, Informative)
Offtopic but maybe helpful to somebody that would never expect systemd to do this.... and yet another argument against what systemd stands for.
So I had this raid device, it had some problems and it had to be rebuilt. All done, created a FS on it, it synced all good.
Tried mounting it, mount command exits successfully, i type in df -h... nothing. Partition not mounted, nothing in dmesg... all checks out fine.
After few more attempts to figure out what's wrong, out of disbelief that after 25 years of working exclusively on desktop and on servers running linux, i cannot figure out how to mount a filesystem, i turned to google and run into THIS [stackexchange.com]
Apparently:
"The most likely reason is that file system is mounted, as the mount commands reports, but then systemd thinks it knows better and unmounts it before you can see it."
That is some windows grade stuff. Not allowing root user to do what he wants to do, and instead override him and "UMOUNT" the god damn filesystem with 0 notifications of any kind. This egomaniac Pottering knows better than everybody else, and so does his systemd.
I'm not saying that linux does not need something better than it had before, but damn init system should not arbitrarily decide to umount partitions, resolve dns, and do 200 other things it's doing.
As Linus said few years ago:
"And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why."
Re: (Score:2)
Seriously? Whoever codes shit like that should be banned from root for life!
And again I am happy that I decided to rip this crap out of all my systems when it became the insane default in too many of them.
Re: (Score:3)
--It helps if you think of Systemd as like the Master Control Program from TRON (with all that that implies)
Systemd is both a blessing and a curse (Score:2)
So many distributions use it these days, that the pool of people with knowledge about it is considerable.
However, it's a single point of failure and does an awful lot, all of which can break.
Due to the coding standards of the systemd developers, I wouldn't be amazed if a bunch of really big security holes are in there which, at this point, are in all probability hard to fix because they're structural problems.
I have stopped caring (Score:2)
I do not use systemD, AVAHI or PulseAudio. Crappy system software has no place here. So far the only issues I have ever run into is that I have to rip out this crap. No problems afterwards. I have client, server and cloud installations. Just say no to Poetterix.
Wrong way around (Score:2)
This is Poettering we're talking about. He's the greater party - he didn't leave Redhat - Redhat left him (probably because they couldn't keep up with his awesomeness).
"But Sire, our customers have told us that `systemctl list-files` isn't better than just `ls`"
"Silence! I shall simply replace the customers with better ones!"
Systemd is better than SYSV init, but why does it do DNS resolution and network device management and cron type tasks, and... and... and. Sure, all of those things could do with some lo
He works for Microsoft since a while already (Score:2)
Funny enough, this was also a prediction of the Veteran UNIX Admins at the origin of the Debian fork (Devuan).
systemd... (Score:2)
Yeah, creator of systemd. Wonder if he's moving to M$, who I've always wondered if they paid him to create that crap.
You like it? /etc/
Why a binary logfile, instead of plain text? Space isn't an issue.
Why have multiple levels of calls, rather than what's in
And I've yet to see that stupid binary logfile show me *anything* that told me why a boot failed, or why the system suddenly paniced.
Re: (Score:3, Insightful)
Yea, hopefully they remove his "contributions" next.
Re:Too little, too late (Score:4, Insightful)
They're going to need about 10 Poetterings to undo the spaghetti code he's inflicted upon them. His job is done, he doesn't need RedHat anymore, he has them by the balls. RedHat Linux is now SystemD with Apt-get
Re: (Score:2)
Sorry, but no; apt-get is strictly for distros using
Re: (Score:2)
rpms and dnf
Which as we know stands for Did Not Finish.
Re: (Score:2)
Re: (Score:2)
For decades, those were synonyms.
Re: (Score:2, Informative)
RedHat uses rpms and dnf.
Good point. Which shows how uninformed the anti-systemd arguments get here.
Re: (Score:2)
The repackaging of "yum" as "dnf" has been burdened by unwelcome and unnecessary features learned from apt based operating systems, hasn't it?