[ale] Gearing up for the future (wuz: boot speed, systemd, vi vs emacs, etc)

Solomon Peachy pizza at shaftnet.org
Tue Feb 20 10:22:40 EST 2018


On Mon, Feb 19, 2018 at 07:15:31PM -0500, Steve Litt via Ale wrote:
> Yeah, well, they didn't have Redhat's billions behind them when they
> negotiated with the upstreams. They had day jobs, many of which were

They didn't negotiate squat.  They stomped off in a huff, and haven't so 
much as attempted to submit a single patch to anything.  Least of all 
Debian.  Which isn't exactly rolling around in the cash either.

> negatively impacted by systemd. But anyway, the word "codepaths" isn't
> defined in dictionary.com, the Urban Dictionary, acronymfinder.com,
> or a generic web search, so unless by "codepaths" you mean the sysvinit
> start and stop scripts, I doubt there was anything barely functional
> pre-systemd, and once again, there were and are plenty of init systems
> that don't use those start and stop scripts.

And are you seriously pulling out dictionary definitions?  What do you 
think this is, a high school debate?  I suggest you look up the 
definition of "jargon".  Any half-competent software developer will know 
exactly what that 'codepaths' means.

But I digress -- What I'm referring to has zero to do with "init 
scripts"; instead I'm referring to logind vs Consolekit for managing 
desktop user sessions, that is one of "embrace extend extinguish" that 
the "systemd cabal" is repeatedly accused of doing.

ConsoleKit is a festering pile of swill, was one hack piled on top of 
another (with unique per-distro and desktop environment code, I might 
add), and those depending on it (gnome and kde, plus nearly every distro 
of note) dropped it like a hot potato because it was so awful and its 
promise rewrite (aka ConsoleKit2) had yet to materialize.

It's telling that current development efforts are along the lines of 
re-implenenting logind's dbus api (eg elogind or logind-shim) with 
varying amounts of functionality rather than attempting to fix 
ConsoleKit.  (And for all of Devuan's hand waving about "init freedom" 
the actual work on the likes of elogind, eudev, and whatnot are being 
done by Gentoo developers who are doing actually useful work.  Devuan 
just got smacked for implying otherwise, BTW.

> The preceding is simply not true. You can easily run any init system
> *except* systemd on Devuan. Running runit, s6, or Epoch on Debian is
> crazily difficult: I know, I've done it.

How does Devuan make using runint, s6, or epoch any easier over Debian?  

(Granted, a week ago they modified d-i to allow for more selections at 
 installation time, but that's not in the wild yet.)

> Simply not true. Devuan removes the tight weldings making it insanely
> difficult to lay down an alternative init, so you can install pretty
> much any simple init system including runit, s6, Epoch, or BusyBox init.
> Meanwhile, I wouldn't want to bet my business plan on Debian keeping
> their sysvinit package and their OpenRC package functional as time goes
> on.

What weldings are these?  Note that Devuan is 99.44% Debian; as I write 
this there are only 184 (source) packages different out of 28,036.  
Under the hood, the overwhelming majority of the changes consisted of 
branding (Debian->Devuan) and removing any vistages of systemd, eg 
compile-time options to disable systemd integration, unit files, 
and so forth.

Unless by "Weldings" you're referring to Debian's famous attention to 
detail where they try to ensure every option is fully supported 
throughout the entire system (including across upgrades).  Relaxing 
quality standards isn't exactly something to brag about.

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
Coconut Creek, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://mail.ale.org/pipermail/ale/attachments/20180220/044f5a95/attachment.sig>


More information about the Ale mailing list