10 ms·

I continue to be baffled by people objecting to systemd. I know some people just don't like it and that's fine, people make alternative distros without it. You'

I continue to be baffled by people objecting to systemd. I know some people just don't like it and that's fine, people make alternative distros without it. You're not alone. But I just have to ask, even if it sounds condescending (I'm sorry- but I really am just honestly baffled-) has anyone who complains about systemd actually written a unit file vs an init script? I have used init scripts, I have written init scripts. I hated it. Every program needed it's own little way of doing things and writing an init script for a daemon was a hassle of bash scripting and copy pasting. Now you can get so much functionality out of literally just an ExecStart with a few lines of boilerplate. It's beautiful. And all your logs are in journald, which for me get scraped by a single promtail config into Loki. And systemd's structured logging means I get a lot of metadata available by default for filtering and tagging. It's just swell. And it's free software!

ed25519FUUU 3y ago
I also never understood the disdain for it. I feel like 15 minutes of reading about systemd keywords and I was on my way to making some very usable and reliable systemd scripts. I don’t use sysv init anymore but I don’t feel like I ever fully understood those scripts.
- foobarian 3y ago
  I get the disdain. Beyond just reacting to change, systemv is fully scripted and thus a lot more accessible - one can read the source and understand what is happening fully once the kernel is done. On the other hand with systemd I feel we get this opaque magical complexity encroaching into previously fully grokkable user space and that is very hard to take, regardless of actual pros and cons.
mackal 3y ago
I think it all comes back to people being upset about the Ubuntu PulseAudio switch. Ubuntu did a bad job when they switched to PulseAudio and caused lots of issues. Lennart Poettering was lead dev for both projects and it's weird how much the anti-systemd crowd get their panties in a bunch over him and also PA.
- ilyt 3y ago
  He fucked uo a lot in PA He also fucked up some in systemd, journalctl being biggest example. He also fucked up some in kernel, to the point Linus yelled at him The critique is entirely deserved
  - throw0101a 3y ago
    > He also fucked up some in systemd, journalctl being biggest example. "Let's just invent our own non-ACID file format instead using what's already available." (Like perhaps SQLite.) Howard Chu of OpenLDAP had a rant on this: * https://www.linkedin.com/pulse/20140924071300-170035-why-you-cannot-trust-lennart-poettering-systemd/ https://www.linkedin.com/pulse/20140924071300-170035-why-you... Does journald support off-host log shipping yet? Because for all its supposed replacing of syslog, as a sysadmin I still have to run (r)syslogd to send things to a central log host via RFC 3164/5424 anyway.
    - ilyt 3y ago
      I'm pretty sure it's just him wanting to toy with databases and picking systemd to be his victim. I'd expect when he finds new toy to keep himself busy someone else will fix it to actually work properly for the most time like it happened with PulseAudio
xraystyle 3y ago
I don't get it either. Systemd units are so much more powerful and flexible than init scripts. Writing those bash scripts for everything was a complete pain in the ass. You may disagree with the architecture or design decisions made with systemd, but I don't see how it's possible to argue that SysVinit was in any way actually "better".
- rektide 3y ago
  They're neither more powerful nor more flexible. Init-scripts can iterate & build whatever complexity they want. They can be far wilder. There's almost nothing constraining what an init script could be. Systemd does establish easy-to-use & incredibly-powerful access a wide range of super-powerful knobs. And in a consistent & clear way, where-as each init-script would have a totally different way of doing config & slightly different approaches to the various hacks. And init scripts arent composable, where-as you can take your distro's regular unit, and drop-in some additional configuration easily, in a very eloquent way, across any bit of config. I think systemd is amazing & brings enormous clarity. It has enormous power. But init-scripts still had more power. But it was reckless chaotic power that was enormously hard to tap, and required prodigal talent to develop these individual artisinal artefacts, which became, as a user, a thing of horror to rework. Init-scripts almost never were particularly flexible or powerful, but so help you if you ran into such an artefact.
shrubble 3y ago
Binary logs. Large attack surface. Ever growing features and pieces of the OS that it worms its way into. That's 3...
- kaba0 3y ago
  I never understood this binary log issue - it’s not like it’s some secret proprietary format.. Re large attack surface, anything prior was just security by obscurity, if not worse. You can’t secure chaos.
stcroixx 3y ago
Of course we’ve written both. I don’t even care if it’s better. Large part of the value of Linux for me is stability and lack of churn. I’d just as soon learn another OS if I’m going to put in effort. And I’d way prefer plain text files in /var/log I don’t need weird tools to view. Don’t even know what prom tail or Loki are and I’ve used Linux daily for over 25 years. Blech. Was all part of red hats selfish move to where they are today. Hoping they go down hard.
- ilyt 3y ago
  I mostly like systemd but journalctl/journald unequivocally sucks arse with passion. /rant They made binary format THAT DON'T HAVE ANY FUCKING PROPER INDEXING. It might have actual indexing, who the fuck knows, but it don't have any useful one They could literally just drop in SQLite there and now your entire's system's logs have power of being queried via SQL which would be amazing and easy to use with countless tools that can be used with SQLite but NO, (probably) Lennart wanted to have some fun writing shitty binary format coz of his chronic NIH. strace systemctl status 2>&1 |grep /var/log/journal |wc -l 71 It opens SEVENTY ONE FILES TO GET LOGS ABOUT ONE APPLICATION systemctl status tinc FOR WHICH IT HAS NO LOGS IN THE FIRST PLACE journalctl -a -e -n10 -u tinc |cat -- No entries -- (it's the same for app with logs btw.) I can literally grep a bunch of text files faster than it can look thru it's "efficient" binary logs. But hey if you waste RAM to cache every journal file on your machine in RAM instead of, dunno, actually useful stuff, those commands are fast... It's an abomination and affront to good engineering. Which is shame coz I like many of the other parts. /endrant
- loo 3y ago
  https://github.com/awfulcooking/journalfs https://github.com/awfulcooking/journalfs
- johnea 3y ago
  I've been using it (including writing unit files etc) since archlinux adopted it, so over 10 years now. I still don't like it. The binary interface to logs is a good example, not only for the popular dislike for needing to run a binary to view the log, but also, central to my dislike, is the issue with the "init" system being in charge of logging at all. systemd if far far beyond an "init" system, it is striving to be the "kernel" of user space, in charge of all system functions that are not in the kernel. This isn't feature creep, it's by design. Is the "init" system in charge of network name resolution? What about making fundamental configuration setting to the OS? Another example of the binary required to access logs, is any change to a non-running root filesystem. If you've configured a rootfs for a machine other than the one you're doing this work on (maybe a different CPU architecture, or simply a rootfs for another machine) you're going to run into complications. Same situation when in a chroot. If the rootfs you're configuring, isn't the one currently active, those binary executables are going to havee trouble. As soon as we have systemd-packagemanagerd, there will be 0 difference between systemd based distributions. Everyone will simply put the kernel together w/ systemd for a complete operating system. This was Red Hat's intention, now IBM's intention. I use linux for my work, both in embedded targets and in my development workstation. For many years I've simply copied my home dir to new computers and moved on. The next time I configure a workstation from scratch, I'm going to voidlinux. runit, based on The DJB Way, is much closer to my ideal...
cookiengineer 3y ago
And on top of that: real seccomp sandboxes, dynamic users, chroot, isolated mounts, read-only mounts, isolated groups, process isolation, network isolation, virtual interfaces, virtual /proc and /dev mounts, capability boundaries etc etc ...all that stuff that is real painful to implement with OpenRC or other init script environments. Out of the box, and can be used with every single systemd unit file. Isn't that amazing?
- erik_seaberg 3y ago
  Most of those sound like LXC features, and end users should be able to take advantage of them without having to be aware of how init might work on a particular distro.
__d 3y ago
Unix used to be about simplicity, and the composition of simple tools to achieve very productive outcomes. The shell was a part of that: learn it once, and you could do more-or-less anything with a Unix system. Including manage system startup and shutdown. Linux has never really had that culture of finding the most concise but most general solution to a given problem. The results of that are everywhere, but systemd is a prime example. To be fair, the world is not as simple as it was when Unix was designed either, and that's only partially because the Unix philosophy hasn't been widely adopted.
- kaba0 3y ago
  > Unix used to be about simplicity, and the composition of simple tools to achieve very productive outcomes Then they should have consulted some CS books, as it doesn’t compose in the general case. Also, how was using another init systems command different than using systemd’s?
ekianjo 3y ago
The problem is that systemd tries to turn into something that does everything under the sun. It is not ideal and kind of far from the unix philosophy.
- kaba0 3y ago
  It’s almost like the Unix philosophy is bullshit at its extremes. System init is a fkin hard problem, you can’t just throw million small tools at it, the same way we don’t write web browsers by pipe-ing together curl and whatnot.
  - josephcsible 3y ago
    > System init is a fkin hard problem, you can’t just throw million small tools at it You can't do it the way that everyone did it before systemd?
    - kaba0 3y ago
      Sure, if I were to want a shitty, hacked together unstable system, where not even the few linux program could run on a different distro, as has been the case before systemd.
      - josephcsible 3y ago
        Do you think your description is accurate for Gentoo with OpenRC today?
ilyt 3y ago
> I have used init scripts, I have written init scripts. I hated it. Every program needed it's own little way of doing things and writing an init script for a daemon was a hassle of bash scripting and copy pasting. We had, no joking, thousands lines of init scripts that were just ripped out of distro (mostly CentOS/RHEL... Debian had some pre-made wrappers that mostly did the right thing) and fixed by us because people saying "it's so easy" to write init script ARE LYING. And some apps, like Pacemaker (app for making other things HA), are really sensitive on scripts not being done fully correctly Some tidbits: * script reports app is stopped right after you run start... because it left creating PID to application, app took some time to boot (Java), and the script didn't wait for PID creation. So running "start, then run status to check whether it worked" returned that app did not work. * script reports app is running after reboot. The app is not running. Script read off PID file off /var/run (that at the time wasn't in tmpfs like now /run is), saw PID exists and didn't try to start it at all. The pid was of a different application. That was MySQL, not some random obscure app... * "stop" action doesn't actually return when app is stopped, it just sends signal. sysv goes ahead and shuts down system before app manages to write all of the data. Or in case of pacemaker it does weird stuff because "status returning running after sending stop" should not happen. * other various ways "status" was broken randomly
- bandrami 3y ago
  OTOH "systemctl start httpd.service" exits with 0 even if apache doesn't start because for some reason "a misconfigured apache didn't start" is considered correct behavior. I don't know that any init has actually solved that problem.
  - Arnavion 3y ago
    This requires the application to tell the service manager to wait for some signal that it has successfully "finished starting" beyond just "the process was created". There's no standard way to do it. In systemd's case this is done by opting in to inherit a socket that can be used to communicate that information (`Type=notify`, then calling `sd_notify()`).
    - 3y ago
deltasquared 3y ago
People may not trust systemd because years ago there were some really bad defaults like https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402 that for instance mounted your firmware in read write mode by default. That kind of thing leaves a bad taste in some peoples mouth. I am pretty sure some people have bricked hardware with systemd.
- throw0101a 3y ago
  Or when they started killing user background processes (screen/tmux/nohup X) instead of sending SIGUP like POSIX/Unix has done since basically forever: * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825941 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825941 As someone who runs mostly servers, I also find resolved annoying and have to rip it out. There's also all sorts of tomfoolery with /etc/resolv.conf in many modern distros, to the point I've taken to setting the immutable flag on it to prevent things diddling with it. There was also the bug where systemD wouldn't allow usernames that started with a number. Poettering's (initial?) response was to tag it as "not-a-bug": > Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create it in the first place. Note that not permitting numeric first characters is done on purpose: to avoid ambiguities between numeric UID and textual user names. * https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 * https://news.ycombinator.com/item?id=14681377 https://news.ycombinator.com/item?id=14681377 (discussion at the time) Nevermind that (a) POSIX allows it, and (b) so do the user manipulation tools of Poettering's employer at the time (RH).
andrewstuart 3y ago
Haters gonna hate. Some people just don't like it. That's their decision. In most cases its emotional. Beyond complaints about journals being binary, which I get, there's usually not much more to the systemd hatred than "I just don't like it, humph (frown, arms crossed)". It's an open source world..... the haters have the chance to come up with something that's better and if it is actually better then in the Linux merit driven ecosystem, then the better thing should win and be adopted, right? Personally I love systemd - unbelievably useful and powerful. Stallman used to say Linux should be called gnu/Linux because there's some gnu code in many distros. More realistically it should be called Linux/systemd because systemd defines so much of how the operating system works.
- loo 3y ago
  They should have just offered a way to make it write text log files. I have a prototype FUSE filesystem which renders the journal as a tree of .log files (https://github.com/awfulcooking/journalfs https://github.com/awfulcooking/journalfs) But my muscles finally learned `journalctl` and after reading the docs I mainly use it. Patches welcome to make journalfs practical (i think it may be lagging output when you `tail -f` atm) Would love to see systemd offer a virtual filesystem interface by default.
wink 3y ago
I'm wondering how "writing unit files" even registers as a meaningful percentage of work (time) versus the parts where I (and others) see the problems. Looking at logs, having problems with journald, not being able to shutdown the laptop because something hangs. Don't get me wrong, I've made my peace with systemd and I've never been an outright hater, but I did more sysadmin work in sysv and the transition times than now but I still get bitten by systemd more often per year. Usually small stuff, but apparently it only made those things better that never bothered me.
JohnFen 3y ago
> has anyone who complains about systemd actually written a unit file vs an init script? Yes, I've written quite a lot of both. My objection to systemd isn't really the init system replacement. It's OK (although I really don't prefer it over the System V style). My real objection to it is everything else about it. > And all your logs are in journald JournalD is an example of one of the "everything else" that I strongly dislike.

ed25519FUUU 3y ago

I also never understood the disdain for it. I feel like 15 minutes of reading about systemd keywords and I was on my way to making some very usable and reliable systemd scripts. I don’t use sysv init anymore but I don’t feel like I ever fully understood those scripts.

foobarian 3y ago
I get the disdain. Beyond just reacting to change, systemv is fully scripted and thus a lot more accessible - one can read the source and understand what is happening fully once the kernel is done. On the other hand with systemd I feel we get this opaque magical complexity encroaching into previously fully grokkable user space and that is very hard to take, regardless of actual pros and cons.

mackal 3y ago

I think it all comes back to people being upset about the Ubuntu PulseAudio switch. Ubuntu did a bad job when they switched to PulseAudio and caused lots of issues. Lennart Poettering was lead dev for both projects and it's weird how much the anti-systemd crowd get their panties in a bunch over him and also PA.

ilyt 3y ago
He fucked uo a lot in PA He also fucked up some in systemd, journalctl being biggest example. He also fucked up some in kernel, to the point Linus yelled at him The critique is entirely deserved
- throw0101a 3y ago
  > He also fucked up some in systemd, journalctl being biggest example. "Let's just invent our own non-ACID file format instead using what's already available." (Like perhaps SQLite.) Howard Chu of OpenLDAP had a rant on this: * https://www.linkedin.com/pulse/20140924071300-170035-why-you-cannot-trust-lennart-poettering-systemd/ https://www.linkedin.com/pulse/20140924071300-170035-why-you... Does journald support off-host log shipping yet? Because for all its supposed replacing of syslog, as a sysadmin I still have to run (r)syslogd to send things to a central log host via RFC 3164/5424 anyway.
  - ilyt 3y ago
    I'm pretty sure it's just him wanting to toy with databases and picking systemd to be his victim. I'd expect when he finds new toy to keep himself busy someone else will fix it to actually work properly for the most time like it happened with PulseAudio

xraystyle 3y ago

I don't get it either. Systemd units are so much more powerful and flexible than init scripts. Writing those bash scripts for everything was a complete pain in the ass. You may disagree with the architecture or design decisions made with systemd, but I don't see how it's possible to argue that SysVinit was in any way actually "better".

rektide 3y ago
They're neither more powerful nor more flexible. Init-scripts can iterate & build whatever complexity they want. They can be far wilder. There's almost nothing constraining what an init script could be. Systemd does establish easy-to-use & incredibly-powerful access a wide range of super-powerful knobs. And in a consistent & clear way, where-as each init-script would have a totally different way of doing config & slightly different approaches to the various hacks. And init scripts arent composable, where-as you can take your distro's regular unit, and drop-in some additional configuration easily, in a very eloquent way, across any bit of config. I think systemd is amazing & brings enormous clarity. It has enormous power. But init-scripts still had more power. But it was reckless chaotic power that was enormously hard to tap, and required prodigal talent to develop these individual artisinal artefacts, which became, as a user, a thing of horror to rework. Init-scripts almost never were particularly flexible or powerful, but so help you if you ran into such an artefact.

shrubble 3y ago

Binary logs. Large attack surface. Ever growing features and pieces of the OS that it worms its way into. That's 3...

kaba0 3y ago
I never understood this binary log issue - it’s not like it’s some secret proprietary format.. Re large attack surface, anything prior was just security by obscurity, if not worse. You can’t secure chaos.

stcroixx 3y ago

Of course we’ve written both. I don’t even care if it’s better. Large part of the value of Linux for me is stability and lack of churn. I’d just as soon learn another OS if I’m going to put in effort. And I’d way prefer plain text files in /var/log I don’t need weird tools to view. Don’t even know what prom tail or Loki are and I’ve used Linux daily for over 25 years. Blech. Was all part of red hats selfish move to where they are today. Hoping they go down hard.

ilyt 3y ago
I mostly like systemd but journalctl/journald unequivocally sucks arse with passion. /rant They made binary format THAT DON'T HAVE ANY FUCKING PROPER INDEXING. It might have actual indexing, who the fuck knows, but it don't have any useful one They could literally just drop in SQLite there and now your entire's system's logs have power of being queried via SQL which would be amazing and easy to use with countless tools that can be used with SQLite but NO, (probably) Lennart wanted to have some fun writing shitty binary format coz of his chronic NIH. strace systemctl status 2>&1 |grep /var/log/journal |wc -l 71 It opens SEVENTY ONE FILES TO GET LOGS ABOUT ONE APPLICATION systemctl status tinc FOR WHICH IT HAS NO LOGS IN THE FIRST PLACE journalctl -a -e -n10 -u tinc |cat -- No entries -- (it's the same for app with logs btw.) I can literally grep a bunch of text files faster than it can look thru it's "efficient" binary logs. But hey if you waste RAM to cache every journal file on your machine in RAM instead of, dunno, actually useful stuff, those commands are fast... It's an abomination and affront to good engineering. Which is shame coz I like many of the other parts. /endrant
loo 3y ago
https://github.com/awfulcooking/journalfs https://github.com/awfulcooking/journalfs
johnea 3y ago
I've been using it (including writing unit files etc) since archlinux adopted it, so over 10 years now. I still don't like it. The binary interface to logs is a good example, not only for the popular dislike for needing to run a binary to view the log, but also, central to my dislike, is the issue with the "init" system being in charge of logging at all. systemd if far far beyond an "init" system, it is striving to be the "kernel" of user space, in charge of all system functions that are not in the kernel. This isn't feature creep, it's by design. Is the "init" system in charge of network name resolution? What about making fundamental configuration setting to the OS? Another example of the binary required to access logs, is any change to a non-running root filesystem. If you've configured a rootfs for a machine other than the one you're doing this work on (maybe a different CPU architecture, or simply a rootfs for another machine) you're going to run into complications. Same situation when in a chroot. If the rootfs you're configuring, isn't the one currently active, those binary executables are going to havee trouble. As soon as we have systemd-packagemanagerd, there will be 0 difference between systemd based distributions. Everyone will simply put the kernel together w/ systemd for a complete operating system. This was Red Hat's intention, now IBM's intention. I use linux for my work, both in embedded targets and in my development workstation. For many years I've simply copied my home dir to new computers and moved on. The next time I configure a workstation from scratch, I'm going to voidlinux. runit, based on The DJB Way, is much closer to my ideal...

cookiengineer 3y ago

And on top of that: real seccomp sandboxes, dynamic users, chroot, isolated mounts, read-only mounts, isolated groups, process isolation, network isolation, virtual interfaces, virtual /proc and /dev mounts, capability boundaries etc etc ...all that stuff that is real painful to implement with OpenRC or other init script environments. Out of the box, and can be used with every single systemd unit file. Isn't that amazing?

erik_seaberg 3y ago
Most of those sound like LXC features, and end users should be able to take advantage of them without having to be aware of how init might work on a particular distro.

__d 3y ago

Unix used to be about simplicity, and the composition of simple tools to achieve very productive outcomes. The shell was a part of that: learn it once, and you could do more-or-less anything with a Unix system. Including manage system startup and shutdown. Linux has never really had that culture of finding the most concise but most general solution to a given problem. The results of that are everywhere, but systemd is a prime example. To be fair, the world is not as simple as it was when Unix was designed either, and that's only partially because the Unix philosophy hasn't been widely adopted.

kaba0 3y ago
> Unix used to be about simplicity, and the composition of simple tools to achieve very productive outcomes Then they should have consulted some CS books, as it doesn’t compose in the general case. Also, how was using another init systems command different than using systemd’s?

ekianjo 3y ago

The problem is that systemd tries to turn into something that does everything under the sun. It is not ideal and kind of far from the unix philosophy.

kaba0 3y ago
It’s almost like the Unix philosophy is bullshit at its extremes. System init is a fkin hard problem, you can’t just throw million small tools at it, the same way we don’t write web browsers by pipe-ing together curl and whatnot.
- josephcsible 3y ago
  > System init is a fkin hard problem, you can’t just throw million small tools at it You can't do it the way that everyone did it before systemd?
  - kaba0 3y ago
    Sure, if I were to want a shitty, hacked together unstable system, where not even the few linux program could run on a different distro, as has been the case before systemd.
    - josephcsible 3y ago
      Do you think your description is accurate for Gentoo with OpenRC today?

ilyt 3y ago

> I have used init scripts, I have written init scripts. I hated it. Every program needed it's own little way of doing things and writing an init script for a daemon was a hassle of bash scripting and copy pasting. We had, no joking, thousands lines of init scripts that were just ripped out of distro (mostly CentOS/RHEL... Debian had some pre-made wrappers that mostly did the right thing) and fixed by us because people saying "it's so easy" to write init script ARE LYING. And some apps, like Pacemaker (app for making other things HA), are really sensitive on scripts not being done fully correctly Some tidbits: * script reports app is stopped right after you run start... because it left creating PID to application, app took some time to boot (Java), and the script didn't wait for PID creation. So running "start, then run status to check whether it worked" returned that app did not work. * script reports app is running after reboot. The app is not running. Script read off PID file off /var/run (that at the time wasn't in tmpfs like now /run is), saw PID exists and didn't try to start it at all. The pid was of a different application. That was MySQL, not some random obscure app... * "stop" action doesn't actually return when app is stopped, it just sends signal. sysv goes ahead and shuts down system before app manages to write all of the data. Or in case of pacemaker it does weird stuff because "status returning running after sending stop" should not happen. * other various ways "status" was broken randomly

bandrami 3y ago
OTOH "systemctl start httpd.service" exits with 0 even if apache doesn't start because for some reason "a misconfigured apache didn't start" is considered correct behavior. I don't know that any init has actually solved that problem.
- Arnavion 3y ago
  This requires the application to tell the service manager to wait for some signal that it has successfully "finished starting" beyond just "the process was created". There's no standard way to do it. In systemd's case this is done by opting in to inherit a socket that can be used to communicate that information (`Type=notify`, then calling `sd_notify()`).
  - 3y ago

deltasquared 3y ago

People may not trust systemd because years ago there were some really bad defaults like https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402 that for instance mounted your firmware in read write mode by default. That kind of thing leaves a bad taste in some peoples mouth. I am pretty sure some people have bricked hardware with systemd.

throw0101a 3y ago
Or when they started killing user background processes (screen/tmux/nohup X) instead of sending SIGUP like POSIX/Unix has done since basically forever: * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825941 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825941 As someone who runs mostly servers, I also find resolved annoying and have to rip it out. There's also all sorts of tomfoolery with /etc/resolv.conf in many modern distros, to the point I've taken to setting the immutable flag on it to prevent things diddling with it. There was also the bug where systemD wouldn't allow usernames that started with a number. Poettering's (initial?) response was to tag it as "not-a-bug": > Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create it in the first place. Note that not permitting numeric first characters is done on purpose: to avoid ambiguities between numeric UID and textual user names. * https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 * https://news.ycombinator.com/item?id=14681377 https://news.ycombinator.com/item?id=14681377 (discussion at the time) Nevermind that (a) POSIX allows it, and (b) so do the user manipulation tools of Poettering's employer at the time (RH).

andrewstuart 3y ago

Haters gonna hate. Some people just don't like it. That's their decision. In most cases its emotional. Beyond complaints about journals being binary, which I get, there's usually not much more to the systemd hatred than "I just don't like it, humph (frown, arms crossed)". It's an open source world..... the haters have the chance to come up with something that's better and if it is actually better then in the Linux merit driven ecosystem, then the better thing should win and be adopted, right? Personally I love systemd - unbelievably useful and powerful. Stallman used to say Linux should be called gnu/Linux because there's some gnu code in many distros. More realistically it should be called Linux/systemd because systemd defines so much of how the operating system works.

loo 3y ago
They should have just offered a way to make it write text log files. I have a prototype FUSE filesystem which renders the journal as a tree of .log files (https://github.com/awfulcooking/journalfs https://github.com/awfulcooking/journalfs) But my muscles finally learned `journalctl` and after reading the docs I mainly use it. Patches welcome to make journalfs practical (i think it may be lagging output when you `tail -f` atm) Would love to see systemd offer a virtual filesystem interface by default.

wink 3y ago

I'm wondering how "writing unit files" even registers as a meaningful percentage of work (time) versus the parts where I (and others) see the problems. Looking at logs, having problems with journald, not being able to shutdown the laptop because something hangs. Don't get me wrong, I've made my peace with systemd and I've never been an outright hater, but I did more sysadmin work in sysv and the transition times than now but I still get bitten by systemd more often per year. Usually small stuff, but apparently it only made those things better that never bothered me.

JohnFen 3y ago

> has anyone who complains about systemd actually written a unit file vs an init script? Yes, I've written quite a lot of both. My objection to systemd isn't really the init system replacement. It's OK (although I really don't prefer it over the System V style). My real objection to it is everything else about it. > And all your logs are in journald JournalD is an example of one of the "everything else" that I strongly dislike.