On Fri, 27 Oct 2017, Clem Cole wrote: Well, yeah. Has M$ Word even really gotten much in the way of new features since version 6 in the early 1990s? But it's sure gotten bigger... And that seems the way of software in general. -uso.

On Fri, Oct 27, 2017 at 11:51:12PM +0200, Andy Kosela wrote: We cared. We being the BitKeeper guys. BK as of 2002 (bk-2.0.5): 33 documented commands wc *.c 67633 225563 1565556 total BK as of 15 years later (bk-7.3.2) 165 documented commands wc *.c 125812 444197 3017977 total So we doubled in size for all the built in commands but we had 5x as many commands. A huge amount of functionality over the bk-2.x era. The only way we did that was by encouraging and rewarding commits that took out as much as they put in. It's possible but you have to be disciplined. --lm

This is half-way (and perhaps more than that) to what the 'worse is better' paper would call 'the MIT approach'. I think it's fairly obviously the right thing, and equally obviously almost never done. --tim

But if you try to turn Plan9 into a lean UNIX, you lose everything that Plan9 advocates. In particular, I don't see how you can possibly integrate namespaces into UNIX in any meaningful way. Without those, it's no longer Plan9, and therefore a pointless endeavour. The release of the 10th Edition UNIX source is much more enlightening. Here you can see a fully functional UNIX with what, 29?, system calls? And you can see the genesis of many of the Plan9 concepts (/proc, dial(), mk, mux, etc). --lyndon

On Fri, 27 Oct 2017 19:34:11 -0700 Lyndon Nerenberg <lyndon(a)orthanc.ca> wrote: Lyndon Nerenberg writes: As you may know I have been a 9fan for a long time & would love if plan9 became mainstream. But I just don't see any hope of a wider acceptance of Plan9. My perception is that plan9 itself has not evolved a lot in 20-30 years. May be its original structure is good enough or may be it just hasn't had a large enough set of innovative users. The small group of plan9 users continue to mostly use the stuff built by the Bell lab guys. I think it would be a real shame to see plan9 become a relic. The road not taken. Would be nice if we can do something about it. IMHO, the best hope to keep it alive is to pull a reverse C++ trick! C++, which is now a much more complex beast of a PL, initally got accepted because "it was compatible with C". So the idea here is to provide a Unix compatible (complex) API as a library to allow running a lot of existing s/w and entice people to write new s/w to a simpler but more composable API. It won't make plan9 advocates happy and it won't have a "plan9" API but this seems doable to me. Start with the Plan9 kernel so you've already got process centric and mountable namespaces. Next "port" linux or freebsd API. Write a set of library functions that implement various Unix API calls by calling on the plan9 API. Mutate the latter as necessary. [As an example, if 9P is found lacking, enhance it or replace it] This is not unlike implementing linux API on top of a microkernel. Concurrently port some kernel resident critical subsystems from Unix to become user mode programs communicating via 9p (or its child). All the while keeping an eye on performance and complexity. If done right, I think we can do away with containers & jails for cloud based s/w, without any loss of security.o So that is my pipe dream! I don't know much about it. In a separate message you wrote: That is the "dieting" approach. Much harder as you have to constantly watch out you haven't broken anything. But if you start with plan9, ioctl() is already gone! However, it can be implemented as a library function for dusty decks.