[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: Re: Re: Bug#727708: multiple init systems: We have to see it for what it is: Lennart/Linux OS. Yes it is.

On Wed, Jan 29, 2014 at 6:00 PM, ChaosEsque Team
<chaosesqueteam@yahoo.com> wrote:
> Ah, you're a systemd acolyte. You smugly proclaim that it is USELESS to resist!

No wrong.    There  are just possible ways to resist.   Then there are
impossible ways.

>>Forking every package that depends on systemd is pointless.
> If you read what I wrote you would see that I said fork everything below/or above
> (whatever "software stack" direction you believe in) the linux kernel,
> and maintain them in a very stable form, applying security patches and bug fixes.

Dbus userspace has differences in operation to kdbus kernel space.
The control parts around kdbus have been done by systemd.  Then you
have cgroups and their design that systemd is matching up to what the
developers of that want.

Sorry systemd integration with Linux kernel is deep.   Forking
everything using systemd and thinking that is a way out is simply not
a possibility the kernel is a dependency in this mix.

You will require a systemd replacement or at least a part replacement
not to use systemd in future at the moment.  Yes a part replacement to
manage kdbus and cgroups for example.

So options are common standards between init systems for
package/application makers to use or forking systemd itself.  Anything
else is going to run into road blocks.

upstart has a fork of systemd logind.  So are going the fork path..

>>Fork the kernel???  right we all know how successful this turns out
>>for those making clones of Solaris.  Solaris clones have to go SMC
>>they don't have a option of using a different init system.
> Personally I do not care what you or Lennart are sick of (which includes
> unix philosophy, as-well as any people who are learned in the unix
> way). I do not want to learn your new little computer religion (getting
> bigger every day). There are social consequences to your hostile
> internal fork of the Gnu/Linux system. You and Lennart do not give a
> damn about those consequences for other people.

There are consequences to people running a crappy designed init system
as well.   More down time.

>>Secure software is a science.  I am sick of those who say Software is
>>more an art.  Saying software is a art is a nice universal excuse not
>>todo quality control.
> Anyway, one way to have secure software is to freeze development
> at some mature version, and then do an audit and focus on fixing
> all the little niggling bugs and failings. Not that you windows programmer
> refugees would know anything about that. You're a flavor of the month
> or half-decade kind of people. And you are attacking the linux system
> from the inside. You like building on shifting sands, and you like it
> even more to force us all to live on the beach with you.
> If you want secure software, it's called the grsecurity patch and PAX, not systemd.

Systemd does bring some security fixes that grsecuirty and pax cannot
fix.  If you like it or not systemd fixes some of the issues with

Journald and cgroups solve a issue with error logging where
applications can incorrectly report what they are.  Yes syslog issues.
 Yes there is a kernel issue in the Linux kernel where you cannot
track what process started what other process without using cgroups.

These kernel issues are why init systems cannot be OS generic and work
correctly.  OS kernel issues need to be taken into account when
starting processes.   Should package mantainers need to worry about
these OS differences.  Most likely no.   We just need a generic
standard that the different init systems accept.
>>Sysvinit came on Linux by being lazy.
> It came on linux by doing one thing and doing it well: it starts various processes
> the system administrator wants started, and then it gets out of the way.
> Very nice and secure design paradigm: does few things, has few lines of code.
Sorry its sysvinit is horrible from a secure and design paradigms.
There is a lot of extra code writing in sysvinit with lots of extra
ways to break things.

Really sysvinit was at the start poorly made clone of BSD init.


BSD init system that is shell script based was in fact designed todo 1
thing well.  Starting the system.    What is the big difference
between BSD init and Sysvinit.  BSD init supports dependencies.    Yes
the rcorder in BSD init does the same a systemd to start all the
services in the correct order so they can start.

The problem is it was lazy to take sysvinit instead of using a proper
solution from the start.  sysvinit throws start up order back on
administrators and expects them to be skilled enough to start
everything in the correct order.   This is not a modern init system
heck its not a quality historic init system.

The simple fact is sysvinit has never done one thing well.  Tidy or
effectively is not something you link with sysvinit.  You can end up
with services spinning and eating up resources waiting for other
services to start because sysvinit does not have a dependency solution
of any form.

Like BSD users never had to manually order their services so their
system would start.   Ordering services that is truly a responsibility
of a init system.   So why do Linux users have to keep on putting up
with this hell????

You might not like what is being done.   systemd shake up has had to come.

>>The Linux world is horribly fragmented.
> Good. It is called choice. Guess what: the hobbyists do not exist to promote or
> expand that religion in your mind called "Linux" or "Desktop Linux" or "The Universal Faith".
> You think if you could just FORCE the Linux world to standardize on YOUR
> software and YOUR interfaces then they would work more efficiently towards YOUR
> goals (of supreme Desktop OS or whatever computer religion/heresy you're into.)
> As an aside: you know once upon a time there was little fragmentation in the init system area.
> It was pretty much a non issue and no app cared what init system you ran.
> Lennart and friends changed all that.

This is a complete lie.   There have always been multi init systems
and fragmentation.  Even inside sysvinit there were different parties
ideas where common code between init scripts should be stored.

sysvinit was the first init fragmentation with a rough copy of BSD
init lacking core features.  Then after that we have had other init
systems forcing themselves to be sysvinit compatible.   So horrible
fragmented without true free choice.

I really do want free choice in init systems.   I want some true
competition.    I don't want garbage of sysvinit being keeping on
forced on us.   Only way for true competition is something to replace
shell scripts as a startup declaration formation.   Something that can
run into a generator and spit out what ever init system I want to use

> In math and science there are often only a handful of ways to
> do a particular thing. In art and religion there are infinite possibilities
> and choices: software is the same. Ofcourse all my software
> is suspect, as am I. Perhaps I'm a heretic and should be burned.
There is infinite possibilities in software but only a limited number
are secure and correctly done.

I would like to see other solutions done correct.

Did you miss me raising openrc.   I am not just for systemd.  I am for
a solution that can work inside the realities.

Freebsd being dominate launchd and Solaris being dominate SMC and
Linux being something different is the reality we have to live with.

Attempting to be like you ChaosEsque Team will never get a solution.

Reply to: