Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg <embe8573@student.uu.se>]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

>> init is, I think, a remnant of AT&T's UNIX System
>> V. init has been around on Unix systems a long
>> time, including Linux systems. init is functional
>> but very heavy-handed and hackish in style - for
>> example, running system userspace startup (and
>> exit) processes - and in what order - relies on the
>> file*names* of scripts!
>
> You call it hackish, but I find it is an essential
> unixism. Using the file system as a database for
> unix administration data, keeping other unix
> adminstration data in simple text file tables
> (instead of more sophisticated, but also much more
> brittle databases (think for example, the various
> versions of Sun NIS (Yellow Pages), NeXT/Apple
> NetInfo, and now Directory Services (how long will
> it last!?)).
>
> This is essential to keep unix administration data
> in simple text files, and possibly in structured
> directories (ie. with file names encoding things
> like order of loading or others), because this is
> what gives unix its discoverability and ease of
> administration (and ease of writing administrative
> tools).
>
> On the other hand, I don't mind people developping
> non-unix systems, using a unix kernel and adding
> layers, such as Android. But that should not trample
> upon a true unix system.

Don't even true unix systems have to change?

But I don't think init is bad. The script name
solution isn't what we expect today when we hope to
just add or remove stuff regardless of what is already
there, but I have mucked around with that myself and
it was straightforward with the runlevels as
directories and "services" (?) as scripts. (Yes, that
is a very Unix solution.)

>> So because of some child-diseases and other
>> obstacles that were to be expected, there has been
>> a constant ruckus and never-ending hullabaloo where
>> many people - including those that should probably
>> focus on their stuff - have expressed dislike in
>> unpleasant ways.
>
> I've not looked at systemd too closely, but AFAICS,
> the problem is not child-diseases, but more that
> it's not enough unixy. It's kind of like launchd on
> MacOSX, and, while I must admit that launchd finally
> seems to work satisfactorily, I wouldn't say that it
> plays nice from a unix point of view.

I got systemd to work almost instantly the way init
did, but it was more complicated than init as I had to
wade through scripts with code that I didn't
understand, and then add a couple of lines. It worked,
but init is more clear for my purposes. But I would
suspect systemd brings something to the table for
those who does this more often and thus take the time
to understand the new system. Actually it is enough
for me that Debian opted for it: I trust them.

>> And now, classy old Debian has forked again!
>
> Ubuntu forked from Debian and it's not a bad thing
> (arguably).

Forking is not a bad thing conceptually, it is rather
it should be done when an all-but undividable piece of
software is at a crossroad and people want to take
different roads.

For example, let's say there is code for a basic
calculator. Some people want to keep it simple (keep
it as it is), some people wants to do a GUI and make
it a plotter as well, and some third people want to
stick with CLI but extend it into a scientific
calculator with e and powers and all.

Now, what I would do is: do *all* of that, and then
have it configurable! But OK, a fork is a good option
as well because then the basic code can be reused.

On the other hand, when I am against forking (as an
opinion, of course I'm not saying it should be
hindered in practice) - when I am against forking is
when the fork is on some big system, but is due to a
small software component that should be all modular
already.

So forking systemd to do a different systemd (let's
call it systemd2) is OK, but not to fork Debian
because some people prefer systemd to systemd2. Why
not just make it optional?

Forking OSs (distros) involves so much overhead it is
much better to put that time into (modular) software.
That would get us better software and people would be
more inclined to compose their own systems *within* a
system. So instead of distro hopper we would have
better computer users as well.

-- 
underground experts united