On Monday 17 Feb 2014 07:01:53 Yuri K. Shatroff wrote:
> 17.02.2014 00:19, Canek Peláez Valdés пишет:
> > On Sun, Feb 16, 2014 at 1:00 PM, Yuri K. Shatroff <yks-...@yandex.ru>
> > wrote: [ snip ]
> > 
> >> Isn't there too many "if you believe" and "if you agree"? A church of
> >> systemd? ;)
> > 
> > As I said to Tanstaafl, it gets kind of philosophical.
> 
> Even religious.
> 
> > Technically, systemd is the obvious superior choice, and that's why
> > the TC voted for it in Debian (read the discussion).
> 
> Oh I have read so many discussions already... :)
> To me, systemd's technical superiority is far not obvious. Just another
> init system would be, but as long as systemd is much more that one, I
> can't say that. It should NOT be compared to OpenRC / upstart alone,
> rather to a whole bunch of tools it replaces, and probably even those
> it's ambitious to replace.
> 
> >> I wonder why all systemd's fancy stuff hasn't yet been integrated into
> >> any existing init system, because of theoretical impossibility or just
> >> practical uselessness?
> > 
> > If it's "practically useless", why so many distributions keep choosing
> > it? Why GNOME started using it?
> 
> Well, I said that technical superiority matters little for maintainers;
> what matters is money. If I'd write some super-puper fancy init system
> and kernel replacement, who would be interested? It's not the time of
> Linus' rise, now you don't deal with USENET freaks, but with Intel,
> RedHat and other billionaire corps. Do you have the guts and means to
> keep up with competitors, even not about kernel/init subsystems, but a
> user app like mailer/browser/messenger...
> A kernel subsystem requires much more technical competence to maintain
> and is far more critical for functioning, so much more important here is
> not any 'technical superiority' but simply resources, human and
> financial, spared if using RH-maintained systemd.
> 
> >> Actually why not do the daemon management, logging, cron etc in the
> >> Linux kernel itself? It's obvious, and we even have a perfect example
> >> of kernel-integrated graphics around -- `guess the OS name`. It also
> >> has much in common with systemd; "Believe us it's the best OS",
> >> "Believe us it provides loads of features", "Agree with having binary
> >> logs" etc.
> > 
> > All the software is libre; with only that any comparison to Microsoft
> > becomes moot.
> 
> Once you mentioned "technical superiority", let's compare other stuff
> technically too. :)
> 
> >> A competent approach for choosing software for a task is answering the
> >> questions:
> >> 1. Is the software standards-compliant?
> >> 2. Does the software have an alternative compatible implementation?
> >> 3. Is the software developed to achieve a certain, concrete goal?
> >> 4. Does the software achieve the goal?
> >> 5. Does the software achieve the goal "gracefully"?
> >> 6. Does the software have a clear perspective and view what it will be
> >> like? 7. Is the software developed and maintained by a reliable company
> >> or group?
> > 
> > That's *your* approach. It's certainly not my approach: I don't care
> > if Emacs is "standards-compliant" (whatever that means for a text
> > editor); I don't care if Inkscape has an alternative compatible
> > implementation; and for the rest of your questions, my answer would be
> > yes.
> 
> You don't care about Emacs and Inkscape but do you care the same nought
> about e.g. /bin/cp, /bin/mv etc? Do you care that your browser talks
> HTTP rather than SHiTP? Do you care that once after a couple of years
> your systems get unmaintained and unmaintainable because the software on
> them becomes a load of bashed up crap which only a world's head lennart
> can deal with? Well, you'll say that red hat tralala, but we've seen the
> rise and fall of many giants e.g. Sun with their once 'technically
> superior' Solaris and SPARCs, well one can name many I just don't have
> time, also we seen MySQL bought by Oracle, and all.
> Nothing is eternal, and it's (Again!) quite not always technical matters
> that matters.
> 
> >> AFAICT, with systemd there's by far one "yes". The other answers are
> >> dubious if just plain "no".
> >> 
> >  From your point of view.
> >  
> >> I'd personally share Alan McKinnon's POV: there's no real reason to
> >> switch to systemd since the present init systems serve pretty well and
> >> the benefit, if any, isn't worth the adaptation threshold.
> > 
> > That's fine; you don't have to use systemd. But if (as an extreme and
> > unlikely example), Gentoo decided to switch exclusively to systemd,
> > then either someone willing and able would need to come out ant start
> > maintaining the alternatives, or then you should do it.
> 
> At present, no. But the trend is clear.
> 
> > That's how free software works.
> 
> Actually, free software (one you don't pay for) works like any other
> software you pay for. You probably wanted to say "that's how the OSS
> model works" but it's getting less and less true. The OSS model in many
> cases retains only its open source. Take MySQL, take KDE, take GNOME.
> Who cares about users? We do what we deem feasible regardless if you
> like it or not. Don't like it? C'mon, fork, it's free. C'mon, it's
> technically superior. C'mon, who are you? An admin? A programmer? A
> Bachelor/PhD? Ha, man, we're BILLIONAIRES. That says it. We GRANT you
> our software AS IS. And its source. And its bugtrackers. We make
> business by the fact that we have millions of free testers 'round the
> world. We can afford that. If you can afford forking and maintaining,
> c'mon man.
> 
> >> But why then is Linux drifting to systemd? The answer is simple: money.
> >> Time is money. You have to support two init systems -> twice the time,
> >> twice the money. Sooner or later, a sum of money will outweigh the
> >> users' opinion. To be a realist, one has to admit that in near future
> >> 90% of new distro versions will be systemd-based. Unless some green
> >> soxx emerge and take over Red Hat...
> > 
> > I don't think neither time nor money had to do with Debian's (nor
> > Arch's, nor OpenSuse's, nor Maegia's, nor Sabayon's) decision.
> 
> It's not in terms "think" or "don't think". It's a fact.
> 
> > It's just technically superior. But's that's just my opinion, and what
> > I believe ;)
> 
> That's a good thing to believe in. It's hard to prove, hard to see,
> impossible to test all cases.
> Money is what you don't believe in. You either have it enough or not.
> 
> > So, amen? :D
> 
> Amen. :D
> 
> > Regards.

I am not sure if people object to the Lennart-way of messing up Linux, under 
the blessings of RHL, or if they just don't like the immediate outcome.

Essentially, in his arrogance Lennart only needs to code things the way *he* 
sees as useful or expedient to him and his pay masters.  In doing so he throws 
the *nix way of developing software out of the window and creates a convenient 
for him monolith.  Wherever he can't be bothered to do a neat and versatile 
job he makes his own arguably option-limiting decisions and thus we have 
arrived to today's flavour of systemd-udev-pulseaudio-gnome and whatever else 
he will try to weld in tomorrow.  He found like minds in Sievers et al and 
money from RHL helped them get there.

It ain't pretty and architecturally does not follow the *nix design 
principles, but as Canek says, those who can code better should step up to the 
plate and redesign systemd as it should have been done from the start for the 
benefit of Linux, without making the design compromises that Lennart has 
decided suit him.  I don't know if forking systemd is easy, but no one has so 
far decided to do so.

Given the title of this thread I fear that those of us who can't code, will 
increasingly find our choices becoming limited, because more and more 
functionality is hacked inextricably into systemd and friends.  It's probably 
too early to call if Gentoo will remain one of the few options in Linux that 
do not use systemd, but decisions taken upstream (for example initrd for 
separate /usr) are affecting some us already.
-- 
Regards,
Mick

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to