[9fans] alright, this should be interesting

[9fans] alright, this should be interesting

[andrey mirtchovski]

slashdot interviews rob pike (only the questions part):

http://interviews.slashdot.org/article.pl?sid=04/10/05/1537242&tid=189&tid=156&tid=130&tid=11

Re: [9fans] alright, this should be interesting

[Kenji Okamoto]

> slashdot interviews rob pike (only the questions part):

I don't agree with you, Andrey.

How much did the Slashdot pay to Rob for this interview?
I suppose they didn't.   If so, why Rob has to reply to those not
so interesting questions?   It's something like public threat to him...

If anyone want to make interview to someone, s/he must make
apointment before to make it public.   This is the very basic rule
to make interview, I think.

Kenji

Re: [9fans] alright, this should be interesting

[andrey mirtchovski]

>> slashdot interviews rob pike (only the questions part):
> 
> I don't agree with you, Andrey.
> 
> How much did the Slashdot pay to Rob for this interview?
> I suppose they didn't.   If so, why Rob has to reply to those not
> so interesting questions?   It's something like public threat to him...
> 

interviews on slashdot are pre-arranged.  i believe Robin Miller, who,
besides slashdot interviews, handles newsforge.com has already sent a
message to Rob Pike and they have agreed on an email interview.  the
only way to request an interview is to submit the request as a
slashdot story.  Rob can prove me wrong if indeed nobody has contacted
him for an interview and this whole thing is a load of, well, crap (or
dingo's kidneys) :)

slashdot is applying the moderation scheme to find out what everybody
else thinks are the best questions.  the 10 moderated highest by the
slashdot users themselves get to be sent to the interviewee.  it's a
kind of an 'open source' approach to interviewing which mostly works
the sane part of the slashdot populace prevails in most cases and you
end up with reasonable questions.  if a really good question gets in
late, there's no chance for it to be picked up unfortunately.

andrey

ps: there are some interesting questions there whose answers i'd like
to know myself.  most of the people were cheated by the 'co-creator'
tag though, or had little factual knowledge of plan9.  things like
"plan 9 is a microkernel combination of unix and multics' ideas",
"when are you going to make plan 9 distributed?", or "plan 9 was
written in Alef" can definitely be observed first-hand :)

Re: [9fans] alright, this should be interesting

[geoff]

Not to mention the usual inaccurate, fourth-hand knowledge found on
slashdot being passed off as conventional wisdom.  12-character
file-name components, my fanny!  Can't they even be bothered to look
at the freely-available v6 or v7 sources?  (and I believe that should
be ``load of *old* dingo's kidneys''.)

Re: [9fans] alright, this should be interesting

[C H Forsyth]

>>If anyone want to make interview to someone, s/he must make
>>apointment before to make it public.   This is the very basic rule
>>to make interview, I think.

there is a pleasant ploy, along these lines:
freelance journalist rings up famous person A (or rather A's agent) and
says ``I'd like to interview you for The Times'', and
having obtained agreement (which was likely, The Times being at the time
suitably august), rings up The Times to ask ``Would The Times
like an interview with famous person A?''.

it can't work as well as it once might have done, because of Google(tm):
A's agent almost invariably googles journalist's name to see whether
they are indeed a staff writer as implied and what sort of
writing they do.

Re: [9fans] alright, this should be interesting

[Leo Caves]

Rob's "interview" is now available on slashdot

http://interviews.slashdot.org/interviews/04/10/18/1153211.shtml? 
tid=189&tid=156&tid=130&tid=11

Re: [9fans] alright, this should be interesting

[Kenji Okamoto]

> Rob's "interview" is now available on slashdot

I've just read that long documents (answer and questions).
Rob answered sincerely to those who are considered not to be
professional (like myself☺).

All the answers are not new to me though.   Probably, I've been
engaged in Plan 9 too much...

Kenji

Re: [9fans] alright, this should be interesting

[Ronald G. Minnich]

> All the answers are not new to me though.   Probably, I've been
> engaged in Plan 9 too much...

One thing I disagree with (in our context) is that kernels don't matter.
For what we do, they matter a LOT. And in the commercial world, kernels
matter tremendously, such as in embedded applications. There are companies
determined to build from-scratch kernels so they can have a "proprietary
advantage"; there are others just as determined to use Linux Inside
because they don't have the resources to do their own. It's economics.

In the general case, for desktops and laptops and such, however, it may
well be true that kernels don't matter. 

ron

Re: [9fans] alright, this should be interesting

[Dave Lukes]

My 2¢ worth:

 > In the general case, for desktops and laptops and such, however, it may
 > well be true that kernels don't matter.

Well, yes and no.

Kernels are also important in the sense that they set the tone for 
everything above them:
kencc wouldn't have happened on linux, for example.

In the same way, although I work day-to-day on MaxOSX, linux, etc.,
I hope that some of the neat ideas from all of plan9, such as uniformity 
of resources,
permeate what I do.

DaveL.

Re: [9fans] alright, this should be interesting

[Tim Newsham]

> Well, yes and no.
>
> Kernels are also important in the sense that they set the tone for
> everything above them:
> kencc wouldn't have happened on linux, for example.

The "personality" can be completely isolated from the kernel.
It is possible to provide the complete plan9 API above windows
or linux or any other reasonable kernel.  It wouldn't be efficient,
and you may have to bend over backwards in a few places if using
some APIs (ie. see cygwin's implementation of fork and select
using only the win32 api), but it is possible.  So in this sense,
I'm not sure I agree with you.

> DaveL.

Tim N.

Re: [9fans] alright, this should be interesting

[Ronald G. Minnich]

On Tue, 19 Oct 2004, Tim Newsham wrote:

> 
> The "personality" can be completely isolated from the kernel.

yes it can, and no it can't. 

Simple one: how do I get the name of the last user to change a file? I 
don't think I can get that in linux but it's there in 9p. 

Yes, there's a host of stuff you can do in emulation in libraries etc.  
but there's also things that just never quite work right. So you can do
it, and it's good to do it to socialize the ideas (that's what "Software
Tools" did in many ways for Unix) but it's still not the real thing in the
end.

ron

Re: [9fans] alright, this should be interesting

[Charles Forsyth]

one aspect of `personality' can be hard to emulate,
and that is ease of getting the whole system to be
more nearly correct (and maintainable, given that the
underlying system that's doing the emulating might constantly
be changing, with independently changing variants).
it's the old problem of trying to build a sturdy reliable thing
on top of lots of wobbly bits (``they said i was daft to build
castle on swamp, but i built it all the same, just to show them'').
mind you, i suppose that's essentially what is done when an effective
distributed system is built on top of lots of cheap components that
often break down and fall into the swamp.

Re: [9fans] alright, this should be interesting

[Dave Lukes]

> (``they said i was daft to build
> castle on swamp, but i built it all the same, just to show them'').
> mind you, i suppose that's essentially what is done when an effective
> distributed system is built on top of lots of cheap components that
> often break down and fall into the swamp.

Well ... you haven't quite extended the analogy far enough.
The distributed system is city built on a large raft floating on the 
swamp,
so if some odd bits fall off and some peasants die: so what?

As long as either
a) there's enough distributed control (it's a 
democracy/anarchy/whatever) or
b)  the central part of the raft containing the castle (i.e. the grid 
controller or whatever)
    is built on huge mushroom pilings, so it never falls into the swamp,
the city(system) will keep on functioning.

I can't believe I'm sending an email to 9fans talking about mushroom 
pilings.
Can we get back to plan9, before I start ranting about shield anchors, 
please?

DaveL.

Re: [9fans] alright, this should be interesting

[Tim Newsham]

> > The "personality" can be completely isolated from the kernel.
>
> yes it can, and no it can't.
>
> Simple one: how do I get the name of the last user to change a file? I
> don't think I can get that in linux but it's there in 9p.

Easy.  You run a different filesystem.  The filesystem is not
dictated by the kernel.

Simple one: have a p9 userland with a 9p implementation that
uses a remote file server.

> Yes, there's a host of stuff you can do in emulation in libraries etc.
> but there's also things that just never quite work right. So you can do
> it, and it's good to do it to socialize the ideas (that's what "Software
> Tools" did in many ways for Unix) but it's still not the real thing in the
> end.

I can't think of anything that you cant do right.  That may just be
my own shortsightedness.

> ron

Tim N.

Re: [9fans] alright, this should be interesting

[Steve Simon]

One could emulate plan9 on any OS by linking each program
with a stub library which provides file accesses as
IPC calls to a plan9 suporvisor program.

As plan9 applications access all resources via files so,
if you emulate file access you emulate the whole enviroment.
This is similar to cygwin but the job is simpler as there is
a nice abstraction layer between the app and the suporvisor.

Of course if you use import(1) to share files between these emulations
you can share the emulated resources, just like The Real Thing (tm).

There could be a shortcut in the file emulation library for
direct access to physical files as a speedup but it wouldn't be
required in the first pass.

Sorry if this is all obvious to everyone, and doubly sorry
if this is exactly how the plan9 ports works, I use the ports
occasionally but I have never looked "under the hood".

-Steve

Re: [9fans] alright, this should be interesting

[Russ Cox]

> As plan9 applications access all resources via files so,
> if you emulate file access you emulate the whole enviroment.
> This is similar to cygwin but the job is simpler as there is
> a nice abstraction layer between the app and the suporvisor.

> There could be a shortcut in the file emulation library for
> direct access to physical files as a speedup but it wouldn't be
> required in the first pass.
> 
> Sorry if this is all obvious to everyone, and doubly sorry
> if this is exactly how the plan9 ports works, I use the ports
> occasionally but I have never looked "under the hood".

Just FYI, it's not, for the most part.  The 9pm stuff that
seanq did was a bit closer to this, and an intermediate
step between 9pm and the ports that I did a few years
ago behaved almost exactly like this, with a separate
"9kernel" process that all the ported apps talked with
to execute "system calls".  But I found the debugging 
tremendously frustrating (bugs in the kernel brought 
everything down) and the amount of integration didn't
seem necessary.

In the current ports, each process is on its own as far
as the rest of the system is concerned, and code has been
rewritten (mostly in libraries) to accomodate the base 
systems where needed.

Russ

Re: [9fans] alright, this should be interesting

[Ronald G. Minnich]

On Tue, 19 Oct 2004, Tim Newsham wrote:

> Easy.  You run a different filesystem.  The filesystem is not
> dictated by the kernel.

but the stat structure is.

> Simple one: have a p9 userland with a 9p implementation that
> uses a remote file server.

ditto.

ron

Re: [9fans] alright, this should be interesting

[Ronald G. Minnich]

On Wed, 20 Oct 2004, Ronald G. Minnich wrote:

> 
> 
> On Tue, 19 Oct 2004, Tim Newsham wrote:
> 
> > Easy.  You run a different filesystem.  The filesystem is not
> > dictated by the kernel.
> 
> but the stat structure is.

although what you can do is put this extra junk in the extended 
attributes, now that I think of it. xgetattr or some such.

ron

Re: [9fans] alright, this should be interesting

[boyd, rounin]

> but the stat structure is.

bingo.  i was waiting for that.

Re: [9fans] alright, this should be interesting

[Tim Newsham]

> > Easy.  You run a different filesystem.  The filesystem is not
> > dictated by the kernel.
>
> but the stat structure is.

The one used by the kernel's stat syscall is.  But you're
not obligated to use it (or the kernel's filesystems, for that
matter).

> ron

Re: [9fans] alright, this should be interesting

[Ronald G. Minnich]

On Wed, 20 Oct 2004, Tim Newsham wrote:

> The one used by the kernel's stat syscall is.  But you're
> not obligated to use it (or the kernel's filesystems, for that
> matter).

then you're into emulating the kernel VFS layer outside the kernel, which 
is ok, sort of like trying to the candy bar without removing the wrapper.

Seriously, that approach has been done to death for almost 30 years now,
it works ok, but the limitations at this point are pretty well known. Not
saying you can't do it, I did v9fs on freebsd and linux in user-mode
libraries; at the same time, with the advent of versioned symbols in gcc
libraries, it's kind of a pain in the a@@. Versioned symbols is when I
stopped supporting it.

Plus, you get the wonderful situation that all your file systems start to 
act a little different, depending on where you type 'ls'. 

I'm assuming you've done this a few times?

ron

Re: [9fans] alright, this should be interesting

[Dave Lukes]

Tim,
You are missing the point of what I said:

>> Kernels are also important in the sense that they set the tone for
>> everything above them:

In other words, if you have a crufty kernel, you'll have a smelly  
compiler,
and vice-versa.

>> kencc wouldn't have happened on linux, for example.

i.e. if you have just implemented the 15th optional parameter to
the  
asynciowithorwithoutsignalandoptionalscattergatherfromthe19thaddresszone 
() system call,
which supplies a bitmask of signal numbers and the days of the week on  
which to send them in the event of there being a 'c' in the month name,
then adding the  
__asm____stuff___3_registers_and_a_status_mask_up_your_nose() inline to  
gcc to make it run 10 times faster
seems like a ReallyGoodIdea(tm).

> The "personality" can be completely isolated from the kernel.

Yes, but you've still gotta struggle through six piles of elephant  
excrement to get there,
by which time your brain is soup, and you're muttering about how to  
implement a 15th way to map
all the odd-numbered framebuffers into someone else's address space.

> It is possible to provide the complete plan9 API above windows
> or linux or any other reasonable kernel.  It wouldn't be efficient,
> and you may have to bend over backwards in a few places if using
> some APIs (ie. see cygwin's implementation of fork and select
> using only the win32 api), but it is possible.  So in this sense,
> I'm not sure I agree with you.

Well, we're talking oranges and (Posix-compliant) apples, so it's hard  
to agree:
you're talking about implementations, I'm talking about philosophical  
approaches to problem solving.

Cheers,
	DaveL.

Re: [9fans] alright, this should be interesting

[Tim Newsham]

> Tim,
> You are missing the point of what I said:

I must be, because I still dont agree with your point.

> In other words, if you have a crufty kernel, you'll have a smelly
> compiler,
> and vice-versa.

Why?  You could build a fresh smelling compiler like 8c/8a/8l.

> >> kencc wouldn't have happened on linux, for example.
>
> i.e. if you have just implemented the 15th optional parameter to
> the
> asynciowithorwithoutsignalandoptionalscattergatherfromthe19thaddresszone
> () system call,

You don't need to change any of the system calls to build an emulation
layer.

> which supplies a bitmask of signal numbers and the days of the week on
> which to send them in the event of there being a 'c' in the month name,
> then adding the
> __asm____stuff___3_registers_and_a_status_mask_up_your_nose() inline to
> gcc to make it run 10 times faster
> seems like a ReallyGoodIdea(tm).

You dont have to play with gcc/gas cruft either.

> > The "personality" can be completely isolated from the kernel.
>
> Yes, but you've still gotta struggle through six piles of elephant
> excrement to get there,
> by which time your brain is soup, and you're muttering about how to
> implement a 15th way to map
> all the odd-numbered framebuffers into someone else's address space.

Now, I'm not saying that working through six piles of elephant
excrement is easy, but some of us do this for work on a daily basis.
So yah, the person who wrote the emulation layer would have to
get their feet wet, but the users of an emulation layer hardly
need to worry about such things.

> Well, we're talking oranges and (Posix-compliant) apples, so it's hard
> to agree:
> you're talking about implementations, I'm talking about philosophical
> approaches to problem solving.

Perhaps this is why I don't see your point...

but.. if you were to go in to work one day and found that some
linux (*bsd, slolaris, win32, etc..) box that you used on a daily
basis was running a plan9 emulation layer that was running rio,
acme, 9p and the whole shebang, how would it matter to you what
was under the covers?

> 	DaveL.

Tim N.

Re: [9fans] alright, this should be interesting

[Russ Cox]

You're claiming that the "software quality" of the
underlying kernel somehow plays a role in determining
the "software quality" of the software written on top of
it, presumably by providing an example for others to
follow.

I agree with the general point -- people exposed to examples
of clean software are more likely to write clean software --
but I think you've gone overboard.

Specifically, I don't see why the kernel should be placed
in such a position of importance.  I think the effect is true
of any software.  I hung around Bell Labs for at least a
year before I started using Plan 9, but the programs
that I wrote during that time got a lot cleaner because I
was exposed to good clean code, but it wasn't the kernels.
I was using Linux at home and SGI Irix at Bell Labs.

Also, your particular example is definitely flawed:

    Kernels are also important in the sense that they set
    the tone for everything above them: kencc wouldn't have
    happened on linux, for example.

The cleanliness of Plan 9's kernel and the cleanliness of
the C compilers are definitely correlated, but not directly.
They're clean because Ken was intimately involved in both.
If Ken had been using some other system, even Linux, and
was writing a compiler, I'm confident he could have pulled
off the same trick.  In fact, my understanding is that the
compilers happened in preparation for the kernel, so the
kernel can't take credit.

Russ

Re: [9fans] alright, this should be interesting

[Kenji Okamoto]

Russ, you made a good point.

And therefre, it is very important for youngs to see first a clean
software rather than usuful☺ one.

Kenji

Re: [9fans] alright, this should be interesting

[Skip Tavakkolian]

> You're claiming that the "software quality" of the
> underlying kernel somehow plays a role in determining
> the "software quality" of the software written on top of
> it, presumably by providing an example for others to
> follow.

I think the effect is direct, not just by examples.
If some specific function of your (high quality) software
written for some (low quality) kernel counts on a kernel feature that
works sometimes depending on special cases, sooner or later
that ugliness will cause ugliness in the code that deals with it.
I think forsyth's example says it exactly. You can't build any better
than the foundation will allow.

RE: [9fans] alright, this should be interesting

[Nigel Roles]

> 
> I think the effect is direct, not just by examples.
> If some specific function of your (high quality) software
> written for some (low quality) kernel counts on a kernel feature that
> works sometimes depending on special cases, sooner or later
> that ugliness will cause ugliness in the code that deals with it.
> I think forsyth's example says it exactly. You can't build any better
> than the foundation will allow.
> 
> 

Ugliness is in the eye of the beholder.

Google have combined
a huge wobbly raft of Linux PCs and a search algorithm
into something which has the eyeballs of the world
choosing it in preference.

Are you telling me that Google would be demonstrably better
built on Plan 9? I can't see that, and nor would any of
their customers, because the kernel is hidden from view.

You can perhaps argue that there are alternatives to Linux
which might have lessened the amount of work they
needed to do to reach system administration nirvana, but
from what Rob says they have it solved pretty well.

Another example is MacOS X, built on BSD, the latter lampooned
by Linux acolytes for being no good for laptops. Apple solved
the problems, such that most people I know would buy Apple
as their next laptop.

If someone asks me which mobile phone to buy, I always say
Nokia. This is because, regardless of which kernel they use
(and they have changed several times), the MMI is generally
preferred.

You can claim that ugly kernels beget ugly code, and
I would agree. Claiming that ugly kernels beget ugly applications
is going too far. There are too many counterexamples.

Most users in the world don't see the code, and don't care
about it's uglyness. They care whether something works and is
easy to use.

Re: [9fans] alright, this should be interesting

[Dave Lukes]

 > You can claim that ugly kernels beget ugly code, and
 > I would agree. Claiming that ugly kernels beget ugly applications
 > is going too far. There are too many counterexamples.

There are _some_ counterexamples,
but they are far outweighed by the examples,
both in number and lines of code.

>Most users in the world don't see the code, and don't care
>about it's uglyness. They care whether something works and is
>easy to use.
>
Me too (he said, typing mail into Thunderbird, canceling the alarm on 
his PalmPhone ...),
but I still maintain that, given better foundations, we'd get more 
better stuff,.

I'd better get back to hacking Postfix configs ...

    DaveL.

Re: [9fans] alright, this should be interesting

[Nigel Roles]

Dave Lukes wrote:

> Me too (he said, typing mail into Thunderbird, canceling the alarm on 
> his PalmPhone ...),
> but I still maintain that, given better foundations, we'd get more 
> better stuff,.
>
Couldn't agree more, he said editing his photos with PhotoShop, 
configuring his wireless AP,
watching his FreeView STB, and running Plan 9 in vmware.

Re: [9fans] alright, this should be interesting

[Brantley Coile]

Since this seems to be the hot-thread-of-the-month, and it has nothing
to do with patents, unlike what I imagine is going on on other mailing
lists talking about Rob's interview, I'll have to chime in with my own
view of dubious value.

Rob seems to me to have beens speaking pragmaticly.  By that I mean he
was observing the current situation in his environment.  I assume that
is mostly Linux and such.  I don't think he was speaking universally,
and meant to imply that you can simulate one OS on ANY kernel.  So, if
we assume he meant on the current Linux kernels, Russ is demonstrating
whether Rob is correct or not.

Personally, I've run Cygwin and, years ago, sam, 9term, and 9wm.  As
soon as possible I installed real Plan 9.  I've done similar several
times, and I have always found the simulated environments lacking in
some way.  I'm not smart enough to know why, or I'm too lazy to give
it a lot of thought.  It just seemed different in many ways and I
always came back to real Plan 9.

But, on the other hand, Inferno seems to be the same on any systems,
and Oberon was the same whether I ran it natively, on Windows or the Mac.
(They were actually different but only because the different
versions were also different releases of Oberon.)

 Brantley

Re: [9fans] alright, this should be interesting

[Dan Cross]

Brantley Coile <brantley@coraid.com> writes:
> Personally, I've run Cygwin and, years ago, sam, 9term, and 9wm.  As
> soon as possible I installed real Plan 9.  I've done similar several
> times, and I have always found the simulated environments lacking in
> some way.  I'm not smart enough to know why, or I'm too lazy to give
> it a lot of thought.  It just seemed different in many ways and I
> always came back to real Plan 9.

System emulation layers like plan9ports, cygwin, etc are sort of like
masturbation.  Sure, it's fine when you've got nothing else going on,
but it'll never beat the real thing.

	- Dan C.

Re: [9fans] alright, this should be interesting

[Tiit Lankots]

> System emulation layers like plan9ports, cygwin, etc are sort of like
> masturbation.  Sure, it's fine when you've got nothing else going on,
> but it'll never beat the real thing.

taking her to the movies - $20 and 2h
-"- restaurant - $50 2h
-"- night club - $20 4h
   various beverages - $50	
(your face after her third 'no' to your "ok, then let's do it this way") -  
priceless

TOTAL: money spent - $140, time spent - a full day's worth of work

vs

a box of tissue - $2
a quick download (after all, that's what the internot was invented for,  
right) - $0

TOTAL: money spent - negligent, time spent - about 2 minutes

Pragmatically taken, the wetware shoud be extinct.
Gladly, it's different with software.

P.S. To amortize the accumulative costs of the first situtation, human  
race invented the marriage. Sometimes it even works.

Re: [9fans] alright, this should be interesting

[Brantley Coile]

> P.S. To amortize the accumulative costs of the first situtation, human  
> race invented the marriage. Sometimes it even works.

As it did in my case, twenty-five years and counting.  And it
gets better and better.

  Brantley

Re: [9fans] alright, this should be interesting

[Dave Lukes]

 > As it did in my case, twenty-five years and counting. And it
 > gets better and better.

Sadly, I have a counterexample.

Dave.

RE: [9fans] alright, this should be interesting

[Skip Tavakkolian]

> Ugliness is in the eye of the beholder.

Moral relativism doesn't apply to ugly code (and cannibalism).

> Are you telling me that Google would be demonstrably better
> built on Plan 9? I can't see that, and nor would any of
> their customers, because the kernel is hidden from view.

Better and different.  They could do things that they can't do
(easily) now.  When you multiply not-easy by a large number, it
becomes an impossibility.  I think the statement about "Bringing data
to the user instead of the other way around: Those damn browsers are
still in the way" is very telling.  And yes, there would be a
practical problem of building Plan9 administrative expertise -- mostly
a mater of time.

> Most users in the world don't see the code, and don't care
> about it's uglyness. They care whether something works and is
> easy to use.

But we're not talking about everybody.  Somebody has to,
and many of the people here have worked on systems that are
the guts of many things being used now.

Re: [9fans] alright, this should be interesting

[Dave Lukes]

 > Moral relativism doesn't apply to ugly code (and cannibalism).

<applause level="deafening"/>

>>Are you telling me that Google would be demonstrably better
>>built on Plan 9? I can't see that, and nor would any of
>>their customers, because the kernel is hidden from view.
>>    
>>
>
>Better and different.  They could do things that they can't do
>(easily) now.  When you multiply not-easy by a large number, it
>becomes an impossibility.
>
Yes!!!!!
Also, even if it's not impossible, no-one with any taste wants to get 
involved:
I _could_ contribute to Linux, but there's no way I can be bothered to 
even look at the code,
far less contribute, because a red mist descends ASA I even look at the 
directory structure.

>  And yes, there would be a
>practical problem of building Plan9 administrative expertise -- mostly
>a mater of time.
>  
>
Well, actually ...

>>Most users in the world don't see the code, and don't care
>>about it's uglyness. They care whether something works and is
>>easy to use.
>>    
>>
... and interestingly, speaking as an SA, NEITHER DO THE SAs!
They are users too:
you give them a set of tools to reboot a server, offline a disk in a 
RAID array, check the length of a mail queue ...

it's only the "developers" (of the kernel/apps, ...) who really care 
about any of the underlying stuff.

DaveL.

Re: [9fans] alright, this should be interesting

[Jason Gurtz]

On 10/22/2004 03:12, Dave Lukes wrote:

>>>Most users in the world don't see the code, and don't care
>>>about it's uglyness. They care whether something works and is
>>>easy to use.
>>>    
>>>
> ... and interestingly, speaking as an SA, NEITHER DO THE SAs!
> They are users too:

OTOH, sometimes clean src is--at least to this SA--a good thing.  ...like
the time I was investigating why sendmail (w/ strict helo checking turned
on) was rejecting a certain Tektronix printer we have.  Turns out the
buggy MFer (they would not fix this!) was saying

    helo myDomain.com\n
space char-------------^

instead of

    helo mydomain.com\n

What I found, at least in the case of sendmail-8.12.x (and taking into
account my haltingly poor grasp of anything more than elementary C :), was
that it wasn't too hard to take this particular case into account and
still turn away the more egregiously broken SMTP engines of certain
malware.  Surely there must be cases like this in kernel land too?

~Jason

-- 

Re: [9fans] alright, this should be interesting

[Dave Lukes]

> OTOH, sometimes clean src is--at least to this SA--a good thing.

Agree fully, but not all SAs are like you and I are obviously are ...

>   ...like
> the time I was investigating why sendmail (w/ strict helo checking 
> turned
> on) was rejecting a certain Tektronix printer we have.

Hmmm ... That must be one of the few bogus HELO stories I've not seen!

BTW: my general answer to the "WTF do I do with sendmail?" question
is "replace it with postfix", which sucks just as much as sendmail, but 
in more tolerable ways:-~.

> 	.  Surely there must be cases like this in kernel land too?

I'm sure there are.

Dave.

Re: [9fans] alright, this should be interesting

[boyd, rounin]

> You can perhaps argue that there are alternatives to Linux
> which might have lessened the amount of work they
> needed to do to reach system administration nirvana, but
> from what Rob says they have it solved pretty well.

you can do it with lunix, but it's bloody hard work to get
it to the point where administering large N is hands off.

RE: [9fans] alright, this should be interesting

[Nigel Roles]

9fans-bounces+ngr=9fs.org@cse.psu.edu wrote:
>> You can perhaps argue that there are alternatives to Linux
>> which might have lessened the amount of work they
>> needed to do to reach system administration nirvana, but
>> from what Rob says they have it solved pretty well.
> 
> you can do it with lunix, but it's bloody hard work to get
> it to the point where administering large N is hands off.

Well, it can't be hands off, as with the number of machines
they own, there must be a disk drive failure about every
3 seconds.

Re: [9fans] alright, this should be interesting

[boyd, rounin]

> Well, it can't be hands off, as with the number of machines
> they own, there must be a disk drive failure about every
> 3 seconds.

it can;  buy real disks (tm) and a decent raid controller (eg. storageworks).

Re: [9fans] alright, this should be interesting

[Ronald G. Minnich]

well, all I know is that when I moved to Unix from other OSes in 1976 (I'm
old) it was a revelation from heaven. It had a major impact on how my
brain worked. Things that were just plain not doable on other OSes were
trivial on Unix. It really did change my thought processes.

Going to other OSes (OS/MVS, HP MPE, RT/11, RTE, IBM's OSes for the
Series/1 machine, RSX, etc.) I would start to feel a visceral anger at
them.  You want to know about gesture computing? You should see the
gestures I used at those OSes. I used to get so angry at HP MPE that
occasionaly I'd hit the return key a little hard and it would fly out of
the cube. I got good at repairing keyboards.

So to me, the OS is a Big Deal. The model the OS presents to me molds my
thought processes in some sense -- I guess I'm weak-minded!

Same for me with Plan 9. I keep going back to Linux and getting angry at 
it. It's really a total pain for me to use it now that I've gotten used to 
Plan 9. Keyboards are sturdier than the ones I used to have, and I'm older 
and weaker, so no big problems yet, however. Although I do keep a hunk of 
railroad rail under my desk for non-cooperative hardware ... interesting 
to see what a railroad rail will do to an IBM Deskstar.

ron

Re: [9fans] alright, this should be interesting

[Russ Cox]

> Same for me with Plan 9. I keep going back to Linux and getting angry at
> it. It's really a total pain for me to use it now that I've gotten used to
> Plan 9. Keyboards are sturdier than the ones I used to have, and I'm older
> and weaker, so no big problems yet, however. Although I do keep a hunk of
> railroad rail under my desk for non-cooperative hardware ... interesting
> to see what a railroad rail will do to an IBM Deskstar.

Still no luck on the Tux punching bag search.

Russ

Re: [9fans] alright, this should be interesting

[Eric Van Hensbergen]

On Wed, 20 Oct 2004 16:02:21 -0400, Russ Cox <russcox@gmail.com> wrote:
> 
> Still no luck on the Tux punching bag search.
> 

we need Tux vs Glenda rock 'em sock 'em robots.

         -eric

Re: [9fans] alright, this should be interesting

[Charles Forsyth]

> Same for me with Plan 9. I keep going back to Linux and getting angry at
> it. It's really a total pain for me to use it now that I've gotten used to
> Plan 9.

actually, i sometimes feel the same when messing with Linux
but because i was used to Unix, let alone Plan 9!  also because i've got
Linux, Windows and Plan 9 on the same machine, and Linux wallows
even more than Windows.  this is Unix?  i think not.

it's important to be careful about this basis for comparison though, because
now that i've been reminded of it, i remember not dissimilar reactions
when i had once to use a 6th Edition system after i'd worked with 7th Edition for quite a time.
``oh.  that.''

Re: [9fans] alright, this should be interesting

[boyd, rounin]

> i remember not dissimilar reactions
> when i had once to use a 6th Edition system after i'd worked with 7th Edition for quite a time.
> ``oh.  that.''

yes, 6th and 7th were very different things.

Re: [9fans] alright, this should be interesting

[Dave Lukes]

 > it's important to be careful about this basis for comparison though, 
because
 > now that i've been reminded of it, i remember not dissimilar reactions
 > when i had once to use a 6th Edition system after i'd worked with 7th 
Edition for quite a time.
 > ``oh. that.''

Well, yes ... but V6 was still way better than RSX-11M, for example.

DaveL.

Re: [9fans] alright, this should be interesting

[William Josephson]

On Wed, Oct 20, 2004 at 04:02:21PM -0400, Russ Cox wrote:
> > Same for me with Plan 9. I keep going back to Linux and getting angry at
> > it. It's really a total pain for me to use it now that I've gotten used to
> > Plan 9. Keyboards are sturdier than the ones I used to have, and I'm older
> > and weaker, so no big problems yet, however. Although I do keep a hunk of
> > railroad rail under my desk for non-cooperative hardware ... interesting
> > to see what a railroad rail will do to an IBM Deskstar.
> 
> Still no luck on the Tux punching bag search.

No, but I have a good chunk of railroad rail from
the New York subway once you find it.

Re: [9fans] alright, this should be interesting

[boyd, rounin]

> Although I do keep a hunk of 
> railroad rail under my desk for non-cooperative hardware ... interesting 
> to see what a railroad rail will do to an IBM Deskstar.

interesting.  boggs needed to teach field circus [sic] about LP40s.
took the door off, shot it full of holes, put it back and on said:

    FIX THIS!!

Re: [9fans] alright, this should be interesting

[Dan Cross]

"boyd, rounin" <boyd@insultant.net> writes:
> 
> > Although I do keep a hunk of 
> > railroad rail under my desk for non-cooperative hardware ... interesting 
> > to see what a railroad rail will do to an IBM Deskstar.
> 
> interesting.  boggs needed to teach field circus [sic] about LP40s.
> took the door off, shot it full of holes, put it back and on said:

When I was in Marine Combat Training, they showed us what a termal
grenade could do to the engine block of a humvee.  That's a decent
way to fix a printer.

	- Dan C.

Re: [9fans] alright, this should be interesting

[Dave Lukes]

Russ,
Again, I think you miss the point: you are not the problem: the rest of 
us are!

>Also, your particular example is definitely flawed:
>
>    Kernels are also important in the sense that they set
>    the tone for everything above them: kencc wouldn't have
>    happened on linux, for example.
>
>The cleanliness of Plan 9's kernel and the cleanliness of
>the C compilers are definitely correlated, but not directly.
>They're clean because Ken was intimately involved in both.
>  
>
See my other post: the key word here is "Ken": many others (myself 
included) couldn't have.

Cheers,
    Dave.

Re: [9fans] alright, this should be interesting

[Dave Lukes]

<WARNING>
Contains an analogy in severely bad taste at the end: don't read the 
last part if likely to be offended by it.
</WARNING>

Tim,

> > You are missing the point of what I said:

 > I must be, because I still dont agree with your point.

OK, let me try again ...

Firstly, the existence of this thread is partial proof of my point:
we wouldn't be having this discussion at all if gcc/linux/... didn't exist.

>>In other words, if you have a crufty kernel, you'll have a smelly
>>compiler,
>>and vice-versa.
>>    
>>
>
>Why?  You could build a fresh smelling compiler like 8c/8a/8l.
>  
>
<shout tone="frustrated">BUT THEY DIDN'T!!!</shout>
They built g-goddamned-cc,
and I almost weep when I think what the million monkeys who committed 
that particular crime against code
could have done if they'd been given some education in style, taste etc.

Bad examples lead to more badness:
if you stare at crap for long enough, you start to think that crap is 
the One True Way.

>but.. if you were to go in to work one day and found that some
>linux (*bsd, slolaris, win32, etc..) box that you used on a daily
>basis was running a plan9 emulation layer that was running rio,
>acme, 9p and the whole shebang, how would it matter to you what
>was under the covers?
>  
>
Well, firstly, it would matter intrinsically because I am a decent human 
being who wants to eliminate suffering,
and whoever had built your emulation layer would either be
a) (worst case scenario) banging their head against the wall of a padded 
cell or,
b) (probable best case scenario) wandering around saying things like:
    "Well, the SmackMyIoVecUp() call with the optional 
BarbedWireandCatONineTails option is not so bad, really, when you get 
used to it",
and then I'd have to kill them, which would ruin their whole day.

Yes, I know that Really Clever People (many of whom will read this) can 
build Really Good Systems on top of crud,
but the fact is that, in the general case, People Don't: they build 
bigger piles of Crap.

Neither does the existence of the Good Stuff somehow improve, or excuse 
the existence of, the underlying Crap.


Does one small Good Thing somehow ameliorate the existence of loads of 
Bad Things?




And now, sorry in advance, but it's That Time of Year ...
Sorry.
Sorry.
Sorry.
Sorry.
Sorry.








<tasteless-hitler-analogy>
"Yes, I know Hitler was responsible for the murder of your paternal 
grandparents,
 but, hey, the Communists burned down the bier-keller just after he 
spoke there, so that was Really Cool, right?!"
</tasteless-hitler-analogy>

Sorry.
Sorry.
Sorry.
Sorry.
Sorry.
Sorry.
Sorry.
Sorry.
Sorry.
Sorry.
    DaveL.