5 ms·

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 thou

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.
    - throw-8462682 5y ago
      > But it's not actually booted until the service is up, so it's moot. With per second billing, fast boot times save money and enable lower fixed capacity, further lowering cost.
      - knorker 5y ago
        But no it doesn't. Until your service is started, your service is NOT actually booted. That's what I said. You are not paying per-second for the VM. The VM itself adds zero value to you. It's the service that's running (or in this case, not) that you're paying for. Who cares how long it takes before systemd calls listen()? Nobody derives value from that. You're not paying for that. You're paying for the SERVICE to be ready. And if you're not, then why are you even spinning up a VM, if it's not going to run a service? It's just clever accounting.
        throw-8462682 5y ago
        Starting services in parallel will reduce overall service start up time as well, even if services are dependent on each other, because services often do work before they connect to a dependent service. Without socket activation that is a race condition.
    - yawaramin 5y ago
      > I didn't say that. Because they don't. Yes, you did. Here's a refresher: > 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. I.e. sometimes computers just need to reboot, and there's nothing you can do about it. > Nobody cares If nobody cares, then why do people hate rebooting so much?

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.
  - throw-8462682 5y ago
    > But it's not actually booted until the service is up, so it's moot. With per second billing, fast boot times save money and enable lower fixed capacity, further lowering cost.
    - knorker 5y ago
      But no it doesn't. Until your service is started, your service is NOT actually booted. That's what I said. You are not paying per-second for the VM. The VM itself adds zero value to you. It's the service that's running (or in this case, not) that you're paying for. Who cares how long it takes before systemd calls listen()? Nobody derives value from that. You're not paying for that. You're paying for the SERVICE to be ready. And if you're not, then why are you even spinning up a VM, if it's not going to run a service? It's just clever accounting.
      - throw-8462682 5y ago
        Starting services in parallel will reduce overall service start up time as well, even if services are dependent on each other, because services often do work before they connect to a dependent service. Without socket activation that is a race condition.
  - yawaramin 5y ago
    > I didn't say that. Because they don't. Yes, you did. Here's a refresher: > 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. I.e. sometimes computers just need to reboot, and there's nothing you can do about it. > Nobody cares If nobody cares, then why do people hate rebooting so much?