Re: End of hypocrisy ?
On Tue, 5 Aug 2014 11:19:55 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> On Ma, 05 aug 14, 00:05:59, Brian wrote:
> > On Mon 04 Aug 2014 at 18:28:44 -0400, Steve Litt wrote:
> >
> > > On Mon, 4 Aug 2014 14:03:35 +0200
> > > Raffaele Morelli <raffaele.morelli@gmail.com> wrote:
> > > >
> > > > I've seen tons of posts sent to this list about systemd... bla
> > > > bla bla... and did not understand what's the matter with it.
> > > >
> > > > I wonder what are you all doing with your init scripts which
> > > > doesn't work with systemd. So what?
> > > >
> > > > /r
> > >
> > > I can answer that with two reasons:
> > >
> > > 1) Binary log files. If you can't see what a radical departure
> > > that is from the world of Unix, look again.
> >
> > Looked twice. It is a radical departure.
>
> Let's not forget text logs are still available since journald is
> configured to forward everything to your syslog as soon as it's
> available. In practice I find myself using only journalctl to read
> logs instead of less/grep/tail/etc.
If that's true, forget this argument.
>
> > > 2) Gratuitous interdependency. Part of the Unix Philosophy is that
> > > programs should "do one thing and do it well." The user
> > > assembles a functionality from many such small programs. Up to
> > > now, init was just init. It started the computer, the /dev
> > > and /proc stuff, the TTY's and the daemons, then pretty much got
> > > out of the way. Now here comes systemd, requiring or encouraging
> > > even desktop environments to require or suggest it.
> >
> > systemd neither requires nor encourages DEs to use it. It does
> > tempt in a rather cheeky way, though. So much so that its allure
> > has turned out to be irresistable to upstream GNOME. Weak-kneeded
> > and impressionable, the lot of them!
Gnome doesn't concern me. Xfce, LXDE, Openbox, those concern me.
>
> I have to add that the world of computing has become much more
> complex and there's only so much one can do just by combining the
> traditional small and simple tools of Unix. To perform complex tasks
> one needs complex tools and booting a Unix-like system hasn't been
> simple since a long time now.
Thank you Mr. Gates!
In March 2001 I ran screaming from an OS that did every last thing for
me, whose excuse for being an entangled mess was the complexity of the
world. Little did I know that in the 2010's, long after Windows
stopped being important, the Linux developers would for some reason
start skewing everything toward first-time users, at the expense of
productivity for the experienced.
As far as booting being complex, what's the problem? Initialize the
TTY's, load the device drivers, bring up the daemons in the proper
order, which could be fairly reliably defaulted for the average user,
and reordered for those needing a special setup. If something is
blocking the boot, address that one blocking step. I see no need for
multi-threaded (or whatever you want to call it) init. Not if it
changes the entire operating system.
>
> > > Imagine if they replaced grep, cut, cat, diff, awk, sed, head,
> > > tail, ls, and find with ks (stands for Kitchen Sink). You can do
> > > anything you want with ks, but you need to know all its options
> > > and config settings, and its myriad of idiosyncracies.
>
> Instead we have to know the different options and config settings for
> a couple of dozen different tools and deal with all the myriad of
> idiosyncrasies created by any possible interaction between them.
> Thanks, but no thanks.
This is where we differ. I'd rather have building blocks from which I
could build anything, rather than a monolith I need to trick into doing
what I want it to do.
>
> > > And if it has bugs or
> > > departures from documented behavior, as any program of its
> > > size is likely to have at one time or another, everything breaks.
> >
> > Hey, a sparkling idea. We could call the program "busybox" and try
> > to get it into d-i. Now, would it catch on elsewhere?
>
> I was going to say perl :p
And you would have been 100% right. As you build your subsystem using
grep, cut, cat, diff, awk, sed, head, tail, ls, and find, there will be
small parts that those tools can't do without massive kludging. That's
the time to use a few lines of Perl (I prefer Python, but you know what
I mean), or C. And you have PRECISELY what you need, no need to fight a
gigantic Swiss Army Knife application.
I guess it's a philosophical difference. From my perspective, give me
the tools and a language to code in, and I'll take it from there.
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
Reply to: