Slashdot Mirror

sed '/^$/d' to delete blank lines

sed 's/ *$//' to remove trailing spaces

sed 1d to delete the first line of something

Google turned up a couple sed faqs:

http://www.dreamwvr.com/sed-info/sed-faq.html

http://www.faqs.org/faqs/editor-faq/sed/

If you're using bash or zsh with the default emacs-like bindings, you can use ctrl-r to do an interactive backwards search in your history. Just keep hitting ctrl-r to search deeper back into the history.

Also, the one thing I've noted a lot of intermediate Linux users don't know about, but find very useful upon investigation is job control. Even with good window management and multiple xterms, job control is very useful: I often have three or four jobs on each xterm. Also, a neat trick: with zsh or bash, "fg %-" goes back to the second-to-last job. You can use this to quickly suspend and switch between two jobs continuously (eg, after you've done it once, "ctrl-z, ctrl-p, enter" switches to the "other" job).

Also, if there's a long command I recently executed, I usually won't search through history, but rather use the "!cmd" thing. Eg, if you've recently run "gcc -g -Wall -O3 -blahblah ..." a few commands ago, you can do it again by just typing "!gc" without searching. I guess it's really a question of preference, but I picked this up from the older gurus who were weaned on the monstrosity which is the C shell.

And thats the point: So far we've only observed Gamma-bursters in young galaxies in the early stages of galaxy formation. Not in old galaxies like our own.

Yes you can argue that and it's very plausible that they might be a factor of a young Universe. I don't completely agree with the reasoning however, and there are other possibilities.

Most notably there are so many more far-away galaxies than nearby galaxies. More recent estimations based on the hubble deep field have placed it at possibly 80 billion galaxies, or at least something on that order. Nearly all of them are an incredibly long way away from us.

Even though there are lots of gamma ray bursters, it's no real surprise that any given event is likely to happen in a far away location from nearly every other point in the Universe. It's already been argued that gamma ray bursts have enough energy that it'll eventually be visible from everywhere no matter how far away it happens. The reason we're seeing so many of them is that we're (arguably) seeing about as far as it's possible to see.

Under this scenario, it's completely possible that gamma ray bursts happen in older galaxies, too. The only reason we haven't seen them yet is because there aren't enough older galaxies nearby to have justified the probability of it happening while we're here to watch. In an estimated 80 billion galaxies, we're only detecting about one burst per day, from an entirely random direction.

If we are seeing every one that happens within these 80 billion galaxies, and if you figure it out on a calculator, a typical galaxy would average a gamma ray burst about every 220 million years... if it was a uniform distribution throughout the life of the Universe.

Again, it's all theory.

I have worked closely with three shops in the previous three years that used Microsoft Exchange. Each had at least 3 full time equivalents of MSCEs to babysit their Exchange servers, probably more if you count overtime. This is not counting the occasional high priced consultant. None of these shops could keep Exchange running for a full week. Nor could they keep it from losing mail (When I measured it was 10-15%, ). Nor could they get it to communicate well with other mail servers. Nor could they keep it from getting wiped out once every three months by MSTDs (especially worms and virii).

In contrast, Novell servers run years at a time unattended (nearly every consultant has at least two such anecdotes of their own) and many UNIX-based MTA's need only a few hours of non-hardware maintenance per year, when set up tight. I guess running MS-Exchange is a new status thing to flaunt resources, like having a tuburcular wife was during the Vicrotian era.

Needless to say the managment's support was/is a real PITA for anyone doing work via e-mail with people outside of the house's MS-Intranet. In one case it even delayed a publishing a book by several weeks. In house use of Exchange was fine -- when it was down for you, it was down for everyone else so it was a nice time out and a chance to go have coffee with the others. When put to the test, file sharing couldn't, wouldn't, didn't function often enough to be useful either. For file sharing, those without access to a Novell or Unix file server, used sneaker net or mailed attachments. Yes, Exchange does look good in the 4-color glossy marketing brochure, but that's were it ends and reality sets in.

Puh.

Back to mail databases. RFC 2822, Internet Message Format specifies the general structure of a message. This can be over simplified as a header with its standard and non-standard fields and one or more message bodies. RFC2049 specifies multipart bodies. These structures do seem very well suited to a relational database.

The Kinesis changed my life, pure and simple. Before this keyboard I tried many alternatives, including the MS Natural keyboard, and none of them releived me of the constant pain in my hands. At one point in my career it got so bad that the pain at night prevented me from sleeping -- even if I spent a day or two away from the computer.

After trying the Kinesis, not only do I feel that my typing is faster (and ABSOLUTELY more comfortable), my pain is all but gone -- and this includes stretches of days with 20 hours of typing per day.

It's impossible for me to heap enough superlatives at this product. To say that it saved my career as a computer scientist is not overstating it. I can recommend it whole-heartedly, and urge anyone who has pain to at least give it a shot.

I'm in no way associated with Kineses (other than being a very satisfied customer) but I am so impressed with their keyboards that I actually offered to invest in the company (at the time they weren't soliciting outside investors).

Here is where I bought my keyboard (see the picture of it on the home page): DMB Ergonomics

And here is some additional information that might be helpful:
Alternative Keyboards

Typing Injury FAQ

• Persistent and temporary file formats
• User interface
• Network protocols
• System and architectural design
• Relationships between data elements (or objects if you think that way)

faqs.org has some instructions that might help..

Back when the company was in Glendale (before it became the big ISP we all know and hate) it was staffed with like 90% Scientologists. The CTO was Brian Wenger, who used to edit the "Pro-Scientology" FAQ

Another of their employees was Philip Gale. He worked there when he was 16, before going to MIT and killing himself.

Stay far away from Earthlink...Not only are they a shitty business, but any money you send there way helps Scientology.

In actuality, an email address can contain almost anything except '@', a '%' or a '!'. Yes, email addresses can even contain spaces if you quote them: "FirstName LastName"@domain.com is a perfectly valid email address.

I agree with the sentiment, but I don't think that's exactly correct. Those special characters are also allowed under RFC 822, just as long as they are quoted.

As a practical matter, both sendmail and qmail seem to allow those characters quite happily. I just sent email from qmail and sendmail boxes to a qmail box with addresses like "foo@@example.com", "bar!@example.com", and "foobar!%@@example.com", and all of them got to the destination machine and were delivered happily.

2.2.9 Organization The text of this line is a short phrase describing the organization to which the sender belongs, or to which the machine belongs. The intent of this line is to help identify the person posting the message, since site names are often cryptic enough to make it hard to recognize the organization by the electronic address.

The bottom line is that from the Internet's point of view, your ISP and network provider is RoadRunner, so it makes perfect sense to label you as being part of that "organization" in this context. It is both within the letter and spirit of NNTP. To allow you to use your own vanity Organization header would only add confusion and defeats the spirit of the header.

In particular the software was PhotoRealistic RenderMan (PRMan). See the renderman FAQ. Also the NeXTSTEP 3D Graphics Kit, an API, was based on RenderMan.

"obscurity is an accepted security paradigm"

That phrase was either taken completely out of context, or is just plain wrong. But then again, they can teach whatever they want at CS courses.

Pfleeger probably has a more pragmatic approach than for example people with an encryption background such as Bruce Schneier.

My point is: Obscurity does not make anything more secure. It only delays the discovery and exploitation of an existing security leak. The world is full of examples in this matter. Sure, when securing something obscurity can be used as a tool to give a better probability of the security hole to be fixed before it's discovered, but that assumes you're searching for them better and faster than the crackers.

So obscurity can be helpful in delaying the attackers and giving you an edge, but only when combined with significant effort from your end to stay ahead. Hence, obscurity not a security paradigm, just one of the security tools in a much larger toolbox. If you use obscurity as a paradigm, you're basically just hoping that 'they' don't find your network.

A good reading on the subject of security through obscurity is the snake oil faq. Pay special attention to the section about 'secret algorithms'.

What's the definition of "deep linking"? Is this some kind of special URL that is not the same as every other URL?

According to RFC 2396, an absolute HTTP URI consists of http://[userinfo@]host[:port]/path. If path is not empty, then the link is considered "deep".

telnet mail.xyz.com 110

user (username)
pass (password)
list
top (number of message to check) (kb to read)
dele (message to delete)
retr (number of message to read entirely)
quit

Quicker, cheaper, easier. This was one of the best tips I got from a friendly sysadmin. :)

Of course, I would ask why CmdrTaco didn't check the RFC, but hey, who am I to question slashdot's leader? ;)

you can be quite sure that MS will fight compatibility tooth and nail

The iCalendar Message-Based Interoperability Protocol (iMIP) makes it simple to exchange scheduling and contact information between various programs, including Outlook, via text files.

well.... the way things are now, the biggest hardware cost for space flight is the launch vehicle. you need like 7.5 kilometers/second to get into Low Earth Orbit, this generally sets you back $5K to $10K per kg into LEO (or like a factor of 3 or 4 higher for Geosynchronous Transfer Orbit, which is used for comm sats).


http://www.faqs.org/faqs/space/launchers/


then you need like another 3 or 4 kilometers/second to get to the rest of the solar system (and you can do tricks like gravity assist etc once away from earth)

so the problem isnt using a chem. rocket to go to mars, jupiter, etc but hauling that rocket's fuel up into LEO...

solar sails require zero fuel. other futuristic space propulsion types all consume LOTS of power, which means bigger launch vehicle, bigger costs

Although I couldn't find a definition for the term trojan horse on CERT's website, a link was provided to the comp.virus FAQ. According to it, a trojan horse is:

A TROJAN HORSE is a program that does something undocumented that the programmer intended, but that some users would not approve of if they knew about it.

What RadWare's software is doing makes it perfectly clear that spyware should be treated as a trojan horse (with legal implications where applicable), beacause that's what it is.

well, according to RFC 1591, .ORG was intended for "organizations that didn't fit anywhere else."

So take the set of all organisations, remove commercial organisations (.COM), educational institutions (.EDU), government organisations (.GOV), military organisations (.MIL) and network providers (.NET) and you pretty much have only non-profits and special interest groups left -- people who are unlikely to have thousand of dollars up their sleeves.

DNS: see RFC 2671. It uses a label type that was deliberately reserved in the original standard in order to send extended information, and a new resource type, OPT, that lets you advertise what extensions you support and to send more kinds of request than could possibly be encoded in the original standard.

NNTP: see RFC 2980. (The extension mechanism seems to be that if the client sends an extended command that's not recognised, it'll get an error. :) )

DNS: see RFC 2671. It uses a label type that was deliberately reserved in the original standard in order to send extended information, and a new resource type, OPT, that lets you advertise what extensions you support and to send more kinds of request than could possibly be encoded in the original standard.

NNTP: see RFC 2980. (The extension mechanism seems to be that if the client sends an extended command that's not recognised, it'll get an error. :) )

7.2.1 Type
[snip]
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. [snipped]

Get the A/UX FAQ here:
http://www.faqs.org/faqs/aux-faq/
It's really long and covers any question that would ever have about this old OS.

Orange

From their our technology page: "SIP-thru-NAT, Vonage's proprietary communications technology. "

NAT
SIP

Doesn't look terribly proprietary to me :)

From their our technology page: "SIP-thru-NAT, Vonage's proprietary communications technology. "

NAT
SIP

Doesn't look terribly proprietary to me :)

So when a joke RFC is submitted, it's a fun joke, but when the patent office has a joke patent, they're morons? C'mon, it's a joke. Laugh.

7.2.1 Type
[snip]
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. [snipped]

<news truth="0">

Mozilla.org has signed a deal with Distributed Computing Technologies Inc. to include encryption research software in the official binary releases of Mozilla 1.0 Release Candidate 5. The RC5 build will include a distributed application to measure the strength of RSA's RC5 cipher, described in RFC 2040.

</news>

Please try to get some information about what type 1 (juvenile-onset) diabetes is - somewhere other than Hollywood *roll of eyes*.

As FallLine has already corrected here, if a type 1 diabetic goes into a "coma", it's probably due to hypoglycaemia or a low blood-sugar level. The blood-glucose level is normally kept from going too high by injections of insulin, usually two to four a day. Note that some people who are not diabetics can also suffer from hypoglycaemia. As FallLine also pointed out, any injection given to a person in a hypoglycaemic coma would (well, should :) be an injection of glucose. Which works damn fast to bring one out it - or so I've been told by those who have seen me coming out of a coma after a glucose injection :). BTW, from what I've heard of the plot development, it's quite plausible that the girl should have dropped into a coma. Extreme stress can lower blood sugar level rather quickly.

The important thing to remember is that a healthy type 1 diabetic can survive for quite a long time without insulin. They'd feel like complete shit, of course, and they'd have no energy and hardly be able to eat anything with carbohydrates in it (because that would only drive their BGL higher), but they don't just up and die due to lack of insulin.

BTW, also try not to confuse type 1 and type 2 (mature onset, not-insulin-dependent) diabetes, because I'm sure someone's going to do it in this discussion sooner or later, eg. "my seventy-year-old dad has diabetes and he doesn't blah blah blah..." *roll of eyes, grin*

Have a look through the misc.health.diabetes FAQ for more information.

Pete.

Please try to get some information about what type 1 (juvenile-onset) diabetes is - somewhere other than Hollywood *roll of eyes*.

As FallLine has already corrected here, if a type 1 diabetic goes into a "coma", it's probably due to hypoglycaemia or a low blood-sugar level. The blood-glucose level is normally kept from going too high by injections of insulin, usually two to four a day. Note that some people who are not diabetics can also suffer from hypoglycaemia. As FallLine also pointed out, any injection given to a person in a hypoglycaemic coma would (well, should :) be an injection of glucose. Which works damn fast to bring one out it - or so I've been told by those who have seen me coming out of a coma after a glucose injection :). BTW, from what I've heard of the plot development, it's quite plausible that the girl should have dropped into a coma. Extreme stress can lower blood sugar level rather quickly.

The important thing to remember is that a healthy type 1 diabetic can survive for quite a long time without insulin. They'd feel like complete shit, of course, and they'd have no energy and hardly be able to eat anything with carbohydrates in it (because that would only drive their BGL higher), but they don't just up and die due to lack of insulin.

BTW, also try not to confuse type 1 and type 2 (mature onset, not-insulin-dependent) diabetes, because I'm sure someone's going to do it in this discussion sooner or later, eg. "my seventy-year-old dad has diabetes and he doesn't blah blah blah..." *roll of eyes, grin*

Have a look through the misc.health.diabetes FAQ for more information.

Pete.

In Einstein's theory of General Relativity (which is what predicts ways of building devices allowing travel backwards in time), even stating conservation laws is problematic, and in fact on a large scale in our universe, they appear to be violated.

(Yes, stuff your physics teacher didn't tell you about.)

I can only point you to the following internet standard:

Subliminal Telnet

So yes, someone thought of it before.

Dave.

I usually type in root@127.0.0.1 as the email address... let 'em clog up their own mail server.

root@127.0.0.1 is not a valid address. Sending email to such address usually gives some error like unrouteable mail domain "127.0.0.1" because there's no MX record in DNS for 1.0.0.127.in-addr.arpa (but I'm not sure if it would work even if there was such record, I'm too lazy to test it). Use root@[127.0.0.1] if you want email to literal ip address bypassing the standard MX resolving (see RFC 822). But the mail server can be configured to reject them, and e.g. my server will give you this error: root@[127.0.0.1] domain literals not allowed.

So the root@localhost is probably the the best choice (but it still sometimes may not work as you expect, if the "localhost" is not set as local domain of SMTP server). But remember that even when you make them spam local root mailbox, it's usually their own account, not the one of their ISP.

When I have to ever register with working email I make alias like spam-from-yahoo.com@my.domain so I always know who sends spam and I can always deactivate such alias. But I have yet to see anyone selling my spam-from-their.domain@my.domain address to anyone.

If you can't easily edit /etc/aliases on your mail server (and if you're not your own postmaster, it's usually true) check out spamgourmet self-destructing disposable email addresses:

After you save and confirm the email address where you'd like to receive messages, you can give out self-destructing disposable email addresses whenever you want as follows:

someword.x.user@spamgourmet.com

where someword is a word you haven't used before, x is the number of email messages you want to receive at the address (up to 20), and user is your username. For example, if your username is 'spamcowboy', and you give this address to somebody (or, more probably, some thing):

spamelope.2.spamcowboy@spamgourmet.com

the address will be created here the first time it is used, and you'll receive at most two messages (forwarded to the email address you specify above) on the address. The rest will be indelicately consumed. That's it. You won't ever have to come back here.

I don't use it because I have my own mail server and I can do whatever I want (or whatever I can) with my mail address, but spamgourmet seems to be great if you just have one mailbox somewhere like most of the people.

The standard version of ping uses ICMP echo requests.
http://www.faqs.org/rfcs/rfc792.html
</nitpick>

Part of what makes RF radio stations economical--and even occasionally profitable--is that the marginal cost of providing the broadcast service to an additional listener is essentially nil, modulo geographic saturation and transmitter power.

Today's streaming media services, however, incur a high marginal cost per additional listener--cost scales linearly with the number of listeners. There have been several attempts (Akamai, RBN) to get listeners to use a "nearby" transmitter, but these only flatten the cost-per-additional-listener line a bit by saving money close to the originating transmitter.

The Internet evolved a more bandwidth- and cost-efficient distribution model years ago in the form of multicast, but it was never widely implemented in enough of the places where it would have made a difference--backbones, routers, terminal servers, DSLAMs, cable companies, etc.

The idea is that a multicast packet stream should have a very small bandwidth footprint for the most expensive parts of the trip from transmitter to the receivers, only needing to be duplicated at the last few legs of the trip, where receivers aren't on the same physical network.

IOW, no matter how many of an ISP's customers are listening to a multicast stream, the ISP only has to transfer the packets from the expensive Internet once, and then make sure they get routed down the cheaper links to those customers who are listening.

Now that NAT is becoming more and more widespread, the situation doesn't look good--but hopefully IPv6 will kill NAT, and improve the multicast situation by opening up a vastly larger range of multicast addresses, and therefore a larger maximum number of simultaneous multicast connections.

Some fun links:

An Introduction to IP Multicast Routing (from Google cache, the site seems to be down)

Some stuff from Cisco

RFC2375: IPv6 Multicast Address Assignments

IPv6 Multicast Standards

Ok, let Fritz quote Godwin's.

however Fritz should have flamed out a long time ago.

can determine what is the final target destination instantly, since the LOCAL IP address field of the connection contains the target server's IP address. There is no need for the proxy application to ask the client what is the final target system.

can determine what is the final target destination instantly, since the LOCAL IP address field of the connection contains the target server's IP address. There is no need for the proxy application to ask the client what is the final target system.

There is no mechanism to check to see if proxy12 has the document the user is requesting that now proxy23 needs to get.

There exists even an RFC describing this.
RFC2052 -- A DNS RR for specifying the location of services (DNS SRV)

• AIX is dying.
• AmigaOS is dying.
• BSD is dying.
• BeOS is dying.
• CPM is dying.
• DOS is dying.
• FreeBSD is dying.
• GNU Hurd is dying.
• HP-UX is dying.
• IRIX is dying.
• Inferno is dying.
• Linux is dying.
• LynxOS is dying.
• MINIX is dying.
• MacOS is dying.
• Mach is dying.
• MicroC/OS is dying.
• NachOS is dying.
• NeXT is dying.
• Nemesis is dying.
• NetBSD is dying.
• NetWare is dying.
• OS-400 is dying.
• OS-9 is dying.
• OS/2 is dying.
• Oberon is dying.
• OpenBSD is dying.
• Palm OS is dying.
• Plan 9 is dying.
• pSOS is dying.
• QNX is dying.
• RTEMS is dying.
• SCO is dying.
• Solaris is dying.
• SunOS is dying.
• TRON is dying.
• ThreadX is dying.
• TinyOS is dying.
• Unix is dying.
• VMS is dying.
• VxWorks is dying.
• Windows 2000 is dying.
• Windows 3.11 is dying.
• Windows 95 is dying.
• Windows 98 is dying.
• Windows CE is dying.
• Windows ME is dying.
• Windows NT is dying.
• Windows XP is dying.

The operating system loader, BIOS, or other firmware required at boot time or when installing the operating system would generally not be considered part of the operating system, though this distinction is unclear in the case of a rommable operating system such as RISC OS. The facilities an operating system provides and its general design philosophy exert an extremely strong influence on programming style and on the technical cultures that grow up around the machines on which it runs.

The comp.os.research FAQ makes the following distinction between micro- and macrokernels:
"A recurrent topic of discussion in this newsgroup has been the comparison between microkernel (for example Mach and QNX) and `macrokernel' (traditional Unix) operating systems. The basic notion of a microkernel consists of devolving as much functionality as possible into processes rather than the kernel itself; different systems take different approaches to implementing this.

For example, some systems (such as Mach) leave device drivers in the kernel, and place higher-level services (such as file systems) outside; others (such as QNX) move device drivers outside of the kernel.

However, anecdotal evidence [93-03-03-07-56.52] suggests that the distinction between microkernel and monolithic architectures is becoming more blurred as time goes on, as the two advance. For example, most modern monolithic kernels now implement multiple threads of execution and fine-grained parallelism. Architecturally, this approach begins to appear similar to a microkernel with several kernel-space processes working from shared memory.

As an aside, people often complain that the Mach system can't be a `real' microkernel, because it is so large (at least, this is the argument most frequently cited). However, I have been told that automatically-generated code stubs contribute very significantly to the size of the kernel, and that some size reduction would be likely if MIG (the stub generator) produced better code. [Can someone from CMU comment on this?] As mentioned above, the leaving of device drivers in the kernel also contributes to Mach's size.

Debating microkernels versus monolithic kernels on the basis of kernel size misses the central, architectural point. In the same way as the point of a RISC processor is not to minimise the instruction count, but rather to make a different tradeoff between what is implemented in the processor instruction set and what is implemented in other ways, the microkernel architectural issue is to determine which services are implemented in the microkernel, and which services are implemented external to that microkernel. By making appropriate choices here, the goal is to enhance various OS attributes in a manner that might not be addressable with a monolithic kernel OS. System attributes such as performance, flexibility, realtime, etc. are all variables which are taken into account.

Sorry, doesn't work that way.

See http://www.faqs.org/faqs/usenet/legends/godwin/.

rancid mystery loaves
steady micron slavery
comedy striven salary
trendy mosaic slavery
convert already missy
scary devil monastery
misty adversary clone
mail covers dysentary
discover anal mystery

(alt.sysadmin.recovery)

Official acronym list from the ASR FAQ

Read the alt.usage.english FAQ

(sorry for off-topicness)

If you're interested in how they syncronize the noisy lasers, here is a shortcut to the non-linear faq... a bit of easy evening reading for your enjoyment.

• AIX is dying.
• AmigaOS is dying.
• BSD is dying.
• BeOS is dying.
• CPM is dying.
• DOS is dying.
• FreeBSD is dying.
• GNU Hurd is dying.
• HP-UX is dying.
• IRIX is dying.
• Inferno is dying.
• Linux is dying.
• LynxOS is dying.
• MINIX is dying.
• MacOS is dying.
• Mach is dying.
• MicroC/OS is dying.
• NachOS is dying.
• NeXT is dying.
• Nemesis is dying.
• NetBSD is dying.
• NetWare is dying.
• OS-400 is dying.
• OS-9 is dying.
• OS/2 is dying.
• Oberon is dying.
• OpenBSD is dying.
• Palm OS is dying.
• Plan 9 is dying.
• pSOS is dying.
• QNX is dying.
• RTEMS is dying.
• SCO is dying.
• Solaris is dying.
• SunOS is dying.
• TRON is dying.
• ThreadX is dying.
• TinyOS is dying.
• Unix is dying.
• VMS is dying.
• VxWorks is dying.
• Windows 2000 is dying.
• Windows 3.11 is dying.
• Windows 95 is dying.
• Windows 98 is dying.
• Windows CE is dying.
• Windows ME is dying.
• Windows NT is dying.
• Windows XP is dying.

The operating system loader, BIOS, or other firmware required at boot time or when installing the operating system would generally not be considered part of the operating system, though this distinction is unclear in the case of a rommable operating system such as RISC OS. The facilities an operating system provides and its general design philosophy exert an extremely strong influence on programming style and on the technical cultures that grow up around the machines on which it runs.

The comp.os.research FAQ makes the following distinction between micro- and macrokernels:

"A recurrent topic of discussion in this newsgroup has been the comparison between microkernel (for example Mach and QNX) and `macrokernel' (traditional Unix) operating systems. The basic notion of a microkernel consists of devolving as much functionality as possible into processes rather than the kernel itself; different systems take different approaches to implementing this.

For example, some systems (such as Mach) leave device drivers in the kernel, and place higher-level services (such as file systems) outside; others (such as QNX) move device drivers outside of the kernel.

However, anecdotal evidence [93-03-03-07-56.52] suggests that the distinction between microkernel and monolithic architectures is becoming more blurred as time goes on, as the two advance. For example, most modern monolithic kernels now implement multiple threads of execution and fine-grained parallelism. Architecturally, this approach begins to appear similar to a microkernel with several kernel-space processes working from shared memory.

As an aside, people often complain that the Mach system can't be a `real' microkernel, because it is so large (at least, this is the argument most frequently cited). However, I have been told that automatically-generated code stubs contribute very significantly to the size of the kernel, and that some size reduction would be likely if MIG (the stub generator) produced better code. [Can someone from CMU comment on this?] As mentioned above, the leaving of device drivers in the kernel also contributes to Mach's size.

Debating microkernels versus monolithic kernels on the basis of kernel size misses the central, architectural point. In the same way as the point of a RISC processor is not to minimise the instruction count, but rather to make a different tradeoff between what is implemented in the processor instruction set and what is implemented in other ways, the microkernel architectural issue is to determine which services are implemented in the microkernel, and which services are implemented external to that microkernel. By making appropriate choices here, the goal is to enhance various OS attributes in a manner that might not be addressable with a monolithic kernel OS. System attributes such as performance, flexibility, realtime, etc. are all variables which are taken into account.

any packet loss wouldnt be as bad as if your packets got routed by rfc1149 in hunting season. RFC 2549 is slightly better, but not much.

any packet loss wouldnt be as bad as if your packets got routed by rfc1149 in hunting season. RFC 2549 is slightly better, but not much.

• WSDL schemas so that you could do this using SOAP;
• Microsoft IDL, so that you could do this using COM;
• For insult's sake, CORBA IDL;
• Integration with A Standard for the Transmission of IP Datagrams on Avian Carriers
• An extension that involves using a whiffle bat to convince the unwary that this isn't going to be too painful...

There are but weeks to go; time to start reviewing other 04/01 RFCs for further inspiration....

Sorry, you can't get away with that nowadays.

RFC 2549 updates RFC 1149 with added Quality of Service.

Ahhh. Perhaps they are adapting the Avian Carrier technology to Large Ruminants to provide lower altitude, higher throughput (camels can carry more than birds) service. Latency is still pretty bad, I'll bet.