Slashdot Mirror

BTW, why doesn't anyone mention Dennis Ritchy? He has said some good things about Linux. Also, he did a hell of a lot more work on AT&T Unix than Thompson did. He wrote the C compiler and put together most of the kernel. Thompson wrote the filesystem and text formatters.

Here are some notes Dennis Ritchie found on an old DECtape he had, in which he says:

UNIX was written by K. Thompson. I wrote much of the system software; Ken most of the rest; Other contributors have been Joe Ossanna, Doug McIlroy, and Bob Morris.

Upon what do you base your assertion that Dennis "put together most of the kernel"?

For that matter, as I remember, Joe Ossanna wrote "nroff" and "troff"....

In his bio on his Web site, Dennis also says:

Subsequently, I aided Ken Thompson in creating the Unix operating system. After Unix had become well established in the Bell System and in a number of educational, government and commercial installations, Steve Johnson and I (helped by Ken) transported the operating system to the Interdata 8/32, thus demonstrating its portability, and laying the groundwork for the widespread growth of Unix: the Seventh Edition version from the Bell Labs research group was the basis for commercial Unix System V and also for the Unix BSD distributions from the University of California at Berkeley. The last important technical contribution I made to Unix was the Streams mechanism for interconnecting devices, protocols, and applications.

BTW, why doesn't anyone mention Dennis Ritchy? He has said some good things about Linux. Also, he did a hell of a lot more work on AT&T Unix than Thompson did. He wrote the C compiler and put together most of the kernel. Thompson wrote the filesystem and text formatters.

Here are some notes Dennis Ritchie found on an old DECtape he had, in which he says:

UNIX was written by K. Thompson. I wrote much of the system software; Ken most of the rest; Other contributors have been Joe Ossanna, Doug McIlroy, and Bob Morris.

Upon what do you base your assertion that Dennis "put together most of the kernel"?

For that matter, as I remember, Joe Ossanna wrote "nroff" and "troff"....

In his bio on his Web site, Dennis also says:

Subsequently, I aided Ken Thompson in creating the Unix operating system. After Unix had become well established in the Bell System and in a number of educational, government and commercial installations, Steve Johnson and I (helped by Ken) transported the operating system to the Interdata 8/32, thus demonstrating its portability, and laying the groundwork for the widespread growth of Unix: the Seventh Edition version from the Bell Labs research group was the basis for commercial Unix System V and also for the Unix BSD distributions from the University of California at Berkeley. The last important technical contribution I made to Unix was the Streams mechanism for interconnecting devices, protocols, and applications.

I agree overloaded operators are easier to use, and it makes Java very verobose (as well as increasing the inelegant distinction between objects and primtive types).

Indeed. Every sentient being reading this should immediately snarf the paper written by Guy Steele for OOPSLA '98 entitled Growing a Language which makes this point so forcefully you will be dazzled.

The best place to find this on the net is apparently hanging off the web page of the soon-to-be-slashdotted Phil Wadler; download the postscript version this instant.

The problem with operator overloading is that in long peices of code, it makes it hard to work out what is really going on - you cannot tell whether a + b is just an integer addition or some function call, and then you do not know whether it has the properties you would expect of +.

This is a bit of a red herring. Overloaded methods are at least as open to abuse (e.g., some clown could always define a "print" method that reads files instead...). What they don't do is invite the same expectations. But I think Java has a way out of this: you could have classes implement a standard interface that includes the operators you want to use in your class.

I've always found Java ironic that way; they come up with a truly cool idea like interfaces, then still use inheritance all over the place just to be OO, I suppose.

King Babar

Hell 'we' get 400 Gbps on a single fibre.

But then we're the reason we say *nix!

Drool

I wonder if the strands could be "read" by electrical means.?. After all, DNA is ultimately a biologically evolved four-state memory device.

One method: If each base has a unique resonant frequency (or set of frequencies, like little tiny antennas - akin to spectroscopy), and you "modulate" a strand at each resonance set, would you be able to extract an RF profile or "image" of the strand's sequence? Scanning Capacitance Microscopes might do the trick.

Just a thought...

The general opinion here seems to be like what
was written in an old book about the ibm os/360
project called the "Mythical Man Month" - if it
takes 60 programmers 6 months to write an os, it
will take 120 programmers only 6 months to write the same os.

BTW:
If 8 perl programmers take 8 days to write 8 programs, how long will it take 16 programmers to write 16 programs? ANS: 8 days.

Dr. Software Speaks

here is another cool picture of the internet

I actually work with Denis, Ken, and Brian and they're still cranking out some really cool stuff. None of it is mainstream due to Lucent's (Bell Labs) marketing of it and the huge installed base of current poop (MS Win) and software (*NIX)..

True that GOTOs are still running amuck in their code sometimes. Some of their newer stuff, papers, and such should be public like the theories behind OSs like Plan9 and Inferno, two OSs based completely on a file stucture for everything.

If you check out http://plan9.bell-labs.com/cm/cs/ you can find them and some off their recent work. Check it out.

I think there's perhaps two questions being asked: how to become a competent sysadmin, and how to get hired doing the job. They've got different answers; some people have been answering one, some people have been answering the other.

In order to be a good, competent sysadmin I think you need to understand Unix and the Unix philosophy. Once you grok the philosophy, it is much easier to predict and use Unix, because things make sense. The best book for this that I've ever read is Kernighan and Pike's The Unix Programming Environment. As a side benefit, it will teach you a good amount about the basic tools. It is somewhat dated and assumes that you can program.

Get experience on multiple different Unix variants. This will teach a number of valuable things: how things are different, how things are the same, and how to efficiently ferret out information on new things. Try to work on Unixes that vary as widely as possible, for maximum broadening. If you have a network, use it and work out how to manage several different Unixes so that the users (even if that's only you) won't notice and won't care which one they're using.

Learn debugging skills: how to rapidly figure out what exactly is going wrong in a broken thing and how to dive in to tweak it so it works again. I don't know of any good books on this (and it's probably only taught implicitly at your local university), but it is a skill that a sysadmin will use over and over again. Learn how to poke through a system to see how it does a particular thing.

Learn how to program if at all possible. Not just writing scripts, but really programming. I think that in the long run all the interesting and sustainable bits of system administration will involve being able to do so. Sooner or later all the easy stuff will be automated or become grunt-work of filling in forms or changing backup tapes, done by people who are essentially clerks.

In my opinion, good sysadmins don't know everything, but they do know how to find it out; they learn fast and they can ferret out that little necessary tidbit of information. Learn how to find things out on Unix systems; man pages, GNU texinfo, whatever local proprietary system a Unix vendor may have added, and so on. Information, especially on a Unix system, has a structure; grok it, exploit it, and predict it.

Learn how to read manual pages (an underrated but essential skill). When you can read the 7th Edition sh manpage and it makes sense, you have achieved this. (You can find the 7th Edition documentation at this URL.)

For getting hired, I have no really good ideas. If you know people in Human Resources departments (or who otherwise hire or filter people), ask them for what they look for in a resume that gets that first foot in the door. This may well be a certificate or a course, even if it doesn't teach you anything useful in the long term. HR often works on magic words.

A local Unix user's group may be a good way to get contacts, and maybe even get offered that first job; if nothing else, you can establish to the people who may hire you someday that you do indeed know what you're talking about. If there isn't a local Unix user's group, founding one is likely to get you fairly well known.