Subject: Kernel configuration. It's not just a job, it's an adventure! (fwd)

From: mulix <[email-masked]>
Date: Sun, 17 Jun 2001 10:00:12 +0300 (IDT)

i figure this is amusing enough to be forwarded here, for those of you
who don't read linux-kernel.

-- 
mulix
http://www.advogato.com/person/mulix

linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead

---------- Forwarded message ----------
Date: Sat, 16 Jun 2001 22:27:09 -0400
From: Eric S. Raymond <[email-masked]>
To: CML2 <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Kernel configuration.  It's not just a job, it's an adventure!

Various people on the Linux kernel mailing list and elsewhere have been heard
to opine that CML2's user interface is too oriented towards nontechnical
users.  In response to these complaints, I have implemented a fourth CML2
front end with an interface style expressly designed for the serious,
hard-core hacker.  A transcript of an example session follows:

----------------------------------------------------------------------------
Welcome to CML2 Adventure, version 1.6.1.
You are in a maze of twisty little Linux kernel options menus, all different.
The main room.  A sign reads `Linux Kernel Configuration System'.
Passages lead off in all directions.

> n
The arch room.  A sign reads `Processor type'.
A passage leads upwards.

Choose your processor architecture.
A brass lantern is here.
There is a row of buttons on the wall of this room. They read:
X86, ALPHA, SPARC32, SPARC64, MIPS32, MIPS64, PPC, M68K, ARM, SUPERH, IA64, PARISC, S390, S390X, CRIS
The button marked X86 is pressed.
> take lantern
Lantern: taken.
> look X86
Value of X86 is y.
This is Linux's home port.  Linux was originally native to the Intel
386, and runs on all the later x86 processors including the Intel
486, 586, Pentiums, and various instruction-set-compatible chips by
AMD, Cyrix, and others.
> up
In main room.
> nearby
The arch room.  A sign reads `Processor type'.
The archihacks room.  A sign reads `Architecture-specific hardware hacks'.
The buses room.  A sign reads `System buses and controller types'.
The pm room.  A sign reads `Power management'.
The mtd room.  A sign reads `Memory Technology Device (MTD) support'.
The x86 room.  A sign reads `Intel and compatible 80x86 processor options'.
The policy room.  A sign reads `Configuration policy options'.
The generic room.  A sign reads `Architecture-independent feature selections'.
The block_devices room.  A sign reads `Block devices'.

> go generic
The generic room.  A sign reads `Architecture-independent feature selections'.
A passage leads upwards.

There is an option named MODULES here.
There is an option named NET here.
There is an option named SYSVIPC here.
There is an option named BSD_PROCESS_ACCT here.
There is an option named SYSCTL here.
There is an option named BINFMT_AOUT here.
There is an option named BINFMT_MISC here.
There is an option named SMP here.
> take NET
NET: taken.
> take MODULES
Tristate symbols won't default to M.
MODULES: taken.
> up
In main room.
> nearby
The arch room.  A sign reads `Processor type'.
The archihacks room.  A sign reads `Architecture-specific hardware hacks'.
The buses room.  A sign reads `System buses and controller types'.
The pm room.  A sign reads `Power management'.
The mtd room.  A sign reads `Memory Technology Device (MTD) support'.
The x86 room.  A sign reads `Intel and compatible 80x86 processor options'.
The policy room.  A sign reads `Configuration policy options'.
The generic room.  A sign reads `Architecture-independent feature selections'.
The block_devices room.  A sign reads `Block devices'.

> go buses
The buses room.  A sign reads `System buses and controller types'.
A passage leads upwards.

Specify the buses, disk controllers, and internal interconnection standards
that you want your kernel to support.
It is very dark.  If you continue, you are likely to be eaten by a grue.
There is an option named EISA here.
There is an option named PCI here.
There is an option named PNP here.
There is an option named PARPORT here.
There is an option named HOTPLUG here.
There is an option named IDE here.
There is an option named SCSI here.
There is an option named USB here.
There is an option named I2O here.
There is an option named MTD here.
There is an option named WATCHDOG here.
> light lantern
The lantern radiates a mellow golden light.
> take PCI
PCI: taken.
> help
Welcome to the adventure configurator.  For a command summary, type `commands'.
In general, a three-letter abbreviation of any command word is sufficient
to identify it to the parser.

This interface emulates the style of classic text adventure games such as
Colossal Cave Adventure and Zork.  Configuration menus are rooms, and
configuration options are objects that can be taken and dropped (except
for choice/radiobutton symbols, which become buttons on various room walls).
Objects and rooms may silently appear and disappear as visibilities
change.

Have fun, and beware of the grues!

In main room.
> commands
look [target] -- look here or at target (direction or option).
nearby        -- list nearby rooms (useful with go)
go            -- go to a named menu (follow with the label).
inventory     -- show which options you have picked up.
drop          -- unset option.
take [module] -- set option, follow with option name.
press         -- press a button (follow with the button name).
set           -- set numeric or string; follow with symbol and value.
load          -- read in a configuration (follow with the filename).
save          -- save the configuration (follow with a filename).
xyzzy         -- toggle suppression flag.
quit          -- quit, discarding changes.
exit          -- exit, saving the configuration.
You can move in compass directions n,e,w,s,ne,nw,se,sw or dn for down.
> quit
----------------------------------------------------------------------------
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

What, then is law [government]? It is the collective organization of
the individual right to lawful defense."
	-- Frederic Bastiat, "The Law"

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

---

From: "Nadav Har'El" <[email-masked]>
Date: Sun, 17 Jun 2001 12:06:13 +0300

> who don't read linux-kernel.

Yes, the deluge of postings on the linux-kernel mailing-lists (There are
sometimes hundreds of messages a day. Sometimes I don't even find the time
to read the subject lines of all of them...) sometimes provides us with
a funny or interesting post. Here is one from a couple of days ago that
I find amusing. Shows a great deal of animosity between the developers of
Linux and the developers of *BSD. I wonder when the tabloids and gossip
columns in newspapers pick up on this juice fight :)

This thread discussed how to stop Linux from blinking the text cursor (on
the console windows), and why it does blink. It started off seriously, but
then reached the following pinnacle of human expression:

-------------------
Date:   Fri, 15 Jun 2001 15:21:54 -0400 (EDT)
From: "Albert D. Cahalan" <[email-masked]>
Cc: [email-masked]
Subject: Re: [patch] nonblinking VGA block cursor

Leon Breedt writes:
> Attached is a patch to enforce a non-blinking, FreeBSD-syscons like
> block cursor in console mode.
>
> This is useful for laptop types, or people like me who really really
> detest a blinking cursor.
>
> NOTE: It disables the softcursor escape codes
>       (/usr/src/linux/Documentation/VGA-softcursor.txt), since I don't
>       ever want anything to change my cursor shape/style :)

I've seen this 666 times too often.

Non-blinking cursors are just wrong. You need to patch your brain.
You really fucked up, because now apps can't restore your cursor
to proper behavior as defined by IBM.

The blinking cursor is implemented in your video hardware.
IBM knew what was right for you. Millions of people know that
the blinking cursor is good. It is so right that a proper GUI
will implement the blinking cursor even without hardware support.

Of course FreeBSD has a block cursor. It was easy to program,
and it seems nice to the pot-smoking hippies out in Berkeley.
FreeBSD doesn't define standards. FreeBSD breaks standards.
(zombie creation, "ps -ef", partition tables, pty allocation...)
Gee, kind of like Microsoft, except Microsoft got the cursor right!

Ever wonder why IBM supports Linux instead of FreeBSD? Hmmm?
-------------------

-- 
Nadav Har'El                        |       Sunday, Jun 17 2001, 26 Sivan 5761
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Isn't Disney World a people trap
http://nadav.harel.org.il           |operated by a mouse?

---

From: mulix <[email-masked]>
Date: Sun, 17 Jun 2001 12:21:11 +0300 (IDT)

> columns in newspapers pick up on this juice fight :)

you think this is bad? try this post, from bugtraq, no less:
http://www.securityfocus.com/archive/1/188474

written by al viro, one of the core kernel fs layer people, and directly
attacking openbsd for sloppy kernel programming. you might be aware that
a local root exploit on openbsd was published on bugtraq last week.
inquiring minds wonder if this is the same sort of race al viro is
warning about here...

quote:

"It's not just sloppy. It's obviously broken - obviously for anyone with
half of clue.

I can easily provide more examples of the same crap and so can anyone
who would bother to RTFS the descriptor handling in kern/*. Apparently
that had never happened during the last 5 years or so.

I'm not talking about the bugs that would require anything nontrivial to
find and understand. Just follow the yello^Wpiles of sloppy C and nearly
every one will turn out to be exploitable. And no, it's not limited to
descriptor handling - same goes for sys_pipe.c, etc.

Theo had been informed about that crap. Couple of weeks ago. Finding and
fixing these bugs is a simple matter of grep. So far it hadn't been
done. I've proposed to help with that, but apparently it got no
interest.  <shrug> Very well, there are other piles of garbage in need
of fixing and seeing crappy code in obscure Linux drivers is less
disturbing than that in core kernel.

Frankly. my respect to Theo went way down. This code had never been read
through, let alone audited. And that's the core kernel. Moreover, the
same bugs had been fixed in FreeBSD half a year ago. In other words,
just keeping an eye on other *BSD trees would be enough to catch them.
Same for lurking on freebsd-hackers. Same for watching the Linux tree,
where an audit of relevant areas had been done nearly two years ago.
Done and discussed on linux-kernel. Sad...

#include <stdrants/people_dont_bother_to_RTFS.h>

end quote.