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.
"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.
Biting the hand that feeds IT © 1998–2020