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.
Maybe mixing su with systemd is like mixing PCP and acid
Mixing Linux and systemd is like a remote control on a chainsaw: the idea may sound neat for 2 seconds, but then you realize nothing good can come of this.
"It's going to get out of control. It's going to get out of control and we'll be lucky to live through it."
I honestly, seriously sometimes wonder if systemd is Skynet... or, a way for Skynet to 'waken'.
Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. At 2:15am it crashes. No one knows why. The binary log file was corrupted in the process and is unrecoverable. All anyone could remember is a bug listed in the systemd bug tracker talking about su which was classified as WON'T FIX as the developer thought it was a broken concept.
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.
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]
"... 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.
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?
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?
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
Poettering is so very wrong on many things, having a superficial and shallow understanding of why Unix is designed the way it is. He is just a hobbyist, not a hardened sys admin with years of experience. It's almost time to throw popular Linux distros in the garbage can and just go to BSD
Don't confuse a shallow understanding with a desire to change things to suit his needs. I have no doubt he knows in great detail the hows and whys of the Unix world. He does doesn't agree with them and wants to change them.
The only problem I have with him at all is the incompatibility he is introducing along the way. If systemd were optional then we should all be praising it as just another option in the wide and highly customisable world that is Linux. But alas....
Slackware still gives you a reasonable Unix with BSD leanings with all the compatibility you'd expect from a decent Linux. I've not heard of any intention for it to adopt systemd. The day Slackware goes to systemd, is the day I move to FreeBSD for everything.
And still, Linus says JACK SHIT ABOUT THIS POS. That's the part I don't understand _at all_. "Sure, the midwife is slowly killing my only child, but I don't want to say anything; that would be rude."
I for one, would be glad if he'd instead join in programming the next candy crush or angry birds installments. Just think for a moment how much good that would do!
by Anonymous Coward writes:
on Saturday August 29, 2015 @12:53PM (#50416235)
He bring new code, but brings nothing new. That's called re-inventing the wheel, and in Poettering's case, the old wheels worked better and didn't go flat as often, and were easier for average people to fix.
He bring new code, but brings nothing new. That's called re-inventing the wheel, and in Poettering's case, the old wheels worked better and didn't go flat as often, and were easier for average people to fix.
Oh come on, admit it. Unix always had the reputation that the "average person" couldn't do anything with it.
What we're dealing with now is something that neither "average person" nor "master geek" find easy to fix.
What we're dealing with now is something that neither "average person" nor "master geek" find easy to fix.
This is the best summary I've seen of the whole systemd thing. They try to Apple-ize linux but it's half-baked and neither more user-friendly or more reliable than the stuff they replace.
``They try to Apple-ize linux but it's half-baked and neither more user-friendly or more reliable than the stuff they replace.
I've had the same complaint about CUPS -- Apple's screwball replacement for simple lpd -- for years. (And it's not just the Linux version that, IMHO, sucks. I recently had to live through using CUPS in an Apple shop and getting hard copy of anything was a real time sink.) I have a hard time figuring out what problem CUPS was intended to solve. All I can come up with was that it was shiny and new whereas lpd was old (but reliable). For my trusty, rock-solid HP LaserJet, I keep an old Linux distribution running so I can set it up using LPRng. A couple of lines in a text file and -- Voila! -- I have a print queue. Time spent^Wwasted in CUPS' GUI never seemed to make anything work.
Systemd and well, just about anything Poettering touches is more obtuse than what it replaces, has commands that are difficult to remember, require more typing (making them prone to typos), and don't make much sense. Am I looking for the status of "servicename" or am I looking for the status of "servicename.target"? What's the difference? The guy's pushing me back to Slackware. Or, as someone above mentioned, BSD.
Nothing that Poettering is doing now addresses "The problem".
That's any of the usual FUD that are claimed to be problems for actual consumer end users. That is perhaps the single most frustrating aspect of his current nonsense. He's insisted on making sweeping changes to the parts that don't need fixing and are the least relevant to "the problem".
In the long run, he's not going to be satisfied until he's created his own OS, kernel and all because he calls anything he didn't write a "broken concept," whatever that is, and does his best to shove his version down everybody's throat. And, since his version is far more complex, far more pervasive and much, much harder to use or maintain, the community suffers. I do wish he would get off the pot and start developing the One True (Pottering) kernel so that the rest of the world can go back to ignoring him.
In the long run, he's not going to be satisfied until he's created his own OS, kernel and all because he calls anything he didn't write a "broken concept," whatever that is
How about we get someone to fork the Systemd that distros have adopted and start working on fixing it,
paring it down, and removing unneeded functionality into separate optional related projects?
I tried a bunch of them a few years ago. I found that FreeBSD was the best one, even though it doesn't come with a GUI by default, and so you have to install it afterwards. (Seems kind of ridiculous to me, but that's how they package it for some reason.) I don't know if they've changed the documentation since then, but note that you don't have to compile X11 and your window manager, as there is a system that can install pre-compiled packages that they don't bother to mention until after they tell you how
I do plan to give it another go some day when I have a lot more time to spend learning it
I'm sorry to break this to you, but it is very unlikely that sometime in the future you'll have more free time than now, at least not before retirement.
That post is dated, but significant parts of OS X's kernel constructs are *BSD derived. Please note while the link is focused on FreeBSD code in OS X, that isn't the only BSD code Apple drew from.
by Anonymous Coward writes:
on Saturday August 29, 2015 @11:55AM (#50415925)
Just like he considers exit statuses, stderr, and syslog "broken concepts." That is why systemd supports them so poorly. He just doesn't understand why those things are critical. An su system that doesn't properly log to syslog is a serious security problem.
su is not only for root. it has a dual purpose: switch user or super user. Sometimes you might have to run a command as another user. So if you need to login as Gary you $su gary and type in Gary's password.
Su is not a broken concept; it's a long well-established fundamental of BSD Unix/Linux.
You're pretty much making an argument to tradition here. The correct thing to do would be to counter his claims:
what "su" is supposed to do is very unclear. On one hand it's supposed to open a new session and change a number of execution context parameters (`uid`, `gid`, `env`,...), and on the other it's supposed to inherit a lot concepts from the originating session (`tty`, `cgroup`, `audit`,...). Since this is so weakly defined it's a really weird mix&match of old and new paramters.
I would like more detail from him on why and how it's broken, and how his replacement is truly different from "su -" but since it doesn't appear to be mutually exclusive with the use of "su" or "su -", other than typical reactionary hate I don't see what the problem is.
ok, I just spent my morning researching the problem, and why the feature got built, starting from here [github.com] (linked to in the article). Essentially, the timeline goes like this:
1) On Linux, the su command uses PAM to manage logins (that's probably ok).
2) systemd wrote their own version of PAM (because containers)
3) Unlike normal su, the systemd-pam su doesn't transfer over all environment variables, which led to:
4) A bug filed by a user, that the XDG_RUNTIME_DIR variable wasn't being maintained when su was run.
5) Lennart said that's because su is confusing, and he wouldn't fix it.
6) The user asked for a feature request to be added to machinectl, that would retain that environment variable
7) Lennart said, "sure, no problem." (Which shows why systemd is gaining usage, when people want a feature, he adds it)
It's important to note that there isn't a conspiracy here to destroy su. The process would more accurately be called "design by feature accretion," which doesn't really make you feel better, but it's not malice.
Sometimes su is confusing, I've been using it for many years, yet it has never been clear to me which variables get passed over to the root session ans which do not, to the point that sometimes I do ssh root@localhost instead of su, just to be sure.
If you're having that kind of difficulty, just change to a CLI console and log in as root. If you need to check something in a different window, you can always go back to X (or Wayland, if appropriate) for a moment.
yet it has never been clear to me which variables get passed over to the root session ans which do not
All exported environment variables, just as if you started a spawned a shell binary with the same user.
Except on systems that implemented PAM su, on these systems, PAM modules might be used to change
the values of ulimits or some other environment variables, or clear some.
They might do this because it is the desire of whoever configured the system to assign additional characteristics to
certain inte
As one highly suspect of systemd, I find it really interesting that your audit of systemd has led to posts in which you are compelled to argue that systemd isn't wrong.
Lennart said that it wasn't clear what su should do in this situation. Actually, it's quite clear. su - must construct an environment containing only TERM, HOME, SHELL, USER, LOGNAME, and PATH. That's been the case since UNIX SVR4, at the latest.
Yeah, that's true, I missed the - in the bug report. I don't know what that user was complaining about.
other than typical reactionary hate I don't see what the problem is.
You now have your init daemon providing an alternate attack pathway for gaining privileged access to the system, in a way that completely circumvents the well-established (and monitored by most IDSs) auditing capabilities of the platform.
Su is not a broken concept; it's a long well-established fundamental of BSD Unix/Linux.
You're pretty much making an argument to tradition here. The correct thing to do would be to counter his claims:
what "su" is supposed to do is very unclear. On one hand it's supposed to open a new session and change a number of execution context parameters (`uid`, `gid`, `env`,...), and on the other it's supposed to inherit a lot concepts from the originating session (`tty`, `cgroup`, `audit`,...). Since this is so weakly defined it's a really weird mix&match of old and new paramters.
I would like more detail from him on why and how it's broken, and how his replacement is truly different from "su -" but since it doesn't appear to be mutually exclusive with the use of "su" or "su -", other than typical reactionary hate I don't see what the problem is.
99% of the execution context changes and things that stay the same that su cause, happen in any subshell. Does Poettering dislike subshells as well? Does he dislike shell scripts?
Su is not a broken concept; it's a long well-established fundamental of BSD Unix/Linux.
You're pretty much making an argument to tradition here. The correct thing to do would be to counter his claims:
what "su" is supposed to do is very unclear. On one hand it's supposed to open a new session and change a number of execution context parameters (`uid`, `gid`, `env`,...), and on the other it's supposed to inherit a lot concepts from the originating session (`tty`, `cgroup`, `audit`,...). Since this is so weakly defined it's a really weird mix&match of old and new paramters.
I would like more detail from him on why and how it's broken, and how his replacement is truly different from "su -" but since it doesn't appear to be mutually exclusive with the use of "su" or "su -", other than typical reactionary hate I don't see what the problem is.
Also ask him why the conceptually correctly implemented replacement for simple little su has to be machinectl shell which is like... 16 kilometers long.
I am confused. Can I call "su root" and get a full root shell? Are they just hijacking "su [blank name] which goes to root by default? Most peaple think su means super user when in fact it means switch user. I might be safe becouse I always use the name even when it is root.
I'm so happy I don't have any systemd shit on this machine, seriously what is that man thinking, nothing is broken with su, in fact it's alot more secure than some systems use of sudo. Pottering, listen to me, nothing is broken, if you want that shit on your machine, you have it, just leave the rest of us the fuck alone.
I feel better after that:D
Apparently, however, Poettering was out having a few beers when the "modular OS" concept was being discussed. So he doesn't know how to create "shit on his machine". Instead, he has to integrate it so tightly into the OS that the shit must be on everyone's machine, whether they like it or not.
Which would be bad enough to begin with. Whoever gave him the right to make his shit the essential system component of the Red Hat OS without consulting anyone has a lot to answer for.
For the case where the entire OS becomes one big module.
"Modular" to the rest of us means that if we want binary logging, we install the binary logging package, if we want legacy logging, we install the legacy logging package, if we want some other custom logging, we can install that instead. There may be a default/preferred package, but distros can be built using alernative packages without tearing half the OS apart.
It doesn't mean we go the Windows route: 'Oh, you want to "uninstall IE"? Well, we'll let y
> Deciding what a full login comprises is the shell's responsibility, not your init system's job.
systemd is not an init system. It's a service manager. Mischaracterization makes your opinions seem ignorant.
systemd is bad for trying to force utilities to be rewritten into a unified application layer, for no other reason. Error prone initiative, to create a new class of problems (where coordination preemption occurs, is just moved around). There's no misuse of a utility role, in this case.
Which manage system commands controlling system daemons, using daemon configuration files much like those of SysV init scripts but with more modular activation and re-starting when they crash.
It's an init script system with better service monitoring.
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.
If Lennart Poeterring is complaining about something being broken, then maybe he should start with systemd instead of assuming he is smarter than the decades of unix people who came before?
by Anonymous Coward writes:
on Saturday August 29, 2015 @12:27PM (#50416069)
If you want a FULL shell Oh I dont know 'su bash' usually works pretty fng good...
It does if you are fine to only get root privilege, without FULL environment of root. But if you would have to make sure you have FULL root environment, first discarding anything you had in calling user and then executing root users environment (/etc/profile etc.) you better use "su - bash" or "sudo -i". Compare what you get both ways "su bash" vs "su - bash" with runnint "set" and "env" commands, please.
Failing to have FULL root environment, can have security implications (umask, wrong path, wrong path order,...) which may or may not be critical depending what system you are operating and to whom. Also some commands may fail or misbehave just because of path differences etc.
Above is trivial information and should be clear without further explanation anyone running *nix systems for someone else as part of job ie. work professionally on the field. Incase you don't, it's still useful information you should learn about sysadmin of the platform you happen to use.
> In short: I think chroot is plenty good for security
Check man chroot. The authors of chroot say it's useless for security. Perhaps you think you know more than they do,and more than security professionals like myself do. Let's find out.
> you get a shell in one of my chroot's used for security, then..... ur uid and gid are not going to be 0. Good luck telling the kernel to try and get you out. There aren't going to be any/dev,/proc, or other special filesystems
Gonna be kind of tthough to have a ahell without a tty, aka/dev/*tty* So yeah, you need/dev. Can't launch a process, including/bin/ls, without/proc, so you're going to need proc. Have a look in/proc/1. You'll see a very interesting symlink there.
> mounted noexec
Noexec is basically a suggestion, not an enforement mechanism . Just run ld/path/to/executable. ld is the loader/lilinker for elf binaries. Without ld,you can't run bash, or ls. With ld, noexec is ignored.
My company does IT security for banks. Meaning we show the banks how they can be hacked. When I say chroot is not a security control, I'm not guessing.
Wasn't the point that chroot is as good, and not better, as the normal Unix permission/groups security feature? So, basically, chroot doesn't and isn't designed to add any additional security besides the normal Unix permission/groups security.
This means using a chroot is not less secure, but it is not more secure either. If you have proper permissions configured on your system, you are no safer inside a chroot than relying on system permissions to keep a user in check.
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: (Score:3, Funny)
Maybe mixing su with systemd is like mixing PCP and acid
Re:Hang on a minute... (Score:5, Funny)
Maybe mixing su with systemd is like mixing PCP and acid
Sulfuric or hydrochloric?
Re: (Score:2)
Citric.
Re:Hang on a minute... (Score:4, Funny)
I don't know that. Aaaaaaaargh!
Re: (Score:2)
Maybe mixing su with systemd is like mixing PCP and acid
Mixing Linux and systemd is like a remote control on a chainsaw: the idea may sound neat for 2 seconds, but then you realize nothing good can come of this.
"It's going to get out of control. It's going to get out of control and we'll be lucky to live through it."
Re: (Score:2)
"going to" ???
That boat has already sailed, some time in the past year.
Re:Hang on a minute... (Score:5, Insightful)
I honestly, seriously sometimes wonder if systemd is Skynet... or, a way for Skynet to 'waken'.
And if Pottering isn't just a T3 from the future or some such, working to prepared the existing internet for it to awaken.
I mean, really -- honestly, he has essentially re-written the entire userland, as one package, maintained by one. More kernel patches are next.
Re:Hang on a minute... (Score:5, Funny)
I honestly, seriously sometimes wonder if systemd is Skynet... or, a way for Skynet to 'waken'.
Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. At 2:15am it crashes.
No one knows why. The binary log file was corrupted in the process and is unrecoverable. All anyone could remember is a bug listed in the systemd bug tracker talking about su which was classified as WON'T FIX as the developer thought it was a broken concept.
Re: Hang on a minute... (Score:2)
Re: (Score:2)
That's Systemd/Linux. Linux is only the kernel you know.
Give it enough time, systemd will replace the kernel, too.
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:2)
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)
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: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: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)
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?
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)
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)
Maybe Poettering meant sudo, cause I can give you a list there.
Re:Bullshit (Score:4, Interesting)
Poettering is so very wrong on many things, having a superficial and shallow understanding of why Unix is designed the way it is. He is just a hobbyist, not a hardened sys admin with years of experience. It's almost time to throw popular Linux distros in the garbage can and just go to BSD
Re: (Score:2)
...or you could just switch to one of the many Linux distros that haven't been contaminated with systemd. Gentoo, perhaps?
Re: (Score:2)
Woot, Slackware.
I upgraded from 10.something to 14.1 a while back and I'm loving the changes.
Re: (Score:2)
Don't confuse a shallow understanding with a desire to change things to suit his needs. I have no doubt he knows in great detail the hows and whys of the Unix world. He does doesn't agree with them and wants to change them.
The only problem I have with him at all is the incompatibility he is introducing along the way. If systemd were optional then we should all be praising it as just another option in the wide and highly customisable world that is Linux. But alas....
Re: (Score:2)
Slackware still gives you a reasonable Unix with BSD leanings with all the compatibility you'd expect from a decent Linux. I've not heard of any intention for it to adopt systemd. The day Slackware goes to systemd, is the day I move to FreeBSD for everything.
Re: (Score:2)
Change for change's sake (Score:2, Insightful)
"Delivering" the wrong thing is not an asset, it's a liability.
And that's why Poettering is a liability to the Linux community.
Re: (Score:2)
I wouldn't be glad if he died, but I would be glad if he disappeared.
Re: (Score:2)
Re:Bullshit (Score:4, Insightful)
There are plenty of programmers who can spew out hundreds of lines of crap code in a day.
The problem is that others then have to spend years fixing it.
It's even worse when you let the code-spewers actually design the system, because you'll never be allowed to go back and redo things right.
Re:Bullshit (Score:5, Insightful)
He bring new code, but brings nothing new. That's called re-inventing the wheel, and in Poettering's case, the old wheels worked better and didn't go flat as often, and were easier for average people to fix.
Re: (Score:2)
He bring new code, but brings nothing new. That's called re-inventing the wheel, and in Poettering's case, the old wheels worked better and didn't go flat as often, and were easier for average people to fix.
Oh come on, admit it. Unix always had the reputation that the "average person" couldn't do anything with it.
What we're dealing with now is something that neither "average person" nor "master geek" find easy to fix.
Re: (Score:3)
What we're dealing with now is something that neither "average person" nor "master geek" find easy to fix.
This is the best summary I've seen of the whole systemd thing. They try to Apple-ize linux but it's half-baked and neither more user-friendly or more reliable than the stuff they replace.
Re:Bullshit (Score:4, Insightful)
I've had the same complaint about CUPS -- Apple's screwball replacement for simple lpd -- for years. (And it's not just the Linux version that, IMHO, sucks. I recently had to live through using CUPS in an Apple shop and getting hard copy of anything was a real time sink.) I have a hard time figuring out what problem CUPS was intended to solve. All I can come up with was that it was shiny and new whereas lpd was old (but reliable). For my trusty, rock-solid HP LaserJet, I keep an old Linux distribution running so I can set it up using LPRng. A couple of lines in a text file and -- Voila! -- I have a print queue. Time spent^Wwasted in CUPS' GUI never seemed to make anything work.
Systemd and well, just about anything Poettering touches is more obtuse than what it replaces, has commands that are difficult to remember, require more typing (making them prone to typos), and don't make much sense. Am I looking for the status of "servicename" or am I looking for the status of "servicename.target"? What's the difference? The guy's pushing me back to Slackware. Or, as someone above mentioned, BSD.
Re: (Score:2)
Nothing that Poettering is doing now addresses "The problem".
That's any of the usual FUD that are claimed to be problems for actual consumer end users. That is perhaps the single most frustrating aspect of his current nonsense. He's insisted on making sweeping changes to the parts that don't need fixing and are the least relevant to "the problem".
Re: (Score:2)
And unlike your guy from Germany, the guy I know didn't lose (and that's how his name ends).
The way this should end (Score:4, Insightful)
In the long run, he's not going to be satisfied until he's created his own OS, kernel and all because he calls anything he didn't write a "broken concept," whatever that is, and does his best to shove his version down everybody's throat. And, since his version is far more complex, far more pervasive and much, much harder to use or maintain, the community suffers. I do wish he would get off the pot and start developing the One True (Pottering) kernel so that the rest of the world can go back to ignoring him.
Re: (Score:2)
In the long run, he's not going to be satisfied until he's created his own OS, kernel and all because he calls anything he didn't write a "broken concept," whatever that is
How about we get someone to fork the Systemd that distros have adopted and start working on fixing it, paring it down, and removing unneeded functionality into separate optional related projects?
Re: (Score:2)
PC BSD [pcbsd.org]
Re: (Score:3, Interesting)
I tried a bunch of them a few years ago. I found that FreeBSD was the best one, even though it doesn't come with a GUI by default, and so you have to install it afterwards. (Seems kind of ridiculous to me, but that's how they package it for some reason.) I don't know if they've changed the documentation since then, but note that you don't have to compile X11 and your window manager, as there is a system that can install pre-compiled packages that they don't bother to mention until after they tell you how
Re: (Score:2)
I do plan to give it another go some day when I have a lot more time to spend learning it
I'm sorry to break this to you, but it is very unlikely that sometime in the future you'll have more free time than now, at least not before retirement.
Re: (Score:3)
But the are distros based on FreeBSD such as PC-BSD that have the UI and other desktop features and apps canned and ready to go
Re: (Score:2)
MacOS, which is FreeBSD based.
Re: (Score:2)
Re: (Score:2)
Um, no.
https://lists.freebsd.org/pipe... [freebsd.org]
That post is dated, but significant parts of OS X's kernel constructs are *BSD derived. Please note while the link is focused on FreeBSD code in OS X, that isn't the only BSD code Apple drew from.
Re: (Score:2)
Re: (Score:2)
doesn't even require right-click context menus.
Weird. Which OS 'requires' right-click context menus? OS X, just like Windows and Linux, has functionality that may be reached by either
OS X has context menus, just like everyone else. I truly don't understand what you might mean.
Re:Bullshit (Score:5, Informative)
Just like he considers exit statuses, stderr, and syslog "broken concepts." That is why systemd supports them so poorly. He just doesn't understand why those things are critical. An su system that doesn't properly log to syslog is a serious security problem.
Re:Bullshit (Score:5, Insightful)
su is not only for root. it has a dual purpose: switch user or super user. Sometimes you might have to run a command as another user. So if you need to login as Gary you $su gary and type in Gary's password.
Re:Bullshit (Score:4, Insightful)
You're pretty much making an argument to tradition here. The correct thing to do would be to counter his claims:
I would like more detail from him on why and how it's broken, and how his replacement is truly different from "su -" but since it doesn't appear to be mutually exclusive with the use of "su" or "su -", other than typical reactionary hate I don't see what the problem is.
Re:Bullshit (Score:5, Interesting)
1) On Linux, the su command uses PAM to manage logins (that's probably ok).
2) systemd wrote their own version of PAM (because containers)
3) Unlike normal su, the systemd-pam su doesn't transfer over all environment variables, which led to:
4) A bug filed by a user, that the XDG_RUNTIME_DIR variable wasn't being maintained when su was run.
5) Lennart said that's because su is confusing, and he wouldn't fix it.
6) The user asked for a feature request to be added to machinectl, that would retain that environment variable
7) Lennart said, "sure, no problem." (Which shows why systemd is gaining usage, when people want a feature, he adds it)
It's important to note that there isn't a conspiracy here to destroy su. The process would more accurately be called "design by feature accretion," which doesn't really make you feel better, but it's not malice.
Re:Bullshit (Score:5, Insightful)
The problem is at step 5): su isn't confusing. It's a lame excuse to get your way.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
yet it has never been clear to me which variables get passed over to the root session ans which do not
All exported environment variables, just as if you started a spawned a shell binary with the same user.
Except on systems that implemented PAM su, on these systems, PAM modules might be used to change the values of ulimits or some other environment variables, or clear some.
They might do this because it is the desire of whoever configured the system to assign additional characteristics to certain inte
Re: (Score:3)
Re: (Score:2)
Wow...that is .. fightning. I dont' understand why I'm using this command incorrectly and abusing it, so could you add a crappy workaround.
I do think systemv init scripts needed to replaced and I'm for full-process control...but systemd is a horrible implemention of that.
Re: (Score:3)
I've found another way how to avoid the problem: no PAM at my Slackware machine. See? The rest of the list is, all of a sudden, pointless.
Re: (Score:2)
As one highly suspect of systemd, I find it really interesting that your audit of systemd has led to posts in which you are compelled to argue that systemd isn't wrong.
Re: (Score:2)
Re: (Score:2)
Lennart said that it wasn't clear what su should do in this situation. Actually, it's quite clear. su - must construct an environment containing only TERM, HOME, SHELL, USER, LOGNAME, and PATH. That's been the case since UNIX SVR4, at the latest.
Yeah, that's true, I missed the - in the bug report. I don't know what that user was complaining about.
Re:Bullshit (Score:5, Insightful)
You now have your init daemon providing an alternate attack pathway for gaining privileged access to the system, in a way that completely circumvents the well-established (and monitored by most IDSs) auditing capabilities of the platform.
I'd call that a problem, but YMMV.
Re: (Score:2)
Re: (Score:2)
pkexec goes through pam just like su. So no, it will not do the exact same thing in providing an alternate attack vector.
Re: (Score:2)
Re: (Score:2)
You're pretty much making an argument to tradition here. The correct thing to do would be to counter his claims:
I would like more detail from him on why and how it's broken, and how his replacement is truly different from "su -" but since it doesn't appear to be mutually exclusive with the use of "su" or "su -", other than typical reactionary hate I don't see what the problem is.
99% of the execution context changes and things that stay the same that su cause, happen in any subshell. Does Poettering dislike subshells as well? Does he dislike shell scripts?
Re: (Score:2)
You're pretty much making an argument to tradition here. The correct thing to do would be to counter his claims:
I would like more detail from him on why and how it's broken, and how his replacement is truly different from "su -" but since it doesn't appear to be mutually exclusive with the use of "su" or "su -", other than typical reactionary hate I don't see what the problem is.
Also ask him why the conceptually correctly implemented replacement for simple little su has to be machinectl shell which is like... 16 kilometers long.
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:3)
Apparently, however, Poettering was out having a few beers when the "modular OS" concept was being discussed. So he doesn't know how to create "shit on his machine". Instead, he has to integrate it so tightly into the OS that the shit must be on everyone's machine, whether they like it or not.
Which would be bad enough to begin with. Whoever gave him the right to make his shit the essential system component of the Red Hat OS without consulting anyone has a lot to answer for.
Re: (Score:2)
Re: (Score:3)
For the case where the entire OS becomes one big module.
"Modular" to the rest of us means that if we want binary logging, we install the binary logging package, if we want legacy logging, we install the legacy logging package, if we want some other custom logging, we can install that instead. There may be a default/preferred package, but distros can be built using alernative packages without tearing half the OS apart.
It doesn't mean we go the Windows route: 'Oh, you want to "uninstall IE"? Well, we'll let y
Re:Bullshit (Score:5, Insightful)
Deciding what a full login comprises is the shell's responsibility, not your init system's job.
And certainly not the job of one Poettering, who still has not produced one piece of good software in his life.
Re: (Score:3)
> Deciding what a full login comprises is the shell's responsibility, not your init system's job.
systemd is not an init system. It's a service manager. Mischaracterization makes your opinions seem ignorant.
systemd is bad for trying to force utilities to be rewritten into a unified application layer, for no other reason. Error prone initiative, to create a new class of problems (where coordination preemption occurs, is just moved around). There's no misuse of a utility role, in this case.
Re: (Score:2)
systemd is not an init system. It's a service manager.
You are right, but the reason it got adopted by distros like Debian is because it makes it easy to write init scripts.
Re: (Score:2)
Which manage system commands controlling system daemons, using daemon configuration files much like those of SysV init scripts but with more modular activation and re-starting when they crash.
It's an init script system with better service monitoring.
Of course "su" *IS* a broken concept !! (Score:2, Insightful)
Lennart Poettering's long story short: "`su` is really a broken concept
Of course to Lennart Poettering "su" is broken !!
Long story short --- To that egotistical son of a bitch, anything that is not made by him MUST BE 'broken'
'nuff said!
Re: (Score:2)
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.
Or sudo -s
Re: (Score:3)
If Lennart Poeterring is complaining about something being broken, then maybe he should start with systemd instead of assuming he is smarter than the decades of unix people who came before?
Re:Bullshit (Score:5, Interesting)
If you want a FULL shell
Oh I dont know 'su bash' usually works pretty fng good...
It does if you are fine to only get root privilege, without FULL environment of root. But if you would have to make sure you have FULL root environment, first discarding anything you had in calling user and then executing root users environment (/etc/profile etc.) you better use "su - bash" or "sudo -i". Compare what you get both ways "su bash" vs "su - bash" with runnint "set" and "env" commands, please.
Failing to have FULL root environment, can have security implications (umask, wrong path, wrong path order, ...) which may or may not be critical depending what system you are operating and to whom. Also some commands may fail or misbehave just because of path differences etc.
Above is trivial information and should be clear without further explanation anyone running *nix systems for someone else as part of job ie. work professionally on the field. Incase you don't, it's still useful information you should learn about sysadmin of the platform you happen to use.
Re: (Score:2)
Ok. Do you want someone to be able to break out of a chroot or jail, using [alternativetosu] ? Because you might not want that...
Re: (Score:3, Informative)
You can ALWAYS "break out" of chroot.
If you get a shell in one of my chroot's used for security, then.....
Re: (Score:2)
read the man page (Score:5, Informative)
> In short: I think chroot is plenty good for security
Check man chroot. The authors of chroot say it's useless for security. ,and more than security professionals like myself do. Let's find out.
Perhaps you think you know more than they do
> you get a shell in one of my chroot's used for security, then..... /dev, /proc, or other special filesystems
ur uid and gid are not going to be 0. Good luck telling the kernel to try and get you out.
There aren't going to be any
Gonna be kind of tthough to have a ahell without a tty, aka /dev/*tty* /dev. Can't launch a process, including /bin/ls, without /proc, so you're going to need proc. Have a look in /proc/1. You'll see a very interesting symlink there.
So yeah, you need
> mounted noexec
Noexec is basically a suggestion, not an enforement mechanism . Just run ld /path/to/executable. ld is the loader/lilinker for elf binaries. Without ld ,you can't run bash, or ls. With ld, noexec is ignored.
My company does IT security for banks. Meaning we show the banks how they can be hacked. When I say chroot is not a security control, I'm not guessing.
Re: (Score:3)
Wasn't the point that chroot is as good, and not better, as the normal Unix permission/groups security feature? So, basically, chroot doesn't and isn't designed to add any additional security besides the normal Unix permission/groups security.
This means using a chroot is not less secure, but it is not more secure either. If you have proper permissions configured on your system, you are no safer inside a chroot than relying on system permissions to keep a user in check.
https://securityblog.redhat.co... [redhat.com]
Re: (Score:2)