[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: administration of initscripts

> On Wed, Apr 17, 2013 at 09:51:02PM +0100, Kevin Chadwick wrote:
> > 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
> > pressure.
> Which standard, POSIX?


> > POSIX is a very good thing. Do you disagree? I could perhaps
> > understand if there were major benefits.
> It's a good thing for helping to write software portable across UNIX
> implementations, when that's your goal. It isn't always your goal.
> It's slightly less useful if you are only targetting Linux (where LSB
> is a bit more useful, but still flawed). It's also quite old, a lot
> has happened since 2008.
> > 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.
> Let's explore this scenario in a bit more detail. When is POSIX
> mandated? Usually for user-land software written under contract to
> government or military, right? In that situation the company is
> delivering a product to run on top of an OS. That would not preclude
> that OS (which the customer has already got) from using systemd, nor
> Linux (with it's non-POSIX-compliant features) nor *BSD (with their
> non-POSIX-compliant features)… In other words I cannot see a scenario
> where this is actually the case.

That's a very narrow view of what may be delivered.

> Does this happen? Or is POSIX compliance only mandated for operating
> systems that are deployed/sold to public or military funded projects.
> In which case what is important is that POSIX is implemented, not
> that it is exclusively implemented — i.e., a *superset* of POSIX
> functionality is acceptable. And lucky it is, because all the BSDs
> implement non-POSIX functionality, not just Linux. (Although none of
> free/net/openBSD are actually fully POSIX compliant anyway: see below)
> > 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.
> I'd like to see an answer to the question another poster put to you
> regarding this: which part of the POSIX specification specifically
> relates to init systems?

That's a loaded disengenuous question. A system running systemd can not
be POSIX compliant ever.

How can it not be relevant as pid1, if programs come to depend on
systemd then you would have to fork more and more code and not
necessarily just for embedded systems wanting leaner code but possibly
for POSIX compliance.

The key point is Linux running systemd is losing things and gaining
almost nothing.

> > So launchd is better than systemd because in this regard because it
> > is POSIX compliant.
> Do you mean it does not rely on any non-POSIX features? "POSIX
> compliant" usually means something else. See e.g.
> <http://en.wikipedia.org/wiki/POSIX#Compliant_via_compatibility_feature>,
> which lists operating systems which are "Mostly POSIX compliant".
> Note: Linux is "mostly", not "fully". Note also, FreeBSD, NetBSD and
> OpenBSD are "mostly", not "fully".

I was pointing out that you were twisting things. launchd being POSIX
compliant has no bearing on the discussion. Your point was pointless.

> > 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 reconsider.
> If you were a faithful follower of Kernighan UNIX philosophy, you
> wouldn't touch those nasty BSDs with a bargepole. 


> What we know of as "UNIX" today is rather an amalgamation of the two
> — rather different — east and west coast philosophies.

The book talks about the east and west as you call them not as one
being better but both being so depending on the task at hand because the
world isn't black and white. What I was saying was that systemd goes
against some of the good principles set forward in that book.

> > Technical arguments such as you can get from the book I have
> > mentioned are very important but pass most people by.
> It's a great book but it's not to be taken as gospel, and it was
> written over 14 years ago. More relevant IMHO, but just as much not a
> panacea, would be "The Unix Programming Environment", again
> co-authored by Kernighan, which is over 30 years old.
> -- 
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org Archive:
> [🔎] 20130420143452.GC12919@debian">http://lists.debian.org/[🔎] 20130420143452.GC12919@debian


'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
universal interface'

(Doug McIlroy)

Reply to: