Re: How about a fork of Jessie without systemd?

Quoting Ruben Safir ([email protected]):

> Well, Gnome does that applications which are useful and the sound
> integration was decent before it went off the rails.

Well, luckily for you, the problem isn't with GNOME applicatiosn but
rather with GNOME.  Remember the list?  gnome-bluetooth,
gnome-settings-daemon, gdm3, gnome-core, gnome-disk-utility, pcmanfm,
daisy-player, and a couple of other obscure apps that require
policykit-1 that in turn requires systemd.  

Do you see Abiword in that list?  Gnumeric?  No, you don't.  Like me,
you like to run those GNOME applications under Window Maker.  And
there's nothing preventing you from running those and a dozen or two
other GNOME applications, because 'GNOME applicaition' means only that
it depends on gnome-libs and gtk, not that it necessarily requires
anything else.  _GNOME_ as a framework has a problem, because things
like gnome-settings-daemon, gdm3, gnome-core, gnome-disk-utility have
dependency problems, but individual GNOME applications do not.

Honestly, was that actually difficult to figure out?  Surely you've
understood for many years that each DE is merely a suite of X11
applications with a common look and feel on account of some libs and a
graphics toolkit they all use, and nothing prevents you from using those
applications on an a la carte basis without needing the whole DE.


> I have had compains adopt gnome screadsheets, their quicken like
> finance program, and video editing programs.

If you had complaints about _them_, that has nothing to do with systemd.
But I suspect you're confused, and failing to understnad the difference
between GNOME as a whole and GNOME applications.

Fix that.  


> Additionallym the network manager seems to succeed at the universities
> wifi in a way that wicd just won't.
> 
> don't ask me why.


Once again, we get to remedial details:

NetworkManager is merely and purely a front-end to Wireless Tools for
Linux and wpa_supplicant.  So is wicd.  So is connman.   (Well, as Marc
points out, NetworkManager's feature bloat means it also calls Bluetooth
network code.)  

So, any WiFi networking connection that can be initiated by one can
be initiated by any of the others _or_ with no wireless network manager 
at all.  Yeah, _no_ wireless network manager:  Remember iwconfig / 
ifrename / iwgetid / iwlist / iwpriv / iwspy?  They still work fine.

Not able to make iwconfig work?  Figure it out.  It's not significantly
more complex than iwconfig, and there's a perfeclty suitable man page.



> But forget Gnome.  X11 needs an entire backport configuration to reroot
> it and make it work without systemd.

No, it actually doesn't.

I really don't know what exact idiocy you got into with OpenSUSE, but I
have a running instance of Debian Jessie in front of me with package
xserver-common package version 1.16.4 , which is to say, current.  It
looks to me that _if_ there _were_ a lack of root user privilege to
start the Xorg server -- which there is not -- then 'man 5
Xwrapper.config' would tell you wnat to put on the
/etc/X11/Xwrapper.config line to fix that.

Which is what I said upthread, except I'm saying it in more detail this
time.

I didn't need any existing expertise to know that, which is lucky
because I actually didn't know that -- until I did 30 seconds of Web
searching a couple of days ago.

Welcome to the Internet.  Occasionally something needs 30 seconds of Web
searching.


> Is this hard?  It is for me.  It is definetely a fork in the package
> design.

You keep using this phrase.  I do not think it means what you think it
means.

Again, not certain what exact Xorg problem you ran into on OpenSUSE that
proximately resulted (along with your 'init scripts' thing) in your
running to Manjaro telling tales of terror about systemd, but all I'm
_aware_ of happening with 'rootless X' is that some Xorg guys figured
out about eight/ten years ago how Xorg _could_ be started without the
need to run that massive graphics engine with root-user authority --
which is A Good Thing, because the X server binary running as a big
root-privilege process has always been a security Sword of Damocles.
Nothing about that requires systemd, nor even PolKit, ConsoleKit,
upower, udisk2, and the rest of the Freedesktop.org brass band.

Maybe next time you have a technical problem, you should not overreact,
change distributions, and go around yelling on mailing lists, but rather 
do what the rest of us do:  Spend a little quality time with a search
engine, grep some logfiles, tinker a little, fix it.


> I'm not sure what you mean with this paragraph....

So, you're going to ignore what I said, talk past me, and change the
subject to something wildly different about use of UUIDs in partition
mounts -- which if you don't like them (as I don't), don't use them (as
I don't).  Towards which end, you might want to turn off DE automounters
(as I do).

If you run DEs with their whole marching bands of processes that each
have their own ideas about how to run your system, don't act surprised 
when your system is no longer being administered your way.  Again, this
is Linux 101.  We should not be needing to have that conversation on
linux-elitists in 2015.


> I never made predictions.

That bit about if things go the way they've been progressing was some
_other_ Ruben Safir?

> I love it when you write about me in the third party.

THe correct phrase is 'third person' (e.g., 'he'), but what I wrote
there was entirely second person (e.g., 'you').  As the saying goes, you
could look it up.


> You left out some essentle details.

Quite probably because you never provided a coherent factual account --
and you still haven't.

 
And, by the way, the bit about how you could no longer run tried and
tested init scripts doesn't make sense, either, because systemd-based
distributions include the ability to parse and run SysVInit scripts.

_______________________________________________
Do not Cc: anyone else on mail sent to this list.  The list server is set for maximum one recipient.
linux-elitists mailing list
[email protected]
http://zgp.org/cgi-bin/mailman/listinfo/linux-elitists