back to article The D in Systemd is for Directories: Poettering says his creation will phone /home in future

Systemd inventor Lennart Poettering told the crowds at the All Systems Go Linux user-space event in Berlin he intends to reinvent home directories to fix issues with the current model that are otherwise insoluble. Specifically, he wants Systemd, or rather systemd-homed, to manage and organize home directories. In Linux …

  1. Pascal Monett Silver badge

    That was a serious breath of fresh nerdiness

    I'm glad that there are people out there who are intelligent enough to tackle these kinds of issues and do so for the sake of my protection.

    That said, I kinda doubt that "most people" encrypt their laptop drives. Most of the people I know who do have laptops have work laptops, and even they are not always using disk encryption, although their IT department should be pushing that.

    As for private users, try and talk them into encryption and watch their eyes glaze over in real time.

    No, sorry, I don't see it happening any time soon.

    1. Anonymous Coward
      Anonymous Coward

      Re: That was a serious breath of fresh nerdiness

      Or you could just use Windows which fixed most of this a couple of decades ago.

      1. werdsmith Silver badge

        Re: That was a serious breath of fresh nerdiness

        It's true but you shouldn't say it.

      2. Anonymous Coward
        Anonymous Coward

        Re: That was a serious breath of fresh nerdiness

        For a good demonstration of Windows Encryption get yourself a copy of CryptoLocker.

        It's free to install for everyone, but there's a 2BTC uninstall fee.

        1. Anonymous Coward
          Anonymous Coward

          Re: That was a serious breath of fresh nerdiness

          Yes as my Linux based Synology NAS previously notified me....

        2. TheVogon

          Re: That was a serious breath of fresh nerdiness

          Stupid is as stupid does. Windows 10 offers pretty good ransomware protection if you don't ignore the prompts to enable it:

          https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/enable-controlled-folders

      3. Teiwaz

        Re: That was a serious breath of fresh nerdiness

        Or you could just use Windows which fixed most of this a couple of decades ago.

        Yes, Windows were so concerned about the need to encrypt your files, they devised a system which allowed any passing webside script to do it for you.

        1. HighTension

          Re: That was a serious breath of fresh nerdiness

          In 1998? I don't remember NT3 or 4 having any such provision, and ME and 98 were laughable in terms of security (oh the joys of unpassworded access to C$ shares on US cable networks, had some juvenile fun with that!). I may be wrong, I'm officially ancient in IT terms.

      4. JohnFen

        Re: That was a serious breath of fresh nerdiness

        ...as did Linux.

      5. Anonymous Coward
        Anonymous Coward

        Re: That was a serious breath of fresh nerdiness

        "Or you could just use Windows which fixed most of this a couple of decades ago."

        Someone obviously doesn't understand TFA.

    2. Cederic Silver badge

      Re: That was a serious breath of fresh nerdiness

      Given the RIP Act anybody encrypting their hard drive is pretty much setting themselves up for potential future grief.

      Forget your password? Lose your key? 10 year old laptop? Tough shit, off to jail with you.

      1. steviebuk Silver badge

        Re: That was a serious breath of fresh nerdiness

        Just go back to TrueCrypt. The independent said it was still safe despite it being closed down. And at least with it you can create a hidden encrypted partition. I'm sure at the US airports the people asking to look at your laptop aren't gonna have any idea you have a TrueCrypt hidden partition installed.

        1. imanidiot Silver badge

          Re: That was a serious breath of fresh nerdiness

          If they want to, the people at the airport probably have automated scanning tools that tell them a TrueCrypt partition exists. And then the rubber gloves come out, so to speak.

          1. EVP

            Re: That was a serious breath of fresh nerdiness

            You shouldn’t keep your decryption keys in your body orifices to be found by the customs.

            Seriously, TrueCrypt can create a hidden volume inside a volume, i.e. it features “plausible deniability”. In another words, you can happily show contents (full of porn, plausible) of the first volume to the customs while keeping contents (full of romantic poems written by you, denied) of the second volume secret and completely hidden. The customs might still get the gloves out just for fun, but that’s another story.

            TrueCrype was (well, still is) a really nice tool. Too bad it’s not updated anymore.

    3. katrinab Silver badge

      Re: That was a serious breath of fresh nerdiness

      If you have a Mac, then FileVault is very easy to set up. You then need to supply a password before the computer will boot up.

      1. whitepines
        Linux

        Re: That was a serious breath of fresh nerdiness

        If you use Linux, LUKS FDE is very easy to set up (select the Encrypt option during installation). You then need to supply a password before the computer will boot up.

      2. phuzz Silver badge

        Re: That was a serious breath of fresh nerdiness

        Not sure why you're getting so many downvotes for that (except for being slightly off topic). Windows BitLocker is much the same.

        Newer versions of Android are different, only the user's files are encrypted,. So the the phone will boot, and receive phone calls, but messages/emails etc. won't be received until the phone is unlocked. Well confusing if you don't realise you've not unlocked it, because at a quick glance it looks like the phone is working as normal.

    4. DrXym

      Re: That was a serious breath of fresh nerdiness

      Encryption has to come out of the factory enabled with no way to turn it off and be hardware assisted so there is neglible impact on performance. Even myself as an expert am extremely leery of enabling encryption on a device which shipped with no crypto because I know the device would have to reimage and migrate all the data to get to that state.

      1. whitepines
        FAIL

        Re: That was a serious breath of fresh nerdiness

        Encryption has to come out of the factory enabled

        Erm, doesn't that kinda defeat the purpose? Where this stuff is manufactured (deepest darkest China) the factory would be forced to keep a list of all encryption keys; to change them, you'd have to wipe and reinstall anyway.

        That's of course assuming they'd even use a different key for each machine!

        1. TheVogon

          Re: That was a serious breath of fresh nerdiness

          Why would they need to keep the keys? Any issue in the supply chain you just reimage the device.

          1. whitepines
            Big Brother

            Re: That was a serious breath of fresh nerdiness

            Why would they need to keep the keys?

            Because their government literally tells them to?

            Encryption may be soft-illegal here in Blighty, but it's hard illegal in China without the government also having access. Plus that pesky drive to hack into anything and everything outside of Chinese borders.

        2. DrXym

          Re: That was a serious breath of fresh nerdiness

          I didn't say the encryption key has to be set by the factory, although that already happens - SoCs contain non volatile storage which is how every phone has a unique MAC, licences and yes keys.

          But full disk encryption in Android is enabled by generating a random key on first boot and storing it in hardware based storage. This key is further encrypted with a default password and reencrypted with a different hash if the user sets their own PIN/password/lock screen. They key doesn't change once it is generated.

          The point being, it should happen by default and there is no reason it shouldn't when encrypted I/O is supported in hardware. Doing it after the fact, converting an unencrypted to an encrypted partition on the fly is potentially destructive. Very few people would risk doing it which is why it should be always on.

      2. doublelayer Silver badge

        Re: That was a serious breath of fresh nerdiness

        "Encryption has to come out of the factory enabled"

        This is generally fine as long as it makes me set the key. If it uses one set at the factory and simply encrypts that key with the password I supply, that's not acceptable.

        "with no way to turn it off"

        Not acceptable. I may want to turn it off. If I know enough about how it works to do that, I probably have a reason. For example, if I want people to be able to remove the disk and read it on something else, encryption would completely remove that option. If I want people to be able to boot another disk on it, which isn't encrypted with a key known by the remaining components or at all, the user couldn't do that either.

        "and be hardware assisted so there is neglible impact on performance."

        That's already the case. Nearly every disk encryption solution uses AES, and nearly every modern processor used in a computer has AES acceleration in hardware. Ask the many people, myself included, doing all their work on devices with full disk encryption. It's fine from a performance standpoint.

        "Even myself as an expert am extremely leery of enabling encryption on a device which shipped with no crypto because I know the device would have to reimage and migrate all the data to get to that state."

        You're worried that a device will have to be reimaged? Do you know how often that happens? It happens on large upgrades (Windows and Mac, not Linux most of the time). It happens when a disk gets replaced. It happens if a backup is restored. It should happen every time a device changes hands. It is the first step after a company gets a device from somewhere else as they'll apply the corporate image. And it happens when the disk gets encrypted. If you're encrypting the right way, and I'm sure as an expert you would, all the disk has on it at the time of encryption is a basic OS image with the encryption software if that wasn't already included. If for some reason it fails, which doesn't really happen unless you cut power or something, reimage and reencrypt. It'll work fine the next time.

        What you're really getting when you ask for this is a device that is stuck with the original factory image, and because you've asked for "no way to turn it off", can't ever be replaced, for any reason. And that's terrible from a security perspective, even if that image and user data is encrypted.

        1. DrXym

          Re: That was a serious breath of fresh nerdiness

          Well your edge case certainly trumps the general case... Whole disk encryption doesn't mean the key is irretrievable. Windows 10 (for example) allows a user to store a recovery password in active directory or in home, via an escrow service, or a bitlocker recovery key which you print out and keep safe. And BTW, Windows 10 already defaults to encrypt the FS on many tablets and laptops.

      3. HighTension

        Re: That was a serious breath of fresh nerdiness

        I think that's exactly the wrong place to put trust. Look at the controversy around TPM when it was first introduced, and internal memos from Microsoft were leaked saying how great it was that they could leverage their OEM market by ensuring the TPM would not allow the installation of anything other than Windows. I think the backlash on that revelation was what ended the Ballmer era and paved the way for the increased openness we see today (and the "Internet will never amount to anything" misjudgement).

        What I don't like at all about Poettering's outputs is that it's just way to complicated and intertwined with so may other parts of systemd, instead of being just one reusable part in a chain. The opacity and "tight integration" to the point of being monolithic is frustrating. The learning curve is fine when it works, but appalling when it goes wrong, as it's really hard to pin down what is really misbehaving and how to fix it. OTOH, yes, it's faster to boot, easier to integrate your own services and targets with no real shell knowledge and its ability to safely override distro installed scripts is great.

        And worse, the "pluggability" breeds repeated reinvention of the wheel, eg /etc/network or /etc/sysconfig/network moving to NetworkManager, and now on Ubuntu to the terrible netplan. You cannot even properly set MTUs on bridge interfaces - it just takes what the parent interface has. As a sysadmin/architect of 20 years experience I like the results of a configuration to match the documented ones.

        1. HighTension

          Re: That was a serious breath of fresh nerdiness

          Bloody hell, another immediate vote-down with no reply to the comment. Voter - have you ever heard of the "Clipper Chip"? Read Schneier's "Practical Cryptography" or Singh's "Crypto", or Sterling's "Hacker Crackdown"? TPM actually turned out to be useful in locked-down environments, but not solely "locked OS" ones. Poettering does some good things, and some bad. I think Pulseaudio is the best compromise so far on sound in Linux. networkd and systemd not so much - solving problems that upstart and NM had already solved adequately.

        2. Pascal Monett Silver badge

          Re: the backlash on that revelation was what ended the Ballmer era

          That probably didn't help, but I think the fiasco that was Vista followed by the utter failure that was Windows 8 was what did him in.

          And it was about effing time.

    5. Wayland

      Re: That was a serious breath of fresh nerdiness

      With Windows 10 the drive is often encrypted.

      If it was by default them most people would encrypt their laptop drive. Different on a server as someone has to be there to unlock it, which they already are with a laptop.

      The desktop is less of a problem since less opportunity to steal it. The password in RAM is a lesser problem with the desktop because you cannot suspend to RAM and then steal it.

      1. TheVogon

        Re: That was a serious breath of fresh nerdiness

        Yes you can.

  2. Doctor Syntax Silver badge

    "The [redacted to please Cloudflare who block anything that looks like a path] passwd database is not extensible, and therefore Linux has evolved numerous secondary databases that are stored elsewhere, such as [redacted to please Cloudflare] shadow, a privileged location used for encrypted password hashes and other password-related fields, such as the maximum time before a password expires."

    Linux has evolved no such thing. It's simply inherited it from Unix

    It was a necessary step for Unix to evolve in that way after the sort of incident described in "The Cuckoo's Egg". The password file has to be world readable because user programs such as ls and chown need to be able to map UIDs to user names and is small enough to be exfiltrated even over a dial-up modem link. Once desktop processing power became sufficient to crack the encryption then in use in passwd the actual passwords needed to be moved into a separate file which could be privileged because only a limited number of system programs needed access.

    We now have a lot of fussing about state and configuration to satisfy some arbitrary scheme about directory usage. Stuff that. Unix directory usage, like the rest of the system, was designed on practical grounds. We're seeing the steady destruction of a working, practical system design to satisfy the ego of a Jonny-come-lately. If he wants to design a system to his own notions let him go ahead and do that from scratch and get out of everybody else's hair.

    1. Anonymous Coward
      Anonymous Coward

      re: Once desktop processing power became sufficient to crack the encryption

      Way back when, you didn't need to decrypt if the sysadmin had set a blank password and you could read /etc/passwd (which you could ..)

      And at my Uni, because the teaching staff were ... prone to "forgetting" their passwords, the computer centre staff made lecturer passwords blank by default.

      You can see where this is going ...

      Lecturer accounts had privileges to share files that students didn't ... which meant if you could log in as a lecturer *any* lecturer (they knew how to assign groups, but it seemed to cause more problems, so there was just a "lecturer" group) then you could see (and sell) coursework.

      Anon, obviously.

      Even then, it always struck me as strange that /etc/passwd had to be readable by all - really it should have been only readable by a login daemon ? But then my hacking exploits also worked out how to trick the PRIMEs login daemon ....

      1. Doctor Syntax Silver badge

        Re: re: Once desktop processing power became sufficient to crack the encryption

        If lecturers couldn't be arsed to remember their own passwords I shudder to think what their security courses might have been like.

        1. K

          Re: re: Once desktop processing power became sufficient to crack the encryption

          As the saying goes - Those who can't, Teach!

          Its 100% true, my wife works in a scientific field (medicines), she and her colleagues all have PHD's in Maths, in recent years they've had 2 "professors" start, and on-paper they were amazing candidates, but in fact, they cannot seem to think for themselves, have no common-sense, and if there is no "paper on it" then are are clueless!

          1. Anonymous Coward
            Anonymous Coward

            Re: re: Once desktop processing power became sufficient to crack the encryption

            > but in fact, they cannot seem to think for themselves, have no common-sense,

            That's been my experience with a lot of people from "good" universities - some then pick up some utility over the years, others stick steadfastly to quoting shit they were taught back in Uni that doesn't actually practically apply in the real world.

            Doesn't go for all degree holders, by any means, just seems to be common amongst Cambs and Oxbridge types in particular.

            1. iron Silver badge
              Headmaster

              Re: re: Once desktop processing power became sufficient to crack the encryption

              Oxbridge = Oxford & Cambridge (it's pretty obvious from the spelling)

              So either say "Oxbridge" or say "Cambridge & Oxford" but never say "Cambs and Oxbridge" because you'll just look like a twat.

              1. Anonymous Coward
                Anonymous Coward

                Re: re: Once desktop processing power became sufficient to crack the encryption

                A pox on Oxbridge...

                Camford FTW!

                1. phuzz Silver badge
                  Facepalm

                  Re: re: Once desktop processing power became sufficient to crack the encryption

                  No no, OP said "Cambs", clearly they were talking about the Camborne School of Mines. ;)

                  (My brother got very confused and had assumed they were all training to be psychiatrists. He'd mis-heard it as the School of Minds).

              2. K
                Trollface

                Re: re: Once desktop processing power became sufficient to crack the encryption

                > but never say "Cambs and Oxbridge"

                I'll admit, it did make me laugh - but are you an academic by any chance?

            2. Paul Johnston
              Joke

              Re: re: Once desktop processing power became sufficient to crack the encryption

              and Hull of course!

          2. A Non e-mouse Silver badge

            Re: re: Once desktop processing power became sufficient to crack the encryption

            I think these people become so knowledgeable and specialized that their brain can no longer process common sense.

            1. WonkoTheSane
              Headmaster

              Re: re: Once desktop processing power became sufficient to crack the encryption

              Specialization means that academics are learning more and more about less and less.

              The end case is that pretty soon, they'll know everything about nothing, and nothing about everything.

              1. nematoad

                Re: re: Once desktop processing power became sufficient to crack the encryption

                We used to have a saying in the Army: " A corporal is a man who knows a little about a lot of things, everyday he learns more and more about less and less until eventually they make him a sergeant."

                Seems as if it is also true within the groves of academe.

            2. LeahroyNake

              Re: re: Once desktop processing power became sufficient to crack the encryption

              Or in the immortal and intentionally sexist (to prove a point that nomes of whatever sex should be equal and that nomes are just as stupid as lumbering humans ) Women can't read, there is something different about their brain and it would just overheat.

              Paraphrased from Terry Pratchett, The Nomes.

              https://en.m.wikipedia.org/wiki/The_Nome_Trilogy

              1. Anonymous Coward
                Anonymous Coward

                Re: re: Once desktop processing power became sufficient to crack the encryption

                Women! Know your limits!

        2. Chris King

          Re: re: Once desktop processing power became sufficient to crack the encryption

          I don't have to imagine - I remember one lecturer telling his students about the importance of physically securing kit and taking regular backups...

          ...he then left his laptop open on a desk, whereupon some friend of humanity helped himself to it, complete with three weeks of work not backed up.

      2. Anonymous Coward
        Anonymous Coward

        Re: re: Once desktop processing power became sufficient to crack the encryption

        Not that shocking. School / Uni networks always have been garbage.

        I used to get hauled up by the sysadmin regularly for being a dick.

        My favourite exploit was installing Doom or Atomic Bomberman in the print spool folder and showing everyone how to do it.

        For some reason it was writable by everyone.

        Apparently I caused them massive headaches because all the printers kept spewing garbage for weeks.

        They tallied everything up and apparently I'd cost the school £300 in crisp white A4.

        I also got hauled up for expanding students storage areas. We were given a paltry 20mb (it's the 90s), but in order for students to keep their copy of coursework_files.zip (definitely not games) they needed more space...so I found a utility on a website (used to be known as Crash Dummies) that let me perform admin tasks without any admin credentials. I gave everyone a 250mb quota (which everyone then filled with garbage freeware and other assorted crap).

        The sysadmin told me that they ran out of space within a month because the student storage drive was only 10GB.

        They hauled me up for showing people how to bypass the internet filter. It was a caching proxy designed to save bandwidth rather than filter. As a result, students clogged up the internet connection constantly (it was a 64k ISDN).

        I was in the sysadmins office at least once a month. He would absolutely lose his shit and throw things around as well as sweep everything off his desk.

        Gloriously angry.

        1. Doctor Syntax Silver badge

          Re: re: Once desktop processing power became sufficient to crack the encryption

          "a paltry 20mb"

          Back when.... No, that way we get to the four Yorkshiremen sketch.

          Let's just say that punched cards are limited only by the amount you can carry.

        2. A Non e-mouse Silver badge

          Re: re: Once desktop processing power became sufficient to crack the encryption

          For some reason [print spool folder] was writable by everyone.

          Er, and how else are users meant to submit their jobs to the print spooler?

          1. Doctor Syntax Silver badge

            Re: re: Once desktop processing power became sufficient to crack the encryption

            Via a setuid program that has permission to write there.

          2. oldcoder

            Re: re: Once desktop processing power became sufficient to crack the encryption

            I used lpr which was allowed access... No one could write to the directory. And then it went through lpd anyway.

        3. Chris Parsons

          Re: re: Once desktop processing power became sufficient to crack the encryption

          And bravely anonymous.

        4. anonymous boring coward Silver badge

          Re: re: Once desktop processing power became sufficient to crack the encryption

          I believe I had a quota of 512kB of disk space on our shared AT&T 3B2.

          1. jake Silver badge

            Re: re: Once desktop processing power became sufficient to crack the encryption

            I owned all 67 megs and 2 megs of RAM in my 3B1 ... Still do, in fact, but it boots 4.3BSD instead of the shitware that AT&T shipped with it.

            Yes, I know, the 3B1 was unrelated to the rest of the 3B series. A couple years ago, I was offered a complete, working 3B15 (with tape drive), free for the hauling away. I declined. Historic, yes. Useful, not so much. I think it's in storage at The Computer History Museum in Mountain View.

          2. Anonymous Coward
            Anonymous Coward

            Re: re: Once desktop processing power became sufficient to crack the encryption

            > I believe I had a quota of 512kB of disk space on our shared AT&T 3B2.

            Luxury! I once had a quota of 72KB on a 72KB floppy disk.

      3. Pigeon

        PRIME

        Are you talking about PRIMES last-ditch attempt at unix machines? The venerable Primos machines disappeared in the 90's. They didn't have daemons, but phantoms.

    2. Ima Ballsy
      Pint

      Upvoted ....

      Wanted to say how it seems he wants to rule the world ...but you succulently phrased all the good bbits ...

    3. DCFusor
      Coat

      Good encapsulation, Dr S

      "We're seeing the steady destruction of a working, practical system design to satisfy the ego of a Jonny-come-lately. If he wants to design a system to his own notions let him go ahead and do that from scratch and get out of everybody else's hair."

      It'd be nice to leave linux design to Linus' group, methinks. It's not like they've done a bad job so far.

      Other than letting this guy break user-space, that is. Which it has, endlessly on machines here - as soon as you do something a little fancy, like say, auto-mount a network share over wifi, which was broken for years.

      First, it wouldn't mount - though it'd worked for years in fstab. So you used some workaround from systemD almost-documentation or a google search. Then that workaround broke, then the next one.

      Finally, fstab mounting worked again, and you could even tell it to not try to do the mount until there was network! Amazing, almost as good as before.

      Nope - now, since you have to have network before mounting, it had to remove network before dismounting, and your system took endless waits to shut down while it tried and tried to dismount something over a network it had disconnected from. Because, you know, LP knows best and understands all possible interactions. Finally, a few years later, one of the most basic "custom" things seems to work again. Some of us don't have years, or the spare time to fix the workarounds constantly.

      Someone on Phoronix got castigated for sharing this reference to some fundamental issues in the way systemd is done - because it's years old. But not one of those issues have been fixed. Welcome to your new, improved, attack surface. And we're going to let this guy fiddle in security now?

      https://ewontfix.com/14/

      1. Doctor Syntax Silver badge
        Unhappy

        Re: Good encapsulation, Dr S

        "It'd be nice to leave linux design to Linus' group, methinks. It's not like they've done a bad job so far."

        Yes, but as I'm sure you know Linus & Co are only concerned with the kernel. The rest of a Linux distro involves stuff from various Unix implementations, either directly or reimplemented by FSF or others.*

        But the overall composition of a distro is designed by the distro's own maintenance team. We're told they like systemd because it's easier for them and if that's a problem for users it's just a problem for users. This is, to my mind a weakness of FOSS; it's purely developer lead. The theory is that if you don't like it you can just fork it.

        But that's easier said than done, especially if your focus is on using it as a tool to do your every day job. What's worse it seems as if systemd and its dependencies have wormed their way into so much it might become impossible to do a simple systemd-less fork. On the one hand it seems to be taking Devuan a long time to get their Buster based version out (although Knoppix seems to have managed) and on the other I came across a Debian status email which floated the idea that they gave up attempting to provide a theoretically possible sysv option.

        I think I might be coming to the end of the line with Linux.

        * Hence Stallman's insistence on calling it GNU/Linux although this ignored many other contributions.

        1. jake Silver badge

          Re: Good encapsulation, Dr S

          "it might become impossible to do a simple systemd-less fork."

          So don't use such a fork. Instead, use a distro that never implemented systemd in the first place. Simples.

          I use and recommend Slackware. Try it. You might like it. There are other options; most won't cost you anything but a little time and bandwidth to try. Don't forget the BSDs and Minix (surprise!), they have viable options for most folk's desktops.

          1. Doctor Syntax Silver badge

            Re: Good encapsulation, Dr S

            As more and more of userland gets pottered about with upstream in order to make it work with the vampire squid it might be more difficult to maintain such distros without forking more and more of them.

            1. Kabukiwookie

              Re: Good encapsulation, Dr S

              That's because when you want tonuse Linux in a business, which usually means that piad support is a requirement, there's only one option to go to.

              Linux is dying because of this monopoly.

              Devuan needs to move into second gear and offer enterprise support.

              1. steeplejack

                Re: Good encapsulation, Dr S

                piad?

              2. Michael Wojcik Silver badge

                Re: Good encapsulation, Dr S

                Only one option? We have quite a few customers using SLES, and some using Oracle's Linux distribution (I won't speculate why). Red Hat (now IBM) may be the biggest player in the commercially-supported Linux game, but they're not the only one.

                For now, anyway. I assume that's part of King Lennart's world-domination plan.

          2. CrazyOldCatMan Silver badge

            Re: Good encapsulation, Dr S

            I use and recommend Slackware

            [Misty-eyed wibbly-wobbly moment]

            The first linux distro I ever used was Slackware - back in 1995 or so..

            Nowadays I use Devuan - all the advantages of Debian but without the taint of Systemd

        2. NATTtrash

          Re: Good encapsulation, Dr S

          On the one hand it seems to be taking Devuan a long time to get their Buster based version out...

          One can ask oneself: would this be why MX is taking off so well? I would agree that this sysD stuff goes way over the head of the "average user" (if there is such a thing), but there is no denying that MX assent is remarkable. Whether the "non-sysD" part is driving it yes or no...

          I'll be honest: I don't like what/ how LP communicates. But viewing this objectively, it's only fair to acknowledge that there are different design philosophies, and each one has its right to have a go at it. What troubles me more is that, if an user, in an environment/ fundamental philosophy that marks "free, unfettered user choice" as its highest value and asset, wants to operate a sysD free system, the choice become very small indeed. All the big, user popular distros like e.g. Debian, Mint, *buntu, Manjaro, all demand a "sysD or piss off" approach. Which does sound Redmondish/ Cupertinoride to me. Then again, most users concern doesn't stretch further than "the new exciting new wallpaper"...

          1. ibmalone

            Re: Good encapsulation, Dr S

            Poettering sounds like a man trapped in a fever dream, stuck in logical circles where he has to decide between state and configuration and to make sure all the rows are neat he must rebuild everything from the ground up.

            Somebody point out to him that configuration is necessarily a type of state and possibly give him a weak sedative till it passes.

            1. steeplejack

              Re: Good encapsulation, Dr S

              I cannot imagine that LP keeps getting his suspended laptop stolen and processed by people who freeze the RAM. So for one man's obsessive theory-based "itch" the rest of the world has to be disrupted.

          2. Doctor Syntax Silver badge

            Re: Good encapsulation, Dr S

            "On the one hand it seems to be taking Devuan a long time to get their Buster based version out...

            One can ask oneself: would this be why MX is taking off so well? "

            Like Devuan, the MX stable is still Debian Stretch, i.e. Debian 9, not 10.

      2. Ben Tasker

        Re: Good encapsulation, Dr S

        > auto-mount a network share over wifi, which was broken for years.

        Oh god, SystemD and fucking mounts.

        I got hit by this the other day.

        Replaced a failed disk, updated fstab and ran mount. No errors, but the things not mounted.

        System-mother-fucking-D was automatically unmounting it in the background. Why? Because at boot, it reads in fstab and creates a unit for each mount.

        At boot, fstab said that /dev/sdb (or whatever) should be mounted at /foo. So there's a unit saying that /dev/sdb goes to /foo. /dev/sdb no longer exists, so that unit's automatically inactive.

        fstab now (correctly) says that /dev/sdc should mount to /foo. So when you run mount, that's exactly what happens.

        But then systemD sticks it's grubby little nose in, decides it's a conflict and unmounts the fucker, quietly pushing 2 lines into the journal. Not dmesg though, no. Unless you run journalctl you won't see it.

        Turns out, you need to do a systemctl daemon-reload to make it go and regenerate the units.

        Unsurprisingly this annoyed me, then I found the SystemD bug and saw it had annoyed others to. Still not fixed, but there is a "workaround" listed in there for when a daemon-reload doesn't work (as is apparently sometimes the case):

        > Remove the line from /etc/fstab and mount it manually (or use a startup cronjob script).

        SystemD is fucking useless.

        Based on the reports in that bug, Poettering should be less concerned about whether someone can decrypt his home after suspend, and more concerned about whether he'll be able to mount the fucking thing after a suspend.

        1. whitepines
          Flame

          Re: Good encapsulation, Dr S

          To this day we have production(!) VMs that won't shut down any more thanks to systemd. They get to the end of the shutdown process and systemd decides to navel-gaze forever trying to digest the fact that it's not running on some crappy repurposed Windows laptop, but in a real server environment with these odd things called 100Gig networking and SAN mounts.

          The solution as I understand it wasn't to work around Poettering's pottering (as in "to potter around") old derelict trash by having to constantly devise and apply workarounds on the VMs, but to simply issue shutdown and then kill -9 the VM processes on the host after a 5 minute delay.

          Progress...not!

          1. Kabukiwookie

            Re: Good encapsulation, Dr S

            I said it once before.

            The only thing that Microsoft needs to do is pull Linux down to its own level of mediocrity.

            And Poetering is making it ffing happen.

        2. Anonymous Coward
          Anonymous Coward

          Re: Good encapsulation, Dr S

          Parsing text files for config is a slow legacy solution without full auditing (bar a full config management solution) that is incapable of per field ACLs. Systemd is at least a start to an enterprise grade CMDB like just for instance the Windows Registry Btrieve database based solution. Im sure Linux could do better than the Windows Registry, but it's a clear improvement on dozens of text files.

          1. nematoad
            FAIL

            Re: Good encapsulation, Dr S

            "...but it's a clear improvement on dozens of text files."

            Maybe, but at least with a text file you can actually read the bloody thing and see where the problem is. Or is systemd so infallible so as not to actually need human intervention?

            Any thought of Linux moving to a Windows like registry system gives me the shudders, and yes when I was working I did know how the use regedit. I don't miss that at all.

          2. whitepines
            Thumb Down

            Re: Good encapsulation, Dr S

            Oh good, so we can go into binary hell just like on Windows.

            Poettering Linux 2020: We're sorry, your registry has been corrupted. Please reinstall Poettering Linux to continue.

          3. Kiwi
            WTF?

            Re: Good encapsulation, Dr S

            Parsing text files for config is a slow legacy solution without full auditing (bar a full config management solution) that is incapable of per field ACLs.

            Wait, you're defending this stuff in a thread where it cannot even properly handle mounting disks?

            One commenter in the site Mr Tasker linked talks of wasting over 22 hours on this issue - and you want to try and make out it's faster?

            Others report issues of systemd silently unmounting devices (ie with no warning) and then writing data to the underlying file system where it is not intended to be.

            And you think this is defensible? How about instead of sitting here defending systemd, go and learn how to code and fix the issue that's been a problem for some 4 years now!

          4. Anonymous Coward
            Anonymous Coward

            Re: Good encapsulation, Dr S

            So why are so many newer Microsoft apps using text-based configuration files now?

            1. Anonymous Coward
              Anonymous Coward

              Re: Good encapsulation, Dr S

              So that they can support cross platform compilation and deployment onto legacy OSs that don't have a registry?

              1. Nick Ryan Silver badge

                Re: Good encapsulation, Dr S

                So that they can support cross platform compilation and deployment onto legacy OSs that don't have a registry?

                Or, possibly, because even Microsoft have realised what a clusterfuck the registry is and and are trying to revert this stupidity in their own applications...

                Want to remotely recover an applications from a hung system. Are these settings strewn around in a bespoke registry setting somewhere? With the registry, you're stuffed.

                Is the registry corrupted? Again? Then you better hope that you had a backup of the application's configuration somewhere. Yes, in a text file.

                Want a tree of overlaid configurations where sunsequent configurations overlay each other (permissions permitting). Hey look, IIS does that using configuration files and not the registry.

                ...and it goes on. There are very, very few genuine benefits to an arbitrary database store of commingled settings for all applications on a system, but there are many benefits to have these settings distributed sensibly. A standard OS provided application configuration using a database file? That's possibly a good service for an OS to provide. One 'orrible bunged up binary blob mess of many things all rammed together? Definitely not.

              2. Anonymous Coward
                Anonymous Coward

                Re: Good encapsulation, Dr S

                Nice troll. Go back to reddit.

          5. Peter Gathercole Silver badge

            Re: Good encapsulation, Dr S

            IBM learned about registries all the way back in the 1990's.

            AIX implemented a registry called the ODM with AIX 3.1 on the RS/6000. It went down like a lead balloon with almost every technical user of AIX criticizing it (including many people in IBM itself!)

            Nowadays, although it's still there for some things (like device configuration and software inventory tracking), almost everything else is using flat files.

            This is what experience shows us works.

            1. Anonymous Coward
              Anonymous Coward

              Re: Good encapsulation, Dr S

              900 + million users of Windows 10 says that the Registry works pretty well.

              1. jake Silver badge

                Re: Good encapsulation, Dr S

                And four and a quarter billion flies say that shit makes for good chow. Doesn't mean I'm going to emulate them, now does it?

              2. John Brown (no body) Silver badge

                Re: Good encapsulation, Dr S

                "900 + million users of Windows 10 says that the Registry works pretty well."

                Most of those 900 + million users of Windows 10 wouldn't know a registry if you hit them over the head with it and have no knowledge about whether it works pretty well or not. The rest of the users have 2 or more 3rd party "registry cleaner" programmes selected from the many of them out there because using them can help stave off the day when a full reinstall is the only way to properly repair the registry.

              3. Michael Wojcik Silver badge

                Re: Good encapsulation, Dr S

                900 + million users of Windows 10 says that the Registry works pretty well

                "Doesn't fail completely" << "works pretty well".

              4. Anonymous Coward
                Anonymous Coward

                Re: Good encapsulation, Dr S

                Billions of devices running Linux seem quite happy with text files too. And you'll find it in plenty of places that Windows simply won't fit, so those 'slow' text files aren't looking too bad after all.

          6. fajensen

            Re: Good encapsulation, Dr S

            BINGO! What do I win?

          7. Jaybus

            Re: Good encapsulation, Dr S

            A centralized CMDB is certainly not an improvement. First, text file parsing is not slow and most apps parse their config file(s) within a few milliseconds at most. Also, a centralized CMDB is a single point of failure. The KISS principle does apply.

        3. Dazed and Confused

          Re: Good encapsulation, Dr S

          Turns out, you need to do a systemctl daemon-reload to make it go and regenerate the units.

          That's f***ing stupid, systemd is capable of kicking off an action on a file change. Why aren't they having the unit generator for the mount and device units triggered off the changes to the fstab file. It would help if they used their own features properly.

          1. Kabukiwookie

            Re: Good encapsulation, Dr S

            That's because they went from a clean, small and easy to understand init system to an overengineered, bloated binary log clusterfsck and even the team working on it doesn't know in detail what the fsck is going on anymore.

            That's why.

        4. ibmalone

          Re: Good encapsulation, Dr S

          But why would you ever want more mount points on a laptop?

          What's that you say skippy? You're actually running a server? It has systemd on it because some maniac makes all their design decisions based on how they want their laptop to work? And a bunch of other maniacs thought it would be a good idea to put this person in charge of designing a server OS?

          You think we should just all chip in and buy Poettering a macbook so he'll leave linux alone?

          I don't know skippy, I worry I'm just projecting my thoughts onto the unrelated vocalisations of a wild animal.

          1. CrazyOldCatMan Silver badge

            Re: Good encapsulation, Dr S

            buy Poettering a macbook so he'll leave linux alone

            Oi! What did the Macbook ever do to you? I'm quite happy that the Mac is Poettering-less..

            (Not that Apple haven't made a valiant effort to mess it up over the years - I want a modern 17" Macbook Pro dammit! With a proper keyboard like wot it used to have. And a shell that can survive a full bottle of wine falling on it with only a small dent!)

        5. sitta_europea Silver badge

          Re: Good encapsulation, Dr S

          [quote]

          SystemD is fucking useless.

          [/quote]

          No, I'm sorry to contradict you but that's just plain wrong.

          SystemD is WORSE than fucking useless, it's a fucking liability and I uninstall the fucking thing every chance I get.

        6. Kiwi
          Pint

          Re: Good encapsulation, Dr S

          Replaced a failed disk, updated fstab and ran mount. No errors, but the things not mounted.

          While I slept, deep in the recesses of what passes for a brain, things moved and sparked and gradually a though was formed.

          This morning I phoned a former customer - a nice old guy who retired from IT some time back but still plays with newer hardware. Of late he's been having an issue with removable drives and network stores showing up as present but when he tries to access them they're not there, he has to pull them out and plug them back in again.

          We'd talked of this a while back but nothing in my knowledge of Linux would help.

          I twigged overnight that the issue you refer to might be related, and asked him if he has sillyd on his system. He does.

          Thanks Sir, we may now have a way to resolve the issue! (though I still suggested he may find Devuan or Slackware more to his tastes :) )

          [I won't exactly repeat what he said when he was told it could be StupiD silently unmounting the hardware, and don't bother with your imagination as I don't think you'll match it either. Suffice to say he has experienced a lot of problems and some actual physical pain (has bad arthritis, largely bed-ridden, this fault has meant he's had to get up at times when he's been too sore to do so), and wasted a lot of time faffing around with something not only broken in a StupiD way, but so idiotically designed that it doesn't even report an error in a sensible place/manner!]

    4. hmv

      The user database is in /etc/passwd is it? Someone will have to tell one of my machines :-

      ✓ meredith@someserver» grep meredith /etc/passwd

      ✗ meredith@someserver» getent passwd meredith

      meredith:*:1:1:Meredith:/home/meredith:

      (certain values may have been changed)

      I suspect Poettering may need to acquire some experience with large multi-user systems (which might for example be an LDAP-enabled lab workstation). The notion that the user database is only a file is long outdated - it's merely the default implementation.

      Generating uids randomly sounds like a security problem in the making; I want uids to be unique across a network.

      Change is good; but throwing out backwards compatibility is usually bad.

      1. whitepines
        Facepalm

        Exactly, anyone doing multi-user systems already fixed this with the same overall method used by every other large deployment: Kerberos and LDAP. I'm sitting at a work machine that has the same output; nothing is in /etc/passwd or /etc/group beyond the core system services, and yet somehow magically getent passwd/group works and I have an automounted (at login), link-encrypted (and presumably backend encrypted) network share at my disposal.

        I guess our IT can look forward to Even More Fun! trying to fix Poettering's latest "everything is a laptop!" shitshow. I wouldn't be surprised if we do end up on Devuan or something systemd-free in the future.

        1. Anonymous Coward
          Anonymous Coward

          Does Linux support Kerberoa constrained delegation out of the box without installing a third party ID management solution yet?

          1. whitepines

            What does that even mean? What is "Kerberoa"?

            If it's credential delegation, that's kind of a core feature of the Kerberos stack. I know when I open Kerberos-enabled applications on our Linux systems they use my login-generated ticket to gain access (SSO).

            1. Androgynous Cow Herd
              Joke

              Simple English.

              Kerberoa is the plural of Kerberos. For when you have more than one.

              You might need more than one Kerberos if you really want two factor security.

              1. whitepines
                Joke

                Re: Simple English.

                Or several Kerber Boas. They're like normal boa constrictors, but bigger and more digital. They can sense the h4xz0rs kilometers away, but seeing as one Kerber Boa can eat only one h4xz0r you need at least three under / on your desk for any real security...

              2. Michael Wojcik Silver badge

                Re: Simple English.

                You might need more than one Kerberos if you really want two factor security.

                Nah. Each Kerberos already comes with three-factor security. Plus four paws for backup.

            2. Anonymous Coward
              Anonymous Coward

              Clearly it's a typo of Kerberos. Delegation is different from SSO.

              Kerberos delegation is where for instance you log into a web front end and that web front end can use your Kerberos credentials to authenticate against remote services such as say a database rather than using say a privileged service account and having to assign user permissions at the web front end.

              Kerberos constrained delegation allows you specify delegation access permission on a per service basis.

              1. werdsmith Silver badge

                The proximity of A & S on the mainstream English language language keyboard you see. The typo should be instantly recognisable as such.

                1. Kabukiwookie

                  No shit sherlock.

                  1. werdsmith Silver badge
              2. Michael Wojcik Silver badge

                Kerberos delegation is where for instance you log into a web front end and that web front end can use your Kerberos credentials to authenticate against remote services such as say a database

                That's not "Kerberos delegation". That's the specific basic thing Kerberos does. The front end solicits authentication from the user and passes it to the TGS, and gets a TGT. Then it can use the TGT to get service tickets for whatever remote services it needs.

                That's what Kerberos does. If you're referring to something else, you haven't done a good job of explaining it.

    5. Anonymous Coward
      Anonymous Coward

      >>>> "We're seeing the steady destruction of a working, practical system design to satisfy the ego of a Jonny-come-lately. If he wants to design a system to his own notions let him go ahead and do that from scratch and get out of everybody else's hair"<<<<

      I agree entirely. The problem is when his things start to leak into 'sane' distrubutions, or even into the BSD's, simply because people start writing their stuff to work the insane way, and no way else... (witness alsa compatibility in bsd etc)

      It's like brexit - I wouldn't care what they did if it wasn't for the fact that their foolishness will affect me too.

  3. Chronos
    Facepalm

    One task done properly

    The corollary I'll leave you to work out. SystemD is almost Microsoftish in its tentacle spawning creep to engulf anything with which it comes into contact. The idea is fine, the execution in PID 1 is not.

    1. HereIAmJH

      Re: One task done properly

      It's worse than that. It's Microsoftish at a Windows NT/2000 level. Microsoft has improved over the last two decades and SystemD has Linux distributions targeting where Windows used to be.

      Frankly, if this is the direction that Linux is going to go, why not just use Windows?

      1. whitepines
        Alert

        Re: One task done properly

        Frankly, if this is the direction that Linux is going to go, why not just use Windows?

        I agree with the sentiment, but I wouldn't touch that steaming pile of Redmond CCTV with a barge pole. BSD, Mac, even Fuschia, but no, not going back to Windows bondage thank you very much.

    2. Kabukiwookie

      Re: One task done properly

      If the news would ever come out that Poetering is on Microsoft's payroll I would not be surprised in the least.

  4. Steve Button Silver badge

    If you really want that this system can come up on its own, don't use this stuff.

    OK noted. I really do (1). I won't (2)

    (1) Want the system to come up on its own.

    (2) Use this stuff.

    But I'm a server admin.

    1. Androgynous Cupboard Silver badge

      Re: If you really want that this system can come up on its own, don't use this stuff.

      Yup. Some of the ideas posited have merit, but once again he's solving for one particular use-case and ignoring the others, just as he did for pulseaudio.

      The end result will be either workflows being adjusted to match the designed-for use case, or fragmentation into a "server" and "desktop" approach to managing users. Hooray.

      1. DCFusor

        Re: If you really want that this system can come up on its own, don't use this stuff.

        A recent raspian distro had to leave out pulseaudio because, in LP's words, it "exposed flaws in poorly written audio drivers" - eg the mainstream ones for build in audio and for the ubiquitous USB dongles.

        Could the systemd guys not lift a finger to even tell the driver writers what they meant, or by golly, submit fixes to upstream for some really basic stuff they complain isn't right? Nope, can't be arsed.

        Which of course, required more workarounds to get background music playing in one app to be interrupt-able or mixable with audio for some important announcement/page - something that had worked for years without any effort.

        Haven't even removed the workaround on newer ones, or tested it it's still required. I have other things to do.

        1. JohnFen

          Re: If you really want that this system can come up on its own, don't use this stuff.

          It's been my normal practice for a long while now to remove PulseAudio from my installations. Doing so makes life easier.

        2. Anonymous Coward
          Anonymous Coward

          Re: If you really want that this system can come up on its own, don't use this stuff.

          You think that's annoying... Try fixing a pulse-audio problem on Freebsd, which already has an implementation of oss that doesn't require such hacks as pulse-audio, but has to cope with software written to only work with pulse-audio, hence requiring pulse-audio porting to the platform that doesn't need it!

        3. Anonymous Coward
          Anonymous Coward

          Re: If you really want that this system can come up on its own, don't use this stuff.

          Are you sure that they didn't? Shit drivers should be called out and fixed.

          That's why Windows has a driver test suite that must be passed before they will be digitally signed.

          1. Anonymous Coward
            Anonymous Coward

            Re: If you really want that this system can come up on its own, don't use this stuff.

            "Are you sure that they didn't? Shit drivers should be called out and fixed."

            lol pottering and cult members can't even be bothered to fix their own shit when called out..

            potty twat needs to go fuck himself with a rusty spoon..

    2. steelpillow Silver badge

      Re: If you really want that this system can come up on its own, don't use this stuff.

      So how easy to not use it will distros like debian make it?

      I use devuan for a reason.

      1. Doctor Syntax Silver badge

        Re: If you really want that this system can come up on its own, don't use this stuff.

        "I use devuan for a reason."

        Me too but I'm getting worried as to how long it will be able to survive as this garbage gets further and further into the upstream. I came across this https://lists.debian.org/debian-devel-announce/2019/09/msg00001.html from the current Debian project leader. Scroll down to "Init System Diversity". It's not very cheering.

        1. steelpillow Silver badge

          Re: If you really want that this system can come up on its own, don't use this stuff.

          Yeeks! Emotional exhaustion, "it-would-take-me-too-long-to-tell-you-why-I'm-not-going-to-tell-you-anything". What a great environment to drop new home directory paradigms into. This is not the place to make helpful (ahem) suggestions, but one does wonder how long the momentum can be kept up.

  5. Marki Mark
    Mushroom

    I might have been tempted to pay attention, but since he's resposible the systemd shit storm he has no credibility with me...

    1. Doctor Syntax Silver badge

      Perhaps you need to pay attention. It's likely to be shoehorned in within the next couple of years or so. Maybe sooner than that, who cares if it's too buggy for release? It's probably intended to introduce enough dependencies into regular prorams to make the likes of Devuan and Slackware finally impossible. It's going to be BSD or nothing.

      1. Captain Hogwash

        Re: It's probably intended...

        Maybe, but why?

        1. Pirate Dave Silver badge

          Re: It's probably intended...

          Poettering is involved, the "why" doesn't matter, only the "fuck you, I'm smarter" matters.

      2. sbt
        Happy

        "It's going to be BSD or nothing."

        That's an easy choice; BSD. I'd choose BSD over many things that are not nothing, as well, including pretty much all distros shipping systemd. Raspbian's OK as a default install if you're just being an end user.

        1. JohnFen

          Re: "It's going to be BSD or nothing."

          If I switch to BSD, one of the first things I'll do is begin working to port it to the R-Pi.

          1. sbt
            Go

            I have good news.

            You can already run FreeBSD on the Pi. It's been supported since the first Pi and part of core since 11-STABLE. They're working on official support for the Pi 4; see https://wiki.freebsd.org/arm/Raspberry%20Pi

            1. werdsmith Silver badge

              Re: I have good news.

              That's good news. Linux is now consigned to ToyTown as far as I'm concerned. My test environment VMs for personal projects have gone to BSD, I'm changing to a BSD cloud service and whilst it will be sad to step away from the core support on Pi, the linux world is now too toxic.

            2. JohnFen

              Re: I have good news.

              That's awesome! It makes the idea of switching all my machines to BSD much more attractive.

      3. Citizen99

        "...intended ... dependencies ... likes of Devuan and Slackware ... impossible"

        I'm already seeing dependency issues trying to run my 'heritage' Debian-packaged applications on Devuan. Not necessarily available on other non-systemd systems. And in my late '70s I have neither the time or stamina to compile from source. Poettering, kindly leave my machines alone.

      4. Chronos

        Having been a maintainer of several FreeBSD ports in the past, I have to point out that *BSD isn't an option if so many of the applications we rely on not to use "Linuxisms"¹ assume SysD is in place. It'll make porting, supporting and using said applications a bloody nightmare. Shims that fake SysD's APIs are all well and good but many simple things rely on direct access and edge cases that aren't covered because Poettering moved his mouse or it simply wasn't exposed in normal usage are legion. If the default in the *nix world is to do all of this via SystemD, your worldview from an alternative environment becomes increasingly narrow.

        Bottom line is if Slackware and Devuan become impossible, so do many of the ports in the *BSDs. What is actually needed is education of distro maintainers in Unix fundamentals such as One Task Done Properly and code portability. SystemD is almost proprietary in its effect.

        ¹ See the porters' handbook for details.

    2. Anonymous Coward
      Anonymous Coward

      One wonders if LP is actually a stealth MS employee or plant, attempting to destroy Linux from within.

      1. Kiwi
        Devil

        One wonders if LP is actually a stealth MS employee or plant, attempting to destroy Linux from within.

        I gave up wondering that a long time ago.

        While I am not at all convinced he is a plant from MS, I am quite concerned that he does not have Linux and it's users best-interests at heart.

        Whoever pottything works for, it's not for the good of the Linux community, nor for the good of humanity.

        1. Anonymous Coward
          Anonymous Coward

          Pottering around at RedHat

          "Whoever pottything works for, it's not for the good of the Linux community, nor for the good of humanity."

          I read somewhere that he's been a RedHat employee for several years. So you could well be correct.

          [09:58 UTC]

          1. SImon Hobson Bronze badge

            Re: Pottering around at RedHat

            Yes, that's my understanding.

            RedHat make their money from users needing support services, something reliable and easy to fix if it does go wrong doesn't make much money in support - something that needs "experts" to fix anything results in lucrative support contracts.

            1. ROC

              Re: Pottering around at RedHat

              And now IBM's ownership of RedHat just amplifies the effect...

  6. Scotthva5

    Insert "systemd is evil" comment here

    'nuff said.

  7. sw guy

    Solving not existing problem

    When at work, using workstation set by IT team, I have a user-name and a home-directory, but no grep command on well known files will be able to link both, because IT team knows its job. Thus, while I remember that yellow pages were invented years ago, I do not even bother to know whether it is still in use or something newer is in use.

    Of course, when network is not reachable, I cannot connect. But it does not matter as I cannot work either.

    1. Chronos

      Re: Solving not existing problem

      LDAP/Kerberos. It's one of the very few things MS got right - then screwed it up by requiring a load of proprietary nonsense in DNS to make it work¹, compounding that by making realms so complicated so as to be completely unrecognisable to even the experienced *nix admin. Linux just requires a couple of config files, a PAM module or two and an nsswitch tweak.

      FSVO of "making it work" which MS deems as being "when nothing but Windows can use it"

  8. Ben Tasker

    However, it may not be such a problem in practice, since the focus of this solution is end users with laptops rather than servers, and remote login to a laptop is not common.

    This is still ultimately going to end up on a server though, isn't it. And you _should_ be making users log into their own account and then elevate privileges so that you have an audit trail.

    I mean, half the problems SystemD claims to fix are focused on laptops, and yet systemd is still in every fucking server distro by default.

    I took the time to learn how to use SystemD because I could see that there was going to be no avoiding it, I *still* fucking loathe it, and rather than making it better, he's talking about adding more shit to the suite.

    1. simonlb Silver badge

      If the intended audience for this is laptop users, then there is no justification for making it a core component in every install. Have it as an optional component to install as required.

      1. Rich 2 Silver badge

        You're right. There is no justification. But it will happen all the same

      2. Doctor Syntax Silver badge

        I use Linux on a laptop and I still don't want systemd.

        1. jake Silver badge

          I use Slackware on a laptop and never have to think about systemd.

          (Actually, I do have to think about it, alas. Can't explain to a table full of C*s why their distro of choice is not a good idea without understanding that distro at a fundamental level ... The more I know about systemd, the less I like it.)

      3. damnyankee

        And yet- NetworkManager is mandatory on EL8, and RedHat's blog covered how AWESOME IT IS FOR SERVERS.

        Here's the thing: In spite of that blog entry, and all of RedHat's cheerleading, I can't conceive of a genuine use case where I want a server to have multiple possible configurations for a single network interface and to choose between them.

        Systemd jacking around with fstab is well documented.

        systemd also, and this is my favorite, consistently loses track of if services are running, leaving them in a state where they can neither be started nor stopped, because systemd failed at the one thing it should theoretically do.

        "A Problem Lennart had once on his laptop" seems to be the entire use case for all of his projects, and RedHat seems hellbent on forcing those as dependencies everywhere and deploying them on something that is supposed to be "Enterprise Linux"

        1. vgrig_us

          Looks like you can still disable networkmanager. Need to install "deprecated" network-scripts package... Thank god!

        2. JohnFen

          "RedHat's blog covered how AWESOME IT IS FOR SERVERS."

          Hell, it's not even awesome for non-servers. NetworkManager is a serious pain in the ass for all but the simplest of configurations.

        3. Mark 65

          The problem on Lennart's laptop is the sack of s**t that sits in front of it

    2. Kiwi

      However, it may not be such a problem in practice, since the focus of this solution is end users with laptops rather than servers, and remote login to a laptop is not common.

      This is still ultimately going to end up on a server though, isn't it. And you _should_ be making users log into their own account and then elevate privileges so that you have an audit trail.

      Not only that, but I do often remotely log into people's laptops from a user account that should NOT be running. Where I do maintenance etc work for various family and friends, I keep a way to go in via SSH. Also I have my own machine often at home where it may be on but me logged out (or where it's off but I ask someone else to turn it on). I have auto-login disabled where others can readily get physical access, but pottything seems to think that "for security", in order to maintain my 'workflow', I need to have the system automatically log me in?

      (El reg - where the hell is our "despairing for humanity" icon?????? I suggest a picture of pottything itself would suffice!)

    3. Zolko Silver badge

      Ben Tasker : "half the problems SystemD claims to fix are focused on laptops"

      that's not how I remember it, I saw systemd being targeted for VM-hosted server-farms. There is absolutely no benefit of systemd on laptops, but since I don't run servers in VMs I thought that there might be use-cases I'm not aware of. Now, if laptops are the real targets then that removes even that small reason for systemd.

      Unfortunately Devuan Ascii comes with kernel 4.9 and my laptop needs at least 4.15. And I can't get hold of a Devuan Beowulf download ISO. Especially one as KDE LiveCD. I'm just trying an MX respin, let's see.

  9. Jay 2

    "I want my own laptop finally secure so I can suspend. I want these problems to be solved, finally, because we never could solve them," he said.

    Fine, fuck up your own laptop for your own particular needs and let the rest of us live and work in peace! I understand the need for security, but there are differences to what he needs to do in a coffee shop on his precious laptop and what a large amount of us want to do on multitudes of enterprise servers.

    And I'll have to put the obligitory systemd rant in too. I can understand the problem the problem it was attempting to solve and I understard how (using modules/dependancies) it intened to do it. But unfortunately the implementation leaves a lot to be desired...

    1. R3sistance

      It is easy to say that systemd leaves a lot to be desired but the problem is that nobody else made an alternative that gained any kind of wide-scale adoption to replace the very much legacy sysvinit. So yes, while there are systems much more in-line with the linux design philosophies, they weren't popular. Generally speaking this can be put down to the alternatives leaving far more to be desired or failing to meet some basic criteria in real-world usage.

      1. Adair Silver badge

        That's a maybe.

        It's also possible that Systemd was pushed for political reasons as much as anything else, i.e. it wasn't about being 'the best' option, just the one that happened to work well enough on a technical level, but also happened to be being pushed by a particular person/people at a particular time and place that suited certain other peoples political and financial agendas.

        This happens all the time: witness the rise of Microsoft and their broken Windows. You wouldn't choose it if you had a choice of decent OSes, but here it still is... still of questionable quality, but tolerated and abused by millions.

        1. R3sistance

          You'd need to take a too narrow a view to get stuck on this for all systemd's adoption. Obviously SystemD being developed by Red Hat engineers such as Poettering, we saw it first coming from the Red Hat/Fedora side. But this does not then explain adoption by other Distributions like Debian or Ubuntu. I think it more likely that there are actual real-world reasons to explain this and I'd put this back to it being for the Enterprise and not for the expert user.

          Obviously there are many distributions that do not use SystemD still, and some branches of both Debian and ubuntu that do not use SystemD.

          1. vgrig_us

            Dependancies in core system components and other software make running without systems close to impossible. And guess who develops or has a major say in development of those? A certain IBM subsidiary...

            So distros are really forced to use it. You can't run gnome3 without it as far as I know.

            1. R3sistance

              still waiting on IBM to rebrand it blue hat and to kick out anybody over the age of 40.

              Red Hat have a lot of say but they are not tyrannical dictator with full veto power against anything that they do not like, and there are still many distros which do not use systemd.

              1. Michael Wojcik Silver badge

                kick out anybody over the age of 40

                Hmm. Lennart turns 39 next month. A silver lining for IBM agism?

            2. eldakka

              > You can't run gnome3 without it as far as I know.

              And this is a problem?

              1. vgrig_us

                @eldakka "as far as I know" part should've made clear how little of the problem it is for me personally.

                However - no major distro can possibly omit gnome3.

                1. eldakka

                  I use Gentoo which allows me to omit both Gnome3 and Systemd.

                  As does Devuan.

                2. ROC
                  Black Helicopters

                  Mint 17/18/19 with MATE, which keeps the Gnome2 look/feel I grew used to over the last 10 years or so (as my non-techie teacher wife did, following my lead since I was not interested in supporting her school issued Mac, nor Windows), but it still has drunk the SysD koolaid. Guess I need to start re-acquainting myself with BSD's, ando/or Slackware again...

                  1. Kiwi
                    Pint

                    Mint 17/18/19 with MATE, which keeps the Gnome2 look/feel I grew used to over the last 10 years or so

                    Devuan uses Mate. Not as "polished" as with Mint, but while I noticed it at first (going from Mint 17 to the Devuan before Ascii) I don't notice it now. A couple of panels (top and bottom) that autohide when I'm not doing stuff, and if the window borders/icons etc are something I'm noticing then there's a problem with the content of the page I'm looking at :)

            3. jake Silver badge

              "You can't run gnome3 without it"

              You say that like it's a bad thing ...

          2. Carpet Deal 'em

            But this does not then explain adoption by other Distributions like Debian or Ubuntu.

            Debian has Red Hat people on its controlling board and Ubuntu is ultimately a Debian derivative.

          3. Zolko Silver badge
            Paris Hilton

            R3sistance : "I think it more likely that there are actual real-world reasons to explain this"

            funny how I often read this, but never, ever, actually have seen any real-world examples where SysV-init wouldn't work. To me systemd looks like a solution in search of a problem. Theorethical problems are invented, and many people feel that there must be some sort of very technically skilled people that actually do need this but they are afraid to look not skilled enough therefore accept this crap ... wasn't there a story about an emperor and his cloths that told exactly this ?

        2. Doctor Syntax Silver badge

          "suited certain other peoples political and financial agendas."

          Once it got shoe-horned into Debian we were left with the situation that the only major systemd-free server distro was Red Hat 6. Hmmm.

          1. jake Silver badge

            I use BSD on the servers. Horses for courses & all that.

            That said, Slackware makes for a rather good server OS, when setup by a competent admin.

            (Before anybody says "But how many of us are competent admins? What about my Great Aunt Martha??? Frankly, if you're not competent, you have no business setting up servers. And besides, your Great Aunt Martha has never installed an OS of any description, and isn't going to start anytime soon, regardless of the machinations and mewlings of poettering and his ilk.)

            1. Dan 55 Silver badge

              Frankly, if you're not competent, you have no business setting up servers.

              How would ever get round to setting up your first server then?

              1. jake Silver badge
                Pint

                "Baby's First Server" is not actually a server, it's a learning tool.

                Semantics? Perhaps. Have a homebrew & think about it :-)

              2. katrinab Silver badge
                Paris Hilton

                Take a retired desktop PC. Strip out stuff like sound cards that are not needed on a server. Download some server operating systems and play around with them.

            2. Doctor Syntax Silver badge

              "And besides, your Great Aunt Martha has never installed an OS of any description"

              How do you know, you've never met my great aunt Martha?

              1. jake Silver badge

                "How do you know, you've never met my great aunt Martha?"

                I was going with the odds.

              2. Michael Wojcik Silver badge

                "Have you ever used an electronic digital computer?"

                "Yes."

                "And where was that?"

                "My aunt has one."

        3. Kiwi
          Pint

          still of questionable quality, but tolerated by and abusing millions.

          FTFY

      2. Santa from Exeter

        The only thing that made sysvinit legacy was the likes of Poettering declaring it so. He appears to want to replace the whole of the perfectly useably text file based infrastructure with stupid binary blobs or databases. The beauty of flat files is that you can grep them, diff them, even tkdiff them if you must! Binary logfiles are a stupid idea to anyone who administers servers which sometimes have issues!

        1. R3sistance

          sysvinit was seen as legacy way before SystemD became a thing and there have been multiple previous attempts to replace it (i.e. runit). If you're solely relying on the logs on the local server, then you're already doing something wrong in the first place, at least at minimum have a proper syslog server and forward your logs, if not getting something like Splunk or ELK. Grep is great but using it for say scanning 1GB+ log files on a loaded production DB server is just a no, very bad practice.

          you can still use text based files in systemd for launching services/daemons but the issue is that this really gives no real comprehension of process state and that is problematic in a professional enterprise environment, which is part of the reason why sysvinit really is legacy. Also the whole single threaded initialisation process and multiple other issues, since sysvinit has no real comprehension of dependancies either.

          1. Doctor Syntax Silver badge

            "the issue is that this really gives no real comprehension of process state"

            Exactly. Because it's all hidden in the great morass of systemd.

            Anyone with the basic shell skills needed to administer a Unix-like system can develop the script st the terminal before deploying it.

            And your belief about searching the log database or logging to a remote server doesn't get you very far in trying to sort out a non-booting box without being able to make sense of whatever logs it managed to write. Even the remote logging depends on the box being able to get itself as far as being onlne.

            1. R3sistance

              If you're using imjournal, then your logs on the syslog server will be readable, you haven't even tried looking into it have you?

              Also systemd reports to you the state of the process, it's pretty simple, systemctl status <name>, in sysvinit you'd need to have a cron or another daemon checking constantly against the script and hoping that you haven't missed any cases where the process might not be in the expected state in your scripting, whereas systemd you have the process respawn itself on failure, or you can make it e-mail you.

              Seriously in the time I've worked in an MSP, the amount of sysadmins I've seen generate terrible little scripts that they are so proud of and thinking it's production applicable when in reality it should get a very fast rm -f... is too many too count. Scripts are great when done well, the problem is all the people that think their scripting is up to par when it isn't. Good scripts need heavy peer reviewing, testing and maintenance before being deployed properly (not just cut/pasted or SFTP/Rsynced into place). Unlike the 25 line scripts somebody usually places on to some random server is a bad practice that just makes things bespoke and so so bad for production.

              1. Doctor Syntax Silver badge

                Wow. I'm left wondering how all those real Unix/Informix systems I used to manage ever staggered into life. Systems which ran large and small businesses for years. Systems from V7 through System III to System V.

                1. ROC

                  Well, from what I recall of Solaris 10's System Manager (forget the exact name as I last used it about 4 years ago before I retired from web app server support for a big global biz but, close enough), it seemed to work a lot like SysD, and was a more comprehensive way to manage clustered and otherwise linked servers. As I have monitored the brouhaha over SysD on Linux, it has struck me as a Solaris Sys Manager wannabe, only more problematic by all accounts.

              2. JohnFen

                "the amount of sysadmins I've seen generate terrible little scripts"

                Hire competent sysadmins.

                1. Reaps

                  "Hire competent sysadmins."

                  how would someone who doesn't know they are incompetent do that?

                  1. jake Silver badge

                    "how would someone who doesn't know they are incompetent do that?'

                    Are you seriously suggesting that the usability of everything should be dropped down to the user level of the lowest common denominator?

                    It's going to be awfully difficult to cook your pizza without heat.

          2. Ben Tasker

            > at least at minimum have a proper syslog server and forward your logs,

            And when JournalD shits itself and stops forwarding? It happens.

            > at least at minimum have a proper syslog server and forward your logs,

            That's fine if you're working on a very local scale. It doesn't work nearly so nicely when you scale up to global scale. Don't get me wrong, it's a nice tool to have, but you don't want to have to rely on it alone.

            It's also not much use if journald gets stuck and stops forwarding, or if your box is failing to boot in the first place.

            1. R3sistance

              "And when JournalD shits itself and stops forwarding? It happens."

              That's hardly an excuse to not be sending logs to syslog however. Just because you're using syslog server doesn't mean you automatically stop also having local copies of the same said log files too.

              "That's fine if you're working on a very local scale. It doesn't work nearly so nicely when you scale up to global scale. Don't get me wrong, it's a nice tool to have, but you don't want to have to rely on it alone.

              It's also not much use if journald gets stuck and stops forwarding, or if your box is failing to boot in the first place."

              Considering I work primarily in the global scale, no, it's definitely nicer in the global scale, more so when you can use something like Splunk or ELK to compare error logs from different servers. It's also nice when say /var goes read only but you still get logging occurring, cas /var can also go read only, it happens.

              As for servers that have boot issues, if you're truly at a global scale then you'd probably just replace the server out. Drain everything it is doing to another server and get it diagnosed later, removed, replaced or re-installed. If you're at global scale, you should have decent higher availability in place after all. No point worrying about servers going bespoke because somebody came up with a cunning plan to fix some strange boot issue or having to worry if somebody really fixed the corrupted root file system/etc.

              1. Ben Tasker

                > As for servers that have boot issues, if you're truly at a global scale then you'd probably just replace the server out.

                That's only really feasible if by "global scale" you mean - all my kit is in easy-to-reach, or otherwise manned datacentres. Which isn't always true.

                When that kit is somewhere like Timor Leste (for example), that's not quite so straight forward.

                Yes, you can drain the traffic and serve from elsewhere, but now you're dealing with increased latency for the duration of a remote re-install to somewhere with shakey international connectivit, or, waiting weeks for hardware to be swapped out (look how often the boat to TL is ;) ). All

                because some berk didn't like text logs?

                That shakey international connectivity btw? Also a bit of a shot-in-the-head for centralised ELK/Splunk. Working on Global scale doesn't always mean you're solely in big D/Cs with masses of international uplink, sometimes you're in the back-of-beyond, closer to the users

                Colour me cynical, but "one size fits all" is no way to run a network.

                1. R3sistance

                  "That's only really feasible if by "global scale" you mean - all my kit is in easy-to-reach, or otherwise manned datacentres. Which isn't always true."

                  Not even remotely true, You can have these things called "spares", a lot of DCs have on-site technicians or engineers as well if it comes to requiring physical replacement. Some companies will replace entire racks out if a single server fails with equipment all over the world, the fact that a sys admin might be in the US isn't going to prevent them from replacing out a rack in Austria. If you're at that scale, you aren't ever going to be relying on a single person, that'd be dumb past belief.

                  "Yes, you can drain the traffic and serve from elsewhere, but now you're dealing with increased latency for the duration of a remote re-install to somewhere with shakey international connectivit, or, waiting weeks for hardware to be swapped out (look how often the boat to TL is ;) ). All

                  because some berk didn't like text logs?"

                  Well apparently the set-up I'm dealing with is considerably better than the one you're dealing with since where I work, there are solutions to ALL those issues already. If you bother to do your set-ups correctly from the start you're not going to end out with most these problems.

                  "That shakey international connectivity btw? Also a bit of a shot-in-the-head for centralised ELK/Splunk. Working on Global scale doesn't always mean you're solely in big D/Cs with masses of international uplink, sometimes you're in the back-of-beyond, closer to the users"

                  If you're running your systems on the customer site, you can still have a localised syslog server. Sure a centralised ELK/Splunk would be better but it doesn't stop the ability to log to more than just the local server.

                  1. Kiwi

                    Er, you know the far side of the Andromeda galaxy? You'll find Ben Tasker's point somewhere over there, you missed it by that much.

                    You claim to work for a large organisation that can afford to have spares waiting around in large warehouses - but you completely miss that not every organisation can do that.

                    Mr Tasker used the example of Timor Leste, and made a note of suggesting you take note of the shipping schedules. When the boat is that rare, do you have any hint of a clue how precious, and expensive, cargo space is?

                    Not every place has the room to store spares - which do need a reasonable level of protection after all, from the elements, the animals, and the locals who find buying a little food a lot more important than any morals that would otherwise protect your stores.

                    I haven't worked on a "global scale" but I have worked on IT projects related to small island nations - nations where the nearest to an IT technician may be a few day's boat ride away - places where data is priced in the dollars-per-megabyte (though the infrastructure has much improved in the last few years).

                    For a lot of organisations, "spares on site" isn't even remotely feasible.

                    Well apparently the set-up I'm dealing with is considerably better than the one you're dealing with since where I work, there are solutions to ALL those issues already. If you bother to do your set-ups correctly from the start you're not going to end out with most these problems.

                    Nice to work for a large organisation that doesn't really care about a budget and just tosses money at any problem. Not every one has that sort of luxury. Lets see you build and run a server where your entire annual IT budget is - and I'm being quite generous here - $US1,000. That's all hardware, software, data and labour, for a full 12 months.

                    I've helped someone build stuff for a small nation with extremely limited resources, where you have to justify every pound of weight you're shipping and every cent you spend on hardware/software because if you go over weight, then something has to go on a later boat (which, BTW, might be another month away - or two if there's a storm/engine failure etc). There was considerable debate over using a 2.5" backup drive over a 3.5". The cheaper purchase price of the latter would be outweighed by the cost of transport, and we had to consider the generally greater reliability of the latter vs the lower power requirements of the former.

                    You should try working for people on a tight budget, it'll teach you a lot about your comments :)

                    You claim BT's comment is "not even remotely true", yet you clearly have no experience or even concept of some of these situations that other people live in.

                  2. Ben Tasker

                    > Not even remotely true, You can have these things called "spares", a lot of DCs have on-site technicians or engineers as well if it comes to requiring physical replacement.

                    You seem to have skipped part of my post.

                    I gave an example of Timor-Leste. Let me tell you about the TL D/C.

                    It's unmanned and (unsurprisingly) on the island of Timor-Leste. Space is incredibly tight, TL is small, and the D/C is even smaller. So, no, you can't really justify dropping another box in to run Splunk.

                    There's 1 boat there a week - your remote hands will need to get that boat, fit/replace the kit *and wait a week* to get home unless he's exceptionally speedy at doing it - after you've paid a pretty exorbitant price for the cargo space.

                    Connectivity to TL? I mean, it exists, but it's pretty fucking limited.

                    You seem to interpret Global scale as "I've got servers across the world". Whereas I'm interpreting it as - I've got locations fucking everywhere. Big central locations, and lots of little fingers with much more limited connectivity.

                    > Well apparently the set-up I'm dealing with is considerably better than the one you're dealing with since where I work, there are solutions to ALL those issues already.

                    You've an unmanned D/C on TL, with enough local demand to justify the existence of the kit there. You don't have particularly good international uplinks available - even the links over to ID are pretty poor.

                    What solution do you have for that which is better than not fucking with the logs in the first place? And throwing money at it isn't an option for most orgs

                    > prevent them from replacing out a rack in Austria.

                    Sorry, Austria? I give you the example of a small remote island and your counter is that it works just fine in central fucking Europe?

                    Don't make the mistake of thinking TL is the only example I have either, there's a whole lot of world that has extremely remote D/Cs with limited connectivity outside their immediate region.

                    To be clear, I'm not taking issue with your suggestion to use ELK/Splunk in general. Only that you seem to be suggesting that it is suitable as a *replacement* (and apparently in all use-cases at that). It's not.

                    1. Ben Tasker

                      > If you're running your systems on the customer site, you can still have a localised syslog server. Sure a centralised ELK/Splunk would be better but it doesn't stop the ability to log to more than just the local server.

                      Just for avoidance of doubt - the model I'm talking about isn't one of "I've got customers all over the place" either. It's a network spanning the globe, and it has to be tolerant to things like comms failures - preferably without finding down the road that a comms failed fucked something else up.

                  3. Anonymous Coward
                    Anonymous Coward

                    Network

                    The network is not reliable.

                    The network bw is finite

                    The network topology is not static.

                    You can rely on localhost.

                    You can rely on DAS.

                2. Zolko Silver badge

                  Ben Tasker : "When that kit is somewhere like Timor Leste (for example), that's not quite so straight forward."

                  you mean that because of your corner case, this systemd monster must be rushed down the throats of every Linux user ? Hey, if you really do have a use-case, make it such for you and leave the rest of the people happily using SySV-init. Why should I learn workarounds because you can't be arsed to come up with a solution to your problem ?

                  1. Ben Tasker

                    Not sure why you've quoted me - I'm arguing JournalD (and by extension SystemD) is a pile of shite.

        2. John Robson Silver badge

          sysvinit is legacy in the same way as the wheel is legacy.

          1. jake Silver badge

            And BSDinit (4.3 and on) will handle all of the edge cases that sysVinit has issues with.

            Slackware has a happy amalgam of both, best of all worlds. Yes, it has a learning curve ... but nobody ever said everything worth knowing should come easy, now did they? (The default will work for almost any desktop user, install it & use it, no need to even look at the init system if you don't want to.)

          2. Kiwi
            Pint

            acy in the same way as the wheel is legacy.

            Dammit! Beat me to it by half a day!

      3. Rich 2 Silver badge

        "...nobody else made an alternative that gained any kind of wide-scale adoption to replace the very much legacy sysvinit"

        BSD init? It has worked for many many years. And it's far simpler than anything ever used on linux

        1. R3sistance

          A fair comment, I can't say I have used BSD init, I shall at some point have to look at getting a BSD VM running to play. From what I know, OpenRC is similar to BSD Init, so will likely have to look there too.

          1. Crazy Operations Guy

            OpenBSD's rc implementation is, in my opinion, the easiest and most elegant of the the RC implementations. The whole thing is very well documented and plenty of useful comments are in there.

        2. jake Silver badge

          "BSD init? It has worked for many many years. And it's far simpler than anything ever used on linux"

          Not quite. I can easily setup Slackware to boot with a pure BSD init. And I do occasionally, when it's required.

      4. Doctor Syntax Silver badge

        "replace the very much legacy sysvinit."

        Presumably to allow sysadmins with no shell skills to administer systems. That's called "solving the wrong problem".

        1. R3sistance

          I've had to fix shell scripts installed by other administrators/technicians on servers before, I am not saying systemd was the right solution either, I am saying it is the one that has been most widely adopted and that sysvinit was long in need of an overhaul.

        2. rnturn

          No scripting knowledge needed

          That's reminiscent of my VMS days when recruiters would ask me during talks about system manager jobs whether I knew how to write DCL scripts. My response to them back then was: "I wouldn't let someone who didn't know how to write DCL scripts any where near the SYSTEM account" That's, essentially, what I say today when dealing with recruiters regarding UNIX/Linux positions that have a sysadmin component and they ask about scripting experience.

          That Red Hat's L.P. seems to be making writing and understanding shell scripts something completely separated from being a sysadmin---just follow the instructions in the run book. Actually, IBM's purchase of Red Hat makes sense in a way. While contracting with Big Blue, as an admin, I was discouraged from writing anything. Writing code is an entirely separate billable activity from system administration. If your administrators don't know anything about shell scripting, no problem---they don't seem to want you writing the scripts in the first place.

      5. katrinab Silver badge

        What were the problems with sysvinit that needed a complete rewrite?

        Personally, I'm very happy with the even older BSD Init, which allows me to create a service without 5 lines of CSH.

        1. R3sistance

          There is quite a few, for starters the lack of dependencies, processes are just loaded in a pre-defined order and so if you have one daemon reliant on another service but the first service fails, sysvinit will just continue to load the latter service. This means having to manually detect if the previous daemon is running and terminating self or worse, letting the dependent service load when perhaps it should remain down.

          The above plays into the fact that sysvinit really has no idea what state the processes it starts are running in.

          Single threaded initialization, it's mainly a speed thing here so it's opinionated but in an enterprise environment this is actually meaningful. Longer boots is increased downtime for any reboot, like kernel updates for example. It's also not great when you have a customer on the phone shooting for their site to be brought back up right now, you check sysvinit and see it timing out on some process to later find out said process was trying to run a rdns lookup request that never got answered and so just sat their for 5 minutes holding up the entire boot process.

          But the biggest issue, is generally other System Administrators who put together kludges into init scripts, so you end out with bespoke servers using band aid solutions that then later break for various reasons (i.e. package update replacing said script). This is often due to the quality of the sys admin but in a real enterprise environment, you shouldn't be running bespoke and patchy server configurations/scripts.

          1. Kiwi
            Facepalm

            Longer boots is increased downtime for any reboot, like kernel updates for example. It's also not great when you have a customer on the phone shooting for their site to be brought back up right now

            Surely, if you're working at the "global scale" you claimed in this very thread, you're using redundant servers and automatic failovers, load balancers and the like - and making sure server B is functioning before rebooting server A?

            Bloody hell, when I was running a couple of mate's websites off of a spare laptop in the linen cupboard under the stairs, I had a backup clone running at another mate's house where I could redirect DNS before shutting down/doing work on the main machine!

            1. R3sistance

              "Surely, if you're working at the "global scale" you claimed in this very thread, you're using redundant servers and automatic failovers, load balancers and the like - and making sure server B is functioning before rebooting server A?"

              This might be a surprise, but I haven't always worked for the same company using the same set-up. I have previously worked for an MSP, before that I worked in DC ops and before that app/DB dev. Unfortunately while working at said MSP, the sales team would sell some very stupid and unsuitable solutions but my complaints about the terrors their sold fell on deaf ears.

              "Bloody hell, when I was running a couple of mate's websites off of a spare laptop in the linen cupboard under the stairs, I had a backup clone running at another mate's house where I could redirect DNS before shutting down/doing work on the main machine!"

              Fantastic,

          2. SImon Hobson Bronze badge

            processes are just loaded in a pre-defined order and so if you have one daemon reliant on another service but the first service fails, sysvinit will just continue to load the latter service.

            You say that like it's a bad thing !

            The only correct way to do this is to start everything at once, and everything does it's own thing. There's been a few discussions regarding this on the MythTV mailing list - because SystemD's idea of "network up" is different to other ideas, and so the config needs to be changed. In the general case, there is zero way for any distro-level maintainer to know what every users' network config is going to be, and the reliable way to deal with that is for each service to start and immediately wait until services it's dependent on are ready. So if the service is configured to only listen on "localhost" it can continue to load as soon as localhost is available - but if it's configured to listen on a specific interface/IP then it needs to wait until that is ready.

            It may need a bit of work on the part of the admin where (for example) certain interfaces and connectivity are needed - but a system where this sort of checking is the default would make this easier to manage for everyone.

            Similar thing for databases. AFAIK not even SystemD actually knows the difference between "mysqld is running" and "mysqld has finished any startup tasks (such as cleaning/reparing tables after a crash) it might need to do and is actually ready to accept queries". So what does SystemD bring to the table over and above the init script that waits while checking to see if the daemon is running ?

      6. teknopaul

        Re "nobody else made an alternative", nobody wanted it in the first place except Pootering. There already was an init. Who wants a boot that is different each time and after ten years of dev still cant shutdown. What you want in a server is a reliable reboot. Speed does not matter when you have redundancy of servers. Systemd is fine, as an option, for laptops. The alternative was stable. Still is.

        I rarely reboot my laptop. Care not about the speed. Be nice if it would reboot eventually when I type init 6 tho.

        1. JohnFen

          I do reboot my laptops, but I still don't care about bootup time. I've long wondered why this metric is a big deal for people.

          1. Doctor Syntax Silver badge

            "I've long wondered why this metric is a big deal for people."

            It's a big metric if you're trying to push something that allegedly reduces it.

            1. R3sistance

              it's an important metric when you've got a customer shouting down your ear after their services being restored NOW. What you value and what your employer or your customer values are highly different things. Generally customers love high uptimes, they never like to see their services or servers go down, even if it's just to apply monthly or security patches on servers running in higher availability.

              1. Kiwi
                Facepalm

                Generally customers love high uptimes, they never like to see their services or servers go down, even if it's just to apply monthly or security patches on servers running in higher availability.

                Mine never did. Well, once when a bad storm knocked out most of the valley for several hours overnight and well past the UPS time. But then, the same storm also knocked out connectivity for a few days so... But their servers were up and running as soon as I a) knew about the extent of the problem and b) could drive to somewhere with enough connectivity that I could swap the DNS entries for the running-redundant server and the blacked-out main server (which, strangely, became the running-redundant server for the next few months till the formerly-redundant-now-main required a reboot to load a new kernel or something).

                Unlike your claims, I don't work at a global level, yet was still able to provide services for customers with redundant web and email servers located in other towns. I didn't use automatic failover but was (when phone lines were available) alerted PDQ to any issues and able to silently fix them. IIRC, in several years of service, total downtime was less than 24 hours, and most of that on one day due to one storm.

              2. JohnFen

                I was talking about people, not corporations.

                I can think of a number of reasons why an enterprise-scale deployment would care about boot times, but that's a different issue that could, and should, be addressed without making the OS worse for everyone else.

            2. doublelayer Silver badge

              I think it's an often-used metric because it was once important, back when laptops couldn't suspend all that well and would go through the battery quickly enough for it to be dead when you wanted it again. Either that or when people had to reboot very frequently. Neither of those have been a major concern for over a decade though, so we could probably stop using it.

          2. Kiwi
            Pint

            I do reboot my laptops, but I still don't care about bootup time. I've long wondered why this metric is a big deal for people.

            Same. Usually shut mine down at night.

            In the morning, get out of bed, press power button, go for the 3 S's (cept I don't shave and only shower if I'm meeting other people/it's been a couple of days), type in password, go and make coffee. Machine is ready for me.

            Did it take 1 minute to boot? 20 seconds? 10 minutes? Don't know and don't care.

            The servers I still run - reboot only rarely. If I was doing stuff for others I'd make sure the backup is up, reboot the main, and if it takes a minute or a day who cares, redundancy rules bitches!

            (Yes, I know my practices are probably "best practice" in the same sense that "shallow grave at the beach" is "appropriate form of dispute resolution", but it works for me :) )

          3. rnturn

            It reminds me of the "how fast can it format a floppy" measure that used to be popular in early PC reviews.

      7. JohnFen

        "the problem is that nobody else made an alternative that gained any kind of wide-scale adoption"

        That may be because the faults of SysV init, while real, aren't as serious as some people assert. Yes, having something better is desirable, but outside of some edge cases (for which there are alternate init systems that can be used), it's not really that big of a deal.

        Also, in my opinion, systemd is worse than SysV overall anyway. It does improve some things, but brings so much badness along with it that it's not a good tradeoff.

        1. R3sistance

          I respect your opinion. A lot of people just look at it as sysv vs. systemd but in reality it should be looked at for the pros and cons. I've said somewhere above, systemd is great for enterprise but terrible for expert users. As most sys admins are expert users, they naturally do not like systemd compared to sysv which is great for expert users but (in my honest opinion) isn't a truly enterprise worthy solution. I personally would like to see something better than either sysv or systemd.

          1. Doctor Syntax Silver badge

            OK, upvote for that but still have to point out that a lot of us managed to run enterprises on Unix before systemd was a thing.

            1. jake Silver badge

              "a lot of us managed to run enterprises on Unix before systemd was a thing"

              Very true. However, we were (and still are) experts and professionals. Today's crop of kids? Maybe not so much.

              As R3sistance said:

              "systemd is great for enterprise but terrible for expert users"

              Sad that the experts are leaving the enterprise in droves, with no replacements in sight (or on site, apparently), but there you go. Kind of helps to explain all the security howlers that ElReg reports on day in and day out, though.

            2. ROC
              Pint

              I notice the past tense in that assertion. I was involved in Solaris sys admin'ing for external customers of the Big Blue from 2001, then directly as contractor, then employee, supporting a global app for a major pharma biz through 2015, and I saw the demand for uptime constantly adding 9's to the uptime requirement.

              We responded with clustering, backup systems at alternate DC's, and tighter monitoring with round-the-clock support "following the sun" globally. The "old" ways were constantly pushed and tweaked, so anything perceived as improving the uptime was welcomed. But, perceptions were deceptive, and metrics, and more metrics, were demanded to monitor how well we were doing.

              But both still constantly laid off IT support people, thus constantly increasing the load on the remainder in expectations of greater automation efficiency (and cheaper "2nd world" IT labor...). That drove out some people who still had options, thus leaving even fewer to deal with the load.

              Glad I'm retired now, and having fun dabbling with Raspberry Pi's among other gear ;-}

      8. Kiwi
        Holmes

        the problem is that nobody else made an alternative that gained any kind of wide-scale adoption to replace the very much legacy sysvinit.

        It's like 2 wheels on a bike or 4 on a car... Extremely legacy, not perfect for every situation, but seems to work perfectly well most of the time.

        The reason the alternatives are less used is simple, they're less-appropriate.

        1. Kiwi

          Extremely legacy, not perfect for every situation, but seems to work perfectly well most of the time.

          Replying to myself, I know....

          Actually if you want extreme legacy with little real change, look at the basic trailer - hitch, frame, axle, 2 wheels and bed - how many thousands of years have we been using that basic design?

  10. James 47

    Who the hell runs Linux on a laptop?

    1. R3sistance

      It's how I originally got into Linux around 15 years ago with a knoppix CD, but I generally don't use laptops for personal usage anymore.

    2. simonlb Silver badge

      Someone using an 8-year old laptop with 4Gb of RAM and a 60Gb SSD that won't run Windows 10 very well at all?

      Or realistically, anyone who doesn't want to use Windows full stop.

      1. Anonymous Coward
        Anonymous Coward

        Windows 10 will generally run in 4GB RAM just fine (thanks to memory compression). It also has better mobile battery life than say Ubuntu. So the question is more likely which OS is a better fit for you.

    3. hmv

      Who the hell runs anything else on a laptop?

      (and no, I don't really mean that ... run whatever you like on your own laptop, but don't imagine there aren't others with different requirements)

    4. upsidedowncreature

      *raises hand*

      1. vgrig_us

        *another raised hand*

        Allows me not to run windows on bare metal.

        1. Stoneshop
          Boffin

          Allows me not to run windows on bare metal.

          And you really shouldn't, due to the different thermal expansion properties of glass and most metals; you should put some flexible caulking inbetween.

          1. vgrig_us

            Re: Allows me not to run windows on bare metal.

            How do you know I didn't mean "unpainted cylon centurion" by "bare metal"? :-)

          2. rnturn

            Re: Allows me not to run windows on bare metal.

            I prefer a generous air gap between Windows and my bare metal.

            1. Kiwi
              Coffee/keyboard

              Re: Allows me not to run windows on bare metal.

              I prefer a generous air gap between Windows and my bare metal.

              Same.

              I also prefer an air gap between my coffee and my keyboard, but sadly today - that is not to be!

    5. Teiwaz

      I run it on a (2011 era) Netbook

      There really is not other sane option.

      BSD is reliable, but often doesn't have the same hardware support 'Linux does.

      1. herman

        In my humble experience, I haven't found a laptop that OpenBSD doesn't run on. I find OpenBSD and Slackware to be very similar: simple, secure and very fast.

    6. Doctor Syntax Silver badge

      I do. So does SWMBO. What do you expect us to use? Windows?

    7. JohnFen

      I run Linux on multiple laptops. I SSH into them on a regular basis, too.

    8. adnim

      Someone that wants an OS they can trust which doesn't reset file associations every update?

      Mint on Samsung series 9 has never failed me, just works.

    9. jake Silver badge

      Some of us ...

      ... have been running Linux on laptops since before the turn of the century. My primary desktop machine has been a laptop running linux since '96 or thereabouts.

      1. Peter Gathercole Silver badge

        Re: Some of us ... @Jake

        One of my personal major achievements was getting Redhat 4.1 (not RHEL) running on a pre-Thinkpad IBM L40SX (80386SX at 20MHz) in about 1997, it was the only laptop I had at the time. I had to do the initial boot off floppy, and load all of the rest of the packages over SLIP from a desktop system running the same version. as it did not have a CD ROM drive and pre-dated USB. I think that it also only had an 80MB disk, which was a bit of a squeeze.

        I even got XFree86 running!

    10. Kiwi
      Holmes

      Who the hell runs Linux on a laptop?

      Me.

      Not only that, my nextcloud server is also running Linux and, strangely, also on a laptop.

    11. Anonymous Coward
      Facepalm

      Who the hell asks such a dumb question

      On The Register?

      Go ask it on zdnet.com or some other site for drooling morons and then you might find a few people who think like you. Perhaps you logged into El Reg by mistake?

  11. chuBb.
    Facepalm

    Oh FFS seriously, the risk of snarfing decrypt key from memory from a suspended laptop, really???? You got bigger problems if that is really a risk, what with the hackers being physically infront/in possession of your laptop. Oh it make it easy to swap linux laptops/distros, so does partitioning, or does this fartknocker think this is what is stopping linux on the desktop??, frankly if you run *nix on your own kit (im not including hassle less deployments for parents and inlaws) and you cant move your home folder between boxen and distro's then give up and get your self a copy of windows me as pennance...

    Its not even like this really solves or invents anything other than an interminable list of locations for config files to lurk that spoil your day and over write the settings you explicitly set, honestly how is this any different than mounting a vhd with encryption to /home?

    Think i will file this one under solution looking for a problem

    1. Reg T.

      Desktop

      "or does this fartknocker think this is what is stopping linux on the desktop??,"

      The fartknocker is a RedHat furst, whose CEO declared years ago that the Linux desktop was "dead". Anything the fartknocker comes up with at RedHat is for servers. Of course, RedHat is now International Bowel Movement.

      According to that "truthful" fount wikipedia, Poettering has complained that Torvalds is too brutally abusive with language, lacking sensitivity. He must have been very pleased when Torvalds was forced to apologize for his masculine tendencies whilst wearing a tutu, and then put in "rehab".

      Another source is here https://www.zdnet.com/article/lennart-poetterings-linus-torvalds-rant/

      One can use Devuan or Slackware or go BSD. No tutus required.

      1. vgrig_us

        Re: Desktop

        Hey! Leave the tutus alone! Other than that - have an upvote.

      2. hplasm
        Mushroom

        Re: Desktop

        "Poettering has complained that Torvalds is too brutally abusive with languag"

        Really? That utter cunt Poettering said that?

        1. TheVogon

          Re: Desktop

          I assume cunt is an acronym of Computer User Non Technical as I frequently tell our directors when it appears on helpdesk tickets. Or is there some other meaning Americans should be aware of ?!

          1. Chronos

            Re: Desktop

            You forget the others:

            Clit: Can't learn, isolate [from] technology.

            Dick: Doesn't input correct keywords.

            Anus: Another nutter using systems.

            And my personal favourite, Buttocks: Better users tried to offer counsel, killed selves.

      3. Anonymous Coward
        Anonymous Coward

        Re: Desktop

        complained that Torvalds is too brutally abusive with language, lacking sensitivity

        I have a similar complaint: For some people, at some point, 'being brutally abusive with a length of lead piping' needs to be considered.

      4. rnturn

        Re: Desktop

        > Poettering has complained that Torvalds is too brutally abusive with language, lacking sensitivity.

        Sensitivity? Oh, where's that video of Poettering hopping up on stage, beer in hand, to take over some guy's talk at a symposium when you need it?

      5. JohnFen

        Re: Desktop

        "Poettering has complained that Torvalds is too brutally abusive with language, lacking sensitivity."

        Hmmm, that reminds me of something about a pot and a kettle...

    2. Doctor Syntax Silver badge

      "Oh FFS seriously, the risk of snarfing decrypt key from memory from a suspended laptop, really?"

      If it's a risk just shut down instead of suspending. Not even possible to insult it as a first world problem.

      1. Anonymous Coward
        Anonymous Coward

        Yeah, but then he'd have to go through all that systemd crap on start up...

      2. John Robson Silver badge

        Wasn't the original "problem" system boot time...

        Well - if it boots fast you don't need to suspend... And most linux boxes are never suspended anyway, they are servers.

        1. simonlb Silver badge

          I run 3 desktops and 1 laptop with various flavours of Mint and after the post-checks they are all at the login screen well within 15 seconds, so boot time is not a problem. Christ, I take longer than that to yawn...

        2. jake Silver badge

          Most of my Linux boxen are desktops. The servers are mostly BSD.

      3. Kiwi
        Trollface

        "Oh FFS seriously, the risk of snarfing decrypt key from memory from a suspended laptop, really?"

        If it's a risk just shut down instead of suspending. Not even possible to insult it as a first world problem.

        You may've just hit the nail on the head.

        From text either here or in a thread linked through posts here, I understand that systemd-encrufted machines/VMs have trouble shutting down, especially when network shares are involved?

        Perhaps pottything is scared to shut his machine down lest he be reminded just how foul his offerings are?

        #sogladImovedtoDevuan

  12. R3sistance

    Next NetworkManager

    So remember when NetworkManager came out in RHEL and it was originally for laptops switching between different wifis but slowly was modified for usage as a Server and then by RHEL7 it was basically put down as a requirement to use for RHEL servers... this whole it's for laptop comment concerns me that this'll follow the same route that NetworkManager went to eventually become a requirement.

    1. vgrig_us

      Re: Next NetworkManager

      You may have to install network manager on rhel7, but you don't have to run it. How do I know that? It's a first thing I do after install - disable the damn thing.

      It's really time to seriously learn bsd.

      1. Jay 2

        Re: Next NetworkManager

        Yep me too. I know what I want my network interfaces to do and how to configure them so that they do. I don't need some wanky daemon trying to second guess what I'm up to and try and do it for me.

        On a side note that's also why I hate Apple email clients (and why I use alternatives) as there's no shiboleet way to break out of the wizard and just type the config in, so you have to wait for it to try and ultimately fail so you can just get on and configure the damn thing.

        1. vgrig_us

          Re: Next NetworkManager

          @jay 2 - try to do a policy based routing on a multihomed server running bridge interfaces with vlans and static routes... Now try to do that with networkmanager. :-)

      2. R3sistance

        Re: Next NetworkManager

        I am not saying you can't disable it, you definitely can. However Red Hat has been building most their tooling in RHEL7 around it now, like NMCLI, having gone for RHCE I was not able to avoid having to use nmcli or firewall-cmd and in some ways I can't say they are bad tools either but they were forced on to me. Not sure if it's red hat being too pushy on their new technologies or those of us being too clingy to the old ways.

        1. vgrig_us

          Re: Next NetworkManager

          I'm not disagreeing with you, just pointing it out before fanbois show up screaming.

      3. Anonymous Coward
        Anonymous Coward

        Re: Next NetworkManager

        Turns out NetworkManager is required on RHEL8.

        I used to disable it too, and still do, where I can.

        I've been using FreeBSD for years, it's probably time to do even more with it.

  13. Anonymous Coward
    Anonymous Coward

    No. Please no....

    This actually fills me with dread.

    systemd is an abomination we're forced into having to deal with. It already breaks systems by starting services out of order ('hey, lets start your application before we start LDAP' being a particular bug-bear). The thought of random UIDs/GIDs being assigned <shudder>.

    If it stays a laptop module to be installed by paranoid people then fine - but don't let it anywhere near Enterprise servers. I NEED those types of servers to come back up unattended.

    This isn't so much as a solution looking for a problem, its a solution looking to CREATE a problem.

    1. Niarbeht

      Re: No. Please no....

      Your complaint about LDAP being started after your application can be fixed.

      https://www.freedesktop.org/software/systemd/man/systemd.service.html

      https://www.freedesktop.org/software/systemd/man/systemd.unit.html

      You'll want to look at Requires= and Before=/After=

      You'll also want to... I don't know... read the manual?

    2. Dan 55 Silver badge

      Re: No. Please no....

      Random UIDs/GIDs... what happens to the file owner and group if you save a file outside the your home directory? How can your home directory store files from other owners and groups?

      I knew he was too quiet, he was busy working on some nonsense that everyone will shoot down in five minutes.

      1. Anonymous Coward
        Anonymous Coward

        Re: No. Please no....

        When everyone else has been implementing ways to make sure user identity is the same across the enterprise (well mostly kerberos/ldap).. he's been working on a way to make it different on every login.

        I'm just amazed some of these idea get as far as any public announcement.

  14. Dan 55 Silver badge
    WTF?

    Is he off his rocker?

    "If you authenticate via SSH it goes via authorized keys in the home directory. So if you want to authenticate something that is inside of the home directory, so that it can access the home directory, where does the decryption key come from, to access the home directory? It is a chicken-and-egg problem," said Poettering.

    His solution is that the user must already be logged in, for SSH to work.

    That is really a good idea for servers.

    A person at the session asked what should be done by a university student, for example, who wanted to log in to a Linux machine that was rebooted overnight from 200 miles away. The answer: "If you really want that this system can come up on its own, don't use this stuff. This is about security."

    As is that.

    It looks like he's doing all he can to push BSD for any serious use. Perhaps he's an undercover operative sent by Theo.

    1. Tascam Holiday
      Linux

      Re: Is he off his rocker?

      I think the idea is bonkers too, but the SSH key issue is already solved. We use LDAP to hold public keys at my org, as the home directory is created on initial login only, so doesn't initially exist. We get the user's key as part of registration. A combination of SSSD and SSHD config sorts this out.

      ...actually scrub that. You'd still need to use a password to decrypt the home dir container, so this wouldn't help much. Oh well!

      1. doublelayer Silver badge

        Re: Is he off his rocker?

        I can think of some options to fix the SSH issue*. But why should I? It's a bad idea, and I don't want to encourage it by solving their problem.

        *But I'm going to anyway. Have the SSH process store keys. Users can drop those keys into an SSH database, and only root needs access to that to verify them. They verify the key is present, challenge the user, then request the decryption key. Alternatively, and a worse idea, is to trust any incoming key enough to establish a session, then request a decryption password, then check whether that key is authorized or not. If not, reject the user and log an intense security warning because it means a person has a user's decryption key but is using an untrusted device.

        The easiest solution is not to do this to home folders.

  15. alain williams Silver badge

    Not part of systemd

    I can see that some might want this, but keep this away from systemd - it is already too large which: brings in bugs and dependencies.

    The dependencies combined with the manic determination to prevent systemd working on any Unix than Linux is making it hard to do some things on, eg, BSD. Maybe this is what RedHat wants.

  16. RegW

    passwd

    > On resume, the same password will both log-in and decrypt the home folder.

    ... so if I change my password, my home folder will need re-encrypting?

    1. Dan 55 Silver badge
      Trollface

      Re: passwd

      Why would you ever need to change your password if it's a strong 2048-byte encryption key?

      1. RegW

        Re: passwd

        Under the company policy it would expire before I have finished typing it.

    2. Rich 2 Silver badge

      Re: passwd

      Ah! What YOU need is the new systemDreadful password changing module. It's really clever and only uses 10 cores and 500GB of memory.

  17. Chris King
    WTF?

    Fine for a stand-alone machine, but...

    "Poettering's idea is to have self-contained home folders, where the system assigns an UID automatically if it detects that the folder exists"

    So if that UID/GID isn't fixed, how is the poor user meant to access shared directories on a server ?

    (The answer is probably in the presentation, but I just couldn't sit through it)

    1. Androgynous Cupboard Silver badge

      Re: Fine for a stand-alone machine, but...

      Yep. Goodbye NFS.

      Although, now I've written that, maybe he is on to something?

      1. Kiwi
        Trollface

        Re: Fine for a stand-alone machine, but...

        Although, now I've written that, maybe he is on to something?

        FTFY

    2. Anonymous Coward
      Anonymous Coward

      Re: Fine for a stand-alone machine, but...

      obviously the solution to that is to layer another unique identifier on top of it. perhaps it can be named the Second Home userID Token Enumerator. (ephemeral UID/GID, mapped to the SHITE)

  18. Rich 2 Silver badge

    Linux is dead

    It's difficult to think of where to start with this. Basically he wants to absorb as much as he possibly can into systemDreadful, And, in true Poettering style, he wants to take something that is SIMPLE, well understood, and STABLE, and replace it with something that is incredibly complicated, not fully understood by anyone except him, and (almost certainly) unstable and error-prone. And, of course, any errors that there may be won't be fixed because he's "too busy" or just "can't be bothered".

    And I can't wait for the day when some glitch occurs that kills off /home directories en-mass the world over, and makes them unrecoverable.

    I don't think it's any exaggeration to say that WHEN (not IF, because 99% of the linux distributors are sheep and can't think for themselves) this abhorrence makes it into mainstream linux, then ...well ...it's game over!

    1. Anonymous Coward
      Anonymous Coward

      Re: Linux is dead

      "And I can't wait for the day when some glitch occurs that kills off /home directories en-mass the world over, and makes them unrecoverable."

      While having some container-style home dir + user/pass/UID/GID embedded is certainly appealling, I am too, deeply worried about this.

    2. Doctor Syntax Silver badge

      Re: Linux is dead

      "not fully understood by anyone except him"

      I think you're being too generous.

    3. jake Silver badge

      Re: Linux is dead

      "WHEN (not IF, because 99% of the linux distributors are sheep and can't think for themselves) this abhorrence makes it into mainstream linux, then ...well ...it's game over!"

      Hardly. The kernel itself is immune to his machinations, and so is Slackware.

      1. Doctor Syntax Silver badge

        Re: Linux is dead

        Jake, did you read that link I posted to the Debian mailing list. The gist was that it was getting difficult to maintain sysvinit because of all the systemd dependencies creeping into upstream userland stuff. That makes me worry about the maintainability of Slackware as well because surely they must be either keeping to old versions of userland or chasing the same issues.

        1. jake Silver badge

          Re: Linux is dead

          I've been living with and contributing to Slackware for a long time. I've never seen anyone wringing their hands over systemd getting in the way of the Slack init, nor userland. The upcoming 15.0 release will be systemd free ... and if the current 14.X is anything to go by (7 years old, no EOL in sight), 15.X will be with us for a lot of years. Note that Slack's init is a hybrid of SysV and BSD ... It is very resilient in the face of cancers like systemd. I rather suspect that other distros will be looking into the Slack way of doing things before too much longer.

          For the record, I haven't had a single system crash or failure to boot that wasn't my own damn fault since the release of Slack 14.0 in September of 2012. This includes the Slack installations that I maintain for friends and family (this timeframe and these results work for BSD, too).

          Seriously, try it alongside BSD. I not only advocate it, I employ the pair as my solution.

          1. Chronos

            Re: Linux is dead

            Actually, if you want a prime example of BSD vs PoetteringWare, try the vast, almost interstellar gulf between the clusterfsck that is Pulseaudio and BSD's snd(4) automatic kernel multiplex system. I'm frankly staggered nobody in Linuxland has replicated this yet.

      2. Rich 2 Silver badge

        Re: Linux is dead

        "...Hardly. The kernel itself is immune to his machination..."

        Users use operating systems, not kernels. Saying the kernel is immune is like saying the vim editor is immune. It might be, but it's still shagged if the rest of the system is borked

        1. jake Silver badge

          Re: Linux is dead

          You are replying to half of my statement. If you read and understood the other half, perhaps you would offer a different comment.

    4. the Jim bloke
      Coat

      Requires clear and distinct labelling

      So Linux, for for the original OS and its legitimate descendants

      versus

      Pox, for the things Poettering has been fiddling with.

      1. vgrig_us

        Re: Requires clear and distinct labelling

        Make it POS instead.

  19. Bronek Kozicki
    Facepalm

    Hahahaha

    "His solution is that the user must already be logged in, for SSH to work." .... so Pottering is bastardizing Linux from multi-user server system to a single-user desktop. This is hilarious, I hope all major distribution will just show him the finger.

    1. R3sistance

      Re: Hahahaha

      It's really very stupid and there must be much easier solutions than "the user must be logged in". I am surprised he didn't defer to cockpit or something actually. Even a flat file database that stores the encryption key encoded using the relevant private key sounds at least like an option... but then where would he store it... oh right he doesn't want it in /etc does he.

  20. J 3
    FAIL

    Philosophically, he said, it mixes state and configuration

    That particular guy talking about philosophy is pretty rich, methinks...

  21. DasWezel
    Flame

    "If you really want that this system can come up on its own, don't use this stuff"

    I couldn't agree more. Bloody shiteware.

  22. Stephen Booth

    SSH NOT a problem

    I'm not saying I'm in favour of the scheme but I don't see any problem in principle supporting the basic concept of encrypted home directories with ssh. Its only a convention that requires ssh authorized key-files to live in the home directory.

    The encrypted directories could have some unencrypted envelope meta-data. You can put the ssh public key in that.

    SSH also does not have to use public keys it can delegate to the normal PAM library. As users are going to have to put in a password to decrypt the diretory anyway you have already lost all the benefits of using public key authentication anyway might as well just prompt for a password.

    Supporting encrypted directories where the key is only present when the user is logged is a good (and not new) idea. Taking a religious position that all information about the user must be encoded in one of these is just making things over complicated.

    1. herman

      Re: SSH NOT a problem

      "making things over complicated" - that is the whole idea with Poeterware.

      Re-inventing the wheel and replacing it with a Rube Goldberg Machine is Poeterheaven. This ensures permanent employment to its creator.

    2. NullNix

      Re: SSH NOT a problem

      Also, it doesn't have to get authorized_keys out of the home directory -- and actually if your $HOME is NFS-shared that's a bad idea, because it means an attacker with access to your $HOME on one machine can trivially leverage that into access to all of them.

      Instead, use AuthorizedKeysCommand and/or AuthorizedKeysFile in sshd_config to pull your authorized_keys from a central location (it can just be done via curl :) ) which, sure, each user can modify -- but only if they have access to that central location anyway. (Perhaps the fileserver on which all this stuff is stored anyway.)

      1. TonyHoyle

        Re: SSH NOT a problem

        Stick it in LDAP and have SSSD pick it up. It's as secure as your LDAP/Kerberos installation.

  23. gcla72
    Coat

    Devuan?

    Mine's the one without systemD(estroylinux) in the pocket

    1. herman

      Re: Devuan?

      PCLinuxOS, Gentoo, Devuan, Slackware, OpenBSD, MacOS - there are lots of perfectly fine distros that are not infected by Poetering disease.

      1. Rich 2 Silver badge

        Re: Devuan?

        void linux - it's quite nice

      2. jake Silver badge

        Re: Devuan?

        Minix is a viable alternative. MeDearOldMum would probably be running it, if I hadn't moved her to Slackware years ago.

      3. Doctor Syntax Silver badge

        Re: Devuan?

        "OpenBSD, MacOS - there are lots of perfectly fine distros"

        Those are not Linux. They're Unix variants. Linux used to be a Unix-like OS.

        1. herman

          Re: Devuan?

          There is actually very little difference between Linux and BSD/MacOS. Only the kernels differ - everything else is very much the same. It is really only the small (Crucial, but small nontheless) part maintained by Linus that is different.

  24. theOtherJT Silver badge

    Where does the key come from...

    ...well, in my case it comes from /etc/ssh/ldap-keys.sh in accordance with the AuthorizedKeysCommand directive in /etc/ssh/sshd_config.

    Not only will this pull the public part of your key out of your LDAP profile, but will also get the path to your home directory and mount it for you.

    Not that I'm defending this bloody silly idea, I'm not, but if we're talking about SSH to servers, this is already a problem we solved.

  25. John Robson Silver badge

    If he's that worried...

    Why not just have the home directory contain `.ssh/` and `.home.img` a compressed, encrypted, blob of the rest of your home directory that is auto-mounted by something in `.profile`

  26. nagyeger

    I must be an edge case

    I guess I'm an edge case:

    1) I want my laptop to actually boot up with working wifi (thanks so much NotworkManager, for breaking this yet again), so I can ssh into it.

    2) I want my laptop to boot up with properly mounted user directories so that that cron processes can run.

    3) I want my laptop to display all those debug messages while it's booting, so I can SEE why it's taking longer than normal.

    4) I don't expect init to ever cause a SEGV and kernel panic (every other time I log out of X, some days)

    5) I want to be able to run stuff on another computer and have the results on my display, like, urm, X11

    6) 'logfile corrupted, deleting' messages fill me with an inner state of horror, not the rosy glow of 'at least it saved me (maybe) 500ms at boot time'

    David (the luddite)

    P.S Poettering, have you heard of pam-mount? I know you didn't write it, but it lets you mount user partitions as people log in, using their password as a LUKS key. It's been around for at least a decade and a half.

    1. herman

      Re: I must be an edge case

      Poetering is like the US patent office. He only knows about things he did.

    2. Rich 2 Silver badge

      Re: I must be an edge case

      Regarding (1), I can't see any reason at all to use Network Manager. If you want your wifi to work, just kick it off directly with wpa_supplicant.

      It seems to be a general issue with "helpful" Linux utilities like Network Manager - take something simple (yea - ok, wifi can be a bit of a sod to get going sometimes) that already has a perfectly good and usable interface (like wpa_supplicant, for example), wrap it up in a pretty gui that doesn't actually add much, add a few hundred megabytes of "stuff" that does ....errr ...make it look pretty(?), do some magic and **Ta-Daaaa** ...oh, it didn't work. Oh well.

      1. Graham Dawson Silver badge
        Gimp

        Re: I must be an edge case

        Put... put nodejs in it.

      2. Anonymous Coward
        Anonymous Coward

        Re: I must be an edge case

        Oh c'mon, NetworkMangler would be a right pain to use on a server with complex routing, but laptops tend to have a very simple networking config - just connect to wifi and pick up an IP. NetworkManager does that quite well. Maybe there's a VPN in there, but the VPN software usually manages that stuff itself.

        1. rnturn

          Re: I must be an edge case

          > ... NetworkMangler would be a right pain to use on a server with complex routing, but laptops tend to have a very simple networking config - just connect to wifi and pick up an IP.

          While it works pretty well for wi-fi connections, I've found it to be a royal PITB when you find yourself needing to use a hard-wired network connection and a fixed IP so I look at it as an only half-finished component of the desktop. LP doesn't need it so it doesn't get worked on.

    3. TonyHoyle

      Re: I must be an edge case

      An amusing thought is if they require login to decrypt the user directory then systemd user services are fubar.. and they're even semi useful for some things. So lennart is breaking his own stuff.

    4. Doctor Syntax Silver badge

      Re: I must be an edge case

      "I know you didn't write it"

      He sees that as a problem. The rest of us...

  27. JohnFen

    This may solve my procrastination

    I've already decided to move to either Slackware or BSD in order to escape SystemD, but the amount of work involved is quite large (I have a lot of machines) so I've been procrastinating.

    This may get me off my butt about this.

    1. jake Silver badge

      Re: This may solve my procrastination

      "I've already decided to move to either Slackware or BSD"

      Change that or to an and ... Slack on the desktops, BSD on the servers. Has been working for me for two and a half decades or thereabouts.

      1. JohnFen

        Re: This may solve my procrastination

        I thought about that, but I have a lot of machines and very much prefer for them all to be running the same thing, to reduce my mental state-changing.

    2. Outer mongolian custard monster from outer space (honest)

      Re: This may solve my procrastination

      You can use devuan etc as a good interim solution and just swap one or two of them to *bsd to get a feel for it. Its worth doing because there's a chance in future that upstream changes will force the systemd-free distro's into abandoning their resistance.

      *bsd is actually pretty close a experience with the ports enabled, just the occasional thing slightly different. Flags, syntax etc, just enough to trip you up at first but not enough to be worth loosing sleep over. People see my laptop and don't even realize its bsd underneath.

      If you have to have stuff that has a hard dependancy on a certain os/version for support, that's what virutal machines are for. Its a shame that my vm host now has linux vm's in amongst the more usual suspects but that's how life goes.

      1. JohnFen

        Re: This may solve my procrastination

        I tried devuan out on a test machine, but decided not to go that direction for the very reason you cite: I think it's a temporary reprieve.

      2. herman

        Re: This may solve my procrastination

        Exactly, I have found that laptops with OpenBSD 'Just Work' TM.

  28. Zarno
    Mushroom

    It's a gelatinous cube...

    It eats everything in sight, corrodes everything in sight, and is damn hard to kill with anything but fire.

  29. John Doe 6

    Dear Linus

    Will you please stop this systemd madman ?

    Concerned Linux users of the world.

  30. Anonymous Coward
    Anonymous Coward

    For Real?

    There are people out there that still use Linux, the 90’s are calling and the sad nerds from back then want their toy OS back...

    1. jake Silver badge

      Re: For Real?

      There are bad trolls, and then there are very bad trolls.

      And then there is this.

      D-, must try harder.

  31. payne747

    Feature Creep much?

    It's not really in the spirit of Unix philosophy to cram more and more functionality into systemd. I'm wary.

  32. Dan 55 Silver badge

    In other news...

    Knoppix 8.6 first wide public release to abandon systemd

    And I think we can all agree with that.

    1. Doctor Syntax Silver badge

      Re: In other news...

      Just to clarify - it's the first wide public release of Knoppix to abandon systemd.

  33. Jeremy Allison

    Recycling an old joke...

    systemd isn't a bad operating system, it just lacks a good init system :-) :-).

  34. Anonymous Coward
    Anonymous Coward

    he likes to pass off criticism as a hater brigade instead of fuctional concerns...

    so here is a brief summary of some of those concerns:

    This "solution" is designed for laptop/desktop users, and will cause crippling fragmentation of the core user security model in unix/linux systems. It will be crippling because in addition to breaking compatibility with all existing implementations, and that the Unix and BSD communities are unlikely to support it at all, it also means a fork between server and desktop code bases that will impact both OS distributions and applications that are installed in both roles. One issue is since if the forked systemd.userd proposal is to be supported, both OS distros and app developers have to write and execute exception code and test cases for both user environments, as well as non-systemd environments. Forcing other teams to once again alter their code base and undertake both expense and effort exceeds the value of the parts of the solution that actually require breaking changes.

    In addition, the proposal once again forces dependencies with the tangled mess of systemd, and fails to address the concerns of enterprise customers who are already providing other solutions to etc/passwd era problems the proposed solution neither addresses or supports.

    Lastly, the individual responsible has a long history of causing remote root issues and has shown a poor grasp of secure coding, design, or reliability principles, so this undertaking seems to be a poor fit for their skill set.

    A good solution to these problems could still be be deployed without dependencies that exclude all other Unix systems, and allow scalable solutions like those already working with SAMBA/LDAP/FIDO/RADIUS. A good solution would be developed in concert with major stakeholders like the major Unix/Linux and BDS communities, as well as the code maintainers of the package level components that would be impacted. A good solution would have a minimum level of dependencies, allowing more efficient and complete code review and security auditing, which is a necessity for attack surface that is front facing. A good solution would be subject to scrutiny, discussion, and review from the security community before it was release into the wild.

    1. Doctor Syntax Silver badge

      Re: he likes to pass off criticism as a hater brigade instead of fuctional concerns...

      You sound like one of the hater brigade. Have an upvote.

    2. Anonymous Coward
      Alert

      Re: he likes to pass off criticism as a hater brigade instead of fuctional concerns...

      Where do I go to join this hater brigade? Do I get a membership card to put in my wallet?

      1. vgrig_us

        Re: he likes to pass off criticism as a hater brigade instead of fuctional concerns...

        And the logo on that card should be "demonized" penguin - with bsd horns and trident.

  35. Anonymous Coward
    Anonymous Coward

    First he f*cked the audio, then he f*ck init and now what else is he going fo f*ck

    Yeah seriously all I can see from Lenart is things get done how he likes them, devoid of any checks with reality and what currently exists.

    Just glanced over the article, and guessing by default kernel config using more that 16 bits for the UUID, Lenart thinks that the only files that users should own are those temporary in /run and those under home, and all rights for everything else will come from the systemd.

    1. Anonymous Coward
      Anonymous Coward

      Re: First he f*cked the audio, then he f*ck init and now what else is he going fo f*ck

      It's been obvious for quite some time that lennart wants to take over the entirety of userspace and essentially isolate the kernel inieu of actually controlling kernel dev. The next step will presumably be shifting kernel interfaces into systemd until there's nothing left except a giant blob of monolithic mush from ring 0 out.

  36. E 2

    (facepalm)

    What if I want to use LDAP for authentication and authorization via PAM?

    1. whitepines
      Happy

      Re: (facepalm)

      You get a slap on the wrist.* Kerberos is for authentication, LDAP is for authorization once authenticated.

      Or something like that. Anyone remember the horrors of NIS? Makes a proper Kerberos/LDAP system (which incidentally is what runs, somewhat bastardized, under the hood of the magic Microsoft AD system) look like it's worth the effort to set up.

      * LDAP isn't a secure authentication service. It's a directory, and not even all that wonderfully secure without going through hoops at that. If you want your users to be able to look up anyone's password or point their machines at a different LDAP directory to use their passwords for other accounts, then by all means use LDAP alone. Otherwise, you need the crypto stuff from Kerberos in conjunction with LDAP.

      1. vgrig_us

        Re: (facepalm)

        Hmm, weird - I distinctly remember setting up openldap where my users couldn't even lookup their own password hashes, let alone others'. All secured with ask/tls as well. And password policy... Hmmm.

        1. whitepines

          Re: (facepalm)

          But *something* has to access the directory with credentials to read the hashes, no? And if that something means you're storing effectively domain-wide read credentials on every single connected system, that might be a problem.

          1. vgrig_us

            Re: (facepalm)

            What?! By "something" you mean root or openldap user on a server running ldap? It's been a while, but I think "simple bind authentication" doesn't need password to be readable. Google it if you like - I'm too lazy to pull old config and openldap mailing list thread. Something about ACL for password attribute.

            Again - simple bind can be done securely with SSL.

            1. whitepines

              Re: (facepalm)

              It's been a while since our company looked at pure LDAP authentication, I know it was shot down PDQ due to a number of attack vectors and the final solution was LDAP + Kerberos.

              A quick Google turns up papers like this one:

              https://file.scirp.org/pdf/JIS20110400007_36476949.pdf

              "As discussed previously in section 4.1, LDAP is a poor choice for authenticating users and entities."

              The authors go on to present various ways of hacking pure LDAP logins. Whether they apply to SSL + LDAP I don't know, but SSL brings other problems. You'd have to pin a corporate root certificate on each client, otherwise you're wide open to direct attack by any malicious CA in the system keyring, and then you have to securely distribute updates to those certs on a regular basis.

              1. vgrig_us

                Re: (facepalm)

                I was arguing "passwords visible", not general security challenges (as SSL certs are). And Linux ldap client has been kerberized since forever. Even Linux services (including telnet - lol) been kerberized since rhel5.

                So, yeah, ldap is more secure with kerberos, obviously. And that how everyone is "doing it". Including windows ad (that includes distributing trusted cert, btw).

  37. Anonymous Coward
    Anonymous Coward

    Pesky little Gnomies!

  38. Kevin McMurtrie Silver badge

    I'm lost. What is being solved with this massively complex and flawed mechanism?

    It sounds like he's trying to solve two problems without solving them.

    First, a computer stolen while anything is decrypted is vulnerable. How does moving encryption to the user-level solve that? Assume the user decryption keys are tossed when the computer suspends. Now what at wakeup? All of every users' processes crash or lock up until each one logs in again? That seems worse than locking up the whole system in firmware until a password is provided.

    Second, give user-level encryption. Why? Protect against an admin viewing everything? An admin could intercept your decryption keys just as easily. Nothing is safe if you can't trust the admin role.

    1. Ima Ballsy
      Holmes

      Re: I'm lost. What is being solved with this massively complex and flawed mechanism?

      ....or more along the lines of:

      "Since my system d shit ain't working right and I don't know how to make it fucking work, I'll throw more shit on the pile of stink and make people love me more !!!"

    2. Anonymous Coward
      Anonymous Coward

      Re: I'm lost. What is being solved with this massively complex and flawed mechanism?

      Lennart is solving his lack of control over user home dirs. That's it.

  39. Scoured Frisbee

    I totally get not mixing state and configuration in /etc, and it is trivially obvious that this is going in the opposite direction - as the follow up line of questioning revealed, if you have to get the system to sign your home directory then now the home directory is storing configuration. Whatever, I've built systems that had problems too, if I don't catch them then hopefully someone else does and we figure it out - that's why I enjoy working with smart people.

    What I don't understand is what is happening at RedHat. There are plenty of bright folks at RH who could have easily come up with all our above objections and then some. How did P get to a conference before he considered them, and that on stage? Is there some cult of personality going on, or dearth of management keeping communications open? Did all the good developers move away because of a toxic environment? Something something agile devops sprints? As someone who has occasionally considered RH jobs I am genuinely curious...

    1. JohnFen

      Red Hat is the Microsoft of the Linux world.

  40. oceanhippie
    Linux

    destroy the village in order to save it?

    Hmm System D fixed some errr I don't know what it fixed. But in the processes it cause trouble for not the nerd but the humble user. E.G when I reboot or shutdown a system, I like it to actually do it systemd sometimes decides to get to "Reach Target Shutdown" and just sit there.

    What ever Systemd "fixed" this is far more irritating.

    the ability to hack around in a user folder that you can under stand that name of and location of far out ways the complexity of the bodged password system.

    'I'm not a number - I'm a free man' I'd like my home folder not to be a number or . *sudders* a guid.

    /systemd/home/syy/{d49cf921-bc70-4d78-a4e1-bf1c8df2d491}/user/{50210286-a14b-4989-bf22-8552c862fce0}

  41. MarkSitkowski

    I stopped updating our Linux box at CentOS 6.9., having seen in 7.0 and onwards, that the loonies were planning to run the asylum.

    6.9 works properly, and has all the features that Unix should have - the most important of which is stability.

  42. Tom Paine

    Awful. Just awful.

  43. mithrenithil

    I suppose someone could easily use his words against him...

    If security is such a concern then don't suspend...

  44. Dan 40
    Flame

    Did I read random UID/GID ?

    Does anyone not understand how filesystems work ?

  45. DuncanLarge Silver badge

    Him again?

    WTF is he talking about?

    Self contained user directories with the user details entombed in the directory?

    Thats going to be fun for a sysadmin who wants to manage user stuff with a bit of perl. Now (s)he will have to walk through all the dirs in /home and process loads of redundant JSON stuff rather than just grep/cut/tr/sed over /etc/passwd. This seems more suited for laptops that are loaned out to users, needing their home dirs to move between machines (roaming profiles). But of course he thinks that this should be default even on a static server.

    And the encryption key is in RAM when a laptop is suspended, well yep, I'm sure it is. The solution is to shutdown or hibernate the thing if you are really worried. Apple went the way of locking the key away in a special chip that greatly hinders the ability to decrypt the filesystem even if the machine is running but as PC/laptop hardware is so variable we cant guarantee the presence of a TPM, which would be the obvious solution.

    I dont have much truck for Poettering/Linux. He needs to stop thinking that he knows best how EVERYTHING should be done because its been done a certain way for a long time and then helping to make it default / required. Why not improve what is already there instead of completely replacing it with brand new untested code that breaks everything? We may end up in the same place but at least it would be a development roadmap with some decent develpment and testing behind it.

    Next up: Poettering creates systemd-ramcheck, not to replace memtest86 (which he will do so eventually) but to warn the user that they are not using the correct amount or speed of ram. Upon boot, systemd-ramcheck determines if you are still using DDR2 or less than 8GB of DDR3 and then puts the user into a "light boot" mode where the only function available is to launch a browser that can only browse to amazon and certain pc parts websites where you are expected to order new/more ram. Simply because Poettering thinks that nobody uses older systems or less ram and if they do they need help.

    Then comes: systemd-hdddetect that does the same but with HDD's. The intention is that Poettering thinks that your machine should only be booting of an SSD as HDD's are old and slow and nobody uses them.

    After that we get: systemd-guires a service that ensures that you are using the correct resolution for your monitor. When you for some reason plug in an old LCD or shock horror an old CRT that only supports 1024x768, because its a headless machine that you only need to see the gui for a moment and any display will do, you will end up with either a red flashing warning window telling yo that systemd-guires does not support anything less than 4K or the machine will attempt to switch to 1024x768, get the timings wrong so you get crap on the screen and then lock up the display manager/compositor.

    I honestly think he should make his own distro, Poetter-OS to try this stuff out and then it can migrate from there.

    Oh and I still have issues with pulseaudio...

  46. cmaurand

    These are the reasons why I stopped using systems that use systems. If I wanted to use windows, I would. Systemd is a pig.

  47. This post has been deleted by its author

  48. Anonymous Coward
    Anonymous Coward

    Securely leave your laptop on.

    Why would anyone that is worried about security use suspend on the laptop instead of shut down?

    Shut it down. There, fixed that for you...

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like