Slashdot Mirror

Python is not the most popular, though it's moved up a lot. Languages without static typing are barbaric

As older /.ers will remember, "Real Programmers don't write in PASCAL, or BLISS, or ADA, or any of those pinko computer science languages. Strong typing is for people with weak memories." - Real Programmers Don't Write Specs

> You are not an opponent, you are nobody.

Yet you seem to be compelled to reply to me. I find that funny.

> You fucked up by spouting off about 9 bits and you haven't been able to recover.

You're under the mistaken impression I'm loosing this debate. You're also mistaken that my argument depends on 9-bit bytes existing.

> The Texas Instruments engineers are bright people, who are not part of this conversation.

But their work is. And they have a product where a byte is not 8 bits.

> They did not utilize 9 bit bytes

Read my previous post again, I never said TI used a 9-bit byte. I said they used a 16-bit byte. So if your statement of "There are 8 bits in a byte, period." is correct then the bright Texas Instrument engineers must be wrong for saying their product uses a 16-bit byte.

> nor did anyone else for that matter.

Multics

https://en.wikipedia.org/wiki/... - "The standard C programming language requires that the size of the char data type be at least 8 bits,[3] and that all data types other than bitfields have a size that is a multiple of the character size,[4] so standard C implementations on 36-bit machines would typically use 9-bit chars, although 12-bit, 18-bit, or 36-bit would also satisfy the requirements of the standard."

https://isocpp.org/wiki/faq/in... - "The C++ language guarantees that a char* (char pointers) can address individual bytes." and "Another valid approach would be to define a “byte” as 9 bits"

http://multicians.org/pg/mvm.h... - "To get 64K (256KB, using 9-bit bytes"

> In the future, feel free to sling your garbage as it pertains to any real byte implementation.

I just gave you an example where a byte was not 8 bits but you chose to reply right away with insults instead of actually reading what I wrote about a product that uses 16-bit bytes.

Even if an architecture that used a 9-bit byte never existed it doesn't matter. My argument was that a byte is not always 8-bits. The 16-bit byte DSP I mentioned proved that I was correct.

MULTICS had email in 1965. It was written by Noel Morris and Tom Van Vleck, though it was designed a little earlier. The credit for coming up with the idea usually goes to Glenda Schroeder.

So it's like Cheverolet claiming he invented the Cheverolet; except hardly anyone ever used or heard of "EMAIL".

The history of the internet disagrees with you. If by "hardly anyone" you mean the thousands of users of ARAPNET which spanned the US with hundreds of servers by the time this so-called person "invented" email. "In 1971, Ray Tomlinson, of BBN sent the first network e-mail (RFC 524, RFC 561).[57] By 1973, e-mail constituted 75 percent of ARPANET traffic."

V1 of Unix from 1971 had a man page for the mail command. Multics had a MAIL command. Shiva did not invent these systems that are the fundamental basis of modern email.

If Shiva claims to have coined the term email in short form or as an acronym (EMAIL) or as the name for his system, fine. But there is a big difference between coining a term and inventing something and we already have well explored this concept in society. By trying to create this stupid fantasy of his, he's just losing all his credibility and we will just ignore him.

The amazing thing is, this guy seems smart and well spoken, why would he ruin his reputation by making easily disprovable claims over such a widely used and revered technology. It's proof that you have to be careful with people and what they say, they may just be a crazy fucker.

Format drive and install one of the following operating systems:

• BeOS
• Syllable
• AROS
• Plan 9
• Minix
• FreeDOS
• DR-DOS
• OpenVMS x86 port is coming!
• Visopsys
• SqueakNOS
• Haiku
• Kolibri
• ReactOS
• Tizen
• SkyOS
• MorphOS
• MenuetOS
• CP/M 86
• Multics, also see Multicians
• Erlang as an Operating System

There have been a large number of more or less obscure operating systems and not all have been ported to x86. Unfortunately the architecture has become a de facto standard even though it's not the best architecture or the most efficient but instead a patchwork of solutions to retain backwards compatibility. We have lost many interesting architectures over the years that would have deserved a better fate to the Intel bandwagon.

Right, that is an understatement. The Multics CPUs were multimillion dollar systems with dedicated support staff that took up large rooms. Compared to which most DEC machines of the time were less than toys. That's why UNIX was considered an "emasculated" Multics. It's really sad that BTL bailed, but such is life. The Multics memory protection mechanisms are so much different than what was available then, or now, that porting directly to x86/x84 is not feasible. We got it working under emulation only with much effort. That said, the folks doing the VMS port to x86/64 had similar problems with the x86 architecture. They decided to implement various missing bits in software. A x64 port of Multics would be quite doable using the same techniques. The realization of which is left as a exercise for the reader. For more information see http://multicians.org/ https://sourceforge.net/projec... andhttp://ringzero.wikidot.com/ Multics Lives! "Multics rulez, UNIX droolz"

Bah, forget this newfangled crap, Multics was doing this half a century ago (which includes use of RAID tape drives, checkpointing, ACLs, and other recent innovations).

We went to lunch afterward, and I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, "We left all that stuff out. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'"

Still happens ...

Both UUCP and TCP/IP had email (although the ip side lagged badly, mail was really invented at Bell,

No, it wasn't.

IP made very crude versions of this ad took forever to do it)

Inter-host email came out the same year that UNIX first existed, and wasn't invented at Bell Labs. It ran over NCP, because TCP/IP didn't even exist yet.

SMTP, which ran over TCP and NCP, was first specified in 1982, slightly after TCP was first specified.

If they're starting from scratch, I hope they will design for security rigor from the start. Recommend Multics as a case study. Not saying copy from architecture, but learn from intellectual approach. See http://www.multicians.org/hist...

Unix is not Multics and that is really all you need to know about Multics

There are many interesting aspects about Multics that deserve to be heard about if not studied. To name a few: the second-dimension access system or protection rings via "ring brackets" that allowed a 'r', 'w' or 'x' access to a "segment"/file depending on the caller (user or daemon) own "running ring". Thus, a lower (higher privilege) ring program would extend its r&|x access via brackets to allow a user to enter that program (a "gate"). For instance the continuums (now forums) were usually running in ring 3, while a simple user was in 4 (the core system was in 0). Multics had also convenient and powerful ACL, accesses provided to user/group-project/login-mode. Using long names or short names for a file(segment)... Studying a bit of Multics helps to realize that most of OSes concepts were already invented ~50 years ago...

Unix is not Multics and that is really all you need to know about Multics

There are many interesting aspects about Multics that deserve to be heard about if not studied. To name a few: the second-dimension access system or protection rings via "ring brackets" that allowed a 'r', 'w' or 'x' access to a "segment"/file depending on the caller (user or daemon) own "running ring". Thus, a lower (higher privilege) ring program would extend its r&|x access via brackets to allow a user to enter that program (a "gate"). For instance the continuums (now forums) were usually running in ring 3, while a simple user was in 4 (the core system was in 0). Multics had also convenient and powerful ACL, accesses provided to user/group-project/login-mode. Using long names or short names for a file(segment)... Studying a bit of Multics helps to realize that most of OSes concepts were already invented ~50 years ago...

\

I personally have noticed little progression and indeed in many areas a general regression in the quality and reliability of software since approximately 2006/7.

You want to start reading the design and code of Multics which are somewhere on the Multicians site. You will soon come to realise that software design has been going backwards since at least the 1960s. Probaly since Lady Ada herself.

There are reasons for that. The generations of people become broader and less special in the general population; the historical cruft becomes greater; the systems and requirements become more complex and require more hackery to implement. However '"brogrammers", "hipsters" and "neckbeads"' probably have a relatively small input into this.

PL/I differed from C in that C didn't have a lot of hacked in stuff. The two languages are alike in that they let you do lots of things, even write entire, sophisticated operating systems. Multics was written in PL/I and it was an early example of a multi-user, multi-tasking, multi-CPU, shared memory system with strong security.
Another way they are similar is that both will let you easily write code that will crazy things and be very difficult to debug.

Huh? CTSS is a time sharing system! Of course you're sharing the core.

Well, depends on your point of view. I believe that CTSS was swapping whole cores when doing the VM switch, so you're sharing the HW but not even the physical address space - there was only one user program running in the B-core at any given instant. Each of the time-sharing users was provided with an illusion of a whole physical machine, much like with VM/CMS.

From http://www.multicians.org/thvv/compatible-time-sharing-system.pdf

7094 CPU Modifications. The hardware RPQs that made CTSS run on MIT’s 7094s
added an interval timer (B/M 570220) and memory boundary and relocation registers
(RPQ E007291) to the 7094 processor.

[...]

Memory Boundaries and Swapping. CTSS used the modified 7094’s memory boundary
register to limit user jobs’ access to only part of B-core, so that the supervisor didn’t have
to swap 32K to the drum for every job.

Nope, sounds like it could have multiple jobs in core.

Sounds like the Multics Cookie Monster.
The Wikipedia entry has a slightly different take on the story.

I recommend looking at some of the Multics features, particularly the use of segmentation and paging instead of a more normal file system.
see http://www.multicians.org/features.html for an introduction to Multics features and the references for how they really work. Multics was written to run on an SMP system so a system with 1 processor was the special case.

I would also suggest looking into security, again both the permissions an perhaps the ring based permission levels. The more the cpu can help with building in security from the start the easier it will be in the long run.

You might also want to look into the NS32xxx series from National Semiconductor in the late 80's/90's( not sure exactly when). The NS3200 all had the same instruction set, however you could get the chip with 8bit, 16bit, and 32bit memory/data access. At this stage of CPU's I'd suggest looking into detaching the instruction set from the 'bit' size so the external access to memory/data was independent of the bit size. With a 32 bit data/address bus it may take 2 transfers to handle a 64 bit data item, but that can be done by the hardware without the software having to know about it. All the software sees is a 64 bit (or maybe later on with added instructions a 128bit) address/data path with the actual path width hidden by the hardware. A 64 bit program might run a little slower on a 32 bit bus, but it will run.

Let's not forget CMS, MVT, MFT, etc.

If we're talking pre-PC, let's not forget CTSS.

For that matter, I think I remember that MSWindows was derived from VMS, but with the security and multi-taksing deleted because "personal computers don't need that". But it could have been NT rather than MSWind.

The main architect of NT was Dave Cutler, who was, as far as I know, also the main architect of VMS, so there are similarities in the innards (same "16 time-sharing priorities, 16 real-time priorities" scheduling model and similar I/O subsystem, for example). However, the multi-tasking was definitely not deleted from NT, nor was the security (in the sense of having user IDs and process credentials and ACLs on files, at least in NTFS, and on other objects).

"Classic" MS Windows antedated Cutler, and had no VMS influences I know of.

This reminds of the old Real Programmers, Real Software Engineers, and Real Computer Scientists.

There is a clear genealogy, and that even goes back into the 1960s with Multics.

Yeah - a while ago, I lost a day reading through the stuff on www.multicians.org. I remember this story, though, relevant to this Slashdot article.

Here’s TECO EMACS version 170 from MIT, circa the mid 1980s I think: http://pdp-10.trailing-edge.com/mit_emacs_170_teco_1220/index.html To use it you need a working PDP-10 (or an emulator), with an appropriate OS (ITS, TOPS-10, or Twenex), and a working TECO. Emacs was originally a bunch of Editing MACroS implemented in TECO, the world’s most difficult text editor: http://en.wikipedia.org/wiki/TECO_(text_editor)

I don’t know if you could get TECO EMACS working in other versions of TECO, but TECO is still lovingly ported to modern systems like Mac OS X and Windows. Learning to use it will make your brain hurt.

Multics Emacs was the first port away from TECO, thoroughly described by its author Bernie Greenberg: http://www.multicians.org/mepap.html There’s a link to the source in that paper, dating to the early 1980s.

Other flavours of Emacs were ZWEI (ZWEI was EINE Initiailly; EINE Is Not Emacs) for the MIT CADR Lisp Machine (http://www.heeltoe.com/retro/mit/mit_cadr_lmss.html) and its descendants like ZMACS on the LMI Lambda and on Symbolics Genera systems.

I always use Pronouncable passwords myself. They're easy to remember but still not brute forcible.

As he says on his Web site, he's the "inventor of EMAIL".

He does not, however, say he's the inventor of email or e-mail or electronic mail, so I guess he means he's the inventor of a system named "EMAIL". the copyright he got was for a "COMPUTER PROGRAM FOR Electronic Mail System", which suggests that "EMAIL" was a program that implemented, err, umm, email.

He als says "Every software system needs a User's Manual, so did the world's first E-MAIL system. At that time, Shiva was everything on the project: software engineer, network manager, project manager, architect, quality assurance AND technical writer.", so maybe "the world's first E-MAIL system" was the first system that "handled it all" - ARPANET e-mail involved different mail user agents and mail transfer agents on different operating systems, so there wasn't a single "COMPUTER PROGRAM FOR Electronic Mail System".

Or not. A historical overview of the CTSS system, from its fiftieth anniversary, quotes Tom Van Vleck (also cited in another posting):

Electronic Mail. Noel Morris and I wrote a command, suggested by Glenda Schroeder and Louis Pouzin, called MAIL, which allowed users to send text messages to each other; this was one of the earliest electronic mail facilities.[11] (I am told that the Q-32 system also had a MAIL command in 1965.)

Reference 11 is to Van Vleck's The History of Electronic Mail (which mentions the copyrighting of "EMAIL" in a parenthetical note at the top of the page) and Errol Morris's New York Times Opinionator blog post "Did My Brother Invent E-Mail With Tom Van Vleck?" (my head asplode when I learned that Errol Morris was Noel Morris' brother).

The news article he cites says he "created an electronic mail system", which may well be the case. It doesn't say he created the first electronic mail system, and "created an electronic mail system" suggests that the notion of an "electronic mail system" wasn't a Shiny New Idea (and, in fact, it wasn't).

And, in fact, the article to which the "to defend his standing as email's creator" link takes you quotes him as saying "I did not claim that I created electronic communications," so at least give him credit for that.

As he says on his Web site, he's the "inventor of EMAIL".

He does not, however, say he's the inventor of email or e-mail or electronic mail, so I guess he means he's the inventor of a system named "EMAIL". the copyright he got was for a "COMPUTER PROGRAM FOR Electronic Mail System", which suggests that "EMAIL" was a program that implemented, err, umm, email.

He als says "Every software system needs a User's Manual, so did the world's first E-MAIL system. At that time, Shiva was everything on the project: software engineer, network manager, project manager, architect, quality assurance AND technical writer.", so maybe "the world's first E-MAIL system" was the first system that "handled it all" - ARPANET e-mail involved different mail user agents and mail transfer agents on different operating systems, so there wasn't a single "COMPUTER PROGRAM FOR Electronic Mail System".

Or not. A historical overview of the CTSS system, from its fiftieth anniversary, quotes Tom Van Vleck (also cited in another posting):

Electronic Mail. Noel Morris and I wrote a command, suggested by Glenda Schroeder and Louis Pouzin, called MAIL, which allowed users to send text messages to each other; this was one of the earliest electronic mail facilities.[11] (I am told that the Q-32 system also had a MAIL command in 1965.)

Reference 11 is to Van Vleck's The History of Electronic Mail (which mentions the copyrighting of "EMAIL" in a parenthetical note at the top of the page) and Errol Morris's New York Times Opinionator blog post "Did My Brother Invent E-Mail With Tom Van Vleck?" (my head asplode when I learned that Errol Morris was Noel Morris' brother).

The news article he cites says he "created an electronic mail system", which may well be the case. It doesn't say he created the first electronic mail system, and "created an electronic mail system" suggests that the notion of an "electronic mail system" wasn't a Shiny New Idea (and, in fact, it wasn't).

And, in fact, the article to which the "to defend his standing as email's creator" link takes you quotes him as saying "I did not claim that I created electronic communications," so at least give him credit for that.

Ayyadurai may have been the first person to use the term "email".

Nope; that was probably BBN Mercury in 1965. Every important component to e-mail can be found by that year; that page even specifically debunks this bozo at the top. Like a lot of things, the minute electronic mail became feasible to build, e-mail was built by multiple people. All the requirements were in place the minute a community of people on time-shared computers existed. The number of independent creations of the same thing during a short time period show it was really an obvious next step the minute two people could use the same computer.

Oh yes, he sure did. In 1982. When every computer on the network already had networked mail services. Electronic mail was invented before this clown was even born. Let the burning at the stake proceed forthwith.

Yep. It's amazing how little e-mail has changed since it was invented in the mid-sixties. (Incidentally, that link also reveals to the young computer history student that unsolicited mass mailings date to 1971, and unsolicited commercial mass mailings date to 1978. Feel free to pick which one is spammier in your mind.)

The first example is probably CTSS mail, which dates to late 1964. Not only is mail older than most people here, it's old enough to have gone out of patent coverage 1.5 times.

You can always make them think hard about it: Multics once had the message HODIE NATUS EST RADICI FRATER, which diagnosed and impossible file system with two roots. The recipients had to find someone who'd gone to catholic school to figure it out. As it happens, the hardware was broken and there was a good reason not to continue...

--dave

The story of the Cookie program, in the words of its author.

Yep. The last Multics installation closed in 2000, but they released the source under the MIT license in 2007.

You would be correct. Linux isn't the first "hot patch" system.

Multics (1965) was designed for 24/7/365 operation, and could replace any component by design. Hardware or software.

http://www.multicians.org/

You might want to look at http://www.multicians.org/myths.html sometime.

What do you mean by dead? Unsupported? Unmaintained? Unpopular? Unused? Unportable?

Bell Labs pulled out of the project in 1969. Multics had operational sites shortly after, and there were functioning, maintained Multics systems very much alive until October of 2000. For quite a long time, Multics was the only system to achieve one of the highest security ratings (an entire level beyond what any Hardened Unix system has accomplished).

The Intel 80386 memory management system was designed to have approximately the same capabilities for memory management as the H6180 systems Multics was originally developed for. A port of Multics to the 386 was underway in the 80s but the project was canned due to budget constraints.

Unix and Multics were not really competitors until much later in Unix's lifetime. Multics was designed from the ground up to be a highly flexible, reliable, secure computing resource. Unix was designed to be a small, lightweight text-processing system.

PL/I compilers and tools are still available from IBM. There are plenty of people who worked on Multics who can be hired to port Multics PL/I to IBM PL/I or microcomputer PL/M.

The Unix filesystem and memory management models are based heavily on those of Multics. The VMS security model was based significantly on that of Multics. The Windows NT development team basically hired a bunch of ex-VMS designers and ex-PR1ME designers (PR1ME was a system heavily based on ideas from Multics and coded by many ex-Multics designers, seeing a lot of use in the industry before PR1ME fell behind in hardware capabilities along with many other specialized minicomputer manufacturers with the rise of the consumer workstations). Multics made a *huge* impact on modern computing. Unix would not have gotten very far is Bell Labs had not been involved in the early development of Multics. Many of the features from Multics that were not brought over to Unix was because Unix was not aiming to be a multiprogramming environment (initially) so much as a DOS for PDPs that didn't suck...

Honeywell/Bull made some very dumb moves, and that's why Multics is no longer running. If there was an inexpensive, highly secure, highly flexible, multiuser, multiprogramming operating system for the 386 in the era of PCBSD, DR-DOS, Xenix, and Novell, as there would have been until some executives canned the port to the 386... things might be very different today...

I've encountered bits and pieces of Unix hagiography for the last 15 years, and in all that time, I've internalized that "Multics sucks" (somewhere alongside the virgin birth), yet I can't bring to mind a single reason *why* Multics sucked. Were the Romans really so stupid as they are made out to be?

From Fernando J. Corbató's 1991 Turing lecture concerning one of Muttlix's early teething problems:

The decision to use a compiler to implement the system software was a good one, but what we did not appreciate was that new language PL/I presented us with two big difficulties: First, the language had constructs in it which were intrinsically complicated, and it required a learning period on the part of system programmers to learn to avoid them; second, no one knew how to do a good job of implementing the compiler.

So, perhaps, not the best suited language for systems programming?
From Wikipedia:

The goal of PL/I was to develop a single language usable for both business and scientific purposes.

Doesn't that vision give your average PHB a throbbing chum? If simplicity is hard, let's scale up the mediocre talent and do sameness instead.

PL/I was designed by a committee drawn from IBM programmers and users drawn from across the United States, working over several months.

No sociology experiment from the 1960s was complete without confederates in white shirts. The free-love hippies managed to sneak into the language promiscuous data type conversions.

Dijkstra summed it up in 1975 with his monograph
How do we tell truths that might hurt?

PL/I --"the fatal disease"-- belongs more to the problem set than to the solution set.

God, I love this guy. He's the patron saint of annoying the hell out of people by always being right, and putting a fine point on it. Same monograph includes another famous zinger:

APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past.

From Myths about Multics

We wrote 3000 pages of the Multics System Programmer's Manual first, while waiting for the PL/I compiler.

That should strike a painful nerve in anyone who tried to adopt the C++ STL in 1994.

Ouch. Shipwrecked on the beach of half a programming language, fondling your monads.

Not half surprising that Thompson ended up carving his own canoe with a pen knife to escape.

Smalltalk did this in the '70s, and the idea goes back to APL in the early '60s.

And, perhaps more to the point, Multics, also in the '60s.

The general answer is to manage the change you suffer, so as to keep it from getting ahead of you.

You can do this several ways, but the best requires you be the creator of the interfaces that are to change. If you are, you can make it easy for your customers (and your own team) to change asynchronously, basically by version-numbering your interfaces. Paul Stachour has a good talk on this at multicians.org.

A primitive form of this is freezing your interfaces: once they're in the Application Binary Interface (ABI), don't change then until the hardware changes so much that everyone has to recompile (e.g., when switching to 64-bit). This is heavily used in operating systems, but not in the world of programming languages.

Finally, if you're the consumer of someone else's changes, steal a technique from the porting/migration community and automate your changes when your supplier forces you into them. One tools, aimed at Vim/Emacs users is "port", described at Strength-Reducing the Task of Porting. It only takes about 10 minutes to create a change-database entry and optionally a sed script, so you can make a controlled change of all your sources to match a vendor's newest brainstorm.

--dave

Spam is:...Commercial email.

No, there is no need for something to be commercial to be spam. One of the first recorded spams was an anti-war message sent to all CTSS MAIL users about 1971. The first major USENET spam was in January 1994, telling us "Jesus is Coming Soon". (Well, apparently he wasn't. Whoops!)

The first documented use of the term "spam" that I've seen was in response to a USENET experiment called ARMM (Automated Retroactive Minimal Moderation) that went into sorcerer's apprentice mode and posted and posted and posted...

Spam is UBE - unsolicited bulk e-mail (or other electronic communication). This was spam. Suspension may be too harsh, though: I'd just put her in the stocks for a few hours and hand every recipient a rotten tomato.

Pfff. There's nothing that a large capacitor bank or stored-inertia motor-generator pair can't do. Who needs some tiny little solid-state UPS? If you run over it with a truck, it stops working! And, forget this DIMM memory. A large cabinet of core memory is not only economical and practical (keeps your server room warm, also functions as an EMF detector and cosmic ray detector---four uses in one!) but is inherently non-volatile and stylish to boot. Lost power so long that your stored energy systems got exhausted? No need to fear, thanks to magnetic hysterisis technology, core memory deteriorates quite slowly when kept in good field isolation!

And one person (i.e., me) to mention drum storage from back in the old days (i.e., before I was born), just like every other time it's come up and I've seen it and been bothered to comment, and probably with a link to multicians.org.

Also done 35 years ago by Multics, where it was called "page multilevel". Somewhat different storage technologies in that case, but with similar characteristics.

Some people were still dinking around with IBM 1401 (late 1950s) code as recently as 2000. http://www.multicians.org/thvv/1401s.html, but not for any productive purpose. I wouldn't be at all surprised to find Fortran/Cobol programs originally written for the IBM709 or CDC1604 still in use. Not on the original hardware of course -- too expensive to run Maybe the right question is what is the oldest computer still in use somewhere in the world? Odds are pretty good that some of the code from its early years is still around.

>> You obviously overlook the flamewars he started...
Who did ?
>> Emacs vs Vi
This really originated as a war between "berkeleyites" unix users and "bigger iron" universities using PDP 10 or PDP 20.
The main "issue" of Emacs was that it didn't started on Unix but was one of the first "major programs" ported to it.
So for instance the key binding conflicted, and of course vi was designed to work well even for 300 bauds acoustic modems user, wherease Emacs
needed faster terminals (except for the brillant MULTICS version see http://www.multicians.org/mepap.html)

>> GPL vs BSDL
Yes because he saw the issue behind forking off toward a proprietary version, partly because within the history of emacs there is goesling emacs and zimmerman emacs and because without a mecanism like the GPL the "open source" model is doomed to stay a playground for academics and student untill they go to have "real jobs" transforming what they found in their formative years into "serious money".
This would be livable if the by product would not be a more and more calicified IT industry where "winners take all" concistently applies, and creativity is discouraged.

>> GNU/Linux vs Linux
Well yes it is a pain to go from two to three syllables but who started the war, those who forgot that the OS is only a part of the full solution/environment ? or he who maybe not always so gently tries to get people to remember ?
>> Free vs Open Source
So some people want to dance around their obligation in the free software movement, and sanitise it by calling it "open source" and RMS started the flame war ?

>> etc etc...

>> Not that I'm trying to discredit his contributions to Free/Opensource Software, but a "peace" award might be a bit off the mark :)
Well you usually do not get a peace award because you are particularly peaceful, but because you make the world a less dangerous place.
And RMS certainly gave a tool that enables people in emerging countries to created, and be part of an "intellectual" industry, unfortunatelly few chose to do so, for mostly bad but understandable reasons, nevertheless this is what deserves a "peace award"

Then write an applet that runs on your homepage that in turn starts to do lookups against those names. Make the applet a bit nice so it isn't considered a DoS attack. A few seconds delay between each nslookup/whois call.

This applet can be used to target other domain name front runners too so it will render the current strategy of buying domain names automatically rather hopeless.

Just for the sake of it maybe everyone shall do whois searches of the most popular criminal outfits - preferably those with tastes for the extreme and then send a postcard to the outfits and see what happens...

The late André Bensoussan worked with me on the Multics operating system at Honeywell in Cambridge. We were working on a major change to the file system, which required a subsystem, the VTOC manager, to manage file description information. It had to transport the file information between disk and memory, manage a shared memory buffer pool, and manage space on disk for the information. In other words, it was a small virtual memory manager.

André took on the job of design, implementation, and test of the VTOC manager. He started by sitting at his desk and drawing a lot of diagrams. I was the project coordinator, so I used to drop in on him and ask how things were going. "Still designing," he'd say. He wanted the diagrams to look beautiful and symmetrical as well as capturing all the state information. I was getting nervous about the schedule, so I was glad when he finally began writing code. He wrote in pencil, at his desk, instead of using a terminal. He declined offers of typing help, and just kept writing away in pencil. He rewrote parts, copied things over, erased and rewrote.

Finally André took his neat final pencil copy to a terminal and typed the whole program in. His first compilation attempt failed; he corrected three typos, tried again, and the code compiled. We bound it into the system and tried it out, and it worked the first time.

In fact, the VTOC manager worked perfectly from then on. Only one bug was ever found in it, and that was my fault: André had asked me the calling sequence for an error procedure, and I'd guessed instead of looking it up, so it crashed the first time it hit an error. Beyond that the program was perfect.

How did André do this, with no tool but a pencil?

Multics was, fundamentally, a research OS

Ken Thompson & Dennis Richie worked on MULTICS (MIT and Bell Labs were both involved in the project). After Bell Labs dropped out of the project, Ken & Dennis created Unix partly as an effort to reproduce the good stuff they were missing.
MULTICS and GCOS both ran on variations of the same hardware (The G in GCOS used to be GE as in General Electric -- Honeywell kept the acronym when they bought GE's computer operation).
The GCOS field in /etc/passwd was to support a batch job submission subsystem. This field connected your Unix account and your GCOS account.
The MULTICS is not an acronym but the gag acronym I heard was Many Unbelievably Large Tables In Core Simultaneously (that's what I heard -- http://www.multicians.org/multics-humor.html has it as Many Unnecessary Long Tables In Core Simultaneously).

Btw, it's "Multics" not "MULTICS".

Probably the best source for Multics-related information is this site.

It doesn't work in Lynx! C'mon, REAL geeks don't use firefox (that's like emacs)---they use lynx (like vi)!

Personally, I prefer this firehose.

If what you described works, then the kernel just isn't switching segmentation tables properly or validating pointers. Obviously, the kernel should have a special validation case when an application has actually allocated a page at address 0. Besides, what maps to NULL in one place isn't necessarily what maps to NULL elsewhere (or vice versa), so there's no _guarantee_ of your suggested exploit working, even if the kernel screws up.

The separate kernel and user rings are also designed to prevent this. It's true that the on most platforms, ring implementation isn't very sophisticated, but in Multics, you couldn't propagate data outside of a proper ring bracket without explicit requests that were always validated.