1) You have the right to expect payment for software you have written.
2) You have the right to set whatever payment you want for the software you have written- if you don't like it (or think I'm asking too much), *don't use my software*.
3) Using someone's software without paying for it is *piracy*.
So far, I don't think I've said anything so radical that Alchin would disagree with me. But here comes the twist. I define the GPL as payment in kind. The cost of using my software is that I get to use *yours*. The cost of being able to modify my code is that I get to modify yours. Quid pro quo.
If you don't like this deal, DON'T USE GPL'D CODE.
Here's the punchline. By advocating that you should be able to use GPL'd source code without paying for it in kind, that is *piracy*.
This would be correct, except for one minor little problem- precedent. This case, and others like it, *will* matter when it's our turn be sued for being programmers.
Guess what? Climbing on top of a 50 story high fuel-air bomb and lighting the fuse is *risky*. Gee, who'd a thunk it? What I find amazing is that so *few* fatalities have occurred in the American space program- what, ten deaths in fifty years? Compare that to explorations of the past- one of Columbus' three ships didn't make it back, and a vast majority of the people who sailed with Magellan didn't make it back (including Magellan!).
NASA is being set up to fail. If everything goes right then we cut their budget because no one cares anymore. If things go wrong and people die (or even if missions fail) then we cut their budget because it's too risky. End result: we cut their budget.
Why? Because NASA's defenders are, to put it bluntly, politically naive. They're engineers and scientists, and how you win an argument with an engineer or scientist is you get your facts and logic right. When presented with the facts and logic, the scientist or engineer goes "Oh- you're right."
Well, we're not dealing with scientists or engineers here, we're dealing with politicians. And I'm not sure how many people may have noticed, but neither facts nor logic have much weight in political debate. What counts is money and votes.
The first time a congress criter looses his seat in whole or in part because he voted against funding for NASA, and thus the pro-NASA forces contributed large amounts of money to and voted for his opponent- then, and ONLY then, will NASA get the budget it deserves.
Consider using TeX/LaTeX, postscript, or an XML/SGML variant, like DocBook or HTML.
Basically, what you want is a format the fits the following criteria:
1) The original text can be easily gotten out of the format. This way even if the programs that read the file go the way of the dodo, future programs could still recover the data.
2) The specification is fully open and documented, and preferrably stable and mature.
3) At least one open-source program handles displaying/converting the format. I would recommend storing a copy of this program in the same place as the standards themselves- including shipping source with standards CDs.
You've gotten over the hardest part already- you've realized you have a problem.
The problem is that the watermark has to survive obvious variances in encoding- for example, compressing into an MP3 or OOG file. Or being piped out a speaker into a D/A and re-recorded. In other words, the encoding *has* to have and audible effect. One of the first things MP3 encoders do is throw away all non-audible data- and there goes your watermark.
They need three states to be detectable- "I'm a (legal) uncopied watermark", "I'm an (illegal) copied watermark", and "I'm not watermarked". The third is necessary if they are not insisting that all non-watermarked media (i.e. all songs and recordings already in people's hands) cannot be played.
The problem is that all steganography (which watermarking is just a practical application of) depends upon it's existance being unsuspected. If I even *suspect* that steganography is being used, I can replace the steganographic data channels with data of my own.
Take the classic steganography example- transmitting text hidden within a GIF, where each bit of text replaces the low-order bit of a single pixel. If I even suspect that this is occuring, I can go through and change each low order bit to 0, or to a random value. This is the equivelent of jamming a radio frequency by broadcasting noise. Goodby steganographic channels.
Or, to take your example, if they used inaudible phase shifts or volume changes, I just go through and eliminate all inaudible components of the music, and add my own (random) inaudible phase shifts and volume changes.
So all I would need to do in this case is replace the steganographic channels which encode "I am a watermark" with data that says "I am not watermarked" and everything is gravy.
Notice that both "transmissions" on steganographic channels changes the data. The picture is not the same. The de-watermarked version *by definition* will be different from the watermarked version. And the watermarked version will also be different from the original, pre-watermark version. With some cleverness you could make the de-watermarking processes end up closer to the original than the watermarked version (instead of shoving in random data, you guess what you think the original data might have been before watermarking). But this is irrelevent, as they are measuring difference from the watermarked version, not the original. If adding the watermarking is audible (as it almost certainly has to be, see above), then removing it- even removing it perfectly and returning the true original recording- fails the test because it is audibly different from the watermarked version.
The other alternative is to combine the categories of "I am an (illegal) copied watermark" and "I am not watermarked"- making all existing (non-watermarked) media instantly obsolete. Note- I wouldn't put this past them. Simply purchasing a legal copy of IP does not imply the legal right to play back that IP- notice that you cannot play a legal (non-pirated) DVD on a legal DVD player if the two come from different zones. And simply because you own the White Albulm and can play it *now* does not necessarily mean you will be able to do it ten years from now. What, did you think you had *rights* or something?
If you find yourself backed into a corner and installing an Exchange server, buy a backup program that talks to Exchange and can back up the Exchange database live. Do not take no for an answer.
Exchange keeps everyone's mail messages in one huge database in a single file, which it then locks everyone else out of. And I mean *all* mail messages, unread and saved alike. So if you don't have a backup program which works with Exchange, to back up this file you have to take the server down (manually, no scripting here), back the file up, and bring the server back up. During the weekend or after hours, naturally- people don't like it when they don't have access to email during normal buisness hours.
Not backing the mail up is not an option. A single bad block can corrupt the whole mail DB, and trash everyone's mail. And we all keep mail around for one reason or another- often critical information is kept in the form of saved mail messages- all of which can vanish because of a single bad block.
This isn't Microsoft bashing. I've had this happen to a company I was working at (fortunately, I wasn't responsible for the mail server at that point). Save yourself the pain.
The one big file also accounts for the scalability problems of Exchange. Remember, this is running (by definition) on a 32-bit x86 machine, which gives you a maximum process size of about 3 gig. Mapping files larger than this so you can treat them as a data structure is impossible. This is why, as of a year or so ago, Exchange couldn't handle more than about 400 people per machine. They may have fixed this since then (I doubt it, but anything is possible). Don't take assurances- ask to talk to someone who is running 1000 people on a machine before simply beleiving that it can be done.
Oh, today is completely different. In the 1960's and 70's (when Brooks wrote MMM) the theory was "If one woman can have a baby in nine months, nine women can have a baby in one month." Today's theory is "If one woman can have a baby in nine months in normal time, on woman can have nine babies in one month on internet time (she'll just have to put in some overtime)." (Ever notice how it's *on* internet time, not *in* internet time? That's because you have to be on something to agree to that sort of schedule.)
1) If you don't modify the source code, then obviously you don't have anything you need to distribute. If, for example, you use the Linux kernel intact (i.e. the kernel would still run just happily without your code), then nothing needs to be distributed.
2) So long as the source code is publically available and under the GPL, the deal is satisified. Take an old P-90 box with a few hundred meg of HD space, throw Linux and an anonymous FTP server up, put code on server, forget to publish the fact that the software exists. Nothing in the license requires a Freshmeat announcement, or postings to the correct newsgroups or maillists (although this is encouraged!).
3) I thought the GPL explicitly dealt with content editing. You can edit proprietary documents with Emacs, compile proprietary code with gcc, and store proprietary information in MySQL. Just like you can write public domain documents in Word, compile GPL code with Visual C++, and store public information in Oracle.
4) There are gray areas still- just not the ones you list. Consider a GPL'd Java program- can I take pre-compiled.class files out of a GPL program, link them with my proprietary code (but neither recompile nor modify the GPL code!) and keep my code proprietary? My suggestion: avoid the gray areas. If you're not sure, and don't want to abide by the GPL, don't use GPL'd code in questionable ways.
5) There is a lot of concern, and rightfully so, over this legal challenge. But a license which isn't defended is tantamount to no license whatsoever.
6) Do you think your average contract lawyer can write good code? Then why do you think that _you_ can write a contract that will hold up in a court of law if you're not a contract lawyer? The one huge advantage the BSD license has over the GPL license IMHO is that it has already stood up to the worst a large corporation (AT&T) could do. But of even greater concern to me than the future of the GPL is the horde of programmer-licenses that have shown up. How many of them have even been run past a contract lawyer, let alone a court of law? How many of them are just the pseudo-legalesse of a programmer way out of his depth and not knowing it?
The more dangerous legal challenge to open source may not be to the GPL, but to all of the programmer-licenses out there. But what of Apache or Perl? Perl's "pick your license" stunt makes it (mind you, IANAL) seem more vulnerable- at best, any action which is legal under either license is legal (i.e. the set of restricted behaviors is the intersection of the sets of restricted behaviours of the two licenses).
One peice of logic I have to very strongly disagree with. Comparing Microsoft in 2000 to Microsoft in 1990 is completely bogus. Try comparing Windows, in either 2000 or 1990, to Unix in 1990. Microsoft managed to "innovate" from a 1950's era OS theory-wise up into the mid-80's. Try again.
Mr. Pike also doesn't seem to like backward compatibility, either- either through protocols or through API interfaces. Maybe it'd be nice to throw everything out and start from scratch- but there is a huge cost to this as well. One could argue that backwards compatibility is the difference between a theoretical success and a comercial one. This isn't to say that theoretical successes aren't important, just that they don't automatically turn into commercial successes.
I do agree that OS research is pretty much dead, but not because it's been killed by the horrid evil commercial companies, but because the problems have been _solved_. It's not the only one, either- data base design, numerical analysis, parsing and lexical analysis, and fundamental algorithms are also pretty much solved problems. Hey, haven't seen a sorting algorithm in a couple of decades- I wonder where all the innovation has gone? CPUs have gone from 1MHz to 1GHz, why haven't sorting algorithms gone from O(n * log(n)) to O(n), or even O(log(n))?
Math disciplines die too. The (IIRC) fifth international conference on Information theory back in 50's (you remember, Claude Shannon and that gang) was canceled because no one really had anything new to say. The problem got solved, move on to a new problem.
We're seeing this in OS theory as well. Remember the classic Tannenbaum vr.s Torvalds debate? What Tannenbaum missed was that, although theoretically better than monolithic kernels, in practice microkernels didn't have any signifigant advantage (or, rather, had disadvantages to match their advantages, and the successfull OSs would be "middle of the road" OSs with some features of both). Microkernels were the last gasp of the "Real Man" OS Theorists. It fizzled.
Rather than viewing this as a failure of research, I'd consider this a success. Congratulations, guys, you've solved the problem. Now go on and start trying to solve another one.
Start them on object oriented from the get-go. It's syntax is also good at catching "newbie errors".
What I _wouldn't_ worry about is teaching them a "toy language". Of course they'll learn other languages. Do NOT start them on C or C++. Yes, those are languages "professionals" use. So? You don't learn to drive in a formula-1 race car or an eighteen wheeled semitruck, despite the fact that is what the "professionals" use. You don't learn to fly in an F-16 jet fighter. You learn to drive in a Geo Metro with an automatic (or equivelent), and you learn to fly in a piper cub.
It's worse than that: with full knowledge of the problems with gets(), Strousup gave us istream::operator(char *) with _exactly_ the same problem. Allowing a new generation of programmers to program their buffer overruns in an object oriented language.
Actually, for the market they're aiming the Xeons at, more cache is better. Server-class Sparcs often have 8 meg of cache per CPU. RDBMs are notoriously cache-hungry. By having Intel put the 2M cache on-die, they ensure that the Sparc has nothing to worry about from the Xeon.
The 32-bit vr.s 64-bit is also a big problem. To balance CPU/memory/disk bottlenecks, you generally want about 1 gig of memory per CPU- so finding 12-16 gig of memory in a machine isn't unusual. And you want one process- the RDBM- to use _all_ of it (or at least most of it).
According to the Judge in the DeCSS case, any device which can be used to circumvent copyprotection is illegal according to DMCA- even if circumventing copy protection is not it's primary use, right? Now we have Microsoft claiming that there were discussions about how to use winzip to bypass it's copy protections and view the content without agreeing to the license, right?
So doesn't this put winzip in the same category as DeCSS- a tool which, despite it not being it's primary purpose, can be used to violate copy protections?
This doesn't just touch physics journals- although the physicists are more likely to be rational about the issue than the record or movie industries. But no debate about copyright or intellectual ownership I have seen to date has looked at the long-term issues. And by long-term, I don't just mean years or decades, I mean thousands of years.
Everyone decries the burning of the library of Alexandia. It's destruction has greatly impoversihed us today, it denied us access to the thoughts and works of the people who wrote those books. The burning of the library of Alexandria was a lobotimization of human culture.
But if Alexandria was a lobotomization, today's IP rules are senility. This is because, for short-term gain, the ignore the fact that the only way information survives long-term is if it's _copied_. No media lasts forever. Pop quiz: how many books today are older than 200 years old? Euclid's "Elements" survives today because it was copied, and copied again. The image of cloistered monks painfully hand-copying books survives to this day.
We need to address the concerns not only of the artists, writers, creators, and IP corporations, not only of the IP consumers, but also the concerns of our decendents a thousand years from now. Otherwise, we risk being a culture with no history, and therefor no future.
Before you answer "none!", remember that this post- and all the posts made about the Hellmouth, Microsoft, Linux, and whatever- are being hosted on machines paid for and maintained by Andover, and distributed over bandwidth paid for by Andover. We recognize that a book publisher has some rights over the works being published- why not Andover?
The more I think about it, the more I think "Intellectual Property" is an oxymoron.
Attempting to base modern society off of 18th century pre-industrial laws is like _so_ dated it's carbon dated! This is the new economy, baby- with the new rules to match! Talking about fusty old documents like that is even funnier than trying to apply 19th century antitrust laws to modern info e-dot-commerce company! Like, get real!
Patents are the modern, high tech way to deal with monopolies- make everyone a monopoly! For example, I myself have patented the word "the"- and am rolling out plans to charge a $3 licensing fee for every use of the word the. You may even have heard about my forth comming IPO- the dot com. "It's _the_ place to invest!" It'll be the biggest IPO to hit since Redhat's prehistoric IPO! It'll make billions! It'll make Sagans! (Billyuns and Billyuns)
And any insinuation that I, rightfull patent holder of the word the, might not be in the best interest of the society as a whole, is obviously instigating a communist plot to topple the markets, bankrupt millions of daytraders, encourage the illegal international piracy of the word the, cast the whole of civilization down into the depths of dispare and poverty and maybe even rend the fabric of this most noble country called The(tm) United States of America. For beautiful and sacred lies, for never ending gain... Opps, sorry, little flash back there.
Where was I? Oh, yeah, Natalie Portman- Naked and Petrified...
The evidence says yes. There was an attempt to post a trojan in open source recently (I lost the URL- help, anyone?). It lasted _ten_ _hours_ before it was discovered. And this question applies doubly so to closed source- as not just anyone can read it, only employees can read it. And most companies that I know of don't implement any sort of code review, so often a peice of code is only ever read by one person.
2) Are they qualified to review the code? Some yes, some no. Once again, the exact same question can be applied to close source. Opps, most closed source isn't reviewed, even by unqualified programmers!
3) It's easy to hide vulnerabilities in complex, poorly documented source code. This I'd agree with- especially _unintentional_ vulnerabilities. On the other hand, it's also hard to _maintain_ such code- and in the open source world, over time it tends to get reimplemented. Sendmail worries you? Try using smail or qmail instead. And, if anything, complex, poorly documented source code is more likely in closed source projects where the assumption that only the original writter will ever see the code, and as they already understand it, comments and simplicitly are optional. Besides, writting comments and refactoring code takes time, and I have a deadline this week...
4) There is no strong gaurentee that source code and binaries have any relationship. Ah yes, Ken Thompson's paper. Thompson's paper assumes only one compiler, ever. You always compile gcc with only gcc- never Sun's cc, or IBM's xlc. It also assumes that any version of the compiler will recognize any other version of the compiler- so gcc 1.0 would recognize the source code to gcc 2.4, AND be able to insert the back door correctly into the produced binary! It'd also have to recognize the source code to tools like objdump and gdb as well, and insert the proper back doors into _them_ as well. I knew Ken Thompson was legendary- but this defies the imagination.
And, once again, there's no evidence of this on the closed source world either. Prove to me that Visual C++ isn't inserting back doors into Windows...
5) Open source makes it easy for the bad guys to find the vulnerabilities.
I was wondering when this chestnut would show up. The implicit assumption here is that the bad guys can't disassemble code- an assumption proveably false. There was a famous quote an IRA terrorist reportedly once said to Prime Minister Thatcher once- "We only have to be lucky once. You have to be lucky all the time." Security analysts face the same problem- the crackers only have to find _one_ vulnerability, while the security people have to find _all_ of them. You're not making the cracker's lives much difficult, but you're making the white hat's lives all but impossible.
Open source is not a security silver bullet- and I don't know of anyone outside a few anonymous cowards who claims that. Open source _is_ better than closed source for security. No ifs, ands, or buts.
Re:BOTTOM 10 pickup lines at Calculusgirls.com
on
80 Proof Quickies
·
· Score: 2
Bodily functions that are one-to-one and onto are normal, so long as they are discrete and not continuous.
No- he's right. Real programmers don't use IDEs. There hasn't been an IDE yet that did string handling right in FORTRAN.
_Intelligent_ programmers use IDEs- but only because they're convient. They understand the code the IDEs produce, and could write it themselves if they took the time. In that sense, IDEs are no different than any other code generators- lex and yacc, for example.
But an IDE is no replacement for skill and understanding.
Congratulations, Bruce- you've just lost all my respect. Which is saying something- I used to be a fan.
Where do you think all that gee-whiz technology you write about comes from? The computers, the materials science, etc. Guess what: lots of it comes from the space program.
The other really intelligent thing Perl does it is uses native libraries. For example, if you use a regular expression in Perl, that's one instruction in the virtual machine- which calls a native C routine to actually do the regular expression. Most of your time in a Perl program is not spent in the virtual machine, it's spent in these optimized native routines.
This is one problem Java has for performance- since they wrote most of the libraries in Java, you are spending most of your time in the virtual machine.
Slashdot Mirror
First some assumptions:
1) You have the right to expect payment for software you have written.
2) You have the right to set whatever payment you want for the software you have written- if you don't like it (or think I'm asking too much), *don't use my software*.
3) Using someone's software without paying for it is *piracy*.
So far, I don't think I've said anything so radical that Alchin would disagree with me. But here comes the twist. I define the GPL as payment in kind. The cost of using my software is that I get to use *yours*. The cost of being able to modify my code is that I get to modify yours. Quid pro quo.
If you don't like this deal, DON'T USE GPL'D CODE.
Here's the punchline. By advocating that you should be able to use GPL'd source code without paying for it in kind, that is *piracy*.
This would be correct, except for one minor little problem- precedent. This case, and others like it, *will* matter when it's our turn be sued for being programmers.
Guess what? Climbing on top of a 50 story high fuel-air bomb and lighting the fuse is *risky*. Gee, who'd a thunk it? What I find amazing is that so *few* fatalities have occurred in the American space program- what, ten deaths in fifty years? Compare that to explorations of the past- one of Columbus' three ships didn't make it back, and a vast majority of the people who sailed with Magellan didn't make it back (including Magellan!).
NASA is being set up to fail. If everything goes right then we cut their budget because no one cares anymore. If things go wrong and people die (or even if missions fail) then we cut their budget because it's too risky. End result: we cut their budget.
Why? Because NASA's defenders are, to put it bluntly, politically naive. They're engineers and scientists, and how you win an argument with an engineer or scientist is you get your facts and logic right. When presented with the facts and logic, the scientist or engineer goes "Oh- you're right."
Well, we're not dealing with scientists or engineers here, we're dealing with politicians. And I'm not sure how many people may have noticed, but neither facts nor logic have much weight in political debate. What counts is money and votes.
The first time a congress criter looses his seat in whole or in part because he voted against funding for NASA, and thus the pro-NASA forces contributed large amounts of money to and voted for his opponent- then, and ONLY then, will NASA get the budget it deserves.
It's the only place safe from becoming a victim of American foriegn policy.
Brian
Consider using TeX/LaTeX, postscript, or an XML/SGML variant, like DocBook or HTML.
Basically, what you want is a format the fits the following criteria:
1) The original text can be easily gotten out of the format. This way even if the programs that read the file go the way of the dodo, future programs could still recover the data.
2) The specification is fully open and documented, and preferrably stable and mature.
3) At least one open-source program handles displaying/converting the format. I would recommend storing a copy of this program in the same place as the standards themselves- including shipping source with standards CDs.
You've gotten over the hardest part already- you've realized you have a problem.
Brian
The problem is that the watermark has to survive obvious variances in encoding- for example, compressing into an MP3 or OOG file. Or being piped out a speaker into a D/A and re-recorded. In other words, the encoding *has* to have and audible effect. One of the first things MP3 encoders do is throw away all non-audible data- and there goes your watermark.
They need three states to be detectable- "I'm a (legal) uncopied watermark", "I'm an (illegal) copied watermark", and "I'm not watermarked". The third is necessary if they are not insisting that all non-watermarked media (i.e. all songs and recordings already in people's hands) cannot be played.
The problem is that all steganography (which watermarking is just a practical application of) depends upon it's existance being unsuspected. If I even *suspect* that steganography is being used, I can replace the steganographic data channels with data of my own.
Take the classic steganography example- transmitting text hidden within a GIF, where each bit of text replaces the low-order bit of a single pixel. If I even suspect that this is occuring, I can go through and change each low order bit to 0, or to a random value. This is the equivelent of jamming a radio frequency by broadcasting noise. Goodby steganographic channels.
Or, to take your example, if they used inaudible phase shifts or volume changes, I just go through and eliminate all inaudible components of the music, and add my own (random) inaudible phase shifts and volume changes.
So all I would need to do in this case is replace the steganographic channels which encode "I am a watermark" with data that says "I am not watermarked" and everything is gravy.
Notice that both "transmissions" on steganographic channels changes the data. The picture is not the same. The de-watermarked version *by definition* will be different from the watermarked version. And the watermarked version will also be different from the original, pre-watermark version. With some cleverness you could make the de-watermarking processes end up closer to the original than the watermarked version (instead of shoving in random data, you guess what you think the original data might have been before watermarking). But this is irrelevent, as they are measuring difference from the watermarked version, not the original. If adding the watermarking is audible (as it almost certainly has to be, see above), then removing it- even removing it perfectly and returning the true original recording- fails the test because it is audibly different from the watermarked version.
The other alternative is to combine the categories of "I am an (illegal) copied watermark" and "I am not watermarked"- making all existing (non-watermarked) media instantly obsolete. Note- I wouldn't put this past them. Simply purchasing a legal copy of IP does not imply the legal right to play back that IP- notice that you cannot play a legal (non-pirated) DVD on a legal DVD player if the two come from different zones. And simply because you own the White Albulm and can play it *now* does not necessarily mean you will be able to do it ten years from now. What, did you think you had *rights* or something?
Brian
If you find yourself backed into a corner and installing an Exchange server, buy a backup program that talks to Exchange and can back up the Exchange database live. Do not take no for an answer.
Exchange keeps everyone's mail messages in one huge database in a single file, which it then locks everyone else out of. And I mean *all* mail messages, unread and saved alike. So if you don't have a backup program which works with Exchange, to back up this file you have to take the server down (manually, no scripting here), back the file up, and bring the server back up. During the weekend or after hours, naturally- people don't like it when they don't have access to email during normal buisness hours.
Not backing the mail up is not an option. A single bad block can corrupt the whole mail DB, and trash everyone's mail. And we all keep mail around for one reason or another- often critical information is kept in the form of saved mail messages- all of which can vanish because of a single bad block.
This isn't Microsoft bashing. I've had this happen to a company I was working at (fortunately, I wasn't responsible for the mail server at that point). Save yourself the pain.
The one big file also accounts for the scalability problems of Exchange. Remember, this is running (by definition) on a 32-bit x86 machine, which gives you a maximum process size of about 3 gig. Mapping files larger than this so you can treat them as a data structure is impossible. This is why, as of a year or so ago, Exchange couldn't handle more than about 400 people per machine. They may have fixed this since then (I doubt it, but anything is possible). Don't take assurances- ask to talk to someone who is running 1000 people on a machine before simply beleiving that it can be done.
I wonder if the lawyers defending 2600 et. al. are watching?
Oh, today is completely different. In the 1960's and 70's (when Brooks wrote MMM) the theory was "If one woman can have a baby in nine months, nine women can have a baby in one month." Today's theory is "If one woman can have a baby in nine months in normal time, on woman can have nine babies in one month on internet time (she'll just have to put in some overtime)." (Ever notice how it's *on* internet time, not *in* internet time? That's because you have to be on something to agree to that sort of schedule.)
Brian's first law: kludges multiply.
1) If you don't modify the source code, then obviously you don't have anything you need to distribute. If, for example, you use the Linux kernel intact (i.e. the kernel would still run just happily without your code), then nothing needs to be distributed.
.class files out of a GPL program, link them with my proprietary code (but neither recompile nor modify the GPL code!) and keep my code proprietary? My suggestion: avoid the gray areas. If you're not sure, and don't want to abide by the GPL, don't use GPL'd code in questionable ways.
2) So long as the source code is publically available and under the GPL, the deal is satisified. Take an old P-90 box with a few hundred meg of HD space, throw Linux and an anonymous FTP server up, put code on server, forget to publish the fact that the software exists. Nothing in the license requires a Freshmeat announcement, or postings to the correct newsgroups or maillists (although this is encouraged!).
3) I thought the GPL explicitly dealt with content editing. You can edit proprietary documents with Emacs, compile proprietary code with gcc, and store proprietary information in MySQL. Just like you can write public domain documents in Word, compile GPL code with Visual C++, and store public information in Oracle.
4) There are gray areas still- just not the ones you list. Consider a GPL'd Java program- can I take pre-compiled
5) There is a lot of concern, and rightfully so, over this legal challenge. But a license which isn't defended is tantamount to no license whatsoever.
6) Do you think your average contract lawyer can write good code? Then why do you think that _you_ can write a contract that will hold up in a court of law if you're not a contract lawyer? The one huge advantage the BSD license has over the GPL license IMHO is that it has already stood up to the worst a large corporation (AT&T) could do. But of even greater concern to me than the future of the GPL is the horde of programmer-licenses that have shown up. How many of them have even been run past a contract lawyer, let alone a court of law? How many of them are just the pseudo-legalesse of a programmer way out of his depth and not knowing it?
The more dangerous legal challenge to open source may not be to the GPL, but to all of the programmer-licenses out there. But what of Apache or Perl? Perl's "pick your license" stunt makes it (mind you, IANAL) seem more vulnerable- at best, any action which is legal under either license is legal (i.e. the set of restricted behaviors is the intersection of the sets of restricted behaviours of the two licenses).
on SourceForge.
It's still crude (we're working on it)- but it is booting Linux _right_ _now_ on SiS530 chipsets.
One peice of logic I have to very strongly disagree with. Comparing Microsoft in 2000 to Microsoft in 1990 is completely bogus. Try comparing Windows, in either 2000 or 1990, to Unix in 1990. Microsoft managed to "innovate" from a 1950's era OS theory-wise up into the mid-80's. Try again.
Mr. Pike also doesn't seem to like backward compatibility, either- either through protocols or through API interfaces. Maybe it'd be nice to throw everything out and start from scratch- but there is a huge cost to this as well. One could argue that backwards compatibility is the difference between a theoretical success and a comercial one. This isn't to say that theoretical successes aren't important, just that they don't automatically turn into commercial successes.
I do agree that OS research is pretty much dead, but not because it's been killed by the horrid evil commercial companies, but because the problems have been _solved_. It's not the only one, either- data base design, numerical analysis, parsing and lexical analysis, and fundamental algorithms are also pretty much solved problems. Hey, haven't seen a sorting algorithm in a couple of decades- I wonder where all the innovation has gone? CPUs have gone from 1MHz to 1GHz, why haven't sorting algorithms gone from O(n * log(n)) to O(n), or even O(log(n))?
Math disciplines die too. The (IIRC) fifth international conference on Information theory back in 50's (you remember, Claude Shannon and that gang) was canceled because no one really had anything new to say. The problem got solved, move on to a new problem.
We're seeing this in OS theory as well. Remember the classic Tannenbaum vr.s Torvalds debate? What Tannenbaum missed was that, although theoretically better than monolithic kernels, in practice microkernels didn't have any signifigant advantage (or, rather, had disadvantages to match their advantages, and the successfull OSs would be "middle of the road" OSs with some features of both). Microkernels were the last gasp of the "Real Man" OS Theorists. It fizzled.
Rather than viewing this as a failure of research, I'd consider this a success. Congratulations, guys, you've solved the problem. Now go on and start trying to solve another one.
Start them on object oriented from the get-go. It's syntax is also good at catching "newbie errors".
What I _wouldn't_ worry about is teaching them a "toy language". Of course they'll learn other languages. Do NOT start them on C or C++. Yes, those are languages "professionals" use. So? You don't learn to drive in a formula-1 race car or an eighteen wheeled semitruck, despite the fact that is what the "professionals" use. You don't learn to fly in an F-16 jet fighter. You learn to drive in a Geo Metro with an automatic (or equivelent), and you learn to fly in a piper cub.
It's worse than that: with full knowledge of the problems with gets(), Strousup gave us istream::operator(char *) with _exactly_ the same problem. Allowing a new generation of programmers to program their buffer overruns in an object oriented language.
Actually, for the market they're aiming the Xeons at, more cache is better. Server-class Sparcs often have 8 meg of cache per CPU. RDBMs are notoriously cache-hungry. By having Intel put the 2M cache on-die, they ensure that the Sparc has nothing to worry about from the Xeon.
The 32-bit vr.s 64-bit is also a big problem. To balance CPU/memory/disk bottlenecks, you generally want about 1 gig of memory per CPU- so finding 12-16 gig of memory in a machine isn't unusual. And you want one process- the RDBM- to use _all_ of it (or at least most of it).
According to the Judge in the DeCSS case, any device which can be used to circumvent copyprotection is illegal according to DMCA- even if circumventing copy protection is not it's primary use, right? Now we have Microsoft claiming that there were discussions about how to use winzip to bypass it's copy protections and view the content without agreeing to the license, right?
So doesn't this put winzip in the same category as DeCSS- a tool which, despite it not being it's primary purpose, can be used to violate copy protections?
And if you look beyond linux, most networking protocols start life as open source. Consider SMTP, HTTP, TCP/IP, POP, IMAP, DNS, etc.
This doesn't just touch physics journals- although the physicists are more likely to be rational about the issue than the record or movie industries. But no debate about copyright or intellectual ownership I have seen to date has looked at the long-term issues. And by long-term, I don't just mean years or decades, I mean thousands of years.
Everyone decries the burning of the library of Alexandia. It's destruction has greatly impoversihed us today, it denied us access to the thoughts and works of the people who wrote those books. The burning of the library of Alexandria was a lobotimization of human culture.
But if Alexandria was a lobotomization, today's IP rules are senility. This is because, for short-term gain, the ignore the fact that the only way information survives long-term is if it's _copied_. No media lasts forever. Pop quiz: how many books today are older than 200 years old? Euclid's "Elements" survives today because it was copied, and copied again. The image of cloistered monks painfully hand-copying books survives to this day.
We need to address the concerns not only of the artists, writers, creators, and IP corporations, not only of the IP consumers, but also the concerns of our decendents a thousand years from now. Otherwise, we risk being a culture with no history, and therefor no future.
Before you answer "none!", remember that this post- and all the posts made about the Hellmouth, Microsoft, Linux, and whatever- are being hosted on machines paid for and maintained by Andover, and distributed over bandwidth paid for by Andover. We recognize that a book publisher has some rights over the works being published- why not Andover?
The more I think about it, the more I think "Intellectual Property" is an oxymoron.
Attempting to base modern society off of 18th century pre-industrial laws is like _so_ dated it's carbon dated! This is the new economy, baby- with the new rules to match! Talking about fusty old documents like that is even funnier than trying to apply 19th century antitrust laws to modern info e-dot-commerce company! Like, get real!
Patents are the modern, high tech way to deal with monopolies- make everyone a monopoly! For example, I myself have patented the word "the"- and am rolling out plans to charge a $3 licensing fee for every use of the word the. You may even have heard about my forth comming IPO- the dot com. "It's _the_ place to invest!" It'll be the biggest IPO to hit since Redhat's prehistoric IPO! It'll make billions! It'll make Sagans! (Billyuns and Billyuns)
And any insinuation that I, rightfull patent holder of the word the, might not be in the best interest of the society as a whole, is obviously instigating a communist plot to topple the markets, bankrupt millions of daytraders, encourage the illegal international piracy of the word the, cast the whole of civilization down into the depths of dispare and poverty and maybe even rend the fabric of this most noble country called The(tm) United States of America. For beautiful and sacred lies, for never ending gain... Opps, sorry, little flash back there.
Where was I? Oh, yeah, Natalie Portman- Naked and Petrified...
1) Is anyone readining it?
The evidence says yes. There was an attempt to post a trojan in open source recently (I lost the URL- help, anyone?). It lasted _ten_ _hours_ before it was discovered. And this question applies doubly so to closed source- as not just anyone can read it, only employees can read it. And most companies that I know of don't implement any sort of code review, so often a peice of code is only ever read by one person.
2)
Are they qualified to review the code? Some yes, some no. Once again, the exact same question can be applied to close source. Opps, most closed source isn't reviewed, even by unqualified programmers!
3)
It's easy to hide vulnerabilities in complex, poorly documented source code. This I'd agree with- especially _unintentional_ vulnerabilities. On the other hand, it's also hard to _maintain_ such code- and in the open source world, over time it tends to get reimplemented. Sendmail worries you? Try using smail or qmail instead. And, if anything, complex, poorly documented source code is more likely in closed source projects where the assumption that only the original writter will ever see the code, and as they already understand it, comments and simplicitly are optional. Besides, writting comments and refactoring code takes time, and I have a deadline this week...
4)
There is no strong gaurentee that source code and binaries have any relationship. Ah yes, Ken Thompson's paper. Thompson's paper assumes only one compiler, ever. You always compile gcc with only gcc- never Sun's cc, or IBM's xlc. It also assumes that any version of the compiler will recognize any other version of the compiler- so gcc 1.0 would recognize the source code to gcc 2.4, AND be able to insert the back door correctly into the produced binary! It'd also have to recognize the source code to tools like objdump and gdb as well, and insert the proper back doors into _them_ as well. I knew Ken Thompson was legendary- but this defies the imagination.
And, once again, there's no evidence of this on the closed source world either. Prove to me that Visual C++ isn't inserting back doors into Windows...
5) Open source makes it easy for the bad guys to find the vulnerabilities.
I was wondering when this chestnut would show up. The implicit assumption here is that the bad guys can't disassemble code- an assumption proveably false. There was a famous quote an IRA terrorist reportedly once said to Prime Minister Thatcher once- "We only have to be lucky once. You have to be lucky all the time." Security analysts face the same problem- the crackers only have to find _one_ vulnerability, while the security people have to find _all_ of them. You're not making the cracker's lives much difficult, but you're making the white hat's lives all but impossible.
Open source is not a security silver bullet- and I don't know of anyone outside a few anonymous cowards who claims that. Open source _is_ better than closed source for security. No ifs, ands, or buts.
Bodily functions that are one-to-one and onto are normal, so long as they are discrete and not continuous.
No- he's right. Real programmers don't use IDEs. There hasn't been an IDE yet that did string handling right in FORTRAN.
_Intelligent_ programmers use IDEs- but only because they're convient. They understand the code the IDEs produce, and could write it themselves if they took the time. In that sense, IDEs are no different than any other code generators- lex and yacc, for example.
But an IDE is no replacement for skill and understanding.
Congratulations, Bruce- you've just lost all my respect. Which is saying something- I used to be a fan.
Where do you think all that gee-whiz technology you write about comes from? The computers, the materials science, etc. Guess what: lots of it comes from the space program.
Call me when you catch a clue.
The other really intelligent thing Perl does it is uses native libraries. For example, if you use a regular expression in Perl, that's one instruction in the virtual machine- which calls a native C routine to actually do the regular expression. Most of your time in a Perl program is not spent in the virtual machine, it's spent in these optimized native routines.
This is one problem Java has for performance- since they wrote most of the libraries in Java, you are spending most of your time in the virtual machine.