I've been wondering the same thing and trying to interpret the decision.

As far as I can tell, what it means is "the status quo we already have today".
systemd is already the Default init system in Debian and has been since Debian 8 (Jessie). The decision specifies that the maintainer has the choice of delivering an init script and/or a systemd service file, i.e. it's the maintainer's choice what to support and how, which is the way it was already. So as far as I can tell, this decision doesn't give any additional guidance nor has any particular other requirements than before.

The one change this does seem to make is that maintainers have the option to adopt systemd-specific features such that packages may not be able to work with other init systems.

Ian Jackson has some analysis of the various options that were available for the vote, and a link to these was sent to the [debian-devel] mailing list:
https://diziet.dreamwidth.org/...

I like it, and I plan to implement it. Thanks for the idea.

I didn't understand the following statement:

I don't understand this as-is and I've re-read this a few times trying to figure out "what you probably meant instead" and haven't been able to figure that out either. If you wouldn't mind, please respond with a tad more detail so I can try to understand better. Thanks.

I agree; sharing of data online should be an opt-in operation rather than something that for the most part cannot be completely opted-out-of. Microsoft's EULA allows for sharing any data they collect with third-parties, and there are reports that they already have and are continuing to do so. There are those that are proponents of what Microsoft is doing, saying that it's "good" for the OS, however if any open-source operating system were to do what Microsoft is doing, it would receive a lot of criticism for sharing data without opt-in consent.

There is some relief to be had however: on Windows 10 Pro and above the Telemetry service can be disabled. The service is named "Customer User Experiences and Telemetry". Look in "Administrative Tools" in "Services" and stop + disable it. The way to verify that the service is disabled is to look at the hidden folder %Program Data%\Microsoft\Diagnostics before-and-after stopping and disabling the service; before stopping the service the encrypted files there cannot be deleted because they're "in use", after stopping the service the files can be deleted and don't return.

There are firewall rules concerning the "Customer User Experience and Telemetry" service that can be disabled too -- but (from what I've read) supposedly disabling these rules won't block the service from the Internet. i.e. similar to how some sites cannot be blocked via "hosts" file entries because Microsoft has hardcoded certain names/IPs in their DNS resolver, supposedly there are certain hardcoded bypasses to the firewall as well.

It's possible to get Windows Update working over Tor, BTW. Windows Update unfortunately only understands an HTTP proxy, not Socks5, so another proxy (such as Privoxy, which is open source) is required to forward traffic to Tor via Socks5. Windows Update follows the proxy set by 'netsh winhttp set proxy IP:PORT;exception_list' (which requires being run from an Admin command prompt). Then firewall rules to block all traffic not coming from the Tor daemon. Verification via packet sniffing or via 'Tcpview' from SysInternals. Unfortunately what I see after all that is there is still some System-level traffic that accesses the 'Net directly, i.e. bypassing the firewall, so this still doesn't seem to be 100% trustable. (Not that it could be, anyway, given that Windows is not open source.)

Edward Snowden has been charged under the Espionage Act which presents an impossible burden to defend one's self against.
https://en.wikipedia.org/wiki/...

This is discussed some by defense lawyers during the movie Citizenfour.
http://www.imdb.com/title/tt40...

This is the GR:
      https://www.debian.org/vote/20...

the intent of which was to insure that alternate init systems continued to work, not to remove packages that didn't support that. Making a bug RC could potentially cause a package to be removed if the bug was ignored and unfixed, but any DD can NMU the package to fix an RC bug at any time, so packages like Xfce4 being removed as a result of an init system RC bug is fairly unrealistic IMHO.

Yep, I tried my best to install Xfce4 without systemd... that didn't go well, even on a desktop system. KDE can run without running systemd as the init system as well but exhibits several annoying quirks -- it cannot tell when the system is internet-connected, so for instance KMail2 will instantly try to get mail on login and then complain for every account that the connection fails.

I'm bummed that Ian's GR concerning init system equality failed, which means that going forward systemd is the only init system that has to work in Debian, because devs have the option not to care if changes to the packages they maintain break other inits. (Hopefully that won't happen, but based on what I've seen devs say in [debian-devel] I'm not terribly hopeful.) I'm also bummed that Debian had to drop the kFreeBSD port as an official port for Jessie. Ugh.

So yeah needless to say this transition is ... rough.

I've been a Debian user since late 1999 and I very much sympathize with what you've said here. Over time I've gotten increasingly deeper into Debian, and I also find I have some nagging issues with systemd that I didn't have under sysvinit/sysv-rc. Thankfully I've never been a heavy Gnome user, but I've been testing Gnome 3, Cinnamon, and MATE lately, and find that I heavily dislike the current Gnome 3 in Debian Jessie, can deal with Cinnamon, and like MATE the most of the three. Agree re: Firefox/Iceweasel, though I can still tolerate it's current version in Sid.

The biggest problem I have with systemd isn't on the technical side but rather the social side; the issue has been very devisive -- no other issue to date has set groups against one another in such a heated way in some time now. A number of Debian developers have quit or dropped out of teams over it, let alone the heated threads in [debian-devel] about it.

Right now my short-term plan is to ride out the Jessie release by sticking with sysvinit on servers but use systemd on desktops to gain more familiarity with it. I don't have any plans to switch to FreeBSD, and I'm upset that Debian dropped the kFreeBSD port from being official for Jessie. :-/ It would have been nice to have that as a fallback.

Re: Debian Testing -- the stability of Testing has been the issue of ongoing discussions at DebConfs so unfortunately this is a known issue. I can't say I know all of the reasons behind this problem, but I think one of them might be the automatic removal of source packages within 30 days that have RC bugs, and another being that transitions from Sid -> Testing can be such that source package versions in Testing can be out-of-sync compared to Sid. So the irony is that Sid / "Unstable" is actually more stable than Testing, almost all of the time. Sid doesn't get support from the security team though, so I don't consider it good for servers. So because of this I avoid Testing altogether, and run Stable for servers (and "customer" desktops) and Sid for my own desktops. That seems to work except of course that I run into some frustrations with packages for Stable being a bit old.

Anyway -- good post. Best of luck in whatever you choose to use for your free OS.

systemd is "optional" in Debian Jessie in that it's possible to uninstall, but systemd gets installed by deafult in Jessie, and it's also not easy to remove depending on what you're looking to run on the machine. Gnome depends on systemd heavily, so I'm not even sure if it's possible to remove systemd without removing Gnome. I've tried to run a Jessie system without systemd installed and it's ... difficult. You can have systemd installed without using it as the PID 1 init, but that too leads to unexpected behavior. Both Gnome and KDE have been built today with the assumption of systemd being PID 1, Gnome depends on logind to be able to log in, and so on.

The other init systems still work for now in Jessie but the GR [General Resolution] that Ian Jackson from the Debian Technical Committee started to declare that keeping the other init systems working was RC [Release Critical] was voted down, which means that systemd is now by default considered the only init system that has to continue to work. Because of this GR's defeat and the backlash on Ian for bringing it up, he's since resigned from the Debian-TC which I think is a great loss. :-( (My big thanks goes to Ian Jackson for his work within the Debian Technical Commttee.)

I haven't yet tried OpenRC outside of VM but IIRC in the VM it worked fine for me. Unfortunately the OpenRC packages (and documentation) in Debian were not in good shape at the time fo the Debian-TC discussion and decision on the default init system for the Jessie release.

Ian Jackson is a man of principle, and the way the final vote was done within the TC [Technical Committee] was certainly objectionable: he was in the middle of discussing what should be on the ballot when Bdale Garbee called for an immediate vote on the same subject but with a totally different ballot. Then when the vote came to a tie, Bdale used the "casting" vote, meaning he had two votes where all the other TC members had only one. Furthermore Bdale's friend and close business partner Keith Packard had just recently joined the TC.

Furthermore this GR [General Resolution] isn't about reversing the TC decision nor in changing the default init system for the Jessie release -- it's about giving the other init systems a fair chance by making them possible to use by making the bugs in packages causing them to break RC [Release Critical]. That's all.

And he did bring this GR up in March, but at that time the Debian community was more hopeful that support would continue for the other init systems, but instead support for everything else has waned -- Ubuntu immediately decided to switch to systemd and drop upstart, and there have been issues with support for other packages concerning the standard sysv-rc init -- all of which Ian had expected to happen.

The main objection from Debian developers concerns the timing of this GR only because the Jessie release is nearing, but ... Ian did bring this up in March...

The C64 power supply used a 5v linear regulator rated for 0.2A - 0.3A less current than the C64 itself drew through it, so the part would have premature failure because it was underrated. Apparently/supposedly the difference was expected to be dumped as heat, and the supply was potted which made it very difficult to get to the part that failed and replace it... but doing so was necessary because the replacement supplies had the same design flaw. I did that replacement and after doing so the power supply looked terrible (I left it ripped open), but with a linear regulator that had a sufficient current rating it never failed again (whereas the replacement supplies all did).

Putting the power supply in a refrigerator sounds terrible (but dedicated), but then, so was the "correct" fix. ;-)

Yes, the C64 power supply was potted -- and after digging through it what had to be replaced wasn't a fuse, it was a 5v linear regulator. The problem with the C64 power supply was that the Linear regulator was designed for 1A, but Commodore was using it to pass 1.2A. This shortened the life of the part, and when it failed it required a huge effort to dig through it to find the part that was bad and replace it.

But I did exactly that. And unfortunately one generally had to do that if they wanted to end up with a reliable supply, because the replacement supplies had the same design flaw and would thus fail in the same way. Once I replaced the 5v regulator with one that was rated for 1.5A, it never failed again. :-)

Well, I was speaking of modularity in design terms, not about dependencies per se. Vista and above are known to be "more integrated" than previous Windows versions, and simultaneously nowhere near as modular for the base OS as most Linux distributions. [And as such I agree that dependencies are a bigger issue on Linux than Windows. ;-)] What I'm getting at is that on Linux a bug such as the OpenSSL problem can be quickly narrowed down to a particular package, whereby the code that needs looking at for a fix is much smaller that way. On a more integrated system the source of the error is likely harder to find, and once found more complicated to fix, than a modular system.

However this is speculation on my part, as I'm not familiar with nor involved in the design of Windows OSes, nor have I looked at any of the Windows source code, and I also don't otherwise have a way of making a "Linux vs Windows" side-by-side comparison.

This is probably obvious, but the larger they get and the more "integrated" their system is (i.e. I'm thinking of the new level of system integration with Vista versions and above), the slower they're likely to be able to create correct fixes. I don't know this for a fact, but it seems as though the Windows system itself isn't terribly modular compared to other systems (Debian Gnu/Linux for instance) that have packages and dependencies. On a modular system focus can be placed on the "one package" that has a problem (if you can debug the issue down to the package level), but on a very integrated non-modular system where the source code itself is a guarded secret, that sounds like a difficult problem to deal with.

I wouldn't call "erorr 800F0092" to be a "clean" error code -- more like a bizarre confusing unintelligible error code. The errors in Linux can sometimes be frustrating too, or might even be hidden in a log like you pointed out, but they're never designed to be as unintelligible as many of the Windows system error messages are. On Windows there seem to be two kinds of error messages: ones for developers and ones for users; "error 800F0092" vs "check the cable", and there doesn't seem to be a whole lot in-between. At least on Linux systems you get a full range of them. ;-)