8 ms·

Care to elaborate? Off the bat, your comment comes across as a cynical rant due to its high use of strong words (garbage, fuck) and lack of examples. And even i

Care to elaborate? Off the bat, your comment comes across as a cynical rant due to its high use of strong words (garbage, fuck) and lack of examples. And even if you have anecdotes, to be convincing, it would have compare something like bug density to the software projects that collectively replaces. As written, your statement is unlikely to convince anyone that isn’t yet already.

j16sdiz 5y ago
Not OP. I my experience, systemd config is simple because it handles all the complexity. Inside it’s guts, it is much more complicated than a sysv system — naturally so because it can do so much more. Those folks loves using the latest and greatest kernel function for all its glory. All works well - until it don’t. When something is broken, suddenly you have to understand all the interdependent components to debug. Back in the days, these were not so uncommon, because bugs or simply unimplemented features………
- knorker 5y ago
  Agree with that. It breaks catastrophically. But it's also overengineered. Like starting a daemon on first connect is "neat trick", but should never have gone beyond that. Like: oh, I want to restart this daemon, because I want it to re-run its init code (possibly with new settings), but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart" is a no-op.
  - throw-8462682 5y ago
    Starting a daemon on first connect is essential for fast boot times of a system with multiple dependent network services. This is mostly a desktop use case though. Not sure if it can be disabled for servers.
    - knorker 5y ago
      But I would also like to see data showing how often desktop users reboot (on purpose, that is, not because systemd or something says "you should reboot now" because it's shitty software that doesn't just work cross updates). Like, who even boots their computer anymore? Isn't the typical user on a laptop, and just suspends it? My workplace even had to install corp software that forces a reboot every N days (with warnings ahead of time) because people just Do. Not. Reboot. And even for the people that do, at what cost, here? You have a bunch of services and services completely broken, but "they started just fine" (except they didn't start), and only break once you actually need them. So to me this really looks like it applies neither to servers nor desktop. I'm really not seeing any use case except fetishizing boot times. And for me this always SPENDS human wait time, not save it. I try to use a service, and nope, it needs to "boot up" first. Could you not have done that already, WTF? (and maybe it fails to boot, which I only find out about now that I'm already in the zone to use it) Are we really optimizing for kernel developers, here? Can't they just disable the services they don't need, to speed it up? And we have eleventy billion cores now. Really? You can't start a 645kB gpsd? It takes what, 3ms?
      - yawaramin 5y ago
        > So to me this really looks like it applies neither to servers nor desktop. It applies to both. We need desktops to boot up fast, because you said it yourself, sometimes they just need to. And no one likes waiting around for their machines to boot. Can you imagine the volume of complaints about long boot times that would come in to large-scale distros from annoyed users? That alone makes it a high priority. And on top of that, we need servers to boot up fast, because nowadays they're virtualized and started/stopped constantly when services are scaled up and down. Can you imagine trying to scale up a fleet of servers and waiting a couple of minutes for each one to boot?
        knorker 5y ago
        > We need desktops to boot up fast, because you said it yourself, sometimes they just need to I didn't say that. Because they don't. > And no one likes waiting around for their machines to boot. Nobody cares, if it's once for every month or two. Which it is. > we need servers to boot up fast But it's not actually booted until the service is up, so it's moot.
  - yawaramin 5y ago
    > but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart" is a no-op. FTA: > It can then boot your service on the first request, or you can do systemctl start lunchd yourself if you think that would take a while.
    - knorker 5y ago
      You can, but it doesn't. If I know I want to start it I can just connect with the client. Sounds like you're arguing something like "yes, it's broken. But you can just reimplement everything and it won't be broken anymore". Yes, I can also turn off "kill user processes on logout", but that doesn't make that not-broken.
      - yawaramin 5y ago
        No, I'm arguing there's a way to force-start even socket-activated services. But this is really a moot point. Systemd's socket activation is really meant for system services which would otherwise be in the critical path of system boot. 'Regular' client-facing services that people normally run–webapps, etc.–are not really the target use case. It's fine to start them up in the normal way, with WantedBy=multi-user.target in the [Install] section. And I have never seen people use socket activation for them anyway. So you are basically arguing a strawman here.
        knorker 5y ago
        > So you are basically arguing a strawman here. gpsd is an example that immediately comes to mind that was set to start on-demand. Which is ridiculous. So it's a straw man that actually exists, making it not a straw man.
knorker 5y ago
It's a pile of proof-of-concept broken pieces duct taped together into a big mess. Here's an example: Someone read that fd-passing is a thing, so now systemd listens to just about everything and spawns stuff on-demand. Now, that may seem like a good idea, if you think it up in a vaccuum and don't have experience with the real world. It's a great idea, if you're in high school. But to have it actually accepted? WTF is even happening? Oh, let's do this for time sync from GPS. Great. All that time that could have been spent verifying the signal and all, completely wasted, because some jerk thought that it's better to waste 15 minutes of the human waiting, just to save 100kB of RAM. It's a monumentally bad idea. And more specifics: Like I said, when you replace init you need to have it not crash. And then restarting daemons with systemctl almost to a rule fails, and fails silently. Often I have to just kill the daemon manually, and systemctl start it again. But people aren't complaining about systemd anymore because now there's two kinds of people: 1. People to young to remember stable software. 2. People who have given up, and just accepted that Linux too "just needs a reboot every now and then to kinda fix whatever got broken". But maybe the trend is changing? Pipewire looks like it's not actually shit (unlike PulseAudio which has plagued us forever), and while it has some important bugs in edge cases, it's actually more reliable than what it's replacing(!) > As written, your statement is unlikely to convince anyone that isn’t yet already. It's hard to convince people who don't care. Or indeed those who don't know that no, actually, short of a kernel upgrade "reboot to fix that problem whenever it happens" is not normal, and is a serious bug. Pre-systemd Linux had as a selling point that it's actually stable, compared to Windows at least. But Windows has gotten much better in the past decade in reliability, and Linux much worse. systemd is on the level of a re-think by a pretty bright high school student. And that's not a good thing. It's a very bad thing. > to be convincing, it would have compare something like bug density to the software projects that collectively replaces You're asking me to be data-driven, while being fully aware that systemd isn't, right? Your argument is essentially fallacy by implying that status quo is data-driven. It's hard to take your suggestion at face value. Especially with many of the same people pushing systemd at the time making up shit like "We know that Unity is objectively the best user experience in the world"[1] (that's why it lost, because nobody liked it, right?[2]). At the same time I also fall into group (2), above. I don't have time to wrestle in the mud with people who don't care. [1] a quote like that, I may not have gotten the words just right. but the word "objectively" (without data) was there. [2] and I don't even particularly care about window managers. Before Unity I hadn't bothered switching from "whatever the default is on this system" in most cases.

j16sdiz 5y ago

Not OP. I my experience, systemd config is simple because it handles all the complexity. Inside it’s guts, it is much more complicated than a sysv system — naturally so because it can do so much more. Those folks loves using the latest and greatest kernel function for all its glory. All works well - until it don’t. When something is broken, suddenly you have to understand all the interdependent components to debug. Back in the days, these were not so uncommon, because bugs or simply unimplemented features………

knorker 5y ago
Agree with that. It breaks catastrophically. But it's also overengineered. Like starting a daemon on first connect is "neat trick", but should never have gone beyond that. Like: oh, I want to restart this daemon, because I want it to re-run its init code (possibly with new settings), but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart" is a no-op.
- throw-8462682 5y ago
  Starting a daemon on first connect is essential for fast boot times of a system with multiple dependent network services. This is mostly a desktop use case though. Not sure if it can be disabled for servers.
  - knorker 5y ago
    But I would also like to see data showing how often desktop users reboot (on purpose, that is, not because systemd or something says "you should reboot now" because it's shitty software that doesn't just work cross updates). Like, who even boots their computer anymore? Isn't the typical user on a laptop, and just suspends it? My workplace even had to install corp software that forces a reboot every N days (with warnings ahead of time) because people just Do. Not. Reboot. And even for the people that do, at what cost, here? You have a bunch of services and services completely broken, but "they started just fine" (except they didn't start), and only break once you actually need them. So to me this really looks like it applies neither to servers nor desktop. I'm really not seeing any use case except fetishizing boot times. And for me this always SPENDS human wait time, not save it. I try to use a service, and nope, it needs to "boot up" first. Could you not have done that already, WTF? (and maybe it fails to boot, which I only find out about now that I'm already in the zone to use it) Are we really optimizing for kernel developers, here? Can't they just disable the services they don't need, to speed it up? And we have eleventy billion cores now. Really? You can't start a 645kB gpsd? It takes what, 3ms?
    - yawaramin 5y ago
      > So to me this really looks like it applies neither to servers nor desktop. It applies to both. We need desktops to boot up fast, because you said it yourself, sometimes they just need to. And no one likes waiting around for their machines to boot. Can you imagine the volume of complaints about long boot times that would come in to large-scale distros from annoyed users? That alone makes it a high priority. And on top of that, we need servers to boot up fast, because nowadays they're virtualized and started/stopped constantly when services are scaled up and down. Can you imagine trying to scale up a fleet of servers and waiting a couple of minutes for each one to boot?
      - knorker 5y ago
        > We need desktops to boot up fast, because you said it yourself, sometimes they just need to I didn't say that. Because they don't. > And no one likes waiting around for their machines to boot. Nobody cares, if it's once for every month or two. Which it is. > we need servers to boot up fast But it's not actually booted until the service is up, so it's moot.
- yawaramin 5y ago
  > but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart" is a no-op. FTA: > It can then boot your service on the first request, or you can do systemctl start lunchd yourself if you think that would take a while.
  - knorker 5y ago
    You can, but it doesn't. If I know I want to start it I can just connect with the client. Sounds like you're arguing something like "yes, it's broken. But you can just reimplement everything and it won't be broken anymore". Yes, I can also turn off "kill user processes on logout", but that doesn't make that not-broken.
    - yawaramin 5y ago
      No, I'm arguing there's a way to force-start even socket-activated services. But this is really a moot point. Systemd's socket activation is really meant for system services which would otherwise be in the critical path of system boot. 'Regular' client-facing services that people normally run–webapps, etc.–are not really the target use case. It's fine to start them up in the normal way, with WantedBy=multi-user.target in the [Install] section. And I have never seen people use socket activation for them anyway. So you are basically arguing a strawman here.
      - knorker 5y ago
        > So you are basically arguing a strawman here. gpsd is an example that immediately comes to mind that was set to start on-demand. Which is ridiculous. So it's a straw man that actually exists, making it not a straw man.

knorker 5y ago

It's a pile of proof-of-concept broken pieces duct taped together into a big mess. Here's an example: Someone read that fd-passing is a thing, so now systemd listens to just about everything and spawns stuff on-demand. Now, that may seem like a good idea, if you think it up in a vaccuum and don't have experience with the real world. It's a great idea, if you're in high school. But to have it actually accepted? WTF is even happening? Oh, let's do this for time sync from GPS. Great. All that time that could have been spent verifying the signal and all, completely wasted, because some jerk thought that it's better to waste 15 minutes of the human waiting, just to save 100kB of RAM. It's a monumentally bad idea. And more specifics: Like I said, when you replace init you need to have it not crash. And then restarting daemons with systemctl almost to a rule fails, and fails silently. Often I have to just kill the daemon manually, and systemctl start it again. But people aren't complaining about systemd anymore because now there's two kinds of people: 1. People to young to remember stable software. 2. People who have given up, and just accepted that Linux too "just needs a reboot every now and then to kinda fix whatever got broken". But maybe the trend is changing? Pipewire looks like it's not actually shit (unlike PulseAudio which has plagued us forever), and while it has some important bugs in edge cases, it's actually more reliable than what it's replacing(!) > As written, your statement is unlikely to convince anyone that isn’t yet already. It's hard to convince people who don't care. Or indeed those who don't know that no, actually, short of a kernel upgrade "reboot to fix that problem whenever it happens" is not normal, and is a serious bug. Pre-systemd Linux had as a selling point that it's actually stable, compared to Windows at least. But Windows has gotten much better in the past decade in reliability, and Linux much worse. systemd is on the level of a re-think by a pretty bright high school student. And that's not a good thing. It's a very bad thing. > to be convincing, it would have compare something like bug density to the software projects that collectively replaces You're asking me to be data-driven, while being fully aware that systemd isn't, right? Your argument is essentially fallacy by implying that status quo is data-driven. It's hard to take your suggestion at face value. Especially with many of the same people pushing systemd at the time making up shit like "We know that Unity is objectively the best user experience in the world"[1] (that's why it lost, because nobody liked it, right?[2]). At the same time I also fall into group (2), above. I don't have time to wrestle in the mud with people who don't care. [1] a quote like that, I may not have gotten the words just right. but the word "objectively" (without data) was there. [2] and I don't even particularly care about window managers. Before Unity I hadn't bothered switching from "whatever the default is on this system" in most cases.