back to article Soft-reboot in systemd 254 sounds a lot like Windows' Fast Startup

Version 254 of systemd marks the 115th release of this ever-growing init system for Linux. Expect to see it in the autumn releases of Ubuntu and Fedora, and in Arch and openSUSE Tumbleweed sooner. This version brings at least one fairly significant user-facing change that may even be noticed by people who never interact with …

  1. cookieMonster Silver badge
    Linux

    something else to shout about

    We suppose that will give the haters something else to shout about.

    You hit that one right on the head.

    1. jake Silver badge

      Re: something else to shout about

      "hater", Prop. Noun, often used by the under-educated (usually teenagers) in order to attempt to put down actual educated people (usually adults).

      Translation of 'hater' into English: "Everybody who doesn't agree with what I have faith in, despite the fact that I (me, personally) actually have faith in the belief of the given faith, and can't actually offer up a real, honest scientific argument confirming it's existence."

      Alternative translation: "I hate adults. They don't know anything!".

      1. FIA Silver badge

        Re: something else to shout about

        Nah, it's just that to a certain group of people 'hater' means 'someone who doesn't agree with this, often vocally'.

        Language changes over time, it's just life. Yo!

        (oh, also, making judgements about people based on their age whilst berating that arbitrary group for making judgements on an arbitrary group of people based on their age really messes with my head... ;) )

        1. Stuart Castle Silver badge

          Re: something else to shout about

          I think people are too quick to judge others now. It's entirely possible to like someone, even be friends with them, even if their views are opposite to yours.. It's also possible to have a reasoned debate with them about why their views are different, without just dismissing them as a hater. In fact, such reasoned debate can be helpful because they may have legitimate reasons for their views that you can address.

          I try not to judge people based purely on their age. Being old does not make you wise, any more than being young makes you stupid. It's about life experience, and I've met some young people that have experienced way more than most older people. You can be intelligent, wise, or stupid whatever age you are.

      2. drankinatty

        Re: something else to shout about

        Reminds me of "Never trust anyone over 30..." (which sounded good until I passed that milestone in the 90's...)

      3. Liam Proven (Written by Reg staff) Silver badge

        Re: something else to shout about

        [Author here]

        > Alternative translation: "I hate adults. They don't know anything!".

        This 55YO is peering blearily at you over the top of his varifocals, and if my hairline had not receded so far, my eyebrows would have merged with it.

        1. jake Silver badge

          Re: something else to shout about

          As I said, it's an alternative translation.

          Regardless, I reject the term "hater". It is unnecessarily emotionally loaded, and clearly ad hominem in it's intended use. Tactical syntax designed to affect the emotions of the reader.

          Regardless of the names you attempt to call me, I do not hate the systemd-cancer. I'm more flabbergasted that hoi paloi has run with it.

          Red Hat implemented it to make their Linux Distribution more Windows-like, which should be a red flag to anyone with a clue. Debian did it for internal political reasons, the tech involved had nothing to do with its implementation in that space. Another red flag. Most of the rest followed on blindly through ignorance and/or apathy, with a pinch of sheer laziness, because they use one those two distro's repositories. In no example that I can find did a distribution choose the systemd-cancer because it is demonstrably a technologically better system. Not one. Think about that for a minute, and then ask yourself "Have I been had?".

          There is a reason that an init, traditionally, is a small bit of code that does one thing very well. Like most of the rest of the *nix core utilities. All an init should do is start PID1, set run level, spawn a tty (or several), handle a graceful shutdown, and log all the above in plaintext to make troubleshooting as simplistic as possible. Anything else attached to this base is a vanity project that is best placed elsewhere, in it's own stand-alone code base.

          Inventing a clusterfuck init variation that's so big and bulky that it needs to be called a "suite" is just asking for trouble. The systemd-cancer is b0rken by design and implementation.

    2. Zenxyzzy

      Re: something else to shout about

      Awesome. Yet another reason to run MX. Best move I've made in the linux space for years.

  2. Doctor Syntax Silver badge

    "But the flipside is that it means systemd will gradually encroach on even more of your operating system."

    BSD gets closer.

    1. Peter Gathercole Silver badge

      It's very close in my world. I've just started bringing my daily driver laptop more up to date from Ubuntu 16.04 to something still in support (mainly because software is now doing OS checks, and stopping working after the OS leaves mainstream support), and now when I use it (it's currently at 20.04) I'm noticing broken things left, right and centre. Almost everything I've tried to do ends up with having to fix something before I can finish the job.

      The current annoyance is that when using X.org, I'm getting background corruption, and every now and then I get my terminal sessions just flashing junk on the screen, before reverting to readable text. This is liveable with, but is incredibly annoying (and it's not just on one terminal program, it seems to affect them all!). Oh, and the fact that Network Manager keeps dropping out, leaving me with no working network connections.

      20.04 should already be quite mature, so I can't really understand why these problems still exist. I can't say that they are systemd related, but some of the problems I have had (like DNS name resolution failing after one upgrade) have been. But taken together with other Linux moves away from UNIX, it's making me want to to ditch Linux completely.

      I'm just wondering whether to do it now before putting Ubuntu 22.04 on the system.

      1. Joe W Silver badge

        There's e.g. Devuan (which just... works out of the box on a reasonably current laptop), if you want to stay with a Debian derivative. There's other alternatives as well. Don't really like Ubuntu anyway...

        1. Zenxyzzy

          Do try MX. It is free of systemd, except for a compatibility shim. As an added bonus, pulse audio is gone too!. No poettering about.

        2. Peter Gathercole Silver badge

          I already have Devuan running on one of my systems, and it is a potential candidate, but it's not just systemd that is upsetting me. Wayland is a problem for me (and I still use xorg), and the very direction that some of the core GNU developers are going in (little things like removing pg, deprecating the old network commands - presumably to be completely removed at some time in the future and all of the other "death by a thousand cuts" changes) upset me.

          I'm a long term UNIX throwback who is living their last few working years with commercial UNIX systems. Change in my working environment is not what I need right now. Muscle memory gets in the way when using Linux nowadays, and if I re-train my muscles, will get in the way of my work.

          I see Jake is recommending Slackware again further down the comments. Maybe I'll just take his advice, we seem to have a similar outlook most of the time.

          1. jake Silver badge

            Personally, I like Slackware. For a lot of reasons, many of which I'm fairly certain you (as an old UNIX hack) can get along with.

            If you just want to look, you can find a live CD image here https://download.liveslak.org/ ... but as we all know, live CDs have their own problems.

            Suggestion: Beg, steal or borrow a spare computer (people throw away 4 year old machines every day, this should not be much of a problem), and install Slackware on it. Run it alongside whatever distro you use today for a month or two. Report back.

            Slackware still boots into the CLI by default. I'm sure this won't bother you, but if you have anyone in the household who prefers a GUI, simply edit /etc/inittab, which is mostly self-documenting in Slackware. (Sound familiar?)

            vi is a link to Vim's CLI mode ... but if you prefer a more traditional vi, try stevie. (Both come with.)

            You can run as root for convenience during this testing phase, but I don't recommend it. adduser does exactly what it did 45 years ago.

            If for whatever reason the install doesn't find your network connection, hardwire it and use dhcpcd eth0 before delving too deep. You can change to a wireless connection later if you feel the need.

            A simple startx will do just that. KDE is the default, but XFCE is also an option.

            The default sound is pulseaudio for historical reasons, but it's fairly easy to switch back to plain-jane ALSA. For normal people, pulse-on-slack works for normal stuff.

            Wayland is available for those interested, but by default Slack still uses a more sane x.org.

            Obviously, the systemd-cancer is not there, Slackware uses a kind of hybrid of the best bits of the SysV and BSD inits.

      2. Anonymous Coward
        Anonymous Coward

        those issues remain...

        Don't feel too bad I am current with Debian 'stable' and those issues are still present even with the new shiny in place. NetworkManager continues to drop out constantly garbage in the terminal fonts that appear garbled at boot.

      3. Anonymous Coward
        Anonymous Coward

        ... making me want to to ditch Linux completely.

        No need for all that ...

        What is happening is that you are wanting to ditch a systemd init Linux completely.

        The solution to your woes? --> use Devuan

        No systemd, no problems.

        .

      4. jake Silver badge

        "It's very close in my world."

        Try Slackware or Devuan (or both) for your (primary) desktop first. You already know them.

        Note that I usually go with BSD on the servers ... habits of a lifetime.

    2. CrazyOldCatMan Silver badge

      BSD gets closer.

      I've only got one systemd-infested VM - I wanted to spin up a Mastodon instance and couldn't find it in my usual OS builds (Devuan and FreeBSD).

      So Ubuntu LTS was installed.

    3. jake Silver badge

      BSD works nicely. Are you familiar with it?

      If not, at your age you might want to stick with Linux.

      Devuan and Slackware do not use the systemd-cancer. Try 'em. They work.

    4. FIA Silver badge

      BSD gets closer.

      I have a query... as Linux diverges further from the Unix model and becomes it's own thing, will this spurn a new interest in the BSDs, or will the inevitable compatibility differences that start to emerge either force the BSDs down the Linux route, or increasingly deprive them of software?

      1. _andrew

        Since Gnome comes from the house-of-systemd, there have long been GUI applications that consider that not working on not-Linux is not their concern. One of the reasons why there are now BSD-flavoured/specific desktop systems (although I'm sure that a lot of the older ones still work fine too). The Linuxization of the desktop GUI and (especially) graphics card drivers was what motivated me to switch my desktop activity from FreeBSD to macOS years ago. Still runs my servers. I have a suspicion that the situation is improving though, and have been tempted to try putting a FreeBSD desktop together again. We'll see.

    5. Bebu
      Windows

      BSD gets closer.

      Or could try OpenIndiana (Illumos / OpenSolaris).

      The Solaris service management facility seems a bit more coherent than systemd and not subject to its endless feature creep.

      Systemd hasn't actually given me any grief (under RHEL7/CentOS7) and some of its features are rather handy. The ability to specify ambient capabilities is for me one such.

      I prefer software that a a few clearly related things really well without abitrarily interferring with other systems. I fear systemd will end up doing everything and being pretty ordinary in most and rubbish in some without the option of picking and choosing with which things you are prepared to let it have its wicked way.

      1. Anonymous Coward
        Anonymous Coward

        Re: BSD gets closer.

        systemd was somewhat less intrusive and maybe even less broken in RHEL7/CentOS7, yes. The creeping features were still ramping up back then.

        Once RHEL8 came around, the systemd encroachment on the OS seemed to accelerate. Or maybe it was merely that poettering got more prolific in announcing new system-this and systemd-that modules (or whatever he called them) that would soon be coming to a distribution near you.

        To be fair, I think there's something to be said for the idea of a dependency tree for startup routines. That said, I never had a problem with rc[runlevel] startup scripts at all, and certainly appreciated the ease of figuring out the startup sequence and even examining the scripts themselves to see what was happening -- 2 tasks which I've found frustratingly convoluted with systemd.

        So overall, the conceptual idea of something like systemd is worth consideration. The implementation is another thing. And the viral spread and insidious growth is something else yet again. If they'd stopped at just replacing init, without spreading into syslog, networking, nameservice, device management, timekeeping, mounts, homedirs, bootloader, and who knows what else, maybe the thing wouldn't feel so invasive and out of control.

      2. Liam Proven (Written by Reg staff) Silver badge

        Re: BSD gets closer.

        [Author here]

        > The Solaris service management facility seems [...] not subject to its endless feature creep

        That's because nobody is actively developing it any more. It's unchanging because it is static and essentially dead.

        1. bazza Silver badge

          Re: BSD gets closer.

          >That's because nobody is actively developing it any more. It's unchanging because it is static and essentially dead.

          Or, to put it another way, it works, is complete and requires no further updates.

          General Whinge About the Software "Industry"

          One of the problems with the entire software industry is that young guns coming into it don't really understand what's been done before, often re-invent things, and will deem something old and perfectly satisfactory to be obsolete or somehow lacking and set out to replace it with newer, shinier code riddled with bugs / security flaws (cough, systemd, cough).

          One example that does my nut in is travel. I've noticed that recently, Outlook has started picking up airline booking confirmations and automatically generating Outlook calendar items from it. All very well and good.

          However, we've been here before. Google had a go at that, messed it up, and abandoned it (no surprise). But back in the good ole days of BlackBerry, to the first half of the 2000s if not earlier, BlackBerry phones came with BlackBerry Travel (from WorldMate) that did exactly the same thing and a whole lot more besides (hotels, hire cars, the lot). WorldMate packed it in, only because Google announced they were going to do the same kind of thing as WorldMate / BlackBerry Travel, and decided to get out whilst the going was good. This was a really pity, because WorldMate had a really good grip on what travel actually was and on how busy people needed it to be managed, and AFAIK no one has even come close to replicating its feature set. There's other things like Kyack, that I've not tried, which might, but last time I looked at it it didn't.

          However, if you go back to the 1980s, IBM Profs (in some installations) was smart enough to allow you to book a meeting with people, with it automatically taking into account all other attendees' itineraries / travel time, no matter where they were in the world. It would also book them airline tickets / hire cars / hotels as necessary all by itself. That was useful, and saved time / effort.

          Everything we've got today just makes booking things a prettier experience, but they're not actually helping remove the need for the task in the first place. Likely there's very few left who have any idea what a proper meeting booking system actually looks like, and just assume that a webmail / webcalendar thing with just the right flat shade of blue is the last word in convenience.

          My point is that, for decades now, re-invention, re-creation, re-implementation has eroded functionality and usefulness across the board. Things have got prettier, but less useful, and all this is being done by people who, generally speaking, don't actually do "work" themselves.

          What Has This Got to do With SystemD?

          For example look no further than systemd's new soft reboot. As you've properly pointed out, it's more or less a pointless feature. It is going to cause more problems than it solves, but they're doing it anyway. They think it's a neat feature. It's not.

          IBM / RedHat need to get on top of what their SystemD fanatics are doing, because the more they're doing it the more they're creating reasons for people to stop using RedHat in particular. Right now there's a bunch of RedHat customers who are probably wondering why they're paying money for support to a company that is also creating the conditions (constant system-D changes) for needing that support, and have now made it a lot more expensive by killing off CentOS and it's look-alikes.

          A cynic might say that this is deliberate on their part - and they may be correct. But they are also making things technically "worse", which is a sure-fire way of eventually losing all your customers. The only reason IBM became as big as they did was because of their constancy - they were famed for things being sensible, knowable, over long periods of time. With RedHat and their current activities, they're tossing that USP in the dumpster wholesale. RedHat were doing that before IBM's ownership of course, but it's not stopped since.

          Another example is network name resolution. For decades, there's been a perfectly acceptable way of doing this with a standard library call. Now, systemD wants you to do name resolution via a dBus call to its resolve daemon. Thing is, if you do it that way, you're waving goodbye to source code portability.

          This leads on to another player - the US Department of Defence.

          The DoD

          The DoD back in the day mandated POSIX as the API standard against which all software written for the DoD (servers, radars, the lot) had to be written. This is why MS introduced a POSIX runtime back in early Windows NT, and why OS/2 had one also.

          Linux / Cloud is now a big component of DoD's activities. However, one thing they'll probably care about quite a lot is if Linux (driven by RedHat / IBM / SystemD) stops being POSIX compatible. I know that, technically, Linux never has been, but the difference has been too slight to care about. If SystemD does change programming APIs in Linux to the extent that source code written for Linux can no longer also be rebuilt to run on the embedded system inside a radar on an aircraft (something DoD do actually care about) and needs to be re-written, then DoD might go off Linux / SystemD big time.

          If that happens, then a lot of US defense companies might also be obliged to move off Linux. And the one thing about the entire defense sector going off an operating system is that they really do have the money to do something about it. If all of DoD, Lockheed, Boeing, Northrop Grumman, General Dynamics, BAE, General Atomics, and everyone else demands FreeBSD instances from, say, Amazon, would Amazon a) say no, or b) say yes? What about Microsoft / Azure?

          Amazon or Microsoft, having crossed that Rubicon, wouldn't keep that FreeBSD offering just for the defense sector. How many other companies would make the switch, if the instances were cheaper (because one could shop around and buy FreeBSD support from the best support vendor)?

          For Linux, allowing SystemD to tinker so much with what the Linux ecosystem could become could result in a very large, powerful sector putting a large amount of money into an alternative.

          1. Liam Proven (Written by Reg staff) Silver badge

            Re: BSD gets closer.

            [Author here]

            Great rant. I like it.

            I do want to quibble over some points, though, which cast doubt on the rest for me.

            > Outlook has started picking up airline booking confirmations and automatically generating Outlook calendar items from it

            Probably copied from Gmail. It's done that for years, and very handy it is too.

            > IBM Profs [...] would also book them airline tickets / hire cars / hotels

            Really?

            Maybe via some money-no-object internal IBM system... Pre-WWW I don't think there was the networked integration to do that. Things like BACS existed, but were formidably complex.

            https://en.wikipedia.org/wiki/BACS

            > IBM / RedHat need to get on top of what their SystemD fanatics are doing

            I don't think _any_ company in this space has that kind of level of oversight any more.

            E.g. inside RH and SUSE, techies communicate by plain-text bottom-posted email on mailing lists and by IRC and the like. The execs and marketing teams communicate by rich text top-posted email over Gmail or Outlook, and by video chat, and Javascript-based "work social networks", and they don't know the engineering teams' tools exist, or how they work, let alone how to use them.

            The management teams don't even realise that they are paying *rivals* to _host theor corporate email solutions _when they _sell email hosting tools as part of their own products_. Yes it is that bad.

            > and why OS/2 had one also.

            [[Citation needed]]

            I used it. No it didn't, not that I know of.

            > technically, Linux never has been,

            Wrong. POSIX now is Single Unix Certification, and as I have written at length, multiple Linux distress have passed.

            > a very large, powerful sector putting a large amount of money into an alternative.

            ... Good? Sounds great? Yes please, bring it on?

  3. Peter Gathercole Silver badge

    The proprietary UNIX systems I use every working day still have separate /, /usr, /var, /home and /opt filesystems.

    In the case of AIX, this is largely because of the diskless boot operations that still want / and /usr to be completely read-only (although I've come across IBM supplied software that broke those rules - it cam as a great surprise to the people who wrote some AIX hardware maintenance task scripts that they could not write to /usr because it was read-only!)

    Oh. and in case you wonder whether this is actually used any more, the IBM Power 775 Supercomputer systems running AIX ran their compute nodes as diskless systems, but I suppose that even this is more than 5 years ago.

    1. John Riddoch

      I don't recall AIX installations ever giving you an option to not have those default filesystems, it just creates them regardless. I know we collapsed everything into /, /var and /home years ago on Solaris when I used to work with it. There didn't seem to be much need for the separation of usr & opt and it added overhead to systems management and meant we could run slices 5 & 6 for Live Upgrade targets. ZFS root then removed the option of a separate usr or opt filesystem and it was sometimes a pain to even get /var split off.

      When I started working with Solaris in the late 90s, we were told / & /usr were separate to help system recovery as we should be able to recover a system from just the root filesystem. As /usr/bin & /usr/sbin migrated into symlinks from their equivalents in /, that became less of a fact of life, but "we've always done it that way" creates a whole legacy of its own. This was also back in the day I suspect some larger systems had to split them into different disks because of size limitations.

      1. Joe W Silver badge

        One minor thing: I like having /opt - for the stuff I build myself that is not related to the OS as per the "vendor".

  4. karlkarl Silver badge

    I feel its going the wrong way, we want *more* separate hierarchies.

    The BSD /usr/local approach is very nice to separate ports/packages from the base install. Linux distros often lack a coherent concept of a base and now with this merge, it will get even harder.

    Weirdly I really like the Solaris (i. 10) approach of /opt/csw, /usr/sfw, /usr/ucb, etc. And the OpenBSD Xenocara in /usr/X11R6 is just much neater.

    One of my projects is designed to take this even further, and create small self-contained / encapsulated hierarchies out of any package and dependencies: https://github.com/osen/pkg_bundle

    TL;DR; I basically don't like packages and dependencies and all their cruft sprawled all over my systems. It makes it difficult to audit for one.

    1. FIA Silver badge

      The BSD /usr/local approach is very nice to separate ports/packages from the base install. Linux distros often lack a coherent concept of a base and now with this merge, it will get even harder.

      I really like the NetBSD approach that takes this further, it also has /usr/pkg, for anything installed via the packaging system, so if it all goes into dependency soup you can just delete /usr/pkg and start again.

      Mind you, you do then find all the self compiled stuff that depends on package installed libraries, so it does have it's downsides.

      I have also since moved to FreeBSD, and not had a major problem with packages being installed in /usr/local. (I build less stuff these days though.. as that was mainly something I just did because I always had done.)

  5. Doctor Syntax Silver badge

    "The Reg FOSS desk is very happy that he hasn't had to edit an init script in many years, and does not miss such things even one tiny bit, but all the same it's going to irk some people."

    It's a long time since I had to edit an init script. It's like restoring from backup. You don't miss doing it if you haven't had to but when you need it you really need it. With init scripts if there's a problem you can either put tracing statements into the script or run it from the command line, stepping through it. Good luck doing that with a black box. Systemd hasn't put me to that trouble, partly because it hasn't had the chance. Years back I had a shedload of trouble sorting out a problem with upstart which is similarly opaque.

    1. xenny

      I rarely edit init scripts, but the ability to run then line at a time by hand can sometimes be a lifesaver. Some of this really feels like development for the sake of justifying P's employment.

      1. boblongii

        "Some of this really feels like development for the sake of justifying P's employment."

        Well, yes. That's systemd in toto.

        I'm happily using Gentoo and living without systemd or his god-awful sound system.

        1. FIA Silver badge

          If I was being cynical I'd argue that his goal is to make a better desktop Linux, which justifies his employment as moving Linux from a server to a desktop OS takes it out of the space where it currently challenges MS into a space where it's unlikely to.

      2. Anonymous Coward
        Anonymous Coward

        I have believed for quite some time that poettering shat out systemD because he couldn't be arsed to learn how to do Linux things in established ways with existing tools and utilities, so instead inflicted his twisted viewpoints and creations on everyone else.

        It requires real work and effort to improve things without breaking everything around them. OTOH tearing apart the status quo so you can build what you want, devil take what anyone else thinks, and throwing rocks if they disagree with or otherwise criticize you, doesn't require you to respect anyone or anything else, or care about the fallout or consequences.

    2. jake Silver badge

      ""The Reg FOSS desk is very happy that he hasn't had to edit an init script in many years, and does not miss such things even one tiny bit, but all the same it's going to irk some people.""

      This is a null argument, and always has been. A properly setup system very, very rarely needs tweaking. I can't remember the last time I needed to tweak a startup script on any of the computers that help to run Chez jake.

      I have, however, had to make custom startups for various clients over the years. For most of those, the systemd-cancer was shown to be more of a hindrance than a help. As a consultant, I have to show my clients why I was going with either BSD or Slackware instead of the kitchensinkware boutique Linux varietal that they had been sold on.

      The systemd-cancer causes far, far more problems out in the real world than it pretends to fix.

      1. ianbetteridge

        How do "properly set up systems" get properly set up in the first place? Do they come like that out of the box?

        No, they need tweaking.

        1. jake Silver badge

          "How do "properly set up systems" get properly set up in the first place?"

          Competent administrators ... or, in the world of Linux, competent distro maintainers.

          "Do they come like that out of the box?"

          Honestly? I haven't checked recently.

          So I just downloaded the latest Slackware installation DVD ISO, burned it to appropriate media, and installed it on a completely blank computer, accepting all defaults.

          Everything works out of the box. I would not hesitate to use this system as a loaner for MeDearOldMum, should her computer HaltAndCatchFire. All I would need to add is her printer, near as I can tell, and thanks to CUPS that's handeable via GUI. (Note that I'd have to add her printer regardless of OS; she's afraid of plugging in hardware.)

          "No, they need tweaking."

          Slackware 15.0 doesn't seem to. Perhaps your distro maintainer is incompetent?

        2. DuncanLarge

          > How do "properly set up systems" get properly set up in the first place?

          They install like it mate. It's called a distro. They release, you install, all proper and good.

          Only something like Gentoo and certainly Linux From Scratch need "tweaking" but that is the whole point of those!

      2. Zenxyzzy

        The whole problem of optimizing a system minimise boot time is wrong on countless levels. Who reboots systems? I have systems with uptimes measured in years.

    3. DuncanLarge

      In all my years using GNU/Linux (since around 1998) I have never edited an init script.

      I have at times created my own, which worked quite well.

      I have manually renamed them to adjust the boot process, again no issues there and an interface I like.

      I've never had to edit them although I have read a couple to assist with debugging some software issues.

  6. Will Godfrey Silver badge
    Linux

    Hmmm

    While I agree that /usr is somewhat 'overgrown' I do very much like the separation between /usr/{stuff} and /usr/local/{stuff}

    1. Jon 37 Silver badge

      Re: Hmmm

      That is staying, because it is useful. It's just the /bin Vs /usr/bin part that is being merged.

      1. boblongii

        Re: Hmmm

        And for no reason at all.

        Who is this change helping? Why do the systemd devs get to decide these things? I'm not paying them or asking them to. I'd pay them to *stop* coding if I could afford to.

        1. jake Silver badge

          Re: Hmmm

          "Who is this change helping?"

          Marketing. "LOOK! WE HAVE SOMETHING NEW!!!!! YOU MUST BUY (into) IT!!!"

          And lo, the sheeple flocked for their masters ...

      2. Number6

        Re: Hmmm

        Having done a clean install of Mint 21.2 this past weekend, I note that /bin is a link to /usr/bin, /sbin to /usr/sbin, and a bunch of /libxx are now links to /usr/libxx. I guess that's a half-way house, lets things run from one place for stuff that wants to, but provides a catch-all for legacy software looking elsewhere. I notice a lot of scripts still have #! /bin/sh at the top.

      3. DuncanLarge

        Re: Hmmm

        > It's just the /bin Vs /usr/bin part that is being merged

        I cant see any reason to. What if I dont want a /usr?

    2. jake Silver badge

      Re: Hmmm

      It's a file system. Logically placing the files into subdirectories according to their use only makes sense.

      A library uses the Dewy Decimal System[0] for a reason, EVEN THOUGH that system has evolved over time as our knowledge has increased.

      Why people think that such a complex system that evolves over time as capability is added to that system shouldn't become more complex is beyond me.

      [0] Yes, I know, there are other ways of storing books in a library. UDC, BISAC, LCC, etc, all have their merits and problems, but anyone with a couple of brain cells to rub together should have no issues working within their frameworks. Note that none have become more condensed over the years.

      1. Anonymous Coward
        Anonymous Coward

        Re: Hmmm

        I'm still amazed that somehow libraries are still a thing in 2023.

    3. DuncanLarge

      Re: Hmmm

      > While I agree that /usr is somewhat 'overgrown' I do very much like the separation between /usr/{stuff} and /usr/local/{stuff}

      Cettainly. And someone else mentioned the idea of read only /usr, which really sounds a good idea.

  7. Ian Johnston Silver badge

    This feature should deliver much faster system reboots so long as you don't need to restart your kernel.

    OK, I'll bite. When might I want to reboot but not restart the kernel? I have two desktop machines running Linux and I only ever reboot them when I do a kernel upgrade.

    1. nematoad Silver badge
      Unhappy

      "...faster system reboots."

      Just as bloody well given that everything that Poettering has his fingers in seem to require a reboot a la Windows.

      I recently moved distros because of all the grief I had with weird glitches showing up in PCLinuxOS. I went to Mageia but soon beat a hasty retreat due to the nightmare I was having with systemd and Pulseaudio. Talk about verbose, un-parsable diagnostics. And the re-boots! Systemd might be right for some people but I went back to PCLOS where at least I can read what is going on in the various logs and edit any config files I need to.

      Talk about taking a sledgehammer to crack a nut.

      1. DuncanLarge

        > Talk about taking a sledgehammer to crack a nut.

        If Poettering gets hold of it te nut will be part of the sledgehammer

        1. Chronos

          And the sledgehammer will break first, peppering the nut with cast iron and making it inedible.

    2. BinkyTheMagicPaperclip Silver badge

      If you're 'restarting' without restarting the kernel, it's not re-initialising hardware on a warm boot, which can have a difference to a full cold boot initialisation.

      It's also faster. Could potentially be useful for certain hardware configurations, or virtual machines?

      I do wonder if the increased speed is truly worth the extra complexity, though.

      1. jake Silver badge

        "I do wonder if the increased speed is truly worth the extra complexity, though."

        And if there is any reason at all for this kind of thing on MeDearOldMum's computer. Maybe 1 person in 100,000 might, possibly, make use of this kind of thing very occasionally and perhaps 1 in 10,000,000 on a daily/weekly basis?

        So why inflict it on the vast majority of users? Implement it as a kernel module, and allow those that need it to load it.

      2. _andrew

        Re: faster. The latest FreeBSD quarterly report mentioned that the boot-speedup work has got a (presumably vm) kernel boot down to 12ms. Since booting real hardware is something that happens as close to "never" as kernel upgrades allow, the VM use-case appears to be the only instance where boot speed is of any concern at all. Or perhaps embedded systems: it's useful if they just "turn on", but they're usually sufficiently simpler that they can. The need for VMs to boot quickly is because they have become the new "program" as the process model has failed to keep up with the complexity of software distribution and the reality of anti-dependencies. I blame shared libraries and perhaps the IP model of network communication.

      3. dubious

        VMs already boot fast, so probably more useful on physical server hardware running some wretched Linux distro like CoreOS that Redhat have managed to make more reboot-on-change happy than a BT router.

        1. F. Frederick Skitty Silver badge

          A lot of VMs are never rebooted in cloud environments, since they're more often replaced rather than rebooted. So I'm struggling to think of a real world use case that justifies the complexity and yet more ideological bullshit from the SystemD plonkers.

      4. katrinab Silver badge
        Megaphone

        No it is not worth the extra complexity.

        On my hardware, Debian boots in about 1 second, not including POST time which is about a minute. FreeBSD boots in about 4 seconds, and Ubuntu takes about 20 seconds.

    3. stiine Silver badge
      Holmes

      LP - does it still mean Long Playing

      You're forgetting that systemd was badly designed and poorly impemented soley so that LP's laptop would boot faster. LAPTOP. Very, very few of these fixes are worth the time on a server that is only ever restarted on a kernel update.

      1. Anonymous Coward
        Anonymous Coward

        Re: LP - does it still mean Long Playing

        Long Playing?

        Nah ...

        In Linux speak, LP means asshole.

        .

      2. Missing Semicolon Silver badge

        Re: LP - does it still mean Long Playing

        Wasn't that the source of the new default that logging out killed any remaining processes you started? Purely because LP had leftover X processes on his laptop?

      3. Tim99 Silver badge
        Linux

        Re: LP - does it still mean Long Playing

        Sigh, I wrote this here over 5 years ago (Primarily about inserting systemd into Linux). Warning: It has elements of "I told you so"...

        How can we make money?

        A dilemma for a Really Enterprise Dependant Huge Applications Technology company - The technology they provide is open, so almost anyone could supply and support it. To continue growing, and maintain a healthy profit they could consider locking their existing customer base in; but they need to stop other suppliers moving in, who might offer a better and cheaper alternative, so they would like more control of the whole ecosystem. The scene: An imaginary high-level meeting somewhere - The agenda: Let's turn Linux into Windows - That makes a lot of money:-

        Q: Windows is a monopoly, so how are we going to monopolise something that is free and open, because we will have to supply source code for anything that will do that? A: We make it convoluted and obtuse, then we will be the only people with the resources to offer it commercially; and to make certain, we keep changing it with dependencies to "our" stuff everywhere - Like Microsoft did with the Registry.

        Q: How are we going to sell that idea? A: Well, we could create a problem and solve it - The script kiddies who like this stuff, keep fiddling with things and rebooting all of the time. They don't appear to understand the existing systems - Sell the idea they do not need to know why *NIX actually works.

        Q: *NIX is designed to be dependable, and go for long periods without rebooting, How do we get around that. A: That is not the point, the kids don't know that; we can sell them the idea that a minute or two saved every time that they reboot is worth it, because they reboot lots of times in every session - They are mostly running single user laptops, and not big multi-user systems, so they might think that that is important - If there is somebody who realises that this is trivial, we sell them the idea of creating and destroying containers or stopping and starting VMs.

        Q: OK, you have sold the concept, how are we going to make it happen? A: Well, you know that we contribute quite a lot to "open" stuff. Let's employ someone with a reputation for producing fragile, barely functioning stuff for desktop systems, and tell them that we need a "fast and agile" approach to create "more advanced" desktop style systems - They would lead a team that will spread this everywhere. I think I know someone who can do it - We can have almost all of the enterprise market.

        Q: What about the other large players, surely they can foil our plan? A: No, they won't want to, they are all big companies and can see the benefit of keeping newer, efficient competitors out of the market. Some of them sell equipment and system-wide consulting, so they might just use our stuff with a suitable discount/mark-up structure anyway.

    4. tatatata

      Ah, you have never used Windows. With every small configuration change Windows will need to reboot. See the similarities with systemd?

      1. John Robson Silver badge

        You have moved your mouse, would you like to reboot for this change to take effect?

      2. stiine Silver badge
        Windows

        I've been using Microsoft Windows since 1993. There's no telling how much of my life I've spent waiting for Windows to boot.

    5. jake Silver badge

      "I have two desktop machines running Linux and I only ever reboot them when I do a kernel upgrade."

      Exactly. The whole "faster reboots" thing was a red-herring right from the git-go. Everything surrounding the systemd-cancer has been bullshit and bluster from the beginning.

    6. FIA Silver badge

      OK, I'll bite. When might I want to reboot but not restart the kernel? I have two desktop machines running Linux and I only ever reboot them when I do a kernel upgrade.

      Daily?

      I shut my desktop down daily when I've finished using it, then reboot it the next day. Saves on the electricity when I'm not using it.

      The servers stay on, but why leave your desktop powered up if it's not doing anything.

      To be clear, when I finish for the day I press the 'power' button on the start menu. Modern hardware is fast enough that the boot times aren't that onerous these days, fast boot or not.

      One question, is the Linux implementation like the Windows one? On Windows when you shut down it logs you out then hibernates, but only on shutdown. Doing a reboot actually does a proper shutdown and re-start. I would assume Linux does the same so upgrades aren't an issue?

      (Mind you, I hope they do the UI a bit better, on Windows, with fast boot, if you have to do an upgrade you get an 'Update then shut down' option... This actually re-starts, then does the upgrade, then fast boot shuts down... so you click 'Update then Shut Down' and the first text that appears is 'Restarting....', first few times you end up standing there waiting because you think you hit the wrong button.

      1. jake Silver badge

        "why leave your desktop powered up if it's not doing anything."

        Convenience. With the monitors off, the thing doesn't draw enough power to matter.

        1. FIA Silver badge

          Fair... I do that with the mac, as that consumes little and is silent, but with the desktop (and the current price of electricity) I'm happy to wait the extra 10 seconds it takes to start up every morning.

      2. DuncanLarge

        > I shut my desktop down daily when I've finished using it, then reboot it the next day. Saves on the electricity when I'm not using it.

        You seem confused about the difference between a shutdown and a reboot.

        Shutdown = the system powers everything off, all processes teminated. Note EVERYTING POWERS OFF

        Reboot = The system remains powered ON but terminates all processes, signals to hardware to rest itself and reloads the OS from scratch.

        You dont shutdown then reboot, such a thing is impossible. You have to be booted and running first before you can reboot, and when you do reboot nothing is powered off.

        This systemd change makes that process a tiny bit faster for some reason.

        > but why leave your desktop powered up if it's not doing anything

        Who says it is powered up? It may be in a sleep state or hibernated.

        1. FIA Silver badge

          You seem confused about the difference between a shutdown and a reboot.

          Nah. I typed reboot when I meant boot, I suspect you could've inferred that though. :)

          Who says it is powered up? It may be in a sleep state

          If it's in a sleep state it's powered up, albeit using very little. *

          or hibernated.

          sorry, I wasn't clear, that was my point really... with fast boot it makes sense to shut down (ie, hibernate really) as the re-boot (sorry, I mean boot, as I do actually build my entire machine from scratch each day) is really just an un-hibernate.

          However, most (desktop) machines these days boot so quickly that I'd also contend it's still not onerous to do a full shutdown and start up every day.

          * okay, I get I'm being picky... I'm also aware that unless I'm physically switching off the machine daily it will still draw a small amount in 'soft off' too... ;)

      3. Ian Johnston Silver badge

        The servers stay on, but why leave your desktop powered up if it's not doing anything.

        In my case as a supplemental space heater, running Folding At Home.

      4. Liam Proven (Written by Reg staff) Silver badge

        [Author here]

        > I would assume Linux does the same so upgrades aren't an issue?

        Taking a neutral position, because most of my machines are systemd based and mostly it's fine...

        If you install updates, then the OS can check and see and decide which kind of reboot is needed, on the fly every time:

        * if the kernel has not changed, it just restarts userland.

        * If the kernel has changed, it does a full reboot, ideally using kexec or similar, bypassing bootloader and POST.

        * If the user requested a reboot, it does a full reboot.

    7. Solviva

      On gentoo (without systemd), you're free to restart pretty much anything you like. Upgrade core packages, restart the daemon and off you go. The only thing you can't update and restart is the kernel and I suppose init. Why you'd want to restart init after upgrading - init's job is to initialise so restarting fot the sake of init is somewhat pointless unless there's some serious bug there. As systemd can only restart with the current kernel then this fast restart seems somewhat useless.

      If there's a zombie process, does that actually get killed? Then maybe that's a reason, but if I'm going to the trouble to restart & kill everything, I'd rather spend the extra few seconds to be able to simultaneously load the latest kernel / kernel patches.

      1. jake Silver badge

        init can be restarted at your choice of runlevel, at least on any sane version of *nix ... look up telinit.

    8. DuncanLarge

      > When might I want to reboot but not restart the kernel?

      When you wnat to shave a few milliseconds off your boot time

      > I have two desktop machines running Linux and I only ever reboot them when I do a kernel upgrade.

      Hey, yeah... So why the hell is this systemd thing a thing?

    9. Liam Proven (Written by Reg staff) Silver badge

      [Author here]

      > When might I want to reboot but not restart the kernel?

      If you are in a container?

      Or, you know, when you just need to restart systemd for an update because nothing directly uses the boring old kernel underneath any more. ;-)

  8. Joe W Silver badge

    Usecase?

    "This feature should deliver much faster system reboots so long as you don't need to restart your kernel."

    Not sure why I would need that. Windows did need to be rebooted for almost everything (the running gag was "mouse movement"), but Linux? Only if you do stuff for the kernel, and even then there was some way to switch that over (it was a loooong time ago that I tried that out, so memory might not be as fresh as it never was). And the article mentions as much in the second to last paragraph. So I am confused.

    I also don't really get the argument " The /usr merge also allows making the entire vendor-supplied OS resources read-only for increased security and robustness." why was this impossible before? Why do we get better "separation between vendor-supplied OS resources and machine-specific"? Surely merging directories makes it more difficult (and I totally get it, stuff ended up apparently randomly in /usr/bin and /bin and likewise sbin because some people could not be arsed to think about that issue...). To be honest I don't care either way...

    (and I have not had to edit an init file in a looong while either, but I had some run ins with the oh-so-clever systemd and its kraken of tools that made it pretty difficult to fix network and sound problems I had, so there's that). I use my computers for work and recreation and expect them to "just work" and no longer like to fiddle with stuff (which is why I now prefer Linux), rather than a few decades age, when I wnated to fiddle with stuff (which is why I preferred Linux back then).

    I'm not saying systemd is bad. But then I'm not saying it is actually good. (but I have been burned by pulseaudio... but if you look at my older code I freely admit it was shite, so no hard feelings there?)

    1. jake Silver badge

      Re: Usecase?

      "But then I'm not saying it is actually good."

      It's a solution looking for a problem.

      1. David 132 Silver badge
        Coat

        Re: Usecase?

        It's not even a solution. It was very precipitate of Poettering to foist it on us all.

        1. Ian Johnston Silver badge

          Re: Usecase?

          The entire Linux world was free to reject it, but choose not to do so. Why not?

          1. Anonymous Coward
            Anonymous Coward

            Re: Usecase?

            Red Hat pushed it out, Gnome is intertwined with it, as are other system services things nowdays, unfortunately.

            Red Hat has a great deal of influence, if not outright control, over Linux directions and decisions. Even putting aside the immediate Red Hat family (Fedora, CentOS, RHEL), the current main rebuild distros (Alma, Rocky) were bound to follow by their very nature. Those 5 right there are a big swath of installations out in the world.

            I was most disappointed when Debian chose to deploy and enable systemd by default. The Debian family might have been the best-equipped to deviate from Red Hat's direction to make a go of it their own way, and who knows -- Canonical might have even followed with Ubuntu. That's not what happened, though.

            SUSE also could have gone their own way, but I imagine their Enterprise[tm] business with SLES probably wants to stay in the same customer ballpark as RHEL.

            Full marks to Devuan and MX for stepping off Red Hat's path. I expect it wasn't easy, and may get more difficult over time.

            1. jake Silver badge

              Re: Usecase?

              "Red Hat has a great deal of influence, if not outright control, over Linux directions and decisions."

              Influence perhaps. Control, not so much. Remember, it's FOSS ... ANYBODY is free to roll out their own distribution.

              "Full marks to Devuan and MX for stepping off Red Hat's path."

              How many marks do you give Slackware, then?

              1. Anonymous Coward
                Anonymous Coward

                Re: Usecase?

                Slackware always gets respect from me.

                Devuan and MX were mentioned in this case because they deviated from the chosen path of the parent distribution, not because they're particularly better or worse than Slackware.

                Slackware afaik never went with systemd at all, which is admirable on its own.

          2. jake Silver badge

            Re: Usecase?

            "The entire Linux world was free to reject it, but choose not to do so."

            I don't think that word "entire" means what you think it means.

            For a start, Linus himself has stated that the kernel will remain init agnostic in perpetuity.

      2. georgezilla

        Re: Usecase?

        " ... It's a solution looking for a problem. ... "

        Designed by a narcissist.

  9. AJ MacLeod

    Once again

    Ah yes, once again systemd is "solving" another problem that didn't exist. I can honestly say that I have had far more problems with systemd than any other init system I've used on any OS over the past three decades; frankly it's garbage.

    Who on earth edits init files anyway? I just don't get it. I mean, distribution package maintainers presumably do, but ordinary users or even sysadmins? In my experience no other init system is so convoluted, nor so fragile and above all, so infuriatingly pointlessly dog slow; it just seems to hang up fatally at every possible opportunity for the most trivial of things. Just the other week I had a new systemd botchup to add to my lengthy list of reasons to hate it; suddenly a server which has been in production for several years came crawling to a halt; the / partition was apparently suddenly full when it had 70% free for years. To cut a very long story short, clearing around 3 gigs of logs (systemd as logger) suddenly freed up ten times that amount of space. Never had that issue with any other logger, nor seen any particular reason why my init system should also be the system logger.

    I don't merely hate systemd because of its primary author, I hate it because it's demonstrably far worse than what we had before (and what I still use on my own most important systems) and most of all because it constantly and inexorably grows like a particularly aggressive cancer whilst becoming harder and harder to avoid.

    1. Graham Dawson Silver badge

      Re: Once again

      In this case, it's solving a problem that it has largely created. The requirement to reboot after most updates is due in no small part to the way that systemd has taken over so much of the OS. It used to be that you could just restart services and carry on, but now even relatively minor updates require a reboot. This is a problem that would only get worse under poettering's plan to cram update management into systemd, using read-only system images.

    2. tatatata

      Re: Once again

      Initscripts are mostly static. Systemd unit files however seem to require a lot of attention.

    3. jake Silver badge

      Re: Once again

      "frankly it's garbage."

      IMO, it's worse than garbage. It creates more problems than it pretends to fix, all while fixing things that weren't broken in the first place.

    4. jake Silver badge

      Re: Once again

      "most of all because it constantly and inexorably grows like a particularly aggressive cancer whilst becoming harder and harder to avoid."

      Yep. As I said here, over 6 years ago.

      That's why I call it the systemd-cancer ... Consider: it takes root in its host, eats massive quantities of resources as it grows, spreads unchecked into areas unrelated to the initial infection, and refuses to die unless physically removed from the system, all the while doing absolutely nothing of benefit to the host.

  10. BinkyTheMagicPaperclip Silver badge

    Doesn't seem like a great idea?

    I thought this was just a merge of /usr/sbin and /usr/bin, but it seems to move /bin and /sbin to /usr/bin and /usr/sbin.

    Apparently Solaris has done this already - I don't think it's a good idea there either.

    There are still good reasons to have separate root and usr filesystems and eventually the system *will* have a boot failure and /usr won't be mounted. My understanding (and I see there is disagreement on this) is that /sbin is statically linked, so I know when there's a single user prompt and nothing else I can run the utilities in /sbin to recover the system. The utilities in /bin, possibly not.

    I can see the sense of /usr/bin and /usr/local/bin, but in practice I never really saw the point of /usr/sbin and /usr/bin. If your system is booted to the point it can mount /usr, the libraries are probably also accessible, so who cares if user executables are in /usr/bin or /usr/sbin? Use another utility to find out program dependency.

    In this case, if /usr is separate and corrupts itself (or worse if it *isn't* separate but is still corrupt) what happens at boot? Is there a minimal busybox shell that enables some interaction, or is it a case of boot from removable media?

  11. Dave_A

    And Pottering continues to screw up Linux for its primary purpose....

    Out of hope that maybe someday, people will use Linux (other than ChromeOS) on the desktop in significant numbers...

    Seriously none of SystemD's supposed improvements have much relevance to the hordes of headless VMs or cloud instances that are the overwhelming majority of the installed base....

    1. Graham Dawson Silver badge

      Re: And Pottering continues to screw up Linux for its primary purpose....

      The only relevance systemd has is to poettering's laptop. He wrote it to make his computer boot faster, because he couldn't work out how to configure his init properly. Pulseaudio was written for similar reasons: he couldn't work out how to multiplex audio, so rather than read the farging manual, he wrote a wrapper daemon for alsa that does the same thing, but with more overhead and less transparency.

      If a distro maintainers had just configured alsa properly, none of this would have happened.

      1. Jay 2

        Re: And Pottering continues to screw up Linux for its primary purpose....

        Yes it's become increasingly obvious that a lot of changes are being made so he can happily have his Linux laptop work exactly like a Windows laptop when he's using the free WiFi of a coffee shop for hours on end.

        The annoying thing is that the vast majority of Linux installations are servers/appliances/etc which don't need a lot of that crap, but now have it thrust upon them if a systemd-based distro.

        1. ianbetteridge

          Re: And Pottering continues to screw up Linux for its primary purpose....

          Yeah, how dare anyone want a Linux system to be easier to use for normal people.

          1. Anonymous Coward
            Anonymous Coward

            Re: And Pottering continues to screw up Linux for its primary purpose....

            Nice strawman. Maybe we could dress it up with some ad hominem pants and a begging the question hat.

            Systemd isn't necessary to make things easier for users. All of the problems systemd supposedly solves should have been solved through better documentation and, more importantly, better configuration by distribution maintainers. All systemd really does is add overhead and impose poetterings preferences for userspace on the world, whilst also reducing diversity and creating an ever larger attack surface for vulnerabilities.

    2. jake Silver badge

      Re: And Pottering continues to screw up Linux for its primary purpose....

      "Seriously none of SystemD's supposed improvements have much relevance to the hordes of headless VMs or cloud instances that are the overwhelming majority of the installed base...."

      It also does absolutely nothing for the hoards of Debian and RedHat derivative desktop users who will never even touch the init system because they probably don't know it exists, but even if they did they'd be afraid to go near it. All the while massively increasing the initialization system in size and complexity, thus dragging in many bugs that should have been unnecessary ... to say nothing of increasing the size, scope and number of potential attack vectors. FOR NO GOOD REASON,

    3. georgezilla

      Re: And Pottering continues to screw up Linux for its primary purpose....

      " ... And Pottering continues to screw up Linux for its primary purpose ... "

      That's what happens when you let narcissists think that they know more, better then everyone else and other narcissists agree with them.

  12. Dave_A

    That WSL comment...

    Ironically WSL doesn't use... systemd.

    1. jake Silver badge

      Re: That WSL comment...

      "Ironically WSL doesn't use... systemd."

      Yes, it does.

      That link, for the non-pointy-clicky inclined:

      https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/

  13. cjcox

    Of course, hibernation predates systemd (been around a long time in Linux)

    The problem with hibernation, unless you can somehow come up with a compact structure representation for memory that works most of the time, is that hibernation is going to want enough swap to match your memory size (plus a little).

    In today's SSD flash (don't write needlessly) world, and cheap memory world, running without swap is "a thing". For many reasons.

    But, if hibernation is something you want/need, it works pretty well with Linux (noting that there are ton of edge cases).

    1. BinkyTheMagicPaperclip Silver badge

      Re: Of course, hibernation predates systemd (been around a long time in Linux)

      If I'm reading the documentation correctly (and it's not something I've tried, so implementation may vary) whilst hibernation does need a swap partition or file, Linux doesn't have to use it for swapping.

      The documentation also notes that hibernation can work with swap size smaller than memory. Which does make sense both because memory is usually not fully committed, and there will be duplication, discardable memory, and cache. All which can be potentially junked.

      Windows uses a hibernation file rather than using a pagefile, and I've found it to be effective and fast (I always hibernate my work laptop at the end of the day). It did take until at least the second Windows 10 revision before it was stable, however.

      1. Steve Graham

        Re: Of course, hibernation predates systemd (been around a long time in Linux)

        I have a little netbook which I use if I don't want to get out of the armchair...

        The power button toggles suspend-to-ram, which means that it "boots" in less than a second if I need it. Obviously, if I don't charge the battery for a week, or however long it takes, once recharged, pressing the power button will do a normal cold boot.

        I do have a script that does a suspend-to-disk if the battery gets very low, but of course, that only works when the device is alive. Historically, I've always created swap partitions larger tham memory size, but I'm pretty sure that suspend-to-disk does compression anyway.

    2. DuncanLarge

      Re: Of course, hibernation predates systemd (been around a long time in Linux)

      > In today's SSD flash (don't write needlessly) world

      Todays SSD's have lifetimes and wearlevelling abilities that make that detail a thing of the past. It is very unlikely you will ever wear out an SSD, like lightning you never write to the same place twice (well you eventually will).

      Thus re-ebable swap! The computer architecture we use is based on virtual memory, swap is part of the design. Yes you can turn it off technically but its not really a goot idea.

  14. Kurgan

    Systemd gets worse every day

    I hate that bloated cancer.

  15. dlc.usa
    Boffin

    SysVinit Scripts Deprecated

    Nobody seems to have noticed this:

    > * Support for System V service scripts is now deprecated and will be

    > removed in a future release. Please make sure to update your software

    > *now* to include a native systemd unit file instead of a legacy

    > System V script to retain compatibility with future systemd releases.

    There's a thread on the DNG mailing list discussing the ramifications at https://lists.dyne.org/lurker/thread/20230730.180432.a707194b.en.html#20230730.180432.a707194b

    1. DuncanLarge

      Re: SysVinit Scripts Deprecated

      > Nobody seems to have noticed this

      Dont worry, I have!

      Binary logs and Debian not using slslog by default was enough to make me finally jump ship.

      1. dlc.usa
        Linux

        Re: SysVinit Scripts Deprecated

        A new thread has sprung up on DNG due to an update to powerdns:

        https://lists.dyne.org/lurker/thread/20231011.112423.04ef68ef.en.html#20231011.112423.04ef68ef

  16. Anonymous Coward
    Linux

    Hibernation | Microsoft Fast Startup | systemd: Soft-reboot

    What's the difference between hibernation and ‘Microsoft Fast Startup’ and ‘systemd: Soft-reboot’. And is ‘systemd: Soft-reboot’ any faster?

    1. Solviva

      Re: Hibernation | Microsoft Fast Startup | systemd: Soft-reboot

      Hibernation brings you back to the point where you left off - that unsaved document is still there and still unsaved. Fast start, well applications may open, they may open documents that have been auto-saved from a checkpoint.

      This new soft-reboot is just that, if you have a running system, you could do a normal restarted aka warm boot, a cold boot where the BIOS/UEFI goes through all it's init stuff, or the systemd-boot where you basically skip the BIOS/UEFI part and the bootloader. Starting from cold/hibernation then this soft-reboot has no effect there.

      1. Anonymous Coward
        Boffin

        Re: Hibernation | Microsoft Fast Startup | systemd: Soft-reboot

        @Solviva: Hibernation brings you back to the point where you left off ..

        Yea, I partially understand that, Suspend loses the data if the power cuts. Hibernation can restore the the last active desktop. Could you further clarify what does “Microsoft Fast Startup” bring to the party. I suspect “systemd: Soft-reboot” is part of the strategy by Lennart Poettering to take over Linux.

  17. leppy232

    "Version 254 of systemd marks the 115th release of this ever-growing init system for Linux."

    I would love to see the math that went into that. I suppose it isn't surprising, considering my experience with systemd.

    1. georgezilla

      " ... I would love to see the math that went into that. ... "

      Apparently no one that works on system ever took Math. Math is hard. And I guess so is counting.

      Or is it that they just don't know, understand what the word "version" means?

      Either way, why do we trust someone and their systemd when they can't even fucking count?

      Someone please, PLEASE fucking explain this to me?

    2. Steve Graham

      There were "versions" which weren't "released"?

      1. nijam Silver badge

        > There were "versions" which weren't "released"?

        If only there were more of them. 100%, for preference.

    3. jake Silver badge

      To be fair, the numbering of releases in the world of Linux seems to be driven more on the whims of the maintainer than any coherent notion of progress.

  18. drankinatty

    A "new feature" is a "bug" if it cannot be "turned off".

    Hopefully the folks at freedesktop remember that axiom in implementing this ridiculous fast-boot feature. As I sit, I have a 12 second power-on to full-desktop from cold-start. What the hell do I need a fast-boot feature for? On Arch, with kernel updates weekly, if there isn't a clear way to turn this thing off -- that will cause a problem that never existed before.

    1. drankinatty

      Re: A "new feature" is a "bug" if it cannot be "turned off".

      Unfortunately, this is a case where El Reg (unintentionally) has made a mountain out of a mole-hill.

      This isn't some "change" in the way systemd will work, it is simply the addition of a new subcommand to systemd. You can choose to use it, or not use it, it's not something that systemd will impose by default (which is how I read the article to begin with). You either use the soft-reboot service and soft-reboot target, or you just continue using the normal graphical (or multi-user) target and 'systemctl reboot' instead of the new 'systemctl soft-reboot'. Arch has the soft-reboot man page up at https://man.archlinux.org/man/systemd-soft-reboot.service.8.en

      Whew... Glad I misunderstood the article.... Now the only fly-in-the-ointment will be -- what the distro maintainers do with the new subcommand. Heaven forbid they configure soft-reboot as the default.

  19. georgezilla

    System-d ...............

    Why can't we just have nice things any more? The more I see of system=d the more convinced it because nobody wants them.

    So when are are we going to stop calling our OS Linux and accept that is been completely infected and start calling it System-D OS?

  20. FF22

    Type

    "shuts down all the user's processors" => "shuts down all the user's processes"

  21. DuncanLarge

    I've put it off way too long.

    Time to finally jump ship. No SYSV init support? unit files in strange places like /usr/lib?? Soft reboots? Off I go.

    Regarding Fast Startup, this is not a "fast reboot" but a non-shutdown. It stops windows from shutting down fully, shutdown no longer exists, but a reboot in windows is still a full reboot. Its what we (as in my many IT positions and companies over the years) switch off. We noticed that updates were not getting installed all of a sudden only to discover this stupid feature in windows where a shutdown is no longer anything like a shutdown.

    We suddenly found that no windows updates were installing, for weeks. Why? Well two reasons. There was the usual users who never shitdown and just sleep the laptops all the time, they we have to remind manually to reboot. And then there was the rest, who dutifully would shutdown the laptop or pc at the end of the day as IT tell them to.

    Only the ones who rebooted got any updates. Fast Startup kills shutdown, it is more of a hibernate, in fact I was confused why it was there in the first place as hibernate is basically the same. In a Fast Startup enabled shutdown some parts of windows is shutdown, others are hibernated, particually the elements oif windows that typically take ages to boot when you boot. It actually makes a massive difference when booting off HDD, which is a nasty thing to do these days with windows 10 so bloated and inefficient. But it also prevents most windows updates installing.

    Thus users were weeks out of date. Instead of re-educating users to reboot THEN shutdown, we simply used GPO to turn off Fast Startup. Of course MS turned it back on again after certain updates!

    This soft reboot feature is something different, it affects reboots and not shutdowns. I can see it having some use, butreally its pedantic to try and shave off a few milliseconds of full boot time just because you updated a few things apart from the kernel. But tahts why systemD was created, because some laptop user wanted to have his laptop boot faster.

    I'm off to Devuan anyway, or maybe Debian with another init. Binary logfiles were the last straw and now Debian has got rid of text logfiles, well I just cant see why they are so insane. Lol they claimed "it would stop writing to the filesystem twice", as the binary logs are written followed by the text ones. Thing is for years the binary logs have been stored in a ramdisk...

    Yes I know I can turn them back on. What I want is sensible defaults, not an OS that I have to add loads of fixes to and config to just to get it working the sane way.

    1. Anonymous Coward
      Anonymous Coward

      Re: I've put it off way too long.

      ... off to Devuan anyway, or maybe Debian with another init.

      Devuan is arguably the best move forward, at least for now.

      But ... Debian with another init? 8^D !!!

      Sorry to be the one to break the news to you but that is definitely *not* in Debian's plans.

      Deprecating SystemV support was the last step in that direction.

      "Support for System V service scripts is now deprecated and will be removed in a future release. Please make sure to update your software

      *now* [1] to include a native systemd unit file instead of a legacy System V script to retain compatibility with future systemd releases."

      [1] the asterisks are not mine, they are in the original.

      The inevitable result will be that in a very short time there will be no SystemV compatible packages in the Debian repositories as devs/maintainers will not include init scripts for a deprecated init in their packages.

      That will very quickly extend to all Debian based distributions using systemd.

      ... cant see why they are so insane.

      That is because you are not looking far enough ahead.

      I've said it many times before: there is a lot of moolah behind making systemd the de-facto init for the Linux ecosystem.

      systemd is nothing but a MS registry for Linux and the main purpose is to turn Linux into a MS type OS.

      Like another commentard said:

      "... a developer sanctioned virus running inside the OS, constantly changing and going deeper and deeper into the host with every iteration and as a result, progressively putting an end to the possibility of knowing/controlling what is going on inside your box as it becomes more and more obscure."

      So ...

      Nothing new here: it is the old MS embrace, extend, and extinguish that has been going on for decades, only that now there's active participation from IBM/RH.

      Devuan (and derivatives) is still holding on but who knows for how long this will be so.

      .

  22. ArghUser

    "If you're not a system administrator, the new soft-reboot may well be what you notice most....."

    <Proceeds to explain what it is, what it does, a common scenario where it is bad. Then casually shows a way it can be easily fixed by using system administrator-level tools>

    Irony lost? Or is the goal of systemd is so that in pursuit of what could work, we discard what does.

  23. Fruit and Nutcase Silver badge
    Joke

    Resistance is Futile

    But the flipside is that it means systemd will gradually encroach on even more of your operating system.

    Where did the Borg get the idea?

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