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 [email protected] 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 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
