Don't panic and keep forking Debian • Hacker News Board

Re: Don't panic and keep forking Debian

#111

Post by the_why_of_y » Sat, Nov 29, 2014, 10:51 AM UTC

SwellJoe wrote: post #84

EdwardDiego wrote: post #61

Earlier quoted context omitted.

Linux doesn't dominate the mobile environment. A very specific port of it, by Google, does. Given that it's Google , that's hardly a compelling argument. They could've made Windows NT dominant if they'd so desired.

The comment I was replying to suggested that the diversity (the forks) of Linux were the reason Linux would never win the desktop. I made my comment to make two assertions: First, that the desktop is irrelevant today because more people use phones and tablets, and the spread will continue to grow. Second, that the forkability of Linux made it possible for Android to exist...and, to practically destroy every other com…

It's also interesting to notice that Android is developed in a fundamentally different way to the myriad of mutually incompatible GNU/Linux distributions: Android is developed in cathedral style by a single centralized organization that is able and willing to define categorically the APIs that ISVs can target and keep them stable.

This is a huge factor for its success, considering all previous efforts of coordinating distros (e.g. LSB) pretty much failed.

Re: Don't panic and keep forking Debian

#112

Post by krylon » Sat, Nov 29, 2014, 11:30 AM UTC

Ded7xSEoPKYNsDd wrote: post #107

frozenport wrote: post #94

Earlier quoted context omitted.

Some things on Linux were broken from Day 1 like drivers and X because it they were easier. I doubt a coherent team could have fixed these without rewritting which taks too much time. It took MS 6 years to make XP into Vista, I doubt OSS people operate on that kind of timeframe.

XP to Vista took 6 years because MS had huge plans for Longhorn. It took some time to build these things, then some more time to decide they won't be ready any time soon and throw them all away.

In all fairness, they did not throw all of their plans away - some of the more visible ones, like WinFS, yes, but from what I know, they reworked a lot of Windows' internals going from XP to Vista/7, like the audio and the network stack.

They also made important changes regarding security that at least made it more difficult to exploit bugs in more recent versions of Windows.

And, having personally almost no experience with Vista, the changes they made to the GUI between XP and Windows 7 are, IMHO, rather nice in terms of actual usability.

Also, Vista development got stalled big time when Microsoft first pulled out a substantial part of the Longhorn team to work on XP Service Pack 2, and then decided to re-base Longhorn from XP to Windows Server 2003 (R2?).

The net result was, of course, still a system that took much longer than planned and ended up being a huge disappointment to pretty much everybody, even by Microsoft's standards.

But if you consider Vista a "public beta" of Windows 7 and compare XP to Windows 7 side by side, I think - as far as Windows systems go - Windows 7 was actually a big improvement. (Not only on its predecessors, but also on its successors, as they saying goes.)

Re: Don't panic and keep forking Debian

#113

Post by krylon » Sat, Nov 29, 2014, 11:31 AM UTC

frozenport wrote: post #94

eloff wrote: post #5

The same freedom that leads to all the many, many flavors of linux gives a great diversity of ideas. The downside is it fragments the finite development efforts of the contributors to the point where it becomes difficult to compete with the wider marketplace. I wonder sometimes if it were possible for everyone to contribute to one linux desktop if the situation would be different today. As it stands, after nearly thr…

Some things on Linux were broken from Day 1 like drivers and X because it they were easier. I doubt a coherent team could have fixed these without rewritting which taks too much time. It took MS 6 years to make XP into Vista, I doubt OSS people operate on that kind of timeframe.

Well, except for the Perl 6 project.

SCNR.

Re: Don't panic and keep forking Debian

#114

Post by the_why_of_y » Sat, Nov 29, 2014, 11:38 AM UTC

chubot wrote: post #56

lelandbatey wrote: post #25

Earlier quoted context omitted.

You seem like someone who's used a variety of init systems, so I have some questions: 1. Why is systemd considered "un-unix"? 2. Why is sysv considered to "follow unix"? 3. Can you provide or point to some explanations on the ideologies that motivate the difference of opinions regarding sysv/systemd? 4. Really, can someone provide some context and history for all this?

Those are good questions, but answering them won't fit in a comment. It takes more like a book. One of the best books on the Unix philosophy is "The Art of Unix Programming", which is available for free. (I recommend getting a hard copy and reading the whole thing.) http://www.catb.org/esr/writings/taoup/html/ Other books include The Unix Programming Environment by Pike et. al., though it's less explicit about the ph…

> systemd breaks the Unix design style because it's monolithic: > But the problem is that all the binaries are released together, without well-defined interfaces.

So are Xorg and Apache HTTPD, which break module ABI with every release. Postfix and qmail are also monolithic (according to your reasoning), with a modular implementation of multiple processes but no stable interface between them. If you replace of the postfix processes with one of the qmail processes you won't get a working MTA.

Not to mention the Linux, FreeBSD, Solaris etc. kernels themselves.

Why is it then that we see this argument only used against systemd, when your average Linux distro install is primarily composed of software systems that you would consider to be monolithic?

> Moreover they are also tightly coupled to kernel features.

sysvinit is also tied to kernel features: it won't work without Linux procfs.

> dbus is this weird text/binary RPC-ish mix which is not documented.

No idea where you got that idea, is this D-Bus protocol documentation is a figment of my imagination?

http://dbus.freedesktop.org/doc/dbus-specification.html

Re: Don't panic and keep forking Debian

#115

Post by dredmorbius » Sat, Nov 29, 2014, 1:37 PM UTC

JoshTriplett wrote: post #65

On the one hand, this seems wildly misguided; the Debian distribution for people who don't want to run systemd is still just Debian, and that'll remain the case through at least jessie, and for as long as people continue putting effort into keeping it working. So it's sad that the effort going into this fork doesn't instead go into maintaining the necessary infrastructure in Debian. I'm sure the maintainers of system…

There are several arguments I can see in favor of a fork.

1. Ensure that there will be a systemd-free variant of debian even beyond jessie.

2. Provide a tangible metric of the interest in such a variant.

3. Provide a platform on which alternatives to systemd can be developed and promoted. After all, systemd it must be said, addresses some legitimate concerns, largely concerned with service tracking and a generally far more dynamic computing environment. The recent Future of FreeBSD presentation by Jordan Hubbard is actually one of the more eloquent arguments in this light (noting that FreeBSD is both Not Linux and Doesn't Have Systemd).

The primary argument against forking is that it divides efforts. My counterargument is that forking makes the existing divide between views on a given approach tangible and explicitly visible. Free Software, particularly under the GNU GPL or equivalent copyleft, also explicitly preserves the right to merge projects which have forked, as has in fact been the case in several notable instances -- GCC/EGCS, the long-running TK

For a specific study of the topic, see "A Comprehensive Study of Software Forks: Dates, Reasons and Outcomes" by Gregorio Robles and Jesuus M. Gonzalez-Barahona

http://flosshub.org/sites/flosshub.org/files/paper_0.pdf

It cites: GCC/EGCS, xpdf/poppler, GNU Emac/Xemacs, the numerous OpenOffice forks, X.org/XFree, NetBSD/OpenBSD, Wireshark/Ethereal, Gerequi/Amarok, MySQL/Miriadb. In total the paper explores some 220 forks, analyzing them by software area (e.g., networking, web apps, development, etc.), year of initiation, and reason. "Technical" accounts for the most at 27%, "differences among technical team" is sixth at 7.3%.

Resolution of forks is of particular interest:

Successful branching: 43.6%

Discontinuation of original: 29.8%

Discontinuation of fork: 13.8%

Discontinuation of both original and fork: 8.7%

Re-merging of fork: 3.2%

Other: 0.9%

As a critic of systemd and proponent of the concepts of Free Software, including the Freedom to Fork, I'm in support of this and similar efforts.

Re: Don't panic and keep forking Debian

#116

Post by GFK_of_xmaspast » Sat, Nov 29, 2014, 2:39 PM UTC

chubot wrote: post #76

GFK_of_xmaspast wrote: post #70

Earlier quoted context omitted.

Eric Raymond is not worth taking seriously except as a bad example. That aside, poking around I found this: http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... which looks like reasonably well-defined interfaces? Also not really seeing the problem with a binary protocol, works fine for tcp/ip.

If you don't think the content of that book is relevant to the systemd debate, then you haven't read it. I'd like to see you point to a better book about the Unix philosophy. http://en.wikipedia.org/wiki/Ad_hominem

I've been using unices for over 20 years now (first was ultrix, then truos, sunos, solaris, hpux, aix, linux, netbsd, freebsd, osx) and I don't believe there is such a thing as a unix philosophy.

Re: Don't panic and keep forking Debian

#117

Post by digi_owl » Sat, Nov 29, 2014, 3:03 PM UTC

Ded7xSEoPKYNsDd wrote: post #108

pekk wrote: post #77

Earlier quoted context omitted.

Removing coupling which effectively mandates the use of systemd is a prerequisite for "init-freedom". You can't offer a choice when everything requires systemd.

Compare to Gentoo. Gentoo defaults to their homegrown OpenRC. But Gentoo is all about choice and so systemd is an option and works perfectly well. That's "init-freedom". If someone doesn't like systemd and removes it from their distro, that's OK with me. But calling that "init-freedom" seems weird. Maybe they should call it something like "sysv-freedom", if that's what they mean.

Sadly the one thing that dissapears in this debate is that systemd has long since gone beyond being a init.

For me the whole thing came to a head when i learned that consolekit (a bothersome thing on its own) was depreciated in favor of logind. And logind is tied to the hip of systemd.

There are also issues like journald that you need to have running even if your primary logging facility is syslogd etc.

At this point in time, systemd as init is just a minor part of the issue in my opinion.

Re: Don't panic and keep forking Debian

#118

Post by digi_owl » Sat, Nov 29, 2014, 3:11 PM UTC

gone35 wrote: post #98

gilgoomesh wrote: post #48

Earlier quoted context omitted.

systemd replaces a large number of startup and utility programs (specifically: sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd). It also adds new daemons for logs, logins, locales, hostnames and a few other services. Most of this is a good thing. Faster. Newer code that is easier to maintain. Less reliance on shell scripts favoring declarative config files instead. But change has lots of difficulties…

But there are other objections from people who think systemd is too big in scope or too controlling or focussed on one technology or another or... some kind of conspiratorial trap or something ( http://boycottsystemd.org ). I think these arguments are a little hyperbolic since systemd isn't actually a single monolithic system and is really an overarching project to update a lot of major system utilities. Well, with r…

Sadly it drags the whole debate into an argument over semantics. Yes, it is not monolithic in the sense of one binary running everything. But at the same time everything ties back to systemd running as init.

This in effect makes everything under the systemd umbrella tightly coupled. Can i run journald on its own, or logind, or resolved, networkd? As long as the answer is no, they mays well be one big blob.

And it is presented as such as well from a source point of view.

http://www.freedesktop.org/software/systemd/

There is no separate tarball for udev, journald, logind, or any of the other *d's that make up the systemd project.

Re: Don't panic and keep forking Debian

#119

Post by anonbanker » Sat, Nov 29, 2014, 3:12 PM UTC

johnny22 wrote: post #91

anonbanker wrote: post #69

I've been waiting for this fork. It means I can install a .deb-based distribution again. Here's hoping this is as successful as Libreoffice or X.org has been.

huh? this is the first release to really require systemd. how could you have been waiting for a fork when one wasn't even necessary until a release that isn't even marked stable yet.

I've been waiting approximately 180 days for this fork. it's been over a year since the General Resolution where systemd got voted on.

the fork, for some of us, has been necessary since we saw how toxic the debian constitution was in practice.

Re: Don't panic and keep forking Debian

#120

Post by digi_owl » Sat, Nov 29, 2014, 3:16 PM UTC

ahomescu1 wrote: post #96

gilgoomesh wrote: post #48

Earlier quoted context omitted.

systemd replaces a large number of startup and utility programs (specifically: sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd). It also adds new daemons for logs, logins, locales, hostnames and a few other services. Most of this is a good thing. Faster. Newer code that is easier to maintain. Less reliance on shell scripts favoring declarative config files instead. But change has lots of difficulties…

> systemd replaces a large number of startup and utility programs (specifically: sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd). It also adds new daemons for logs, logins, locales, hostnames and a few other services. > But there are other objections from people who think systemd is too big in scope or too controlling or focussed on one technology or another or... some kind of conspiratorial trap or…

More correctly, you can't just use networkd as your dhcp client unless you have systemd as init. You could however use dhcpcd on top of systemd (tho the latter would likely make a lot of noise about "missing functionality").

And that is the insidious nature of it all. the *d's panders developer laziness. What do you do when some production critical piece of code demands networkd, logind, or any of the systemd sub-daemons? Do you look to replace it, or do you roll over and replace whatever already functioning init you have with systemd?