[9fans] devtrace release time

[9fans] devtrace release time

[john]

Devtrace is ready for your consumption, hot out of the
oven and juicy fresh. The source is at
/n/sources/contrib/john/devtrace-backport.tgz
which includes all the necessary source files, the man
page (troff), and instructions for putting it in the
kernel and compiling.

Remember, this isn't mine alone, Ron and Aki came up
with the idea and did the real hard implementation;
I just finished up and did some porting. Therefore,
make sure to blame Ron if it doesn't work.

John Floren

Re: [9fans] devtrace release time

[Uriel]

Does it work now with non-amd64 kernels?

Peace

uriel

On Wed, Dec 17, 2008 at 8:36 PM,  <john@csplan9.rit.edu> wrote:
> Devtrace is ready for your consumption, hot out of the
> oven and juicy fresh. The source is at
> /n/sources/contrib/john/devtrace-backport.tgz
> which includes all the necessary source files, the man
> page (troff), and instructions for putting it in the
> kernel and compiling.
>
> Remember, this isn't mine alone, Ron and Aki came up
> with the idea and did the real hard implementation;
> I just finished up and did some porting. Therefore,
> make sure to blame Ron if it doesn't work.
>
> John Floren
>
>

Re: [9fans] devtrace release time

[john]

This source is backported to the PC kernel in /sys/src/9/pc.
The instructions make this abundantly clear, what with all
the stuff being done in /sys/src/9/pc.

John

> Does it work now with non-amd64 kernels?
>
> Peace
>
> uriel
>
> On Wed, Dec 17, 2008 at 8:36 PM,  <john@csplan9.rit.edu> wrote:
>> Devtrace is ready for your consumption, hot out of the
>> oven and juicy fresh. The source is at
>> /n/sources/contrib/john/devtrace-backport.tgz
>> which includes all the necessary source files, the man
>> page (troff), and instructions for putting it in the
>> kernel and compiling.
>>
>> Remember, this isn't mine alone, Ron and Aki came up
>> with the idea and did the real hard implementation;
>> I just finished up and did some porting. Therefore,
>> make sure to blame Ron if it doesn't work.
>>
>> John Floren
>>
>>

Re: [9fans] devtrace release time

[Uriel]

Didn't know the amd64 kernel doesn't live in /sys/src/9/pc/.

Sorry, I should have guessed that
/sys/src/9/not-for-the-unworthy-unwashed-masses/ was much more likely
location.

Peace

uriel


On Wed, Dec 17, 2008 at 8:55 PM,  <john@csplan9.rit.edu> wrote:
> This source is backported to the PC kernel in /sys/src/9/pc.
> The instructions make this abundantly clear, what with all
> the stuff being done in /sys/src/9/pc.
>
> John
>
>> Does it work now with non-amd64 kernels?
>>
>> Peace
>>
>> uriel
>>
>> On Wed, Dec 17, 2008 at 8:36 PM,  <john@csplan9.rit.edu> wrote:
>>> Devtrace is ready for your consumption, hot out of the
>>> oven and juicy fresh. The source is at
>>> /n/sources/contrib/john/devtrace-backport.tgz
>>> which includes all the necessary source files, the man
>>> page (troff), and instructions for putting it in the
>>> kernel and compiling.
>>>
>>> Remember, this isn't mine alone, Ron and Aki came up
>>> with the idea and did the real hard implementation;
>>> I just finished up and did some porting. Therefore,
>>> make sure to blame Ron if it doesn't work.
>>>
>>> John Floren
>>>
>>>
>
>
>

Re: [9fans] devtrace release time

[ron minnich]

On Wed, Dec 17, 2008 at 12:08 PM, Uriel <uriel99@gmail.com> wrote:
> Didn't know the amd64 kernel doesn't live in /sys/src/9/pc/.

OK, I am only responding to this because of the incorrect impressions
being left by these kinds of comments.

The backport John did is to the standard kernel that you all can get
on your machine. It should in fact even work on 9vx. You are welcome
to use it. In fact, one could actually look at what John released
*before* posting to this list and making oneself look silly. It's an
idea.

great unwashed masses? I am reminded of a liberation sign somebody
spotted in some foreign land once:

"The Masses are Revolting!"

:-)

ron

Re: [9fans] devtrace release time

[Eric Van Hensbergen]

On Wed, Dec 17, 2008 at 4:07 PM, ron minnich <rminnich@gmail.com> wrote:
>
> "The Masses are Revolting!"
>

"You said it! They stink on ice!"

        -History of the World, Part I.

Re: [9fans] devtrace release time

[Devon H. O'Dell]

2008/12/17 ron minnich <rminnich@gmail.com>:
> On Wed, Dec 17, 2008 at 12:08 PM, Uriel <uriel99@gmail.com> wrote:
>> Didn't know the amd64 kernel doesn't live in /sys/src/9/pc/.
>
> OK, I am only responding to this because of the incorrect impressions
> being left by these kinds of comments.
>
> The backport John did is to the standard kernel that you all can get
> on your machine. It should in fact even work on 9vx. You are welcome
> to use it. In fact, one could actually look at what John released
> *before* posting to this list and making oneself look silly. It's an
> idea.

It doesn't (yet) work on 9vx. I'm working on that right now, though.
More on that in a later message.

--dho

> great unwashed masses? I am reminded of a liberation sign somebody
> spotted in some foreign land once:
>
> "The Masses are Revolting!"
>
> :-)
>
> ron
>
>

Re: [9fans] devtrace release time

[lucio]

> In fact, one could actually look at what John released
> *before* posting to this list and making oneself look silly. It's an
> idea.

Uriel is renowned for demanding tools to be released on principle,
without him having any practical need for them.  He lands up sounding
like a peevish, ungrateful child who just wants more sweets even
though his hands are already full.

Far from him to actually do some checking first.  What could he
possibly need with devtrace anyway?

That said, is there any reason why devtrace is not part of the
distribution and are there plans to incorporate it?

++L

Re: [9fans] devtrace release time

[Uriel]

Yea, stupid retarded moron I am to give a fuck about the welfare of
Plan 9 and its future.

After all, I have only invested I don't know how many hundreds of
hours of my life in it...

uriel

On Thu, Dec 18, 2008 at 4:52 AM,  <lucio@proxima.alt.za> wrote:
>> In fact, one could actually look at what John released
>> *before* posting to this list and making oneself look silly. It's an
>> idea.
>
> Uriel is renowned for demanding tools to be released on principle,
> without him having any practical need for them.  He lands up sounding
> like a peevish, ungrateful child who just wants more sweets even
> though his hands are already full.
>
> Far from him to actually do some checking first.  What could he
> possibly need with devtrace anyway?
>
> That said, is there any reason why devtrace is not part of the
> distribution and are there plans to incorporate it?
>
> ++L
>
>
>

Re: [9fans] devtrace release time

[john]

>> In fact, one could actually look at what John released
>> *before* posting to this list and making oneself look silly. It's an
>> idea.
>
> Uriel is renowned for demanding tools to be released on principle,
> without him having any practical need for them.  He lands up sounding
> like a peevish, ungrateful child who just wants more sweets even
> though his hands are already full.
>
> Far from him to actually do some checking first.  What could he
> possibly need with devtrace anyway?
>
> That said, is there any reason why devtrace is not part of the
> distribution and are there plans to incorporate it?
>
> ++L

Answering the last question: devtrace has only been compatible with
the current kernel for a few weeks, which I've spent testing and
cleaning up the code a bit.  Right now, I'd object to including
devtrace in the distribution because of all the #pragma's it tosses
around in 9/pc, 9/port, and even libc.  Also, it currently replaces
the *old* profiling system--that's why the assembly functions are
called _profin and _profout even though they call tracein and traceout
in devtrace.c (and everything else in the code is called "trace"
rather than "profile").

I hacked the linker so it could take a -t flag and insert _tracein and
_traceout; if we were to put it in the distribution, we could replace
all my "#pragma profile 0" lines with "#pragma trace 0", which would
allow you to still use the old profiling system without interference.
It would be a bit of work but definitely feasible if there's interest.


John

Re: [9fans] devtrace release time

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 152 bytes --]

On Wed, Dec 17, 2008 at 11:55:50PM -0500, john@csplan9.rit.edu wrote:
> It would be a bit of work but definitely feasible if there's interest.
 
+1

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] devtrace release time

[john]

> On Wed, Dec 17, 2008 at 11:55:50PM -0500, john@csplan9.rit.edu wrote:
>> It would be a bit of work but definitely feasible if there's interest.
>
> +1

I presume by this that you were able to get devtrace working?  Did you
find the documentation sufficiently clear?  Any problems?

John

Re: [9fans] devtrace release time

[Uriel]

No, '+1' means that he agrees and supports the quoted statement.

uriel

On Thu, Dec 18, 2008 at 6:04 AM,  <john@csplan9.rit.edu> wrote:
>> On Wed, Dec 17, 2008 at 11:55:50PM -0500, john@csplan9.rit.edu wrote:
>>> It would be a bit of work but definitely feasible if there's interest.
>>
>> +1
>
> I presume by this that you were able to get devtrace working?  Did you
> find the documentation sufficiently clear?  Any problems?
>
> John
>
>
>

Re: [9fans] devtrace release time

[lucio]

> On Wed, Dec 17, 2008 at 11:55:50PM -0500, john@csplan9.rit.edu wrote:
>> It would be a bit of work but definitely feasible if there's interest.
>
> +1

Out of scope in my case, but the logistics interest me greatly.
Please keep me in the loop.

++L

Re: [9fans] devtrace release time

[sqweek]

On Thu, Dec 18, 2008 at 12:52 PM,  <lucio@proxima.alt.za> wrote:
> Uriel is renowned for demanding tools to be released on principle,
> without him having any practical need for them.

 I don't see why uriel having a practical need for them or not is
relevant. I see the relevant question as "does /anyone/ in the
community have a practical need for the tool?".
 That's really hard to answer when the mere fact that the tool exists
is not readily available to the community (how DO we know about the
x86-64 kernel? I think everything I've heard about it has been via
uriel).

>  He lands up sounding
> like a peevish, ungrateful child who just wants more sweets even
> though his hands are already full.

 But unlike a child looking for sweets, uriel isn't complaining for
his own benefit:

> What could he possibly need with devtrace anyway?

 Exactly! His desire is not to get the code for himself, but for the
code to be available for anyone who does want to use/debug/develop it.

 Yes, uriel's manner is abrasive, and it gets old listening to him
make the same complaints over and over. But it boils down to this:
when uriel perceives an inhibitor to plan 9's growth and development,
uriel raises his voice (because no one else will!). Maybe he's not
always right, and maybe his righteous attitude makes him hard to
reason with, but his heart is in the right place.

-sqweek, wishing we could all just get along

PS. Congrats on the release, John/Ron/Aki!

Re: [9fans] devtrace release time

[lucio]

> On Thu, Dec 18, 2008 at 12:52 PM,  <lucio@proxima.alt.za> wrote:
>> Uriel is renowned for demanding tools to be released on principle,
>> without him having any practical need for them.
>
>  I don't see why uriel having a practical need for them or not is
> relevant.

Well, let me try to explain it.  Uriel is _not_ an elected
representative of the community he makes no bone about despising.
Everyone on 9fans (and I presume on the IRC channel) is perfectly
capable of standing up for themselves and I, no doubt amongst others,
take exception to Uriel (mis)representing my views.

Also, Uriel is not even a Plan 9 user.  How could he possibly evaluate
anyone's need for a theoretical piece of software?  Or, for that
matter, evaluate the risk of releasing it prematurely?  As for the
alternative question: "does /anyone/ in the community have a practical
need for the tool?", the answer is self-evident: Ron needed the
software and Ron got it, whatever it took him to achieve this.  Can
you spot the difference?

As for those who did not know about it, why would they have a need for
it?  And why should they be expecting it to be available?  Contrary to
Uriel's statements, those who have had something to contribute have
been able to do so, it is only in the realm of "helping" Bell Labs
that cards have been kept close to Bell Labs' chest and it is known
that Bell Labs does not subscribe to the "software development bazaar"
philosophy, so that should come as no surprise.  Me, I am grateful
that the current release of the Plan 9 kernel is not encumbered with
partial changes to allow unknown parties to experiment with a 64-bit
kernel.  Perhaps if you think about it you will see my side of it.

Uriel does not "raise his voice", he whines.  And he makes it sound
like he's whining on everyone's behalf when it isn't even on his own
behalf.  That makes him a politician in my book and that's quite
enough said.

++L

Re: [9fans] devtrace release time

[sqweek]

On Thu, Dec 18, 2008 at 5:47 PM,  <lucio@proxima.alt.za> wrote:
> Or, for that matter, evaluate the risk of releasing it prematurely?

 What risk?
-sqweek

Re: [9fans] devtrace release time

[lucio]

> On Thu, Dec 18, 2008 at 5:47 PM,  <lucio@proxima.alt.za> wrote:
>> Or, for that matter, evaluate the risk of releasing it prematurely?
>
>  What risk?

Untested and/or incomplete kernel changes?

++L

Re: [9fans] devtrace release time

[erik quanstrom]

On Thu Dec 18 06:44:58 EST 2008, lucio@proxima.alt.za wrote:
> > On Thu, Dec 18, 2008 at 5:47 PM,  <lucio@proxima.alt.za> wrote:
> >> Or, for that matter, evaluate the risk of releasing it prematurely?
> >
> >  What risk?
>
> Untested and/or incomplete kernel changes?

i don't think that's the main risk, though that is still
a problem, and a current problem.

in my view, plan 9 is great because you can change
it easily.  but i'm not sure that means that every change
needs to be made cannonical, especially if the result
is harder to change.

- erik

Re: [9fans] devtrace release time

[sqweek]

On Thu, Dec 18, 2008 at 8:42 PM,  <lucio@proxima.alt.za> wrote:
>sqweek wrote:
>>  What risk?
>
> Untested and/or incomplete kernel changes?

 I'm not seeing the issue?
 We're not talking about dumping random stuff into the /sys/ of
unsuspecting users here, the matter at hand is simply the availability
of the code to interested parties (who might want to test and/or
complete the changes). You could argue that this is the case, and
interested parties need only contact the labs to get a copy of the
code, and I do kind of like the approach. It has a nice personal feel
to it. But it has some limitations, too, namely that you need to know
the code exists to request it.

 You were looking for elaboration on this earlier - imagine passers by, for one:
 "Alright, my x86-64 board arrived! I wanted to try out some other
OSes, what have we here... hmm Plan 9, seems interesting... aw, no
native port! Guess I'll try losethos."
 It also requires a prior interest in the code - there's no chance for
someone to stumble upon it and become interested that way.

 To be fair, you don't need to know the code exists. You could always
send a mail out when starting to work on a project to see if anyone
has already started... hm, which would have the advantage of keeping
everyone in the loop with what people are up to, and now that I'm
thinking about it would work pretty well, at the expense of some
noise. Also it requires everyone's participation to work well, and
doesn't deal so well with people disappearing (like the guy who did
the inferno NetBSD/386 port - fortunately he had publicised his
patches, so it was possible for someone else to pick them up, test
them out and get them in the distribution).

 I'd like to illustrate my point further but this is probably already
long enough, and I should be cleaning my apartment so as to avoid
getting kicked out following my inspection tomorrow. ;)
 To sum up, I'm not trying to say that withholding code is the devil's
practice and you're all going to hell if you do it and as soon as all
code is public developers will fall out of the sky to write drivers
for plan 9... My point is simply that there's a lot of caveats and
potential obstacles that disappear when code is freely available, and
I'm yet to see anyone demonstrate a disadvantage of doing so.
-sqweek

Re: [9fans] devtrace release time

[Steve Simon]

> I'm yet to see anyone demonstrate a disadvantage of doing so.

the problems with publishing code is you have to:
	write the manual
	document the install process
	remove all the debug cruft that you where leaving just in case
	field emails about how it:
		doesn't "Work they way I expected"
		it suicides if I press Alt-J
		"the whole design is fucking braindamaged"

This takes time and effort, and noone wants to just put the code
up in a mess, reputations do matter, and we take prinde in our work, don't we?

whats worse is if you publish a tar and then somone fixes a load of
stuff but in the meantime you are working and your code gets out of sync
so you have to merge by hand.

use CVS (or whatever is trendy) I hear you say? Well you have to set that
up, and if you have CVS you have to police it, what if people check in
broken code.

It all takes time and concerntration, which would be better spent on
getting on with the code and sorting it out.

One of the biggest things we lack is Wifi support (IMHO) and Russ put
up his incomplete Centrino driver a few years ago. How much interest has that
sparked? Similarly the sshv2 code, though we now have openssh so its less of
a problem.

Ok, the bottom line for me:

I AGREE it would be lovely to have an AMD64 kernel for pure kudos reasons
(my OS has 64 bits and yours doesn't), BUT, I completely understand why those
working on it don't want to release it until they are ready.

-Steve

Re: [9fans] devtrace release time

[lucio]

> I AGREE it would be lovely to have an AMD64 kernel for pure kudos reasons
> (my OS has 64 bits and yours doesn't), BUT, I completely understand why those
> working on it don't want to release it until they are ready.

I wish I had been able to put it so well - quoting the absolute
minimum, the rest is equally well phrased.

Thank you, Steve.

++L

Re: [9fans] devtrace release time

[sqweek]

On Fri, Dec 19, 2008 at 1:54 AM, Steve Simon <steve@quintile.net> wrote:
>> I'm yet to see anyone demonstrate a disadvantage of doing so.
>
> the problems with publishing code is you have to:
>        write the manual
>        document the install process
>        remove all the debug cruft that you where leaving just in case

 No no no, this is all release oriented stuff! Just put the code up so
if someone really interested happens by they can check it out and work
the details out themselves. What's the disadvantage there?

>        field emails about how it:
>                doesn't "Work they way I expected"
>                it suicides if I press Alt-J
>                "the whole design is fucking braindamaged"

 I'm not understanding how feedback qualifies as a disadvantage.
Unless you're writing a twitch game or MMORPG, then I could understand
not wanting to hear from your users.

> and we take prinde in our work, don't we?

 Of course. But it's silly to entertain the notion that code comes off
our fingertips perfect and fully formed. It's software: there's bugs,
there's design flaws, development is incremental. Often it can be
useful long before it is perfected.

> whats worse is if you publish a tar and then somone fixes a load of
> stuff but in the meantime you are working and your code gets out of sync
> so you have to merge by hand.

 At least this represents a modicum of cooperation. Without the
published tar to start from, that someone may well start from scratch
and duplicate whatever effort you've already put in. Good luck a)
finding and b) merging any fixes from a completely separate tree.

> use CVS (or whatever is trendy) I hear you say? Well you have to set that
> up, and if you have CVS you have to police it, what if people check in
> broken code.
>
> It all takes time and concerntration, which would be better spent on
> getting on with the code and sorting it out.

 Disagree. Well, you're right that it takes time. But that time is a
one time cost, to set up and learn to use the VCS. Once you've made
that investment there is no constant drain on your time/concentration.
I'm not sure I agree that the time is better spent coding - I think if
you actually sat down with a modern DVCS like mercurial or git you'd
find it actually creates quite a nice environment for collaboration.
No need to worry about policing anything using the pull model.

 It's not like version control systems have a monopoly on tools you
need to invest time in before gaining productivity from them. Awk,
acid, acme, spin all require a certain amount of time investment to
understand how they work before the become useful tools.

> One of the biggest things we lack is Wifi support (IMHO) and Russ put
> up his incomplete Centrino driver a few years ago. How much interest has that
> sparked?

 Like I was saying, publishing code doesn't *generate* interest. It
just leaves open the possibility of someone using it later.

> Similarly the sshv2 code, though we now have openssh so its less of
> a problem.

 Michiel was looking at this just the other week.

> (my OS has 64 bits and yours doesn't),

 What OS doesn't have 64 bits these days, aside from Plan 9?
-sqweek

Re: [9fans] devtrace release time

[erik quanstrom]

On Thu Dec 18 13:08:15 EST 2008, sqweek@gmail.com wrote:
>  No no no, this is all release oriented stuff! Just put the code up so
> if someone really interested happens by they can check it out and work
> the details out themselves. What's the disadvantage there?

i think you have to understand that some people do not
approve of hanging their dirty laundry in public.  i think
one has to afford them this space.

>  Of course. But it's silly to entertain the notion that code comes off
> our fingertips perfect and fully formed. It's software: there's bugs,
> there's design flaws, development is incremental. Often it can be
> useful long before it is perfected.
[...]
> > whats worse is if you publish a tar and then somone fixes a load of
> > stuff but in the meantime you are working and your code gets out of sync
> > so you have to merge by hand.
[...]
>  At least this represents a modicum of cooperation. Without the

i have some experience in this.  i've published some
plan 9 early.

the downside is that you no longer have any control.
and thus you can't necessarly get bug fixes published.
there is no law that says, if you accept the original,
you must accept bug fixes and improvements.

so if one cares about the quality of the result, one
believes in one's own abilities, publishing a finished
thing can make a lot of sense.

this isn't what i do, and i pay a price for it.

- erik

Re: [9fans] devtrace release time

[C H Forsyth]

> "Alright, my x86-64 board arrived! I wanted to try out some other
>OSes, what have we here... hmm Plan 9, seems interesting... aw, no
>native port! Guess I'll try losethos."

the current amd64 port was just to get going, and it also
checked that the compiler could compile a running kernel.
it has enough restrictions that you wouldn't use it for
`production' use (in the Plan 9 sense!), and in the example context you
gave, it would just lead to mockery.

Re: [9fans] devtrace release time

[sqweek]

On Fri, Dec 19, 2008 at 4:06 AM, C H Forsyth <forsyth@vitanuova.com> wrote:
>> "Alright, my x86-64 board arrived! I wanted to try out some other
>>OSes, what have we here... hmm Plan 9, seems interesting... aw, no
>>native port! Guess I'll try losethos."
>
> the current amd64 port was just to get going, and it also
> checked that the compiler could compile a running kernel.
> it has enough restrictions that you wouldn't use it for
> `production' use (in the Plan 9 sense!), and in the example context you
> gave, it would just lead to mockery.

 Ah. Proof of concept is probably still interesting to someone taking
up the baton, though I guess in this instance they'd be more
interested in what was learned from the prototype in terms of the
changes that need to be made.
 Not that I'm aware of anyone gunning for that job, but I'm still not
seeing the downside of having the code out there. You're not in much
of a position to mock if you download code marked proof of concept
expecting it to be production ready...
-sqweek

Re: [9fans] devtrace release time

[ron minnich]

On Thu, Dec 18, 2008 at 2:50 PM, sqweek <sqweek@gmail.com> wrote:
>  You're not in much
> of a position to mock if you download code marked proof of concept
> expecting it to be production ready...


You must not read this list as much as I thought :-)

ron

Re: [9fans] devtrace release time

[ron minnich]

On Thu, Dec 18, 2008 at 12:47 AM,  <lucio@proxima.alt.za> wrote:
>Ron needed the
> software and Ron got it, whatever it took him to achieve this.  Can
> you spot the difference?]

It's a bit more than that: I saw a need starting in 2000, with the
initial open source release; I gave talks to anyone who would listen
in DOE and five years later started to get money. Money is a necessary
but not sufficient condition. Without people like Eric and Jim and
Charles it would still be all just talk; we are lucky to have those
smart people. It also takes a willingness, at times, to risk your job,
which at least one person on this project has done over the last 3
years. It's a *LOT* of work to get to where we are now. It's also
taken the determination of those at Bell Labs who were unwilling to
let it all die. I admire their dedication.

And we do have a sword hanging over our heads: we've got to get Plan 9
on the top 500 in 2009 or the DOE aspect of this may all go bust. So
you're looking at 9 years (feels like 90!) of pushing on strings with
a pretty hard deliverable next year.

I do see a gradual uptick on this list of people who are finding ways
to contribute, and that's good to see. And I also see a gradual
realization in my community that Linux is not the End of History where
kernels are concerned.

BTW, 9vx is making a lot of new fans. The startup is just breathtaking
and people get drawn in.

This project might only have happened in DOE, which is a very open
agency in these ways. It is unlikely that any other branch of the US
Gov't would have funded this work -- certainly DARPA would not have.

ron

Re: [9fans] devtrace release time

[lucio]

> And we do have a sword hanging over our heads: we've got to get Plan 9
> on the top 500 in 2009 or the DOE aspect of this may all go bust. So
> you're looking at 9 years (feels like 90!) of pushing on strings with
> a pretty hard deliverable next year.

Could you elaborate on "the top 500"?  And why is the community only
alerted now to this potentially very clear objective?  I'm sure we'd
all want to be of help rather than hindrance in such a situation?

++L

Re: [9fans] devtrace release time

[ron minnich]

On Thu, Dec 18, 2008 at 12:08 AM, sqweek <sqweek@gmail.com> wrote:

>  Yes, uriel's manner is abrasive, and it gets old listening to him
> make the same complaints over and over.
>when uriel perceives an inhibitor to plan 9's growth and development,
>uriel raises his voice (because no one else will!).

The interesting paradox being that Uriel has so annoyed some critical
people that they no longer post to this list.

Hence Uriel should raise his voice about uriel, as uriel is an
inhibitor. But wait, his voice *is* the inhibitor. Should he then not
raise his voice?

Should he raise his voice against himself?

What would the barber of Seville have to say about this? He only
shaves those who don't shave themselves!

ron