This sort of thing should be well covered by
university policy. In the old days, professors
and grad students got to keep everything. Now
the schools are starting to want a piece of the pie, and are trying to
change the rules. I don't know of any place
where the school gets 100%, but a lot of places
are introducing some sort of splitting arrangement.
My opinion is that you should fight it tooth and
nail. The "work for hire" doctrine is intended
for situations where an employer gives you specific direction: "I want you to build an airplane that goes 550 knots or better and carries between 400 and 500 passengers." It isn't intended to apply to situations where they say "Go and think of cool things, but if you come up with anything commercially viable, I want a cut because I was buying your pizza."
The only way these cretins could get me to assign one of their books for a class would be if there were no paper books left in the world and
they cut my fingers off. I'd rather write and
self-publish my own text that do such a thing to my students.
You might be able to sell such an idea to dentists, because sadly, a lot of dentists aren't all that bright. But any CS student would be nuts to buy into such an astoundingly greedy scheme. And any CS prof -- or engineering, or physics, or humanities -- should be burned at the stake for helping to promote it as long as there is still an alternative.
You can count on it that
the only reason this thing is flying even as far as it has gone is that Vicious Source Technologies has paid NYU a huge bribe. Sure, it's called a "marketing agreement", but you know that it boils down to money changing hands.
The NYU dental school is a blight on the face of academia. Their next contract will probably be with a huge candy company.
Yeah, that's what I care about. The single most important thing about the computer of 2010 is that it looks like a flying saucer. Oh, sure, we'll toss in a reference to optoelectronics to show that we're hip to technological issues as well as artsy stuff.
Duh.
One form of the 2010 machine will be a tiny watch or pendant running Linux 4.8.16. But another will be a clunky tower, just like today, because the bigger the package, the more you can put inside.
I doubt there'll be a place for their inconvenient, unstackable design.
Technologically,
maybe it won't even have a hard disk. Maybe it'll
use optics, maybe something else. The only thing I care about is that
it'll be big (storage-wise) and fast.
As to the "swoopy" design, just check out all those 50's-era predictions of the future. Yeah, it'll look like a frisbee -- and no doubt I'll be wearing a silvery one-piece jumpsuit.
Writers don't get to define technical terms
on
Is UNIX An OS?
·
· Score: 1
Sigh.
You might as well argue that an Indy race car isn't
an automobile because it doesn't have a cup holder.
"Operating System" is a technical term in computer science.
It has a precise definition.
Like most technical terms, you can't arbitrarily
decide to change the definition (if you plan to communicate effectively).
It's especially ridiculous to try to do so as
part of an argument that depends on drawing definitional lines.
Part of the problem is that distributed operating systems are much harder to do than we would wish (as are distributed applications). Napster isn't the answer, it's really just a specialized search engine combined with what boils down to a bunch of ftp servers.
Load balancing? Easy to write, hard to make work well. You need to compare the cost of migration to the benefits of balancing, and you need to make decisions based on partial and outdated information. Many early systems thrashed because everybody would migrate to the idle processor, which then became overloaded, so everybody migrated somewhere else, etc.
Speaking of migration, it's a mess. The only system I know of that implemented migration fully was Locus, out of UCLA. The trouble is that whenever a process has a dependency on or a hook into its environment, that connection must be migrated too. Open files, working directory, sockets, controlling tty, signals, process parent/child relationships, and many more details must be handled. Not fun, and the benefits turned out to be mostly minor (though I do recall writing a cool version of "find" that migrated itself to the machine that stored the current subtree as it ran).
The issue of supporting distributed applications is generally considered to be separate from writing a truly distributed OS. Most of what a distributed application needs can be provided by a good communications library. To some extent, we're still learning exactly what such a library should have. What about SETI@home is specialized to it, and what's universal? I don't think we've completely figured it out.
The following is a non-exhaustive list of major concerns and design issues that must be addressed in a distributed OS. We have fairly good solutions to some, but most have not yet been solved:
Process control. How much process migration is a Good Thing? How do you decide what machine to use to start a process, and when do you decide to migrate it to another?
Communication and synchronization. What facilities does a distributed application need? How do we make those easy to use?
Reliability. How do we deal with the inevitable machine failures?
Replication. What processes and data should be duplicated on different systems? Are you doing the replication for performance, for reliability, or both? How do you manage updates to replicated data? How do you keep replicated process synchronized?
Lack of global knowledge. How do you make decisions based on partial information?
Naming. What names to things have. Do you have a shared global namespace, or a private one? How do you resolve names? What do you do when people and objects move?
Scalability. How does the system behave when the number of computers/users/programs jumps by a factor of 10 or 100? (This is a place where Napster doesn't do real well.)
Compatibility. How do you support existing software? Do you run on only one kind of hardware, or many?
Security. Who gets to run on what machine?
Finally, I should note that the list of projects at U of Arizona might appear to be complete, but it omits a lot of important projects. Four that jump to my mind are Locus and Ficus from UCLA (though the latter is more of a distributed filesystem than an OS), Coda from CMU (again a DFS, rather well-known to Linux folks), and of course the extremely important Network of Workstations work out of UC Berkeley, which led to Inktomi and Hotbot.
(3) The term ''telephone solicitation'' means the initiation of a telephone call or message for the purpose of encouraging the purchase or rental of, or investment in, property, goods, or services, which is transmitted to any person, [unless based on a prior relationship]
It shall be unlawful for any person within the United States... (B) to initiate any telephone call to any residential telephone line using an artificial or prerecorded voice to deliver a message without the prior express consent of the called party, unless the call is initiated for emergency purposes or is exempted by rule or order by the Commission under paragraph (2)(B);
(3) Private right of action A person or entity may, if otherwise permitted by the laws or rules of court of a State, bring in an appropriate court of that State - (A) an action based on a violation of this subsection or the regulations prescribed under this subsection to enjoin such violation, (B) an action to recover for actual monetary loss from such a violation, or to receive $500 in damages for each such violation, whichever is greater, [emphasis added] or (C) both such actions. If the court finds that the defendant willfully or knowingly violated this subsection or the regulations prescribed under this subsection, the court may, in its discretion, increase the amount of the award to an amount equal to not more than 3 times the amount available under subparagraph (B) of this paragraph.
In other words, if ABC calls you and either (a) hangs up without talking to you or (b) leaves a prerecorded message on your answering machine, you can take them to small-claims court and get somewhere between $500 and $1500. Not bad for a day's work!
Incidentally, this is the same section that prohibits junk faxes. It can be pretty profitable to read the entire statute.
Different people's minds work in different ways. The FP fanatics have minds that happen to be in the minority.
If your mind works one way, FP seems "simple" and "natural." If your mind works another way, FP is convoluted and hard to understand. (That happens to describe most people.) And if your mind works a third way, somewhere in the middle, FP is just another technique that is useful in the right situation and inappropriate in others.
One problem is that the minority contingent has failed to recognize that they are unusual, and in their eagerness to convert others they have overstated the benefits of FP. Yes, anybody can learn to write simple functional programs. There is even evidence to suggest that beginning programming classes are best taught in a functional language. But FP is not a panacea, any more than COBOL was.
What worries me is that the suggested fix is also incorrect. When you are doing something as important as key generation, you shouldn't just ignore the return from read! You should check for a failed read and handle it appropriately (where the definition of "appropriately" depends strongly on the PGP code and perhaps a bit on the/dev/random code, neither of which I have the time to read at the moment, unfortunately).
Not exactly. The installer is also the way you upgrade. Given the way Linux advances, you have to install lots of times. Unfortunately, upgrades are one of the places SuSE isn't quite as strong as they might be (I keep a list of about 20 things I have to do every time upgrade, things like relinking/dev/mouse, selecting US paper sizes, and integrating my changes to/etc/files).
Ah, the oft-quoted "Those who can, do; those who can't, teach." Too bad it's a misinterpretation. The original intention was a reflection of the reality of aging: "Those who still can, do; those who no longer can, teach."
I am a college professor. I am certainly concerned about protecting my intellectual property rights; it is primarily for that reason that my course Web pages have restricted access even though I would prefer to have them be open.
Nevertheless, I have to wonder about the UCLA suit. As I said in another post, copyright law protects the expression of an idea, not the idea itself. At least in the classes I teach, I don't think the student notes are a very close copy of how I sometimes express myself. (I hope, anyway, that last week nobody wrote it down when I digressed from the subject by lying down on the floor and kicking and screaming!)
If I want to make money by selling class notes, I am certainly capable of creating such a collection. Since I choose not to, if one of my students wants to do the work, why shouldn't they profit?
The whole thing strikes me as a dog-in-the-manger attitude: "I don't have the energy to make extra money by providing you with really good notes written by the professor, so I don't want anybody else to get that money either." Sheesh.
As I recall, one of the requirements for a successful copyright lawsuit is economic harm. It's hard to see where the economic harm would arise, other than with respect to UCLA's own lecture notes (which they deny taking into consideration, and which weren't copied verbatim in any case).
You've almost got it right. There is no requirement in the law for a fixed form. Furthermore, your MLK example is bogus because there is a fixed form: the films of the speech.
Copyright law protects the expression of an idea, not the idea itself. In this distinction, copyrights differ from patents, trademarks, and trade secrets, all of which protect the idea itself.
Thus, for example, I can steal the ideas from "I Have a Dream" and use them in a speech of my own. But if I were to use MLK's exact words (or a substantial portion of them) I would be guilty of violating his copyright -- if his heirs chose to assert and enforce it.
I think that your professor's definition of "idiot" is rather narrow, and his definition of CS Ph.D.'s is even narrower.
For example, anybody who gets a Ph.D. in the area usually called "Systems" will have to write significant amounts of code. My own dissertation required around 45K lines of stuff. In contrast, I have a fellow professor who is a theorist, and she recently told me that she doesn't even need pencil and paper to do research -- except that she likes to doodle while she thinks! That doesn't make her incompetent at CS. She just knows different stuff than I do.
As to your prof, just because his code didn't compile hardly means he's incompetent. It just means he was too lazy to test it before he gave it to you.
Having defended people, now let me also say that a lot of CS profs have no industry experience, which means that their approach to writing software is not always in tune with what industry needs. That's why many managers consider a fresh graduate as a trainee. It's not that the new hires are stupid or ignorant, it's just that they still need to learn a lot of practical aspects of the stuff they learned in college. The degree isn't useless, though: without it, you wouldn't be ready to learn the practical stuff.
First, in fairness to CMU, I have to say that I've been to Pittsburgh and it has a bum rap. It's one of the prettiest cities in the U.S.
The people who say "get a real education in the foundations of CS" are right. Trade schools are short-term. A fundamental education will last you a lifetime.
If you want a really tough school that specializes in educating the smartest scientists and engineers in the country, you might consider Harvey Mudd College. We're expensive (though financial aid is available, like most places) and we're hard to get into and hard to get through. But if you can cut the mustard, I think we offer a better undergrad education than CMU, MIT, or Caltech. (If you can get into HMC, you can probably get into any of the other three, so it's your choice.)
Disclaimer: I'm on the faculty, so I might be the teensiest bit prejudiced.:-)
Just to correct a small error in the parent article: Coda was written by Jay Kistler as his doctoral dissertation under the supervision of Mahadev Satyanarayanan (commonly known as "Satya").
Peter Braam's contribution was that he ported Coda to Linux (it originally ran on BSDi or NetBSD; I forget which). This was a lot of work but FAR less than Kistler's contribution.
A ton of people have given some pretty good advice. As someone who went straight for a Master's the easy way, spent 15 years in industry, then got a Ph.D. and now teaches at a top undergraduate institution, here's my quick take and some pointers I think may be helpful:
The Top Four really are superb, but the people who say "choose based on field" are also right. If any of CMU, MIT, Berkeley, or Stanford cover your field and you can get in, move heaven and earth to go to one of them.
If the Top Four don't take you, try for a school that has several people working in the field you're interested in. Check out their recent publications and see if they're cool; if possible talk to them to find out whether you like them or they're assholes. Talk to their current grad students. Try for a school that has a reputation (easy measure: they consistently get papers into the top conference in the field). Avoid a school that has only one prof in your field: if you hate him/her, or if the research s/he's doing two years from now isn't fun, you're screwed.
An experienced, understanding advisor at your current school is invaluable.
Know thyself. Why do you want a graduate degree? The person who said "go straight to work" was partly right. An MS is quick and easy to get, and it will pay off in industry (lots of people are impressed). A Ph.D. is a very specialized degree, and not tremendously useful unless you want to go into research or academia. (Exception: in some consulting positions the prestige factor helps.)
It is very hard for most people to return to school after time outside. I'm not talking about forgetting how to study, I'm talking about having a life, kids, and car payments. Most people never try, and of those who try, most never finish.
A Master's usually takes two years. I did it in one under abnormal circumstances; I know a guy who took eleven (full-time!). A Ph.D. in CS usually takes from 4 to 7 years depending on the school and advisor. I know of a guy who did it in 3 (and regrets going so fast) and one who took 13.
When you're looking for a job after getting a Ph.D., many things matter. Some of the important ones are the quality of your dissertation, the number of publications you have, the name of your school, the names of your references, and the content of your reference letters. All of those are affected to some degree by your choice of school. Employers also care about you, of course (make sure your interview is great!), but the above items are harder to fix late in the game.
Early in your graduate career, it can be good to do internships at industrial research labs. This approach gives you good dissertation ideas, and also gives you a wider base to draw on when it's time to get reference letters.
Enough random advice. Here are some books and URLs:
Tomorrow's Professor: Preparing for Academic Careers in Science and Engineering, by Richard M. Reis. This book contains absolutely essential advice, starting with how to pick a graduate school and ending with advice on surviving your first year as a professor. If you are thinking about grad school, or in it, this book is a MUST! I only wish it had been written before the last year of my doctorate. Even so, it made a huge difference in my eventual success. I owe my current job to many people, but Dr. Reis is unquestionably one of them.
A Ph.D. is Not Enough: A Guide to Survival in Science, by Peter J. Feibelman. This book has some very realistic, sometimes cynical advice for prospective scientists.
How to be a Professor: Some Good Books is a Web site devoted to helping people adjust to academia. For a prospective grad student, it can also serve as an introduction to what to expect.
I'd hate to actually have them notice it, but last year when NSI renewed my domain name, they sent me their contract by e-mail. I modified it carefully (it's amazing what you can do by adding "not" in a few strategic places) and returned it to them. One of the clauses specified that if they accepted my money, they also accepted my version of the agreement.
The beautiful part is that they answered my mailback with a confirmatory message that quoted the contract in its entirety. That means that if it ever came to court (in my home state, as allowed by the contract they accepted), I could demonstrate that they received the contract. That puts them in a rather tough position: if they want their original e-mail contract enforced, they have to argue that e-mail contracts are legal. But I never agreed to their contract -- and they accepted mine!
IANAL, and I am certainly not stupid enough to actually force a court test. But if NSI ever decides to give me a hard time (not impossible, given the similarity of my UUCP-vintage domain name to that of a much larger Johnny-come-lately), I at least have some ammo. Heh heh.
If there is any lesson to learn from the Red Hat IPO, it is this: don't try to do geeks a favor. What a bunch of arrogant fools! First they get pissed because they wrote the code, and "all" Red Hat did was package, market, and support it. (If it's so easy, why didn't you get rich doing it?)
Then, when Red Hat has the generosity to invite them to share in the wealth that Red Hat built from a bunch of inconsistent and incompatible software, they don't even bother to learn the rules of the game before jumping in. I can't believe the number of people who've complained about getting surprised. Hey, I wasn't an IPO expert either, but I had the good sense to watch other IPOs in the last week to find out what the pattern was like.
But even that childishness isn't enough. Noooo, the big day comes and things don't go quite according to plan (i.e., your wet dreams). Do people swallow hard, say "Shucks, I had my hopes up," and get on with their life? Not a chance. Wild talk follows of suing E-trade (didn't read that contract you signed, did you?), complaining to the SEC (because E-trade followed their rules!), and boycotting E-trade because alerts didn't arrive by e-mail (didn't read that disclaimer either, did we?).
The funniest (or saddest) thing is that Red Hat and E-trade are busting their butts to make sure we make a couple of bucks, even if it's at their expense. The e-mail last night came in at midnight EDT. Tonight's e-mail, informing me that I'll get my requested shares within a day of the confirmation I sent this morning, was sent at almost 10 PM EDT. (And BTW, you have until 3 PM EDT Friday to confirm. You can wait to see what the stock does and then take the plunge. Talk about a gift!)
Frankly, if I were still in the business world I'd be sorely tempted to make a list of all you self-centered cretins so that I could avoid ever having to deal with you. You don't have the faintest idea of how the world works, and rather than trouble your precious selves to learn, you fly off the handle at the first minor glitch and blame everybody else for your own ignorance.
Me, I'm pleased that I didn't buy shares at $14 and see them immediately drop to $3. I could have afforded it, but it would have been a disappointment. Instead, I am guaranteed that I have lost nothing, and I have an excellent shot at making a threefold after-tax profit. Every day on the stock market should be so good.
OK, I just got off the phone with an E-trade broker (12:05 PM PDT). He confirmed what everybody else has been saying: affinity shares haven't been allocated yet. But I thought to ask a more interesting question, and he answered it:
Q: How many people have expressed interest in the affinity program?
A: Red Hat sent out 8000 e-mails. 12K E-trade customers have expressed interest in the IPO.
What does this mean to YOU? Red Hat allocated 800K shares and sent out 8K e-mails. E-trade allocates 100 shares each, then parcels out the leftovers. That means that affinity program members are guaranteed to get at least 100 shares each. You will get them at the initial offering price of $14, regardless of what they're selling for right now (and anybody who watches IPOs can also guarantee you that, while tomorrow's price may not be as high as today's peak, it's not going to be $9 unless the Red Hat prez pulls an Eagle Computer).
So stop whining, kiddies.
Oh, P.S. Never heard of Eagle? 10 or 20 years ago they celebrated a super-successful IPO. The president had a lot of champagne, got into his shiny new sports car, and drove into a tree. The company didn't do too well after that.:-(
Slashdot Mirror
My opinion is that you should fight it tooth and nail. The "work for hire" doctrine is intended for situations where an employer gives you specific direction: "I want you to build an airplane that goes 550 knots or better and carries between 400 and 500 passengers." It isn't intended to apply to situations where they say "Go and think of cool things, but if you come up with anything commercially viable, I want a cut because I was buying your pizza."
You might be able to sell such an idea to dentists, because sadly, a lot of dentists aren't all that bright. But any CS student would be nuts to buy into such an astoundingly greedy scheme. And any CS prof -- or engineering, or physics, or humanities -- should be burned at the stake for helping to promote it as long as there is still an alternative.
You can count on it that the only reason this thing is flying even as far as it has gone is that Vicious Source Technologies has paid NYU a huge bribe. Sure, it's called a "marketing agreement", but you know that it boils down to money changing hands.
The NYU dental school is a blight on the face of academia. Their next contract will probably be with a huge candy company.
Duh.
One form of the 2010 machine will be a tiny watch or pendant running Linux 4.8.16. But another will be a clunky tower, just like today, because the bigger the package, the more you can put inside. I doubt there'll be a place for their inconvenient, unstackable design.
Technologically, maybe it won't even have a hard disk. Maybe it'll use optics, maybe something else. The only thing I care about is that it'll be big (storage-wise) and fast.
As to the "swoopy" design, just check out all those 50's-era predictions of the future. Yeah, it'll look like a frisbee -- and no doubt I'll be wearing a silvery one-piece jumpsuit.
You might as well argue that an Indy race car isn't an automobile because it doesn't have a cup holder.
"Operating System" is a technical term in computer science. It has a precise definition. Like most technical terms, you can't arbitrarily decide to change the definition (if you plan to communicate effectively). It's especially ridiculous to try to do so as part of an argument that depends on drawing definitional lines.
Load balancing? Easy to write, hard to make work well. You need to compare the cost of migration to the benefits of balancing, and you need to make decisions based on partial and outdated information. Many early systems thrashed because everybody would migrate to the idle processor, which then became overloaded, so everybody migrated somewhere else, etc.
Speaking of migration, it's a mess. The only system I know of that implemented migration fully was Locus, out of UCLA. The trouble is that whenever a process has a dependency on or a hook into its environment, that connection must be migrated too. Open files, working directory, sockets, controlling tty, signals, process parent/child relationships, and many more details must be handled. Not fun, and the benefits turned out to be mostly minor (though I do recall writing a cool version of "find" that migrated itself to the machine that stored the current subtree as it ran).
The issue of supporting distributed applications is generally considered to be separate from writing a truly distributed OS. Most of what a distributed application needs can be provided by a good communications library. To some extent, we're still learning exactly what such a library should have. What about SETI@home is specialized to it, and what's universal? I don't think we've completely figured it out.
The following is a non-exhaustive list of major concerns and design issues that must be addressed in a distributed OS. We have fairly good solutions to some, but most have not yet been solved:
Finally, I should note that the list of projects at U of Arizona might appear to be complete, but it omits a lot of important projects. Four that jump to my mind are Locus and Ficus from UCLA (though the latter is more of a distributed filesystem than an OS), Coda from CMU (again a DFS, rather well-known to Linux folks), and of course the extremely important Network of Workstations work out of UC Berkeley, which led to Inktomi and Hotbot.
(3) The term ''telephone solicitation'' means the initiation of a telephone call or message for the purpose of encouraging the purchase or rental of, or investment in, property, goods, or services, which is transmitted to any person, [unless based on a prior relationship]
It shall be unlawful for any person within the United States ... (B) to initiate any telephone call to any residential telephone line using an artificial or prerecorded voice to deliver a message without the prior express consent of the called party, unless the call is initiated for emergency purposes or is exempted by rule or order by the Commission under paragraph (2)(B);
(3) Private right of action A person or entity may, if otherwise permitted by the laws or rules of court of a State, bring in an appropriate court of that State - (A) an action based on a violation of this subsection or the regulations prescribed under this subsection to enjoin such violation, (B) an action to recover for actual monetary loss from such a violation, or to receive $500 in damages for each such violation, whichever is greater, [emphasis added] or (C) both such actions. If the court finds that the defendant willfully or knowingly violated this subsection or the regulations prescribed under this subsection, the court may, in its discretion, increase the amount of the award to an amount equal to not more than 3 times the amount available under subparagraph (B) of this paragraph.
In other words, if ABC calls you and either (a) hangs up without talking to you or (b) leaves a prerecorded message on your answering machine, you can take them to small-claims court and get somewhere between $500 and $1500. Not bad for a day's work!
Incidentally, this is the same section that prohibits junk faxes. It can be pretty profitable to read the entire statute.
If your mind works one way, FP seems "simple" and "natural." If your mind works another way, FP is convoluted and hard to understand. (That happens to describe most people.) And if your mind works a third way, somewhere in the middle, FP is just another technique that is useful in the right situation and inappropriate in others.
One problem is that the minority contingent has failed to recognize that they are unusual, and in their eagerness to convert others they have overstated the benefits of FP. Yes, anybody can learn to write simple functional programs. There is even evidence to suggest that beginning programming classes are best taught in a functional language. But FP is not a panacea, any more than COBOL was.
What worries me is that the suggested fix is also incorrect. When you are doing something as important as key generation, you shouldn't just ignore the return from read! You should check for a failed read and handle it appropriately (where the definition of "appropriately" depends strongly on the PGP code and perhaps a bit on the /dev/random code, neither of which I have the time to read at the moment, unfortunately).
Not exactly. The installer is also the way you upgrade. Given the way Linux advances, you have to install lots of times. Unfortunately, upgrades are one of the places SuSE isn't quite as strong as they might be (I keep a list of about 20 things I have to do every time upgrade, things like relinking /dev/mouse, selecting US paper sizes, and integrating my changes to /etc /files).
Ah, the oft-quoted "Those who can, do; those who can't, teach." Too bad it's a misinterpretation. The original intention was a reflection of the reality of aging: "Those who still can, do; those who no longer can, teach."
Nevertheless, I have to wonder about the UCLA suit. As I said in another post, copyright law protects the expression of an idea, not the idea itself. At least in the classes I teach, I don't think the student notes are a very close copy of how I sometimes express myself. (I hope, anyway, that last week nobody wrote it down when I digressed from the subject by lying down on the floor and kicking and screaming!)
If I want to make money by selling class notes, I am certainly capable of creating such a collection. Since I choose not to, if one of my students wants to do the work, why shouldn't they profit?
The whole thing strikes me as a dog-in-the-manger attitude: "I don't have the energy to make extra money by providing you with really good notes written by the professor, so I don't want anybody else to get that money either." Sheesh.
As I recall, one of the requirements for a successful copyright lawsuit is economic harm. It's hard to see where the economic harm would arise, other than with respect to UCLA's own lecture notes (which they deny taking into consideration, and which weren't copied verbatim in any case).
Copyright law protects the expression of an idea, not the idea itself. In this distinction, copyrights differ from patents, trademarks, and trade secrets, all of which protect the idea itself.
Thus, for example, I can steal the ideas from "I Have a Dream" and use them in a speech of my own. But if I were to use MLK's exact words (or a substantial portion of them) I would be guilty of violating his copyright -- if his heirs chose to assert and enforce it.
For example, anybody who gets a Ph.D. in the area usually called "Systems" will have to write significant amounts of code. My own dissertation required around 45K lines of stuff. In contrast, I have a fellow professor who is a theorist, and she recently told me that she doesn't even need pencil and paper to do research -- except that she likes to doodle while she thinks! That doesn't make her incompetent at CS. She just knows different stuff than I do.
As to your prof, just because his code didn't compile hardly means he's incompetent. It just means he was too lazy to test it before he gave it to you.
Having defended people, now let me also say that a lot of CS profs have no industry experience, which means that their approach to writing software is not always in tune with what industry needs. That's why many managers consider a fresh graduate as a trainee. It's not that the new hires are stupid or ignorant, it's just that they still need to learn a lot of practical aspects of the stuff they learned in college. The degree isn't useless, though: without it, you wouldn't be ready to learn the practical stuff.
The people who say "get a real education in the foundations of CS" are right. Trade schools are short-term. A fundamental education will last you a lifetime.
If you want a really tough school that specializes in educating the smartest scientists and engineers in the country, you might consider Harvey Mudd College. We're expensive (though financial aid is available, like most places) and we're hard to get into and hard to get through. But if you can cut the mustard, I think we offer a better undergrad education than CMU, MIT, or Caltech. (If you can get into HMC, you can probably get into any of the other three, so it's your choice.)
Disclaimer: I'm on the faculty, so I might be the teensiest bit prejudiced. :-)
Peter Braam's contribution was that he ported Coda to Linux (it originally ran on BSDi or NetBSD; I forget which). This was a lot of work but FAR less than Kistler's contribution.
Enough random advice. Here are some books and URLs:
As usual, I've run on and on, so I'll close with a wish for your success and one last thought: grad school was the most fun thing I ever did!
The beautiful part is that they answered my mailback with a confirmatory message that quoted the contract in its entirety. That means that if it ever came to court (in my home state, as allowed by the contract they accepted), I could demonstrate that they received the contract. That puts them in a rather tough position: if they want their original e-mail contract enforced, they have to argue that e-mail contracts are legal. But I never agreed to their contract -- and they accepted mine!
IANAL, and I am certainly not stupid enough to actually force a court test. But if NSI ever decides to give me a hard time (not impossible, given the similarity of my UUCP-vintage domain name to that of a much larger Johnny-come-lately), I at least have some ammo. Heh heh.
Then, when Red Hat has the generosity to invite them to share in the wealth that Red Hat built from a bunch of inconsistent and incompatible software, they don't even bother to learn the rules of the game before jumping in. I can't believe the number of people who've complained about getting surprised. Hey, I wasn't an IPO expert either, but I had the good sense to watch other IPOs in the last week to find out what the pattern was like.
But even that childishness isn't enough. Noooo, the big day comes and things don't go quite according to plan (i.e., your wet dreams). Do people swallow hard, say "Shucks, I had my hopes up," and get on with their life? Not a chance. Wild talk follows of suing E-trade (didn't read that contract you signed, did you?), complaining to the SEC (because E-trade followed their rules!), and boycotting E-trade because alerts didn't arrive by e-mail (didn't read that disclaimer either, did we?).
The funniest (or saddest) thing is that Red Hat and E-trade are busting their butts to make sure we make a couple of bucks, even if it's at their expense. The e-mail last night came in at midnight EDT. Tonight's e-mail, informing me that I'll get my requested shares within a day of the confirmation I sent this morning, was sent at almost 10 PM EDT. (And BTW, you have until 3 PM EDT Friday to confirm. You can wait to see what the stock does and then take the plunge. Talk about a gift!)
Frankly, if I were still in the business world I'd be sorely tempted to make a list of all you self-centered cretins so that I could avoid ever having to deal with you. You don't have the faintest idea of how the world works, and rather than trouble your precious selves to learn, you fly off the handle at the first minor glitch and blame everybody else for your own ignorance.
Me, I'm pleased that I didn't buy shares at $14 and see them immediately drop to $3. I could have afforded it, but it would have been a disappointment. Instead, I am guaranteed that I have lost nothing, and I have an excellent shot at making a threefold after-tax profit. Every day on the stock market should be so good.
Sheesh.
What does this mean to YOU? Red Hat allocated 800K shares and sent out 8K e-mails. E-trade allocates 100 shares each, then parcels out the leftovers. That means that affinity program members are guaranteed to get at least 100 shares each. You will get them at the initial offering price of $14, regardless of what they're selling for right now (and anybody who watches IPOs can also guarantee you that, while tomorrow's price may not be as high as today's peak, it's not going to be $9 unless the Red Hat prez pulls an Eagle Computer).
So stop whining, kiddies.
Oh, P.S. Never heard of Eagle? 10 or 20 years ago they celebrated a super-successful IPO. The president had a lot of champagne, got into his shiny new sports car, and drove into a tree. The company didn't do too well after that. :-(