Shuttleworth: Losing graciously

How could an Ubuntu boot be so different from everybody else boot that it would require work not already done by other maintainers in other distributions?

The tedious work of porting all the init scripts to systemd service units has already been done. I really don't understand where work remains apart from testing that it actually work.

If Ubuntu didn't want to provide the systemd-sysvinit package which makes /sbin/init (and related) a symlink(s) to systemd's binary... that's reasonable.

But choosing explicitly to not give users the ability to even install the systemd binary to even play with it as an alternative using the kernel commandline arguments to choose the init... that's clearly a punitive decision meant to keep Ubuntu users from having the option. Having the systemd binary on disk in no way impacts the ability to provide a rock solid default experience at all...for any release...whether it be an lts or not.

However, splitting out the systemd-services package as a new binary package in Ubuntu instead of providing the systemd package and then deliberately leaving out several binaries under /lib/systemd/ was unwarrented by any technical reason whatsoever. When Ubuntu introduced systemd-shim in Ubuntu they should have figured out how to use the packaging system correctly for shim and systemd to be parallel installable or have the packages conflict instead of preferentially maiming the systemd implementation as packaged to force a preference for shim. I mean,holy crap man, there is a whole alternative system already in place to handle the complexity of this sort of parallel installable replacement if a single packaging Conflict is deemed unworkable. Delibrately ripping out bits of competing implementations from inside well constrained directory namespaces inside packaging is a horrible horrible hack and terrible packaging management policy. Terrible. Just yuck. If -shim as a fork of the code base needs to be installable.. then fracking namespace it as a fork and treat it as a fork and make the fracking competing implementations conflict at the packaging level.

But now that Ubuntu maintainers have _finally_ deemed it worthwhile to get shim into Debian, the Debian maintainer collaboration will sort out how best to support -shim as an alternative without horribly maiming systemd packaging in the process of making a space for shim. You know, the hard integration work Ubuntu punted on actually doing when introducing -shim. And Ubuntu will _eventually_ get to benefit from that much better packaging work. It's really a shame that Canonical doesn't make it a policy to push changes into Debian first and benefit from clean merges as a way to minimize exact this sort of thing from happening as was seen with -shim.

And I have to say the accusation that I'm not doing research rankles a bit. I've probably done more research than anyone in this discussion (other than the systemd developers who I'm sure have a much better understanding of init systems outside of linux than I do currently). But there's always more research to do. Until I get greenlighted for the Google neural implant, I expect there will be gaps in my knowledge. Please, if you would be so kind as to provide me some pointers to material to read up on that would give me a better understanding of the technical issues in the decision which necessitated explicitly removing /lib/systemd/systemd and /bin/systemd from the deb packaging in Ubuntu as inherited from Debian when Ubuntu decided to disembowel the Debian packaging for systemd.

My understanding is the exact opposite. Most of the installable services in Ubuntu are still controlled by sysvinit scripts and have not "gone native" and picked up a unit file in their packaging. What has gone upstart native is early boot for required services up to mounting and a very narrow set of services that make up the very narrowly defined desktop boot configuration for the Ubuntu desktop default (and not even everything one could consider desktop relevant either).

But please, prove me wrong. Can you provide me with a full list of packages in the Ubuntu repository which drop files into /etc/init/ as compared to the full list of packages which drop files into /etc/init.d/ so we can make an accurate judgement as to where upstart native unit file adoption actually stands.