Systemd wins top gong for 'lamest vendor' in Pwnie security awards The annual Pwnie Awards for serious security screw-ups saw hardly anyone collecting their prize at this year's ceremony in Las Vegas. That's not surprising: government officials, US spy agencies, and software makers aren’t usually in the mood to acknowledge their failures. The Pwnies give spray-painted pony statues to those …
> Red Hat will abandon systemd when the fork has enough traction.
Doubtful. You gotta understand what systemd actually is; the idea is to build a piece of software that will rival the kernel in terms of importance to Linux. This way Red Hat's puppet Lenny Poettering becomes as influential as Linus.
The hat? Genuine bacofoil that.
Distrowatch's search page allows you to search distributions by criteria. It's got an init field where you choose the inits you're interested in... and "not systemd".
No other init has a "not" field, only systemd, for some reason.
Unfortunately it lists 177 active distributions with systemd and 94 active distributions without systemd. That's how much this disease has spread.
To be fair you need an existing admin to create a user starting with a number (which most don't because back in the day it wasn't allowed) then they need to create a Unit file with that user specified as owner, then the user needs to get root anyway to get write access to that Unit file to do anything.
Or alternatively a poorly put-together package might include such a unit file and then you end up with a service running as root when you weren't expecting it.
Most people agree that it's a difficult security hole to exploit easily, but that doesn't detract from the fact that it it a security hole. The issue people have is the systemd team's response to this bug report (mainly your man Poettering here) and to other bug reports that people submit. The response is essentially "I refuse to acknowledge this is a bug - this is an issue with everyone else."
In a world where everyone else is scrambling to fix years of sub-optimal security in code (both open-source and closed-source), the systemd team seem to be adopting a policy of doesn't-apply-to-us, which is bizarre when the code they're writing is such a fundamental part of the operating system.
And here's how the Systemd devs will acknowledge it:
Criticism flows off them like water off a duck's arse.
Yep. just shows that the anti-systemd trolls don't understand that systemd was not awarded this "lame" award for being hacked, it was awarded for a difference on opinion with which the presenters of the award disagreed. It would have been different if they had been able to create a hack. Hell, who'd expect the antis' to work that out anyway.
The apparent hate that many pure FLOSS fans have for RedHat will only be amplified after this.
How dare a company rake in a Billion $$$$ from releasing FREE Software?
You can prise my CentOS 6.9 (no Systemd) systems from my cold dead hands. Until it is either dropped entirely or given a severe pruning (why does the init system need to do DNS lookups?, shakes head in bewilderment) I won't be using it for a long time.
IMHO, Pottering found the wrong solution to a problem that for 99% of us did not exist.
I've no problem with any company making money from releasing FLOSS who, after all, are the largest contributors. In fact, a commercial vendor is more likely to respond to users than an independent developer who has nothing to lose or gain from the responses to their work.
In Red Hat's case, however, I can't avoid the thought that, as things have worked out, they are now (AFAIK) the only resort for those who need a commercial vendor-supported distro and want it to be systemd-free. Is that irony or a clever ploy?
"Is that irony or a clever ploy?"
@Dr Syntax: I'm assuming that you are referring to RHEL 6. I suspect that it is just the releases working their way through the Gantt chart. My hypothesis will be disproved if and when a special 'extended life' subscription (at a premium price) appears for RHEL 6 near 2019. A further disproof would be a Fedora release coming with a choice of init (cold day in hades &c).
Coat: Centos 7 actually works fine for this clueless end user desktop operative, so off out.
"Until it is either dropped entirely or given a severe pruning (why does the init system need to do DNS lookups?, shakes head in bewilderment)"
resolved can be turned off pretty easily. Not that anyone here is looking for solutions or is at all interested in learning how systemd actually operates.
"(why does the init system need to do DNS lookups?, shakes head in bewilderment) " - well, if you knew anything about it instead of replying on the ignorant posts of trolls, you'd know that the "init" part does not do DNS look ups. Any binary with a "systemd-" prefix is part of the project and completely optional.
"Any binary with a "systemd-" prefix is part of the project and completely optional."
Agreed. However upstream programmers may well be tempted to support only the systemd-* components as it makes their job easier, and packagers for various distributions may be tempted to include hard dependencies on the systemd-* components because they assume their presence.
So in effect the random walk that is Linux development (lots of projects all producing code that depends on the state of other projects also producing code with many feedback loops) may collapse into a stable mono-culture. Consequences to be witnessed. Possibly detrimental. Bit early to tell.
"So in effect the random walk that is Linux development (lots of projects all producing code that depends on the state of other projects also producing code with many feedback loops) may collapse into a stable mono-culture."
For 25 years, there's been non-stop freakout about Linux allowing "TOO MANY CHOICES!!!"
Now, there's non-stop freakout about Linux possibly "collapsing into a stable mono-culture".
Meanwhile, anyone who knows their stuff just keeps working and ignores the noise.
"Now, there's non-stop freakout about Linux possibly "collapsing into a stable mono-culture""
Can't speak for others, I'm not actually freaking out as such, just trying to understand the dynamics at a whole system level.
FOSS has been pumping out lines of code for - what - 30 odd years without much in the way of an overall plan (bazaar c.f. cathedral &c) except building something that keeps working. Complex systems with strong linkage between elements will tend to exhibit a limited range of behaviours.
https://en.wikipedia.org/wiki/Complex_system
A dose of mono-culture might be for the best - we'll have to see.
Coat: Remember I just consume this stuff.
"Agreed. However upstream programmers may well be tempted to support only the systemd-* components as it makes their job easier, and packagers for various distributions may be tempted to include hard dependencies on the systemd-* components because they assume their presence."
Ah, I think I understand now. The problem with systemd is its too good at what it does.
>The problem with systemd is its too good at what it does.
Tangling up dependencies so more and more FOSS has a dependency on the Linux kernel? Finally driving a stake through POSIX? I know lets shove as much functionality as we can in the one process that has to run or we get a kernel panic. What could go wrong?
"Ah, I think I understand now. The problem with systemd is its too good at what it does."
@dbannon: excellent reply, but of course it does not have to be 'too good' just 'good enough' and easier/less work than what came before. That is why software generally needs faster processors/more memory/ big libraries in layers &c over time. And it works.
Redhat must ensure that systemd-* is fit for purpose and that bugs are responded to rapidly as they have bet their business on it until around 2028(?) (RHEL 8 support EOL based on past releases). I imagine that people with more of a mindset around responsive bug-fixing and quality will take over the maintenance from those who 'move fast and break things' (to mis-quote)
Coat: usual disclaimer - clueless end user
The problem with systemd is its too good at what it does.
Where "at what it does" == "cause security holes"+"emulate the worst aspects of the Borg"+"lead developers obtuse blindness to any form of critisism"+"be an answer to a question that very, very few were asking"+"further taking linux in the direction of Windows"..
There is a reason why I no longer use linux for the majority of my VMs - FreeBSD all the way. Anything that "has" to be linux (Ubiquiti controller for example" has now been rebuilt under Devuan.
I've worked with a couple devs who were confident they could never err, contrary to all evidence. It is grating, much more than an average screamer or blowhard - to the point I've considered quitting when it looked like we might be on the same project, and in one case made clear to management that customers would have to be the first to work with a feature if they couldn't assign someone else to look at the bugs. (They chose not to assign anyone else, hence anon - and I apologize if you were one of the customers.)
Anyway reading Pottering's comments reminded me of those old battles. I feel sorry for the folks who have to work with him and yet are trying to get a good product out - best of luck to you!
Systemd isn't an init system, the goal is to replace most/all Linux OS userspace with Systemd. This is no accident, one of the designers is quoted as saying as much, the actual website escapes me at the moment. The other problem is that Lennart Poettering is an ignorant prick with an over inflated sense of his own technical abilities.
Was it something like this: systemd and Where We Want to Take the Basic Linux Userspace in 2016?
Last year DNS/DNSSEC, networking, containers, and control groups were on his list. Obviously he's not going to stop there, it seems his idea is to replace everything that isn't the kernel or GNU command line utilities with systemd but he's not even particularly good at it, he's just stitching together some kind of Frankenstein's monster.
Form the link you provide: "Basically, if something is a reasonably low-level userspace component, highly generically useful, required in most applications of the OS, would benefit from tighter integration in the OS layer, and has a clear future in tomorrow’s technology, then it might be a job for systemd."
Fuck. Me. Sideways.
"...and has a clear future in tomorrow’s technology..."
@GrumpenKraut and all
A cultural studies Masters' thesis topic could well be the use of phrases such as 'modern' and 'tomorrow's technology' by Dr(?) Poettering and his colleagues. The framing is outrageous - it is less than half a lifetime since we were writing programs on punched cards.
I'm sure that RedHat will make it all work because they have a $2.5 x 10^9 business that depends on it all working. It will be interesting to see how things go when the bulk of servers depend on operating systems that use the technology. I predict a far more responsive approach to (properly written) bug reports by people with a practical mind set.
The epic 0wnage award was split between North Korea and Russia for launching the WannaCry ransomware contagion and masterminding the Shadow Brokers, respectively.
Frankly, this spounds like a sponsored politicial message and rather out of place.
This site is infested with this kind of rubbish. NK struggles with basic agricultural problems but somehow managed to do a steal NSA's backdoors and engineer the wannacry attack... This is a false flag operation that, thankfully, nobody took too seriously.
So a nation that is know for its isolation and lack of advanced technology or even basic technology suddenly steals an NSA backdoor and uses it to launch wannacry attack? We're talking about a place where the few TV's they have are still CRT, where people are struggling with basic agricultural issues. Who donesn't see this is a false flag attempt gone puff? It's ridiculous now. But we are talking about the empire trying to start a nuclear war with NK so it's not funny-ridiculous. Please stop spreading this kind of rubbish. We all know you need to sell page prints but you ought to have some degree of dignity.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
