4 ms·

Yes, but we didn't decide to not use sysvinit on those grounds. It's quite a nifty case to make, that we can't use a new init system because we haven't used th

by akerl_ 13y ago

Yes, but we didn't decide to not use sysvinit on those grounds. It's quite a nifty case to make, that we can't use a new init system because we haven't used the new init system for a long time already to find the bugs.

ZeroGravitas 13y ago
That actually strikes me as a more reasonable objection than many I've heard. On the other hand, systemd is actually in use in various places, so bugs are being looked for and found, so this process doesn't begin with Debian's adoption and you're back to balancing probababilities the same as you would with any change.
- belorn 13y ago
  > Debian's adoption In this case, adoption means moving systemd from being optional to default. Debian has had systemd in use for quite a while now with current statistics at 7.5% of all installation (accordingly to popcon http://qa.debian.org/popcon.php?package=systemd http://qa.debian.org/popcon.php?package=systemd).
  - bbanyc 13y ago
    Package names are a bit confusing here. The systemd package includes all the binaries - one of which, logind, is required by GNOME - but doesn't install systemd as /sbin/init and doesn't boot with it by default. The package to do that is called systemd-sysv, for reasons having to do with the special treatment of sysvinit as a "required" package in dpkg. So 7.5% of Debian systems have it installed, but only about 0.3% (plus however many of that 7.5% that are setting init=systemd in GRUB) are using it.
    - ibotty 13y ago
      setting init=/sbin/systemd in the kernel cmdline is the recommended way, so i guess the 7.5% do count as using systemd.
dredmorbius 13y ago
It's quite a nifty case to make, that we can't use a new init system That's not the case I was making. Rather it was oofabz's apparent criticism of sysvinit's security profile based on the fact that bugs were found and removed individually. That's not a particularly valid criticism. There are more valid ways of establishing software quality based on bug estimation (defects found, estimated undiscovered defects remaining). The rate with which init scripts are changed (the fact that they can be modified, possibly erroneously, by individual systems admins is another consideration). A system that's been specifically designed to be resistant to coding and use errors (again: OpenBSD) is better. Some init script systems are better than others, and I've found the Debian scripts to be simpler, cleaner, and more robust than Red Hat's (which use multiple levels of includes and indirection). In the case of systemd, I've found the touted benefits ("faster booting" -- ORLY? I prefer not having to boot/reboot systems), complexity, novelty, and track-record of the primary developer to be quite troubling. Technology is a complexity management system. Much of the problem in the GNOME project comes from failing to manage complexity appropriately (oversimplifying a complex space, creating complex tools with more levels of indirection (gconf and related utilities). It's a train wreck I saw going off the rails over a decade ago. I've got similar fears for systemd. Yes, booting is more complex, some systems (especially cloud deployments) may benefit from expedited startups, dynamic management of devices and services can be a benefit. But off of that in PID 1? And don't even get me started on the logging aspects. I'll be sitting this one out as long as I can.
- DrJ 13y ago
  > (defects found, estimated undiscovered defects remaining) how does one estimate the latter? (Actually curious if this is a known thing)
  - dredmorbius 13y ago
    It's a known thing. Look up "software defect estimation". The methods aren't too dissimilar to how population ecologists estimate the population of a wild animal population (you tag individuals and note the rate at which you're repeated re-tagging the same ones), the estimated total falls out via statistics. It's not a method that's applied frequently even within organizations (I've worked in and with QA numerous times), and my copy of Cem Kaner's Testing Computer Software doesn't seem to address the matter. Boehm's Software Engineering Economics discusses software reliability modelling at page 181 (Chapter 10: Performance Models and Cost-Effectiveness Models). IEEE has "An efficient defect estimation method for software defect curves" which looks like it should cover the area, membership or purchase required: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1245391&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1245391 http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=124539... "Applying Software Defect Estimations: Using a Risk Matrix for Tuning Test Effort", James Cusick, Wolters Kluwer http://arxiv.org/pdf/0711.1669.pdf http://arxiv.org/pdf/0711.1669.pdf BUG COUNT ESTIMATION: http://www.testdesigners.com/bugnets/bugcountestimation.html http://www.testdesigners.com/bugnets/bugcountestimation.html References Capers-Jones, leading authority in the field. Many methods start with an assumption that software coding is essentially a progress of inserting bugs into code at a known rate (and there are studies which have established such rates with fairly high levels of confidence). So debugging and QA are then a bug removal function. Knowing what your bug insertion rate was allows you to estimate how many of those bugs you've removed. That's the theory.

by akerl_ 13y ago

ZeroGravitas 13y ago

That actually strikes me as a more reasonable objection than many I've heard. On the other hand, systemd is actually in use in various places, so bugs are being looked for and found, so this process doesn't begin with Debian's adoption and you're back to balancing probababilities the same as you would with any change.

belorn 13y ago
> Debian's adoption In this case, adoption means moving systemd from being optional to default. Debian has had systemd in use for quite a while now with current statistics at 7.5% of all installation (accordingly to popcon http://qa.debian.org/popcon.php?package=systemd http://qa.debian.org/popcon.php?package=systemd).
- bbanyc 13y ago
  Package names are a bit confusing here. The systemd package includes all the binaries - one of which, logind, is required by GNOME - but doesn't install systemd as /sbin/init and doesn't boot with it by default. The package to do that is called systemd-sysv, for reasons having to do with the special treatment of sysvinit as a "required" package in dpkg. So 7.5% of Debian systems have it installed, but only about 0.3% (plus however many of that 7.5% that are setting init=systemd in GRUB) are using it.
  - ibotty 13y ago
    setting init=/sbin/systemd in the kernel cmdline is the recommended way, so i guess the 7.5% do count as using systemd.

dredmorbius 13y ago

It's quite a nifty case to make, that we can't use a new init system That's not the case I was making. Rather it was oofabz's apparent criticism of sysvinit's security profile based on the fact that bugs were found and removed individually. That's not a particularly valid criticism. There are more valid ways of establishing software quality based on bug estimation (defects found, estimated undiscovered defects remaining). The rate with which init scripts are changed (the fact that they can be modified, possibly erroneously, by individual systems admins is another consideration). A system that's been specifically designed to be resistant to coding and use errors (again: OpenBSD) is better. Some init script systems are better than others, and I've found the Debian scripts to be simpler, cleaner, and more robust than Red Hat's (which use multiple levels of includes and indirection). In the case of systemd, I've found the touted benefits ("faster booting" -- ORLY? I prefer not having to boot/reboot systems), complexity, novelty, and track-record of the primary developer to be quite troubling. Technology is a complexity management system. Much of the problem in the GNOME project comes from failing to manage complexity appropriately (oversimplifying a complex space, creating complex tools with more levels of indirection (gconf and related utilities). It's a train wreck I saw going off the rails over a decade ago. I've got similar fears for systemd. Yes, booting is more complex, some systems (especially cloud deployments) may benefit from expedited startups, dynamic management of devices and services can be a benefit. But off of that in PID 1? And don't even get me started on the logging aspects. I'll be sitting this one out as long as I can.

DrJ 13y ago
> (defects found, estimated undiscovered defects remaining) how does one estimate the latter? (Actually curious if this is a known thing)
- dredmorbius 13y ago
  It's a known thing. Look up "software defect estimation". The methods aren't too dissimilar to how population ecologists estimate the population of a wild animal population (you tag individuals and note the rate at which you're repeated re-tagging the same ones), the estimated total falls out via statistics. It's not a method that's applied frequently even within organizations (I've worked in and with QA numerous times), and my copy of Cem Kaner's Testing Computer Software doesn't seem to address the matter. Boehm's Software Engineering Economics discusses software reliability modelling at page 181 (Chapter 10: Performance Models and Cost-Effectiveness Models). IEEE has "An efficient defect estimation method for software defect curves" which looks like it should cover the area, membership or purchase required: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1245391&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1245391 http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=124539... "Applying Software Defect Estimations: Using a Risk Matrix for Tuning Test Effort", James Cusick, Wolters Kluwer http://arxiv.org/pdf/0711.1669.pdf http://arxiv.org/pdf/0711.1669.pdf BUG COUNT ESTIMATION: http://www.testdesigners.com/bugnets/bugcountestimation.html http://www.testdesigners.com/bugnets/bugcountestimation.html References Capers-Jones, leading authority in the field. Many methods start with an assumption that software coding is essentially a progress of inserting bugs into code at a known rate (and there are studies which have established such rates with fairly high levels of confidence). So debugging and QA are then a bug removal function. Knowing what your bug insertion rate was allows you to estimate how many of those bugs you've removed. That's the theory.