Not at all. How would you build for all those architectures? The infrastructure, etc. are staggering.

Also, not having Docker would be a good thing.

Assuming that you wanted to keep any fork/derivative alive you'd need to rely on volunteers. On that basis you'd probably do the "obvious" thing - create the AMD64 version, and then work from there as/when volunteers interested in other architectures arrived.

Infrastructure would be hard, but not impossible. Either you pay for it, or you solicit donations/sponsorship.

Docker I like, I could live without it, but I wouldn't choose to do so. Yet.

IMHO, forking Debian just for the pleasure of forking is of (almost) no interest, if one is not able to offer as much stability and support as Debian is able to offer today, even if it is on only one architecture.

I agree with you that forking Debian outside of base+server stuff has no point. But, still IMHO, the main point of using Debian today on servers is the strength of the stable release and the fact that there is a good security team. Forking Debian without being able to offer such level of support still sound madness to me.

I am not a Debian Developer even if I use and follow it (on many host) since around 1994 (from i386 hosts to sparc stations, at the beginning, to amd64 and some arm today). I really regret not having jump into the wagon and tried to be a DD at that time (but well time was missing and maybe confidence too). I really like Debian, but as an external observer, and as lot of people, I dislike what is happening today.

I agree with Joey Hess when he says that the formal constitution was probably a bad move.

Anyway if one want to fork Debian first thing is to state why, and to explicit what has to be avoided in the fork which is present in Debian and should not be.

All that to come to my question : what is the main trouble with Debian today in your eyes ?

I have no personal interest in a fork, I've just spent some time thinking about how such a thing could be done in a way that might have a chance of surviving.

I imagine such an endeavour would take a lot more time, effort, and resources than anybody undertaking it would suspect. But equally I'm sure that with a decent base of volunteers it could be done.

I do have concerns about Debian, and the way things are working out, but I do not wish to document them at this time. The only thing I'll say is that it is not a coincidence I've been experimenting with other distributions recently, nor is it a coincidence that I'm submitting a comment from this OpenBSD-powered laptop.

Steve, the very fact that you look at other distributions and operating systems is very useful to Debian. Without that look outside, one just cannot have a solid understanding how to improve Debian.

Thank you for sharing these ideas, since this has been on my mind all day and I've been too tired to really sit down and think much about it myself.

So the release team didn't accept kfreebsd into jessie. We may need to do some of the things you mentioned here, ourselves, if we're going to make a stable release out of it. Especially the infrastructure for stable/security updates.

Happily we do have most of the essential software packages you listed. (And BSD jails, and propellor by joeyh even works on kfreebsd to do something similar to Docker). But it may be difficult to keep sid/testing working if breakage on kfreebsd doesn't have RC severity any more. It could also mean greater dependence on systemd, if it'd be no longer a requirement to support kfreebsd. I think unofficial package builds with portability fixes would become necessary eventually.

I'm sympathetic to some users' concerns about systemd (it's unfortunate the arguments became so hostile). I think what many people would like is an updated, supported stable release for their existing systems, which would otherwise break if they were migrated to systemd. Or some people would like to avoid it on new installs too.

That there's so much conflict in Debian right now is really sad; I think there must be some organisational change that could let teams each work on the things they want to do. For example - dropping GNOME from kfreebsd was IMHO a really positive step because there was so much conflict between each team's goals. So long as we have other desktop choices, GNOME isn't essential; I don't want its maintainers burdened with a requirement to make a new upstream release build and work on every official port, to be able to migrate into testing and part of the next Debian release.

I hope there's a solution to all these problems that doesn't involve a complete fork of everything. For kfreebsd we may only be 'forking' the release part: produce install media, provide repositories for stable/security updates. There ought to be a way to similarly release a linux+sysvinit blend/derivative too. Probably other non-official ports should be trying to do releases and produce install media too. We don't even need to follow official Debian release schedules, which could allow for interesting choices like long-term stable, or shorter release cycles.

I don't think a small group could handle this. You mention e.g. "Python" in your list. Is this the Python interpreter? Or the 2000 or so Python modules in Debian? As a Python software developer, I like the fact, that most Python modules I ever needed, where already in Debian. I packaged a few more. Being forced to use pip (or npm or gem or whatever) for software development would be disservice.

Personally, I would not even look at a server-only OS, because the thing I like most about Debian is (after the freedom thingie), that we use it in the company for the embedded systems we produce, on the laptops of the hardware and software developers, and on the servers. The "universal OS" slogan really got me!

FWIW I added python randomly - as I tend not to use it.

I was mostly concentrating on deamons and services which could be accessed remotely when I made my initial partitioning. I suspect that some deamons will require python/perl/lua/whatever to be useful but I hadn't really gotten as far as thinking of "daemons", "libraries", "devel", etc. Beyond explicitly ruling out "desktop".

FWIW I think that it's in Debian's interest to help ensure forking is possible and as easy as possible. It's probably important that this is done from time to time to make sure things are working.

However, and although I think the anti-systemd fork is just anonymous hot-air, I do find it amazing that there are people who may be prepared to spend the time to do a fork for such a reason, but such people cannot grasp that Debian has committed to supporting multiple init systems, and we lack people actually being prepared to test and file bugs for upgrades, installs etc. of the non-default choice. There's plenty of opportunity for people to contribute constructively to Debian to ensure that continuing to use sysvinit is a smooth experience.

Can I just post here: GOD DAMN RED HAT AND THEIR SYSTEMD CANCER. OK, I'm done now. This whole thing could have been avoided by better leadership. Poettering should just leave. Whiny Pulse Audio systemd garbage code man.