Re: administration of initscripts
> On 04/16/2013 03:02 PM, Kevin Chadwick wrote:
> >>> Lets not pollute this useful thread with systemd
> >> It seems a thread about init systems and administration/tweaking of them is the
> >> most appropriate place for systemd to be mentioned. Not least that it can solve
> >> the problem the OP had. It should not be ignored or avoided from being
> >> mentioned just because some people hate it. Some people hate sysvinit. What we
> >> should not do is 'pollute' the thread with any misinformed bias or non
> >> objective statements about the suitability of something for a particular job.
> >> Let's stick to facts.
> > Fair enough. I would always agree with that. I will say I am not biased
> > in any way by my usage of BSD.
> >>> but I will say it would be the absolute last on my list and actually systemd
> >>> itself is incomptible with BSD not just udev and from my experience would be
> >>> laughed out of the room by BSD devs even if it was POSIX compliant.
> >> Luckily we're on a Debian mailing list, then, isn't it, and not a BSD one!
> >>>> Systemd has "assimilated" udev, in a manner of speaking. Udev can still
> >>>> run completely without systemd, but for system builders they have to
> >>>> take a lot of extra steps to seperate udev from systemd and install it.
> >>>> Worse, some devs of systemd want to fully integrate udev into systemd
> >>>> and make it so you can't use udev without systemd. This is bad for many
> >>>> distributions as systemd may not be an option. Debian is an example:
> >>>> Debian has a couple pet prijects to be ported to things
> >>>> like HURD and BSD, which do not provide kernel features absolutely
> >>>> necessary for systemd. Some Gentoo developers have forked udev for this
> >>>> reason.
> > I was merely replying to a few mails at once noting that the above
> > suggests udev is the only non posix part. Systemd is too, such as
> > cgroups which if you search for on the OpenBSD list you will see strong
> > arguments for them actually being practically pointless. I haven't the
> > time to look it up or talk about it here but it shouldn't be hard to
> > find.
> > Please also note that it is not about Linux or BSD either but POSIX.
> > Without POSIX Linux negates itself from some major projects and
> > turning POSIX into Linux only, negates POSIX.
> First off: Linux itself is not fully POSIX compliant, even without
> http://en.wikipedia.org/wiki/POSIX#POSIX-oriented_operating_systems. So
> claiming importance of POSIX to Linux is not entirely correct. While
> POSIX is IMPORTANT to Linux, it's never been a design goal of Linux to
> full comply with POSIX. The Linux Standard Base is probably more
> omportant to Linux distributions.
And that's a Linux problem where some BSDs put lots of effort into
compliance only to have the standard changed to suit linux due to
POSIX is a very good thing. Do you disagree? I could perhaps understand
if there were major benefits.
> Second off, so many people misunderstand the goals and design of the
> POSIX standards. The entire set is largely geared for source
> compatibility between Unix-like systems. I challenge you to find
> anywhere in the POSIX standards that defines anythign about the init
> system or system manager.
That's irrelevent as a systemd only linux world (which granted will
never happen despite lennarts best efforts) would make using Linux more
difficult for many major products where POSIX is a requirement and
would damage Linux too as cross polination would be less likely.
> Third off: SysV is probably even WORSE for compatibility between
> Unix-like systems (And I doubt POSIX would even recommend SysV-like
> capabilities.), because while it itself will function in virtually any
> half-way POSIX environment: Initscripts themselves, which SysV cannot do
> anything without, are entirely platform-specific. For example: Debian
> initscripts will not work at ALL on an LFS system, which has its own
> initscripts. This effectively makes any advantage of usign SysV for
> promoting cross-compatibility null when you still have to use very
> platform-specific methods to use it. systemd's design with the unit
> files and how it works is to allow upstream developers to do what SysV,
> Upstart, and OpenRC certainly would not: A universal way for their
> daemon to be run by a Linux system.
Absolute rubbish and SysV is just one of many methods that correctly
use an init which also differes between systems but can be POSIC
compliant. Yes you have a main rc script which will be customised for
any major project or embedded project or perhaps distro and this simply
demonstrates the power and universality of init. At the end of the day
the primary usage is to set the arguments of a command which is
easily made cross compatible.
> Fourth off: An example, lets look at OS X, which is not only fully POSIX
> compliant, but also fully SUS compliant and therefore a fully Unix
> system. It uses launchd, which systemd's entire design is based on, by
> the author's own admission. If systemd were so incredibly "bad for
> standards" as you claim, how come it functions almost entirely like a
> system manager for a full-scale POSIX/SUS system?
So launchd is better than systemd because in this regard because it is
POSIX compliant. That does not change any of the other arguments
against systemd. I know very little about OSX because I know that I do
not want to know about any OS that leaves security holes in browsers
on it's desktop and mobile webkit for months on end and in the latter
case removing the ability to rectify it by app install.
> Fifth off, and I know this should be taken with a bit of salt: According
> to Lennart, systemd is a lot closer to how Unix has always intended
> system management to be rather than SysV.
Lennart hasn't got a clue about UNIX. Why not take a true Unix source
such Brian Kernighan and read "The Practice of Programming" and then
> Finally, being Linux-specific is ENTIRELY irrelevant to POSIX. BSD also
> has system-specific parts. So does OS X. So does AIX and Solaris and
> Windows and EVERY operating system. It is impossible, even under
> POSIX/SUS compliance for this to be done. It is better for udev and
> systemd to take advantage of kernel features to do their job *right*
> rather than meet your impossible goal of "working universally well on
> all systems." If systemd were to have a BSD port, it'd lose some
> capabilites and admittedly gain some. The goal of systemd is to be a
> *Linux* system manager. The Linux-specific usage of systemd is hardly
> pointless, and you should consider the source of the people making that
> claim: BSD users. I know I''m generalizing here, but ever notice how
> many unsubstantiated claims *against* Linux are made by BSD users? I
> could just as easily cite sources claiming the Linux-specific features
> systemd uses are VERY useful,
You could but they wouldn't stand up outside of the cloud world
enterprise (red hat) of initiating tiny server instances instantly
which is what systemd was designed for with tons of already
existing features added and removing an init management problem which
Linux has long had a problem with unlike OpenBSD atleast to make you
take it and run.
Technical arguments such as you can get from the book I have mentioned
are very important but pass most people by.
> and I'd be more inclined to believe Linux
> users saying these thing than BSD users because *Linux* users actually
> have usage experience to back it up.
I use both every day. It is actually Linux users who often have no BSD
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a