Slashdot Mirror

If you want to give Acme a try (I love it), you can do one of two things:

A: Download Inferno. It's a Virtual Machine-based operating system that runs on top of Linux, Mac OS X, Windows, and Plan 9 (to name a few). Acme is included. Free to download.

Or B: plan9port. It's a port of the Plan 9 libraries to UNIX, including Linux and BSD. Acme is included (screen shot under KDE). Again, free to download.

You should read the Plan 9 wiki entry on acme before trying to use it.

Enjoy!

Shouldn't Glenda (http://plan9.bell-labs.com/plan9dist/glenda.html) be an Angora rabbit (http://www.angorarabbit.com/)?

Well, Rob did something different -- took what they learned from UNIX and wrote something new. And in his eyes, Plan 9 probably has way-fewer warts than POSIX.

I'm surprised this was modded troll. I'm a UNIX user since '92 or thereabouts, and have my FreeBSD 1.0 CD to show for it. Rob is textbook hard core old school, yet he decided to develop something decidedly *different* from UNIX. Therefore, he must have felt that something more radical was warranted than tacking on new substructures to the old warhorse. Cleaner and more interesting solutions were only possible through starting fresh.

Anyway, I was interested in his opinion of if UNIX deserves incremental change and updates, or if it, in his opinion, is ultimately a dead-end -- that our time would be better spent working on something that takes what was good from UNIX yet leaves the bad behind, just as UNIX did to MULTICS.

For example, Plan 9's per-process mount tables are definitely interesting, making more general a concept found in UNIX, but a much bolder change than what one would expect on a UNIX. Similar things can be said of Hurd's abandonment of the 'process running as root has all priviledges' concept. Likewise for languages whose system runtimes perform array bounds checking automatically.

Also, if you will, a link for (instructions) porting to Plan 9.

if you don't want to rewrite your code use this:

APE - The ANSI/POSIX environment...

rewriting your stuff is an eye opener though -- it mostly involves removing code that shouldn't be there in the first place but was forced upon you by unix' legacy crap.

"In the rush to personal workstations, though, some of their weaknesses were overlooked. First, the operating system they run, UNIX, is itself an old timesharing system and has had trouble adapting to ideas born after it. Graphics and networking were added to UNIX well into its lifetime and remain poorly integrated and difficult to administer." - Quote

You obviously have never used Acme, the greatest UI ever created:

"Acme: A User Interface for Programmers" By Rob Pike

And now you can even run it on (l)Unix thanks to rsc's plan9port: http://swtch.com/plan9port/

I was just re-reading the Acme paper this afternoon, and this made me wonder, acme was supposed to eventually support non-textual graphics but this was never implemented, why? and what ideas did you have for such an implementation?

If done right that could allow acme to replace rio completely ;)

P.S.: For the parent, if you want to know more about Rob's view on user interfaces I recommend that you at least read his papers: 8½, the Plan 9 Window System and The Text Editor sam

You obviously have never used Acme, the greatest UI ever created:

"Acme: A User Interface for Programmers" By Rob Pike

And now you can even run it on (l)Unix thanks to rsc's plan9port: http://swtch.com/plan9port/

I was just re-reading the Acme paper this afternoon, and this made me wonder, acme was supposed to eventually support non-textual graphics but this was never implemented, why? and what ideas did you have for such an implementation?

If done right that could allow acme to replace rio completely ;)

P.S.: For the parent, if you want to know more about Rob's view on user interfaces I recommend that you at least read his papers: 8½, the Plan 9 Window System and The Text Editor sam

You obviously have never used Acme, the greatest UI ever created:

"Acme: A User Interface for Programmers" By Rob Pike

And now you can even run it on (l)Unix thanks to rsc's plan9port: http://swtch.com/plan9port/

I was just re-reading the Acme paper this afternoon, and this made me wonder, acme was supposed to eventually support non-textual graphics but this was never implemented, why? and what ideas did you have for such an implementation?

If done right that could allow acme to replace rio completely ;)

P.S.: For the parent, if you want to know more about Rob's view on user interfaces I recommend that you at least read his papers: 8½, the Plan 9 Window System and The Text Editor sam

The Jerq was the original name for the Blit -- a name that management didn't approve of, for some reason.

More info: AT&T 5620 (and Related Terminals) Frequently Asked Questions

And also: Can someone advise me regarding a gui for UNIX

From: Dennis Ritchie <dmr@plan9.bell-labs.com>

Norman Wilson's account of the Jerq/Blit etc. is quite complete and correct, though there was some recycling of names. 'Jerq' actually was used quite early, when Pike got interested in bitmap graphics. The name was a takeoff on the Three Rivers Perq, which he (and I) saw at Lucasfilm Ltd. while attending an early Usenix. Blit was the slightly more PC version (suggested either as part of BitBlt or "Bell Labs Interactive Terminal). The originals used the Motorola 68000, and part of the development messup was AT&T Computer systems' decision to switch to the WE32000 processor with consequent delay for porting and reworking.

The earliest versions were not quite as wonderful in practice as Norman suggests for the later ones. They were built by the Teletype corp. model shop (in quantity of a few hundred) and downloading the OS took several minutes at 1200bps--necessary at startup, since they didn't have a ROM for the whole thing, just enough for doing a download. They were also static electricity antennas! Many is the time that I would shift in my chair, then touch the keyboard, only to have the terminal reset itself. I developed the habit of putting my hand on the heavy steel case before moving around.

On the other hand, the basic idea was architecturally right (and the later commercial versions were not so subject to static, and had ROM for the OS). They were even nicer at 9600bps.

It's good to know that Norman is still using his.

Dennis

Given that Rob Pike works for Google, I wouldn't be surprised if he wrote that question himself...

Why not link to the official plan9 site?

Rob's opinion of OO is well known; one of my favorite quotes by him is: "object-oriented design is the roman numerals of computing."

As for building on Unix and C, his(and Bell Labs') answers are well known:

- Plan 9
- Limbo
- Inferno
- [New]Squeak

I think that he and the Bell Labs folks already answered those questions over 10 years ago:

http://plan9.bell-labs.com/sys/doc/9.html
(See specially the first section: Motivation)

uriel

Shannon's seminal paper created the field of information theory, it's a surprisingly easy read for such an influential paper.

Two questions:

1. Dave Cutler, mastermind of the Windows NT kernel, once described UNIX as a "junk OS designed by a committee of Ph.D.s.".

   Given two important facts:

   • Windows NT is mostly written in C and C++, both Bell Labs innovations, and
   • IE/Mediaplayer integration has turned the Windows NT codebase into a security disaster

   How would you respond to Cutler's assertions, and how would you rate the code quality of the NT kernel (assuming that you might have perused the recent leaked NT4 source)?

2. While UNIX-like operating systems are growing in popularity, actual Bell Labs code is rarely encountered in free operating systems because of licensing issues (with a few notible exceptions).

   This is a frustrating situation for all of us. Do you see any possibility that major portions of UNIX and Plan 9 source being released under licensing that major distributions would find acceptable?

Please also accept my personal thanks for your work in the field of computer science. The influence of the community of researchers at Bell Labs will be felt for many generations to come.

After reading your presentation on the death of systems research, I was rather disappointed at the dismal situation presented. Has anything changed since you presented that talk, or have your thoughts changed about the matter? As someone who is interested in systems research, what do you think is the most promising direction that is emerging today?

In your paper, systems software research is irrelevant, you claim that there is little room for innovation in systems programming, and that all energy is devoted to supporting existing standards. Do you still feel this way now that you're working at Google?

reading the source code is not enough

unless you taped out the CPU, wrote the BIOS, wrote the compiler & wrote the OS

http://cm.bell-labs.com/who/ken/trust.html

For running a typesetting system for patent applications?

No, really!.

What you say is true in the absence of mutipath propagation (without independent fading). It is not true for an independently fading channel. Using MIMO on an independently fading channel (ie. multiplicative noise) does allow capacity to exceed what is possible in a SISO system operating at the Shannon limit.

I refer to to Foschini's seminal paper on the subject.

This web page sums it up:

MIMO systems retain all the properties of SIMO/MISO systems, since in some sense the optimization of the transmitting and receiving antenna elements is carried out in a superset of that of SIMO/MISO. In reality, MIMO systems offers advantages which go far beyond that of conventional smart antennas, as was first hinted in a breakthrough paper by J. Foschnini at Lucent Tech. in 1996 [Foschini96]. In this paper, Foschini shows that if the NxM channel matrix describing the wireless link in a M-transmit N-receive system has ideal independently fading elements, then the capacity of such a system grows linearly with the smallest number of antennas min(N,M) and no longer with the log function. An incredible improvement over the more traditional SIMO/MISO case. A similar result was also reported in [Telatar95]. In parallel, Foschini also developed a practical transmitter/receiver algorithm to beused in the MIMO context: the now famous "BLAST" algorithm [Foschini96]. Later another breakthrough scheme was proposed by ATT-Labs based on the idea of space-time coding [Tarokh98] to extract diversity gains in MISOthen MIMO.

I'm interested in any objections you still have, just in case there is a shortcoming in my knowledge.

http://cm.bell-labs.com/cm/cs/who/dmr/otherports/i bm.html

That mentions "TSS", as in "TSS/370", as in "Time Sharing System/370", as in "System/370", not "CTSS", which ran on a modified IBM 7094.

http://cm.bell-labs.com/cm/cs/who/dmr/otherports/i bm.html

As for the heritage of various OS's, the child tends to learn from the mistakes of the parent, and end up a significantly different creature. As for UNIX, although early incarnations were great distant from MULTICS, later versions actually came much closer. For example, System V/MLS, borrowed many more concepts from Multics then prior versions.

What's broken with Unix?
Wrong question. See Pike

How would you fix it?
Throw it out and start over. I know that's a heretical statement, but it needs to be done.

Q. What's broken with Unix? How would you fix it?

That is an easy one, one word and a single digit number: Plan 9

Having in mind that Rob Pike and a few other Plan 9 developers now work at Google, I wonder if they had anything to do with this question...

There has been some speculation among Plan 9 fans about what the hell is Rob doing at Google, aside from some small contributions to the Plan 9 on Unix project no one knows what he is working on... I hope that some day we will all get to find out ;)

Q. What's broken with Unix? How would you fix it?

That is an easy one, one word and a single digit number: Plan 9

Having in mind that Rob Pike and a few other Plan 9 developers now work at Google, I wonder if they had anything to do with this question...

There has been some speculation among Plan 9 fans about what the hell is Rob doing at Google, aside from some small contributions to the Plan 9 on Unix project no one knows what he is working on... I hope that some day we will all get to find out ;)

> > Lets have the BEST of everything in one core repository.

> like This[www.freebsd.org] one?

Sorry, I'm sure you made a small mistake...

The one you were thinking of is This one.

Or maybe This one.

All of the GNU tools in *BSD are kept in the codebase of the BSD in question. They're customized versions of the official GNU tools (even gcc). On top of that, not all of the tools that exist in GNU/Linux exist in BSD as the GPL'ed version. Awk in FreeBSD 5.x is the One True Awk, nearly all the GNU tools in OpenBSD have been replaced with BSD licensed tools. In FreeBSD ls, vi, cat, grep, more, less, etc are mostly BSD equivalents of the GNU equivalents of the original UNIX toolset. In some cases, they ARE the original UNIX toolset, where the tools have been open sourced. This is the case of Awk in FreeBSD 5.x - it is awk written by Aho, Weinberger, and Kernighan, available here.

That said, there are people over at debian who have slapped the GNU tool set on both NetBSD and FreeBSD kernels, and called it GNU/FreeBSD and GNU/NetBSD. This precedence seems to push myself towards the conclusion that changing the toolset does, indeed, warrant a name change. For the most part, GNU/FreeBSD and FreeBSD will behave the same, until you type ps -aux on GNU/FreeBSD and get a warning about "bad ps syntax", or fire top and notice slight differences in how it behaves vesus top in FreeBSD.

Personally, If the GNU toolset was thrown on a SunOS kernel, I wouldn't get my panties in a bunch over people calling that system GNU/SunOS. But, perhaps my priorities differ from yours.

Reading your post is like one of those "How Many Mistakes Are In This Picture" things you see in Highlights.

The salt doesn't have anything to with protecting against dictionary attacks,

The salt is exactly to prevent against dictionary attacks. A dictionary attack (using the term old-school) is where I prepare, in advance, a dictionary of passwords and their hash values, indexed by the latter. Then, when you're making your attack, you look up the hashed password and voila! you know the password. In a world without salts, I expect that many security folks would be able to recognize many common passwords' hash values on sight.

it is used to make the algorithm computationaly harder to break.

The salt does nothing (or rather an insignificant amount) to make the computation harder. It's specifically used to prevent a dictionary attack.

The salt is simply the first two characters in your hash,

The salt is a randomly-generated sequence. It's stored as the first two characters of the encrypted password in traditional crypt() passwords, and is followed by the hash. But it's not the first two characters of the hash.

all of the subsequent characters are based from the salt.

They're based off of both the salt and the password. Your post makes it sound like the password is hashed, the first two characters of the hash are the salt, and the rest of the password entry are generated from that. This is not at all what happens.

The salt is generated randomly (from the time of day, number of processes running, etc), to get 12 bits of randomness (note that the salt is isomorphic with the space [A-Za-z0-9/.]{2}). The password is hashed using a DES, with the password as the key and a string of 0s as the plaintext. Partway through the DES operation (specifically, after the E-box), some of the bits are swapped based on the salt.

After DES outputs the hash value (its ciphertext), it is appended to the salt. This concatenated value is stored in the passwd field of your passwd file. So the salt is the first two characters of that output, but it's not the first two characters of the hash. It's used to perturb the hash in one of 2^12 ways.

Note that the specifics I gave (length of salt, use of DES) only applies to traditional Unix passwords. Most modern Unixes use a different hash scheme by default, such as MD5. The role of the salt still applies: it's used to perturb the hash function to prevent dictionary attacks. There are differences in how it's stored and how it perturbs the hash.

For further study, I recommend reading Password Security: A Case History by Robert Morris and Ken Thompson.

% mount -A /net/legolink /n/remote

% cd /n/remote
% ls
motor sensor

% ls motor
motor/0 motor/1 motor/2 motor/012

% ls sensor
sensor/0 sensor/1 sensor/2

# Start motor...
% cd motor
% echo -n f7 > 0

# Reverse the motor...
% echo -n r7 > 0

# Stop the motor...
% echo -n F0 > 0

# Run the motor for 5 seconds...
% echo -n r7 > 0; sleep 5; echo -n F0 > 0

# Ok, lets play with a sensor...
% cd /n/remote/sensor
% echo b0 > 0
% cat 0
0

# Click the button a few times and then try reading the sensor file again
% cat 0
4

# Let's try a blocking read on the sensor
% echo b5 > 0
% cat 0
# [click the button 5 times]
5

# Ok, we're done playing - unmount the brick namespace
% ls /n/remote
/n/remote/motor /n/remote/sensor
% unmount /n/remote
% ls /n/remote
%

% mount -A /net/legolink /n/remote

% cd /n/remote
% ls
motor sensor

% ls motor
motor/0 motor/1 motor/2 motor/012

% ls sensor
sensor/0 sensor/1 sensor/2

# Start motor...
% cd motor
% echo -n f7 > 0

# Reverse the motor...
% echo -n r7 > 0

# Stop the motor...
% echo -n F0 > 0

# Run the motor for 5 seconds...
% echo -n r7 > 0; sleep 5; echo -n F0 > 0

# Ok, lets play with a sensor...
% cd /n/remote/sensor
% echo b0 > 0
% cat 0
0

# Click the button a few times and then try reading the sensor file again
% cat 0
4

# Let's try a blocking read on the sensor
% echo b5 > 0
% cat 0
# [click the button 5 times]
5

# Ok, we're done playing - unmount the brick namespace
% ls /n/remote
/n/remote/motor /n/remote/sensor
% unmount /n/remote
% ls /n/remote
%

As for not using C, I've read that Theo de Raadt likes the compiler and language that is used in Plan 9. Can't use it due to license problems, though.

What do you find interesting in a VMS and Java clones is beyond me, two of the worst technologies ever created in the history of software. Not to mention the most directly at odds with the Unix philosophy.

If you are going to "reshape this industry", you could at least try to do so into a less hideous new shape. (l)Unix has been dead for more than fifteen years[1], but better things have been around for almost as long.

If you like C but are tired of doing memory allocation, why don't you use the language that the creators of C spent twenty years designing[2] to overcome C limitations: Limbo

Rob Pike admitted that the main problems with C (as a high level language) are the lack of proper strings and the lack of garbage collection, with limbo you get that and a bunch of other really wonderful goodies, like the best parallel programming framework using CSP and the most beautiful and simple distributed environment thanks to 9p/Styx.

Not only that, but now Inferno/Limbo and Plan 9 are open source.

Note: Now you can even run most of Plan 9 user space under Linux: Plan 9 on Unix

[1] "Not only is UNIX dead, it's starting to smell really bad." -- Rob Pike circa 1991
[2] Directly or indirectly most languages developed at Bell Labs for the last 30 years have been predecessors of Limbo

Best wishes and I hope that some day you will correct your misguided ways

uriel

What do you find interesting in a VMS and Java clones is beyond me, two of the worst technologies ever created in the history of software. Not to mention the most directly at odds with the Unix philosophy.

If you are going to "reshape this industry", you could at least try to do so into a less hideous new shape. (l)Unix has been dead for more than fifteen years[1], but better things have been around for almost as long.

If you like C but are tired of doing memory allocation, why don't you use the language that the creators of C spent twenty years designing[2] to overcome C limitations: Limbo

Rob Pike admitted that the main problems with C (as a high level language) are the lack of proper strings and the lack of garbage collection, with limbo you get that and a bunch of other really wonderful goodies, like the best parallel programming framework using CSP and the most beautiful and simple distributed environment thanks to 9p/Styx.

Not only that, but now Inferno/Limbo and Plan 9 are open source.

Note: Now you can even run most of Plan 9 user space under Linux: Plan 9 on Unix

[1] "Not only is UNIX dead, it's starting to smell really bad." -- Rob Pike circa 1991
[2] Directly or indirectly most languages developed at Bell Labs for the last 30 years have been predecessors of Limbo

Best wishes and I hope that some day you will correct your misguided ways

uriel

Since I have ended up being a SQL Monkey (again) at work, I assure you that I have no desire to use SQL to access my file system. I don't even want a middle layer that translates to SQL. Heck, I am not even sure I want a relational database for a file system.

I would rather they start, by looking at the speed of the file system and take some hints from the file system for Sprite and maybe some of the capabilities of Plan 9's filesystem / model.

Once, that is handled, look at all the trouble people have mapping our current batch of Object-Oriented Languages to SQL. Know, that you will write a natural language query engine for the end-users, so developers need an API / Object Hierarchy that works. Pick something that will be easy to program, allow decent, extendable meta-data, and fits nicely with objects.

The plan 9 way of doing the windowing system is very interesting. The way /dev/bitblt is handled is probably the nicest way to implement a windowing system...

An intro to 8 1/2

I'm sure if one were to send the patent office the sudo info, MS would argue that they have an "already running admin. process" that then actively accepts requests from other user processes.

And, in fact, that _is_ what they do. Windows 2000 and above have a "RunAs service" which is a process that runs with "Local Computer" security priveleges, which accepts requests from user processes that include a username & password, and execute the command passed if the password is correct.

This isn't to say that this is a unique and original idea. This document describes a similar facility in Plan 9, where a process called 'factotum' grants access to a user's data when authenticated. Having never used plan 9 myself, I'm not sure how similar this is in practice, but the description makes it sound like a substantially more useful implementation of the same original idea.

http://www.cs.bell-labs.com/sys/doc/auth.html

New processes run as the same user as the process which created them. When a process must take on the identity of a new user, such as to provide a login shell on a shared CPU server, it does so by proving to the host owner's factotum that it is authorized to do so. This is done by running an authentication protocol with factotum to prove that the process has access to secret information which only the new user should possess.

Whether that classes as an administrative process is up for debate depending on usage, I think.

Bell Labs invented them in 1999.

The central paradigm behind BLAST is the exploitation, rather than the mitigation, of multipath effects in order to achieve very high spectral efficiencies (bits/sec/Hz), significantly higher than are possible when multipath is viewed as an adversary rather than an ally.

The central paradigm behind BLAST is the exploitation, rather than the mitigation, of multipath effects in order to achieve very high spectral efficiencies (bits/sec/Hz), significantly higher than are possible when multipath is viewed as an adversary rather than an ally.

What an interesting gauge you propose. I better Migrate my family computers over to http://www.cs.bell-labs.com/plan9dist/ ASAP, since it's clearly more intuitive than GNU/Linux, OS X or WinXP!

Just because dos.library was written in BCPL, and BCPL is an ancestor of C, that doesn't make AmigaOS an ancestor of Unix. If you wanted to call AmigaOS an ancestor of TripOS, you would have less of an argument from me.

how about we go back to basics and read the proper books on computer science? no need for your shmancy-fancy-'voice debugged'-automagically-'quality assured' offerings, thanks.

i'll stick with The Practice of Programming. at the very least i trust the people who wrote it to have a better judgement.

Plan 9 is/was the successor to Unix from the people who brought you Unix to begin with.

It's compiler suites, which approach multiple architectures a little differently, by default don't have hardly and ANSI C or POSIX support. If you need that stuff you have to use the APE frameworks. See this for more information.

The fact that it's not quite ANSI C and not quite POSIX by default shouldn't discourage you from playing with the OS though or even trying to use it. Apparently the "thin client" trend is coming back and Plan 9 systems support that metaphor quite nicely where everyone has a graphical display and a private hierarchical namespace [each process can have a different namespace in fact]. The OS is meant to be distributed across many nodes, with CPU nodes and File Serving nodes being part of a grid, but you can run it standalone fairly easily as well.

I've found that even though it doesn't have a great X implementation I can still VNC to other machines that do when I need X and that I can use ssh with their terminal emulator when I need to work with systems Plan 9 can't "mount" or "bind" into my namespace.

As you can probably tell. I was impressed.

If you don't want to mess with installing over you existing OS you can try Inferno which installs on Windows, Linux, FreeBSD and even MacOS X [but if you run Panther you will probably need this patched emulator and installer to make it work]. Once done you can build a multi-CPU-architecture grid all your own and learn the "Limbo" programming language and start harnessing those extra CPU cyucles. Inferno also supports thos hierarchical namespaces of Plan 9.

Plan 9 is/was the successor to Unix from the people who brought you Unix to begin with.

It's compiler suites, which approach multiple architectures a little differently, by default don't have hardly and ANSI C or POSIX support. If you need that stuff you have to use the APE frameworks. See this for more information.

The fact that it's not quite ANSI C and not quite POSIX by default shouldn't discourage you from playing with the OS though or even trying to use it. Apparently the "thin client" trend is coming back and Plan 9 systems support that metaphor quite nicely where everyone has a graphical display and a private hierarchical namespace [each process can have a different namespace in fact]. The OS is meant to be distributed across many nodes, with CPU nodes and File Serving nodes being part of a grid, but you can run it standalone fairly easily as well.

I've found that even though it doesn't have a great X implementation I can still VNC to other machines that do when I need X and that I can use ssh with their terminal emulator when I need to work with systems Plan 9 can't "mount" or "bind" into my namespace.

As you can probably tell. I was impressed.

If you don't want to mess with installing over you existing OS you can try Inferno which installs on Windows, Linux, FreeBSD and even MacOS X [but if you run Panther you will probably need this patched emulator and installer to make it work]. Once done you can build a multi-CPU-architecture grid all your own and learn the "Limbo" programming language and start harnessing those extra CPU cyucles. Inferno also supports thos hierarchical namespaces of Plan 9.

we all want to know how google does it, don't we?

here's what he thinks:

Google knows that 80% of mail messages are text, and we all know that text is highly compressible. That said, they probably only have around 2-300MB of storage allocated for each 1GB account (obviously this will fluctuate up to 1GB depending on the user's mail content). My take on this, is that they have a huge series of RAID arrays at their server farm. Every time an email comes in, it is compressed and stored in that users account on the RAID.

this should be closer to the truth: Venti: a new approach to archival storage

Remarkably, Lucent gives away for free a post-modern operating system which is the successor to UNIX and which was designed by many of the same geniuses who developed UNIX. The new system is a free download from the Lucent server at http://cm.bell-labs.com/plan9dist/.

You can also check out Inferno. It's a cousin of Plan 9. It keeps most of the ideas of Plan 9 while adding many that have since been ported back to Plan 9. It's a virtual machine that can run on top of OSes or natively on hardware. It has it's own language, Limbo, that runs in the virtual machine and is truly cross-platform.

Both can be downloaded freely.

It should be noted by detractors of C, that Mr. Ritchie himself does not think that his brainchild is perfect. This discussion contains a "Critique" section where he analyzes the strengths and failures of the language. At the end, he summarizes the language thusly: "C is quirky, flawed, and an enormous success."

...to which I certainly agree. It is fraught with numerous failings, yet C gets the job done, and carpets the computer world.

It should be noted by detractors of C, that Mr. Ritchie himself does not think that his brainchild is perfect. This discussion contains a "Critique" section where he analyzes the strengths and failures of the language. At the end, he summarizes the language thusly: "C is quirky, flawed, and an enormous success."

...to which I certainly agree. It is fraught with numerous failings, yet C gets the job done, and carpets the computer world.