5 ms·

Also, I'm not sure what you mean by "massive integration issues." Can you identify a "massive" (i.e. show-stopping) problem in Linux-based operating systems th

• JoshTriplett 12y ago
  A few examples, off the top of my head: Socket activation (and related features like bus activation) are one of systemd's key improvements to the boot process. Activation avoids the need for explicit dependencies, because you don't need to depend on avahi to start using the avahi socket. And because of that, systemd can launch avahi and services using avahi in parallel, by opening the socket for avahi, and letting other services write to that socket before avahi fully starts, only blocking when they go to read from it. You could do that with inetd or similar, but inetd doesn't integrate with the init system, so an inetd service can't declare any dependencies on other services, and won't get tracked alongside other services (e.g. with systemctl status). So in practice, very few distributions actually launched services from inetd in practice (notable exception: CUPS), while many distributions use systemd's socket activation. People care about booting quickly. While mechanisms like bootchart existed before systemd, you had to explicitly boot with them to collect results for analysis, and they'd slow down the boot process. With systemd, you can run "systemd-analyze blame" or "systemd-analyze critical-chain" on a production system and see exactly what you need to work on to make the system boot faster. (That was one of the widely lauded features of DTrace: you could safely use it to diagnose production systems.) Then there's journald's original reason for existence: "how can we make 'systemctl status' show the last few lines of log output from a service?". How would you do that on an arbitrary system running an arbitrary syslog implementation? (For extra bonus difficulty, do so while attempting to track the syslog implementation as a service itself, and avoid deadlocks.) Sure, you could recreate that functionality on a particular system with a particular logging configuration, and there are dozens of systems doing so, not counting the myriad production systems deployed with bespoke solutions for log monitoring. (Even then, most of those systems don't correlate a service's log output with that service.) But systemd makes it easy and universal. And that integration extends beyond systemd as well. For instance, if fixing a problem requires adding a new kernel interface, they'll submit a kernel patch, and then have systemd use that new kernel interface, rather than hacking around the problem in systemd and producing a suboptimal solution.
  • felixgallo 12y ago
    "booting faster" is a desktop concern from 1990. Are there really a bunch of linux users turning on and off their computers constantly and using linux on the desktop? Is this really an actual thing? Because I'd like to introduce these people to (a) real desktop environments maintained by smart people and (b) at the very least, suspend mode.
    • dsr_ 12y ago
      In practice, I see people boot Linux desktops under three conditions: 1. Once in a great long while, perhaps when there was a power outage or a critical system update. 2. Daily, for a few people who shut down their computers when they finish work for the day and boot them in the morning. (I never understood this.) 3. When something has gone quite badly wrong. Outside of that, there are desktops which hibernate, laptops which hibernate, and phones which are running Firefox OS or Android and boot about once a week. If you have a journaling filesystem and no weird hardware, desktop boot times are not a problem.
      • ithkuil 12y ago
        not a huge fan of systemd either, but I'm sure that if computers were able to boot in milliseconds then some of those practices would change. Also, it's not only about desktop. Autoscaling of virtual on demand servers can greatly benefit of extremely short boot times. Surely you could use a simple and highly optimized boot system in such cases, but why not use the same if it works well. It seems to me that it's more about systemd developers' attitude than with the actual goals. Perhaps the same goals could be achieved with a more modular approach. The important thing is that distributions (or components that manage the deployment of services, e.g. package managers or custom service management solutions) need a simple yet powerful way to express their requirements. Not sure this requires this level of integration which appears more like a way to force people to use it (or simply because it's simpler to approach this problem by throwing away the complex legacy).
        • felixgallo 12y ago