Re: What could have been done differently?
In message <20030129014651.GB80965@darkuncle.net>, Scott Francis writes:
There's a difference between having the occasional bug in one's software (Apache, OpenSSH) and having a track record of remotely exploitable vulnerabilities in virtually EVERY revision of EVERY product one ships, on the client-side, the server side and in the OS itself. Microsoft does not care about security, regardless of what their latest marketing ploy may be. If they did, they would not be releasing the same exact bugs in their software year after year after year.
They do have a lousy track record. I'm convinced, though, that they're sincere about wanting to improve, and they're really trying very hard. In fact, I hope that some other vendors follow their lead. My big worry isn't the micro-issues like buffer overflows -- it's the meta-issue of an overall too-complex architecture. I don't think they have a handle on that yet. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)
On Tue, Jan 28, 2003 at 09:00:48PM -0500, smb@research.att.com said:
In message <20030129014651.GB80965@darkuncle.net>, Scott Francis writes:
There's a difference between having the occasional bug in one's software (Apache, OpenSSH) and having a track record of remotely exploitable vulnerabilities in virtually EVERY revision of EVERY product one ships, on the client-side, the server side and in the OS itself. Microsoft does not care about security, regardless of what their latest marketing ploy may be. If they did, they would not be releasing the same exact bugs in their software year after year after year.
They do have a lousy track record. I'm convinced, though, that they're sincere about wanting to improve, and they're really trying very hard. In fact, I hope that some other vendors follow their lead. My big worry isn't the micro-issues like buffer overflows -- it's the meta-issue of an overall too-complex architecture. I don't think they have a handle on that yet.
Quite true - complexity is inversely proportional to security (thanks, Mr. Schneier). Unfortunately, it seems like the Net as a whole, including the systems, software and protocols running on it, only gets more complex as time goes by. How will we reconcile this growing complexity and our increasing dependency on the global network with the ever-growing need for security and reliability? They seem to be accelerating at the same rate. -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui
On Tue, 28 Jan 2003, Steven M. Bellovin wrote: :They do have a lousy track record. I'm convinced, though, that :they're sincere about wanting to improve, and they're really trying :very hard. In fact, I hope that some other vendors follow their :lead. My big worry isn't the micro-issues like buffer overflows :-- it's the meta-issue of an overall too-complex architecture. I :don't think they have a handle on that yet. Excellent point. I have been saying this since the dawn of Windows 3.x. Obviously, software engineering for such a large project as an(y) OS needs to be distributed. MS has long been remiss in facilitating (mandating?) coordination between project teams pre-market. You're absolutely correct that complexity is now the issue, and it could have been mitigated early on. (Who knows what? Is "who" still employed?" If not, where are "who's" notes? Who knows if "who" shared his notes with "what"?, Who's on third?...) Now, it's going to cost loads of $$ to get everyone on the same page (or chapter), if that's even in the cards. For MS, it's a game of picking the right fiscal/social/political tradeoff. It's extremely complex now, as the project has taken on a life of its own. Someone let the suits take control early on, and we all know the rest of the story. Any further discussion will likely be nothing more than educated conjecture (as was the above). cheers, brian
On Tue, 28 Jan 2003, Steven M. Bellovin wrote:
They do have a lousy track record. I'm convinced, though, that they're sincere about wanting to improve, and they're really trying very hard. In fact, I hope that some other vendors follow their lead.
Of course we need to be honest with ourselves and recognize this has been going on for a long time before Microsoft was even a glimmer in Bill Gates eye. Multics security. Bell Labs answer: Unix. Who needs all that "extra" security junk in Multics. We don't need to protect /etc/passwd because we use DES crypt and users always choose strong passwords. We'll make the passwd file world readable so we can translate uid's to usernames. Multi-level security? Naw, its simplier just to make everything Superuser. FORTRAN/COBOL array bounds checking. Bell Labs answer: C. Who wants the computer to check array lengths or pointers. Programmers know what they are doing, and don't need to be "constrained" by the programming language. Everyone knows programmers are better at arithmatic than computers. A programmer would never make an off-by-one error. The standard C run-time library. gets(char *buffer), strcpy(char *dest, char *src), what were they thinking?
My big worry isn't the micro-issues like buffer overflows -- it's the meta-issue of an overall too-complex architecture. I don't think they have a handle on that yet.
The strange thing about complexity is its much harder to design a "simple" system than a Rube Goldberg contraption.
On Wed, Jan 29, 2003 at 03:32:41AM -0500, Sean Donelan wrote:
FORTRAN/COBOL array bounds checking. Bell Labs answer: C. Who wants the computer to check array lengths or pointers. Programmers know what they are doing, and don't need to be "constrained" by the programming language. Everyone knows programmers are better at arithmatic than computers. A programmer would never make an off-by-one error. The standard C run-time library. gets(char *buffer), strcpy(char *dest, char *src), what were they thinking?
Possibly that bounds checking is an incredible cpu suck, there are a great many powerful things you can do in C based on the fact that there is no bounds checking (pointers ARE your friend god damnit :P), and in a world before buffer overflow exploits it probably didn't matter if Joe Idiot's program crashed because he goofed? (hindsight is 20/20) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
A world before buffer overflow exploits ? The first (Fortran) programming course I ever took at MIT on the first day of lab they said 1.) If you set an array index to a sufficiently large negative number you would overwrite the operating system and crash the system (requiring a reboot from punched paper tape). and 2.) If you did that, they would be so pissed off at you, you would summarily fail the course. This was back when the Fortran complier was included in each run as part of the card deck. I also remember overflow type hacks on the MIT Multics system, which was constantly being hacked. So, I agree with Sean, what were they thinking ? On Wednesday, January 29, 2003, at 08:18 AM, Richard A Steenbergen wrote:
On Wed, Jan 29, 2003 at 03:32:41AM -0500, Sean Donelan wrote:
FORTRAN/COBOL array bounds checking. Bell Labs answer: C. Who wants the computer to check array lengths or pointers. Programmers know what they are doing, and don't need to be "constrained" by the programming language. Everyone knows programmers are better at arithmatic than computers. A programmer would never make an off-by-one error. The standard C run-time library. gets(char *buffer), strcpy(char *dest, char *src), what were they thinking?
Possibly that bounds checking is an incredible cpu suck, there are a great many powerful things you can do in C based on the fact that there is no bounds checking (pointers ARE your friend god damnit :P), and in a world before buffer overflow exploits it probably didn't matter if Joe Idiot's program crashed because he goofed? (hindsight is 20/20)
-- Richard A Steenbergen <ras@e-gerbil.net> http://www.e- gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Regards Marshall Eubanks
On Wed, Jan 29, 2003 at 08:50:56AM -0500, Marshall Eubanks wrote:
A world before buffer overflow exploits ?
The first (Fortran) programming course I ever took at MIT on the first day of lab they said
1.) If you set an array index to a sufficiently large negative number you would overwrite the operating system and crash the system (requiring a reboot from punched paper tape).
I said exploits, not ways to get outside your proper address space and crash the OS. Any sufficiently powerful language presents an opportunity to do bad things to an ill prepared OS, but the answer isn't to make the language less powerful. Perhaps if we banned C and assembly, and made everyone use perl, we'd be safe. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Richard A Steenbergen <ras@e-gerbil.net> writes:
I said exploits, not ways to get outside your proper address space and crash the OS. Any sufficiently powerful language presents an opportunity to do bad things to an ill prepared OS, but the answer isn't to make the language less powerful.
The Burroughs B6700 had trusted compilers.
Perhaps if we banned C and assembly, and made everyone use perl, we'd be safe. :)
The Perl parser itself (written in C ;) seems to have some issues (in __DIE__ handlers). 8-( -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
On Wed, 29 Jan 2003, Richard A Steenbergen wrote:
On Wed, Jan 29, 2003 at 03:32:41AM -0500, Sean Donelan wrote:
FORTRAN/COBOL array bounds checking. Bell Labs answer: C. Who wants the computer to check array lengths or pointers. Programmers know what they are doing, and don't need to be "constrained" by the programming language. Everyone knows programmers are better at arithmatic than computers. A programmer would never make an off-by-one error. The standard C run-time library. gets(char *buffer), strcpy(char *dest, char *src), what were they thinking?
Possibly that bounds checking is an incredible cpu suck, there are a great many powerful things you can do in C based on the fact that there is no bounds checking (pointers ARE your friend god damnit :P), and in a world before buffer overflow exploits it probably didn't matter if Joe Idiot's program crashed because he goofed? (hindsight is 20/20)
I think the larger concern at that time was memory capacity. Remember that only the very largest machines had over 128K.
At 08:27 AM 1/29/2003 -0600, Alif The Terrible wrote:
FORTRAN/COBOL array bounds checking. Bell Labs answer: C. Who wants the computer to check array lengths or pointers. Programmers know what they are doing, and don't need to be "constrained" by the programming language. Everyone knows programmers are better at arithmatic than computers. A programmer would never make an off-by-one error. The standard C run-time library. gets(char *buffer), strcpy(char *dest, char *src), what were they thinking?
Possibly that bounds checking is an incredible cpu suck
It doesn't have to be, if your compiler is worth its salt. Take a look at the GNU Ada compiler implementation of bound checking -- incredibly efficient. There are optimizations and inductive reasoning you can perform at compile time. Strongly typed programming languages make it easier to perform those optimizations, which is a major problem for C (everything's a pointer, right? :-) However, the current language fad is Java, which is somewhat more strongly typed.
, there are a great
many powerful things you can do in C based on the fact that there is no bounds checking (pointers ARE your friend god damnit :P), and in a world before buffer overflow exploits it probably didn't matter if Joe Idiot's program crashed because he goofed? (hindsight is 20/20)
Not sure if this was ever true for networked applications. The original Morris ARPANet worm exploited a buffer overrun vulnerability in the BSD Unix finger daemon. There's no excuse for failing to change behavior, or not re-visiting bounds checking in compilers & interpreters / virtual machines (e.g. JVM). Finally, and rather off-topic, I have yet to come across a C programming technique that "can't be done" efficiently in, say, Ada -- a language that usually gives C programmers fits of apoplexy. You just have to know how to express the solution in that language, rather than forcing a literal translation of the way it's done in C. Cheers, Mathew
ML> Date: Wed, 29 Jan 2003 11:07:59 -0800 ML> From: Mathew Lodge ML> It doesn't have to be, if your compiler is worth its salt. ML> Take a look at the GNU Ada compiler implementation of bound ML> checking -- incredibly efficient. s/compiler/programmer/ How about: struct buf_t { char *first ; char *cur ; char *last ; size_t size ; size_t remaining ; } ; /* implement various buf-management macros */ Implement some or all, as needed. Replace the char* elements with a union of various ptr types if desired. Keep the type definition available; there's no need for an opaque struct. Now write programs to toss around buf_t* instead of char*. It's not that difficult. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
RAS> Date: Wed, 29 Jan 2003 08:18:45 -0500 RAS> From: Richard A Steenbergen RAS> Possibly that bounds checking is an incredible cpu suck, If you check before each byte. Checking for sufficient space first ("is there room for a 245-byte string?") is much faster. Besides, looking at all the bloated code using indirect function calls[*] and crappy code using poor algorithms... is speed really a concern? [*] Try profiling indirect function calls on x86, especially newer cores. Such instructions carry a stiff penalty... but there's no shortage of virtual functions in certain software. (Think: OWL and MFC libraries.) Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
On Wed, Jan 29, 2003 at 05:26:06PM +0000, E.B. Dreger wrote:
If you check before each byte. Checking for sufficient space first ("is there room for a 245-byte string?") is much faster. Besides, looking at all the bloated code using indirect function calls[*] and crappy code using poor algorithms... is speed really a concern?
[*] Try profiling indirect function calls on x86, especially newer cores. Such instructions carry a stiff penalty... but there's no shortage of virtual functions in certain software. (Think: OWL and MFC libraries.)
Note I'm making a distinction between fixing the string libraries to handle overflow situations better, and changing the entire OS to do array bounds checking. One is good, the other is not. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RAS> Date: Wed, 29 Jan 2003 12:36:22 -0500 RAS> From: Richard A Steenbergen RAS> Note I'm making a distinction between fixing the string RAS> libraries to handle overflow situations better, and changing RAS> the entire OS to do array bounds checking. One is good, the RAS> other is not. Okay. I'll buy that. On a somewhat similar note, it's too bad x86 lacks native support for diasbling PROT_EXEC. That wouldn't solve everything, but it would help. (I recall a paper on some funky asm-foo to implement it, but only skimmed it...) The real definition of layered security: We needn't worry about that here, because another layer will take care of it. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
Richard A Steenbergen <ras@e-gerbil.net> writes:
(pointers ARE your friend god damnit :P)
Most C programmers have no clue about the C pointer semantics, I'm afraid, so this powerful feature is often abused. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
On Wednesday, January 29, 2003, at 02:32 AM, Sean Donelan wrote:
On Tue, 28 Jan 2003, Steven M. Bellovin wrote:
They do have a lousy track record. I'm convinced, though, that they're sincere about wanting to improve, and they're really trying very hard. In fact, I hope that some other vendors follow their lead.
Lest we forget, Microsoft did not originally design Windows for the Internet, nor for a lot of what it does today.
Of course we need to be honest with ourselves and recognize this has been going on for a long time before Microsoft was even a glimmer in Bill Gates eye.
Multics security. Bell Labs answer: Unix. Who needs all that "extra" security junk in Multics. We don't need to protect /etc/passwd because we use DES crypt and users always choose strong passwords. We'll make the passwd file world readable so we can translate uid's to usernames. Multi-level security? Naw, its simplier just to make everything Superuser.
FORTRAN/COBOL array bounds checking. Bell Labs answer: C. Who wants the computer to check array lengths or pointers. Programmers know what they are doing, and don't need to be "constrained" by the programming language. Everyone knows programmers are better at arithmatic than computers. A programmer would never make an off-by-one error. The standard C run-time library. gets(char *buffer), strcpy(char *dest, char *src), what were they thinking?
Unix and C where also not designed for the Internet. More ramble ... but a point will emerge ...
My big worry isn't the micro-issues like buffer overflows -- it's the meta-issue of an overall too-complex architecture. I don't think they have a handle on that yet.
The Internet magnifies relatively harmless conveniences into major problems. Network access and "crack" made the world readable /etc/password into a major security hole. "C" is a vast improvement over assembly and evolved into the language of choice for developers over other languages. So we have a few buffer overflows now and then. The formative Internet did a lot to spread C source code. Unix was the primary platform for the Internet before ISPs spread the network to small businesses and home computers. Some of us remember down loading C code from ftp sites in the era before the web page when you could count off the major source code archives on your fingers.
The strange thing about complexity is its much harder to design a "simple" system than a Rube Goldberg contraption.
The complexity of Windows ... indeed all our modern OSes has evolved as they adapt themselves to network environments, complex graphics, multi media applications, complex user interfaces. Microsoft has tended to absorb applications into the core OS and, perhaps more than any other, softened the line between kernel and application to a point where security suffers. Unix systems have the same problem when root privileges are given to given to code ... often because it is less complex to give a process privilege than to craft a secure sandbox. I was just starting to use the Internet when the Morris worm chewed its way through the net. The Morris worm was the first taste of what a harmless back door and lapses in security could do on the Internet. It has been almost 15 years since that incident and look at how far we have come. Common code and lack of review contributed to that one. Internet worms and viruses have a far greater impact when we all use the same code, the same operating system, the same stack. If you plant one genetic strain of corn you risk famine come the blight. Having BSD*, Linux, OS X, and Microsoft in the mix helps prevent mono culture blights. Having Juniper, Cisco, and others in the core is good for our networks. Competition, variety and some level of complexity do act as safeguards against the the catastrophic failures exhibited by "mono culture" systems. IMHO competition and diversity are necessary for healthy systems, corporation, economies and societies. Any complex set of structures that becomes dominated by a single technology, OS, ideology or genotype becomes the ideal growth media for disease. This is why, IMHO, mono-anythings are bad, no matter how benign or well designed. -- Joseph T. Klein The benefits of Democracy, Republic, and IETF is that we do not speak with a single voice.
Though it was written nearly two years ago, John Quarterman's "Monoculture Considered Harmful" remains the very best exposition of this issue. //www.firstmonday.org/issues/issue7_2/quarterman/ Peter
In a message written on Wed, Jan 29, 2003 at 03:32:41AM -0500, Sean Donelan wrote:
Multics security. Bell Labs answer: Unix. Who needs all that "extra" security junk in Multics. We don't need to protect /etc/passwd because we use DES crypt and users always choose strong passwords. We'll make the passwd file world readable so we can translate uid's to usernames. Multi-level security? Naw, its simplier just to make everything Superuser.
A choice made what, 20 years ago? Almost every major form of unix moved to shadow password files and/or stronger password protection years ago.
FORTRAN/COBOL array bounds checking. Bell Labs answer: C. Who wants the computer to check array lengths or pointers. Programmers know what they are doing, and don't need to be "constrained" by the programming language. Everyone knows programmers are better at arithmatic than computers. A programmer would never make an off-by-one error. The standard C run-time library. gets(char *buffer), strcpy(char *dest, char *src), what were they thinking?
Again, a choice made perhaps 20 years ago? New libraries and languages make solving this problem much easier. New tools are available to catch it when it does happen, even in traditional C. We can't expect people to never make mistakes. Rather, the bar must be set that once a mistake is made and understood we strive never to make it again. The choices you site were made at a very different time, and for very different reasons. I highly doubt if Bell Labs had to make choices today that they would choose the same outcome. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On 29.01 03:32, Sean Donelan wrote:
... Multics security. Bell Labs answer: Unix. Who needs all that "extra" security junk in Multics. .........
[reader warning: diatribe following] Gee, there once were a handflul of people; their principle goal was to make an OS for their own use. They did it in such a way that it could be developed by its users while they used it. Creeping featurism was held down successfully, at least initially ;-(. It ran on platforms orders of magnitude cheaper than what Multics ran on at the time. It taught a lot of people about programming style. I hope I learned some things from it. And they wrote up the shortcomings of the security architecture concisely at the time this began to matter. They understood stuff that M$ with its "creeping featurism", "low support cost defaults", "undocumented API of the week" cannot possibly begin grok and deal with because of ETOOBIG. Now you and I use it because it does the job better than anything else. Then you blame them for not designing in today's requirements 30 (not 20!) years ago. Give them a break ... Daniel PS: Worm? Virus? Who wrote this up concisely first? PPS: Plan 9 anyone?
DK> Date: Thu, 30 Jan 2003 01:05:12 +0100 DK> From: Daniel Karrenberg DK> PPS: Plan 9 anyone? Available for your downloading pleasure. Factotum has picqued my interest, although I've not installed Plan9 myself yet. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
On Thu, 30 Jan 2003, Daniel Karrenberg wrote:
PPS: Plan 9 anyone?
Anything but _THAT_! At some period of my life I was paid to make something resembling production system out of Plan 9... it has all the quality features of v6 Unix, and looks like some student's course project. There were some interesting ideas, but the coding style was totally atrocious. Like, fixed size tables everywhere (oh, you run out of 100 open files, toooo baaaad), little charmers like TCP ACKs being sent in 20ms timer call-backs (so it works awfully great over 100Mbps ethernet :), text-based interfaces requiring padding with spaces to some fixed-length strings, and a zillion other quick hacks. "You are in a maze or little twisting cross-mounts, all alike" :) To summarize original Unix design & coding style very very concisely: % ed s/a/b/ ? That "?" says all. As a matter of fact, 30 years later ed still says "?". --vadim
Any opinion on Inferno ? It seems more suited to build a packet-eating-machine (router, firewall, vpn, choose your favorite flavour)... Rubens Kuhl Jr. ----- Original Message ----- From: "Vadim Antonov" <avg@kotovnik.com> To: </dev/null@reifchen.ripemtg.ripe.net> Cc: <nanog@merit.edu> Sent: Thursday, January 30, 2003 12:14 AM Subject: Re: Bell Labs or Microsoft security? | | | On Thu, 30 Jan 2003, Daniel Karrenberg wrote: | | > PPS: Plan 9 anyone? | | Anything but _THAT_! At some period of my life I was paid to make | something resembling production system out of Plan 9... it has all the | quality features of v6 Unix, and looks like some student's course project. | There were some interesting ideas, but the coding style was totally | atrocious. Like, fixed size tables everywhere (oh, you run out of 100 | open files, toooo baaaad), little charmers like TCP ACKs being sent in | 20ms timer call-backs (so it works awfully great over 100Mbps ethernet :), | text-based interfaces requiring padding with spaces to some fixed-length | strings, and a zillion other quick hacks. | | "You are in a maze or little twisting cross-mounts, all alike" :) | | To summarize original Unix design & coding style very very concisely: | | % ed | s/a/b/ | ? | | That "?" says all. As a matter of fact, 30 years later ed still says "?". | | --vadim |
participants (16)
-
Alif The Terrible -
Brian Wallingford -
Daniel Karrenberg -
E.B. Dreger -
Florian Weimer -
Joseph T. Klein -
Leo Bicknell -
Marshall Eubanks -
Mathew Lodge -
Peter Salus -
Richard A Steenbergen -
Rubens Kuhl Jr. -
Scott Francis -
Sean Donelan -
Steven M. Bellovin -
Vadim Antonov