My point wasn't that Debian is being developed too slow. QA has never been fast.

My point is that Debian nearly always distances itself from the development and the developer community.

In other comment I also mentioned the APT. If Debian was today debating a packaging system, they would never ever opt to *develop* the APT like they did in the past, but they would take the RPM and try to live with it.

Otherwise, just look at two good examples of distros evolving: SUSE Studio and Ubuntu Launchpad. Lots of things which happen there rarely see the daylight - but they allow distro to play proactive role in bringing together the developers and users. (But of course, SUSE Studio and Launchpad are targeted at two different kinds of "developers" - first is for developers of distros and second is for the developers of the software.) That might seem superficial, but it allows distro to actually learn about the new trends and things people are doing with the software. They need much less guessing what/how to do in the next release. OTOH Debian, beside the heavily unreliable popcon, is very very much closed and unto itself.

That distance also plays role in how Debian's decisions are made. You can't roll-out something new and experimental in Debian and expect later it being adopted in Debian main. No. Because Debian wants to have a project with proven track record. And you can't get the "proven track record" *in* Debian - because the project will not be accepted without "proven track record". That is why the development happens in the Fedora, Ubuntu and SUSE. Rarely in Debian.

And why is this on-topic? Because Debian with migration to systemd would in some aspects become Red Hat, which is not something I'm particularly happy about. Because, though RH doesn't develop much of the systemd itself, it does quite a lot of work on systemd integration. Because they played role in its development. They gave the project fighting chance. And all it took for them was to say the developers: OK. At the same time, if you check history of attempts to bring upstart into Debian (which is much longer than the vs systemd discussion), Debian wasted literally years discussing, and mostly dismissing upstart because it was used by only one distribution, despite Canonical's pledge. Result? Red Hat has nurtured the systemd - and Debian has strangled the upstart.

That has nothing to do with the init system. That performance largely depends on the performance of the applications, and to some extent on the performance of the DE. The init system, after start-up, is mostly idle. The "biggest" job it has then is the reaping of the zombie processes.

Yes and no. Mostly no.

Ubuntu uses upstart only to manage the early boot sequence. Majority of everything is still started by the traditional /etc/init.d scripts, with runlevels and whatnot. There are some services which have upstart jobs - but out-of-box they are minority.

I had an installation of vanilla Fedora 20 for couple of weeks. The release where it was said that systemd is properly and fully integrated.

On the same hardware, it did NOT boot or work faster compared to the vanilla Ubuntu.

On average, Fedora was 50-100% slower. Which was kind of surprising, because I thought nothing can beat the Unity desktop in poor interactivity. And that shell-scripted boot can't be faster than the systemd' C boot sequence. And yet...

GNU is not Unix. :)

Emacs is not based on the UNIX.

It is based on the lisp machines.

The lisp machine have died, but Emacs still lives on.

But systemd is written in C. I gather we would have to start by implementing C in elisp.

Emacs OS - I know it is missing a text editor - but does it support systemd?

Compare that to the Fedora. The immaturity of systemd hasn't prevented them from actually giving the users a chance to try the new init system. It actually helped to step up its development. And Red Hat isn't even the top contributor to systemd.

The Debian does lots of good things - but it fails at letting people to help them.

New things are always going to lack "tangible code and some track record". And the Debian is the wrong place for a project to try to get one. And that is the biggest problem of the project, IMO.

It is not a minority. It would become a overwhelming majority when the systemd would actually be installed on the majority of the systems. But it would be too late then, of course.

I probably shouldn't care at all. Systemd would never appear on the systems I work with. For the simple virtue that it is, with the dozens of other "supervision" frameworks, is simply redundant, primitive junk, which is only capable of starting and restarting the Apache server (a.k.a. "hello world" type of service, with no real (distributed networked) dependencies and one bit of state (running/not running)).

The Ubuntu LTS releases, are pretty much what I always expected from the Debian.

The difference is that Ubuntu isn't afraid to put time of developers into the release.

While Debian insists on simple repackaging.

I'm sorry to say it, but Debian has already been a "whore" to lots and lots of other distros, even before Ubuntu hit it big. For the fact of having no distinctive technology of their own.

Recall the time when the APT was ruling. Back then, the Debian ruled. APT had set the bar for other package management systems. People followed the Debian. Now? Not so much. Debian is following and has been following for many many years now. They are not distro per se - they are the distro factory, other distros build up on. I gather that makes it a "whore" distro.

Blaming Ubuntu misses the point. Because Ubuntu does much more than just repackage the Debian. The bigger question is: why Debian hasn't evolved into something like Ubuntu is? Where's Debian's launchpad with the PPAs? where anybody can develop new things? where from users can easily access the new things?

To me the most enlightening - and saddest - moment of the init system selection discussion was when Debian leadership quite clearly stated that they are not interested in something being developed in-house, they are just distro which packages somebody's else work.

After so many years, I have finally understood why Debian is constantly rises, hits the plateau, freezes for few years in shock and tumbles back down. They want to be just a distro. They do not lead - they follow. They do not create standards - they adopt them. They do not develop stuff - they just repackage someone else's stuff.

That again was one of the driving factor in picking the systemd over the rest. With systemd, somebody else is doing all the work, while Debian just repackages it.

Is fork a good idea? There is no fork, really. Debian is nothing but an organization, a community. One can clone the repo - but one can't clone the community.

Take out from all of this? There are no reasons to worry. Nothing really changed. Debian is simply following the rest of the distros. I'm simply hopeful that they would manage to integrate the systemd nicely. If not... It's not like it would be the first time Debian released something broken and unusable. (Oh, yes, there might no RC bugs - but the (too old/too new) versions of the software, or their configuration, simply make it useless. And trying to change it - breaks it.) That's why we have the Ubuntu, after all: it's like Debian, but not striving for some committee set goal - instead striving to be just useful.

I take it then you are not admin - or a lowly paid one.

"new code" + "tons of bullshit" = reasons to ask management for more training, more hardware, larger IT budget. Then learn some the new obscure POS and become literally irreplaceable. Every new release - another new obscure POS - and people get a chance at a nice career.

And most importantly, since RH rewrites all the stuff every time, you do not actually need the Linux experience per se. Sometimes it is even counterproductive, since RH likes to patch stuff in some freaky way. It was for quite some time now with solutions where RH products were used: "People with extensive Linux experience don't need to apply."

Just like it was in the good ol' UNIX times.

Not, if you measure "the progress" by the revenue/profit.

Copyrighting APIs makes no techinical sense, while copyrighting maps and manuals does.

The only thing remotely plausible is patenting APIs. And even that I'm not sure technically feasible.

I've witnessed probably man/centuries of wasted efforts due to crappy APIs - and I've seen single-person projects springing to life and seamingly leveling mountains when the available APIs were good.

Some APIs fit the puzzle of any applications - some force projects as a whole back to the drawing board.

No idea. But the sound works real real good!!!

No PulseAudio, no "committee design" ALSA - the proper OSS.

Low/no jitter - clarity and definition of sound you can't experience under Linux.

If you have hi-fi/better connected to the PC, and your sounds card is supported, you owe it to yourself.