[wmii] sh flame with Uriel

Uriel,

if you got any problems with others, please differentiate
between me and those others. I had no influence if something
went wrong at FOSDEM. I have much respect that you gave a talk
about Plan 9. It will improve your experience and presentation
skills, regardless how well it went.

To the sh-flame in the morning, I have to clarify my standpoints
and to ask you several questions, that is why I CC this mail to
wmii_AT_wmii.de as well.

Background for non-IRC readers: Uriel offended me that I decided
to abandon 9base, especially the switch back to sh.
Because it ended as flame, there weren't much arguments,
that's why I write this mail.

Referring to wc we have 284 lines of sh-code (and
296 lines rc-code in extra/p9p). I don't expect that the amount
of lines will change drastically in the future.

1. So, do you think that 300 lines of shell script code justifies
at least ~40kSLOC of additional dependencies by _default_? (With
a 9base merged into p9p I expect ~60kSLOC at least.)

2. Is the maintenance effort of 9base(p9p merge) worth the
prize, if we only got 300 LOC of rc code not expecting more?

3. With respect to that, isn't it a fair deal if someone
wants to use rc, that he should install plan9port (instead of
abandoned 9base)?

(Plan 9 lovers have installed plan9port already, so they can
just use the rc flavor scripts, even if they won't be officially
maintained.)

4. If you don't like sh, then can you explain us the reasons
which justify to depend on plan9port[-base] for 300 LOC rc code?
Please provide technical reasons.

5. Do you expect that maintaining a merge-in of 9base into
plan9port is lesser effort than maintaining the extra/p9p
scripts to be used in conjunction with plan9port, maybe even
plumber based?

6. What have been the problems with wmii-2 rc subsystem? Do you
think it sucks because of GNU+/bin/sh software usage or because
of architectural reasons (remember rc reload foo abominations)?

With respect to 6. I have to claim that the current wmiirc rc
subsystem is a totally different architecture, regardless if sh
is used or not.

7. Do you request, that I shall do the merge of 9base into
plan9port (9base already works fairly well), that you feel
better because of rc scripts as default and all others are
forced to install plan9port[-base]?

8. If you agree to 7. then I ask, what is your justification
that you request it and what is wrong requesting that you
maintain the rc scripts using rc shell instead for plan9port?

9. Which effort might be lesser expensive, maintaining the rc
scripts, because you can't live with /bin/sh, or maintaining
plan9port-base?

10. Is it simplicity to have two different userlands on a legacy
Unix box?

I had good reasons to use 9base in the 2.5.x series, because it
contained architecture-related bottlenecks (through the heavy
IPC modularization and spawn-based event handling *crap*) and
9base worked around these bottlenecks, because it performed
around 500% faster than the dynamic linked default userland.
Anyway, these architecture-related bottlenecks do not exist
anymore in current, thus there are no performance issues.

Other good reasons have been a nicer shell syntax (subjective)
of rc and much simplier/saner userland tools which don't consist
of GNU bloat.

11. But does this really justifies making 300 LOC dependent from
40kSLOC at least?

12. Won't it be much better to concentrate the efforts onto
plan9port to package/port it for various distributions/BSDs?

I also abandon the mk-switch, because referring to wc, we
got 219 lines of make-related stuff in the complete source tree.
Like /bin/sh, we use a very portable make-dialect, which works
with GNU make and BSD make at least (though Sun make is known to
also work well).

13. Is it worth the effort to switch to mk just for 219 lines?
Forcing people to install mk first, which depends on make as
well (to build it under Unix)...

14. Is this Lunix or Plan 9?

Now I'm curios, how your answers might sound.

If wmii would be a bloaty environment like KDE/Gnome, I would
definately depend on plan9port.

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361