[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