I'm tending to think you intended these as rhetorical, but I'm also
inclined to believe that many on the list won't see what we wish was
obvious, so I'm going to respond.
On Sat, Sep 20, 2014 at 2:08 AM, Reco <recovery...@gmail.com> wrote:
> On Fri, 19 Sep 2014 11:36:58 -0500
> "T.J. Duchene" <t.j.duch...@gmail.com> wrote:
>
>> Why is it not possible to create a completely generic shell script -
>> basically ala SysV that can parse systemd config files for those use cases
>> where Systemd is undesirable?
>
> Everything is possible.
Or, rather, many things are possible.
> Yet your question brings bunch of another, much
> more important ones:
>
> 1) What's the point of re-implementing systemd in shell? What about
> other programming languages, why they're unsuitable for this?
If we were asking about the implementation of a replacement for init,
shell has the advantage that it provides a run-time that we know will
be available, and we are fairly confident will behave itself.
perl has a tendency to do unexpected things. (I like perl, but I have
to admit that its tendency to try to read my mind goes a little too
far sometimes.)
Ruby and Python can't be guaranteed to refrain from internal
housekeeping when you can't afford it. Scheme, Haskell, etc.,
likewise.
FORTH is too hard to keep sane. (FORTH is one of my top three favorite
languages, but FORTH, List, Smalltalk and similar languages are so
customizable that they tend to _be_ customized precisely where and
when you don't want them to be when they are interpreting your pid 1
process. Well, actually, you could do it with a specific dialect of
FORTH, but you would be replaying the problems we had with the various
shells as we evolved them -- sh, ... csh, ... ksh, bash, et. al., ...
dash. And you would be fighting with a lot of FORTH traditions in the
process.)
C++ has the same kinds of problems as FORTH, except that it has a much
larger community and the problems are better known. And it tends to
balloon, in terms of run-time and generated code, a lot more than
FORTH.
Which basically leaves ADA or C. Neither of which would be evil, but
both of which are significantly less customizable than the shell of
the distro, dash in our case.
And one of the advantages of sysv-init is that a competent shell
programmer who understands system administration principles (and even
many end-users, relative to their workstations or home computers) can
customize init. Preferably, through the distro-provided methods, but,
when necessary, by tweaking the code of init itself.
Neither C nor ADA source code is nearly as amenable to customization
as shell scripts. C, in particular, tends to have usage issues similar
to dialect issues in human languages, and those usage issues can
quickly leave people who haven't been steeped in the project's
culture, history, etc, in the dark.
Which usage issues are a big part of the opacity issues with systemd.
> 2) Who will implement it?
Well, if I had been able to make more time, my first small steps would
be hitting sourceforge or github about now. Having a day job does make
it harder to keep up with people who have been hired by RedHat to do
open source.
(I'm planning to check out daemontools before I get too deep, however.)
> 3) Who will support it?
Yep. We are they.
> 4) Why re-implementing systemd? Writing your own init is much more fun,
> as [1] shows to us.
:-)
>> What systemd does is basically a generic process of reading parameters from
>> a file and using them to start a service.
>
> That's one thing of many that systemd actually does, moreover, the list
> of such things changes constantly. Some call it a 'feature creep',
> others call it a 'development'.
>
>
>> Granted, this approach would
>> have the benefits that systemd has, but the concerns about systemd being
>> too opaque or monolithic could be almost mitigated.
>
> Whenever systemd is 'opaque' or not is in the eye of the beholder.
> Systemd is not monolithic, and that's the main obstacle to anyone who's
> willing to re-implement it. The best description of systemd would be
> 'a bunch of small parts each one depending on several others parts'.
How does one define "monolithic"? 35 years or so back, there was a
term that unfortunately has faded from popularity:
implicit linkage
It was intended to describe the hard-to-see inter-dependencies and
shared implicit assumptions that have always been part of any software
project. The global variables and constants, sure, but such things as
the types and ranges of accepted values that tended to be assumed, and
even the assumed protocols, such as in constructor and destructor
patterns.
Part of the theory behind the term was that the level of implicit
linkage was the primary determinant when you needed to tell if
something were monolithic or not.
>> The remaining concerns such as login and so on can be addressed separately.
>
> I don't intend to sound harsh, but - there's no known working 'e-mail
> wishes → actual code' generator. So, if you believe that you idea is
> worth something, why don't you show a shell script that implements
> your idea on some level?
>
> [1] http://wiki.openwrt.org/doc/techref/procd
>
> Reco
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/caar43imwbvcoskdqazsepviojeuinu8h-rohj46wgxubzj4...@mail.gmail.com
