Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday September 22 2019, @01:00PM   Printer-friendly
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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by Anonymous Coward on Sunday September 22 2019, @01:56PM (18 children)

    by Anonymous Coward on Sunday September 22 2019, @01:56PM (#897099)

    Can anyone alive now explain what the hell systemd even currently is, let alone where it is going?

    Is it a replacement for init scripts?
    Is it some kind of daemon?
    Is it some kind of meta-kernel or kernel replacement?
    Is it a general kernel services interface?
    Is it a daemon service provider? With what overall scope?
    And why is the kernel not good enough for each and every "service" systemd is now determined to provide?

    The feature creep of systemd is completely out of control. Poettering & Co. have gone off the ranch and decided to re-implement things that no-one needs redone, in an architecture which was never designed to support them.

    No harm in innovation you say? I say that linux audio system have not in fact recovered from the mid-stream horse crossing to Pulseaudio -- Poettering's pre-systemd trial run. ALSA was fucking working before pulseaudio arrived and screwed everything up for years. Now I'm supposed to believe that Poettering's latest bright idea will handle encryption better than tried and decades tested solutions that already encrypt /home folders at the click of a checkbox? Does Lennart even use a modern Linux system, or does he just not know all the things he's selling are available already?

    HHe 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.

    AAAAhhhhh!!!! [uri.edu]

    Starting Score:    0  points
    Moderation   +5  
       Insightful=5, Total=5
    Extra 'Insightful' Modifier   0  

    Total Score:   5  
  • (Score: 1) by NickM on Sunday September 22 2019, @02:46PM (1 child)

    by NickM (2867) on Sunday September 22 2019, @02:46PM (#897115) Journal
    I know your probably kind of sarcastic but systemd is a collections of system daemons and an init system that are configured in an homogeneous way. The init system is named systemd-init, the logging deamon is named systemd-journald , the networks resolver is named systemd-resolved and I hope by now that uou get the pattern...
    --
    I a master of typographic, grammatical and miscellaneous errors !
    • (Score: 3, Insightful) by HiThere on Sunday September 22 2019, @04:09PM

      by HiThere (866) Subscriber Badge on Sunday September 22 2019, @04:09PM (#897139) Journal

      And the older version was a lot easier to use, and had fewer problems.

      --
      Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
  • (Score: 3, Touché) by The Mighty Buzzard on Sunday September 22 2019, @03:06PM (8 children)

    by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Sunday September 22 2019, @03:06PM (#897120) Homepage Journal

    Alsa was only "working" if you tack on the adjective "poorly". I can't tell you how many times I had to deal with an audio source refusing to play or crashing the program it was part of because something else had the entire damned audio system tied up under alsa; hundreds at least. Yes, pulseaudio's a fucked up pile of monkey turds. But it still works more reliably than alsa ever did.

    --
    My rights don't end where your fear begins.
    • (Score: 3, Informative) by Anonymous Coward on Sunday September 22 2019, @03:57PM (2 children)

      by Anonymous Coward on Sunday September 22 2019, @03:57PM (#897134)

      I did hours long sets with alsa, not a single dropout even with cpu under stress.
      I used the default mpv and pulseaudio, presentation worked fine at home, failed in the field without error messages, likely because of no network, which was the only differing aspect.

      Yes default alsa can do only one application at a time, i also can listen to one thing at a time.

      • (Score: 3, Interesting) by The Mighty Buzzard on Monday September 23 2019, @01:00AM (1 child)

        by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Monday September 23 2019, @01:00AM (#897325) Homepage Journal

        I can listen to music, video game sounds, and system/app notification sounds all at the same time. Maybe you should practice more.

        --
        My rights don't end where your fear begins.
        • (Score: 0) by Anonymous Coward on Monday September 23 2019, @02:10PM

          by Anonymous Coward on Monday September 23 2019, @02:10PM (#897551)

          I practiced monitoring a song and beatmux another since the SL1210mk2 setup in 1996. In fact the sessions I talked about were timestretched mp3 flacs and wavs output by mixxx to two separate stereo tracks to an audio mixer, its output picked up by the same USB audio card input and recorded using arecord. All on a pulseaudioless 10+ year old core i5 2.6ghz laptop.

          I also turn the volume all the way down on the desktop so not to be bothered by notifications and autoplaying stuff. For your use case there is dmix.

    • (Score: 1) by pTamok on Sunday September 22 2019, @06:41PM

      by pTamok (3042) on Sunday September 22 2019, @06:41PM (#897212)

      Yes, pulseaudio's a fucked up pile of monkey turds. But it still works more reliably than alsa ever did.

      Not on my system it doesn't. Unless you count 'reliability' as reliably crashing every time I try to change the volume when watching streamed video via Firefox (and not just YouTube). I now wear my headphones around my neck or behind my ears to listen to anything important.

      I am reasonably good at diagnosing IT issues and finding solutions or workarounds. Pulseaudio has me beat.

    • (Score: 1, Interesting) by Anonymous Coward on Sunday September 22 2019, @07:16PM (2 children)

      by Anonymous Coward on Sunday September 22 2019, @07:16PM (#897220)

      Alsa supports (since forever) setting up a software mixer, if your hardware does not natively support this. You don't need pulse audio to achieve this.

      It is a bit arcane of a config, it you want to set up from just docs, but there are tons of examples around, if all you want is a mixer, or just a mixer with a volume boost, etc.

      Since Alsa came out, I have never seen a crash due to Alsa.

      Personally, I don't now, and didn't understand, at the time, why Linux created Alsa, instead of just improving OSS.

      • (Score: 2) by The Mighty Buzzard on Monday September 23 2019, @01:01AM

        by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Monday September 23 2019, @01:01AM (#897326) Homepage Journal

        I'll admit, I do miss being able to cat .wav files to /dev/dsp

        --
        My rights don't end where your fear begins.
      • (Score: 1, Insightful) by Anonymous Coward on Monday September 23 2019, @01:02AM

        by Anonymous Coward on Monday September 23 2019, @01:02AM (#897327)

        Personally, I don't now, and didn't understand, at the time, why Linux created Alsa, instead of just improving OSS.

        Same reason why git came into being: Hannu Savolainen wanted to make money off of OSS, and provided only a crippled edition for Linux.

    • (Score: 2) by hwertz on Monday September 23 2019, @06:22AM

      by hwertz (8141) on Monday September 23 2019, @06:22AM (#897436)

      Agreed. Apparently ALSA worked pretty nicely if you had a fancier card that supports multiple card users and mixes them on the card; I never had one of these, so the first ALSA user would get the card, the second would (depending on how it was written) either detect the card was busy and have no sound, or simply attempt to open the audio device and block (making that app lock up until the audio device freed up.)

      Pulseaudio is (or at least was last I looked) messy code, but they seem to have gotten the kinks worked out well over 5 years ago, and for me it's worked a treat. It works for "normal" use (i.e. playing a video but still having notification beeps or whatever). It successfully (not useful really but cool) let me pipe audio from computer to phone, and phone to computer, via bluetooth. And, I was able to use pactl and such to persuade pulseaudio to use a SDR (software defined radio) receiver app that was expecting to dump audio out to speaker, and pipe that audio straight into a decoder app that was expecting it's input to come into the headphone jack from a physical radio. Instructions to do this kind of thing in Windows, they buy a $20-30 app to do virtual audio loopback; pulseaudio does it for free.

  • (Score: 5, Insightful) by Anonymous Coward on Sunday September 22 2019, @03:23PM (5 children)

    by Anonymous Coward on Sunday September 22 2019, @03:23PM (#897123)

    "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)

      by opinionated_science (4031) on Monday September 23 2019, @11:12AM (#897498)

      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)

        by rleigh (4887) on Monday September 23 2019, @12:13PM (#897519) Homepage

        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)

          by opinionated_science (4031) on Monday September 23 2019, @01:49PM (#897544)

          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

            by rleigh (4887) on Monday September 23 2019, @05:41PM (#897693) Homepage

            > 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

        by Bot (3902) on Monday September 23 2019, @04:03PM (#897628) Journal

        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.
  • (Score: 2, Interesting) by Anonymous Coward on Sunday September 22 2019, @06:01PM

    by Anonymous Coward on Sunday September 22 2019, @06:01PM (#897184)

    The situation with GNU/Linux and systemd/Linux at present is resembling the one when Microsoft stopped collaborating with IBM on OS/2 and rolled out Windows NT.