Only by not using subordinate clauses did you just avoid saying "plan 9" and "commercial" in the same sentence! Where is Plan 9 deployed? Who are the customers?
Plan 9 is a strawman representative of "commercial Unix".
> Combine a few GNU core utils, and you have more code than the whole plan 9 kernel.
When you actually sit down and think of the cases that can occur, that translates into code. Handle this, handle that, and the KLOC's just pile up.
Speaking of kernel size, what makes a kernel code base big? Why, device drivers for lots of hardware.
Lucent use a real time version of plan9 in phone masts
Coraid use Plan9 on their NAS servers
Researchers at LANL and IBM use plan9 on the Blue Gene, and other, supercomputers
I have worked for two plan9 based companies - ok they didn't survive but we tried :)
The international plan9 conferences drew about 30 people. People from commercial enterprises used plan9 in their workflows. Plan9 was my desktop while building a successful recruitment website.
Literally halfs of dozens of research projects and ones of promotional installations served! Nearly threes of dozens attended conferences, at which twos of booths were no doubt tabled, perhaps both by you, one of the only persons who apparently used Plan 9 commercially.
I'm feeling nostalgic enough to go launch an inferno instance now just on principle.
It's unadopted, but this does not mean it is bad. GNU/Linux is the worst of all and survives only because it's widely adopted, and better-marketed. Many who turn to Unix world first encounter GNU/Linux. GNU/Linux is, quality-wise, inferior to both Plan9 and BSDs, it's a big hack, but it came before, and got adopted first.
Now I downvoted all your comments in this thread for they are unconstructive both in the negative and the positive directions. This is a fanboy-like attitude, where you ignore the fact I explained above, and attack other comments. You take quantity over quality.
BSDs and other systems have their user bases. Those may be small, but they exist. Both GNU/Linux and BSDs are inferior to the ideal system where most legacy cruft shall be gone, but in order to reach that ideal system we should develop the research projects, the ones with little-to-no use. E.g. Plan9. Or microkernels. The all-utf8 approach is perfect, but it can't easily propagate to the mainline if it is not tested for long in research projects, and the ecosystem adapts in this timeframe. So we'd rather not attack them, but let them happen. They'll always be better than mainline, but lesser-adopted, but when they die, the good parts of them will propagate to GNU/Linux, BSD, etc. Take ZFS for example, it was developed on a Sun system, it's not widely adopted, but its now on FreeBSD and Linux (i.e. btrfs, the same concept), for you to enjoy. Or the research in functional languages. Many of those are not adopted, but many features are now propagating to mainline languages.
"BSD purged copyrighted AT&T code from 1989 to 1994. During this time various open-source BSD x86 derivatives took shape, starting with 386BSD, which was soon succeeded by FreeBSD and NetBSD."
BSD was an OS long before 1989; the open-source BSD's weren't new projects written from scratch, but made possible by purging AT&T copyrighted code from the code base.
Linux (the kernel) only started in 1991, from scratch. The GNU parts that go into a "GNU/Linux" --- the GNU C compiler and utilities from the GNU project --- started in 1984. But that is still later than BSD. 1BSD was released in 1978: [https://en.wikipedia.org/wiki/Berkeley_Software_Distribution...]
Seriously, it should be obvious that BSDs mean, in the context of my comment, modern BSDs. The GNU/linux environment was practically usable before those were. Your comment is pure evil rhetoric.
Hey, this isn't really a direct response to any of the points you made, but I've been thinking about your get-rid-of-the-tty comment, and wanted to ask.
What is your take on syntax highlighting in a plan9 world? I've read a list of questions somewhere about p9, and remember this one being asked and having a typically abrasive response, along the lines of "just don't". And I often have a lot of time for those kind of arguments - embrace minimalism. But I regularly (daily) find syntax highlighting to be super-useful for highlighting small errors. What's your take? It seems like a regex-ey problem. Could it be done in a way that was within the spirit of such a system?
Do you even know what coreutils is? It is not openbsdutils. It is not plan9utils. It is not even linuxutils. It builds and runs on virtually every deployed vaguely POSIX-ish environment and then some.
Can I take the OpenBSD userland and untar, configure, build and run in cygwin? Nope. You have proven my point. Nobody uses the little SYS V version.
One hint as to why the GNU version is so "long" and "messy":
/* System V machines already have a /bin/sh with a v9 behavior.
Use the identical behavior for these machines so that the
existing system shell scripts won't barf. */
bool do_v9 = DEFAULT_ECHO_TO_XPG;
It has to run in environments that others do not in order to provide full functionality, so it has to implement that functionality.
And Unix Fifth Edition, imbued with the cleanliness of Ken Thompson's ghost? Yeah, that's lovely, but not only is it again, of limited utility and portability across idiosyncratic modern environments, but it's full of bugs dating to an era where simplicity was valued above handling all inputs. In 1983, crashing on a bad input wasn't even generally understood to BE a bug, much less extremely dangerous especially in core system utilities.
I've used the -e option in GNU's echo many times. The various other versions are strictly less useful to me.
Does the option really belong in echo? Who knows, but it's certainly been useful to me.
UNIX fifth edition goes for absolute minimalism. Echo in Plan 9 is apparently used enough that it's worthwhile to optimize the number of times write is called. FreeBSD echo looks like someone just learned about writev. OpenBSD's seem like the sanest of the minimalists.
For many people, from the writers of the Single Unix Specification to the Debian Policy people, the take-away was and is use printf, for nigh on 20 years now.
I've used -e on GNU's `echo` quite a bit as well. But FreeBSD also supports `printf` (as does Linux by the way), so it's not a great inconvenience the missing -e flag on FreeBSD's `echo`.
$ printf "This\tis an\nexample\n"
This is an
example
You can also use the usual C-style printf parameters as well:
$ printf "This is %-20s example\n" another
This is another example
As a result, the specification for echo is a ridiculous mess which deviates from the other POSIX utilities. It doesn't have the normal command argument handling, and also has implementation-defined behaviors. It's a good command to avoid in serious scripting, other than for outputting fixed, alphanumeric strings.
That said, it's useful to have features like C escape sequences for control characters or arbitrary characters. That feature should be in the shell language. Someone needed it and hacked it into some version of echo. Others elsewhere didn't and so now it's implementation defined whether or not you get backslash processing.
Plan 9 is a strawman representative of "commercial Unix".
> Combine a few GNU core utils, and you have more code than the whole plan 9 kernel.
When you actually sit down and think of the cases that can occur, that translates into code. Handle this, handle that, and the KLOC's just pile up.
Speaking of kernel size, what makes a kernel code base big? Why, device drivers for lots of hardware.