Re: Long filenames in DOS server

>> I'm also looking over the Plan 9 stuff. I'll write up some initial
>> observations in the next week.
>Anyone have any comments? I couldn't get plan9 to run on my machines.

Ok...

Note that most of my comments relate to the kernel itself. I ported their
troff over to VSTa, and it runs *way* faster than groff; it's also written
in C (coincidence? :->). I realy like having access to the original, lean
implementations of all those classic UNIX commands!

The VM system had all the smell of a crock when they first wrote their
papers. If they've released their latest code, then it hasn't improved with
age.

In general, I'm surprised at the lack of workman-like coding in this kernel.
The leaders were old hands, and I know for a fact that Ken Thompson is one
of the best programmers in the industry. But the kernel code is in general
sloppy, poorly commented, and inconsistent.

My real complaint is that it's a warmed-over V7 kernel, except for the
distributed aspects. But if you focus in on the distributed aspects, it
gets choppy really quickly. Filesystem access is OK--but we've had that for
a whole bunch of years now. The core of a distributed system is how you
cause work to be done, but basically none of the process creation/setup is
integrated into their distributed filesystem semantics.

It has SMP--good. It kinda has the look of somebody's first SMP OS,
though--bad. This matches up with their paper on SMP support, where they
show how they attempted to code up an MP-safe algorithm, and failed. Both
the VM system and the SMP support should probably be done over again, based
on what they've learned.

Plan 9 doesn't claim to be a microkernel, but it's pretty small as "regular"
kernels go. Having the filesystem abstraction served by processes keeps the
doors open for things to stay out of kernel space. IP has been both in and
outside the kernel over time in Plan 9. Personally, I believe that if you
have a filesystem served from within your kernel, you've missed the break of
mechanism and policy. Kernels do mechanism; policy happens elsewhere. The
Plan 9 kernel has tons of policy, security, and device cruft down in the
kernel.

Part of this is that although the kernel can do SMP, it can't do preemption
of kernel code sequences. So anything which needs timely servicing goes in
the kernel, which lengthens the code paths, which degrades latency, which
causes more stuff to need to be put in the kernel. It's a slippery slope.

I'd like to hear more about the license. My eyes glazed over part of the
way down the license, and then I saw the GPL at the bottom. What have they
slipped in that might be a problem?

Thanks,
Andy Valencia
Received on Tue Jul 18 08:56:43 2000