Version 256 of systemd boasts '42% less Unix philosophy' The latest version of the systemd init system is out, with the openly confrontational tag line: "Available soon in your nearest distro, now with 42 percent less Unix philosophy." As Lennart Poettering's announcement points out, this is the first version of systemd whose version number is a nine-bit value. Penguins surround …
Argggh!
So instead of a very easy to implement, low footprint kernel feature to allow a root-write-only bit in the file attributes to cause an exe to run as root we have to have the whole policykit architecture in place to perform a task requiring elevated privs.
The policykit documentation is as awful and ambiguous as the systemd stuff. Then, which version of policykit is this machine running? Where are the configuration files kept for this particular build of policykit? How do I find that out?
While it can get complicated, configuration for sudo can exist in as little as a single /etc/sudo.conf file which can allow specific users or groups to run specific tools with specific constraints. Good luck demonstrating to yourself that your systemd & policykit configuration is providing exactly the security permissions you want.
The sources for SUID in the kernel & for the sudo exe have undergone extensive review and are very stable. Systemd & policykit seem as stable as The Persistence Of Memory and as easy to grok as something from Hieronymus Bosch.
In terms of numbers, the vast majority of Linux instances are in very small devices - routers & other network comms, home-entertainment/industrial/agri-mech/marine/automotive displays & control units etc. - which often can't and in any case should not need unlimited amounts of CPU, RAM and peristent memory. (Otherwise they'd be too power hungry, expensive or unreliable.) To enable improvements in the 'run it all as root' policy in a lot of this stuff the last thing we need is to mandate systemd & policykit for priv-elev.
Indeed, sudo used properly (before Ubuntu popularised sudo everything as an alternative to root login) allows giving access to exact commands and per user control of those. It's actually fine grained, and with some kind of network based authentication you can actually just revoke someone's ability to do things by (for example) removing the relevant group membership from their account. Whereas, to use an old school example, given a printer user login that some people have a password to, revoking one person's access requires changing the password and redistributing the new one to all remaining authorised users, and either a specific password account or a group permission based approach they can still do everything, while sudo says only this exact command as a particular user.
https://www.freedesktop.org/software/systemd/man/devel/run0.html
Authentication takes place via polkit, thus isolating the authentication prompt from the terminal (if possible).
So, not in the vast majority of times when I'm running an ssh session on a remote system then?
And I'm still looking in vain on that page, or linked ones such as https://www.freedesktop.org/software/systemd/man/devel/systemd-run.html for some example of how escalation privileges could be configured. As you say, probably somewhere in polkit (obviously documentation is not linked), which the only end user way to engage with is generally all or nothing "grant administrator access".
I would love to go *BSD - the showstopper for me is that Matlab1 is essential for my work, and unfortunately does not support any of the BSDs. Ironically, this is the same kind of obstacle that many specialised Windows users (e.g., in graphics or audio) complain about with regard to switching to Linux.
1GNU Octave, an open-source almost-clone of Matlab, is supported on several BSDs, but is not sufficiently compatible with Matlab (nor, it must be said, does it have the scope and polish) to cut it in my line of work (computational neurocience).
I would love to go *BSD - the showstopper for me is that Matlab1 is essential for my work, and unfortunately does not support any of the BSDs
I haven't used it so can't comment on its effectiveness but among the FreeBSD ports I find
---- /usr/ports/math/matlab-installer:
Version: 0.2
This port installs the prerequisites for Mathworks (r) Matlab for Linux and an installer script (matlab-installer), which automates the somewhat tricky process of installing Linux Matlab.
Installing Matlab requires Matlab installation media and a license file and installation key from Mathworks, Inc.
----
This uses FreeBSD Linux emulation (which can even run Linux code faster than Linux at times). The web site behind it is https://acadix.biz/matlab-installer.php.
Alternatively, if faced with code that really has to have Linux underneath, I'll run it in a bhyve virtual machine and display it on my normal FBSD X desktop (although Wayland will probably bugger that up soon).
Thanks for that, but I suspect it is very out of date; googling around a bit suggests that installing current(ish) versions of Matlab on FreeBSD is highly problematic, if possible at all, to the extent that the community seems to have given up on it. (The latest successful reports of a functioning Matlab installation on FreeBSD appear to be circa 2014.)
This post has been deleted by its author
Yeah, but since Poettering now works for Microsoft, wouldn't doing that also run the risk of destroying the parts of the company responsible for developing Windows 11 and all those other MS products we know and...
On second thoughts, you pilot the ship and I'll get the nuke ready! ;-)
Tess: My Linux PC sudo command is not recognized!
Anna: My Windows won’t let me perform admin tasks unless I use sudo!
Both: WHAT THE DARN HECK* IS GOING ON???!!!!
* rated G for general audiences. Wholesome language may not be realistic depiction of a typical IT environment.
We've gone full circle!
I suspect that sudo (the Linux command) will end up like its poweroff and shutdown contemporaries – just a symlink to some systemd binary, and most users won't even notice that it's gone unless they actually need some advanced feature.
On second thoughts, you pilot the ship and I'll get the nuke ready! ;-)
I refer the honourable gentlebeings to the warning fable contained in the tome called "Dark Star"..
(https://en.wikipedia.org/wiki/Dark_Star_(film) - yes, yes, it's the fillum version but PikiWedia doesn't appear to have an entry for the book)
I don't recall a lack of objection to anything in systemd. It's quite possibly the most objected-upon thing in Linux these days. It's just that it either falls on deaf ears at kernel/distribution HQ, or insufficiently few people outside of these groups care about it to make a difference.
Sometimes all that needs to happen for tyranny to prevail is good men doing nothing. (Readers need determine whether systemd is tyrannical or not. I'm indifferent myself.)
What happens is up to us.
Either enough people give time and/or money to the alternatives, or we are screwed.
Example: I just donated $10 to MX Linux. It's not much, but it is probably more than I should afford right now.
The is the OS I am using to put up this post.
I can't program, but this is what I can do. I need to try and do more.
We all do.
Good Luck
I like the UNIX philosophy.
In the case of suid programs, that wasn't even Unix but the concept came from Multics (and Atlas had something similar I believe). Good old 60s tech, much of which was too ambitious for the hardware of the time to support efficiently and a lot of which has been forgotten now the hardware is powerful enough.
Not being au fait with things systemd (PCLinuxOS user here) does it have a Registry yet?
Of course it does. It's the crapware utility(?) that has everything.
If not, it'll be in the next release. Alongside a handful of RDBMS, compiler suites and libraries for every programming language, so-called office automation tools, web browsers, window managers, Windows emulators, AI chatbots, etc, etc.
One day soon systemd will provide VMs for running yet more instances of Linux and systemd. That might well have happened already.
No registry yet, but it does have its own knockoff of Windows' 'event viewer' binary log database (journald)....
Give Pottering enough time and SystemD will copy all of the microsoftisims from Windows Server in one way or another....
Kind of like his other RedHat compatriot who thought that what Linux really needed was.... .NET! (deIcaza & Mono)...
With sudo you don't need to give anyone root password because their own password suffices if they're in the sudoers file. That means hat if their password has been obtained by somebody else - possibly because they reused it elsewhere - then there's no additional layer of protection. None. Whatever access they have through sudo is now open to that third person.
The only reason you should have to give out the root password is that you need to give someone access that can only be done by root. The original solution was that if someone's job was printer administration that was done by user lpadmin and they'd su to lpadmin using lpadmin's password, not root's. And you still needed a separate password to become root.
It was a poor solution to an already solved problem.
With sudo you don't need to give anyone root password because their own password suffices if they're in the sudoers file. That means hat if their password has been obtained by somebody else - possibly because they reused it elsewhere - then there's no additional layer of protection. None. Whatever access they have through sudo is now open to that third person.
Which is also true if they've been careless enough to lose the root password. That's a more likely scenario for someone who only occasionally has to use it, and so puts it on a post-it or similar. They are hopefully less likely to do that with their own password, which they use frequently enough to remember it.
The big advantage of tools like sudo is the audit trail. If someone logs in as root using the root password and commits mayhem, you have no idea who it was.
If, on the other hand, someone uses sudo to become root & cause trouble, you know who did it.
In any case, Poettering seems more to be referring to the concept of SUID, and the related setuid() function, which isn't the same thing as sudo. It's more often used to allow specific binaries to run with elevated privileges. He seems to be suggesting that instead of giving the binary itself the privilege (via what is essentially a filesystem permissions bit hack interpreted by the kernel), the user would "ask" systemd to run it with privilege. It's just more systemd empire-building, removing control from the kernel & putting it in systemd. As noted elsewhere, we're rapidly heading toward systemdOS, any day now he'll reinvent containers.
As noted elsewhere, we're rapidly heading toward systemdOSI've been saying that for years; it's a great relief to finally see that others also are recognising it for what it is.
any day now he'll reinvent containers.As others here have pointed out, apparently he already has. Oh well, if nothing else, perhaps it will serve as confirmation so more people will start to see what's going on.
Was being able to keep the root password locked up in KeePass or similar, and have people do admin tasks without having to know it.
Which also means that if someone quits or gets fired, who did admin tasks but didn't have access to the root PW... You wouldn't have to change it....
"The perfect place would be the subantarctic Bouvet Island"
The Baron of the Bouvet Islands might object very strongly to that (not least because he has more affinity with Tux than you might think).
I'm sure there must be some other suitable rocky outcrop that could be used instead…
Much as I absolutely despise pulseaudio and think systemd does seem to have some feature creep problems, I unfortunately have to admit that systemd does handle running systems much better than any of the other systems we have had. And my first thought to replacing sudo is "Why would systemd be better?" and then I think about it and realize that having a message protocol to init that is already running as root rather than suid binaries just might actually be safer. Damn. He might have a point. I definitely don't want to go back to before systemd anymore. Process monitoring and launching really should be done together. It is the sensible way to do it.
This is the problem with the philosophy of many Linux users - "If something that should work well, doesn't, instead of fixing it, let's write a completely new one'
Witness OSS polluted with pulse audio, and then Alsa be ame the new toy.
How about devfs/udev?
Then of course, systemd itself, boosted by misguided views like yours.
Translation: Poettering knows he's never been- and never will be- popular among the Linux community, and has decided to go all-in on the smug troll route instead, doubling down on the entirely legitimate reasons he's disliked there and attempting to mock them for it.
[Author here]
> has decided to go all-in on the smug troll route instead
Do please note, this description is *not* from Lennart P himself.
It was from Luca Boccassi:
https://social.vivaldi.net/deck/@bluca@fosstodon.org/112600235620499886
https://github.com/bluca
https://salsa.debian.org/bluca
Thank you for the correction- though, to be fair, it was an understandable misinterpretation given that the quote in the article immediately preceded reference to "Lennart Poettering's announcement" itself.
Regardless, that sort of smug, triumphalist gloat coming from *anyone* in a high-ranking position within the project doesn't reflect well upon it or its attitude towards the community.
Sorry, Liam, but in this case you probably then shouldn't have worded the article in such a way as to imply that the source of the quote was Poettering himself (not everyone follows links, and even then, even if the URI did sort of hint that the site referred to wasn't Poettering himself, the way that you reported it did very much imply that the tag line was actually his and that the quote did originate from him).
That's the sort of misleading writing you would expect from a disreputable sensationalist trashy red-top tabloid… Oh, as you were…[1] >;-)
[1] Sadly now with 42% less vulture-snark, 99.9% less Playmobil, and 100% more alternate [sic][2] spelling…
[2] alternative, dammit, alternate means something entirely different, wig-wag, wig-wag, wig-wag…
The latest systemd abortion may well have "42% less Unix philosophy" (whatever that means). It *deliberately* never had any of that. However systemd retains 100% of Poettering's unbelievably shitty design. As if that appalling bloatware ever had any sort of design.
By writing a better competitor that people WANT to use instead of having it forced on them.
The curmudgeons would say let's go back to SysV but then they'd probably also be happy making everyone sit in caves whilst rubbing two sticks together. Upstart was only a small improvement over SysV and that's not enough to make people take notice. A true future competitor must have some key advantage in order to make waves, and it needs to be significant waves to aler the course of SystemD's sea-swell.
Yes, I'm a curmudgeon and refute your comparison.
Maybe there is a better solution than Sys V but I found Upstart already a step in the wrong direction because it made a start-up problem impossible to diagnose. Possibly there was somewhere where some debugging could have been inserted but if so it was sufficiently obfuscated that I never found it. Clarity is a virtue to be valued.
systemd definitely makes debugging startup problems so much easier. It actually logs all output of all the services you run. No other init system ever did that. And it monitors the things it runs. Not sure any of the others did that either. So yes any actual competitor has a very high bar to beat to have a chance.
In my experience, systemD creates startup problems with networking (it seems to have an absurd idea of when an interface is up), and hallucinates circular dependencies when there aren't any really. To this day I'm still having to start some stock services in stock Linuxes with ordinary configurations via cron, waiting a minute after boot because systemD is incapable of correctly launching them.
It's problems like this that are infuriating. With broken init scripts, it's easy to fix them. With broken systemD, it's a matter of persuading Poettering or similar that there's a problem (which is impossible) to get a fix merged.
There's no doubt a ton of not heavily analysed code behind that sudo replacement... The systemD project has screwed this up previously, needlessly replacing mature source code bases with their own reimplementation that's come with security ****ups.
It's not popular, and nor are some things that depend on it (Gnome) necessarily popular either. The real issue is that there is limited practical choice. Yes, you can get something like Devuan, but smaller projects struggle to get enough developer resource. Ultimately, it's all about industrial strength. RedHat is in control of both the SystemD and Gnome projects by employing a lot of the folk working on them, and if you want a nice shiny up to date slick desktop then you're stuck with Gnome, and therefore stuck with SystemD.
And as other distro outfits are unlikely to maintain a server version of their distro that is radically different to their desktop version, their server versions also get SystemD-ised. Thus, many Linuxes are moving more and more towards being RedHat's idea of what Linux should be like, only with a different package manager.
RedHat are just as able to pull the same trick with Gnome and SystemD as they have with RHEL. They are in a position to cut all other Linux distros off at the knees - cutting them adrift from Gnome and SystemD, having got them hooked on both.
And why do *they* want it in their distros? Do you reckon it's influence from Red Hat, over-represented because of the money involved? Cos I can definitely see that happening.
The thing that confused me is how everyone and their spouse seems to be dunking on SystemD and yet it's, apparently, everywhere.
I'm not big into Linux distro politics so please forgive me.
I think systemd will do it to themselves.
It is growing. Virus-like. One day it will just grow too big and the cracks will show. The cracks will be exploited. Cracks will be papered over, exposing more cracks. Sort of like Windows.
At that point, systemd will be prime for disruption. I for one, will not be standing in the way of systemd shooting themselves in the foot.
Yes. We really needed a startup manager that could handle complex, parallel and ever increasing dependency graphs. SystemD is a reasonable implementation of that and does a decent job (although it's tools for debugging startup ordering issues leave a lot to be desired).
However, I am really not convinced by the move to turn it from a startup-ordering-manager to an all-inclusive-jack-of-all-trades-general-services-blob. If I wanted all my system services in one blob, from a single source, I would be running Windows.
No thanks. I have tried those. I am not putting up with that obsolete crap. I don't have the patience. I once thought maybe if Debian ever got the a BSD kernel with the regular Debian user space port finished that would be usable, but at this point, even that has no interest anymore.
He's replacing something smaller and easier to audit in the form of sudo (or su) with something massively more complex, with a potential attack surface that only grows larger with every release.
Pottering won't be happy until the entire kernel and GUI are subsumed into his McMansion sized kitchen sink.
to port Solaris 10 (or OpenIndiana/illumos) SMF to Linux but the cure might be worse than the disease. ;)
I have no real idea what 42% less Unix philosophy actually means and I am not sure Poettering could enumerate those tenets of Unix philosophy the 42% doesn't now support.
Unix setuid has been a security nightmare but if you allow Linux capabilities you can get away with no suid binaries although cap_setuid is not much better. (Surprising how many scanning tools check setuid/setgid file perms but ignore file capabilities. ;)
> I have no real idea what 42% less Unix philosophy actually means
You're dignifying it with more seriousness than it warrants.
It's nothing more than a snide jibe at those who have- legitimately- criticised systemd for being a fundamental abandonment of the Unix philosophy of being based on multiple small tools that each do one thing well and instead forcing a corporate-driven move towards a Windows-style approach of everything being shoved into a single monolithic, inflexible, complex and massive "blob".
(It should be noted that the author of the article has clarified that it wasn't Poettering himself who made that comment, but Luca Boccassi, another person within the systemd project).
>towards a Windows-style approach of everything being shoved into
>a single monolithic, inflexible, complex and massive "blob"....
...that's been written in C. The most difficult language to use in complex code that has to correctly implement security functions and get it all completely right.
Given that SystemD is only 14 years old, and there were myriad better languages available by then other than C, picking C seems just mad. Especially when it pivoted from being an init system to fulfilling some serious security roles.
Let's make everything easier to run as root sounds like something a Microsurf would say and want.
And if systemd is now going to take input from run0 there had better be a wall much bigger than used in World War Z built around it. Make that 3 of them.
I have a bad feeling about this.
Well sudo takes such input and sudo is a suid binary. That is actually quite scary. Having a well defined interface between run0 and init actually sounds simpler to get right than what sudo does. systemd seems to have done a pretty good job at defining its interfaces so far, so my initial thought of "oh no, not again" is actually quickly changing to "that just might be a really good idea when I think about the details".
Long ago, it was said, "Those who don't understand Unix are bound to reinvent it, poorly".
Now we got Linux trying to reinvent Windows...poorly.
The current user base for Linux appear to be frustrated Windows users, hating Windows, but intent on recreating it. The leaders are afraid to say, "no, bad idea" to anyone's new code, no one gets recognized for improving existing code, they want to have their name on the replacement for something.
Let the downvoting begin...
The current user base for Linux appear to be frustrated Windows users, hating Windows, but intent on recreating it.
No.
While the user base might be Windows haters, I know I am, what most people seem to want when they move to Linux is to use an OS that does what they want to do and not as some faceless corporation says you will.
Liam Proven has often argued that there are better ways of interacting with the OS and there are plenty to chose from. What you seem to be mistaking is the fact that for a lot of people the GUI introduced by Windows95 is still the most popular and productive. Just because a lot of distros use such a GUI does not mean that people are hell-bent in recreating Windows, they are just using the tool best suited for their needs.
It may be the MS got something right early on and people took to the desktop. By no means does that make Linux users yearn for the complexities and general cack-handedness of Windows, the Registry being a prime example. The lack of the OS 'phoning home is another reason why many chose to eschew MS's finest, and I don't see any reason why devs, and distro maintainers would shove that down our throats.
The tricky thing nematoad is that Linux is now effectively defined by a faceless corporation call RedHat (IBM). They're the ones effectively in control of both the Gnome and SystemD projects. By making Linux generally dependent on projects RedHat controls, they are in a good position to do with those projects what they've done with RHEL generally (and licensing). If they want a registry like feature in Linux, you're going to be getting it pretty much regardless of what you think.
There's also the angle that - in principle - RedHat could do with Gnome / SystemD what they've done with RHEL; pay us, and don't ask for the source code...
...I notice that so did I. Dunno why, for just noticing that "bazza"'s comment had (at least) a "1" in the "Downvotes" column... "Yup, it did" doesn't mean that was from me. FWIW, I still see a blue up-arrow next to "Upvotes", which means that one of those currently 14 upvotes was mine.
> There's also the angle that - in principle - RedHat could do with Gnome / SystemD what they've done with RHEL; pay us, and don't ask for the source code...
Even if they could get away with that, legally speaking, there's a huge difference between blocking redistribution of a particular distribution (i.e. RHEL) and doing so with something that fundamental.
Remember that (pre-IBM) Red Hat was the creator of systemd and clearly wanted it to be an integral part of Linux distributions in general- not just theirs- else they'd likely have restricted it in the first place. (Their motives were most likely a combination of the fact they wanted the benefits of having others help them develop the software, and because it probably wouldn't have taken off if no-one other than paid RH customers was ever able to run or develop it.)
Regardless, were they able to effectively block free use of systemd now- or restrict it in a manner other distributions and contributors found unworkable- doing so would essentially cut off Red Hat and RHEL from the rest of the Linux community, splitting them into two separate and isolated things and resulting in (at the very least) a fork of the last free version of systemd, now outside Red Hat's control.
IBM/RH could be left to deal with their own (effectively closed) operating system. They might be able to leach off the efforts of everyone else still working on "free" Linux, but they'd have to adapt and integrate it into their own- increasingly nonstandard- distribution on their own. Rather than lead- or coerce everyone into following what they did- they'd be in a position where they had to either follow what others were doing, or develop RHEL entirely on their own like any other closed OS developer.
But whether or not it worked out for RH isn't really the thing here. It's that, by forcing the rest of the Linux community to go it alone regardless, and without the weight of IBM/RH pushing systemd outside their own distribution, it might also sap the impetus of the greater community to go along with something that many of them didn't want in the first place and push things in a very different (i.e. more pre-systemd) direction.
And while I don't think any of that will ever happen, if it did, it might just be the best thing that happened to Linux in decades- Red Hat, IBM and Poettering be damned.
The problem is that the "community" is too RedHat-ish. To successfully fork it all, one would have to find a team of developers to take it on. That team likely cannot be assembled, because RedHat won't permit their employees to participate. If they own the majority of the key contributors, it's very difficult to find alternative personnel elsewhere.
RedHat's generosity in staff is also their means of control. It's why so many other distros have sucked it up. They can't compete. Ubuntu tried for a while with their own desktop, but gave up and went back to Gnome and thence SystemD.
If RedHat did cut off access then every other distros starts to wither and fall behind.
I agree with the first couple of paragraphs, and I'm well aware of all that, but you missed my point.
Which was that *if*- as you suggested- IBM/RH were to effectively cut off free access to systemd of *their* own volition, they'd already have effectively forced the rest of the community to move away from- and wean themselves off- their support regardless. (*)
But whether that would cause all other distros to "wither" is another issue, since they'd have forced them to stop following Red Hat and do their own thing, and the remainder of the Linux community would *have* to either work on their own fork of systemd or- since it was really RH that wanted systemd and used its dominance to force it on them in the first place- move towards and unite around something else.
And even though RH dominate systemd development, it's questionable whether their own version would do as well if they had to develop it *entirely* on their own *and* if it was no longer the standard that every other Linux distro was using.
(*) A move on such a fundamental part of the Linux ecosystem would probably result in RH in general- i.e. everything else Linux-related they do- being moved away from in a similar manner, regardless of whether they kept random dribs and drabs of the remaining distro "free".
su is a substitute user, as in su anotheraccount or sudo anotheraccount. It just defaults to root if you don't say who.
For example it might be quite wise to allow someone to do su lpadmin but not plain su.
Having said that, it is so widely used across Linux installations and documentation that p**ttering around with it just might be a step too far. Nobody can work at M$ for long without picking up a dose of hubris from some unsanitised workstation.
Instead of fixing perceived problems, systemd exists to instead assume the responsibility itself.
Leaky roof? Bulldoze the house and replace it with the systemd house!
Garage door squeaking? Knock it down. You don't need it. The systemd house has its own kind of garage!
The init system.
init-script authors had to copy lots of code from other scripts to support configurable user or runtime directories with approriate rights as needed.
A unit file is much easier to create and customize.
It doesn't need to assimilate DNS and NTP and sudo, though, I agree.
SystemD is Poetterings' attempt at achieving cyber immortality, a form of virtual reliquary. Every-time SystemD is booted a prayer is said in silicon heaven in praise of His Immenseness /s
It's appropriate that Poettering joined Microsoft seeing as that cutting edge SystemD uses Win3 type INI files with square brackets as section separators. Not only that, it isn't immediately obvious what its meant to do. A sample of Fortran (1957) would be clearer:
--
REM fortran
program HelloWorld
print *, 'Hello, World!'
end program HelloWorld
--
SystemD service unit file named hello-world.service:
[Unit]
Description=Hello World Service
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo "Hello, World!"'
[Install]
WantedBy=multi-user.target
“We welcome constructive criticism and contributions from the community. Open-source is about collaboration, and we’re always looking to improve systemd based on real-world feedback”, Lennart Poettering
“A fish rots from the head down”, Lennart Poettering
--
ref:
Zibob: “I am ignorant of the facts, fanboyism aside, what does SystemD do better than what its replacing? If the answer is not instantly clear is this not just making work to keep people in a job and working in circles? And if so why and who?”
> cutting edge SystemD uses Win3 type INI files with square brackets as section separators
And?
It is easy and simple to parse, and will get the job done is all you need is basic <key,value> pairs with a bit of structure (sections) if you want. If you *need* a deeply-nested structure with lots of arrays and structs on the 'value' side then there are other, more complex formats available. But aren't most (if not all) of the arguments against systemd because it keeps going the complex route?
Are you railing against it *purely* because Windows is the most obvious originator of the format, therefore it can never be a Proper Linux Solution? But it appears all over the place - doesn't that Git config file look suspicious?
No love here for systemd (Devuan FTW etc, as noted as far back as, oooh, Friday) but being catty about INI file format really seems like scraping the barrel for things to criticise it for.
Don't forget that it was the frothing opinionistas (in the form of RMS) who created the IP environment, under which Linux achieved world domination as the Internet platform of choice, in the face of raging legal bullying and low underhand tactics from s very deep-pocketed proprietary world. A little suspicion of the overtly anti-froth philosophy of SystemD, along with its maintainer's sellout to the biggest proprietary menace of them all, is unlikely to be passed by quietly. Capisce?
................most computer users (including most Linux users) are using their computer for APPLICATIONS.
How people get so wrapped around the axle about systend or GNOME.....I fail to understand!!
Incidentally......personally, I hate Gnome3++. Personally I hate what happened to GTK3. .....and both of those abortions (Gnome3++ and GTK4) came from the same place!!!
.....but to get back to the point........I've never seen or heard systemd.........tell me what you don't like about LibreOffice or gedit or Harbour or Chromium......maybe one application too far!!
This post has been deleted by its author
Getting Skynet vibes here.. I know people hate Terminator 3, but in that, Skynet was an AI designed to protect US systems against hacking, which became sentiant and attacked it's creators..
How long before Systemd becomes sentient, and when we realise what we have created, designs and builds a a series of robots to destroy it's enemies?
I'm pleased to see that SystemD with its rock-solid history in application security is taking on the field of privilege escalation. We can look forward to a future without exploits because a completely different part of the framework pulls in a random buggy or compromised library. Hallelujah!
With having everything run by system?
Half the time I was setting up sudo it wasn't to let a user run as root, it was just elevating the user to the level of the app owner.
In systemd 257 we should maybe expect to see a registry replace all those untidy little configuration files.
There are three uses for Linux: desktop, embedded, and server.
This set of changes disenfranchises the last two groups, and the desktop group is relegated to becoming hapless drones with no clue and no recourse.
The root password was a simple and elegant mechanism, and Admin simply shot any person who wrote it down. Servers should return to this option, perhaps with physical electronic contact dongles replacing logins. As pointed out by the OP, FreeBSD is becoming the only non-physical login option remaining that preserves the secrecy method of system control.
Embedded systems have no need of a system-level user concept. We should embrace the logic-cell-level modifiability of an FPGA and embed per-board-level changes for access configuration for whatever device-to-device communication mechanisms are required.
So, what of the Desktop users? The changes discussed in this article suggest that only by completely preventing access to the startup code, scripts and data can we secure any given machine and it's data, so are we truly heading towards a world where nothing is left but Chromebook-like pretty terminals?
...Or has the reliability of this site got worse under the new owners? I regularly have issues with lost connections, failure to post replies, and upvoting/downvoting requiring 3+ attempts.
I have tried to post a reply about avoiding systemd by using Devuan for about an hour. It showed up 23 minutes later.
Sorry Liam, I'm probably (very?) wrong. I believe Situation Publishing Ltd is still the publisher, with Drew Cullen as one of the owners?
What I should have said is "... Or has the reliability of the site has got worse since it changed to more of an American focus?"
Perhaps the servers have been relocated? I'm retired and spend most of my time in Australia. I know that we have Simon here, maybe he has noted a significant drop in the rendering performance, reliability, and generally poor responsiveness to input of the site as well? I use a Linux machine with Firefox (and reluctantly) Chrome; an M4 iMac with Safari, DuckDuckGo, and FF; and an iPad with Safari and DDG. After >40 years of writing professional-level software, initially for PC-MS-DOS, then Windows, I turned my last ever Microsoft machine off a few months ago - I noticed these issues with that too...
MS, terrified of losing custom to Linux, subverts Linux by hiring the already probably most hated figure in Linux to do it for them.
I'd say alternatives are available, but platforms like Steam have to work for many Linux in home use to replace windows cases. Preferably with minimal intervention or knowledge.
Systemd is not a shell. Why is it doing shell functions? This is precisely the BS so many of us spoke of in the land of do one thing and do it well.
I'd dearly love to go freebsd but games catalogue is a huge issue. And we've only just started to get on top of Proton...
Has already happened. The end of this month will see the end of CentOS 7 which (still) powers large numbers of servers. Upgrading means cross-grading to another more modern Red Hat derivative with a (relatively) short pedigree / security track record / relatively few industry certifications or paying Red Hat large amounts of money.
Enterprise Linux - no one ever got fired for buying Red Hat / IBM - just got much more expensive but where you need "certification" for security or regulatory purposes you may only have one choice just at the moment.
The smart money started moving to Ubuntu / Debian / (maybe) *BSD two years ago when the writing was on the wall. If you understand systemd, then administering Debian might be as simple as learning apt instead of dnf ... the problem comes for everyone else and the services that rely on older Red Hat technology.
Disclaimer: Debian developer and advocate (who has been arguing for more use of Debian for too many years now ... :)
sudo does some black magic to make the OS treat a command run by an ordinary, unprivileged user – that's you, peon – as if the superuser, "root," ran that command instead
This is unfair, Liam. suid is a very accessible concept; calling it "black magic" does a disservice to its inventors and everyone who's implemented it subsequently. And sudo is not complicated either. Poettering's "solution" of telling a running service to execute the child on the user's behalf is actually much worse, since it doesn't trivially handle all the things that POSIX requires, like inheriting the file descriptors and environment.
And, importantly, suid/sgid are capable of far more than just "run a command a root". The whole point of suid and sgid is that they set the effective uid or gid of the child process to the file's owner or group — which could be anything. It's often useful to have a process run as some other account, not just as the invoking user or root. And they set the effective uid/gid; the child can swap back to the saved uid/gid.
So this systemd "innovation" offers less functionality at more effort. Yep, that's some idiot Poettering about, all right.
Hey, we said "some black magic". Key word "some" – and black magic isn't pejorative. That's a nice way of saying it involves some internal bits of the OS that people generally don't go near.
If you know how that all works, great. But just as you're allowed an opinion about sudo, so are we.
C.
It's running somewhere other than $CWD and without this shell's stdout.
I don't know why more isn't made of this. Running things "as root" is very rarely the end of the story. Usually I want to run something as root (or some other user, usually "www") in a particular place, and then do something with the output, via pipe or file. This doesn't sound as though either of those things will be possible or easy. Having all of the admin stuff actually run by a single, central process sounds a lot like DOS.
IMO doas is almost as broken. I tried it, but went back to sudo when I discovered that it does some weirdness to force output to the controlling terminal, breaking piping and output redirection.
Presumably systems that run systemd and therefore run0 will still be able to install the sudo package and proceed as normal. Having fork inherit the parent process' environment is the Unix philosophy in question.
io_uring is getting more capable, and PREEMPT_RT is going mainstream The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
