I mean I’ve briefly tried some of the modern distros that go without systems recently, and honestly they just felt like I went back in time except they weren’t even the same as then so I had no idea what I was doing without reading documentation that is imo much worse than the arch wiki.
And as a bonus fuck man pages as I can’t in a pleasant way put them into my 1000s of categorized browser tabs for research and topic switching while being able to return without starting over.
OpenRC seems quite straightforward
Not compared to systemd
It is! People have been burnt by others and have now settled for mediocrity. Nothing wrong with that, I suppose; nothing right, either.
honestly though
Still people raging over something that reliably and securely powers millions of Linux installs.
Not really involved with Linux for the past 15 years so don’t know the ins and outs of the systemd saga butyour debunking is not as convincing as you make it sound. I do run a system at home that when all goes well I don’t need to login to or do troubleshootingfor months. (Ie. Movies and shows download fine, homeassistant works). I stumbled upon systemd a while ago when I had to google how to fucking find and look at some logs on my Ubuntu system. Wtf have been a sysadmin professionally for years until a decade ago. Never seen something changing like that, but I digress as for your points.
Being able to query logs like a database sounds appealing dont take me wrong. But If I am interested I will install splunk, graylog or whatever kids use these days, I don’t need a core component to make a major structural change (logging on Unix is expected to be in plain text, most tools on a Unix systems do some sort of manipulation of log files, and i expect to use cat, grep and tail to work on my logs). The fact that I can opt out is a minor consolation. Also if I want my logs not to be tampered with, I’ll look into how to do that with dedicated tools and technology. On most systems that’s not a concern, why would you even consider that something appealing?
As for sysvinit scripts pain, I hear you buy a) I am pretty sure most script I have written/modified were tens of lines of code, not hundreds, hardly an impossible task to deal with. And b) that’s not something your average user needs to do every day (or decade). Most likely a sysvinit script would be implemented once in the lifetime of a particular project by the developer themselves, or by a package maintainer. If the solution to such a big problem is to have millions of lines of compiled code (that’s news to me, I’ll trust you on that number) it makes me wonder even more.
Are you sure all the counterarguments are really just bizarre nostalgia and easily debunked? I haven’t even read much about it and even when people like you try to sell how good systemd is, it looks to me like the solution we didn’t ask for a problem we didn’t have.
As somebody who started my *nix journey on Unix System V, the OS that sysvinit came from, I think the grandparents comment is spot on.
Also, upstart could have been good, but it’s actually pretty great to see the majority of the ecosystem adopt a single new solution. We wouldn’t want the init landscape to be like the X vs Wayland and WM landscape.
Concerning logs:
- You can still log to text if you want by configuration (e.g. forward stuff to syslog) and you can use any tools you like to read those files you want. So if you like text logs you can get them. You can even invoke journalctl to output logs on an ad hoc / scheduled basis in a variety of text formats and delimited fields.
- Binary allows structured logging (i.e. each log message is comprised of fields in a record), indexing and searching options that makes searches & queries faster. Just like in a database. e.g. if you want to search by date range, or a particular user then it’s easy and fast.
- Binary also allows the log to be signed & immutable to prevent tampering, allow auditing, intrusion detection etc… e.g. if someone broke into a system they could not delete records without it being obvious.
- You can also use splunk with systemd.
So people object to systemd writing binary logs and yet they can get text, or throw it into splunk or do whatever they like. The purpose of the binary is make security, auditing and forensics better than it is for text.
As for scripts, the point I’m making is systemd didn’t supplant sysvinit, it supplanted upstart. Upstart recognized that writing massive scripts to start/stop/restart a process was stupid and chose an event driven model for running stuff in a more declarative way. Basically upstart used a job system that was triggered by an event, e.g. the runlevel changes, so execute a job that might be to kick off a process. Systemd chose a dependency based model for starting stuff. It seems like dists preferred the latter and moved over to it. Solaris has smf which serves a similar purpose as systemd.
So systemd is declarative - you describe a unit in a .service file - the process to start, the user id to run it with, what other units it depends on etc. and allow the system to figure out how to launch it and take care of other issues. It means stuff happens in the right order and in parallel if it can be. It’s fairly simple to write a unit file as opposed to a script. But if you needed to invoke a script you could do that too - write a unit file that invokes the script. You could even take a pre-existing init script and write a .service file that kicks it off.
I feel like the people who complain about systemd have never tried to mess with sysVinit scripts before
6+ years ago, I was trying to configure a touchscreen HAT for a raspberry pi, and dicking with the init.rc script was a massive pain
The alternatives to systemd isn’t init.d or some other legacy init systems. I use runit, pretty easy to understand and use. Stop being lazy dude
Or dinit. dinit is awesome. s6 defeated me; an init system shouldn’t be that complex.
systemd has a lot of nice features, esp. in the area of dependencies and triggers. But it infects everything it touches, is enormous, and is buggy.
Frankly, I’m waiting for the PipeWire successor to systemd. Like systemd, Pulseaudio was everywhere by the time enough people realized how bad it really was and someone wrote a well-designed, well-written replacement. ALSA has problems that Pulseaudio fixed, but with a badly written solution; then a good software developer came up with a good solution that solves the same problems but isn’t just a giant hacky hot mess and now PA is slowly being replaced everywhere. Given that the same person, of questionable skill, who wrote PA also wrote systemd, I fully expect a better-designed solution to replace systemd.
S6 isn’t it. dinit is close, but has some holes that need addressing before it could succeed systemd, and I think it won’t be it; I think systemd’s successor hasn’t been written yet, but I have confidence it will be.
+1 to runit. So much simpler than systemd unit files.
Yep. Having services stateful is a thing that SysV init doesn’t offer. Look at the massive whatever that process management is that postfix had to build to get around that. No, systemd any time over custom stuff like that.
anyone ever seen a goldwing? it was supposed to be a motorcycle but for some reason has a fridge, microwave and what not added.
it is still a motorcycle. you can ride it. it starts right away and has all sorts of extra functions.
and now look at it. it is an ugly piece of engineering that only the weirdest of people like.
dont ride a goldwing. dont use systemd.
No clue about motorcycles but those things look neat and win awards. I want one now. Thanks for turning me on to this neat bike.
yeah sure. enjoy that and some systemd. everyone likes different things.
What are you talking about? The goldwing has been consistently hailed as one of the best touring motorcycle for almost 40 years. Every long distance rider I’ve spoken to says the goldwing is their favorite bike for cross country rides, and the ones who have sold theirs for a BMW or Harley touring bike have expressed regrets about changing.
Just because something has a lot of features, doesn’t mean it’s bad.
where i live ppl laugh about goldwing riders. it is considered the idiots bike: https://avida.cs.wright.edu/personal/wischgol/fsr/Guenther/Goldwing.html
…just one example.
google suggest in my country autocompletes goldwing with “mikrowelle” (microwave).
maybe we just have a different taste.
That was a pretty funny read!
I’m guessing this could be a common use case difference? Maybe touring in smaller stints makes the goldwing seem like way too much overkill, but if I were to do a bike trip across the US, I’d much prefer riding on a goldwing vs a smaller and more “functional” bike. Several thousand miles can be a real killer without all those comfy bells and whistles.
I am fine with systemd. It works. It is more complicated than init.d
Before you copied some random file you edited and put it in init.d and it worked. Now you copy some systemd services file into systemd and run enable and start and it doesn’t work because you don’t know what you are doing.
I didn’t know what I was doing in init.d too but now I have to learn systemd services. Once you know a bit it will work then (probably)
I disagree. Before I had to copy and edit a huge-ass script (100+ lines) in init.d where 80% of it was concerned with PID files. I just want to start a process on boot, why is it so hard?
Now I can look at the documentation and write a simple unit file myself. It’s like 4 lines.
The systemd init units should be setup when you install a package.
init.d wasn’t really what you’d call an “init” “system.” It was shell + conventions about how to write shell scripts to manage each service. It effectively offloaded most of the work people wanted an init system/service supervisor to do onto developers that just needed to ship a system service. Templates/patterns/best practices emerged, but at the end of the day, init.d was just shell, and it caused tons of problems.
The extra complexity of systemd is in exchange for dependency management, service supervision, tons of things that are important/desirable for sysadmins/developers today, but are all far outside the scope of init. I’d much rather cope with the extra complexity of systemd in exchange for being able to write an actual service definition file.
Before you copied some random file you edited and put it in init.d and it worked.
Before you copied some random file you edited and put it in init.d and it appeared to be working but then failed in random ways the first time you restarted, the first time you rebooted, the first time you restarted it via sudo instead of directly as root since some environment variable differed,…
So really it only appeared to be working in my experience because you had no real way to check.
I mean it should be obviously clear that copying random files isn’t sth. You should do anyways
Well, in this context what we are talking about is some random init script from some other service because nobody wants to write all that crap from scratch every time.
Poettering works for MS now? That’s the best news I’ve heard in a long time.
Embrace, Extend, Extinguish.
You are at the second step.
This sounds a bit ridiculous. If Linus started working at MS I wonder if people would suddenly think Linux was a MS project and start hating on it.
Hopefully Microsoft will never make a guide on how to install Firefox because then we’d have to have a panic about that too
people keep saying this, but what is their extinguish plan? how could they realistically extinguish linux? it’s not a company they can buy, or even a single thing they can ruin.
If you know the history of Linux, plenty of people almost did. Microsoft has especially tried. Usually through software patents, FUD, and suing the shit out of everybody. If everyone had to rip SystemD out of their systems tomorrow, would it kill Linux? Nah, probably not. But it would be enough to keep those with large pockets from ever picking it over Microsoft’s offerings.
They’ve effectively kept Linux out of their domain for a very long time now.
That is my point, they have tried and failed completely before when their main product was windows licenses. Now, linux is incredibly important to their azure business, they wouldn’t want to potentially cause detriment to that and is far more important to them than windows licenses.
Also why would we have to rip out systemd, even if they tried to claim ownership of it and make it proprietary, it could be forked from before the license change and we would keep on going like nothing happened.
I guess you don’t remember when Google forked java in Android and still got railed in the courts by Oracle, who simply bought SUN Microsystems in order to gain the rights to do so. It’s not as simple as “oh we’ll just fork it!” when it comes to patents, intellectual property, etc.
What are you even talking about? systemd is currently under an opensource license, they cant retroactively change that. Any changes would be for it going forward if it is even possible for them to buy the rights to it (which I’m not convinced it is as Lennart Poettering is not the sole contributor and Red Hat / IBM and many others also have a significant stake in it). Sun patented Java on it upon its creation and when oracle bought sun, they bought the rights to those patents. They aren’t comparable situations. Java was never open source, it was source available, but still proprietary.
SystemD was just an example my guy, it could be anything.
What else besides running services can system.d do?
bootload, manage devices, manage the network interface, manage accounts, log in, provide a host for temp files, schedule stuff, log events
All of this is background stuff to me so I don’t care
(n.b.: systemd also suffers from a linux kernel vs linux situation. systemd has a component named systemd that only does services stuff)
I believe you mean GNU/SystemD/Linux…
You forgot manage containers, manage system timers, manage network interfaces (in some cases)…
DNS resolution, clock synchronization, there’s something about keyboard configuration but it stopped to make me problems for no reason so I don’t know what exactly…
Oh, and IPC so that Gnome can not be done until other inits won’t run!
But there are a lot of other modules.
manage system timers, manage network interfaces
I said “manage the network interface” and “schedule stuff”
manage containers
That requires podman or some other program, so that’s like saying shell does container management
That requires podman or some other program.
No,
systemd-nspawndoesn’t need any other container management program, it’s its own thing.You’re right about the first two, but as someone pointed out already, wrong about the last.
Also see
machinectl
I can’t believe how much time has passed since the controversy. If I remember correctly the problem is that systemd eats babies
TL;DR init system, services, sockets, slices, logs, boots, VM’s, containers… and that’s fantastic, for monolithic systems.
journalctlgo brrrrStrap in, folks. Old timer with a gavel to slam.
When systemd is unfolded in full, people are sort of apt when they jokingly say “-Linux, or what I’d like to call gnu/systemd/Linux”. Some scream at the top of their lungs, yearning back to rc.0 days, “when everything was much simpler”… this is where the gavel comes down. There are so many improvements they are hard to list and if you asked me if I could go back, only with modern software, I would say nay… and here’s why:
Running services is a whole mess more than just running background apps, and it’s intrinsically intertwined with what is known as the init system - no matter what some people may think. Init is the process of initializing (or bootstrapping) an operating system, and services are background services, but both are about managing the processes within the Linux stack - or the thread. Some say that systemd is doing more than it should, but systemd is not “crossing streams” when both init processes and services need to be managed in concert depending upon the way a system inits - because there’s more than one way to init.
systemd manages init through scopes, slices and services, which combined create the hierarchy of processes used to bootstrap a system, get things up and running, with their relative permissions, in a given state, to facilitate a running and functioning system. Socket units handle socket files or destinations, and timer units handle event driven processes.
It all comes together into a dependency chain that defines your running system, which is testable and manageable from a set of tools.
systemctlis used to manage a running system, and I think it does a great job of it. Imagine fail testing a bunch of non-standardised, random rc bash script files that aren’t distro agnostic, along with whatever daemon runner you were using. It was a mess, and systemd sought to fix that - which imho it has. We view a booted Linux system and it’s process tree much differently through the systemd lens, which gives us a newfound focus that helps us better manage a running system.Also, logs are binary now… you’re all so spoiled and you don’t even know it. Do you remember 20GB txt files you absolutely had to open? Pepperidge farm remembers. Which brings us
journalctl, which is just so good. It’s the swizz army knife of Linux logs. You can point it at anything. Specify-kfor dmesg, a service using--unit, point to a binary in/usr/bin, select previous boot with-b -1,-ffor follow,-etake me to the end of a log. If you haven’t learned how to use this tool, you are running blind. It whips every dang logging system out there. Going from systemd to windows events feels like going from a soft mattress to the inside of an iron maiden.systemd-bootis blazing fast. Don’t get me wrong, Grub2 is still fantastic as well (Apple seems to think so at least), but considering ease of us - as I often do - I’m inclined to prefersystemd-bootbecause ofbootctl, because likejournalctl, it’s a wonderful piece of kit for managing, analyzing and failtesting boot images, provides UEFI functionality and being a sort of one-stop shop for the boot process.Now we we’re seeing systemd managing VM’s (
machinectl) and containers (containerctl), and honestly I’m all for it. Make my life easier. Please. Standardise that mess. And since it is standard, everyone supplies systemd units and because of the nature of systemd and it’s designs, it’s all fail-safed to hell and back. This is good. We want this. At least on the desktop, workstation, even some servers. For containers, embedded, not so much, as they aren’t monolithic systems. That being said, NixOS has proven that systemd isn’t a barrier to entry for new system paradigms either, so I feel those fears were unfounded.You get the theme here. Systemd is a system management suite, and not just a service runner or init system. It seems to grow and grow out of proportion, but at the end of the day, it’s about getting the system(s) and software up and running, as well as managing those processes and figuring out where problems lie. That’s what systemd does. It’s become part and parcel of a fully monolithic Linux stack, and in my opinion it’s a great project that makes our lives much easier.
To me systemd is zen. It’s the cup of tea Linux always needed, and I’m not ashamed to say so.
@taanegl @DmMacniel omg i was so prepared to hear a anti-lennart-pottering rant about sysv init scripts
thanks for what instead turned out to be a very thoughtful and educational text which i will now send to all these sysv pplHaving to occasionally go back to OpenRC or Upstart systems is jarring. Systemd just does so much and does it so much better. Poettering seems like a bit of a chode but he genuinely made an incredible project. I also think that when people say systemd isn’t Unix-like, they forget that systemd isn’t monolithic and it’s possible to use some components of it but not others. The core is all based on a standardized way to start and manage processes and services, be it for boot or usage.
Damn. Thanks for the writeup.
Old timer built Linux… Old timers built open source. Don’t disrespect.
…yes, I know. I’m one of them. Used to compile my OS and everything.
Systemd is still better than init/daemons, categorically.
Many, many things.
The best feature I like is that it can keep track of dependencies and status. It is a “smart” control system for your computer
Who the fuck spells developed with two ‘p’s???
A madman
…who uses systemd
(He’s insane)
It’s a mistake indeed. And there’s a very logical explanation as to why I made that mistake. The reason’s simple, really. Obvious even. So much so that I won’t bother explaining.
Hi am noob why systemd bad? I use Debian, is fucked?
Honestly I’ve been hearing about this for a while now but never bothered to check, I’m too lazy for that.
No one knows to this day
I highly recommend you check out this video
SystemD is not really bad. Like 90% distros use it, and for good reasons. Some people just pointlessly hate it on it, same way some people like to hate on Wayland too.
Here is an alternative Piped link(s):
I highly recommend you check out this video
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
I believe partly because it takes over so many responsibilities that it becomes a requirement for things that don’t need to require it. Plus it diverged from the Linux principle of do only one thing.
Also, afair, it was buggy for a while.
FYI: It’s called Unix principle, not Linux
Oh yeah, thank you
No problemo
There is a fork of Debian without SystemD. https://www.devuan.org/
It’s not inherently bad, it “fails” the Unix Philosophy of “Do one thing and do it well” but since Linux’s kernel is:
- Unix-like, not Unix
- Fails this philosophy, as it does more than one thing but does all of it pretty well
- systemd is just a bundle of tools that do one thing and do it well under one package, like Linux’s kernel
It used to be a mess, but that’s solved. The biggest reason to avoid systemd is mainly user preference, not anything malicious. 90% of current distros use systemd as its easier for the maintainers and package programmers to build for the general than each package and each distro having their own methods of how to do an init system and other tasks.
How Debian and Arch and Gentoo and Slackware and other big distros worked was different, and the maintainers of those packages had to know “Debian’s way” and not a general way that most places accept. Systemd actually solved the Too Many Standards! issue.
I’ve never really seen a big argument against systemd, but maybe I’ve just not heard it.
It used to be a mess, but that’s solved.
Do you mean the past tense of the verb solve or the systemd service that solves mathematical equations? Because solveds code is still a mess. It used to too, but it still is.
🤓
It also didn’t help that Poettering isn’t particularly popular on a personal level. I think there would have been a lot less drama if he had better people skills.
Yeah, but to be honest, I would have terrible “people skills” too if people sent me death threats over writing a free software.
Doesn’t take much to get death threats on the Internet, unfortunately. He probably would have received less of them with a better attitude, though. He wasn’t full-on Ulrich Drepper, but still pretty divisive.
Yeah he seems kind of like a weirdo jerk.
back when you had an init system and you got it just the way you wanted it, you would be pissed that you had to move to systemd
now its there when you install and it is stable so it isn’t a big deal. But old beards hate change.
Old beards built linux and everything around, have some respect.
ITT: self-taught fanboys who don’t know how to spell “developed”.
Obligatory The Tragedy of Systemd
Here is an alternative Piped link(s):
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
I’d like to propose a new rule for this community:
People criticizing systemd to the extent where they promote alternatives (regressions), have to provide proof that they have or are maintaining init scripts for at least ten services with satisfying the following conditions: said init scripts must 1.) be shown to reliably start up the services and 2.) not signal their dependencies to early and 3.) gracefully stop the services 99.9% of the time. People failing to satisfy these conditions are not allowed to voice their opinions on how arbitrary init systems are better than systemd. Violations of this rule will be punished by temporary bans and forcing the violators to fill the entire canvas of a blackboard with “‘do one thing and do it well’ is a unix principle, not a linux principle” in fine print.
More lines of semi-reliable init scripts have been written by package maintainers, than lines of systemd code by Poettering & Co, and that while achieving far less. The old init systems might have been simple, the hell of init scripts wasn’t.
That might have been true a decade ago. I don’t actually know. I do know that modern init scripts for modern alternatives to systemd are barely longer than systemd service scripts though. So that’s kind of an insane take.
OK luddite.
Luddites were champions of the working class and have been smeared by capitalist for over a century. I’d be proud to be called a Luddite.
(In before history nerds um, actually me: chill…I know)
OK commie.
Aww sweetie. You’re cute.
I am. A lot of people fail to see that.
can you give examples of some? Not trying to bd sarcastic, i do just want to see what alternatives are doing.
Sure, that seems pretty reasonable. Here’s the init script for sddm:
#!/usr/bin/openrc-run supervisor=supervise-daemon command="/usr/bin/sddm" depend() { need localmount after bootmisc consolefont modules netmount after ypbind autofs openvpn gpm lircmd after quota keymaps before alsasound want logind use xfs provide xdm display-manager }That’s it. That’s the whole thing.
That’s a pretty simple one though, so here’s Alsa. It’s a more complex one:
code
#!/usr/bin/openrc-run # Copyright 1999-2019 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 alsastatedir=/var/lib/alsa alsascrdir=/etc/alsa.d alsahomedir=/run/alsasound extra_commands="save restore" depend() { need localmount after bootmisc modules isapnp coldplug hotplug } restore() { ebegin "Restoring Mixer Levels" checkpath -q -d -m 0700 -o root:root ${alsahomedir} || return 1 if [ ! -r "${alsastatedir}/asound.state" ] ; then ewarn "No mixer config in ${alsastatedir}/asound.state, you have to unmute your card!" eend 0 return 0 fi local cards="$(sed -n -e 's/^ *\([[:digit:]]*\) .*/\1/p' /proc/asound/cards)" local CARDNUM for cardnum in ${cards}; do [ -e /dev/snd/controlC${cardnum} ] || sleep 2 [ -e /dev/snd/controlC${cardnum} ] || sleep 2 [ -e /dev/snd/controlC${cardnum} ] || sleep 2 [ -e /dev/snd/controlC${cardnum} ] || sleep 2 alsactl -E HOME="${alsahomedir}" -I -f "${alsastatedir}/asound.state" restore ${cardnum} \ || ewarn "Errors while restoring defaults, ignoring" done for ossfile in "${alsastatedir}"/oss/card*_pcm* ; do [ -e "${ossfile}" ] || continue # We use cat because I'm not sure if cp works properly on /proc local procfile=${ossfile##${alsastatedir}/oss} procfile="$(echo "${procfile}" | sed -e 's,_,/,g')" if [ -e /proc/asound/"${procfile}"/oss ] ; then cat "${ossfile}" > /proc/asound/"${procfile}"/oss fi done eend 0 } save() { ebegin "Storing ALSA Mixer Levels" checkpath -q -d -m 0700 -o root:root ${alsahomedir} || return 1 mkdir -p "${alsastatedir}" if ! alsactl -E HOME="${alsahomedir}" -f "${alsastatedir}/asound.state" store; then eerror "Error saving levels." eend 1 return 1 fi for ossfile in /proc/asound/card*/pcm*/oss; do [ -e "${ossfile}" ] || continue local device=${ossfile##/proc/asound/} ; device=${device%%/oss} device="$(echo "${device}" | sed -e 's,/,_,g')" mkdir -p "${alsastatedir}/oss/" cp "${ossfile}" "${alsastatedir}/oss/${device}" done eend 0 } start() { if [ "${RESTORE_ON_START}" = "yes" ]; then restore fi return 0 } stop() { if [ "${SAVE_ON_STOP}" = "yes" ]; then save fi return 0 }That’s definitely longer than a systemd service, but you’d have to write an awful lot of them to be more code than all of systemd. Overall the entire /etc/init.d folder on my PC where all the init scripts even for the stuff I’m not using are stored is a grand total of 147.7 KiB. Not exactly an unmanageable amount of code, in my humble opinion.
Its certainly easier to read than most old init scripts and I can see why some distros and openbsd would pick it over systemd for more control. I’m not likely to pick a distro that uses it anytime soon, but i can see why some do.
That’s totally fair. I’m not some weird evangelist or anything. I just like options and think OpenRC is kinda neat. There’s nothing wrong with systemd, and honestly it’s more work using other options. Not for the actual init system, but for some of the other stuff systemd does. I’ve had to learn cron, and that has been… interesting. It feels like all of the documentation around cron just assumes you already know how cron works. I’m still not sure if I’m doing it right, but I’ve had a good time and my computer works, and really that’s good enough for me.
Almost looks like something taken from ASL linux.
To me systemd is fine, I am not really emotional at init systems. But on the other hand Linux is about choice and systemd kills that in some way because it does so much more than just starting services. GNOME is unusable without systemd, which makes it a no choice if you go into another rabbit hole. It’s kinda weird how deeply systemd is integrated in Linux these days. What I really dislike is that the log is in binary format by default which makes it necessary to deal with another tool to read logs. But well software changes, so do tools. But honestly the devs acted like dick heads sometimes, so I think most of the antipathy comes from their behavior and well yes MS now kinda pushing systemd because poettering works for them. I have fear that MS forces the systemd devs to implement things you cannot simply opt out of because it is so tightly integrated. Maybe copilot for writing systemd unit files would be nice though :P
well yes MS now kinda pushing systemd because poettering works for them. I have fear that MS forces the systemd devs to implement things you cannot simply opt out of because it is so tightly integrated.
How has MS pushed systemd?
That’s a nonsense spin of things. There wasn’t/isn’t a need for Microsoft to push systemd, because it had been adopted by all major linux distributions before Poettering even made the switch. It’s a straw that init system luddites clutch at.
GNOME is unusable without systemd
It is also unusable with systemd.
This comment was presented by the KDE gang.
I have fear that MS forces the systemd devs to implement things you cannot simply opt out of because it is so tightly integrated.
What the hell? Code isn’t unpatchable, and neither is Microsoft the super evil villain trying to ruin the lives of Linux users that childishly.
Systemd is very customizable and flexible. I also fine it is faster than anything else. You can also choose what systemd services to use and what not to use
I’ve been a Unix admin for almost 30 years.
Systemd really is shitty, and Poettering is a serious asshole; but that ship has sailed. It’s time to accept that computers only get worse, and move on.
I’m sad that you have to throw out all the init scripts you’ve written in 30 years.
Maybe stick with Slackware? I’m pretty sure you’ll fit in well there.Aw gee, thanks!
I never said init scripts (and more importantly, the init process) were the right answer. It doesn’t change the fact that systemd has some bad fundamental design and implementation decisions; and that any attempt to address them was met by Poettering saying essentially “this is the way I designed it, and therefore it’s right. You’re wrong.” He has no regards for standards, compatibility, or consistency.
It wasn’t even the first replacement for process management out there. Sun had SMF which was effective but flawed; and systemd duplicated almost every one of its flaws.
In other words, saying that init had to be replaced didn’t necessarily mean systemd; but that’s the world we have now.
I think the community has moved on without you then.
You missed the point where I said “…and move on.”
The fact that I dislike it doesn’t change the fact that it’s prevalent, and so I use systemd every day.
It’s the same with any technology I need. Ansible is a mostly awful language, but I need it to do my job, so I buckle down and use it. Git is…well actually git is pretty awesome.
A decade (or two?) ago, perl was the language of choice for complex admin tasks, despite being a nightmare to maintain. Now we have mostly moved to python and ruby, which are generally much better.
My point is that just because a standard (process, tool, etc.) is flawed, we don’t refuse to use it; and conversely, just because we use a tool doesn’t make it immune to valid criticism.
@swordgeek @possiblylinux127 this from a guy who still uses swords
