[Cialug] The systemd Init System

[jim kraai]

some will disagree here, and for some good reasons, but hear me out ...

that philosophy died hard several decades ago :-(

it was a good philosophy compared to mainframe batch jobs, which i'm sure
was part of the motivation for it in the first place

big reasons:
1. that philosophy doesn't make it easier to support the complex workflow
graphs that complex specialized applications do better by some ways of
measuring 'better'
2. the magical relational database and all that that became
and others, but i'm out of time

i miss that philosophy, but it was already dead before i ever touched a
unix terminal


On Wed, Dec 9, 2015 at 11:53 PM, Scott Yates <Scott at yatesframe.com> wrote:

> Thank you for your replies.
>
> I see the points you are making, and understand why this would be helpful.
>
> One last thought:  This seems like it breaks with the Unix philosophy of
> small, chain-able apps that "Do one thing very well".
>
> Maybe this is just a case where that philosophy breaks down?
>
> On Wed, Dec 9, 2015 at 9:38 PM, Jeffrey Ollie <jeff at ocjtech.us> wrote:
>
> > On Wed, Dec 9, 2015 at 4:13 PM, Scott Yates <Scott at yatesframe.com>
> wrote:
> >
> > > Specifically, systemd seems to have the idea that all other init
> systems
> > > are broken
> >
> >
> > Yes, in fact they are (IMNSHO).
> >
> >
> > > and they have taken it on themselves to "fix" them.  The idea
> > > of a monolithic init system makes me nervous because it throws away 30+
> > > years of proven ideas.
> > >
> >
> > Just because we've been limping along with sysvinit doesn't make them
> > proven.  And actually, there's a very good chance you're not even using
> > sysvinit anymore - Ubuntu replaced sysvinit with upstart in 2006, RHEL 6
> > shipped with upstart in 2010, Mac OS X Tiger shipped with launchd in
> 2005,
> > Solaris has used SMF since at least 2005.  I'm sure that there are other
> > examples that I'm not aware of.  systemd is building on and refining a
> lot
> > of what has come before.
> >
> >
> > > Binary logging similarly bothers me.  Logging systems have been in
> place
> > > for years and have been battle tested and proven.
> > >
> >
> > Utter crap.  Once you want to do more than occasionally grep through the
> > log files, you'll quickly discover how broken things are.  First of all,
> > most programs don't log timestamps with enough precision.  Timestamps
> that
> > only include seconds are almost worthless.  Millisecond precision
> (0.001s)
> > is just barely adequate.  Nanosecond precision (0.000001) second would be
> > preferable.  Second, most programs don't log timestamps with a time zone.
> > When you can reach out and touch all of your servers you wouldn't think
> > that time zones in log files matters, but when you have systems spread
> > across multiple time zones, all of a sudden it matters a lot.  Third,
> most
> > programs get log rotation wrong, or don't do it at all and leave it to
> > external programs like logrotate that cause as many problems as they
> > solve.  Fourth, when dealing with lots of log data, you really want them
> > structured and indexed so that they can be efficiently searched.
> >
> > And that's just getting me started...
> >
> > The whole mind-set of fixing things that are not broken bothers me.
> > >
> >
> > A lot of us do not share that opinion.  Early on in the project Lennart
> > Poettering spent a lot of time explaining why the previous init systems
> > were broken.
> >
> > --
> > Jeff Ollie
> > _______________________________________________
> > Cialug mailing list
> > Cialug at cialug.org
> > http://cialug.org/mailman/listinfo/cialug
> >
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/listinfo/cialug
>