Linus on
Threads, Distributed Computing, Message Passing, Design and More

Subject: Re: SCO: "thread creation is about a thousand times faster than
Date: 27 Aug 2000 22:38:24 -0700
From: torvalds@transmeta.com (Linus Torvalds)
Organization: Transmeta Corporation
To: linux-kernel@vger.kernel.org

In article <52C41B218DE28244B071A1B96DD474F60AD231@DC-SRVR1.dotcast.com>,
Marty Fouts   wrote:
>
>I'm curious: what assumptions did we have about threads 15 years ago that
>turned out to be false?

Personal opinion, and it has nothing to do with "15 years ago" vs
"today":

The pthreads approach never got to a real framework for threads as real
entities.  To pthreads, a thread is a braindamaged stepchild of a
process, and cannot do anything on its own.  It's this drooling messy
thing that has no life without the parent process that wipes up after
it.  It has no spine.

In short, threads are not proper citizens.  They are guest workers.
Expendable.  Worthless.  They don't have a life of their own.

Now, the notion of rfork/clone/sproc "variable-weight processes" is not
new per se.  But it's an important _notion_.  It basically says that
threads are _not_ the ugly drooling stepson that you really wouldn't
want to see at family re-unions.

Suddenly, with rfork/clone/sproc, a thread is not just something that
you can prod in the right direction with the cattle prod of a random
collection of POSIX routines.  A thread is an Idea.  A Notion.
Something worthy of a capital letter.  Something you can discuss in
mixed company.

It's the difference between being useful and being Right.

It's hard to explain.  If you have a bent toward physics, it's the
difference between a practical experiment and the Unified Teory of
Everything. It's the difference between Galileo saying "everything falls
at the same speed" and Newton's "F = mMG/rē".

If you're religious, it's the difference between "It was a dark and
stormy night.." vs "Let there be Light!".

If you're into computers, it's the difference between Windows ("sure, it
works much of the time, and it looks pretty") and Unix ("everything is a
process or a file").

It's like an idea: there are mundane ideas ("hey, let's go out for pizza
and a beer") and there are big ideas ("I have a dream..").

The difference? The big idea leads to something larger than itself. It
makes people think about what the meaning of life is. It gives a
_direction_ for where things are supposed to go.

In contrast, a small idea leads to other small ideas (fifteen beers
later: "I know, let's drive past the police station and moon every cop
in the city!").

Ok. I'm overdoing it. But think of rfork/clone/sproc as a way to try to
come to grips with what it really means to be a thread. Be one with the
thread. Grok the threadedness - so that you can understand what is wrong
and what is right _without_ having to count every comma in a standards
draft that is 473 pages long.

In short, "pthreads" is a rough approximation of the theory of
magnetism.  While rfork/clone/sproc is Maxwell's equations.  One can
tell you how much force a magnet excerts on a charged particle in
motion.  The other one tries to explain how the universe works.

                Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Subject: Re: Some very thought-provoking ideas about OS architecture.
Date: 20 Jun 1999 17:52:33 GMT
From: torvalds@transmeta.com (Linus Torvalds)
Organization: Transmeta Corporation, Santa Clara, CA
To: linux-kernel@vger.rutgers.edu

In article ,
Rik van Riel   wrote:
>
>Unfortunately, EROS is still based on the PC hardware as
>we've got it today and not modeled after a JINI-like
>appliances model (the network is the computer).
>
>With the death of the monolithic computer (if it happens)
>will come the death of Unix, Windows _and_ EROS.

That's a classic thing said by "OS Research People".

And it's complete crap and idiocy, and I'm finally going to stand up and
ask people to THINK instead of repeating the old and stinking dogma.

It's _much_ better to have stand-alone appliances that can work well in
a networked environment than to have a networked appliance.

I don't understand people who think that "distribution" implies
"collective".  A distributed system should _not_ be composed of mindless
worker ants that only work together with other mindless worker ants.

A distributed system should be composed of individual stand-alone
systems that can work together.  They should be real systems in their
own right, and have the power to make their own decisions.  Too many
distributed OS projects are thinking "bees in a hive" - while what you
should aim for is "humans in society".

I'll take humans over bees any day.  Real OS's, with real operating
systems.  Monolithic, because they CAN stand alone, and in fact do most
of their stuff without needing hand-holding every single minute.
General-purpose instead of being able to do just one thing.

>At the moment I can see only one Open Source system that
>could become ready for a world like that.  Alliance OS
>(http://www.allos.org/).

I will tell you anything based on message passing is stupid. It's very
simple:

 - if you end up doing remote communication, the largest overhead is in
   the communication, not in how you initiate it. This is only going to
   be more true with mobile computing, not less.

   Ergo: optimizing for message passing is stupid. You should _always_
   optimize for the local case, because it's the only case where the
   calling protocol really matters - once you go remote you have time to
   massage the arguments any which way you like.

 - Most operations are going to be local. Any operating system that
   starts out from the notion that most operations are going to be
   remote is going to die off as computers get more and more powerful.

   Things may start off distributed, but in the end network bandwidth is
   always going to be more expensive than CPU power.

 - Truly mobile computing implies that a noticeable portion of the time
   you do _not_ want to be in contact with any other computers. Your
   computer had better be a very capable one even on its own. Anybody
   who thinks anything else is just unbelievably misguided.

   This implies that your computer had better have a local filesystem,
   and had better be designed to work as well without any connectivity
   as it does _with_ connectivity. It can't communicate, but that
   shouldn't mean that it can't work.

So right now people are pointing at PDA's, and saying that they should
be running a "light" OS, all based on message passing, because obviously
all the real work would be done on a server.  It makes sense, no?

NO.  It does NOT make sense.  People used to say the same thing about
workstations: workstations used to be expensive and not quite powerful
enough, and people wanted to have more than one.  Where are those people
today? Face it, the hardware just got so much better that suddenly REAL
operating systems didn't have any of the alledged downsides, and while
you obviously want the ability to communicate, you should not think that
that is what you optimize for.

The same is going to happen in the PDA space.  Right now we have PalmOS.
It's already doing internet connectivity, how much do you want to bet
that in the not too distant future they'll want to offer more and more?
There is no technical reason why a Palm in a few years won't have a few
hundred megs of RAM and a CPU that is quite equipped to handle a real
OS.  (If they had selected the strongarm instead of a cut-down 68k it
would already).

In short: message passing as the fundamental operation of the OS is just
an excercise in computer science masturbation.  It may feel good, but
you don't actually get anything DONE.  Nobody has ever shown that it
made sense in the real world.  It's basically just much simpler and
saner to have a function call interface, and for operations that are
non-local it gets transparently _promoted_ to a message.  There's no
reason why it should be considered to be a message when it starts out.

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Subject: Re: Some very thought-provoking ideas about OS architecture.
Date: 21 Jun 1999 18:10:42 GMT
From: torvalds@transmeta.com (Linus Torvalds)
Organization: Transmeta Corporation, Santa Clara, CA
To: linux-kernel@vger.rutgers.edu

In article <85256797.005DDAA9.00@D51MTA03.pok.ibm.com>,
  wrote:
>> Linus Torvalds wrote:
>> > In short: message passing as the fundamental operation of the OS is just
>> > an excercise in computer science masturbation.  It may feel good, but
>> > you don't actually get anything DONE.  Nobody has ever shown that it
>> > made sense in the real world.  It's basically just much simpler and
>> > saner to have a function call interface, and for operations that are
>> > non-local it gets transparently _promoted_ to a message.  There's no
>> > reason why it should be considered to be a message when it starts out.
>
>With due libations to the Gods here, Linus is mistaken on all counts.

It's happened before, it will happen again. However, you had better come
up with a better argument before I believe it happened this time.

>Moving a message from hither to yon *does* accomplish something: it moves a unit
>of work from one protection/encapsulation domain to another.

Ehh..  In real operating systems, we call that event a "system call".
No message necessary or implied, unless you want to call the notion of
switching privilege domains "messages" (and some people do: they call
them messages just to prove that messages are as fast as system calls.
In logic, that's equivalent to proving that liver tastes as good as ice
cream by calling ice cream liver, and is in real life called "lying").

The system call may be turned into a message later if that turns out to
be a good idea, but it's nothing inherent. AND IT SHOULD NOT BE.

>So: even if you think that message passing is not the way you wish to implement
>things, object based APIs offer greater flexibility of implementation, and this
>is generally a good thing.

Object-based API's are a completely different issue (I removed your
argument, because I think it is completely irrelevant to "messages").

I don't think object-based approaches are bad.  A lot of libraries
("stdio" in C) are based on that notion, and it's often the right way to
encapsulate information in user space.

HOWEVER: that is not an OS boundary, and should not be considered to be
one.  The _definition_ of a OS boundary is the boundary of protection
domains: the OS takes over where the library no longer has the
appropriate privileges to access the object any more.  Because if the
library could do the operation, it should - instead of bothering the OS
with it.

So in effect, at the OS boundary the object has to be pretty much
completely opaque, or it shouldn't be considered an OS boundary in the
first place.  QED.

That's why the OS boundary HAS to be equivalent to

        read(handle, buffer, size)

and NOT be equivalent to

        handle->op(READ, buffer, size);

because by definition, if you can do the "handle->op" lookup, then it's
not a OS boundary any more - or at least it is a very BAD one.  See?

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From:  Linus Torvalds 
Subject:  Re: Security question: "Text file busy" overwriting executables but not shared libraries?
To: Jamie Lokier 
CC:  "Eric W. Biederman" , 

On Sat, 13 Oct 2001, Jamie Lokier wrote:
>
> I can think of an efficiency-related use for MAP_COPY, and it has
> nothing to do with shared libraries:
>
>  - An editor using mmap() to read a file.

No, you're thinking the wrong way.

Trust me, MAP_COPY really _is_ stupid, and the Hurd is a piece of crap.

People who think MAP_COPY is a good idea are people who cannot think about
the implications of it, and cannot think about the alternatives.

In particular, you claim that you could use "mmap()" for "read()", and
speed up the application that way. Ok, fair enough.

Now, somebody who _isn't_ stupid (and that, of course, is me), immediately
goes "well, _duh_, why don't you speed up read() instead?".

The fact is, all the problems that "MAP_COPY" has just go away if you
instead of thinking about a mmap(), you think about doing a "read()" and
just marking the pages PAGE_COPY if they are exclusive.

In short: MAP_COPY is braindamaged, because it doesn't have enough
information at the right level to do a reasonable job of it. What people
want to use it for is really to emulate "read()" efficiently using mmap,
and _nothing_ else. That is the only reason for it ever existing, and the
fact is, that clearly shows just how _stupid_ the whole thing is.

You migth as well just do a read() in the first place.

Your arguments are
 - read() implies a memcpy()
 - read() dirties pages and causes more memory pressure

but you don't actually _question_ those arguments.

I will tell you that doing a read() that _acts_ like the MAP_COPY you so
want is a LOT easier than doing MAP_COPY in the first place.

Why?

 - a read() call doesn't have any "history" - it doesn't leave (bogus)
   VM data around like MAP_COPY does. MAP_COPY says "I want these pages to
   have the contents they did _when_I_did_the_mapping_", which is a
   temporal shift that just doesn't make sense in any sane VM model, and
   which inherently implies versioning.

 - a read() can fairly easily just do the optimization

        (a) if we're reading a large area
        (b) if the offset and the destination are page-aligned
        (c) if the page is exclusive (ie no existing other owners)
                then
        just do the page move instead of the copy, and mark the page as
        PAGE_COPY

   Every other use of the page that can change it (ie a shared writable
   mapping, or a "write()" call) will now check the PAGE_COPY bit on the
   _page_, and just say "ok, I'll allocate a new page, and atomically
   switch the ones, and leave the old page untouched and remove it from
   the page cache"

   (And the swap-out logic has to turn a PAGE_COPY page into a swap-cache
   page - this is the real downside, because it implies that we will have
   to write it out to swap if we're low on memory, unlike a real mmap)

Notice? Same as MAP_COPY, but without any global state.

And notice how this is actually conceptually much closer to what you
actually _want_ to use MAP_COPY for.

Could we implement MAP_COPY as such a read()? Yes, sure. But that's just
confusing the issue - why call it a mmap() at all, when it isn't. The day
when Hurd is so common that we want to emulate its braindamages is not
going to be in my life-time, I suspect.

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

From: Linus Torvalds 
Subject:  Re: [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists with insertion
To:  Paul McKenney 
CC: , , Rusty Russell 

On Sat, 13 Oct 2001, Linus Torvalds wrote:
>
> In short, RCU seems to be a case of "hey, that's cool", but it's a
> solution in search of a problem so severe that it is worth it.

Oh, and before people start telling me that RCU was successfully used in
AIX/projectX/xxxx/etc, you have to realize that I don't give a rats *ss
about the fact that there are OS's out there that are "more scalable".

The last time I looked, Solaris and AIX and all the rest of the "scalable"
systems were absolute pigs on smaller hardware, and the "scalability" in
them often translates into "we scale linearly to many CPU's by being
really bad even on one".

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 From:  Linus Torvalds 
                                                               00:15

 Subject:
        Re: Coding style - a non-issue
     To: 
        Victor Yodaiken 
    CC: 
        Rik van Riel , Andrew Morton ,
        Larry McVoy , Daniel Phillips ,
        Henning Schmiedehausen ,
        Jeff Garzik , 



On Fri, 30 Nov 2001, Victor Yodaiken wrote:
>
> Ok. There was no design, just "less than random mutations".
> Deep.

I'm not claiming to be deep, I'm claiming to do it for fun.

I _am_ claiming that the people who think you "design" software are
seriously simplifying the issue, and don't actually realize how they
themselves work.

> There was a overall architecture, from Dennis and Ken.

Ask them. I'll bet you five bucks they'll agree with me, not with you.
I've talked to both, but not really about this particular issue, so I
might lose, but I think I've got the much better odds.

If you want to see a system that was more thoroughly _designed_, you
should probably point not to Dennis and Ken, but to systems like L4 and
Plan-9, and people like Jochen Liedtk and Rob Pike.

And notice how they aren't all that popular or well known? "Design" is
like a religion - too much of it makes you inflexibly and unpopular.

The very architecture of UNIX has very much been an evolution. Sure, there
are some basic ideas, but basic ideas do not make a system.

When they say that the devil is in the details, they are trying to tell
you that the details MATTER. In fact, the details matter quite a lot more
than the design ever does.

> Here's a characteristic good Linux design method ,( or call it "less than random
> mutation method" if that makes you feel happy): read the literature,
> think hard, try something, implement

Hah.

I don't think I've seen very many examples of that particular design
methodology.

It's impressive that you think this is how stuff gets done, but from
personal experience I would say that it's certainly not true to any
noticeable degree. The impressive part is that Linux development could
_look_ to anybody like it is that organized.

Yes, people read literature too, but that tends to be quite spotty. t's
done mainly for details like TCP congestion control timeouts etc - they
are _important_ details, but at the same time we're talking about a few
hundred lines out of 20 _million_.

And no, I'm no tclaiming that the rest is "random". But I _am_ claiming
that there is no common goal, and that most development ends up being done
for fairly random reasons - one persons particular interest or similar.

It's "directed mutation" on a microscopic level, but there is very little
macroscopic direction. There are lots of individuals with some generic
feeling about where they want to take the system (and I'm obviously one of
them), but in the end we're all a bunch of people with not very good
vision.

And that is GOOD.

A strong vision and a sure hand sound like good things on paper. It's just
that I have never _ever_ met a technical person (including me) whom I
would trust to know what is really the right thing to do in the long run.

Too strong a strong vision can kill you - you'll walk right over the edge,
firm in the knowledge of the path in front of you.

I'd much rather have "brownian motion", where a lot of microscopic
directed improvements end up pushing the system slowly in a direction that
none of the individual developers really had the vision to see on their
own.

And I'm a firm believer that in order for this to work _well_, you have to
have a development group that is fairly strange and random.

To get back to the original claim - where Larry idolizes the Sun
engineering team for their singlemindedness and strict control - and the
claim that Linux seems ot get better "by luck": I really believe this is
important.

The problem with "singlemindedness and strict control" (or "design") is
that it sure gets you from point A to point B in a much straighter line,
and with less expenditure of energy, but how the HELL are you going to
consistently know where you actually want to end up? It's not like we know
that B is our final destination.

In fact, most developers don't know even what the right _intermediate_
destinations are, much less the final one. And having somebody who shows
you the "one true path" may be very nice for getting a project done, but I
have this strong belief that while the "one true path" sometimes ends up
being the right one (and with an intelligent leader it may _mostly_ be the
right one), every once in a while it's definitely the wrong thing to do.

And if you only walk in single file, and in the same direction, you only
need to make one mistake to die.

In contrast, if you walk in all directions at once, and kind of feel your
way around, you may not get to the point you _thought_ you wanted, but you
never make really bad mistakes, because you always ended up having to
satisfy a lot of _different_ opinions. You get a more balanced system.

This is what I meant by inbreeding, and the problem that UNIX
traditionally had with companies going for one niche.

(Linux companies also tend to aim for a niche, but they tend to aim for
_different_ niches, so the end result is the very "many different
directions" that I think is what you _want_ to have to survive).

> > And I will go further and claim that _no_ major software project that has
> > been successful in a general marketplace (as opposed to niches) has ever
> > gone through those nice lifecycles they tell you about in CompSci classes.
>
> That's classic:
>       A) "trust me"
>       B) now here's a monster bit of misdirection for you to choke on.
>
> Does anyone believe in those stupid software lifcycles?
> No.
> So does it follow that this has anything to do with design?
> No.

Hey, the whole _notion_ of "design" is that you know what you're going to
write, and you design for it.

Or do you have some other meaning of the word "design" that I haven't
heard about.

                Linus

Date: 	Tue, 7 May 2002 08:36:54 -0700 (PDT)
From: Linus Torvalds 
To: Anton Altaparmakov 
cc: Martin Dalecki ,
        Padraig Brady ,
        Kernel Mailing List 
Subject: Re: [PATCH] 2.5.14 IDE 56
In-Reply-To: <5.1.0.14.2.20020507153451.02381ec0@pop.cus.cam.ac.uk>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org


 [ First off: any IDE-only thing that doesn't work for SCSI or other disks
   doesn't solve a generic problem, so the complaint that some generic
   tools might use it is totally invalid. ]

On Tue, 7 May 2002, Anton Altaparmakov wrote:
>
> Linux's power is exactly that it can be used on anything from a wristwatch
> to a huge server and that it is flexible about everything. You are breaking
> this flexibility for no apparent reason. (I don't accept "I can't cope with
> this so I remove it." as a reason, sorry).

Run the 57 patch, and complain if something doesn't work.

Linux's power is that we FIX stuff. That we make it the best system
possible, and that we don't just whine and argue about things.

> As the new IDE maintainer so far we have only seen you removing one
> feature after the other in the name of cleanup, without adequate or even
> any at all(!) replacements,

Who cares? Have you found _anything_ that Martin removed that was at all
worthwhile? I sure haven't.

Guys, you have to realize that the IDE layer has eight YEARS of absolute
crap in it. Seriously. It's _never_ been cleaned up before. It has stuff
so distasteful that t's scary.

Take it from me: it's a _lot_ easier to add cruft and crap on top of clean
code. You can do it yourself if you want to. You don't need a maintainer
to add barnacles.

All the information that /proc/ide gave you is basically available in
hdparm, and for your dear embedded system it apparently takes up less
space by being in user space. So what is the problem?

My vote is to remove as much as humanly possible.

	"Everything should be made as simple as possible, but not
	 simpler" - Albert Einstein

Think about it, and really _understand_ it.

			Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Date: 	Sat, 11 May 2002 11:04:45 -0700 (PDT)
From: Linus Torvalds 
To: Gerrit Huizenga 
cc: Lincoln Dale , Andrew Morton ,
        Alan Cox ,
        Martin Dalecki ,
        Padraig Brady ,
        Anton Altaparmakov ,
        Kernel Mailing List 
Subject: Re: O_DIRECT performance impact on 2.4.18 (was: Re: [PATCH] 2.5.14
 IDE 56) 
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org



On Fri, 10 May 2002, Gerrit Huizenga wrote:
> In message , > : Li
> nus Torvalds writes:
> >
> > For O_DIRECT to be a win, you need to make it asynchronous.
>
> O_DIRECT is especially useful for applications which maintain their
> own cache, e.g. a database.  And adding Async to it is an even bigger
> bonus (another Oracleism we did in PTX).

The thing that has always disturbed me about O_DIRECT is that the whole
interface is just stupid, and was probably designed by a deranged monkey
on some serious mind-controlling substances [*].

It's simply not very pretty, and it doesn't perform very well either
because of the bad interfaces (where synchronocity of read/write is part
of it, but the inherent page-table-walking is another issue).

I bet you could get _better_ performance more cleanly by splitting up the
actual IO generation and the "user-space mapping" thing sanely. For
example, if you want to do an O_DIRECT read into a buffer, there is no
reason why it shouldn't be done in two phases:

 (1) readahead: allocate pages, and start the IO asynchronously
 (2) mmap the file with a MAP_UNCACHED flag, which causes read-faults to
     "steal" the page from the page cache and make it private to the
     mapping on page faults.

If you split it up like that, you can do much more interesting things than
O_DIRECT can do (ie the above is inherently asynchronous - we'll wait only
for IO to complete when the page is actually faulted in).

For O_DIRECT writes, you split it the other way around:

 (1) mmwrite() takes the pages in the memory area, and moves them into the
     page cache, removing the page from the page table (and only copies
     if existing pages already exist)
 (2) fdatasync_area(fd, offset, len)

Again, the above is likely to be a lot more efficient _and_ can do things
that O_DIRECT only dreams on.

With my suggested _sane_ interface, I can do a noncached file copy that
should be "perfect" even in the face of memory pressure by simply doing

	addr = mmap( ..  MAP_UNCACHED ..  src .. )
	mwrite(dst, addr, len);

which does true zero-copy (and, since mwrite removes it from the page
table anyway, you can actually avoid even the TLB overhead trivially: if
mwrite notices that the page isn't mapped, it will just take it directly
from the page cache).

Sadly, database people don't seem to have any understanding of good taste,
and various OS people end up usually just saying "Yes, Mr Oracle, I'll
open up any orifice I have for your pleasure".

			Linus

[*] In other words, it's an Oracleism.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Date: 	Tue, 6 Aug 2002 09:35:17 -0700 (PDT)
From: Linus Torvalds 
To: Rusty Russell 
cc: "David S. Miller" , ,
        
Subject: Re: [PATCH] kprobes for 2.5.30 
In-Reply-To: <20020806073804.690DE4BA4@lists.samba.org>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org


On Tue, 6 Aug 2002, Rusty Russell wrote:
> 
> > You mean _exception_ handlers. It's definitely not unnecessary. Exceptions 
> > can very much be preempted.
> 
> The patch changes traps 1 and 3 (debug & int3) to interrupt gates
> though.  

Yes, but then it enables interrupts at one point.

And I'm not saying that is wrong - I'm saying that the warning is really 
because you didn't tell the kernel that it was _not_ wrong. The warning is 
a "I got called with interrupts disabled, not nobody actually told me that 
I shouldn't reschedule. I will refuse to reschedule (exactly because 
interrupts weren't enabled), but I don't like the fact that somebody 
apparently did things behind my back".

Think of the kernel as a grumpy girlfriend that you just stood up, and 
bring flowers next time.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Date: 	Wed, 9 Oct 2002 10:50:15 -0700 (PDT)
From: Linus Torvalds 
To: Patrick Mochel 
cc: linux-kernel@vger.kernel.org
Subject: Re: [bk/patch] driver model update: device_unregister()
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org


On Wed, 9 Oct 2002, Patrick Mochel wrote:
> 
> Peter Anvin suggest 'kernfs', which ain't bad. Then again, we could just
> call it 'patfs'..

Oh, yeah, call it "patfs", you egomaniac. Or you could just name the whole
OS after yourself, and then the world will _really_ see what an inflated
ego you have.

Uhh.. I mean.. Never mind. 

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Subject: Re: is KERNEL developement finished, yet ???
From: torvalds@transmeta.com (Linus Torvalds)
Date: Thu, 5 Dec 2002 18:07:22 +0000 (UTC)
To: linux-kernel@vger.kernel.org

In article <000901c29c5d$6d194760$2e833841@joe>,
Joseph D. Wagner  wrote:

>
>Unix (and Linux) developers are far too concerned with clinging to the
>30-year-old outdated POSIX standard, which creates numerous problems when
>trying to advance new features.


No.

Only stupid people think they should throw away old proven concepts. 
What happens quite often in academia in particular is that you find a
problem you want to fix, and you re-design the whole system around your
fix. 

This is how we get crap like microkernels.  They have "an agenda", and
that's the _worst_ thing you can have when designing software.  You
fixate on some perceived problem, and the end result is that yes, maybe
you fixed _that_ problem, but in the meantime you also generated a whole
new of issues - usually things that were solved by the original
approach. 

The UNIX/Linux approach is a very pragmatic thing - leave the things
that work well alone.  There's no point in re-inventing the whole system
just because of some small perceived flaws. 


>This is not a design flaw per say, but let's face it: Unix would be a lot
>more secure (and more flexible in it's security) with ACL's.
>
>Microsoft Windows has had ACL's since 1991 (Windows NT 3.5?); that was 11
>years ago.


Yeah, and look how much more secure it is than UNIX.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Date:	Sun, 12 Jan 2003 12:22:26 -0800 (PST)
From: Linus Torvalds 
To: Rob Wilkens 
Cc: Christoph Hellwig , Greg KH ,
	Alan Cox ,
	William Lee Irwin III ,
	Linux Kernel Mailing List 
Subject: Re: any chance of 2.6.0-test*?
In-Reply-To: <1042401596.1209.51.camel@RobsPC.RobertWilkens.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List:	linux-kernel@vger.kernel.org


On Sun, 12 Jan 2003, Rob Wilkens wrote:
> 
> However, I have always been taught, and have always believed that
> "goto"s are inherently evil.  They are the creators of spaghetti code

No, you've been brainwashed by CS people who thought that Niklaus Wirth
actually knew what he was talking about. He didn't. He doesn't have a
frigging clue.

> (you start reading through the code to understand it (months or years
> after its written), and suddenly you jump to somewhere totally
> unrelated, and then jump somewhere else backwards, and it all gets ugly
> quickly).  This makes later debugging of code total hell.  

Any if-statement is a goto. As are all structured loops.

Ans sometimes structure is good. When it's good, you should use it.

And sometimes structure is _bad_, and gets into the way, and using a 
"goto" is just much clearer.

For example, it is quite common to have conditionals THAT DO NOT NEST.

In which case you have two possibilities

 - use goto, and be happy, since it doesn't enforce nesting

	This makes the code _more_ readable, since the code just does what 
	the algorithm says it should do.

 - duplicate the code, and rewrite it in a nesting form so that you can 
   use the structured jumps.

	This often makes the code much LESS readable, harder to maintain, 
	and bigger.

The Pascal language is a prime example of the latter problem. Because it 
doesn't have a "break" statement, loops in (traditional) Pascal end up 
often looking like total shit, because you have to add totally arbitrary 
logic to say "I'm done now".

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Date:	Sun, 12 Jan 2003 12:33:37 -0800 (PST)
From: Linus Torvalds 
To: Robert Love 
Cc: Rob Wilkens ,
	Christoph Hellwig , Greg KH ,
	Alan Cox ,
	William Lee Irwin III ,
	Linux Kernel Mailing List 
Subject: Re: any chance of 2.6.0-test*?
In-Reply-To: <1042403616.834.94.camel@phantasy>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List:	linux-kernel@vger.kernel.org


On 12 Jan 2003, Robert Love wrote:
> On Sun, 2003-01-12 at 15:22, Linus Torvalds wrote:
> 
> > No, you've been brainwashed by CS people who thought that Niklaus
> > Wirth actually knew what he was talking about. He didn't. He
> > doesn't have a frigging clue.
> 
> I thought Edsger Dijkstra coined the "gotos are evil" bit in his
> structured programming push?

Yeah, he did, but he's dead, and we shouldn't talk ill of the dead. So 
these days I can only rant about Niklaus Wirth, who took the "structured 
programming" thing and enforced it in his languages (Pascal and Modula-2), 
and thus forced his evil on untold generations of poor CS students who had 
to learn langauges that weren't actually useful for real work.

(Yeah, yeah, most _practical_ versions of Pascal ended up having all the 
stuff necessary to break structure, but as you may be able to tell, I was 
one of the unwashed masses who had to write in "standard Pascal" in my 
youth. I'm scarred for life).

			Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Subject: Re: [patch] futex requeueing feature, futex-requeue-2.5.69-D3
From: Linus Torvalds 
Date:Tue, 20 May 2003 08:46:09 -0700 (PDT)
To:Christoph Hellwig 
CC: Ingo Molnar , Rusty Russell , Ulrich Drepper , 

On Tue, 20 May 2003, Christoph Hellwig wrote:

>>
>> On Tue, May 20, 2003 at 11:03:36AM +0200, Ingo Molnar wrote:
>
>>> > have you all gone nuts??? It's not an option to break perfectly working
>>> > binaries out there.
>
>> 
>> Of course it is. 


NO. 

Christoph, get a grip. Ingo is 100% right.

IT IS NEVER ACCEPTABLE TO BREAK USER LEVEL BINARIES! In particular, we do 
_not_ do it just because of some sense of "aesthetics".

If you want "aesthetics", go play with microkernels, or other academic
projects. They don't care about their users, they care about their ideas. 
The end result is, in my opinion, CRAP.

Linux has never been that way. The _founding_ principle of Linux was
"compatibility". Don't ever forget that. The user comes first. ALWAYS.  
Pretty code is a desirable feature, but if prettifying the code breaks
user apps, it doesn't get prettified.

Repeat after me: the goodness of an operating system is not in how pretty 
it is, but in how well it supports the user.

Make it your mantra.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Subject: Re: log-buf-len dynamic
From: Linus Torvalds 
Date: Tue, 23 Sep 2003 15:54:22 -0700 (PDT)
To: Andrea Arcangeli 
CC: Kernel Mailing List , Matthew Wilcox , Marcelo Tosatti , Larry McVoy 

On Wed, 24 Sep 2003, Andrea Arcangeli wrote:

>> 
>> we have cvsps and subversion these days, it's not about cvs only anymore.


Neither of those are anywhere close to bk. 

In particular, they don't support any kind of distributed development.  
They aren't even trying to, I'm sad to say. And to me, distributed
development is the only thing that matters.

And I realise it isn't to you. You don't much care about merging, you only
have your tree you need to worry about. 

And you know what? You shouldn't have to care. I'm not berating you for
using CVS/SVN/whatever. I'm berating you for complaining when _others_
have come to the conclusion that CVS/SVN/whatever really doesn't cut it
for them.

Use CVS and be happy. But don't complain to others that have needs that 
CVS simply can't fill. 

  [ Bad analogy time ]

You're acting like a husband that has a wife that refuses to use make-up,
and thinks that everybody else should have ugly wives too, and calls them 
whores for being prettier.

Actually, in the CVS analogy, I don't think it's that your wife refuses to
use make-up, but that make-up doesn't actually help.

  [ Ok, let's see just _how_ badly I get flamed for that analogy. I
    admit, it really sucks, and is tasteless to boot. My bad. ]


>> But note that cvs+cvsps is already perfectly usable for me, most people
>> is readonly anyways


Indeed. That's pretty much all non-distributed stuff is useful for, from
where I'm stading.  Small projects with a few developers and a lot of
read-only stuff. And even there the developers will bitch about the
limitations.

Sure, SVN makes branches cheaper, but you still have to work with them
like under CVS, ie merging is a total disaster. And you still can't make 
it your private repository.

But that wasn't really my point. My point is that you're only starting
flame wars, with no actual point to your emails. Please don't.

	"Those that can, do. Those that can't, complain".

You're complaining, right now. Everybody who has ever used BK admits to 
its techical superiority. That's just a fact.

I don't care about source control software, so I'm not likely to start
coding one any time soon (like "ever") - but if I did, I'd be totally
_ashamed_ to push lower-quality stuff on users. I'd make excuses for it,
and I'd 'fess up when they didn't work. And I'd try my best to make it
better. Even if it took me a decade.

In contrast, what you're doing is saying "ignore the good stuff: use this
crap, because I'm buddies with the people developing it. We aren't even
trying to compete on technical terms, but we'll push our version on you
because we've got religion, and this doesn't contain any cow-meat". That's
bad - especially if others DON'T share the religion.

I'm ok with other people using NT. When it's better for them, that's their
choice. I work hard to make sure that the Linux kernel is technically
superior, and if I feel it isn't I want to fix it. Because I do _not_ want
people using Linux for religious reasons. I want people to use Linux
because it is _better_ for them, of because they truly believe that they
can make it so (or at least have fun trying).

Take pride in what you do. But don't make that pride blind you to what is 
good technology, and what isn't. Don't get religion. It's a science.

Oh well. I told you not to start a flamewar, and I told Larry to not raise 
to the bait. Now I'll just take my own advice and stop responding. You too 
please stop baiting,

			Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Subject:Re: msync() behaviour broken for MS_ASYNC, revert patch?
From: Linus Torvalds 
Date:Wed, 31 Mar 2004 16:08:05 -0800 (PST)
To:"Stephen C. Tweedie" 
CC:linux-mm , Andrew Morton , linux-kernel , Ulrich Drepper 

On Wed, 1 Apr 2004, Stephen C. Tweedie wrote:

>> 
>> On Wed, 2004-03-31 at 23:37, Linus Torvalds wrote:
>>
>
>>> > If you care about the data hitting the disk, you have to use fsync() or 
>>> > similar _anyway_, and pretending anything else is just bogus.
>
>> 
>> You can make the same argument for either implementation of MS_ASYNC. 


Exactly.

Which is why I say that the implementation cannot matter, because user 
space would be _buggy_ if it depended on some timing issue.


>> And there's at least one way in which the "submit IO now" version can be
>> used meaningfully --- if you've got several specific areas of data in
>> one or more mappings that need flushed to disk, you'd be able to
>> initiate IO with multiple MS_ASYNC calls and then wait for completion
>> with either MS_SYNC or fsync().


Why wouldn't you be able to do that with the current one?

Tha advantage of the current MS_ASYNC is absolutely astoundingly HUGE: 
because we don't wait for in-progress IO, it can be used to efficiently 
synchronize multiple different areas, and then after that waiting for them 
with _one_ single fsync().

In contrast, the "wait for queued IO" approach can't sanely do that, 
exactly because it will wait in the middle, depending on other activity at 
the same time. It will always have the worry that it happens to do the 
msync() at the wrong time, and then wait synchronously when it shouldn't.

More importanrtly, the current behaviour makes certain patterns _possible_ 
that your suggested semantics simply cannot do efficiently. If we have 
data records smaller than a page, and want to mark them dirty as they 
happen, the current msync() allows that - it doesn't matter that another 
datum was marked dirty just a moment ago. Then, you do one fsync() only 
when you actually want to _commit_ a series of updates before you change 
the index. 

But if we want to have another flag, with MS_HALF_ASYNC, that's certainly
ok by me. I'm all for choice. It's just that I most definitely want the 
choice of doing it the way we do it now, since I consider that to be the 
_sane_ way.


>> It's very much visible, just from a performance perspective, if you want
>> to support "kick off this IO, I'm going to wait for the completion
>> shortly."


That may well be worth a call of its own. It has nothing to do with memory 
mapping, though - what you're really looking for is fasync(). 

And yes, I agree that _that_ would make sense. Havign some primitives to 
start writeout of an area of a file would likely be a good thing.

I'd be perfectly happy with a set of file cache control operations, 
including

 - start writeback in [a,b]
 - wait for [a,b] stable
 - and maybe "punch hole in [a,b]"

Then you could use these for write() in addition to mmap(), and you can 
first mark multiple regions dirty, and then do a single wait (which is 
clearly more efficient than synchronously waiting for multiple regions).

But none of these have anything to do with what SuS or any other standard 
says about MS_ASYNC. 


>> But whether that's a legal use of MS_ASYNC really depends on what the
>> standard is requiring.  I could be persuaded either way.  Uli?


My argument was that a standard CANNOT say anything one way or the other, 
because the behaviour IS NOT USER-VISIBLE! A program fundamentally cannot 
care, since the only issue is a pure implementation issue of "which queue" 
the data got queued onto.

Bringing in a standards body is irrelevant. It's like trying to use the 
bible to determine whether protons have a positive charge. 

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 Linux kernel management style

This is a short document describing the preferred (or made up, depending
on who you ask) management style for the linux kernel.  It's meant to
mirror the CodingStyle document to some degree, and mainly written to
avoid answering (*) the same (or similar) questions over and over again. 

Management style is very personal and much harder to quantify than
simple coding style rules, so this document may or may not have anything
to do with reality.  It started as a lark, but that doesn't mean that it
might not actually be true. You'll have to decide for yourself.

Btw, when talking about "kernel manager", it's all about the technical
lead persons, not the people who do traditional management inside
companies.  If you sign purchase orders or you have any clue about the
budget of your group, you're almost certainly not a kernel manager. 
These suggestions may or may not apply to you. 

First off, I'd suggest buying "Seven Habits of Highly Successful
People", and NOT read it.  Burn it, it's a great symbolic gesture. 

(*) This document does so not so much by answering the question, but by
making it painfully obvious to the questioner that we don't have a clue
to what the answer is. 

Anyway, here goes:


		Chapter 1: Decisions

Everybody thinks managers make decisions, and that decision-making is
important.  The bigger and more painful the decision, the bigger the
manager must be to make it.  That's very deep and obvious, but it's not
actually true. 

The name of the game is to _avoid_ having to make a decision.  In
particular, if somebody tells you "choose (a) or (b), we really need you
to decide on this", you're in trouble as a manager.  The people you
manage had better know the details better than you, so if they come to
you for a technical decision, you're screwed.  You're clearly not
competent to make that decision for them. 

(Corollary:if the people you manage don't know the details better than
you, you're also screwed, although for a totally different reason. 
Namely that you are in the wrong job, and that _they_ should be managing
your brilliance instead). 

So the name of the game is to _avoid_ decisions, at least the big and
painful ones.  Making small and non-consequential decisions is fine, and
makes you look like you know what you're doing, so what a kernel manager
needs to do is to turn the big and painful ones into small things where
nobody really cares. 

It helps to realize that the key difference between a big decision and a
small one is whether you can fix your decision afterwards.  Any decision
can be made small by just always making sure that if you were wrong (and
you _will_ be wrong), you can always undo the damage later by
backtracking.  Suddenly, you get to be doubly managerial for making
_two_ inconsequential decisions - the wrong one _and_ the right one. 

And people will even see that as true leadership (*cough* bullshit
*cough*).

Thus the key to avoiding big decisions becomes to just avoiding to do
things that can't be undone.  Don't get ushered into a corner from which
you cannot escape.  A cornered rat may be dangerous - a cornered manager
is just pitiful. 

It turns out that since nobody would be stupid enough to ever really let
a kernel manager have huge fiscal responsibility _anyway_, it's usually
fairly easy to backtrack.  Since you're not going to be able to waste
huge amounts of money that you might not be able to repay, the only
thing you can backtrack on is a technical decision, and there
back-tracking is very easy: just tell everybody that you were an
incompetent nincompoop, say you're sorry, and undo all the worthless
work you had people work on for the last year.  Suddenly the decision
you made a year ago wasn't a big decision after all, since it could be
easily undone. 

It turns out that some people have trouble with this approach, for two
reasons:
 - admitting you were an idiot is harder than it looks.  We all like to
   maintain appearances, and coming out in public to say that you were
   wrong is sometimes very hard indeed. 
 - having somebody tell you that what you worked on for the last year
   wasn't worthwhile after all can be hard on the poor lowly engineers
   too, and while the actual _work_ was easy enough to undo by just
   deleting it, you may have irrevocably lost the trust of that
   engineer.  And remember: "irrevocable" was what we tried to avoid in
   the first place, and your decision ended up being a big one after
   all. 

Happily, both of these reasons can be mitigated effectively by just
admitting up-front that you don't have a friggin' clue, and telling
people ahead of the fact that your decision is purely preliminary, and
might be the wrong thing.  You should always reserve the right to change
your mind, and make people very _aware_ of that.  And it's much easier
to admit that you are stupid when you haven't _yet_ done the really
stupid thing.

Then, when it really does turn out to be stupid, people just roll their
eyes and say "Oops, he did it again".  

This preemptive admission of incompetence might also make the people who
actually do the work also think twice about whether it's worth doing or
not.  After all, if _they_ aren't certain whether it's a good idea, you
sure as hell shouldn't encourage them by promising them that what they
work on will be included.  Make them at least think twice before they
embark on a big endeavor. 

Remember: they'd better know more about the details than you do, and
they usually already think they have the answer to everything.  The best
thing you can do as a manager is not to instill confidence, but rather a
healthy dose of critical thinking on what they do. 

Btw, another way to avoid a decision is to plaintively just whine "can't
we just do both?" and look pitiful.  Trust me, it works.  If it's not
clear which approach is better, they'll eventually figure it out.  The
answer may end up being that both teams get so frustrated by the
situation that they just give up. 

That may sound like a failure, but it's usually a sign that there was
something wrong with both projects, and the reason the people involved
couldn't decide was that they were both wrong.  You end up coming up
smelling like roses, and you avoided yet another decision that you could
have screwed up on. 


		Chapter 2: People

Most people are idiots, and being a manager means you'll have to deal
with it, and perhaps more importantly, that _they_ have to deal with
_you_. 

It turns out that while it's easy to undo technical mistakes, it's not
as easy to undo personality disorders.  You just have to live with
theirs - and yours. 

However, in order to prepare yourself as a kernel manager, it's best to
remember not to burn any bridges, bomb any innocent villagers, or
alienate too many kernel developers. It turns out that alienating people
is fairly easy, and un-alienating them is hard. Thus "alienating"
immediately falls under the heading of "not reversible", and becomes a
no-no according to Chapter 1.

There's just a few simple rules here:
 (1) don't call people d*ckheads (at least not in public)
 (2) learn how to apologize when you forgot rule (1)

The problem with #1 is that it's very easy to do, since you can say
"you're a d*ckhead" in millions of different ways (*), sometimes without
even realizing it, and almost always with a white-hot conviction that
you are right. 

And the more convinced you are that you are right (and let's face it,
you can call just about _anybody_ a d*ckhead, and you often _will_ be
right), the harder it ends up being to apologize afterwards. 

To solve this problem, you really only have two options:
 - get really good at apologies
 - spread the "love" out so evenly that nobody really ends up feeling
   like they get unfairly targeted.  Make it inventive enough, and they
   might even be amused. 

The option of being unfailingly polite really doesn't exist. Nobody will
trust somebody who is so clearly hiding his true character.

(*) Paul Simon sang "Fifty Ways to Lose Your Lover", because quite
frankly, "A Million Ways to Tell a Developer He Is a D*ckhead" doesn't
scan nearly as well.  But I'm sure he thought about it. 


		Chapter 3: People II - the Good Kind

While it turns out that most people are idiots, the corollary to that is
sadly that you are one too, and that while we can all bask in the secure
knowledge that we're better than the average person (let's face it,
nobody ever believes that they're average or below-average), we should
also admit that we're not the sharpest knife around, and there will be
other people that are less of an idiot that you are. 

Some people react badly to smart people.  Others take advantage of them. 

Make sure that you, as a kernel maintainer, are in the second group. 
Suck up to them, because they are the people who will make your job
easier. In particular, they'll be able to make your decisions for you,
which is what the game is all about.

So when you find somebody smarter than you are, just coast along.  Your
management responsibilities largely become ones of saying "Sounds like a
good idea - go wild", or "That sounds good, but what about xxx?".  The
second version in particular is a great way to either learn something
new about "xxx" or seem _extra_ managerial by pointing out something the
smarter person hadn't thought about.  In either case, you win.

One thing to look out for is to realize that greatness in one area does
not necessarily translate to other areas.  So you might prod people in
specific directions, but let's face it, they might be good at what they
do, and suck at everything else.  The good news is that people tend to
naturally gravitate back to what they are good at, so it's not like you
are doing something irreversible when you _do_ prod them in some
direction, just don't push too hard.


		Chapter 4: Placing blame

Things will go wrong, and people want somebody to blame. Tag, you're it.

It's not actually that hard to accept the blame, especially if people
kind of realize that it wasn't _all_ your fault.  Which brings us to the
best way of taking the blame: do it for another guy. You'll feel good
for taking the fall, he'll feel good about not getting blamed, and the
guy who lost his whole 36GB porn-collection because of your incompetence
will grudgingly admit that you at least didn't try to weasel out of it.

Then make the developer who really screwed up (if you can find him) know
_in_private_ that he screwed up.  Not just so he can avoid it in the
future, but so that he knows he owes you one.  And, perhaps even more
importantly, he's also likely the person who can fix it.  Because, let's
face it, it sure ain't you. 

Taking the blame is also why you get to be manager in the first place. 
It's part of what makes people trust you, and allow you the potential
glory, because you're the one who gets to say "I screwed up".  And if
you've followed the previous rules, you'll be pretty good at saying that
by now. 


		Chapter 5: Things to avoid

There's one thing people hate even more than being called "d*ckhead",
and that is being called a "d*ckhead" in a sanctimonious voice.  The
first you can apologize for, the second one you won't really get the
chance.  They likely will no longer be listening even if you otherwise
do a good job. 

We all think we're better than anybody else, which means that when
somebody else puts on airs, it _really_ rubs us the wrong way.  You may
be morally and intellectually superior to everybody around you, but
don't try to make it too obvious unless you really _intend_ to irritate
somebody (*). 

Similarly, don't be too polite or subtle about things. Politeness easily
ends up going overboard and hiding the problem, and as they say, "On the
internet, nobody can hear you being subtle". Use a big blunt object to
hammer the point in, because you can't really depend on people getting
your point otherwise.

Some humor can help pad both the bluntness and the moralizing.  Going
overboard to the point of being ridiculous can drive a point home
without making it painful to the recipient, who just thinks you're being
silly.  It can thus help get through the personal mental block we all
have about criticism. 

(*) Hint: internet newsgroups that are not directly related to your work
are great ways to take out your frustrations at other people. Write
insulting posts with a sneer just to get into a good flame every once in
a while, and you'll feel cleansed. Just don't crap too close to home.


		Chapter 6: Why me?

Since your main responsibility seems to be to take the blame for other
peoples mistakes, and make it painfully obvious to everybody else that
you're incompetent, the obvious question becomes one of why do it in the
first place?

First off, while you may or may not get screaming teenage girls (or
boys, let's not be judgmental or sexist here) knocking on your dressing
room door, you _will_ get an immense feeling of personal accomplishment
for being "in charge".  Never mind the fact that you're really leading
by trying to keep up with everybody else and running after them as fast
as you can.  Everybody will still think you're the person in charge. 

It's a great job if you can hack it.