SoylentNews is people
SoylentNews
from the all-your-computer-are-belong-to-us dept.
At the All Systems Go conference in Berlin 20-22 September, Lennart Poettering proposed a new extension to systemd, systemd-homed.service. A video of his session can be downloaded from media.ccc.de with accompanying slides [PDF].
In his presentation, Poettering outlines a number of problems he sees with the current system, like /etc needs to be writeable, UIDs need to be consistent across systems, and lack of encryption and resource management.
His goals with the proposed solution are migrateable and self-contained, UID-independent home directories with extensible user records that unify the user's password and encryption key; LUKS locking on system suspend; and Yubikey support.
He identifies a number of problems this new idea could cause with SSH logins, disk space assignments, UID assignments, and LUKS locking.
He plans to introduce JSON user records that can be queried via a Varlink interface and to a certain extent are convertible to and from existing formats. The home directories will be stored as LUKS-encrypted files that will be managed by the proposed new service, systemd-homed.service. The system integration will be supported by pam_systemd and systemd-logind.service.
It will be interesting to see how the world responds to this new take on systemd's ever-increasing encroachment of Linux.
... and lastly, this story is brought to you from a systemd-free laptop.
(Score: 5, Insightful) by Anonymous Coward on Sunday September 22 2019, @03:23PM (5 children)
"The feature creep of systemd is completely out of control."
That was the whole point. They couldn't proprieterize the kernel, so the proprieterized the next best thing: the init system. I knew it was a fuckfest shill for Redmond the first time I saw the INI file format. I have always been flabberghasted that Debian chose SystemD. I thought Debian were supposed to FOSS zealots. The design principles that SystemD uses, move in the other direction.
(Score: 2) by opinionated_science on Monday September 23 2019, @11:12AM (4 children)
i must have missed something. How is systemd proprietary if it's FOSS?
Is this a theoretical complaint?
(Score: 5, Insightful) by rleigh on Monday September 23 2019, @12:13PM (2 children)
It's hyperbolic, but not theoretical.
Being "FOSS" means having a free software licence. That licence grants you the right to modify the source code as you see fit. The entire point behind software freedom is to empower the user, by both allowing them access to the original source code, and to make and distribute modifications. That's the legal rights. However, there are also practical concerns. If something is made as big and complex as possible, even though it's technically free from a legal perspective, it can be effectively closed to modification in practice.
Not all software is modifiable. You can't alter a character set, or a communications protocol, without breaking inter-operability. You would need to create a new one which could be used alongside the original. You can't alter systemd if you modify any of its interfaces. But many of the internal and external interfaces are so poorly documented (e.g. logind), that you couldn't do this even if you tried. You can't reimplement or redesign a system when the original is opaque to begin with. And this is the source of much of the concern and frustration with systemd. It's rooted in bad design and bad implementation, which we are powerless to fix or to maintain ourselves. This is in stark contrast to other init systems, which are completely open to understanding and modification, even if they are superficially less featureful.
Linux succeeded because it could be repurposed for many tasks and used as glue to connect and interoperate with many different systems. It was open for modification, and many people took advantage of that. systemd represents a corporate takeover of Linux, by locking it down to a small set of officially sanctioned "use cases", while sticking the finger up at everyone who wants to deviate from these scenarios. It's as inflexible as Windows or MacOS in essence. This goes completely counter to what Linux was historically, and that's one of the major sources of complaint. By making its unit configuration declarative, rather than imperative, they have been able to insert themselves as the gatekeepers of what is and is not allowed, which is basically "whatever Lennart thought was a good idea to jam in at the moment". Same deal with the D-Bus and library interfaces which can't be reimplemented since they depend upon so much internal state and undocumented behaviour. It's a fragile house of cards, and it's going to come back to bite them.
(Score: 2) by opinionated_science on Monday September 23 2019, @01:49PM (1 child)
but interfaces in FOSS code, can be wrapped. A pain, yes! But try doing that with binary only Micro$oft junk.
For that matter, have a crack at closed source CUDA.
So in all cases, having the source code to both sides of a systems is many times easier than having just one.
(Score: 2) by rleigh on Monday September 23 2019, @05:41PM
> but interfaces in FOSS code, can be wrapped
What exactly do you mean by this? Do you really mean wrapping, or independently re-implementing? And what exactly are you wrapping or re-implementing? The core code? The library APIs? The D-Bus endpoints and services? Either way, please explain what the end goal of the exercise would be.
Whether or not it's wrapping or re-implementing, you can't do anything without there being a documented design, a documented API, and/or a documented set of D-Bus services. This part is sorely lacking, and would greatly limit what is possible to do. There's a reason it's impossible to replace logind with a compatible alternative implementation. To be compatible, you have to understand the behaviour of what you're replacing in order to replicate it. And not even the systemd developers understand all the subtle nuances of that. It's almost completely defined by the implementation...
> But try doing that with binary only Micro$oft junk
Err, wrapping a documented ABI and/or API would be trivial, particularly since it's all documented. Microsoft Windows has a dedicated service API, and you can wrap it if you want to (unsurprisingly, it's already been done).
> So in all cases, having the source code to both sides of a systems is many times easier than having just one.
Please rephrase this; it's barely intelligible. What exactly are the "both sides" you are referring to? And what is the source code being used for?
(Score: 3, Insightful) by Bot on Monday September 23 2019, @04:03PM
Systemd is not proprietary. It is worse, it is anti-free software. The distro adopting systemd has to devote resources to adapt to its quirks and has to obsolete literal tons of software and how-tos. And this is not meant to settle. Forking is an option but the stabilized, documented result still has a questionable usefulness. Yes Unix has many paths towards a solution, and the answer to that "problem" is called a configured distro.
Being internally free software is as irrelevant as an expansionist country being internally democratic. In fact, they all want to seem democratic as a way to shift blame on the masses.
Account abandoned.