The Good, the Bad, and the Ugly: The Unix Legacy

http://herpolhode.com/rob/ugly.pdf

by orib • 18 years ago

28 32 18 years ago

herpolhode.com

gaius8• 18 years ago

by making all hardware equivalent, good software enabled bad hardware.

An excellent point.

tptacek9• 18 years ago

Is it really? High-end X86 server hardware is quite good.

gaius8• 18 years ago

There is some pretty decent kit around at the moment, e.g. Sun's x4500 and x4600, but that's fairly recent, it wasn't that long ago that an x86 "server" was a desktop PC in a rackmount chassis. If even that, I remember datacentre racks full of desktop PCs on shelves. Even now, there are only a handful of tier 1 vendors making kit where everything from the RAID acceleration to the 10gigE works right out of the box.

orib4• 18 years ago

Compared to most architectures, X86 sucks pretty badly. Thanks to good compilers, though, you don't have to care about the lameness of the instruction set (eg, there are ambiguities in the encoding that need to be disambiguated by register prefixes, there are lots of subtle and pointless variations in the instructions, etc.) Good software lets you pretend that the instruction set you're using isn't actually complete crap.

newt0311• 18 years ago

Another excellent point: C. C is absolutely wonderful for writing low-level code like kernels, device drivers, and language interpreters. For anything else, it is atrocious. The problem is that these two spheres require drastically different tool sets. Kernels and the kind need to be exposed to the underlying implementations because they need to manipulate these low level devices. Application software on the other hand should be completely insulated from such low level details of the system.

ajross2• 18 years ago

Honestly, that conventional wisdom is a little hackneyed.

I'm not sure most folks would call C "wonderful" for low level code. It's warts are well known, and really don't need to be there: the structure syntax is needlessly complicated (. and -> are separate operators for no good reason); the calling conventions are backwards to support a varargs facility that almost no one understands; they underspecified the type conventions, leading to perennial confusion about the sizes of ints and longs or the signedness of char; etc... If you were starting from scratch to write a language to live in the same space, you probably would fix most of those.

But conversely, it's not "atrocious" for "application" code either. Plenty of good software has been and will continue to be written in C. It's probably a poor choice for code that handles mostly string data. It's doesn't have a whole lot of advantages for an architecture with lots of parallelism (i.e. one which doesn't need to worry about single-CPU performance issues). Since those two criteria generally define "web development", you don't see a whole lot of C used for the kind of problems YC startups work on. Just recognize that those defined a very limited notion of "application", and that lots of people in the real world are working on "applications" for which C et. al. are very useful, eminently practical languages choices.

Really, C is there to abstract the CPU. If the CPU has an instruction to do something, you'll probably find it as an operator in C. If it doesn't, you won't. If your problem is appropriately targetted at that level of abstraction, you'll think C is great. If it's not, you won't. I guess that's hardly a surprise.

stcredzero• 18 years ago

I've worked on a large client/server property/casualty insurance application written in C. I've also written programs and middleware in C++, Java, Perl, and Smalltalk.

C is great for getting the CPU to do something at a somewhat low level, but still having some ability to abstract. If you want lots of abstraction my experience is that C++, Java, and Smalltalk are much better choices. Of those, C++ gives you the most leeway for getting yourself into deep trouble that's hard to debug. Smalltalk allows you to blow up or lock up the world with one errant statement, but messing with those parts of the library is rare, and you can get everything back anyhow because your source code and every change to the image is kept in something like a transaction log. Java gives you a lot of the benefits of Smalltalk, but saddles you with a syntax that was designed to allow low level programming with somewhat high level abstraction, even though you aren't doing the former and want the latter in spades.

iigs• 18 years ago

from the pdf:

cat . doesn't work anymore (readdir vs. read).

Does anyone know when this last worked? I'd love to install whatever version of UNIX had this and see the output from it.

tptacek9• 18 years ago

It's binary gibberish. It's also the answer to an old DE Shaw interview question --- how do you tell whether you're on an NFS-mounted filesystem or not? ("cat ." will fail on NFS).

nailer3• 18 years ago

Interesting. Was there no 'mount' command, or for those of us who like to save commands, 'df .'?

pavelludiq• 18 years ago

"1. What is the best thing about Unix? A: The community. 2. What is the worst thing about Unix? A: That there are so many communities."

I can't say i agree. Why are there so many BSD's and why are there even more Linux distros, and why are there so many 'buntus? Well its my opinion that having that many choices is an advantage. I can't stand 90% of the Linux distributions, but some people might think that my choice(Kubuntu) is a bad one, some would say that choosing Linux instead of FreeBSD or OpenBSD is a bad idea. Choice is good, sometimes more choices are confusing, but if you just go for the most popular choices and ignore the less popular ones, its easy to make them. Will we have one unified Unix one day? If it runs gnome i'll switch to vista, no tanks Ubuntu, KDE is MY choice, its good to have one.

silentbicycle• 18 years ago

The Unix culture intrinsically values having so many choices, which is a consequence, I think, of historically being a platform by programmers/for programmers. Some people are picky about tools, and it encourages them to make their own. It's highly unlikely that it will unify in any real sense as long as its core design attracts people who bristle at the thought of being stuck using anything besides KDE, or GNOME, or Fluxbox, or ratpoison, or dwm, ...

I think it's a really good thing that different distributions tend to focus on particular goals, e.g. security as a design principle in OpenBSD, portability in NetBSD, being available as a free OS (in various senses) with Debian and Ubuntu, etc. (I really don't want this to turn into an argument about different distros; I know I'm trailing off there, I had a harder time summarizing Debian). Anyway, different foci lead to different discoveries, bugfixes, etc., but due to the pervasive Unix culture they are shared.

Still, that avalanche of necessary choices will probably keep it thriving in different niches from a system designed to have a consistent face for everyone. It's harder to teach people to use, harder to market, etc.

The Good, the Bad, and the Ugly: The Unix Legacy

Related Stories