Lennart Poettering's long story short: "`su` is really a broken concept
Declaring established concepts as broken so you can "fix" them.
Su is not a broken concept; it's a long well-established fundamental of BSD Unix/Linux. You need a shell with some commands to be run with additional privileges in the original user's context.
If you need a full login you invoke 'su -' or 'sudo bash -'
Deciding what a full login comprises is the shell's responsibility, not your init system's job.
I've had a job now for about 10 years where a large fraction of the time I wear a software engineer's hat. Looking back now, I can point to a lot of design decisions in the software I work on that made me go "WTF?" when I first saw them as a young'un, but after having to contend with them for a good number of years, and thinking about how I would do them differently, I've come to the conclusion that the original WTF may be ugly and could use some polish, but the decisionmaking that produced it was fundamentally sound.
The more I hear about LP and systemd, the more it screams out that this guy just hasn't worked with Unix and Linux long enough to understand what it's used for and why it's built the way it is. His pronouncements just sound to me like an echo of my younger, stupider, self (and I just turned 30), and I can't take any of his output seriously. I really hope a critical mass of people are of the same mind with me and this guy can be made to redirect his energies somewhere where it doesn't fuck it up for the rest of us.
its the other way around. we used to have small, simple programs that did not take whole systems to build and gigs of mem to run in. things were easier to understand and concepts were not overdone a hundred times, just because 'reasons'.
now, we have software that can't be debugged well, people who are current software eng's have no attention span to fix bugs or do proper design, older guys who DO remember 'why' are no longer being hired and we can't seem to stand on our giants' shoulders anymore. again, because 'reasons'.
1) The only thing that systemd might do faster is boot. Since Linux servers are not booted that often, that is a trifling advantage, at best. Certainly not worth breaking everything that works.
2) Systemd does not always boot faster. Only under certain circumstances.
3) More resource intensive generally means slower on the same hardware. Systemd may boot faster, but it runs slower.
4) There are ways to improve boot speeds without breaking everything that works.
That's not what I am suggesting. Maybe the analogy was imperfect.
Systemd is like cars compared to horse carriages in early 1900s. They were a not-so-good alternative to the established method. Horse-based transportation was a mature solution which reached its limits, and cars at the time were a worse alternative in most ways.
I say, give it time. See if it would grow into something better. Flinging poo at systemd is like yelling "get a horse!" when seeing a car, back in the 1900s. True at the moment, but in ti
Flinging poo at systemd is like yelling "get a horse!" when seeing a car, back in the 1900s. True at the moment, but in time proven to be shortsighted.
Do you have credible proof that it will be proven to be shortsighted? If not, you might want to say the following, much less exciting statement:
"Flinging poo at systemd might be like yelling "get a horse!" when seeing a car"
Or do you believe in proof by analogy? By this proof methodology, you could have proven in 1944 that there won't be any nuclear bomb explosion next year, because a nuclear bomb is like the proof of Fermat's last theorem - it hasn't been built yet and won't be by next year.
I feel ya there. I'm trying to stay away from the concept of "Get off my lawn", and push more towards education. It is no surprise that a vast majority of the modern investments in technology are "web-based". A lot of people that are coming out of schools now had their first introduction to computing and networks over the "web", and they learned backwards.
There were those of us who saw the evolution of the web "forwards". Who remembers installing the Trumpet Winsock TCP/IP stack on Windows? Because it didn't
Actually, with all the rave around Arduinos, Raspberrys & Co. quite a few people are "learning forwards" again.
Here's a serial TCP/IP 'stack' for example: http://playground.arduino.cc/C... [arduino.cc]
Who remembers installing the Trumpet Winsock TCP/IP stack on Windows?.
Oh god, brrrr... Those were the bad old days. The move from IPX to IP was a nightmare. Now, however, it looks like IPv6 will have a lot of the simplicity that we lost in that transition. The good old days may be returning.
"... Where the youngin's come in and rip up everything..."
Get off my lawn and learn to spell.
I've run an IT *company* now for well over 15 years. Herr P is a bit outspoken but in general I agree with his approach. Some of their design decisions are a bit wacky to my mind but I'm an old fogey in that regard. However I am happy to report that my large herds of Linux boxes are much happier with systemd than they were with an unholy mix of sysvinit, openrc, upstart and other stuff.
However I am happy to report that my large herds of Linux boxes are much happier
When I run *NIX, it is not for the happiness of the machines, but for the happiness of the users and owners. That is a critical difference between *NIX and non-*NIX.
He's got a bit of a track record of half-finished shit rushed to release that is a pain in the arse to deal with for at least a couple of years after it was supposed to be done. For some reason his stuff finally works a couple of years after he's moved on from it to the next big thing - I'm not sure if he's moved into bugfix instead of rapid change mode on his old projects or if somebody else is cleaning up his mess. Even after years of fixes NetworkManager and PulseAudio do not come up to the standard of the
You're arguing against the person but you're not saying anything about the project. Tell us what's wrong with systemd, regardless of who wrote it, not what's wrong with the author.
The article gives an example of a major thing wrong with this project. My post is about it not being the first time. My post is based on an assumption that whoever reads it has read the article summary above.
You can't really separate the two. If the two things dbIII (701233) mentioned go tits up it's an inconvenience; you use ifconfig and the like, you do without sound until you reboot.
However if something as major as your init system breaks you could well end up with an unbootable system. Having someone who's known to be a bit of a cowboy fiddling with that doesn't sound prudent to me.
Yes. And the biggest problem is that he seems to be very intelligent, hard-working, talented, and... megalomaniac. I suppose he thinks he's on par with Linus, even though he has maybe 5% of his insight and experience.
From his blog he thinks he could have done a far better job on the kernel than Linus, so that gives the impression that he thinks he is well beyond Linus. Maybe it will drive him to actually live up to his impression of himself after a few years so we should just put it down as annoying instead of a problem since it's still possible to use *nix without using his project.
As much as I dislike what Poettering does, many things with Unix and Linux are built the way they are because either it was something supposed to be a temporary hack but stayed this way by the sheer force of inertia or because it made sense decades ago, doesn't make sense anymore, but is considered a holy cow because "we've always done it this way".
Name two and their consequences. And by consequences I don't mean one time annoyances like "it's cumbersome to write the init scripts" but actual things like "this language forces me to use double the memory or twice the cpu" and explain how systemd fixes it without introducing a worse one.
You haven't been paying attention these last 20 years when every unix vendor has replaced SysV init with something else.
Writing init scripts is not a one time annoyance, at least not for distro maintainers. They are also not portable between distributions, as systemd unit files are. SysV init is also literally the dumbest form of init, where the init process has no information about dependencies, and cannot react sensibly to any changes in system state. Another sticking point involved the inability of the system to track processes accurately, which resulted in a number of kernel-level features over the years, of which cgroups are merely the most recent. Yes, it's fairly rare to have things go wrong, but pidfiles are unquestionably a bad hack.
Init is a misnomer. It was supposed to be the method by which your system changed states, but it was never very good at this, so people are used to thinking of it only as handling a few rare circumstances. The problem systemd solves is how to get the computer from state A to state B reliably, and guarantee that the services it manages are started properly. Startup and shutdown are special cases of this problem. It is built on kernel-level features that allow it to track processes accurately (and incidentally also track resource useage).
Systemd is the result of a number of (IMO) obvious choices. Cgroups exist, therefore it makes sense to write a service management tool to take advantage of them. As long as you're writing a service management tool, you should probably write in dependency resolution. Handling startup and shutdown is another logical choice. Also, since 95% of init script contents are common tasks, it makes sense to abstract out that stuff into a common C-based library. At this point it is relevant to note that, cgroups aside, OpenRC does this exact same thing.
Writing scripts is part of UNIX, and systemd coexists with them pretty happily. However, rewriting scripts into more flexible C libraries is also part of the UNIX tradition. What's so hot about these scripts, besides that you're more comfortable working with them?
Upstart was much more limited in goals and utility than systemd, and it took (arguably) the wrong approach to dependency resolution. It was an evolutionary upgrade with many of the same problems as SysV init. Rightly or wrongly, systemd is using the functionality provided by cgroups to implement a more-or-less complete plumbing layer for Linux services. You could interpret that as codifying, standardizing, and integrating existing components and features, or you could interpret it as absorbing functionality
The problem is that systemd is light years ahead of pulse audio (LP's other main project) in terms of not breaking my system, but it shares a number of qualities from my perspective: it fixes problems that I don't have at the cost of throwing away things that I value. The quality of software he produces has improved quite a bit in the last 10 years, but his arrogance and inability to listen to the needs of his users has not changed much at all.
The thing is, I *really* don't care if these projects exist. M
Keep in mind that Red Hat also pushed network manager (the thing that completely breaks network setups) as well and I don't think LP had a hand in that
NetworkManager was Lennart's project from the beginning, but it may have been handed off to someone else now.
Well put. The notion that *nix is a structure built by many people, with many bricks (and many eyes on each) is being violated.
Its not about using larger bricks, its about using one brick?
How will that brick be patched? How many eyes are on that brick? How does the community build and grow Systemd?
Its time for a split,probably going back to volkerding's work, or BSD and rethinking init and networking and.. sure. sudo as well.
Who has the leverage to ask why more is being done by fewer and fewer?
This reasoning also extends, IMO, to new programming languages as well. A lot of my friends hop on the bandwagon every time something like C#, or Scala, or Node(Ok, it's not technically a language is it?), or Go pops out.. "OMG a new language, so much better than C++, so much more productive I'll be!".. I don't honestly believe in most cases that the language is what's going to make you productive, but your ability to think and just do the work. And obviously C++ has some things that are pretty WTF-y but us
The road to ruin is always in good repair, and the travellers pay the
expense of it.
-- Josh Billings
Bullshit (Score:5, Insightful)
Lennart Poettering's long story short: "`su` is really a broken concept
Declaring established concepts as broken so you can "fix" them.
Su is not a broken concept; it's a long well-established fundamental of BSD Unix/Linux. You need a shell with some commands to be run with additional privileges in the original user's context.
If you need a full login you invoke 'su -' or 'sudo bash -'
Deciding what a full login comprises is the shell's responsibility, not your init system's job.
Hang on a minute... (Score:5, Insightful)
Well, let me explain some of the problems that I've had with su.
Oh wait. I've never had problems with su. Ever. What is up with this???
Re:Hang on a minute... (Score:5, Interesting)
The more I hear about LP and systemd, the more it screams out that this guy just hasn't worked with Unix and Linux long enough to understand what it's used for and why it's built the way it is. His pronouncements just sound to me like an echo of my younger, stupider, self (and I just turned 30), and I can't take any of his output seriously. I really hope a critical mass of people are of the same mind with me and this guy can be made to redirect his energies somewhere where it doesn't fuck it up for the rest of us.
Re:Hang on a minute... (Score:5, Insightful)
Re:Hang on a minute... (Score:5, Insightful)
its the other way around. we used to have small, simple programs that did not take whole systems to build and gigs of mem to run in. things were easier to understand and concepts were not overdone a hundred times, just because 'reasons'.
now, we have software that can't be debugged well, people who are current software eng's have no attention span to fix bugs or do proper design, older guys who DO remember 'why' are no longer being hired and we can't seem to stand on our giants' shoulders anymore. again, because 'reasons'.
Re: (Score:1)
Yeah. Much like walking being a much simpler way to get anywhere, compared to driving.
Re: (Score:2)
Re: (Score:1)
Nothing except that sometimes it's not fast enough.
Re: (Score:2)
Are you trying to imply that systemd is faster? (Score:2)
1) The only thing that systemd might do faster is boot. Since Linux servers are not booted that often, that is a trifling advantage, at best. Certainly not worth breaking everything that works.
2) Systemd does not always boot faster. Only under certain circumstances.
3) More resource intensive generally means slower on the same hardware. Systemd may boot faster, but it runs slower.
4) There are ways to improve boot speeds without breaking everything that works.
Re: (Score:2)
That's not what I am suggesting.
Maybe the analogy was imperfect.
Systemd is like cars compared to horse carriages in early 1900s. They were a not-so-good alternative to the established method.
Horse-based transportation was a mature solution which reached its limits, and cars at the time were a worse alternative in most ways.
I say, give it time. See if it would grow into something better. Flinging poo at systemd is like yelling "get a horse!" when seeing a car, back in the 1900s. True at the moment, but in ti
Re: (Score:2)
You mean it's the sensible thing to do?
When systemd reaches the level of, say, a 1930s car then get back to me.
Re: (Score:2)
Flinging poo at systemd is like yelling "get a horse!" when seeing a car, back in the 1900s. True at the moment, but in time proven to be shortsighted.
Do you have credible proof that it will be proven to be shortsighted? If not, you might want to say the following, much less exciting statement:
"Flinging poo at systemd might be like yelling "get a horse!" when seeing a car"
Or do you believe in proof by analogy? By this proof methodology, you could have proven in 1944 that there won't be any nuclear bomb explosion next year, because a nuclear bomb is like the proof of Fermat's last theorem - it hasn't been built yet and won't be by next year.
Re: (Score:2)
Re: (Score:2)
Apparently some people enjoy driving from the living room to the WC when they need to take a leak.
Re: (Score:2)
I don't have a driver's license.
And you of course missed the point.
Re: (Score:2)
This might sound strange, but I sure wish the younger generations would get over themselves and "grow up".
No, I think this more has to do with a combination of hubris and Red Hat capturing a number of open source utility projects.
Re: (Score:2)
This might sound strange, but I sure wish the younger generations would get over themselves and "grow up".
No, I think this more has to do with a combination of hubris and Red Hat capturing a number of open source utility projects.
Yes.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It is no surprise that a vast majority of the modern investments in technology are "web-based". A lot of people that are coming out of schools now had their first introduction to computing and networks over the "web", and they learned backwards.
There were those of us who saw the evolution of the web "forwards". Who remembers installing the Trumpet Winsock TCP/IP stack on Windows? Because it didn't
Re: (Score:2)
Here's a serial TCP/IP 'stack' for example: http://playground.arduino.cc/C... [arduino.cc]
Re: (Score:1)
Who remembers installing the Trumpet Winsock TCP/IP stack on Windows?.
Oh god, brrrr... Those were the bad old days. The move from IPX to IP was a nightmare. Now, however, it looks like IPv6 will have a lot of the simplicity that we lost in that transition. The good old days may be returning.
Re: (Score:2, Interesting)
"... Where the youngin's come in and rip up everything ..."
Get off my lawn and learn to spell.
I've run an IT *company* now for well over 15 years. Herr P is a bit outspoken but in general I agree with his approach. Some of their design decisions are a bit wacky to my mind but I'm an old fogey in that regard. However I am happy to report that my large herds of Linux boxes are much happier with systemd than they were with an unholy mix of sysvinit, openrc, upstart and other stuff.
Putting the imperative in
Re: (Score:2)
However I am happy to report that my large herds of Linux boxes are much happier
When I run *NIX, it is not for the happiness of the machines, but for the happiness of the users and owners. That is a critical difference between *NIX and non-*NIX.
Re: (Score:2)
He has a track record of such things (Score:2)
For some reason his stuff finally works a couple of years after he's moved on from it to the next big thing - I'm not sure if he's moved into bugfix instead of rapid change mode on his old projects or if somebody else is cleaning up his mess.
Even after years of fixes NetworkManager and PulseAudio do not come up to the standard of the
Re: (Score:2)
Look above at the summary for your answer (Score:2)
My post is about it not being the first time.
My post is based on an assumption that whoever reads it has read the article summary above.
Re: (Score:2)
You can't really separate the two. If the two things dbIII (701233) mentioned go tits up it's an inconvenience; you use ifconfig and the like, you do without sound until you reboot.
However if something as major as your init system breaks you could well end up with an unbootable system. Having someone who's known to be a bit of a cowboy fiddling with that doesn't sound prudent to me.
Re: (Score:1)
So true. LP will go down in history as the man that fucked up Linux for the rest of us.
Re: (Score:3)
Yes. And the biggest problem is that he seems to be very intelligent, hard-working, talented, and ... megalomaniac.
I suppose he thinks he's on par with Linus, even though he has maybe 5% of his insight and experience.
Re: (Score:2)
From his blog he thinks he could have done a far better job on the kernel than Linus, so that gives the impression that he thinks he is well beyond Linus. Maybe it will drive him to actually live up to his impression of himself after a few years so we should just put it down as annoying instead of a problem since it's still possible to use *nix without using his project.
Re: (Score:2)
If that's the case then why doesn't he just fuck off and build his own OS from the ground up? Should only take him a week.
Re: (Score:2)
GNU Lennarx. Yes, please!
Re: (Score:2)
As much as I dislike what Poettering does, many things with Unix and Linux are built the way they are because either it was something supposed to be a temporary hack but stayed this way by the sheer force of inertia or because it made sense decades ago, doesn't make sense anymore, but is considered a holy cow because "we've always done it this way".
Re: Hang on a minute... (Score:3)
Process Tracking (Score:4, Interesting)
You haven't been paying attention these last 20 years when every unix vendor has replaced SysV init with something else.
Writing init scripts is not a one time annoyance, at least not for distro maintainers. They are also not portable between distributions, as systemd unit files are. SysV init is also literally the dumbest form of init, where the init process has no information about dependencies, and cannot react sensibly to any changes in system state. Another sticking point involved the inability of the system to track processes accurately, which resulted in a number of kernel-level features over the years, of which cgroups are merely the most recent. Yes, it's fairly rare to have things go wrong, but pidfiles are unquestionably a bad hack.
Init is a misnomer. It was supposed to be the method by which your system changed states, but it was never very good at this, so people are used to thinking of it only as handling a few rare circumstances. The problem systemd solves is how to get the computer from state A to state B reliably, and guarantee that the services it manages are started properly. Startup and shutdown are special cases of this problem. It is built on kernel-level features that allow it to track processes accurately (and incidentally also track resource useage).
Systemd is the result of a number of (IMO) obvious choices. Cgroups exist, therefore it makes sense to write a service management tool to take advantage of them. As long as you're writing a service management tool, you should probably write in dependency resolution. Handling startup and shutdown is another logical choice. Also, since 95% of init script contents are common tasks, it makes sense to abstract out that stuff into a common C-based library. At this point it is relevant to note that, cgroups aside, OpenRC does this exact same thing.
Writing scripts is part of UNIX, and systemd coexists with them pretty happily. However, rewriting scripts into more flexible C libraries is also part of the UNIX tradition. What's so hot about these scripts, besides that you're more comfortable working with them?
Upstart and Systemd (Score:2)
Upstart was much more limited in goals and utility than systemd, and it took (arguably) the wrong approach to dependency resolution. It was an evolutionary upgrade with many of the same problems as SysV init. Rightly or wrongly, systemd is using the functionality provided by cgroups to implement a more-or-less complete plumbing layer for Linux services. You could interpret that as codifying, standardizing, and integrating existing components and features, or you could interpret it as absorbing functionality
Re: (Score:2, Insightful)
The problem is that systemd is light years ahead of pulse audio (LP's other main project) in terms of not breaking my system, but it shares a number of qualities from my perspective: it fixes problems that I don't have at the cost of throwing away things that I value. The quality of software he produces has improved quite a bit in the last 10 years, but his arrogance and inability to listen to the needs of his users has not changed much at all.
The thing is, I *really* don't care if these projects exist. M
MOD PARENT UP! (Score:2)
Well said.
I think we should get rid of Gnome, and work on MATE, or something like it.
Re: (Score:2)
NetworkManager was Lennart's project from the beginning, but it may have been handed off to someone else now.
Re:Hang on a minute... More done by fewer and fewe (Score:3)
Re: (Score:2)
This reasoning also extends, IMO, to new programming languages as well. A lot of my friends hop on the bandwagon every time something like C#, or Scala, or Node(Ok, it's not technically a language is it?), or Go pops out.. "OMG a new language, so much better than C++, so much more productive I'll be!".. I don't honestly believe in most cases that the language is what's going to make you productive, but your ability to think and just do the work. And obviously C++ has some things that are pretty WTF-y but us