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 …
"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!".
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... ;) )
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.
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.
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.
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.
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.
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?
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.
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.
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.
>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.
[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?
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.
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.
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.
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.)
"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.
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.
""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.
"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?
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.
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.
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.
"...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.
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.
"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.
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.
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.
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.
> 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.
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... ;)
[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.
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.
"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?)
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.
"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?
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.
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.
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.
"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.
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?
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....
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.
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.
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.
"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,
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).
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.
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.
> 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.
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
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.
@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.
" ... 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?
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.
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.
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.
... 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.
.
"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.
io_uring is getting more capable, and PREEMPT_RT is going mainstream The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
