sorry. better luck next time. i've been admining Unix and Win32 boxes for... well, a good while now, for really big companies. and for anyone with a reasonable security background, your post just doesn't hold water. for a few reasons. first off, the number of advisories at the sites you noted isn't any good indication of the security of the system. in fact, possibly the inverse. companies like Red Hat activly track and publicly report security issues to places like this, whereas Micro$oft doesn't, and has been known to exert legal or licensing force on folks who do. also, you're comparing all outstanding issues, for all versions. Linux/BSD/most unicies releases patches pretty regularly. Micro$oft? NT4 had, what 4 service packs? compare that to how often folks like Sun come out with patches, or even just the "recomended patch cluster". Micro$oft just doesn't take that kind of thing seriously. the problems remained, but they're more interested in preserving your reason for buying future product than in fixing the problem. next, Linux is far from the only Unix out there. whether by ignorance or intent, you've chosen to compare Win32 to the least secure Unix standardly available. do the same comparison to any of the BSDs (especially Open), or AIX, HP-UX, UnixWare, or (my personal favorite Unix) Solaris. your're not gonna turn up nearly as many holes. and (finally, for now) note that saying "you shouldn't use NT" doesn't translate into "use Linux instead". there are better Unicies out there (Solaris and OpenBSD for example) in terms of security, stability, and performance, and things even better than Unix (even plain-old telnet in Plan 9 requires challenge/response authentication - no passwords in the clear, ever, anywhere but your keyboard). and i'm not even going to comment on your statement that disabling a few options secures Win32. i'll assume you're kiding.
Charon accepts cookies just fine. um, you did read the man page, right? RIGHT?!? `man charon`, buddy. it's got problems with some JavaScript (thanks to crappy standards and Netscape and IE pretty much ignoring them anyway), and no Java at all (thank God), but it's got cookies, and is quite usable. i'm using Charon to post this, logged in and all.
i have not "played with" Plan 9; i have used it quite extensively, both in personal use and in a corporate development environment on major projects. Plan 9 is not the fastest system ever made for every application, no. but its speed has proven to be more than adaquate for everything i've needed it for. it's been able to service heavy web traffic, provide mail service based on database queries to an organization of well over 100K people, provide streaming audio, and still allow people to do their daily development work, all on a reasonably small cluster. yes, it's fast enough. oh, and when you say "all programs communicate through a protocol" as if it's a bad thing... would you rather then not have a defined method for communication (no protocol)? or maybe you'd rather they just didn't communicate...
i'm sorry, has he just killed your dog? you seem to take personal offense to his criticism of a C compiler. yes, GCC does all that you claim (i'd argue with the statement regarding the performance of the generated executables, but whatever). that's not what was being discussed. the fact that GCC is so frikin' huge really disturbs me. not to mention the fact that i don't want my C compiler to be able to do fortran, java, objective-C, C++, Ada, Python, Forth, 68020 assembly, Java, or whatever. i want it to be able to do C. call me unreasonable. also, gcc takes rediculous ammounts of time and energy to compile. it's huge! and the code is sloppy as all hell. maybe that's because it's the work of so many, over so long. i don't know. but it's nearly impossible to read and understand. also, it's slower at actually generating the executables than most compilers i've compared it to. and the fact that it's almost an ANSI C compiler bothers me. and the very existance of GNU C, and programs written specifically for it, REALLY bothers me. what's more, the Plan 9 compiler suite offers a far more ellegant solution to cross-compiling than gcc does. you might want to check it out. thank you for showing so much respect for the man with about 30 years of experience in C compilers, the guy who wrote the language!
yes, Plan 9 uses central servers for file storage. but the similarity between that and the 1970's dumb terminal days pretty much end there. when i was learning Plan 9 in '96, i started thinking of it as sort of "X terminals done right"... everything was imported from my file server to my terminal totally transparently. i couldn't tell from any normal use whether i was running networked or locally (you can run off local disk with Plan 9, it's just not recomended). it was beautiful. Plan 9 does not have process migration between servers, nor any redundancy in the typical clustering sense of the word. you can do server pools, certainly. yes, assuming it and OpenGL were ported, you could run Quake on a remote multi-processor Ultra-900000 or whatever, using all the processing power of that, and pushing the data out to your local display device. in this way, a 486 with a good graphics card becomes a quite usable terminal, if you've got a nice CPU server somewhere. but this isn't always a good idea. in your example, you've now got to stream the video data over the network; not very polite in a shared network, to be sure, and probably not practical with anything less than a dedicated link to your CPU server (which you could do, of cource).
okay, your questions first, in order. license: well, it's not GPL and you should read it without GPL in mind. it gives you alot of freedom and alot of options, but still allows an "original contributor" (note that this may include people other than Lucent in the future) still retains some significant rights. most notably, they are guaranteed access to any modifications you make, if they ask. performance: that depends who you ask. it certainly has been for all my uses. it's not quite the fastest system i've ever used, no, but it's certainly competative enough for most needs. SMP support is quite good in my experience; i've run several dual-PII boxes, and a pair of quad-PPro. both made me quite happy. and what're you talking about wrt text-based protocols? 9p isn't, and that's really the only Plan 9 specific protocol. drivers: more are always welcome, i suppose. the structure of the kernel makes the sort of importing from Linux/*BSD* not really feasable, and the structure of the system makes it not really a good idea anyway. but drivers can be made fairly easily. many exist for popular hardware, and could be used as templates for new ones. limitations: i'm not familiar with the one you cite, but there are some. while there is an ANSI/POSIX Environment (called APE, creatively enough), the native Plan 9 environment uses not-quite-ANSI C. the differences are described on the web site. generally, they make programs much cleaner, and source easier to read. also, much of what those things are commonly used for are simply not needed under Plan 9. windowing system: first off, it's rio, not 8 1/2, in the 3rd edition. similar feel, very different internals. as for your question: it's quite usable, in the guy-sitting-at-his-desk-trying-to-get-work-done sense of the word. it's easy to develop for, lightweight, and ver unintrusive. i've used it for years and not found anything nearly as nice. it takes some getting used to, coming from a typical Unix world, especially Plan 9's near total lack of cursor addressing. it really is an improvement, though, once you get used to it. porting GTK, OpenGL support: porting GTK doesn't make sense. rio doesn't run under/with X, and isn't even distantly related to X. it's model for doing things is totally different: it is a file server, in the Plan 9 way. it multiplexes devices, rather than providing other ways of talking to the same devices. in almost all cases, an app that can run under rio can run without it, or the other way around. including rio itself. Plan 9 usable for whatever: a resounding yes. lots of people, including me, have been doing it for years. a bunch of folks at the labs have it as their primary computing environment, including providing file service, web service, streaming audio, and distributed computation. they've used clusters of Plan 9 to do all sorts of interesting things, from mass audio encoding to chess simulation to formal verification systems.
moving on, i think maybe you missed much of the point. you say, for example, that "a lot of the functionality of Plan 9 can actually also be provided on top of a standard UNIX kernel without kernel modifications." i believe this to be quite false. the single largest difference, in my mind, is the use of per-process, user/process-modifable namespaces. check out upas/fs, rio, and acme and tell us how you'd be able to implement them under Unix. or something more basic like importing someone else's disk (not a partition or a file system, but the raw disk device). and you've got to be able to do it all as a user, not root.
first off, it's not a new OS. it began development in 1989 or 1990, and the previous edition was released in 1995. you make a number of statements or assertions that just arn't true: //Mac OS X is a Unix clone nope, sorry. it is built on a Unix kernel, and has a Unix-like command line, but that's not the same thing. is a VW bug a Corvette clone because they both use IC engines? //Windows 2000 is even trying to be Unix-ish. in some ways they're trying, yes. but this is mainly through a POSIX layer. or are you really only refering to the fact that they both have command lines which you can do things from? oh, no... you're not one of those horridly uninformed people who think DOS was "like Unix, only smaller", are you? //Amiga is now a Unix clone this may be true (i've not been able to check first hand), but certainly not from what i read. mainly, see the MacOS arguement above. //Is BeOS a Unix clone? well, at least you asked the question here. no, it's not. it was built from scratch, and borrows a few of the Unix ideas, but is a pretty new system. like Win32, it's got a POSIX compatability layer, and a (pretty limited) command line, but is most certainly not a Unix clone. and of cource, you implied that Plan 9 was a Unix clone. also untrue. Plan 9 was written from scratch, using many of the good ideas that have served Unix well for the past 30 years. it's by the same lab, so parts of the system feel much the same, but it is distinctly different.
no, that's not the editor... not in Plan 9, anyway. my favorite man page in the distrobution's got to be the man page for Emacs. the whole manual's at:
sure, several. the elegance of the system makes using it or developing on it simply beautiful. the windowing system, rio, makes writing graphical apps easy (especially compared to X or MS), the built-in support for Unicode on every level is really nice, and (speaking as a systems admin) the dump file system has saved me more time (and saved my ass more times) than i can count. not to mention all the "incremental" improvements they've got over comparable Unix tools: mk vs. make, rc vs. *sh*, etc. management of networked systems is far easier than anything i've seen or worked with (other than a bunch of Unix servers with XTs hanging off, and Plan 9's alot more powerful than that). it's fast and small.
Jason Earl, in his quite finite wisdom, said: "Give me an example of an innovation that would be impossible to implement on Unix and perhaps I might change my mind."
um, have you ever used Plan 9? here: rio and acme, just for starters. you also might want to take a look at section 4 of the Plan 9 manual (available online at http://plan9.bell-labs.com/sys/man). the third edition of Plan 9 is due out "any day now"... i suggest you take a look at it when it does pop up. specifically in Plan 9, the existance of dynamic, per-process, user/process-modifiable namespaces makes a whole range of applications possible that you just can't do on Unix. and before you point to 9wm or Wily as Unix implementations of rio or acme (respectivly), note that the authors of each specifically state they are not such things. they are designed to take the look and feel, but they are different things. also, there's more in question here than whether or not something's doable under a given platform. the platform influences what ideas you will work on. there is, for example, a reason why X (even before the popularity of Linux) had so many different window managers, while MS, which you can sort of do the same thing to, has three, to the best of my knowledge.
your comment about Emacs is, i think, a good example of much of what Rob's talking about. you want a platform that runs Emacs. regardless of whether the platform enables you to build far more innovative things than other platforms. regardless of whether or not it has something far superior to Emacs for whatever you use it for. Acme, for example, is a absolutely wonderful environment for developing programs, editing text docs, composing/editing/reading mail, and so on. but it's certainly NOT Emacs. therefor, based on your own comments, you wouldn't like it. i believe it is this attitude that has rob feeling a little less than enthusiastic about the state of OS research.
also, despite your summary, i don't think rob's complaining about "computer scientists" as a whole using the "crufty old tools" you mention. i think maybe he's a bit upset that folks doing OS research are so attached to those tools. without a doubt, the tools you do influence the types of ideas you come up with, or at very least which ones you implement, and how they end up looking.
uh, GCC is the crowning achievement of free software? god help us all. i love this: "gcc is among the most standards-compliant compilers in existence" um, sorry, but you're just plain wrong. unless you're refering to GNU C as a standard. gcc is an almost-ANSI C compiler... much less so than Sun's comercial C compiler. and the original comment was about inovation, not functionality. what about gcc makes it innovative? we've had cross-compilers before, we've got faster, smaller, better-optimizing compilers (not all at once), we've had portable compilers. if you're talking about functionality, GIMP is far more impressive than gcc. or groff, maybe. both re-implementations of existing ideas. neither's particularly innovative.
okay, cheif; if "the Internet is one big phreaking standard" than where can i find the definition for it? what body regulates this standard? c'mon... i'm begging for you to point me to all those RFCs out there. my good man, those are most definatly NOT standards documents. go read some IEEE or ANSI documents. now those are standards documents. and you don't see it as a potential problem that new ideas need to be tailored to existing ideas? you (well, maybe not you, but someone inteligend) could make the arguement that everyone benifits from _real_ standards, sure. and lots of people ARE complaining that the internet could benefit from some _real_ standards, or that there's lots of other problems with it, or its current structure; you simply choose not to hear them.
oh, and "The computer is an appliance now"... really? what sort of computer are you using? my mother can connect a TV and a toaster... give her a computer and she's lost. and ever set up networking on a Win32 box? _that's_ an appliance? bah. you _can't_ be that dumb.
I think, in general you're correct. i used to work in a very large company (big red circle for a logo, used to be the phone company...), and the overwhelming trend was that people with more formal education had better programing skills. there was also a very real trend that those with more experience had better skills. there were exceptions to both, of cource, but the trend existed. what i think is pretty key here is the difference between education, certification, and vocational training. regardless of where it's obtained, be it in school, or work, or whatever, it's education that makes someone a good programer (or a good _whatever_, for that matter). training is clearly a part of that education (you'll make a lousy C programmer if you don't the syntax), but it's not the whole story. certification (like degrees), tends to indicate a certain level of training, but really says very little about overall education. like Roundeye says, things like working in a group, understanding of deadlines and priorities, things like that, are equally important to being more than a coder, but a programer, an architect. certifications may not be the whole story, but they're better than nothing. if you've been in the "real world" for a decade, and you've got good references, but no degree, great. you're still a viable prospect. but if you've got no degree, you've never worked on anything, but can code me a C compiler in 15 minutes... sorry, better luck next time. i've run hiring of various IT departments for people in my former company, and i only saw one aplicant (out of several dozen) worth looking at who didn't have a degree. i didn't see any who didn't have solid work experience. myself, i've got no degree. i'm good at what i do, but i know i'd benefit from certain types of formal education. there are things you learn in a good program that do more than increase your knowledge: they change the way your mind works. a guy i used to work with tought a 12 week cource in fortran. after restructuring the cource, he was producing better fortran programers than the cource had ever previously seen. his restructing consisted of this: 10 weeks learning concepts in pascal, then the last two in fortran. the vocational training of learning to fortran syntax was the easy part; learning how to build and design programs was the hard part. i consider it something of a tragedy that most University CompSci/CompEng programs are becomeing glorified VoTec cources. any department that teaches intro programing (or related) using Java or C++ is a good example. OS cources teaching from Linux is another danger sign. the industry has no shortage of coders; they're a dime a dozen. what we're at a serious shortage of are program architects. and it's rare to learn that mucking around in your basement.
Slashdot Mirror
sorry. better luck next time.
i've been admining Unix and Win32 boxes for... well, a good while now, for really big companies. and for anyone with a reasonable security background, your post just doesn't hold water. for a few reasons.
first off, the number of advisories at the sites you noted isn't any good indication of the security of the system. in fact, possibly the inverse. companies like Red Hat activly track and publicly report security issues to places like this, whereas Micro$oft doesn't, and has been known to exert legal or licensing force on folks who do.
also, you're comparing all outstanding issues, for all versions. Linux/BSD/most unicies releases patches pretty regularly. Micro$oft? NT4 had, what 4 service packs? compare that to how often folks like Sun come out with patches, or even just the "recomended patch cluster". Micro$oft just doesn't take that kind of thing seriously. the problems remained, but they're more interested in preserving your reason for buying future product than in fixing the problem.
next, Linux is far from the only Unix out there. whether by ignorance or intent, you've chosen to compare Win32 to the least secure Unix standardly available. do the same comparison to any of the BSDs (especially Open), or AIX, HP-UX, UnixWare, or (my personal favorite Unix) Solaris. your're not gonna turn up nearly as many holes.
and (finally, for now) note that saying "you shouldn't use NT" doesn't translate into "use Linux instead". there are better Unicies out there (Solaris and OpenBSD for example) in terms of security, stability, and performance, and things even better than Unix (even plain-old telnet in Plan 9 requires challenge/response authentication - no passwords in the clear, ever, anywhere but your keyboard).
and i'm not even going to comment on your statement that disabling a few options secures Win32. i'll assume you're kiding.
Charon accepts cookies just fine. um, you did read the man page, right? RIGHT?!? `man charon`, buddy. it's got problems with some JavaScript (thanks to crappy standards and Netscape and IE pretty much ignoring them anyway), and no Java at all (thank God), but it's got cookies, and is quite usable. i'm using Charon to post this, logged in and all.
i have not "played with" Plan 9; i have used it quite extensively, both in personal use and in a corporate development environment on major projects. Plan 9 is not the fastest system ever made for every application, no. but its speed has proven to be more than adaquate for everything i've needed it for. it's been able to service heavy web traffic, provide mail service based on database queries to an organization of well over 100K people, provide streaming audio, and still allow people to do their daily development work, all on a reasonably small cluster. yes, it's fast enough.
oh, and when you say "all programs communicate through a protocol" as if it's a bad thing... would you rather then not have a defined method for communication (no protocol)? or maybe you'd rather they just didn't communicate...
i'm sorry, has he just killed your dog? you seem to take personal offense to his criticism of a C compiler. yes, GCC does all that you claim (i'd argue with the statement regarding the performance of the generated executables, but whatever). that's not what was being discussed. the fact that GCC is so frikin' huge really disturbs me. not to mention the fact that i don't want my C compiler to be able to do fortran, java, objective-C, C++, Ada, Python, Forth, 68020 assembly, Java, or whatever. i want it to be able to do C. call me unreasonable.
also, gcc takes rediculous ammounts of time and energy to compile. it's huge! and the code is sloppy as all hell. maybe that's because it's the work of so many, over so long. i don't know. but it's nearly impossible to read and understand. also, it's slower at actually generating the executables than most compilers i've compared it to.
and the fact that it's almost an ANSI C compiler bothers me. and the very existance of GNU C, and programs written specifically for it, REALLY bothers me.
what's more, the Plan 9 compiler suite offers a far more ellegant solution to cross-compiling than gcc does. you might want to check it out.
thank you for showing so much respect for the man with about 30 years of experience in C compilers, the guy who wrote the language!
yes, Plan 9 uses central servers for file storage. but the similarity between that and the 1970's dumb terminal days pretty much end there. when i was learning Plan 9 in '96, i started thinking of it as sort of "X terminals done right"... everything was imported from my file server to my terminal totally transparently. i couldn't tell from any normal use whether i was running networked or locally (you can run off local disk with Plan 9, it's just not recomended). it was beautiful.
Plan 9 does not have process migration between servers, nor any redundancy in the typical clustering sense of the word. you can do server pools, certainly.
yes, assuming it and OpenGL were ported, you could run Quake on a remote multi-processor Ultra-900000 or whatever, using all the processing power of that, and pushing the data out to your local display device. in this way, a 486 with a good graphics card becomes a quite usable terminal, if you've got a nice CPU server somewhere. but this isn't always a good idea. in your example, you've now got to stream the video data over the network; not very polite in a shared network, to be sure, and probably not practical with anything less than a dedicated link to your CPU server (which you could do, of cource).
okay, your questions first, in order.
license: well, it's not GPL and you should read it without GPL in mind. it gives you alot of freedom and alot of options, but still allows an "original contributor" (note that this may include people other than Lucent in the future) still retains some significant rights. most notably, they are guaranteed access to any modifications you make, if they ask.
performance: that depends who you ask. it certainly has been for all my uses. it's not quite the fastest system i've ever used, no, but it's certainly competative enough for most needs. SMP support is quite good in my experience; i've run several dual-PII boxes, and a pair of quad-PPro. both made me quite happy.
and what're you talking about wrt text-based protocols? 9p isn't, and that's really the only Plan 9 specific protocol.
drivers: more are always welcome, i suppose. the structure of the kernel makes the sort of importing from Linux/*BSD* not really feasable, and the structure of the system makes it not really a good idea anyway. but drivers can be made fairly easily. many exist for popular hardware, and could be used as templates for new ones.
limitations: i'm not familiar with the one you cite, but there are some. while there is an ANSI/POSIX Environment (called APE, creatively enough), the native Plan 9 environment uses not-quite-ANSI C. the differences are described on the web site. generally, they make programs much cleaner, and source easier to read. also, much of what those things are commonly used for are simply not needed under Plan 9.
windowing system: first off, it's rio, not 8 1/2, in the 3rd edition. similar feel, very different internals. as for your question: it's quite usable, in the guy-sitting-at-his-desk-trying-to-get-work-done sense of the word. it's easy to develop for, lightweight, and ver unintrusive. i've used it for years and not found anything nearly as nice. it takes some getting used to, coming from a typical Unix world, especially Plan 9's near total lack of cursor addressing. it really is an improvement, though, once you get used to it.
porting GTK, OpenGL support: porting GTK doesn't make sense. rio doesn't run under/with X, and isn't even distantly related to X. it's model for doing things is totally different: it is a file server, in the Plan 9 way. it multiplexes devices, rather than providing other ways of talking to the same devices. in almost all cases, an app that can run under rio can run without it, or the other way around. including rio itself.
Plan 9 usable for whatever: a resounding yes. lots of people, including me, have been doing it for years. a bunch of folks at the labs have it as their primary computing environment, including providing file service, web service, streaming audio, and distributed computation. they've used clusters of Plan 9 to do all sorts of interesting things, from mass audio encoding to chess simulation to formal verification systems.
moving on, i think maybe you missed much of the point. you say, for example, that "a lot of the functionality of Plan 9 can actually also be provided on top of a standard UNIX kernel without kernel modifications." i believe this to be quite false. the single largest difference, in my mind, is the use of per-process, user/process-modifable namespaces. check out upas/fs, rio, and acme and tell us how you'd be able to implement them under Unix. or something more basic like importing someone else's disk (not a partition or a file system, but the raw disk device). and you've got to be able to do it all as a user, not root.
first off, it's not a new OS. it began development in 1989 or 1990, and the previous edition was released in 1995. you make a number of statements or assertions that just arn't true:
//Mac OS X is a Unix clone
//Windows 2000 is even trying to be Unix-ish.
//Amiga is now a Unix clone
//Is BeOS a Unix clone?
nope, sorry. it is built on a Unix kernel, and has a Unix-like command line, but that's not the same thing. is a VW bug a Corvette clone because they both use IC engines?
in some ways they're trying, yes. but this is mainly through a POSIX layer. or are you really only refering to the fact that they both have command lines which you can do things from? oh, no... you're not one of those horridly uninformed people who think DOS was "like Unix, only smaller", are you?
this may be true (i've not been able to check first hand), but certainly not from what i read. mainly, see the MacOS arguement above.
well, at least you asked the question here. no, it's not. it was built from scratch, and borrows a few of the Unix ideas, but is a pretty new system. like Win32, it's got a POSIX compatability layer, and a (pretty limited) command line, but is most certainly not a Unix clone.
and of cource, you implied that Plan 9 was a Unix clone. also untrue. Plan 9 was written from scratch, using many of the good ideas that have served Unix well for the past 30 years. it's by the same lab, so parts of the system feel much the same, but it is distinctly different.
no, that's not the editor... not in Plan 9, anyway. my favorite man page in the distrobution's got to be the man page for Emacs. the whole manual's at:
http://plan9.bell-labs.com/sys/man
no, it means no such thing. it's an old message, from the old AT&T unix days. see /etc/rc? on any (i think) commercial unix. lots of other places, too.
sure, several. the elegance of the system makes using it or developing on it simply beautiful. the windowing system, rio, makes writing graphical apps easy (especially compared to X or MS), the built-in support for Unicode on every level is really nice, and (speaking as a systems admin) the dump file system has saved me more time (and saved my ass more times) than i can count. not to mention all the "incremental" improvements they've got over comparable Unix tools: mk vs. make, rc vs. *sh*, etc. management of networked systems is far easier than anything i've seen or worked with (other than a bunch of Unix servers with XTs hanging off, and Plan 9's alot more powerful than that). it's fast and small.
try it. you'll like it.
Jason Earl, in his quite finite wisdom, said: "Give me an example of an innovation that would be impossible to implement on Unix and perhaps I might change my mind."
um, have you ever used Plan 9? here: rio and acme, just for starters. you also might want to take a look at section 4 of the Plan 9 manual (available online at http://plan9.bell-labs.com/sys/man).
the third edition of Plan 9 is due out "any day now"... i suggest you take a look at it when it does pop up.
specifically in Plan 9, the existance of dynamic, per-process, user/process-modifiable namespaces makes a whole range of applications possible that you just can't do on Unix.
and before you point to 9wm or Wily as Unix implementations of rio or acme (respectivly), note that the authors of each specifically state they are not such things. they are designed to take the look and feel, but they are different things.
also, there's more in question here than whether or not something's doable under a given platform. the platform influences what ideas you will work on.
there is, for example, a reason why X (even before the popularity of Linux) had so many different window managers, while MS, which you can sort of do the same thing to, has three, to the best of my knowledge.
your comment about Emacs is, i think, a good example
of much of what Rob's talking about. you want a platform
that runs Emacs. regardless of whether the platform
enables you to build far more innovative things than
other platforms. regardless of whether or not it has
something far superior to Emacs for whatever you use
it for. Acme, for example, is a absolutely wonderful
environment for developing programs, editing text docs,
composing/editing/reading mail, and so on. but it's
certainly NOT Emacs. therefor, based on your own comments,
you wouldn't like it. i believe it is this attitude
that has rob feeling a little less than enthusiastic
about the state of OS research.
also, despite your summary, i don't think rob's complaining
about "computer scientists" as a whole using the "crufty
old tools" you mention. i think maybe he's a bit upset
that folks doing OS research are so attached to those
tools. without a doubt, the tools you do influence
the types of ideas you come up with, or at very least
which ones you implement, and how they end up looking.
uh, GCC is the crowning achievement of free software?
god help us all. i love this: "gcc is among the most standards-compliant compilers in existence"
um, sorry, but you're just plain wrong. unless you're refering to
GNU C as a standard. gcc is an almost-ANSI C
compiler... much less so than Sun's comercial C
compiler. and the original comment was about inovation,
not functionality. what about gcc makes it innovative?
we've had cross-compilers before, we've got faster,
smaller, better-optimizing compilers (not all at once),
we've had portable compilers. if you're talking about
functionality, GIMP is far more impressive than gcc.
or groff, maybe. both re-implementations of existing
ideas. neither's particularly innovative.
okay, cheif; if "the Internet is one big phreaking
standard" than where can i find the definition for
it? what body regulates this standard? c'mon... i'm
begging for you to point me to all those RFCs out
there. my good man, those are most definatly NOT standards
documents. go read some IEEE or ANSI documents. now
those are standards documents. and you don't see it
as a potential problem that new ideas need to be tailored
to existing ideas? you (well, maybe not you,
but someone inteligend) could make the arguement that
everyone benifits from _real_ standards, sure. and
lots of people ARE complaining that the internet could
benefit from some _real_ standards, or that there's
lots of other problems with it, or its current structure;
you simply choose not to hear them.
oh, and "The computer is an appliance now"... really?
what sort of computer are you using? my mother can
connect a TV and a toaster... give her a computer and
she's lost. and ever set up networking on a Win32 box?
_that's_ an appliance? bah. you _can't_ be that dumb.
I think, in general you're correct. i used to work in a very large company (big red circle for a logo, used to be the phone company...), and the overwhelming trend was that people with more formal education had better programing skills. there was also a very real trend that those with more experience had better skills. there were exceptions to both, of cource, but the trend existed.
what i think is pretty key here is the difference between education, certification, and vocational training.
regardless of where it's obtained, be it in school, or work, or whatever, it's education that makes someone a good programer (or a good _whatever_, for that matter). training is clearly a part of that education (you'll make a lousy C programmer if you don't the syntax), but it's not the whole story.
certification (like degrees), tends to indicate a certain level of training, but really says very little about overall education. like Roundeye says, things like working in a group, understanding of deadlines and priorities, things like that, are equally important to being more than a coder, but a programer, an architect.
certifications may not be the whole story, but they're better than nothing. if you've been in the "real world" for a decade, and you've got good references, but no degree, great. you're still a viable prospect. but if you've got no degree, you've never worked on anything, but can code me a C compiler in 15 minutes... sorry, better luck next time.
i've run hiring of various IT departments for people in my former company, and i only saw one aplicant (out of several dozen) worth looking at who didn't have a degree. i didn't see any who didn't have solid work experience.
myself, i've got no degree. i'm good at what i do, but i know i'd benefit from certain types of formal education. there are things you learn in a good program that do more than increase your knowledge: they change the way your mind works.
a guy i used to work with tought a 12 week cource in fortran. after restructuring the cource, he was producing better fortran programers than the cource had ever previously seen. his restructing consisted of this: 10 weeks learning concepts in pascal, then the last two in fortran. the vocational training of learning to fortran syntax was the easy part; learning how to build and design programs was the hard part.
i consider it something of a tragedy that most University CompSci/CompEng programs are becomeing glorified VoTec cources. any department that teaches intro programing (or related) using Java or C++ is a good example. OS cources teaching from Linux is another danger sign.
the industry has no shortage of coders; they're a dime a dozen. what we're at a serious shortage of are program architects. and it's rare to learn that mucking around in your basement.