Users/Developers Threatening Fork Of Debian GNU/Linux

[bobwya]

The Gentoo option to switch between OpenRC and systemd is an elegant way to address this problem. I've been using systemd on Gentoo for a couple of years. It was a somewhat rough ride at the start (like infiinite shutdown times, etc) Over time I have to say I have come to really like systemd. It's really easy to knock up service & mount units to do all kinds of useful stuff.

[valeriodean]

But the real problem is...

why not looks to the problem by the users' perspective?
There are two main type of users: domestic users and sysadmin.

1) domestic users
Probably a very simple configuration laptop-style, single hard drive, maybe without crypt partitions and so on.
This kind of user has no idea what an init system is and he/she doesn't care at all if you change it or not.
In that simple configuration, a change of the init system during the upgrade will pass without any notice, so a big "who cares" here.

2) sysadmin
Here we can have very complex system, with a lot of handwritten hacks here and there, so in this case a replacement of the init system could raise some problems, right? However you are a sysadmin, not the "my cousin had installed linux on my laptop and I have no idea how it works, help!!11!", isn't it?
If a sysadmin that work on debian has:
a) no idea about the incoming systemd as init by default (despite for months that topic was/is everywhere),
b) no idea if some of his hacks could work good or bad with systemd
c) not followed the distro mailing list related to the systemd adoption and its bug tracker
d) not willing to test it before the upgrade
e) not willing to study it and take confidence before the upgrade (especially how to have access to the debug tools/procedures)
f) no idea how to avoid the init system change (this is related to the point c)

then it looks like that sysadmin is superficial and stupid. Unfortunately, for the stupidity there is no cure.
I continue to see more "philosophical" argumentations (to not say stupid) than real issues about the systemd adoption in debian.

[Delgarde]

You would think even the 15 year old Slashdot kiddies that make up 'teh Linux community' would have had the foresight to never let another Miguel de Icaza type clown trash their precious little OS.

What you expect the 15 year old Slashdot kiddies to do anything more than talk, and compete over first post?

[Tentacle]

FreeBSD 10: blah blah blah

Oh, hey, how is that suspend working for you? How about hibernation? Can you use any laptop other than Lenovo? Something, you know, real modern operating systems have been able to do for years? Also did you finally get that ASLR? Is FreeBSD finally as secure as Linux?

[gens]

1.) https://wiki.archlinux.org/index.php...ing_unit_files <-- archwiki have it pretty clear, if you have doubts about the code handling it ,post the code section you troubled with
2.) https://www.kernel.org/doc/Documenta...ps/cgroups.txt <-- useful information for global CGgroups understanding before tejun took maintenance and here you have http://www.linux.com/news/featured-b...roups-redesign the tejun refactor later on and here some background for namespaces http://vincent.bernat.im/en/blog/201...isolation.html, is not related to systemd namespaces per se but the theory is basically the same.
3.) systemd doesn't require an explicit restart or stop or force reload,etc implementation, in non-systemd this options need to be explicit because all services share the same PID namespace and can produce race conditions or zombie process if you just kill it(apache was famous for this) but in systemd cgroups and namespaces deal with cleanly since the service is resources isolated and its PID(parent and child) virtual table reside in its own namespace(similar to abstract linux socket) so is basically race free to let the kernel handling the cleaning, some more detail from lennart http://0pointer.de/blog/projects/changing-roots.html(he mentions other stuff about chroot and containers but the part about unique contexts in the second paragraph is related to the topic at hand)
4.) systemd can handle automatic restart too btw, is just a simple line and it will restart the X service anytime it goes down and additionally you have instanced ondemand services for the same service (see LXC on systemd guide or nspawn for a better idea)
5.) systemd follow the KISS principle, every module in systemd is extremely focused on 1 task and 1 task alone including the init module(is a bit bigger since it require lots of syscalls boilerplate code) and if you remove the syscalls code you will see the logic is pretty simply and often stupid but elegant, the fact that all modules reside in 1 big git repository doesn't make it 1 big executable(is a lot easier to develop this way and modularise on Makefiles)

i asked you, not some websites
and i asked how systemd determines what the next process it starts will be
nothing else

you didn't answer that simple question

and no, systemd is in a galaxy far away from KISS
from wikipedia: "The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided."
systemd, for one example, needs dbus to even work...

and continued on the "Worse is better" page also from wikipedia: "The idea is that quality does not necessarily increase with functionality."

Keep It Simple, Stupid
not Make It Unnecessarily Complicated For No Good Reason, Intelligent Person

[steveriley]

Quote from debianfork.org: "only few of us have the time and patience to interact with Debian on a voluntary basis"

Question for people behind debianfork.org: Where will you take the time from to create and maintain a Debian fork?

If they don't have a convincing answer to that, they should not be taken seriously, no matter what your position on the systemd debate is.

Holy hell, you just summed it up quite nicely there. Not sure if it's worth the time to follow this "news" or even read more comments. Ah, what am I saying? Can't help it...will keep reading

[jmcknight]

My favourite part about this entire discussion is a few things.

1. The argument that systemd essentially pisses all over the UNIX legacy blah blah blah. By using Linux, you're using an operating system that does so with a major system component: the kernel itself. In the many years that it's been under development do you not have the slightest clue at how massive it's become? If you're so concerned about UNIX's legacy -- use MINIX or straight up UNIX.

2. For the anti-systemd people who essentially want it banished, you're promoting what Open Source isn't: lack of choice. You're saying you don't like systemd which is fine, but most of the arguments I've seen against it lack some serious technical merit. I support it but I also see areas where it potentially has problems but I haven't experienced a single problem with it. No crashes, no freezing, etc. This isn't to say that these things don't happen, but the people who are claiming these problems are rampant aren't helping their argument by providing real world examples via crash dumps and the like.

The great thing about Open Source is choice. As much as you've made the choice to use Linux, you also have the choice to not use it. So good luck forking Debian on a team of less than 20 people and I expect this to go the same route as Operating System U -- nowhere.

[Tentacle]

If you're so concerned about UNIX's legacy -- use MINIX or straight up UNIX.

Precisely. Linux Is Not UniX. You want UNIX? Then go use a UNIX. A *BSD is close enough.

Meanwhile, I agree that some principles of UNIX are great, but it doesn't mean that in 2014 we have to blindly follow those principles that were devised decades ago. The UNIX-y many tools that do one thing well is essentially broken in 2014, not because the philosophy is broken, but because there is no integration. There are no standards, no APIs to build against. Systemd is the only major project attempting to change that. I don't like it, but there's no alternative right now.

[CanalGuada]

i asked how systemd determines what the next process it starts will be
nothing else

At boot, the system manager on the OS image is responsible for
initializing the required file systems, services and drivers that are
necessary for operation of the system. On systemd(1) systems, this
process is split up in various discrete steps which are exposed as
target units. (See systemd.target(5) for detailed information about
target units.) The boot-up process is highly parallelized so that the
order in which specific target units are reached is not deterministic,
but still adheres to a limited amount of ordering structure.

When systemd starts up the system, it will activate all units that are
dependencies of default.target (as well as recursively all dependencies
of these dependencies). Usually, default.target is simply an alias of
graphical.target or multi-user.target, depending on whether the system
is configured for a graphical UI or only for a text console. To enforce
minimal ordering between the units pulled in, a number of well-known
target units are available, as listed on systemd.special(7).

The following chart is a structural overview of these well-known units
and their position in the boot-up logic. The arrows describe which
units are pulled in and ordered before which other units. Units near
the top are started before units nearer to the bottom of the chart.

           local-fs-pre.target
                    |
                    v
           (various mounts and   (various swap   (various cryptsetup
            fsck services...)     devices...)        devices...)       (various low-level   (various low-level
                    |                  |                  |             services: udevd,     API VFS mounts:
                    v                  v                  v             tmpfiles, random     mqueue, configfs,
             local-fs.target      swap.target     cryptsetup.target    seed, sysctl, ...)      debugfs, ...)
                    |                  |                  |                    |                    |
                    \__________________|_________________ | ___________________|____________________/
                                                         \|/
                                                          v
                                                   sysinit.target
                                                          |
                     ____________________________________/|\________________________________________
                    /                  |                  |                    |                    \
                    |                  |                  |                    |                    |
                    v                  v                  |                    v                    v
                (various           (various               |                (various          rescue.service
               timers...)          paths...)              |               sockets...)               |
                    |                  |                  |                    |                    v
                    v                  v                  |                    v              rescue.target
              timers.target      paths.target             |             sockets.target
                    |                  |                  |                    |
                    \__________________|_________________ | ___________________/
                                                         \|/
                                                          v
                                                    basic.target
                                                          |
                     ____________________________________/|                                 emergency.service
                    /                  |                  |                                         |
                    |                  |                  |                                         v
                    v                  v                  v                                 emergency.target
                display-        (various system    (various system
            manager.service         services           services)
                    |             required for            |
                    |            graphical UIs)           v
                    |                  |           multi-user.target
                    |                  |                  |
                    \_________________ | _________________/
                                      \|/
                                       v
                             graphical.target

Target units that are commonly used as boot targets are emphasized.
These units are good choices as goal targets, for example by passing
them to the systemd.unit= kernel command line option (see systemd(1))
or by symlinking default.target to them.

Nevertheless, when needed and relevant, systemd boot-up process can be more deterministic (thus less parallelized) since system administrators, packagers or upstream project developers can supply more intermediate specific targets between those special ones that are commonly used, or simply use Before/After/Requires directives in all unit files.

[Nobu]

If I hadn't experienced all of this firsthand, I wouldn't have posted these links here. I tried Fedora 20 just recently and I saw with my own eyes how systemd segfaulted. OK, that was a bug, yum update fixed it. Then it froze on boot trying to run two bad services over and over again - not even trying to realize that they cannot be launched.

Systemd is an abomination. An init system must be rock f*cking solid and equally simple. Systemd is anything but. There was a proposal to create a very simple, very basic init 1 process which spawns all other crazy systemd features as sub-processes so the whole system has no chance of crashing but no, Lennart doesn't think it's worth it.

I've been using ArchLinux since it switched to systemd, and it's been rock-solid. I've also used fedora on-and-off (before and after they switched to systemd) for a couple of years prior to switching to Arch...it was less than rock-solid. systemd is fine, it's just that fedora isn't (and shouldn't be considered) a stable platform. Sure, it's less rocky than, say, rawhide (and much better than OpenSuSE, IMHO)...but it's still just a testing platform for what they're going to put into RedHat. I've been burned multiple times with Fedora and, although it was usually my fault, sometimes it was just a bug introduced in an update. Arch has been much more friendly to me, in that regard.