VSIDO systemd and upstart discussion

[Digit]

Vasty spoketh these words:
Digit said it would be a good idea to pool the resources of the derivatives and create something from that

... not in those words...  but sure... i'll bend to accept that approximation without calling my lawyers to ask about starting a case, mentioning words like defamation, libel, slander and misrepresentation.  lol

hakerdefo spoketh these words:
An open appeal to VastOne. Just for the sake of change, learning and passion build a VSIDO test image featuring runit.

eeehehehehe.  oh how that had me burst into gleeful giggles and delight. ^_^

yeah, methinks we'd all be surprised just how many init systems there are out there, when we include all the rarely implemented, never implemented, and half-written alpha init systems there are.   ... i was reminded of this when doing some more reading about exherbo last night, where there was mention of their "genesis" init system... i doubt it's had a commit for years, but even as it got mentioned, there followed two names of other init systems i didnt recognize. 
never understimate the power, nor the evil, of "advertising and marketting"...  which much of this $eem$ to revolve around.  if it were technical matters alone, i'm sure we'd be seeing more fully-comprehensive comparison charts, ever being updated and repopulated with the esoteric outliers, ready to give them fair equal consideration based on the pertinent details alone.  ... it's rather like watching mainstream media coverage of the "two party state" bs, this is.  we dont so often hear about the hundred other parties who lack the big money from either aristocracy&corporations or unions&corporations.  XD  hehe.  ... and to further analogy... how about a coalition government... a hybrid init system.   

debian might decide to go with upstart... but does that really mean we have to too, if we want to stick with a debian base?     currently, as it is... we're afforded the choice... they're all in the repo... sysvinit, upstart, systemd...  should we really gaf if debian decides to change its default?   i know we're all passionate about our views, principles, and preferences in our technical specifics, but maybe that passion is blinding us to the freedom we'll still be afforded... right?  ... or am i missing how much of a fundamental (and backwards incompatible) change to the system the decision to go for 'systemd|upstart' would bring?



calm down, calm down.  everything's fine.  that tree's not rrrrreally falling, it's just an optical illusion from all the discussionohol we've been drinking. 


ps,  effin' GOLD posts there guys.     ~ i especially got a kick outta the "how to eat an elephant" & "wind being sucked out of debian" bit.  XD

[hakerdefo]

... or am i missing how much of a fundamental (and backwards incompatible) change to the system the decision to go for 'systemd|upstart' would bring?

If we take case of Arch Linux systemd is currently required by 97 packages. This include essential things like lightdm, mesa, networkmanager, pulseaudio, xf86-video-ati, xf86-video-nouveau, spacefm, apache etc. etc.
Here's a complete list,
https://www.archlinux.org/packages/core/i686/systemd/
Cheers.

[Digit]

[edit]might as well ignore this post.  skip to the next. - Digit[/edit]

oh how that makes me crave the likes of gentoo, with USE flags, where easy management of avoiding that sort of thing could happen.

~ having said that, i've just looked at spacefm in gentoo, and it doesnt have any useflags for init systems...
gentoo can do its openrc, or systemd, both are officially supported.  spacefm seems not to depend on systemd there...  i'm just gonna chalk that up to a quirk of arch, n hope debian remains a broader beast.

just to carry on using spacefm as an example...  even if arch and gentoo are indeed very different distros... i think it's good to see how systemd availability needn't necessitate absurd dependencies.  how debian ends up doing this in the future though...  i do fear that being binary based, they'd be less inclined to offer multiple versions that avoid hog-tying users to such drasticness, especially given the recent murmerings.  ... but then, i'll cling to hope in how debian has historically been less inclined to be devs inconsiderate of users, like arch might be accused of.   

sry, rambling, lost in fud.  ^_^

some gentoo'ish output to illustrate for the drastically curious.  ^_^

$ eix spacefm                                                                                                                                       [24/1952]
* x11-misc/spacefm
     Available versions:  ~0.8.6 0.8.7 ~0.9.0 ~0.9.1 ~0.9.2 **9999 {+startup-notification}
     Homepage:            http://ignorantguru.github.com/spacefm/
     Description:         A multi-panel tabbed file manager

$ equery g x11-misc/spacefm-0.8.7
* Searching for spacefm0.8.7 in x11-misc ...

* dependency graph for x11-misc/spacefm-0.8.7
`--  x11-misc/spacefm-0.8.7  amd64
   `--  dev-libs/glib-2.36.4-r1  (dev-libs/glib) amd64
   `--  dev-util/desktop-file-utils-0.21  (dev-util/desktop-file-utils) amd64
   `--  virtual/udev-208  (>=virtual/udev-143) amd64
   `--  virtual/freedesktop-icon-theme-0  (virtual/freedesktop-icon-theme) amd64
   `--  x11-libs/cairo-1.12.14-r4  (x11-libs/cairo) amd64
   `--  x11-libs/gdk-pixbuf-2.28.2  (x11-libs/gdk-pixbuf) amd64
   `--  x11-libs/gtk+-2.24.22  (x11-libs/gtk+) amd64
   `--  x11-libs/pango-1.34.1  (x11-libs/pango) amd64
   `--  x11-libs/libX11-1.6.2  (x11-libs/libX11) amd64
   `--  x11-misc/shared-mime-info-1.2-r1  (x11-misc/shared-mime-info) amd64
   `--  x11-libs/startup-notification-0.12  (x11-libs/startup-notification) amd64
   `--  dev-util/intltool-0.50.2-r1  (dev-util/intltool) amd64
   `--  virtual/pkgconfig-0  (virtual/pkgconfig) amd64
   `--  sys-devel/gettext-0.18.2  (sys-devel/gettext) amd64
   `--  sys-apps/sed-4.2.1-r1  (>=sys-apps/sed-4) amd64
[ x11-misc/spacefm-0.8.7 stats: packages (16), max depth (1) ]

$ emerge -p spacefm

These are the packages that would be merged, in order:

Calculating dependencies ... done!
[ebuild  N     ] media-fonts/dejavu-2.33  USE="-X -fontforge"
[ebuild  N     ] media-libs/freetype-2.4.11  USE="bzip2 -X -auto-hinter -bindist -debug -doc -fontforge -infinality -static-libs -utils"
[ebuild  N     ] dev-libs/gobject-introspection-common-1.36.0
[ebuild  N     ] virtual/ttf-fonts-1
[ebuild  N     ] x11-themes/hicolor-icon-theme-0.12
[ebuild  N     ] perl-core/Storable-2.390.0
[ebuild  N     ] virtual/perl-Storable-2.390.0
[ebuild  N     ] dev-perl/XML-Simple-2.200.0
[ebuild  N     ] x11-misc/icon-naming-utils-0.8.90
[ebuild     U  ] dev-libs/glib-2.36.4-r1 [2.32.4-r1] ABI_X86="(64%*) (-32) (-x32)" PYTHON_TARGETS="python2_7%* -python2_6%"
[ebuild  N     ] x11-proto/xproto-7.0.24  USE="-doc" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-proto/xextproto-7.2.1-r1  USE="-doc" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] dev-libs/gobject-introspection-1.36.0-r1  USE="-cairo -doctool {-test}" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7"
[ebuild  N     ] x11-proto/inputproto-2.3  ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-proto/renderproto-0.11.1-r1  ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-proto/damageproto-1.2.1-r1  ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] dev-util/desktop-file-utils-0.21  USE="emacs"
[ebuild  N     ] x11-proto/compositeproto-0.4.2-r1  ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-proto/randrproto-1.4.0-r1  ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-libs/pixman-0.32.4  USE="sse2 (-altivec) (-iwmmxt) (-loongson2f) -mmxext (-neon) -ssse3 -static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] dev-libs/libpthread-stubs-0.3-r1  USE="-static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-proto/kbproto-1.0.6-r1  ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-proto/xf86bigfontproto-1.2.0-r1  ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] media-fonts/font-util-1.3.0
[ebuild  N     ] x11-misc/util-macros-1.17.1
[ebuild  N     ] x11-libs/xtrans-1.2.7  USE="-doc"
[ebuild  N     ] x11-themes/gnome-icon-theme-3.8.3  USE="-branding"
[ebuild  N     ] dev-libs/atk-2.8.0  USE="introspection nls {-test}"
[ebuild  N     ] x11-proto/fixesproto-5.0-r1  ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-libs/libXdmcp-1.1.1-r1  USE="-doc -static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-libs/libXau-1.0.8  USE="-static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] media-gfx/graphite2-1.2.1  USE="-perl {-test}"
[ebuild  N     ] virtual/freedesktop-icon-theme-0
[ebuild  NS    ] dev-lang/python-3.3.2-r2 [2.7.5-r3, 3.2.5-r3] USE="gdbm hardened ipv6 ncurses readline sqlite ssl threads xml -build -doc -examples -tk -wininst"
[ebuild  N     ] x11-proto/xcb-proto-1.8-r3  ABI_X86="(64) (-32) (-x32)" PYTHON_TARGETS="python2_7 python3_3 -python2_6 -python3_2"
[ebuild  N     ] x11-libs/libxcb-1.9.1  USE="-doc (-selinux) -static-libs -xkb" ABI_X86="(64) (-32) (-x32)" PYTHON_SINGLE_TARGET="python2_7 -python2_6 -python3_2 -python3_3"
PYTHON_TARGETS="python2_7 python3_3 -python2_6 -python3_2"
[ebuild  N     ] x11-libs/libX11-1.6.2  USE="ipv6 -doc -static-libs {-test}" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-libs/libXfixes-5.0.1  USE="-static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-libs/libXrender-0.9.8  USE="-static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-libs/libXext-1.3.2  USE="-doc -static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-libs/gdk-pixbuf-2.28.2  USE="X introspection -debug -jpeg -jpeg2k {-test} -tiff"
[ebuild  N     ] x11-libs/libXcursor-1.1.14  USE="-static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-libs/libXdamage-1.1.4-r1  USE="-static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-libs/libXrandr-1.4.2  USE="-static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-libs/libXi-1.7.2  USE="-doc -static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-libs/libXcomposite-0.4.4-r1  USE="-doc -static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] x11-libs/xcb-util-0.3.9  USE="-doc -static-libs {-test}"
[ebuild  N     ] x11-libs/xcb-util-wm-0.3.9  USE="-doc -static-libs {-test}"
[ebuild  N     ] x11-libs/xcb-util-keysyms-0.3.9  USE="-doc -static-libs {-test}"
[ebuild  N     ] x11-libs/xcb-util-renderutil-0.3.8  USE="-doc -static-libs {-test}"
[ebuild  N     ] x11-libs/xcb-util-image-0.3.9  USE="-doc -static-libs {-test}"
[ebuild  N     ] x11-libs/startup-notification-0.12  USE="-static-libs"
[ebuild  N     ] media-libs/fontconfig-2.10.92  USE="-doc -static-libs" ABI_X86="(64) (-32) (-x32)"
[ebuild  N     ] app-admin/eselect-fontconfig-1.1
[ebuild  N     ] x11-libs/cairo-1.12.14-r4  USE="X glib svg (-aqua) -debug -directfb -doc (-drm) (-gallium) (-gles2) -legacy-drivers -opengl -openvg (-qt4) -static-libs -valg
rind -xcb -xlib-xcb"
[ebuild  N     ] media-libs/harfbuzz-0.9.23  USE="cairo glib graphite truetype -icu -introspection -static-libs"
[ebuild  N     ] x11-libs/pango-1.34.1  USE="introspection -X -debug"
[ebuild  N     ] x11-libs/gtk+-2.24.22  USE="introspection (-aqua) -cups -debug -examples {-test} -vim-syntax -xinerama"
[ebuild  N     ] x11-misc/spacefm-0.8.7  USE="startup-notification"

The following USE changes are necessary to proceed:
(see "package.use" in the portage(5) man page for more details)
# required by x11-libs/gtk+-2.24.22
# required by x11-misc/spacefm-0.8.7
# required by spacefm (argument)
=x11-libs/cairo-1.12.14-r4 X
# required by x11-libs/gtk+-2.24.22
# required by x11-misc/spacefm-0.8.7
# required by spacefm (argument)
=x11-libs/gdk-pixbuf-2.28.2 X

[Digit]

[edit]nope, might as well skip this post too... i didnt look deep enough.  this post is about direct deps only... -Digit [/edit]

oh, er... i suppose i am likely better off just posting this for a clearer comparison, rather than information overload about one package gentoo doesnt have depending on systemd like arch does.   so, yeah, ignore that previous post, which i've left there for curiosity, integrity, novelty, posterity, whatever.

gentoo's list of packages that depend on systemd:

Code Select Expand


$ equery d sys-apps/systemd
* These packages depend on sys-apps/systemd:
sys-auth/pambase-20120417-r3 (systemd ? >=sys-apps/systemd-44-r1[pam])
virtual/logger-0 (>=sys-apps/systemd-38)
virtual/service-manager-0 (kernel_linux ? sys-apps/systemd)
virtual/udev-200 (>=sys-apps/systemd-200:0[gudev?,introspection?,keymap(+)?,kmod?,selinux?,static-libs(-)?])


just 4 it seems.  ^_^

just sayin... we dont need to be hogtied...  i hope debian do things sensibly.   (heck, no guaruntees it'll be systemd at this point ~ yikes ~ anyone know how many packages in noobloatu depend on upstart?)

[Digit]

oh balls.

posted too soon... shoulda investigated further.

newer systemd's on gentoo, when i look deeper, yes... they too depend on systemd, thnx to udev depending on systemd.

* Digit spares the forum his rage posts from irc upon realising this.

sorry for the blurt of ill-thought forum posts.  i've lowered the standard i'm sure.  :/

"find another"... echoes in my brain from a creeping reluctant revelation that my earlier proposal(s) may be the ONLY alternative.

ps

* Digit does "equery d -aD --depth=99 sys-apps/systemd" and cries out "there is no hope in hell"

[VastOne]

^ That is one of the reasons why Iguru created and recommends udevil... to eliminate the need for udev and systemd dependencies

[hakerdefo]

^ That is one of the reasons why Iguru created and recommends udevil... to eliminate the need for udev and systemd dependencies

But in case of Arch Linux udevil requires udev and udev is part of systemd so udevil also requires systemd. Circle is complete. Lennart wins.
This is all coming from a distro that believes(?) in the principles of KISS and user choice.
Lennart is by no means fool. But his ideas often take inspirations from monopolistic apple and microsoft. The idea of systemd for example was clearly inspired from apple's launchd. Now apple design it's computers with a complete integration in mind. Hardware, O.S, Drivers, Applications are tightly integrated and therefore they are naturally dependent on eachother. And that's what monopolistic apple wants. But this model when applied to the world of open source operating systems is a sure shot failure. Oopsy enough rant for the day...
Cheers.

[VastOne]

^ I do not know Arch at all...

Why would udevil require udev in one platform and replace it in another?  That makes no sense to me at all

[jeffreyC]

The most positive thing that I can definitely say about systemd is that it is FOSS,  from wikipedia;
systemd is published as free and open-source software under the terms of the GNU Lesser General Public License version 2.1 or later.

Worst case if it is chosen/used and RedHat/Gnome et-al get sticky later, it can be forked.

[sqlpython]

I was confronted with this absolutely beautiful post.

Thank You sir for the kind review.
The truth is easy and always plays well.

I continue to visit this forum due to the quality of the people here and because to my eyes VsidO is a really outstanding Distro effort. It can't be said too many times so
"Fine Job VastOne!"   

[VastOne]

@sqlpython..  Thank you!

Seems we are all waiting now for the decision ... seems it has been quiet on all fronts, I have not seen or heard anything new

[Digit]

may seem rather off-topic for us, but a few snippets in the conversation caught my eye and made me think of here.  ^_^

http://www.reddit.com/r/linux/comments/1u2lyr/gnu_hurd_is_up_to_344k_lines_of_code/

... i'd quote specific parts, but then i'd feel inclined to include responses that'd gradually drift and trail off, way off, into far away tangents.


[edit]
ah, no, yeah, there's a bit i'll quote:

narrow-vision stupidity

hehe. 

[ozitraveller]

More twists and turns, .........

Debian May Be Leaning Towards Systemd Over Upstart!?
http://www.phoronix.com/scan.php?page=news_item&px=MTU3NDc

[VastOne]

The decision should be made fairly quickly now... Always an interesting read... One thread I saw from that was a Spotify techinical spokesperson stated that they were only interested in systemd for their 5000+ debian servers and cloud that run Spotify... Here is that message

That is quite the endorsement

[ozitraveller]

Init wars: Shuttleworth's copyright licensing hangs over debate
http://www.itwire.com/opinion-and-analysis/open-sauce/62884-init-wars-shuttleworths-copyright-licensing-hangs-over-debate

At this point, it is very clear that systemd will be the default choice for Debian. This, despite the fact that it does not cater to non-Linux systems and one of Debian's recent showpieces has been its kFreeBSD port, "an official Debian GNU distribution using the kernel of FreeBSD instead of the Linux kernel. About ninety percent of the Debian software archive is available for Debian GNU/kFreeBSD"

This is also interesting
init-select
https://lists.debian.org/debian-boot/2014/01/msg00012.html
Hi

The TC init discussion has diverged significantly from Debian's usual
ideals of freedom and meritocracy, so I decided to do something about
it.

So, today I wrote init-select.  It's a small tool that empowers users
to freely and simply choose among all of the available init systems.
It also empowers Debian contributors to devote their energy toward
their favorite init knowing that users can easily swap inits to try
the new features they are working on.

There also seems to be a push on to install plymouth by default as well.