Re: It is not that clearcut
"Bonus points for implementing a device that sits between your VT102 keyboard (VT52 acceptable; VT220 is right out)...
You do realise that the VT52 keyboard was part of the main unit? (see pic at top RHS)
Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.
Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.
systemd-free Devuan Linux hits version 1.0.0 Devuan, the effort to build a systemd-free version of Debian, has released Devuan Jessie 1.0.0, a release candidate felt to be just about the finished article. In a mail sent to the project's followers the self-proclaimed “Veteran Unix Admins” behind Devuan say “This Devuan Jessie release candidate is as close as we can get to …
"Bonus points for implementing a device that sits between your VT102 keyboard (VT52 acceptable; VT220 is right out)...
You do realise that the VT52 keyboard was part of the main unit? (see pic at top RHS)
I run Slackware. The vi clone is elvis. The arrow keys work ... if the keybr0ad has arrow keys, of course. I rarely find myself reaching for them, though, unless I'm in input mode ;-)
Seriously, try using vi as your shell. You'll be awfully surprised at how functional it is. For test purposes, create a user account with a vi shell. Pull up an xterm & log into that account. See what you can (and cannot) do with vi as your day-to-day CLI shell ... At the very least, you'll learn a lot more about vi than most folks. The concept was suggested to me in jest decades ago (1979ish) when a friend commented that "You seem to live in vi! When was the last time you saw a shell prompt?"
That's a distro issue - ideally the Debian Way would be to have an "Init System" virtual package (is that the right terminology?) that can be fulfilled in several different ways including systemd. But I guess it becomes difficult to do that at such a low level as the init system.
It wasn't difficult before systemd came along. Other inits aren't tied to disparate elements of the OS and don't pile so much functionality into a single package. They just run and manage daemons.
If systemd just ran and managed daemons, there wouldn't be any arguments.
It is a shame that Canonical gave up on 'upstart' as it was almost what was needed: an init process that could handle parallel start-up and dependencies. It could also be run as a user PID if users wanted an event-drives start-stops system, say for removable storage. And there it stopped, as it only wanted to be 'init' and not an octopus.
Plain Debian still allows you to switch to SysV init in a matter of minutes ...
Err, well sort of, but not really.
The problem (as already mentioned) is that SystemD just isn't an init system as it was described as whenever there was any dissent from using it. The problem is that there are so many tentacles that it invades all over the system to the point that you CANNOT uninstall SystemD without breaking an increasing amount of stuff. What you will find if you try it is that you cannot remove all vestiges of SystemD without making your system unusable - such are the gratuitous linkages with bits of SystemD that's enforced by SystemD reinventing established ways of having software interact with other bits of software/the system.
Y'know I STILL hope Devuan withers and dies, the sooner the better ... But the prospect of the Debian project eating some crow and seeing sense seems further away than ever.
So great work guys - I grabbed the relevant downloads last night just before I saw this this morning.
My production box is running Old Stable - so I'll need to upgrade shortly _AND I DON'T WANT SYSTEMD_ so I'll have a serious play with this.
Hopefully, unless things change elsewhere, this project will gain momentum and become the hub of a new distribution ecosytstem (like the way Mint sits/sat on Umbongo which sits on Debian). With so much of the heavy lifting to get this far done the nest release will hopefully follow on next Debian a bit more quickly and the team will be able to take a long look at a few other issues they're bothered about. Including everything pottering is trying to suck into systemd.
Why do you _NOT WANT SYSTEMD_ out of interest? It's an elegant system that works with easily understandable text-based configuration files. It's not a "Registry for Linux" as many articles/posts have claimed, it streamlines bringing up a Linux box and does away with a confusing script-based system that was years out of date and difficult to optimise/parallelise. A change of init system isn't something we should be doing more than once every couple of decades, but systemd seems very good to me.
"A change of init system isn't something we should be doing more than once every couple of decades, but systemd seems very good to me."
The problem is systemd is not JUST an init system, it adds in binary logging, time setting, module loading/blacklisting, and all sorts of other stuff that were pretty much already solved and workable. And in many cases it adds bugs/issues that seemingly just don't get fixed if they are not in line with Pottering's personal outlook.
If it were just a paralleled start-up system there would be far less issues, but instead we have fsking *desktops* like GNOME has become that have systemd as a dependency, WTF?!
"The problem is systemd is not JUST an init system, it adds in binary logging, time setting, module loading/blacklisting, and all sorts of other stuff that were pretty much already solved and workable. And in many cases it adds bugs/issues that seemingly just don't get fixed if they are not in line with Pottering's personal outlook."
I'm sure you've heard the following mantra from the Acolytes:
'The beauty in GPL software is that if you don't like it, you can just grab the code and fix it yourself.'
There. Problem solved. ;-)
'The beauty in GPL software is that if you don't like it, you can just grab the code and fix it yourself.'
Quite so, but generally speaking a user would prefer not to have to fix bugs introduced by twats like Poettering. Fixing accidental bugs, incompatibilities and adding functionality is one thing but having to repair the damage done because somebody working high up wants to dictate how your system should work and doesn't give a flying f*** about complexity, compatibility or usability is something I'd rather not have to do.
Especially when the other big names in Linux have their collective hooters stuffed firmly up Poettering's taskmaster's rear end and will not see reason.
"Why do you _NOT WANT SYSTEMD_ out of interest? It's an elegant system"
It is precisely because it is _not_ an elegant system that I don't use it on my Debian systems. It pokes its nose into all kinds of things it shouldn't. It makes non-standard setups unnecessarily difficult. It facilitates wide-ranging attack exploits by enforcing uniformity everywhere. It makes low level troubleshooting more difficult. Each new version exhibits unpredictable behaviour which makes it risky to use on a remote system. Need I go on?
To be fair, you could describe the unit file configuration system on its own as elegant, but the additional feature creep and complexity rule it out for me.
I had actually dismissed Devuan, but I'm pleased to see they've reached this stage.
I was willing to learn it (I mean, I learned Solaris SMF, which is even more opaque, and I even sort of understand OS X's launchd). But I got very irritated with a number of bugs that no one seemed interested in fixing because they only affected servers, not the desktop machines systemd targets. For example, it became impossible to reboot a machine via ssh if it had automounted NFS shares; it would hang in the shutdown process every time, requiring physical power cycling. Bug reports about this were met with a collective shrug.
Personally I find FreeBSD's init system refreshingly simple.
It's not a "Registry for Linux" as many articles/posts have claimed,
It's something a lot more sinister than a "registry". Something like a registry could be added if one were really needed without everything that systemd is bringing into being.
it streamlines bringing up a Linux box and does away with a confusing script-based system
There was nothing confusing about it. When comparing the various sysvinit machines with my current crop of systemd systems, the way in which systemd is gobbling up various modules and making them difficult, sometimes impossible, to access is, if anything, overcomplicating what was previously trivial to work on.
that was years out of date and difficult to optimise/parallelise.
The age of the system is immaterial if it works. As for optimisation, sysvinit was pretty good where that was concerned and "parallelisation" is merely yet another fad which has little real use.
Having said that, the most recent Devuan beta felt like a bit of a let down when I tried it; even the first beta worked better for me. I'll give it a go with a view to possible future use but it all depends on how well it is set up and, more importantly, how well updating works.
You know what *is* confusing? The new unit files.
Sure, they work. They can build all sorts of dependencies and stuff and you can tell something not to start until something else has started, all that good stuff.
And the old /etc/rc.d/rc?.d/[ks]* symlinks to /etc/rc.d/ scripts also controlled ordering.
Ah, "butt parallelization". Sure. When you're booting a server or a high-end workstation that takes several minutes to enumerate its hardware, you don't care whether the OS boots in 30 seconds or 4 minutes. So systemd's *only good feature* was designed expressly to solve a problem with noddy laptops and other prat-about hardware that's better solved by a decent SSD.
The new unit files ... Sure, they work
Not always.
I had to write some systemd unit files the other week. One of them had to start after the DM - lightdm in this case - had started. So I used systemd to control the dependency.
Except that it doesn't work; my unit was started after lightdm had started to come up, not once it was functional. I ended up having to do the synchronisation by hand in a script - so it had the worst of all possible worlds.
SysV is so much simpler...
Vic.
An elegant init system according to UNIX philosophy is a system that does exactly as little as possible in the simplest and sanest way as to be functional at its intended task.
init should not have an attack surface, it should not handle anything more than necessary - its purpose is to start the rest of processes needed for the system to function. Implementing runlevels, parallel startup, dependencies, and process supervision are potentially sensible additions, that don't raise the footprint very much.
For me, the part that is unforgivable about systemd is that it is invasive. Its very existence is a threat to the fundamental architectural principles of simplicity, isolation, transparency, and modularity that were so central to the success, stability and widespread adoption of UNIX and Linux. We're seeing deep dependencies on systemd in software that should have no reason to be aware of an init system, much less interact with one.
> It's an elegant system that works with easily understandable text-based configuration files
No, it's not elegant, and the config files are no easier to understand than the scripts used previously.
> A change of init system isn't something we should be doing more than once every couple of decades
Agreed, but systemd is not an init system (hint: init is an init system). Systemd is spaghetti architecture - even calling it "architecture" at all is generous, of course.
It's a pity that they weren't able to release in 2015, when it was possible mostly to remove systemd from Debian itself, but it seems they must have been gearing up to understand the way systemd has become a dependency even when you don't use it as an init, exactly the issue Devuan warned about.
I mostly use systemd on Debian servers now, but that's because it's becoming harder not to. It's possible on a server, but you just start hitting little irritants. That demonstrates that systemd is far more than the init it claimed to be replacing. I once swapped MTAs from sendmail to postfix at a company with about 400 users. This was done in the middle of the working day, with no loss of service. That's what the unix way of building blocks for services allows, but choosing to run an alternative init is now what systemd expressly prevents in many use cases. Such a pity that Debian, for one, didn't remain neutral in this.
I'd love Devuan to gain credibility and become a plausible alternative.
Thank you for contributing.
For those who would like to contribute in non-technical ways (eg $$$/£££) is there an easy way to do so?
Personally I'd like to stay with Suse but if there's no easy systemd-free option to do so, I'd like there to be some other options too.
TIA
Linux user since RH4...
Yes thanks, I was and am serious, and yes I'll be donating a few pounds/dollars/euros today, and hopefully more to come (times are a bit straitened at the moment).
Reminder, here's why I'm donating, you don't need to be a Linux geek (or much of a geek at all) to understand it, it's two minutes to read, and forever to wonder "why?" and "how?" we got here:
https://github.com/systemd/systemd/issues/5644
I've been donating few quid monthly since the start of the project, also without immediate plan on using it - I have systemd-infested Arch which, for my use, works well enough. So basically my motivation was not as much "displeasure" with systemd as exactly what Devuan promotes - init freedom, for others and perhaps for me (in the future).
Ok, I'll bite. I've done moderate Linux stuff for many years. I get by fine, but I don't put myself in the sage greybeard class.
I've rather like moving to systemd. I'm not a hard core guru of that either, but I've like having some structured approaches to common unit script patterns. I like it much better than the competing "let's just make the scripts more structured with a layered on meta language" that I was having to learn with Upstart and other distorts variants.
So let's say that systemd solves these problem in a deplorable way, does the anti systemd crowd actually have an alternate solution to some of the problems systemd wanted to solve? Or is it just a party of no?
"Or is it just a party of no?"
In short, no it isn't a party of no just for the sake of it.
A lot of people, including me, dislike and distrust systemd because it does not do what it claims. It is supposed to be an init system but due to creep it has its fingers in a lot of other pies as well. Added to that are the like of a binary logging system which adds complexity and Poeterring's seeming fixation on turning Linux into a Windows clone complete with a Registry. I know that people say that systemd speeds up booting but who needs a quick boot on a server and at what cost? Finally as others here have said systemd turns its back on the Unix mantra "Do one thing and do it well."
Does Gnome "do one thing and do it well"? Of course not, it's a GUI desktop environment, not a single program. Within Gnome there are many different executables that form a (sometimes) coherent and cohesive whole and are developed and maintained as a project, and hopefully each executable within Gnome does follow the Unix philosophy. Systemd is exactly the same - it's a collection of small binaries developed and maintained as a project that can form the next step (after a bootloader and kernel) of a complete operating system. There are pros and cons, but systemd does provide a robust mechanism for that bottom layer of a working system and seems to me a far better approach than a collection of shell scripts.
> Does Gnome "do one thing and do it well"?
Gnome is amongst the worst examples you could possibly have picked, given that it's another project that's continually criticised (generally for dumbing down and removing useful features).
It's also a Desktop Environment, so it's kind of expected that it'll contain a wide variety of binaries (just as XFCE, KDE and other DE's do). It's still largely focused on one area though - being a Desktop Environment.
Systemd was supposed to be init, but the wider project has now pulled in other things too (ranging from udev to network management). Technically those other area's aren't part of the init process (in that they're not in PID 1) but they are now part of systemd, leading to systemd increasingly becoming a dependancy for other packages which shouldn't otherwise require systemd specifically.
I have days where I outright hate SystemD, and I have days where I'm ambivalent about it. Can't say I've ever felt good about SystemD though (though the same is probably true for SysV). JournalD and FirewallD though, can die in a fire.
"Does Gnome "do one thing and do it well"?
Nope, and I don't use it either. I even gave up on XFCE and switched to something simpler than that.
Gentoo is still init-system agnostic, and you are free to pick openrc, systemd, or whatever other init system people care to package.
I find systemd annoying when I have to do anything with Ubuntu, CentOS, Suse, etc. But, I haven't really report any problem with it -- all of my daily-use machines use openrc.
"it's a collection of small binaries developed and maintained as a project that can form the next step (after a bootloader and kernel) of a complete operating system."
There were already binaries doing those jobs and doing them well. One of the key things about them was that although they worked together they had well defined boundaries and interfaces between themselves. They did not need to be replaced by an interdependent mess.
One statement made early in the invasion concerned the new systemdified udev. It could be run without systemd but it couldn't be compiled without it. WHAT?????!!!!! This shower couldn't - or wouldn't - structure their code so that common libraries went into one or more source files and the individual programs could be compiled against those without needing to delve into each other's code. Were they really that ignorant of good practice or were they deliberately flouting it? I don't know and frankly I don't care; to know was enough.
This post has been deleted by its author