301–310 of 449 posts
Earlier quoted context omitted.
You're right. Bad generalization. Sentence removed, but archived in your comment. Out of curiosity, what distros do you use that you've had such a good run with init scripts?
I currently use Debian on everything except my R-PIs, where I use Raspbian.
Earlier quoted context omitted.
But...it doesn't include "everything else". My desktop doesn't use systemd-timesyncd, I'm not even sure systemd-nspawn is installed on my home server, that same server isn't using systemd-resolved. I haven't fiddled with journald anywhere 'cause I like it a lot more than rsyslogd, but you totally can forward journald stuff to rsyslogd if that's more your bag (and I think, though don't quote me on that, you can remove…
You can't replace journald. See the 10 times this has been referenced throughout the thread.
[Journald]
Storage=None
ForwardToSyslog=True
Earlier quoted context omitted.
Why on earth do systemd haters insist on capitalizing the D? It's really amazing how people think mistyping the name is some kind of useful or novel criticism of the software.
However juvenile, it is useful – as soon someone writes “SystemD”, I know that they’re either very inexperienced and don’t really know much, or they’re deliberately being spiteful and want to signal their hatred to other haters. Either way, I then know that I can safely ignore them completely, since they’re not part of a constructive conversation.
* https://lists.debian.org/debian-devel/2016/08/msg00547.html
Earlier quoted context omitted.
Systemd is a bunch of loosely coupled tools, though; it's not a monolith at all. PulseAudio was written by Lennart but isn't part of systemd. You don't have to use systemd's resolver. systemd-nspawn is a completely separate process and isn't required for systemd as a whole. It's worth watching Benno Rice (a BSD developer, actually) discuss systemd and some of the misconceptions, some of which you're expressing, there…
There are lots of variations on the UNIX philosophy [1], but two core points are to: 1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". 2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't…
Also, how do you define doing "one thing" exactly? I can see it for `ls` or `cat`, but for anything more complicated than that...not so sure. Is Vi following the UNIX philosophy? If you say; yes, it's 'just an editor', despite 'an editor' being composed of several components, then I can say that systemd is just 'a service manager'. It's a semantics game that does not make sense in today's world.
The Unix philosophy has its uses for sure, but it's far from an universal truth in today's world.
I get that not everybody likes systemd, but a lot of the criticisms seem misguided and looking at sysvinit with role-colored glasses. For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. Yes, there's parts to systemd that not everyone will use, like container support, but in that case you can pretty safely ignore that use case. For me, systemd has p…
I don’t think anyone thinks that sysvinit is better than systemd, but RC definitely is.
What was the problem with sysvinit that they tried to fix? I don't see any.
Earlier quoted context omitted.
I'm not a huge fan, but dbus at least runs on FreeBSD and others.
FreeBSD developers are actually looking at something like systemd themselves. The fact that systemd itself doesn't run on it is just the consequence of POSIX being inadequate for its implementation, since it relies on a bunch of Linux specific features, like cgroups etc. I am personally in the camp that doesn't mind that, Linux users should get the best possible software given their system capabilities, not the lowes…
If this claim were true it still is beside the point of my comment, that systemd itself has a "Linux only, and we don't care" approach, and dbus for the moment is not that.
> GNOME itself does exist on the BSDs
Yes the ports tree is a wonderful place for those things to sit for those who are interested and for a larger portion to not bother installing them. I don't know how many patches they applied to get it working or what the cost and effect of those patches may be over time.
Earlier quoted context omitted.
There are lots of variations on the UNIX philosophy [1], but two core points are to: 1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". 2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't…
Regarding the UNIX philosophy thing, it's worth noting that it is not automatically The Right Thing to stick by it at any cost. You could argue that UNIX itself does not use the philosophy when it's inconvenient, for example many UNIX-(like) kernels were/are monolithic, despite micro kernels with message passing akin to GNU Hurd embody the UNIX philosophy much better than the original UNIX kernel did(!) Also, how do…
Sure. The UNIX Philosophy applies more to userland, I think, than the kernel.
Edit: I'll add with regard to the kernel, the internal structure of the kernel still has fairly well-defined subsystems that interact in clear, mostly consistent ways. So while from an execution standpoint it is monolithic, the philosophy is still something that is taken to heart to some extent.
> Also, how do you define doing "one thing" exactly? I can see it for `ls` or `cat`, but for anything more complicated than that...not so sure. Is Vi following the UNIX philosophy? If you say; yes, it's 'just an editor', despite 'an editor' being composed of several components, then I can say that systemd is just 'a service manager'. It's a semantics game that does not make sense in today's world.
I think dismissing it as a semantics game is taking it pretty far. It's clearly not a black and white rule, but more a guiding philosophy. When it works, it's beautiful and elegant.
The ability to pipe basic UNIX utilities and programs together is something that has always left me a little awestruck. The flexibility and simplicity there is almost profound. SysVinit was far from perfect, but you could at least trace the execution flow from basically start to finish and, if you understood basic *NIX utilities, have a good idea of exactly what was happening.
> The Unix philosophy has its uses for sure, but it's far from an universal truth in today's world.
Again, it's a philosophy, not a universal truth. A guiding light, if you will.
With systemd, that light is pretty dim, if it's on at all.
Earlier quoted context omitted.
Full disclosure: I'm a systemd skeptic. The problem is basically that Linux used to be about choice (choose your distro! choose your DE! choose your shell! choose your browser!) but now that it's become big business, large corporations like Red Hat (developer of systemd) have transformed the evolution of Linux from a bottom-up consensus system to a top-down "we develop all the stuff you use and now it all uses our st…
I am not a systemd skeptic, but I'm also not somebody who cares that much. (Which might seem at odds with this thread, but I'm in a lot of meetings today. ;) I use it and it gets out of my way. For me, it's fine. I'm not qualified to judge the quality of the code in systemd directly; I've browsed it a little but I am a middling C++ programmer and while it hasn't stood out to me as smelly I would defer to more knowled…
I do, it's "if you run a big mainstream distro like Fedora or Debian, let your users swap out init systems". I know there have been debates on this, and I know the general consensus is "it's not worth the trouble / it's not as simple as just swapping out something like systemd". My counter arguments are: there are distros that are doing it, so it doesn't seem like it's that bad after all, and when dealing with something as important as PID 1 (or your libc, or your filesystem) we should be conservative and let users swap things back when making a huge change.
This anti-systemd meme is getting tiring. I generally find it is perpetuated by people who use Linux at a hobby level. Rarely do I speak with guys in Ops who dislike systemd. I am not trying to discredit people here, there are hobby users who are more knowledgeable about Linux related systems than many guys who are professionals. My point is that Linux and systemd are both meant for use on servers, in production, whe…
I have the feeling systemd is meant exactly for what you call hobby or novice users. I actually enjoy some of it on my laptop to be honest ;-)
But in the datacenter it has caused me hours and hours of 'fixing problems that did not exist before systemd came along'.
Most of it's 'improvements' target the desktop user. Many of it's 'improvements' actually get in the way in the server room.
I mean, why would I want to optimize my boot time on a server with all this parallel startup crap? The server spends 10 times more time in BIOS and POST then it takes to boot the OS. It has always been like this. And it still is like this.
From a config management point of view I like systemd. I gives me a consistent API to enable/disable start/stop services. That's awesome. I also like that I can 'override/patch' upstream units without having to maintain a fork. Perfect.
But many other things that came from the systemd ecosystem are questionable. E.g. systemd-resolved, timesyncd and that kind of stuff. Maybe these are nice for desktop users who want a click and play experience on their laptop. No problem with that. But why do they have to break my server's for this?
I mean seriously: Linux on the desktop is irrelevant. Why optimize the whole OS/init for a irrelevant use case?