each to his own
It also became a crucial dependency for many software packages, locking people in.
It's going to take a while before I embrace anything with lock-in.
Senior Red Hat techies this week urged Red Hat Enterprise Linux sysadmins to give Systemd a chance if they haven't already taken the software to heart. At the 2018 Red Hat Summit in San Francisco on Wednesday, Linux container product manager Ben Breard, and senior principal engineer and Systemd co-creator Lennart Poettering, …
Just no. The last thing I want an improved PID1 to have is more points of failure, and a larger surface for attack. I'm sticking with Slackware and the BSDs for many reasons, but a large one is the clusterfuck known as systemd.
And yes, I have given it a fair look. Several times, in several incarnations. It's ill conceived at best.
I was replacing an aging bit of HW and SW last week (a box that had been built to be a dedicated firewall). I tried to do the right thing and went with a "modern" (i.e., uses systemd) Linux. I spent wa-a-ay too darned much time trying to get systemd to run the script with all the the local firewall rules, logging, etc., as part of a systemd service. Eventually I said "screw this", installed Slackware on the new box, copied the firewall script onto it, made a couple of straightforward tweaks on a couple of scripts and configuration files, changed permissions on another, rebooted, and... done. In far, far less time than I had spent to /not/ have a working firewall set up using a systemd-based system.
"trying to get systemd to run the script"
There's your problem. I suspect that systemd was written by (and for) people who have an absolute aversion to shell scripts. When I have gotten systemd to start a service by pointing it at a (suitably modified) init script, its supporters have replied with something approaching an autistic outburst. When systemd was first under development, the outcry against init was 'just look at how many process IDs it uses'. I suspect that these people came from a Windows background. Where running out of resources is a real issue and solved by repeated reboots.
Sure, scripts are slower and less able to leverage parallelism. For processes that run several times a minute or more, this is significant. But startup and shutdown are typically run every few weeks on my machines. A few more seconds isn't going to kill me. But here again, something that is an anathema in the Windows world where this has to be done frequently.
"And perhaps, in the process, you may warm up a bit more to the tool"
Like from LNG to Dry Ice? and by tool does he mean Poettering or systemd?
I love the fact that they aren't trying to address the huge and legitimate issues with Systemd, while still plowing ahead adding more things we don't want Systemd to touch into it's ever expanding sprawl.
The root of the issue with Systemd is the problems it causes, not the lack of "enhancements" initd offered. Replacing Init didn't require the breaking changes and incompatibility induced by Poettering's misguided handiwork. A clean init replacement would have made Big Linux more compatible with both it's roots and the other parts of the broader Linux/BSD/Unix world. As a result of his belligerent incompetence, other peoples projects have had to be re-engineered, resulting in incompatibility, extra porting work, and security problems. In short were stuck cleaning up his mess, and the consequences of his security blunders
A worthy Init replacement should have moved to compiled code and given us asynchronous startup, threading, etc, without senselessly re-writing basic command syntax or compatibility. Considering the importance of PID 1, it should have used a formal development process like the BSD world.
Fedora needs to stop enabling his prima donna antics and stop letting him touch things until he admits his mistakes and attempts to fix them. The flame wars not going away till he does.
SystemD is corporate money (Redhat support dollars) triumphing over the long hairs sadly. Enough money can buy a shitload of code and you can overwhelm the hippies with hairball dependencies (the key moment was udev being dependent on systemd) and soon get as much FOSS as possible dependent on the Linux kernel. This has always been the end game as Red Hat makes its bones on Linux specifically not on FOSS in general (that say runs on Solaris or HP-UX). The tighter they can glue the FOSS ecosystem and the Linux kernel together ala Windows lite style the better for their bottom line. Poettering is just being a good employee asshat extraordinaire he is.
> A solution that no one wants for problems no one has.
That's not strictly true - systemd introduces loads of additional problems...
I've just hit another, and the answer was classic. I'm testing OpenSUSE 15.0, and as expected it is already rock solid. But there's an odd error message about vconsole at boot, a known issue for a few years. Systemd's (Poetering's) response is that an upstream application has to change to fit in with what systemd wants to do. It's that attitude, of forcing changes all over the linux ecosphere, that is a genuine cause for concern. We thought that aggression would come from an antagonistic proprietary corporate, but no, it's come from the supposed good guy, Red Hat.
Lennart Poettering is a typical GERMAN idiot. He clearly lives in the wrong century, still believes in BS his country is known for and the world had to suffer for. Poettering is also responsible for the PulseAudio fuck up (he broke audio in Linux desktop).
Linus, please ban Poettering for his entire live. Revoke his GIT permissions. Ban this asshole who gets paid by M$.
Lennart Poettering is a typical GERMAN idiot. He clearly lives in the wrong century, still believes in BS his country is known for and the world had to suffer for.
You are clearly taking it a runway too far, here ... he happens to be German, yes, but crikey, what does that have to do with his over-dimensioned ego ?
Poettering is also responsible for the PulseAudio fuck up (he broke audio in Linux desktop).
Indeed, but back then he made one good design choice, have pulseaudio to run atop NOT REPLACE GNU sound subsystems. Had he done the same with systemd, I would have been happy, too. (I'd just remove it, job done)
Agreed, Solaris svcadm and svcs etc are an example of how it should be done. A layered approach maintaining what was already there, while adding functionality for management purposes. Keeps all the old text based log files and uses xml scripts (human readable and editable) for higher level functions. Afaics, systemd is a power grab by red hat and an ego trip for it's primary developer. Dumped bloatware Linux in favour of FreeBSD and others after Suse 11.4, though that was bad enough with Gnome 3...
Dumped bloatware Linux in favour of FreeBSD and others after Suse 11.4,
Thing is, I'm kinda liking mainstream Linux at the moment. I started seriously with OpenSuse around the time you left, and the current Leap and Tumbleweed distributions are good enough that the whole family - which is used to Windows and OSX - is happy to use them day-to-day. They can do practically everything they need to with relatively little fuss on my part. I have TW on one machine only, mainly because of an up-to-date kernel which understands my graphics card. It's not quite "fit and forget", but it's pretty easy on the whole.
I've dabbled with various BSDs and I like the philosophy, but I've yet to find one that is as easy to install, update and maintain as mainstream Linux. Any suggestions? Something that's non-threatening for the family?
In my honest experience, keeping Linux systems running smoothly is generally a pain—or maybe I just suck at it.
Incompetence aside, I highly recommend FreeBSD for sysadmin use, and TrueOS for enduser workstations. Wanna know how easy it is to update your system from the terminal?
#freebsd-update fetch install
rebuild any customized ports with `make install':
upgrade binary packages:
#pkg upgrade -y
Boom you are done. TrueOS has an autoupdater that basically does this for you.
AND, if you compile your packages and put them on a central repo on your local network, on the workstations you can completely skip portsnap and manual builds. Just add the repos to your pkg config and add a cron job to autoupdate. While manual upgrades are advised, I haven't had any major breakages when upgrading packages. Just peek at /usr/ports/UPDATING every once in a while to make sure any ports you use don't have any weird issues.
Unlike apt and derivatives, pkg_ng (FreeBSD ports binary package management) in my experience is often free from the cyclic, broken, and incorrect dependencies that tends comes with—again , in my experience. Not hating on apt or those that like it, but I have never not had a problem with apt, yum, etc. on any Linux system I have ever used, no lie. Even NetBSD's pkgsrc is admittedly lacking in some areas. FreeBSD has in my opinion the best package management in the industry. It is dead simple and even in my years of mildly advanced usage I have not had a single problem that was nontrivial to fix, in addition to it being easy to administrate.
However, caveat emptor:
Hardware support on BSD is lacking; you can't buy some off-the-shelf i7 laptop from Best Buy and expect BSDs to work on it—it's possible but unlikely. While some people have been working on porting Wayland, you are generally stuck with Xorg. Video drivers are often outdated or just garbage to begin with. Some things like Bluetooth are shoddy (NetBSD's Bluetooth stack is better IMO). Packages, while plentiful, are updated by the community, and nowadays especially some may not be getting the updates they need—updates that may require code patches to get the new upstream code to compile and run. SysV-style init, only partially async; some may consider this a plus. Kernel, while straightforward, does have some eccentricies and is missing features Linux has had for years.
Some upsides, though: Built-in email framework (ships with Sendmail, EW! but Postfix is a simple two-command install to get it replaced), built-in audio subsystem compatible with OSS and thusly alsa and pulseaudio through OSS compatibility sources, built-in hypervisor `bhyve' with HVM and HDAudio support (run Windows etc.), built-in kernel-mode Linux emulation layer that lets you run unmodified Linux binaries (it's kinda old and crufty though), all configs are easy to read and plaintext, absolutely amazing docs and manpages, a clean and easy to grasp system structure, and an active community willing to help with whatever you need. Additionally TrueOS is incredibly simple to administrate since it's just a graphical distribution of FreeBSD.
There's a lot you will lose by switching that modern Linux distros take for granted, but in return you will find raw sinplicity, the Unix philosophy, and a license allowing you to do almost whatever you want with the codebase. The BSDs also share a lot of common utilities with some popular GNU/Linux distros, like wpa_supplicant, dhcpcd, etc.
Wanna know how easy it is to update your system from the terminal?
What you describe is hardly "easy" - having to rebuild packages for a start. And how do you know which ones? OpenSuse Leap has a little thing that pops up on the desktop and says "you have <n> updates". You click "install updates" and generally speaking - the rare reboot aside - you're done. I'll investigate TrueOS - it sounds a bit like this.
Tumbleweed behaves better if you do updates from the commandline, but it is a single-line command:
sudo zypper dup --no-allow-vendor-change
and you may have a couple of choices to make if there are dependency issues.
Now that's "Boom you are done".
Oh, and whatever else you may say about BTRFS (and I have had my share of problems with it), it does do snapshots very well which means that if an update does something stupid (not seen this on Leap, but have a couple of times with TW) and borks your system, it's a quick reboot from a snapshot, a
sudo snapper rollback and you're back where you started.
As for the downsides you mention... I did say that I have a family that wants to "use" an OS, not be awed by its "raw simplicity". Will it run SuperTuxKart? Will it run Kdenlive (or similar)? Does it talk nicely to Android phones? To the Postscript printer? Can they watch CBBC on the iPlayer?
Note you only have to rebuild packages if you change their default compile options, just like with any other modern distribution that will generally only offer one or two variants of a package. I only added that part for completeness. "How do you know which ones" applies only to those packages: the rest is automatic and hassle-free; if you're compiling ports you will know already which ones to recompile. However, there are also various port tools that allow you to autonate even this process, so if you don't want to deal with it you can just set it up to work automatically, basically with a pourderie pkg repo and build scripts—the end user won't have to do anything, and you will just have to check build logs every blue moon to make sure nothing blows up. And yes, when it comes to one-button updates, that is the kind of experience you will see with TrueOS... Though admittedly I haven't used it much since it was rebranded from PC-BSD. But if it was as simple to use as it was back then I assume it will be even better now.
The only thing you will be running regularly if you don't care about manual package compilation and you aren't using TrueOS package management is the `pkg' command I mentioned, equivalent to your updating on Tumbleweed. I'll admit I don't have much history with zypper so I can't speak on that. I have only had long-term experience with apt, and speaking of that I had an autoremove command nuke a GalliumOS Chromebook the other day... My fault for not realizing it was happening, but there you are.
I haven't mentioned any problems with BTRFS, in fact I like it. I do like ZFS more however, which is now wonderfully stable and available on both BSDs and Linux boxen. They both perform their tasks adequately enough and which to use at this point is more down to which userland tools you prefer, unless you require absolute performance or the choice is mission-critical.
When I say raw simplicity is a plus, I mainly aimed that towards you, the implied sysop and manager of your family's systems. BSDs are easy to administrate AND understand; systemd-based distros and Windows-like GNU/Linux systems (think Mint) are all well and easy to administrate too most of the time, but the second anything goes wrong expect it to do so catastrophically... At least that's my experience with them. YMMV, and at the end of the day the system you know best will be easiest for you to work with, which aside from the pros of using the BSDs is partially why I stick with them despite the downsides.
As for your family and their usage of applications: whether or not it's a joke I recall SuperTuxKart being in both FreeBSD ports and NetBSD pkgsrc; I have no experience with Kdenlive but when it comes to editing I generally stick with compositors like Natron which usually works fine with my setup; I don't know what you mean by "talk", if you mean "plug it in and your DE handles it appropriately" I have never had the want to do this aside from adb and MTP transfers (a fusefs driver is available for both FreeBSD and NetBSD at the minimum), but I imagine TrueOS would either be able to handle it or can have the functionality added; CUPS/GhostScript/etc works fine and I print plenty, and if you prefer Avahi and other Poetterings can make it rather simple to get a printer up and running; I have never used iPlayer but if it's browser-based FreeBSD Chrome has DRM support... If it's an application you can check freshports.org to see if it's listed.
Obviously the layman is not going to appreciate all the benefits of a BSD system, just as the layman is equally not going to appreciate all the benefits of a GNU/Linux system. The difference is there are a number of projects and initiatives in the Linux ecosystem to try and dumb things down as much as possible for the hapless soccermom endusers, while the main project in the BSD ecosystem that I would think is actually usable in a day-to-day trend is TrueOS—unless you want to set up your own system for them, which in and of itself is not a difficult task, but it does require some upkeep. For example, I have FreeBSD running LXDE and various Wine-powered applications (Office 2010, etc) on my mom's laptop, and she is absolutely fine with it, 'specially because we don't have to waste money on more Windows licenses. It took some time to explain to her how things worked and the underlying benefits but now she's smarter for it and has a faster, less-crashy system, and the battery lasts nearly 1.8x as long compared to when it had Windows 10. Admittedly the battery part is merely a side-effect of not using Windows and reducing the clock rate, so it's not really a BSD-only thing.
Raise your hand if you've been completely locked out of a server or laptop (as in, break out the recovery media and settle down, it'll be a while) because systemd:
1.) Couldn't raise a network interface
2.) Farted and forgot the UUID for a disk, then refused to give a recovery shell
3.) Decided an unimportant service (e.g. CUPS or avahi) was too critical to start before giving a login over SSH or locally, then that service stalls forever
4.) Decided that no, you will not be network booting your server today. No way to recover and no debug information, just an interminable hang as it raises wrong network interfaces and waits for DHCP addresses that will never come.
And lest the fun be restricted to startup, on shutdown systemd can quite happily hang forever doing things like stopping nonessential services, *with no timeout and no way to interrupt*. Then you have to Magic Sysreq the machine, except that sometimes secure servers don't have that ability, at least not remotely. Cue data loss and general excitement.
And that's not even going into the fact that you need to *reboot the machine* to patch the *network enabled* and highly privileged systemd, or that it seems to have the attack surface of Jupiter.
Upstart was better than this. SysV was better than this. Mac is better than this. Windows is better than this.
System won't shut down because its already shut down ens160 (the network) and is now waiting to close the tcp connection that's open by rsyslogd. You may as well go to lunch and have a few drinks because its going to take quite some time.
Considering all of the "won't fix" bugs in PulseAudio, I'm surprised that RedHat hasn't assigned Poettering to their Kernel developer team. I'd pay big money to be within earshot of Linus when he got that bit of news.
"I'd pay big money to be within earshot of Linus"
Linus has already banned Poettering from the kernel because he doesn't play nicely with others. I suspect that's what has driven this attempt at taking over all systems ("distros") that run on top of the Linux kernel. Fragile egos are common in folks afflicted with persistent antisocial behavior.
Might just be a Debian thing as I haven't looked into it, but I have enough suspicion towards systemd that I find it worth mentioning. Until fairly recently (in terms of Debian releases), the default configuration was to murder a user's processes when they log out. This includes things such as screen and tmux, and I seem to recall it also murdering disowned and NOHUPed processes as well.
As an older timer (on my way but not there yet), I never cared for the init.d startup and I dislike the systemd monolithic architecture. What I do like is Solaris SMF and wish Linux would have adopted a method such as or similar to that. I still think SMF was/is a great comprise to the init.d method or systemd manor. I used SMF professionally, but now I have moved on with Linux professionally as Solaris is, well, dead. I only get to enjoy SMF on my home systems, and savor it. I'm trying to like Linux over all these years, but this systemd thing is a real big road block for me to get enthusiastic. I have a hard time understanding why all the other Linux distros joined hands with Redhat and implemented that thing, systemd. Sigh.
You're not alone in liking SMF and Solaris.
AFAICT everyone followed RedHat because they also dominate Gnome, and chose to make Gnome depend on systemd. Thus if one had any aspirations for your distro supporting Gnome in any way, you have to have systemd underneath it all.
RedHat seem to call the shots these days as to what a Linux distro has. I personally have mixed opinions on this; I think the vast anarchy of Linux is a bad thing for Linux adoption ("this is the year of the Linux desktop" don't make me laugh), and Linux would benefit from a significant culling of the vast number of distros out there. However if that did happen and all that was left was something controlled by RedHat, that would be a bad situation.
Remember who 'owns' SMF... namely Oracle. They may well have made it impossible for anyone to adopt.
That stance is not unknown now is it...?
as for systemd, I have bit my teeth and learned to tolerate it. I'll never be as comfortable with it as I was with the old init system but I did start running into issues especially with shutdown syncing with it on some complex systems.
Still not sure if systemd is the right way forward even after four years.
SMF should be good, and yet they released it before they'd documented it. Strange priorities...
And XML is *not* a config file format you should let humans at. Finding out the correct order to put the XML elements in to avoid unexplained "parse error", was *not* a fun game.
And someone correct me, but it looks like there are SMF properties of a running service that can only be modified/added by editing the file, reloading *and* restarting the service. A metadata and state/dependency tracking system shouldn't require you to shut down the priority service it's meant to be ensuring... Again, strange priorities...
I have a hard time understanding why all the other Linux distros joined hands with Redhat and implemented that thing, systemd
A lot of other distros use Redhat (or Fedora) as their base and then customise it.
A lot of other distros include things dependant on systemd (Gnome being the one with biggest dependencies - you can just about to get it to run without systemd but it's a pain and every update will break your fixes).
Redhat has a lot of clout.
If systemd is the MCP, does that make Poettering Sark ?
"Greetings. The Master Control Program has chosen you to serve your system on the Game Grid. Those of you who continue to profess a belief in the Users will receive the standard substandard training which will result in your eventual elimination. Those of you who renounce this superstitious and hysterical belief will be eligible to join the warrior elite of the MCP. You will each receive an identity disc. Everything you do or learn will be imprinted on this disc. If you lose your disc, or fail to follow commands, you will be subject to immediate de-resolution. That will be all".
Hmm, this explains a lot...
How about maybe not?
I was pretty open minded about it at first, but the more I learn about it, the more it annoys me. It's really trying to be too much.
Want a better init system? Build a better init system. Don't make it do things no init system was ever meant to do.
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.
This is scarily possible and undeserving of the troll icon.
Harkens easily to non-critical software developers intentionally putting undocumented, buggy code into production systems, forcing the company to keep the guy on payroll to keep the wreck chugging along.
But replacing it with systemd is akin to "fixing" the restrictions of travel by bicycle (limited speed and range, ending up sweaty at your destination, dangerous in heavy traffic) by replacing it with an Apache helicopter gunship that has a whole new set of restrictions (need for expensive fuel, noisy and pisses off the neighbors, need a crew of trained mechanics to keep it running, local army base might see you as a threat and shoot missiles at you)
Too bad we didn't get the equivalent of a bicycle with an electric motor, or perhaps a moped.
"It sounds super basic, but actually it is much more complex than people think," Poettering said. "Because Systemd knows which service a process belongs to, it can shut down that process."
Poettering and Red Hat,
Please learn about "Process Groups"
Init has had the groundwork for most of the missing features since the early 1980s. For example the "id" field in /etc/inittab was intended for a "makefile" like syntax to fix most of these problems but was dropped in the early days of System V because it wasn't needed.
That is the main problem. With different processes you get different results. For all its faults, SysV init and RC scripts was understandable to some extent. My (cursory) understanding of systemd is that it appears more complicated to UNDERSTAND than the init stuff.
The init scripts are nice text scripts which are executed by a nice well documented shell (bash mostly). Systemd has all sorts of blobs that somehow do things and are totally confusing to me. It suffers from "anti-kiss"
Perhaps a nice book could be written WITH example to show what is going on.
Now let's see does audio come before or after networking (or at the same time)?
> Now let's see does audio come before or after networking (or at the same time)?
That depends on your combination of the Conflicts, Before, After, Wants, WantedBy, Requires, RequiredBy, Depends, Needs, NeededBy, PartOf, Contains, Encompasses, and LikesCuddlingWith directives, and I think I only made three of those up, and good luck guessing which of these go into the Unit section and which into the Service section.
Frankly, systemD's abominable configuration scheme needs to be thrown away, shot, buried, and replaced with more structured methods, because the thesaurus is running out of synonyms.
> Frankly, systemD's abominable configuration scheme needs to be thrown away, shot, buried, and replaced with more structured methods, because the thesaurus is running out of synonyms.
Lennart Poettering is a German who can barely articulate himself in English. https://en.wikipedia.org/wiki/Lennart_Poettering
Let's ban Poettering from Linux, and his PulseAudio and SystemD. And let's revert back to MATE, as GNOME3 is butt ugly.
A connection to PulseAudio, why am I not surprised.
Audio that mysteriously refuses to recognize a browser playing audio as a sound source.
"Predictable" network interface names? Not to me. I am fine with "enp" and "wlx", but the seemingly random character strings that follow are not predictable. Oxymoronic.
I dropped Gnome when it went 2.0. Ubuntu when it went to Unity. Firefox when it redesigned the theme to just appear different.
To digress, I am so, so disappointed in Firefox and Mozilla. A shell of what they once were, now dedicated to the Mozilla "brand" as if they're a clothing company.
Why has technology in general gone down the shitter? Why is everything so awful? Will anyone save us from this neverending technohell?
"Why has technology in general gone down the shitter? Why is everything so awful?"
Coz the most important thing in the world is making more profit than you did last quarter. Nothing else is important.
"Will anyone save us from this neverending technohell?"
I try, but every one ignores me, coz I don't have the marketing department of the profit makers.
Yes - for people with fish allergies.
Systemd seems to me to be an attempt at "Embrace, extend, and extinguish" .
With some time any reasonable competent programmer can follow init scripts and find out where any failures in startup are occurring. As init is purely driven by the scripts there are no hidden interactions to cause unexplained failures. The same is NOT true of systemd.
The source of systemd is 15628582 bytes in size - the source of sysvinit is 224531 bytes (less than 2% of the size). (Both sizes from zips of the sources downloaded today - does not include config files makefiles etc - only the contents of the src directory.)
It is of note that the most widely used Linux kernel of all - (the kernel in Android) does NOT use systemd
Not to be seen as supporting Systemd, but the kernel version on my Android 7 phone is 3.18.31 (Anyone know what version Android 8 is generally at?), and I am under the impression that Google has a much different approach overall as to how they fit all the Android OS pieces together due to phone architectural/operational needs (not to mention their "intrusion requirements")?
If they removed logging from the systemd core and went back to good ol' plaintext syslog[-ng], I'd have very little bad to say about Lennart's monolithic pet project. Indeed, I much prefer writing unit files than buggering about getting rcorder right in the old SysV init.
Now, if someone wanted to nuke pulseaudio from orbit and do multiplexing in the kernel a la FreeBSD, I'll chip in with a contribution to the warhead fund. Needing a userland daemon just to pipe audio to a device is most certainly a solution in search of a problem.
And disk mounting
Well, I am compelled to agree with most everything you wrote except one niche area that systemd does better: Remember putzing about with the amd? One line in fstab:
nasbox:/srv/set0 /nas nfs4 _netdev,noauto,nolock,x-systemd.automount,x-systemd.idle-timeout=1min 0 0
Bloody thing only works and nobody's system comes grinding to a halt every time some essential maintenance is done on the NAS.
Candour compels me to admit surprise that it worked as advertised, though.
No worries, as has happened with every workaround to make systemD simply mount cifs or NFS at boot, yours will fail as soon as the next change happens, yet it will remain on the 'net to be tried over and over as have all the other "fixes" for Poettering's arrogant breakages.
The last one I heard from him on this was "don't mount shares at boot, it's not reliable WONTFIX".
Which is why we're all bitching.
Break my stuff.
Web shows workaround.
Break workaround without fixing the original issue, really.
Never ensure one place for current dox on what works now.
Repeat above endlessly.
Fine if all you do is spin up endless identical instances in some cloud (EG a big chunk of RH customers - but not Debian for example). If like me you have 20+ machines customized to purpose...for which one workaround works on some but not others, and every new release of systemD seems to break something new that has to be tracked down and fixed, it's not acceptable - it's actually making proprietary solutions look more cost effective and less blood pressure raising.
The old init scripts worked once you got them right, and stayed working. A new distro release didn't break them, nor did a systemD update (because there wasn't one). This feels more like sabotage.
I haven't been working with Linux for many years, 4+ and I've found that the people with the problem with it are more of the Torvalds type, old school (apparently nothing like it. No package managers, wooo) and people stuck in their ways.
I guess as a relative newbie to the OS and being a relatively young man I can embrace changes a lot more easily.
*pushes chest out* My names Chris. And I like systemD
And theres a nugget of truth to that AJ my lad.
But to be pessimistic and outright dismissive of a new concept is just ridiculous. If its broken and you think you know best, help us make it work.
Sometimes people just like to stick with whats comfortable to them and have everyone else bend to their hissy fits. Sometimes you have to bend.
Are you a bender AJ? I am.
Was INIT always as good as they've built it up to be? OR was it as shite at the start and improvements and bug fixes came along later to make it better.
If RH stick with systemD I've no doubt some good developments will come with it.
I think we can all agree however that FirewallD is trash.
I'm not really bothered about whether init was perfect from the beginning - for as long as I've been using Linux (20 years) until now, I have never known the init system to be the cause of major issues. Since in my experience it's not been seriously broken for two decades, why throw it out now for something that is orders of magnitude more complex and ridiculously overreaching?
Like many here I bet, I am barely tolerating SystemD on some servers because RHEL/CentOS 7 is the dominant business distro with a decent support life - but this is also the first time I can recall ever having serious unpredictable issues with startup and shutdown on Linux servers.
The essential concept behind SystemD (modelling the system as a dependency graph) works for me, but unfortunately the implementation is rather lacking in reliability. I've developed the same level of nervousness about rebooting that I used to have for Windows a decade or two ago. Init relied on you to get things right, and had nothing more than basic linear prioritisation. Much more basic - and much less maintenance hassle.
"Sometimes people just like to stick with whats comfortable to them..."
Others like to stick with something that works.
"...and have everyone else bend to their hissy fits."
Why would you think that? I couldn't care less about what others use on their own systems.
"Sometimes you have to bend."
Choosing a reliable init system isn't one of those times.
I've been using Linux ( RedHat, CentOS, Ubuntu), BSD (Solaris, SunOS, freeBSD) and Unix ( aix, sysv all of the way back to AT&T 3B2 servers) in farms of up to 400 servers since 1988 and I never, ever had issues with eth1 becoming eth0 after a reboot. I also never needed to run ifconfig before configuring an interface just to determine what the inteface was going to be named on a server at this time. Then they hired Poettering... now, if you replace a failed nic, 9 times out of 10, the interface is going to have a randomly different name.
Quite understandable that people who don't know anything else would accept systemd. For everyone else it has nothing to do with old school but everything to do with unpredictability of systemd.
Today I've kickstarted RHEL7 on a rack of 40 identical servers using same script. On about 25 out of 40 postinstall script added to rc.local failed to run with some obscure error about script being terminated because something unintelligible did not like it. It never ever happened on RHEL6, it happens all the time on RHEL7. And that's exactly the reason I absolutely hate it both RHEL7 and systemd.
Ah yes, another systemd (RHEL?) annoyance in that by default the actual rc.local script is not set to be executable and that rc-local.service is disabled. It's almost as if someone doesn't want you to be using it.
Also in systemd, rc.local is no longer the last script/thing to be run. So in order to fudge something to work in rc.local I had to create an override module for rc-local.service that has a dependancy on the network being up before it runs.
> So in order to fudge something to work in rc.local I had to create an override module for rc-local.service that has a dependancy on the network being up before it runs.
oh, no, the system is discouraging me from doing something I shouldn't be doing! (you called it a "fudge" yourself)
let me guess, you also patch openssh so that it doesn't check if the key files are world readable?
if only all the people put half the effort of writing the tirades about Pottering and SystemD into writing their SysV init replacement we would have a working alternative, but that would require actual effort, now wouldn't it
"oh, no, the system is discouraging me from doing something I shouldn't be doing! (you called it a "fudge" yourself)"
No, systemd is starting at a random times, often even before network is working, something that used to be running as the very last script after all other services started.
If you don't see why this is an issue you first name must be Lennart.
"if only all the people put half the effort of writing the tirades about Pottering and SystemD into writing their SysV init replacement we would have a working alternative"
Why would I feel the need to write a replacement for something which has been working for me without major problems for two decades?
If I did want to stop using sysvinit there are already several working alternatives apart from systemd, but it seems that pretending otherwise is quite a popular activity.
> Why would I feel the need to write a replacement for something which has been working for me without major problems for two decades?
funny you say that, because for other people old sysV init wasn't working and systemD is a welcome replacement as it does work, and does work exactly as advertised
yes, including starting services only after the network is available
(use "After=syslog.target network.target")
> there are already several working alternatives apart from systemd
and yet for some reason Debian, SLES, Fedora, Archlinux, CoreOS and Mageia use it by default, it's almost as if people that had to deal with SysV issues knew about those issues and wanted them gone
but conspiracy theories are much more exciting
This post has been deleted by its author
the people with the problem with it are more of the Torvalds type, old school who want to use Unix-like systems
I have no problem with Red Hat wanting their semi-proprietary system. Unfortunately, in order to preserve their data centre presence they had to eliminate competition from non-systemd distros by ensuring it got into the likes of Debian.
I haven't been working with Linux for many years, 4+ ...
I am long past the need to push my chest out and if you must know, my name is Chuck and I these are my thoughts on systemd. 8^P!
I come from many years of MS, back from DOS 5.0 on my 200LX and early IBM office desktops.
Not a coder/programmer or even what you could call an advanced user, just a home and office guy who needs a PC to do things.
I attempted many times to make the jump to Linux and finally made it. It took some effort but not more than what I remember it took me to start with MS DOS in '94 and I was already in my late 20's.
Like I have said before: This systemd issue in Linux brings back memories of my difficult transition from W3.11 to W95, with the end of the familiar *.ini files I understood (and could tweak when things went foul) to the dark and undocumented workings of *the registry*, which took me a few years to get a minimal hold of.
In my opinion, this the same thing but it is now infecting Linux_land.
I see this systemd thing as nothing more than a registry class virus; the moment I understood what it was all about I left Ubuntu and Mint and now use and try out only systemd free distributions, hoping to eventually run only Devuan on my two rigs and netbook.
"I've found that the people with the problem with it are more of the Torvalds type, old school"
Top trolling. What do the people who actually wrote Linux know anyway?
"I can embrace changes a lot more easily."
I've got a friend who believes in conspiracy theories and spiritualism - he is also proud of how much established wisdom he can throw out and replace with stuff that's really convenient, but doesn't actually hold together under pressure.
I'll only be happy with systemd when two things happen: First, the whole thing is dragged behind the bins and shot, and second, Poettering is nailed upside down to a tree by the larger of his testicles and then really hurt - obviously he felt the need to one-up the unholy clusterfuck that was pulseaudio and boy, he succeeded.
I'm one of those weapons-grade curmudgeons that (tries to) adhere to the UNIX philosophy of 'do one thing and do it well', rather than the current trend of 'do multiple things barely adequately and pray to $DEITY that it works'
Couldn't agree more. This arrogant jerk has a history of screwing things up and walking away that others may benefit from being reminded of.
It doesn't matter if it eventually works if I have to waste a big portion of my life - the one thing no one can replace - working around your crap.
I can see some (well, one) benefit of systemd in the depandancies. So things may only start when a pre-requisite has been met.
Unfortunately that is outwighed by the annoyances. For me the worst is stuffing everything in a binary log and not telling you any error message when you restart the service. So you have to go hunting for an error message and in some cases just end up running manually what the service was meant to do just to see what it's complaining about. It's time I'd rather spend fixing the problem itself.
Like other commenters I tolerate systemd as it's part of RHEL/CentOS/Oracle Linux etc 7.x and that's what we have to use. Obviously that's no endoresement.
But when I look at the Debian page that debates systemd it's clear that there are parallels between my attitude to TypeScript/ECMA 6 and reg commenters attitude to systemd. I know I can do what I need with the tool as it was and I don't need this new fangled "type safety". You lot know how to use scripts to boot a device and don't need systemd.
Technology moves on, often in directions that we don't all approve of. Nevertheless you have to keep up or become irrelevant, so I've started learning TypeScript and ECMA6. How you react is up to you.
"Technology moves on, often in directions that we don't all approve of. Nevertheless you have to keep up"
Let's extend the direction metaphor. You're driving along when you realise the road you're on leads in the wrong direction, possibly in the direction of a dangerous flood. Do you keep up or do you take a turn in a better direction?
In your situation there may be no alternative. In the Unixy world there are: several BSD Unices and systemd-free Linux distros.
> TypeScript/ECMA 6 and systemd
M$ is cancer, don't support them. Avoid their software. Don't use their spyware called VSCode nor TypeScript, it will slurp your source code with tricks like always-on phone-home and spellchecker sending home everything among other nasty things.
This post has been deleted by its author
"Why would Lennart's laptop need to handle 15 vlans?"
And this (or a version of it) is the root cause of most of the screwed-up improvements*. "I don't do XYZ. I don't understand XYZ. So I'm leaving it out of the new system."
*Wayland, I'm looking at you.
Yes. Exactly that. I am, at least, pleased to know that it's not just me being crap, but a genuine issue others have met too and ended up using rc.local (once I've noticed it is not executable ffs) to restart those network servers. Only around 10 VLANs here, and yet a "sleep 4" or even more is needed before restarting them.
I could rant, but I won't.
Intrigued by another post suggesting it is all part of an evil M$ plan. I'm not a conspiracy theorist, so I'm choosing not to go down that rabbit hole, makes you wonder though...
How long can this go on?
This post has been deleted by its author
It renamed network interfaces so they would have predictable names.
Hmmmm nice idea, but that's not how it works in practice and I'm not sure this is a core systemd feature. The new naming conventions in RHEL7 don't work in all cases. It has 5 different naming schemes or which it only uses 4 by default.
Firstly it tries to find out whether a network device is an "onboard" one, and looks in 2 different places to make this decision.
Secondly it looks to see whether the NIC is in a named PCI slot, well again there are 2 different places it seems to look, one of which doesn't appear to be readable from the files under /sys, at least not with any of the NIC drivers I've ever tried. Great if you can read it from SMBIOS, not otherwise.
Failing those it then looks to see if the driver is a PCI one and then uses the PCI address, well these aren't natively persistent nor are they consistent. Persistence can be requested from the firmware configuration, but it often isn't enabled by default.
Failing all that it just uses the kernels non persistent & non consistent naming without the benefit of udev rules to provide persistence. Given the asynchronous driver initialization in the Linux 3 & 4 kernels this is particularly bad as if you've got 2 different sorts of NICs then it's anyone's guess which one with get to be eth0 before systemd starts to play it's games.
Now if you run this lot inside a VM then virtio drivers for KVM don't provide the identifiers used by schemes 1 & 2 and they're not PCI to scheme 3 is out too. Scheme 4 is never used by default so we drop through to the kernel names. If you also have emulated NICs in you VM and you've got random naming for your network cards.
The situation with VMWare is just as bad, if not worse. It doesn't provide persistent or even sensible onboard device numbers or you end up with name for you NICS like eno167654321 (something over 2^24). So they put a kludge in the systemd code to spot the ridiculous onboard device numbers and then drop through to scheme 2, but the version of SMBIOS emulated does allow the slot numbers to be pulled from the type 9 records and the field that is used can't be read from /sys and doesn't seem to be consistent, so I can't find a way to know in advance what a NIC will be called so how the *&^% am I supposed to write kickstart files for these things?
And all of this has nothing to do with the job of PID 1, which is the orphan catcher, without which the kernel will die.
I can't remember if it's HPE or Dell (or both) where you can use set the kernel option biosdevname=0 during build/boot to turn all that renaming stuff off and revert to ethX.
However on (RHEL?)/CentOS 7 I've found that if you build a server like that, and then try to renam/swap the interfaces it will refuse point blank to allow you to swap the interfaces round so that something else can be eth0. In the end we just gave up and renamed everything lanX instead which it was quite happy with.
"I can't remember if it's HPE or Dell (or both) where you can use set the kernel option biosdevname=0 during build/boot to turn all that renaming stuff off and revert to ethX."
I'm using this on my Debian 9 systems. IIRC the option to do so will be removed in Debian 10.
From now on, I will call Systemd-based Linux distros "SNU Linux". Because Systemd's Not Unix-like.
It's not clever, but it's the future. From now on, all major distributions will be called SNU Linux. You can still freely choose to use a non-SNU linux distro, but if you want to use any of the "normal" ones, you will have to call it "SNU" whether you like it or not. It's for your own good. You'll thank me later.
It's not clever, but it's the future. From now on, all major distributions will be called SNU Linux. You can still freely choose to use a non-SNU linux distro, but if you want to use any of the "normal" ones, you will have to call it "SNU" whether you like it or not. It's for your own good. You'll thank me later.
And if you have a pair of machines go belly-up at the same time because of SystemD, is that Death by Snu-Snu ?
“So is this the GNU SNU Linux then?”No. That's precisely the point; it's “SNU”, not “GNU”.
GNU means “GNU’s Not Unix”, but that's only in name — it's not called Unix, but it's Unix-like. (So in practice it pretty much is Unix after all.)
SNU, for “SNU’s Not Unix-like” (or was it “Systemd’s Not Unix-like”?), is, well, not Unix-like, so not GNU.
The SNU acronym is in stead of the GNU one, not in addition to it.
It is fascinating to me how the Unix(like) IT community can agree that "things need fixing" yet sit on their hands until someone leaps in, at which point they all know better.
Massive confirmation bias larded on thick there, but my observation stands.
Coming to Korn Shell almost three decades ago after many years working in a very stable mainframe environment I was appalled that every other man page listed "known bugs" with essential utilities (like grep) which had been there for twenty years and more, with no sign anyone was even slightly interested in fixing them.
So I guess my point is: If you think systemd is a load of dingoes kidneys and care passionately about that, why on earth aren't you organizing and specifying-out an alternative that does all the things needed that don't work right with init, yet avoids all the nasty with systemd?
You can complain the systemd design is poor and the implementation bad all you want, but if there is no better alternative - and for the world at large it seems that init isn't hacking it and, as someone so astutely mentioned, Solaris has now a questionable future so *its* "fix" isn't gong to become a systemd rival any time soon - that is what will be taking the carpet from under your feet.
Welcome to my world. When I started a power user was someone who could read paper tape without feeding it through a Westrex. I've lost count of the paradigm changes and Other People's Bad Choices I Have To Live With I've weathered over the years.
Now absent thyselves from my greensward soonest, varlets!
"You can complain the systemd design is poor and the implementation bad all you want, but if there is no better alternative..."
There are several better alternatives. That isn't the problem. The problem is that most of the major Linux distros bent over and took what Red Hat was giving them.
Doesn't seem like that's the case from the linked articles and discussions. It seems like there are alternatives, but that they each have their own set of issues and problems, especially when talking about the utopian goal of a user-friendly Linux-based desktop O/S.
What it seems like to me is that those who "bent over and took what Red Hat was giving them" must have had solid reasons for doing so. People who take pride in their work don't usually take an unpopular step unless there's a net benefit.
Nice rant. Kinda.
However, I don't recall any major agreement that init needed fixing. Between BSD and SysV inits, probably 99.999% of all use cases were covered. In the 1 in 100,000 use case, a little bit of C (stand alone code, or patching init itself) covered the special case. In the case of Slackware's SysV/BSD amalgam, I suspect it was more like one in ten million.
So in all reality, systemd is an answer to a problem that nobody had. There was no reason for it in the first place. There still isn't a reason for it ... especially not in the 999,999 places out of 1,000,000 where it is being used. Throw in the fact that it's sticking its tentacles into places where nobody in their right mind would expect an init as a dependency (disk partitioning software? WTF??), can you understand why us "old guard" might question the sanity of people singing it's praises?
 My spall chucker insists that the word should be "testicles". Tempting ...
Then why did Red Hat commit their resources, time and effort to developing and releasing systemd into the world at large? Are you telling me they decided to change it up for the sake of it?
Comments in this very thread show that init is not up to the job of firing up computers that *aren't* single-purpose servers. Given the preponderance of counter opinions, I'm not putting a lot of faith in your "didn't need fixing" theory.
I don't disagree with the points you are making at systemd's expense regarding new and exciting bugs, merely saying that if people needed the functionality not easily worked (or possible) with trad system V start-up - and they clearly did - that sitting around waiting for someone else to come up with the goods has resulted in that happening.
And considering that every desktop distro I've looked at now comes with a daily FDA requirement of systemd, it would appear as though those building the distros don't agree with you either.
But that said, I understood that with a little work most distros could be rejiggered to run trad systemv init startup and never deal with systemd. Of course, all those upstream apps that assume you didn't do that may be a head- and heart-ache to maintain.
Swings and roundabouts, but if one seriously expects Linux-based desktops to displace the hated Microsoft Windows, saying that the startup can be got to work with some script changes and a little bit of C code is a non-starter. The alternative works out of the box, y'see.
"Then why did Red Hat commit their resources, time and effort to developing and releasing systemd into the world at large?"
Marketing making engineering decisions would be my guess.
"Are you telling me they decided to change it up for the sake of it?"
"Comments in this very thread show that init is not up to the job of firing up computers that *aren't* single-purpose servers."
Those are exceptions to the rule. In the 35 years since SysV init was released, I think I can count on on both hands the number of times I've had to actually code something that it couldn't handle. And those cases were extreme edge cases (SLAC, Sandia, NASA, USGS, etc.). And note that in none of those cases would systemd have been any help. In a couple of those cases, BSD worked where SysV didn't.
"And considering that every desktop distro I've looked at now comes with a daily FDA requirement of systemd, it would appear as though those building the distros don't agree with you either."
Do they actually not agree with me? Or is it more that they are blindly following Redhat's lead, simply because it's easier to base their distro on somebody else's work than it is to rollout their own?
"saying that the startup can be got to work with some script changes and a little bit of C code is a non-starter. "
Correct. For the vast majority of folks. But then, for the vast majority of folks a box-stock Slackware installation will work quite nicely. They are never going to even know that init exists, much less if it's SysV, BSD or systemd. They don't care, either. Nor should they. All they want to do is B0rk faces, twatter about, and etc. The very concept of PID1 is foreign to people like that. So why make this vast sweeping change THAT DOESN'T HELP THE VAST MAJORITY OF PEOPLE WHO HAVE IT INFLICTED UPON THEM? Especially when it adds complexity and makes the system less secure and less stable?
> Do they actually not agree with me? Or is it more that they are blindly following Redhat's lead, simply because it's easier to base their distro on somebody else's work than it is to rollout their own?
I'm not stupid, other people are stupid!
cool argument bro, very mature, bro /s
"I'm not stupid, other people are stupid!
cool argument bro, very mature, bro /s"
One thing I find disappointing in this discussion is the tendency of some participants (on both sides, but mainly from some of the seemingly less experienced systemd advocates) to resort to emotional and defensive behaviour when presented with a rational argument against what they believe. Other people have different requirements. Don't take it so personally.
Red Hat have definitely taken a lurch to the dark side in recent years. It seems to be the way businesses go.
They start off providing a service to customers.
As they grow the customers become users.
Once they reach a certain point the users become consumers, and at this point it is the 'consumers' that provide a service for the business.
SystemD is just a symptom of this regression.
(20 of which on Debian, before that was Slackware)
I am new to systemd, maybe 3 or 4 months now tops on Ubuntu, and a tiny bit on Debian before that.
I was confident I was going to hate systemd before I used it just based on the comments I had read over the years, I postponed using it as long as I could. Took just a few minutes of using it to confirm my thoughts. Now to be clear, if I didn't have to mess with the systemd to do stuff then I really wouldn't care since I don't interact with it (which is the case on my laptop at least though laptop doesn't have systemd anyway). I manage about 1,000 systems running Ubuntu for work, so I have to mess with systemd, and init etc there.
If systemd would just do ONE thing I think it would remove all of the pain that it has inflicted on me over the past several months and I could learn to accept it.
That one thing is, if there is an init script, RUN IT. Not run it like systemd does now. But turn off ALL intelligence systemd has when it finds that script and run it. Don't put it on any special timers, don't try to detect if it is running already, or stopped already or whatever, fire the script up in blocking mode and wait till it exits.
My first experience with systemd was on one of my home servers, I re-installed Debian on it last year, rebuilt the hardware etc and with it came systemd. I believe there is a way to turn systemd off but I haven't tried that yet. The first experience was with bind. I have a slightly custom init script (from previous debian) that I have been using for many years. I copied it to the new system and tried to start bind. Nothing. I looked in the logs and it seems that it was trying to interface with rndc(internal bind thing) for some reason, and because rndc was not working(I never used it so I never bothered to configure it) systemd wouldn't launch bind. So I fixed rndc and systemd would now launch bind, only to stop it within 1 second of launching. My first workaround was just to launch bind by hand at the CLI (no init script), left it running for a few months. Had a discussion with a co-worker who likes systemd and he explained that making a custom unit file and using the type=forking option may fix it.. That did fix the issue.
Next issue came up when dealing with MySQL clusters. I had to initialize the cluster with the "service mysql bootstrap-pxc" command (using the start command on the first cluster member is a bad thing). Run that with systemd, and systemd runs it fine. But go to STOP the service, and systemd thinks the service is not running so doesn't even TRY to stop the service(the service is running). My workaround for my automation for mysql clusters at this point is to just use mysqladmin to shut the mysql instances down. Maybe newer mysql versions have better systemd support though a co-worker who is our DBA and has used mysql for many years says even the new Maria DB builds don't work well with systemd. I am working with Mysql 5.6 which is of course much much older.
Next issue came up with running init scripts that have the same words in them, in the case of most recently I upgraded systems to systemd that run OSSEC. OSSEC has two init scripts for us on the server side (ossec and ossec-auth). Systemd refuses to run ossec-auth because it thinks there is a conflict with the ossec service. I had the same problem with multiple varnish instances running on the same system (varnish instances were named varnish-XXX and varnish-YYY). In the varnish case using custom unit files I got systemd to the point where it would start the service but it still refuses to "enable" the service because of the name conflict (I even changed the name but then systemd was looking at the name of the binary being called in the unit file and said there is a conflict there).
fucking a. Systemd shut up, just run the damn script. It's not hard.
Later a co-worker explained the "systemd way" for handling something like multiple varnish instances on the system but I'm not doing that, in the meantime I just let chef start the services when it runs after the system boots(which means they start maybe 1 or 2 mins after bootup).
Another thing bit us with systemd recently as well again going back to bind. Someone on the team upgraded our DNS systems to systemd and the startup parameters for bind were not preserved because systemd ignores the /etc/default/bind file. As a result we had tons of DNS failures when bind was trying to reach out to IPv6 name servers(ugh), when there is no IPv6 connectivity in the network (the solution is to start bind with a -4 option).
I believe I have also caught systemd trying to mess with file systems(iscsi mount points). I have lots of automation around moving data volumes on the SAN between servers and attaching them via software iSCSI directly to the VMs themselves(before vsphere 4.0 I attached them via fibre channel to the hypervisor but a feature in 4.0 broke that for me). I noticed on at least one occasion when I removed the file systems from a system that SOMETHING (I assume systemd) mounted them again, and it was very confusing to see file systems mounted again for block devices that DID NOT EXIST on the server at the time. I worked around THAT one I believe with the "noauto" option in fstab again. I had to put a lot of extra logic in my automation scripts to work around systemd stuff.
I'm sure I've only scratched the surface of systemd pain. I'm sure it provides good value to some people, I hear it's good with containers (I have been running LXC containers for years now, I see nothing with systemd that changes that experience so far).
But if systemd would just do this one thing and go into dumb mode with init scripts I would be quite happy.
Now more seriously: it really strikes me that complaints about systemd come from people managing non-trivial setups like the one you describe. While it might have been a PITA to get this done with the old init mechanism, you could make it work reliably.
If systemd is a solution to any set of problems, I'd love to have those problems back!
... if systemd would just do this one thing and go into dumb mode with init scripts ...
But, has it occurred to you that what you are wishing for is something that whoever (pronoun taken in the broadest sense) is behind this across the table à la blitzkrieg implementation of systemd will never do?
And that they have their own agenda/reasons for not doing it?
Interesting times ...
I was confident I was going to hate systemd before I used it just based on the comments I had read over the years, I postponed using it as long as I could. Took just a few minutes of using it to confirm my thoughts.
It takes longer than that to really hate systemd.
Wait until you have to fix a broken Ubuntu system in "rescue" mode, and find that two minutes after you get your login prompt, systemd decides to kick in some additional task and 50% of the keystrokes go to that other process.
I just want a working shell, dammit!
It's time to install Debian without systemd, called Devuan: https://dev1galaxy.org/viewtopic.php?id=2047
Don't use a Linux with systemd! Stay with Ubuntu 14 LTS or Ubuntu 16 LTS, or the new Devuan ASCII (Debian).
And stop supporting Ubuntu 18 LTS, Debian and RedHat. They are sleeping with the evil cancerous corp. MSFT is paying RedHat and Ubuntu to EEE Linux with systemd
Yes. I've been using Debian on all of my machines, servers and workstations, for a very, very long now. When Debian adopted SystemD, I tried running with it. I gave it a very good shot, going with it for over a year, and I understand it pretty well now.
But it's terrible, and I've recently decided that it's not something that I can tolerate. That means, given that it's polluted Debian, that I need to change distros. I've decided to go back to where I started: Slackware.
All admins serious about the Unix way of working seem to be moving towards Devuan or Slackware; Devuan is probably the most 'enterprise-ready' and the Devuan team is working to get enterprise support established in the longer term as well.
Like Redhat, but done properly.
Unfortunately it's not really an option for businesses that need safety of support contract, either from Red Hat or Oracle and majority of environments which actually pay sysadmins money do run either RHEL or OL.
So there's no alternative once RHEL6/OL6 are EOL.
There might be an opportunity for Oracle (the only real vendor that has developers and resources required) to create systemd-less variant of OL7 and put the nail in the coffin of RHEL7 while gaining lots of new customers and significantly grow OL install base, but they don't seem interested doing it.
Oracle are out of the running for anything at most organisations due to their licencing chicanery and past record on pretty well everything.
We went with Redhat mostly for QAd & regulated releases and updates. Support never amounted to much (unless you're a blue chip company). The training system was quite useful a few years back for hiring, you at least needed a semblance of a clue for RHCE.
It's a pretty polarizing debate: either you see Systemd as a modern, clean, and coherent management toolkit
Very, very few Linux users see it that way.
or an unnecessary burden running roughshod over the engineering maxim: if it ain't broke, don't fix it.
Seen as such by 90% of Linux users because it demonstrably is.
Truthfully Systemd is flawed at a deeply fundamental level. While there are a very few things it can do that init couldn't - the killing off processes owned by a service mentioned as an example in this article is handled just fine by a well written init script - the tradeoffs just aren't worth it. For example: fscking BINARY LOGS. Even if all of Systemd's numerous other problems were fixed that one would keep it forever on my list of things to avoid if at all possible, and the fact that the Systemd team thought it a good idea to make the logs binary shows some very troubling flaws in their thinking at a very fundamental level.
WRT grep and logs I'm the same way which is why I hate json so much. My saying has been along the lines of "if it's not friends with grep/sed then it's not friends with me". I have whipped some some whacky sed stuff to generate a tiny bit of json to read into chef for provisioning systems though.
XML is similar though I like XML a lot more at least the closing tags are a lot easier to follow then trying to count the nested braces in json.
I haven't had the displeasure much of dealing with the systemd binary logs yet myself.
> I haven't had the displeasure much of dealing with the systemd binary logs yet myself.
"I have no clue what I'm talking about or what's a robust solution but dear god, that won't stop me!" – why is it that all the people complaining about journald sound like that?
systemd works just fine with regular syslog-ng, without journald (that's the thing that has binary logs) in sight
"systemd works just fine with regular syslog-ng, without journald (that's the thing that has binary logs) in sight"
Journald can't be switched off, only redirected to /dev/null. It still generates binary log data (which has caused me at least one system hang due to the absurd amount of data it was generating on a system that was otherwise functioning correctly) and consumes system resources. That isn't my idea of "works just fine".
""I have no clue what I'm talking about or what's a robust solution but dear god, that won't stop me!" – why is it that all the people complaining about journald sound like that?"
Nice straw man. Most of the complaints I've seen have been from experienced people who do know what they're talking about.
"I have no clue what I'm talking about or what's a robust solution but dear god, that won't stop me!" – why is it that all the people complaining about journald sound like that?
I have had the displeasure of dealing with journald and it is every bit as bad as everyone says and worse.
systemd works just fine with regular syslog-ng, without journald (that's the thing that has binary logs) in sight
Yeah, I've tried that. It caused problems. It wasn't a viable option.
So it's now been 4 years since they first tried to force that shoddy desk-top init system into our servers? And yet they still feel compelled to tell everyone, look it really isn't that terrible. That should tell you something. Unless you are tone death like redhat. Surprised people didn't start walking out when Poettering outlined his plans for the next round of systemD power grabs...
Anyway the only way this farce will end is with shareholder activism. Some hedge fund to buy 10-15 percent of redhat (about the amount you need to make life difficult for management) and force them to sack that "stable genius" Poettering. So market cap is 30bn today. Anyone with 5bn spare to park for a few months wanna step forward and do some good?
Early on I warned that he was trying to solve a very large problem space. He insisted he could do it with his 10 or so "correct" ways of doing things, which quickly became 20, then 30, then 50, then 90, etc.. etc. I asked for some of the features we had in init, he said "no valid use case". Then, much later (years?), he implements it (no use case provided btw).
Interesting fellow. Very bitter. And not a good listener. But you don't need to listen when you're always right.
Now, you see, you just summed up the whole problem. Like systemd's author, you think you know better than the admin how to run his machine, without knowing, or caring to ask, what he's trying to achieve. Nobody ever runs a computer, to achieve running systemd do they.
I don't claim I know better, but I do know that I never saw a non-distribution provided init script that handled correctly the basic of corner cases – service already running, run file left-over but process dead, service restart – let alone the more obscure ones, like application double forking when it shouldn't (even when that was the failure mode of the application the script was provided with). So maybe, just maybe, you haven't experienced everything there is to experience, so your opinion is subjective?
Yes, the sides of the discussion should talk more, but this applies to both sides. "La, la, la, sysv is working fine on my machine, thankyouverymuch" is not what you can call "participating in discussion". So is quoting well known and long discussed (and disproven) points. (and then downvoting people into oblivion for daring to point this things out).
now in the real world, people that have to deal with init systems on daily basis, as distribution maintainers, by large, have chosen to switch their distributions to systemd, so the whole situation I can sum up one way:
"the dogs may bark, but the caravan moves on"
I do know that I never saw a non-distribution provided init script that handled correctly the basic of corner cases – service already running
This only shows that you don't have much real life experience managing lots of hosts.
like application double forking when it shouldn't
If this is a problem in the init script, this should be fixed in the init script. If this is a problem in the application itself, it should be fixed in the application, not worked around by the init mechanism. If you're suggesting the latter, you should not be touching any production box.
"La, la, la, sysv is working fine on my machine, thankyouverymuch" is not what you can call "participating in discussion".
Shoving down systemd down people's throat as a solution to a non-existing problem, is not a discussion either; it is the very definition of 'my way or the highway' thinking.
now in the real world, people that have to deal with init systems on daily basis
Indeed and having a bunch of sub-par developers, focused on the 'year of the Linux desktop' to decide what the best way is for admins to manage their enterprise environment is not helping.
"the dogs may bark, but the caravan moves on"
Indeed. It's your way or the highway; I thought you were just complaining about the people complaining about systemd not wanting to have a discussion, while all the while it's systemd proponents ignoring and dismissing very valid complaints.
"I never saw ... run file left-over but process dead, service restart ..."
Seriously? I wrote one last week! You use an OS atomic lock on the pidfile and exec the service if the lock succeeded. The lock dies with the process. It's a very small shellscript.
I shot a systemd controlled service. Systemd put it into error state and wouldn't restart it unless I used the right runes. That is functionally identical to the thing you just complained about.
"application double forking when it shouldn't"
I'm going to have to guess what that means, and then point you at DJB's daemontools. You leave a FD open in the child. They can fork all they like. You'll still track when the last dies as the FD will cause an event on final close.
"So maybe, just maybe, you haven't experienced everything there is to experience"
You realise that's the conspiracy theorist argument "You don't know everything, therefore I am right". Doubt is never proof of anything.
"La, la, la, sysv is working fine" is not what you can call "participating in discussion".
Well, no.. it's called evidence. Evidence that things are already working fine, thanks. Evidence that the need for discussion has not been displayed. Would you like a discussion about the Earth being flat? Why not? Are you refusing to engage in a constructive discussion? How obstructive!
"now in the real world..."
In the *real* world people run Windows and Android, so you may want to rethink the "we outnumber you, so we must be right" angle.
You're claiming an awful lot of highground you don't seem to actually know your way around, while trying to wield arguments you don't want to face yourself...
"(and then downvoting people into oblivion for daring to point this things out)"
It's not some denialist conspiracy to suppress your "daring" Truth - you genuinely deserve those downvotes.
I have no idea how or why systemd ended up on servers. Laptops I can see the appeal for "this is the year of the linux desktop" - for when you want your rebooted machine to just be there as fast as possible (or fail mysteriously as fast as possible). Servers, on the other hand, which take in the order of 10+ minutes to get through POST, initialising whatever LOM, disk controllers, and whatever exotica hardware you may also have connected, I don't see a benefit in Linux starting (or failing to start) a wee bit more quickly. You're only going to reboot those beasts when absolutely necessary. And it should boot the same as it booted last time. PID1 should be as simple as possible.
I only use CentOS these days for FreeIPA but now I'm questioning my life decisions even here. That Debian adopted systemd too is a real shame. It's actually put me off the whole game. Time spent learning systemd is time that could have been spent doing something useful that won't end up randomly breaking with a "will not fix" response.
Systemd should be taken out back and put out of our misery.
The technical details of SystemD are over my head but I do use Mint as the main OS on this laptop which makes me Mr. Innocent Bystander in this argument. I had heard of SystemD and even a rumour that Mint was going to use it. That Mint ALREADY is using SystemD is news to me
( provided by this article ).
My problem is that a month ago a boot of Mint failed and after reading this thread I must wonder whether SystemD is at least one of the usual suspects as the cause of the problem ?
Here's what happened :
As I do every couple of weeks, I installed the latest available updates from Mint but the next time I booted up it did not get beyond the Mint logo. All I got were terminal-level messages about sudo commands and the ability to enter them. Or rather NOT enter them. Further use of Terminal showed that one system file did not now exist. This was in etc/ and related to the granting of sudo permissions. The fact that it did not exist created a vicious circle and sudo was completely out of action. I took the laptop to a shop where they managed to save my Backups folder that had been on the desktop and install a fresh version of Mint.
So what are the chances that this was a SystemD problem ?
From what you say the file /etc/sudoers got deleted (or corrupted). It may have been some (badly effed up) update.
Btw. you could have booted from a rescue image (CD or USB stick) and fixed it yourself. Easy when you have a proper backup, not-quite-so-easy when you have to 'manually' recreate that file.
So even those who are paranoid ( rightly or wrongly ) about SystemD did not pile in to blame it here. I'll take that as a 'no'.
Backup you say ? Tell me about it. I must admit that when it comes to backups I very much talk the talk, full stop.I have since bought a 1TB detachable hard drive which at least makes full backups fast via USB3.
( All I need now is software for DIFFERENTIAL backups ).
Living long enough to have ton of experience is not paranoia (although it can help!). Instead, try the other "P" word ... pragmatism.
Backups are a vital part of properly running any computerized system. However, I can make a case for simply having multiple copies (off site is good!) of all your important personal files being all that's needed for the average single-user, at home system. The OS can be reinstalled, your pictures and personal correspondence (etc.) cannot.
Probably not systemd. If you were the only one it happened to, and it only happened once, write it off as the proverbial "stray cosmic ray" flipping a bit at an inopportune time during the install. If you can repeat it, this is the wrong forum to address the issue. Try instead https://forums.linuxmint.com/
That said, if anybody reading this in the future has a similar problem, you can get a working system back by logging in as root, using your favorite text editor to create the file /etc/sudoers with the single line root ALL=(ALL) ALL, saving the file and then running chown 644 /etc/sudoers ... logout of root and back into your user account and get on with it. May I suggest starting with backing up all your personal work (pictures, tunes, correspondence, whathaveyou)?
 Yeah, yeah, yeah, I know, don't suggest newbies use root. But if su doesn't work, what would you suggest as an alternative?
 visudo wont work for obvious reasons ... even if it did, would you suggest vi to a newbie? Besides, on a single-user system it's hardly necessary for this kind of brute-force bodge.
Opinion Broadcom has yet to close the deal on taking over VMware, but the industry is already awash with speculation and analysis as to how the event could impact the cloud giant's product availability and pricing.
If Broadcom's track record and stated strategy tell us anything, we could soon see VMware refocus its efforts on its top 600 customers and raise prices, and leave thousands more searching for an alternative.
The jury is still out as to whether Broadcom will repeat the past or take a different approach. But, when it comes to VMware's ESXi hypervisor, customer concern is valid. There aren't many vendor options that can take on VMware in this arena, Forrester analyst Naveen Chhabra, tells The Register.
Comment Recently, The Register's Liam Proven wrote tongue in cheek about the most annoying desktop Linux distros. He inspired me to do another take.
Proven pointed out that Distrowatch currently lists 270 – count 'em – Linux distros. Of course, no one can look at all of those. But, having covered the Linux desktop since the big interface debate was between Bash and zsh rather than GNOME vs KDE, and being the editor-in-chief of a now-departed publication called Linux Desktop, I think I've used more of them than anyone else who also has a life beyond the PC. In short, I love the Linux desktop.
At The Linux Foundation's Open Source Summit in Austin, Texas on Tuesday, Linus Torvalds said he expects support for Rust code in the Linux kernel to be merged soon, possibly with the next release, 5.20.
At least since last December, when a patch added support for Rust as a second language for kernel code, the Linux community has been anticipating this transition, in the hope it leads to greater stability and security.
In a conversation with Dirk Hohndel, chief open source officer at Cardano, Torvalds said the patches to integrate Rust have not yet been merged because there's far more caution among Linux kernel maintainers than there was 30 years ago.
Interview In June, Purism began shipping a privacy-focused smartphone called Librem 5 USA that runs on a version of Linux called PureOS rather than Android or iOS. As the name suggests, it's made in America – all the electronics are assembled in its Carlsbad, California facility, using as many US-fabricated parts as possible.
While past privacy-focused phones, such as Silent Circle's Android-based Blackphone failed to win much market share, the political situation is different now than it was seven years ago.
Supply-chain provenance has become more important in recent years, thanks to concerns about the national security implications of foreign-made tech gear. The Librem 5 USA comes at a cost, starting at $1,999, though there are now US government agencies willing to pay that price for homegrown hardware they can trust – and evidently tech enthusiasts, too.
Microsoft is flagging up a security hole in its Service Fabric technology when using containerized Linux workloads, and urged customers to upgrade their clusters to the most recent release.
The flaw is tracked as CVE-2022-30137, an elevation-of-privilege vulnerability in Microsoft's Service Fabric. An attacker would need read/write access to the cluster as well as the ability to execute code within a Linux container granted access to the Service Fabric runtime in order to wreak havoc.
Through a compromised container, for instance, a miscreant could gain control of the resource's host Service Fabric node and potentially the entire cluster.
EndeavourOS is a rolling-release Linux distro based on Arch Linux. Although the project is relatively new, having started in 2019, it's the successor to an earlier Arch-based distro called Antergos, so it's not quite as immature as its youth might imply. It's a little more vanilla than Antergos was – for instance, it uses the Calamares cross-distro installer.
EndeavourOS hews more closely to its parent distro than, for example, Manjaro, which we looked at very recently. Unlike Manjaro, it doesn't have its own staging repositories or releases. It installs packages directly from the upstream Arch repositories, using the standard Arch package manager
pacman. It also bundles yay to easily fetch packages from the Arch User Repository, AUR. The
yay command takes the same switches as
pacman does, so if you wanted to install, say, Google Chrome, it's as simple as
yay -s google-chrome and a few seconds later, it's done.
Microsoft has made it official. Windows Subsystem for Linux 2 distributions are now supported on Windows Server 2022.
The technology emerged in preview form last month and represented somewhat of an about-face from the Windows giant, whose employees had previously complained that while the tech was handy for desktop users, sticking it on a server might mean it gets used for things for which it wasn't intended.
(And Windows Server absolutely had to have the bloated user interface of its desktop stablemate as well, right?)
Good news for especially determined fans of Ubuntu's formerly in-house desktop: there's a new version.
Old-school editor fans, rejoice: some two and a half years after version 8.2, Vim 9 is here, and with a much faster scripting language.
The existing scripting language, Vimscript, remains and will still work. Only scripts beginning with the line
vim9script will be handled differently. The syntax changes are relatively modest; the important differences are in things like local versus global variables and functions, and that functions defined with
:def will be compiled before they are run. This allows many errors to be caught in advance, but more significantly, compiled functions execute from 10× to 1000× faster.
Version 21.3 of Manjaro - codenamed "Ruah" - is here, with kernel 5.15, but don't let its beginner-friendly billing fool you: you will need a clue with this one.
Manjaro Linux is one of the more popular Arch Linux derivatives, and the new version 21.3 is the latest update to version 21, released in 2021. There are three official variants, with GNOME 42.2, KDE 5.24.5 or Xfce 4.16 desktops, plus community builds with Budgie, Cinnamon, MATE, a choice of tiling window managers (i3 or Sway), plus a Docker image.
The Reg took its latest look at Arch Linux a few months ago. Arch is one of the older rolling-release distros, and it's also famously rather minimal. The installation process isn't trivial: it's driven from the command line, and the user does a lot of the hard work, manually partitioning disks and so on.
Biting the hand that feeds IT © 1998–2022