Re: piece of mind (Re: Moderated posts?)
Scott Ferguson wrote:
On 15/10/14 01:54, Miles Fidelman wrote:
Scott Ferguson wrote:
On 14/10/14 23:54, Miles Fidelman wrote:
Andrei POPESCU wrote:
On Lu, 13 oct 14, 18:30:41, Miles Fidelman wrote:
Gee.... assuming that you don't run anything that has systemd
dependencies
and/or systemd-shim is actually maintained and kept up-to-date.
Have you actually looked into what depends on systemd?
Trying to.
As a start - anything that depends on udev and logging come to mind; all
services that require startup (hmm... I run a server, not a desktop - so
that would be pretty much everything).
I'm guessing you really don't want an OS without logging... :)
syslog works just fine - don't need (or want) systemd to take over
logging with a binary format
Miles Fidelman
Miles,
sounds like the selection criteria for LinuxFromScratch
http://www.linuxfromscratch.org/
or maybe revive Debian for Scratch instead of relying on a progressive,
"Universal" OS that struggles to fund LTS and is reliant on upstream for
the majority of development. Embracing diversity and conservatism
(aversion to change) can be "a bit of a stretch".
How do you come to that conclusion.
Which conclusion?
That this is the selection criteria for LFS. (Mind you, building from
scratch is looking better and better - though Gentoo makes it a lot easier.)
But, addressing (some of) your other points:
That Debian is a progressive "Universal" OS?
It changes as a result of developers seeing a need to improve - I'd call
that progressive (rather than static or regressive).
Stability is an awfully nice virtue, one that Debian used to subscribe to.
That your own OS might suit your needs (and some others) better? (did
you take that as an offence??)
That Debian is NO LONGER a suitable operating system for my needs, after
more than a decade - yeah, that I kind of take offense to - or at least
I take offense to the inordinate amount of time that I expect to waste
on migration - be it to systemd, another distro, or another o/s entirely.
Based on the large number of posts you've made complaining that Debian's
plans don't match your needs.
If you took that as a "if you don't like it b*gger off" then you took it
wrongly - I reserve that for those who continually talk about departing
Debian. It seems that you, and others, are bent on demanding something
from developers that those developers don't want to do - it appears to
upset you and cause you stress. In short - a fruitless exercise (unless
I've seriously misjudged you and complaining does gives you pleasure).
Some of us actually have to plan for things like transitions - and the
lack of clarity regarding development plans makes that rather difficult.
Ok... so multiple init systems are going to be supported in Jessie, and
maybe beyond - ok. What seems to be very much up in the air is whether
that choice will be (well) supported at upgrade or install time. That
makes a rather big difference.
For at least a decade, maybe two, Debian has been one on the short list
for linux distros suitable for use on servers, and has been viewed as a
distro for knowledgeable users - and a lot of that has come from
flexibility and a very good packaging system. Lots of important
server-side stuff are designed for Debian first (e.g., Xen).
So, apparently, that's changed.
The number and type of deployments has (greatly) increased in recent
years. Servers are up, embedded devices are up, and so are desktops. And
they all connect to each other. So yes - changed.
Don't forget Steam... enormous changes.
But nothing compared to what's coming - the rest of the world is coming
online.
(I guess, if libreoffice is no. 2 in the
popcon stats, desktop use now dominates. Sigh...)
And understanding what the relative priorities are has major impacts.
With rather large regret, it sure seems like the priority on server-side
support has gone way down in favor of desktop support (as far as I can
infer).
DISCLAIMER: I'm happy with squeeze lts on servers - slowly being
transitioned to Wheezy where end-user requirements demand more modern
apps and libraries (I can't ignore end-users, ymmv).
In some instances I pre-populate /dev (low-resource devices), but mostly
I have no issues with udev. Systemd is something I'll deal with in a few
*years*.
Actually, udev is the ONLY thing I've had issues with in over a decade
of production use. Changed out a nic card, and everything changed -
because udev decided to assign the new interface to some other port (or
some such - it's been a while).
I've had that happen...
nano /etc/udev/rules.d/70-persistent-net.rules
change eth1 to eth0 and remove the line that used to read eth0
I took a while to understand udev, but I find it extremely useful in
some circumstances. Being able to treat devices with more fine-grained
control than just any old nic=eth0 can be useful if you want to treat
different devices differently rather than generically by gross type.
e.g. which nic is which? udev makes that simple.
So far I've had no problems not using udev when it's not required
(static hardware).
A completely unexpected behavior, hard
to track down, poorly documented.
:)
I'd say the same about most packages.
As for unexpected - I usually read the release notes before I begin
testing - no complaints so far.
I don't understand what you mean by "hard to track down". udev gives me
much more information about devices than hal and it's predecessors.
well yeah - but one kind of expects core capabilities to simply keep
operating predictably across upgrades -- you know, regression testing
and all that
Given that the players are the same,
and the scope is much larger, this gives me lots of reservations about
systemd.
I'm *very* wary of any "gut-instincts" - but I do encourage those that
swear by them to publicly journal them for future reference.
well... where systemd is concerned, I point to Linux Torvald's comments
re. PulseAudio; where udev is concerned, I simply make a note to myself
[*1]
I suspect enough to support a tightly-focussed server OS (if you can
herd cats?) - maybe a Debian derivative? Strip out all the DE packages
and it might be do-able...
That used to be Debian.
Not in the 20+ years I've been deploying it. It was always 'better' at
server than desktop - now it's not so bad as a 'desktop'.
But different perspectives and different requirements - I *like* to
modify systems. Debian enable me to tailor it to suit a given purpose -
it I wanted someone else to tailor it for me I'd pay them (and treat
them nice).
hmmm.... I think we agree on this one --- the thing is, I've already
invested a lot of time and effort in tailoring our current installation
-- systemd is going to blow that all ways, or at least require:
- time and effort to build a system that doesn't install systemd by
default (unless the installer folks include init-select as part of
installation), or,
- time and effort to test anything and everything that touches systemd -
particularly customized initializations and such (I'd sure like to see
some regression testing on systemd's support for legacy sysvinit) and
- an expectation that somewhere, I'm going to get bit by some big
problem induced by systemd, that's going to take a long time to figure
out (and having looked at the documentation, that scares me
Beyond that:
- the whole thing with systemd, it's monolithic nature, and it's
intrusiveness is that we lose a lot of that ability to tailor things (or
at least it makes that much harder) - as well as being a major shift in
design and architectural philosophy, away from modularity toward
monolithicness (if that's a word)
- lots and lots of central, unaudited code
CentOS would fit the server focussed distro definition better (well,
limited architectures, on recent hardware...). Some people swear by it
i.e. "I've never used anything else - the others are all rubbish" ;p
Well if I wanted Red Hat family, I'd go with CentOS or RHEL; though when
it comes to commercial distros, SUSE has always struck me as a bit
"cleaner" from a sysadmin perspective.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
Reply to: