All it takes is the motivation, a group of likeminded individuals and the willpower to deliver a dist that does not use systemd. I expect most packages in the debian universe have no deps on systemd and therefore no work required to support those packages. So we're talking system packages, some daemons and maybe a few shims for edge cases.
You're implying that it would be easy. I'd like to think you're right. One group has already announced such a derivative. I'd love to see it succeed, but I'm not holding my breath. Maintaining a linux distribution as well as debian does, including timely security updates, package builds, downstream bug tracking, release management, and uniformity across so many installations as to form a vast support community, is a much bigger job than one might think. There's also the issue of various unrelated but popular packages developing dependencies on systemd, which means any such derivative distro would also be in the business of developing and maintaining forked versions of those packages; also not a trivial task. I guess we shall see.
As for why there are only 2 dists left not to have gone to systemd, perhaps that should serve as a clue in itself.
Many of them seem to be derivative distros that simply don't want to diverge from their upstream distribution's init system, so they have little choice. (Counting them as independent decision makers would be dishonest.) As for the upstream distros, I think it's more telling to note how very divided their communities were in the vote for/against systemd. A strong argument could be made that anything so integral to the core of an OS distribution should not be replaced with something so divisive to the community.
Speaking for myself, I'm a bit disappointed in the loudest factions of this disagreement. Most of what I see in these discussions is two mobs of people pushing for a decision *right now* (meaning this year, or next). The voices shouting "we need systemd!" or "we need nothing of the kind!" dominate the discussion, while a third option seems to have been forgotten: How about waiting until something can be developed that offers important core improvements over sysv init, but isn't as invasive as systemd? Most of us can obviously get by just fine with our existing init systems for a little longer; we've been doing it for years. The uproar over the topic is surely enough to motivate the development (or modification) of an init system that most of the community would find suitable. I'd love to see that happen.
In any case, I think the original question here has been answered.
This is where the exercise of free will kicks in. If you cannot contemplate learning something new, stick with what you have or choose a dist that chooses to do stuff the old way.
Thanks. You just provided yet another example of the same old fallacious argument. It completely ignores two important facts: The only alternative distributions left are either so anemic in their overall support that they would utterly fail as substitutes (debian's software archive is second to none) or are so different that a migration of any significant size would be unreasonably painful (let's see how long it takes you to migrate 50 machines to gentoo, let alone maintain it with 500 machines). Anyone who makes the argument you just made either has no grasp of the real-world issues, or is being disingenuous.
The reasons for disliking it vary, but there is at least one common thread among those who are upset about it: Systemd is being shoved down their throats, in that several of the most widely used, widely loved, deeply entrenched linux distributions have announced that they are adopting it. Many people who use those distributions do so for very good reasons, and since there are no equivalent alternatives, these people are being forced to either accept systemd (which will cause them unwanted trouble) or migrate to an inferior distribution (which will also cause them unwanted trouble). That kind of thing is enough to piss anyone off.
To anyone curious about Mercurial enough to try it, keep in mind that what git calls a "branch" is called a "bookmark" in mercurial, because "branch" has a more traditional meaning over there.
Git is its own worst enemy
Sigh... Git. Ten years later, and it's still making people suffer with its unforgivably awful user interface. Seriously. I like the command line, and git is my primary version control system, but git's UI is the single most user-hostile example of human-computer interaction that I have had the misfortune to encounter in years. Maybe decades.
Git's command structure is a train wreck of inconsistencies, some of its most important terminology is worse than worthless, and its man pages and built-in help text are idiotically obtuse. I have been following its development closely enough to understand how it got this way. A lot of it has to do with placeholder terms that were never updated, synonyms that were never reconciled, features that were grafted onto existing commands and never properly organized, and its origin as a set of low-level components rather than a tool intended for humans. In other words, a pattern of evolution much like any other software, except for one thing: Even after years of being relatively stable, its mantainers still haven't addressed its glaring usability problems.
These aren't just minor warts that only affect a few people, either. There are countless articles, blog posts, and forum threads expressing frustration with git and detailing specific improvements that could transform it from a usability nightmare to an elegant piece of work. Sadly, the maintainers either ignore them or respond with some half-witted reason to resist change. Frankly, I am embarrassed to see my fellow software developers failing so miserably to recognize the importance of usability, and failing to fix it.
What is the cache? It's a place where you're expected to manually arrange your data before you commit it. Does it function like a person would expect a cache to function? No, but we call it that anyway. What is the index? It's the same thing. Does it function like a person would expect an index to function? No, but we call it that anyway. You're referring to the same thing in both cases? Yes, for the most part. Does it function like anything that might be familiar to anyone? Yes, it's essentially a staging area. Why don't you call it a staging area? We do, but only in the minority of cases. You mean you have three names for the same thing, and the most accurate name is the one that you use the least? Yes. Why? Because the meaningful name might be harder to translate into other languages. So you deliberately use a confusing variety of misleading names when writing in English, the single most widely used language in computer science, because one of your translators didn't want to describe a staging area in another language? Yes. Well, that's probably okay, because this thing is probably some obscure piece of git that most people don't have to use, right? No, it's actually one of git's most distinguishing features, and interacting with it is absolutely required in order to use git. I see.
Newcomers shouldn't have to be encouraged to "take the time to learn git." It should be easy. A programmer familiar with version control systems should be able to pick up a new one in five minutes, and find the answer to most intermediate-to-advanced problems in maybe ten or fifteen. They should be able to walk away for a month or two, come back, and still remember how to use it. That doesn't generally happen with git. One has to invest quite a bit of time and patience to confidently use anything beyond its most basic operations without screwing something up, and stay in practice with it, or else end up having to learn most of it all over again.
The ridiculous thing is that it doesn't have to be this way. Mercurial is real-world proof of that.
I hate git for these reasons. It's a cantankerous bastard of a tool that will just as soon kneecap you as handle your data. I only use it because of github (which is brilliant, by the way.) If you want to see an example of how version control should be done, get to know mercurial. Its internal design is similar to git's, and it can do pretty much everything that git can, yet it has a sane user interface.
Here's an astute bit of satire:
+1 for Gandi. I've been using them for over a decade, and have no plans to leave. They cost more than the dirt cheap registrars, but they're worth it, for all the reasons that heypete mentioned.
They recently adopted a motto that sums them up rather well: No bullshit.
Try finding a Cherry G80-5000. Adjustable split keyboard. Haven't used mine in a long time, because it feels like I can't afford breaking or even just any kind of wear.
Seconded. Mine is labeled "MODELL MX 5000", and others are called the ErgoPlus, but they're all basically the same keyboard. I didn't realize what a high quality device it was when I bought my first one. I've now been coding and gaming on it for well over a decade, and it still works beautifully. Even the flexible plastic parts show no sign of damage.
The split angle is completely adjustable, from very wide to no split at all, so it will fit just about any shoulder width and can be temporarily collapsed for guests.
It has Cherry brown switches. I can feel when they engage, but they don't click, so typing noise comes mainly from the key caps bottoming out.
The numeric keypad is detached (and can be unplugged) from the main unit. This is great for right-handed gamers, because it can be moved to the left side of the keyboard and the mouse can be brought in closer.
I originally bought the Cherry 5000 because it was the most comfortable model in the ergo shop at a reasonable price. After a year of using it and a touchpad, my RSI issues were greatly reduced and I was able to go back to using a mouse. After a couple more years, my RSI issues were gone.
It's a real shame they discontinued this model, and not at all surprising that they sell for $500-1000 on ebay. I'd probably pay that much if mine disappeared. It's the only keyboard I've ever liked, and I expect it to last a very long time.
Here's the list. Seventy-three pages worth.
I don't trust my data with any cloud storage company, because none of them can be trusted.
Most of my data gets backed up to encrypted disks that can be stored off-site.
Data that I need to access remotely, like my phone's calendar and contacts, live on my home server. It runs only the software that it needs, sits behind a firewall, and is updated with security patches regularly. It has a much smaller attack surface than any cloud storage company's data center, and is a much less interesting/valuable target for attackers.
Of course, running a personal server has long been the domain of people who have lots of computer admin knowledge, but that is starting to change. Projects like ownCloud, arkOS, and FreedomBox are working toward making it easy. Low-power server hardware is getting dirt cheap. It might not be long before anyone capable of using a smartphone or game console can set up their own file / calendar / contacts / mail / whatever server for under $100 (including storage).
I doubt it. The situation was the same before the lawsuits and regulatory pressure.
Another option is to get a mouse with a thumb button and map it to middle-click. I did that with my old Logitech, and would probably have done the same with an Anker CG100 if I didn't want an MMO gaming mouse like the G600.
It's really absurd, isn't it? Logitech could win the favor of linux users if they offered something even as rudimentary as a command line programming tool or a protocol spec.
I would have bought a mouse from a company that supports linux, but since I really wanted all those extra buttons, my options were severely limited. The G600 was the least bad option.
In case you decide to buy it, here's the ~/.Xmodmap file I use to swap the middle and right buttons:
pointer = 1 3 2 4 5 6 7 8 9
keycode 78 = Multi_key
(That second line is unrelated; it lets me use Scroll Lock as my compose key.)
The Logitech G600 is pretty decent if you can get used to the larger size and all the buttons on the side. Stupidly, it forbids you from programming the middle button to middle click and right button to right click. You can program the middle button to right click and right button to middle click, though, and then swap the two with xmodmap if you're using linux. You might also want to program the resolution down much lower than the default for linux use. Of course, since it's from Logitech, you'll need Windows or MacOS to program it.
None of the new episodes did much for me while I was watching them, and I can hardly remember anything about them now. J.J. Abrams might make the next one more fun, at least, but I recently learned something about Episode 8 that makes me care about the series for the first time in ages: Rian Johnson is doing it. His most recent work was a mainstream movie called Looper, which was fine, but the two he did before that were astonishingly good. (It would be fair to say that story and writing matter to me more than effects.) I'm not sure whether to be worried that he'll mute his talents in pursuit of mainstream money, or excited that he'll make Star Wars interesting again. Either way, I'm looking forward to finding out.