I'll agree on doing away with software patents. The rest of it is fine the way it is. First-to-file is inherently unfair. The one who comes up with an idea first, even if it takes him longer to reduce it to a patentable state, should be the one who gets to benefit from it. The risk of falsified invention dates is offset by the lack of benefit of industrial espionage - something the Europeans are very good at. Same thing with patenting ideas that someone else has disclosed: if you invent it first, you get to benefit from it. --
That's all well and good until they try to pull a Unisys and claim royalties on a firmly entrenched standard.
Allow me to introduce a concept that most slashdotters appear to have no concept of: fiduciary duty. The officers and directors have a legally binding and enforceable duty to their shareholders - and NOBODY ELSE - to use the assets of the corporation to maximize the value of the corporation itself. If the corporation has an asset and fails to take best advantage of it, then the shareholders can sue and the officers and directors can be held personally responsible for the lost value.
This principle means that a corporation that has a patentable invention has a duty to its shareholders to patent it, and a corporation that holds a patent has a duty to exploit it to the best advantage of the shareholders.
I don't like the way Unisys is handling the LZW patent either, but they're hardly evil for doing so. It's quite likely that they are only doing what the law requires of them. --
First-to-file is even more likely to raise the ire of slashdotters than first-to-invent: it destroys the relevance of prior art. Under a first-to-file system, the existence of another object prior ro rht filing date that meets the same claims as those in the patent is completely meaningless. --
4) Wait six to ten months for the patent office to stare cluelessly at the patent and eventually give up on "seeking prior art" (patent employees do not read SlashDot...lucky for you!)
This is a common misconception. The patent office does not have the duty to search for prior art. The patent applicant has the duty to notify the patent office of any and all material prior art. The patent office may find some on its own, but the job is not theirs, at least not under US patent law.
The reason behind this is twofold:
The patent process is not adversarial. If the application meets the requirements, the patent office is obliged to grant the patent, and nobody but the applicant has the right to participate in the process.
The patent office is not expert in the field of the invention. By definition, the inventor/applicant knows more about the subject area than the patent office. The inventor is much more likely to know of applicable prior art than the patent office.
Failure to tell the patent office of all relevant prior art is one legal ground for overturning a patent in court. If there really is prior art, then Intel's patent is invalid and unenforceable...however, the mere existence of distributed.net and SETI@home may not be enough: they must embody elements of every claim in IBM's patent to completely invalidate it, which may or may not be the case. Check with your friendly neighborhood patent attorney for details (and no, I'm not one). --
From reading their page, it appears that they're not even thinking about doing an Alpha version. Dammit. There's no good graphical web browser for Alpha Linux out there, and I was hoping that Opera would fill the void.
I hope that this is merely a matter of limited resources, and not, like Netscape, a matter of the code being so thoroughly non-64-bit clean that it'll never work on an Alpha... --
(Oh, and please lose or break up the wide.signature...it screws up browser formatting, by forcing side scrolling when it wouldn't otherwise be needed.) --
My main Linux server at home is an AlphaStation 200 4/166, for which I paid less than $500, less RAM and disk. I'm about to replace it with a system based on the PC164 motherboard and a 500 MHz Alpha. The motherboard and CPU were on eBay for $249. The biggest expense with these is that you have to use true parity (36-bit) RAM and SCSI disk, but the reward is good, solid performance. Running Linux on one gives you a good vaccine against many script kiddie attacks, since they nearly always depend on replacing a binary, and the payload is almost always an Intel binary.
I'll probably pop for a copy of Tru64 for the AS200; I've liked it ever since my first Unix job that I could put on my resume, with 1.3. --
Unfortunately, the Multia suffers from a common failure: a chip on the bottom of the board overheats and fails, and the machine throws repeated machine checks. I ran a Multia for a year or so as an NT primary domain controller; when it died, that was it. It'd probably be fine for an intermittent user who doesn't leave it on all the time, but I'd recommend staying away from it for server-style use. --
Can you say, ``fork in development''? I guess people don't realize how serious that scenario really is.
Oh? I thought the ability to fork was a key feature of the GPV, one that its zealots hold up as a Truly Good Thing. You mean it's not?
The problem with X and BSD licensing schemes is that they're only free as long as the principal maintainers decide it should be.
You're missing the point, again. A maintainer has the absolute right to decide his work, henceforth, will be released on something other than Open Source terms. Fine. Even so, he CANNOT change the terms of his previous releases. If those releases were once free, they will always and forever remain free.
This is where the above link comes in real handy. I suggest you try it.
I read that post the first time around. In it, you agree with me that RMS and his zealots use a different meaning for "free" than the rest of the world; in so doing, they commit intellectual fraud upon the populace. Only in that limited definition of "free" does the GPV maximize freedom.
I think it's really amusing that you think I'm the clueless one, so much so that you think I don't know about the XFree86 Project.
If you do not wish to be seen as clueless, it would behoove you to act as if you had two clues to rub together.
By the way, this wasn't a flame war until you made it one.
This has been an ongoing flame war for nearly 10 years. This thread on Slashdot is merely the latest iteration. --
Think about how close we came to losing the X Window System to the world of proprietary software, for instance.
Once again, you distort the truth - or ignore it - in your blind zealotry for the GPV.
The truth is that the X Window System cannot, could not, and was in no danger of being "lost". Yes, the X Consortium was on the verge of changing the license terms so that future releases would have been proprietary. So what? The code that was freely available would have continued to be so, and there was not a damned thing the X Consortium could do to change that. The XFree86 folks were going to go ahead with supporting their software and keeping it freely available, and the X Consortium would have been powerless to stop them.
He wants to empower free software. BSD style licensing has nothing to do with that..
Only in the limited, communistic definition of "free" that RMS and his zealots use. Here's a clue for you, though I have little hope it'll stick: True freedom necessarily includes the freedom to do things that piss you off. Until you realize that, this flamewar will never end. --
[...] unless they provide some actual functionality to non-Turbo Linux clustering users, they *shouldn't* be incorporated into the main kernel fork.
I disagree, for a simple reason: Putting the functionality into the main kernel would allow the development of open source userland tools to do the same job as the tools TurboLinux is releasing as proprietary. How long do you think it'd be before something like that sprang up? --
Perhaps these comments are really an indictment of the average reading comprehension of GPV zealots...after all, anyone that had READ the article would have seen that 1) the restrictions don't apply to any code but the stuff Corel is developing themselves, and 2) that Corel intends to release that code as Open Source as well once they think it measures up.
Reasonable people can understand Corel's position, especially when they explain it as they have. Only the most rabid GPV zealot, it seems, can misinterpret it. --
yes, exactly, especially if the counter happens to be in A, you end up with stuff like this:
How about, instead:
ADD A,L MOV L,A JR NC,foo INC H
foo:
(Please don't flame me if I missed the JR (jump relative) mnemonic; it's been years.) To me, the sheer breadth of resources available to the Z-80 programmer outweighs the somewhat warty nature of the architecture; Zilog was trying to build on top of the 8080, which had already gained a fair amount of acceptance, and succeeded quite well.
Were the Z-8000 not even weirder than the 8086 (no small feat!), it could well have been IBM's choice. Intel took a page out of Zilog's book and made the 8086 run code from the 8080 with only a machine translation, something the Z-8000 could not do, and thus immediately took advantage of the library of existing CP/M-80 software; the rest, as they say, is history. --
...thus once again demonstrating that technical superiority has no bearing on product acceptance. The TIs I've been cursed with owning were junk; the HPs I've owned, from the HP-25 through to my current HP-48SX, have been rock solid performers and damned near indestructible. Now if I could just find my [ENTER] > [=] shirt... --
The Z80 is the only architecture that I would rank worse than the x86.
Hmph. Go find some documentation on the Saturn CPU used in the HP-28/48/49 calculators. It makes the Z-80 look like a 68000 from that aspect.
instructions that don't work well together (it's a pain to add an 8bit counter to a 16bit total)
You mean like:
INC C LD B,0 ADD HL,BC
(surround the LD B,0 with a PUSH/POP if needed)?
In general, the Z-80 was simple to learn and use, from both the hardware and software perspectives. I'm happy to see it still around. Some things I did with it in 1980 (say, a programmable sequence tone generator - in 4 chips and no RAM) were next to impossiblt to do as well or as cheaply for years afterward.
Actually, if you like the PIC, you'll love the Atmel AVR programmable microcontrollers. Much cleaner architecture than the PIC, no I/O pin weirdness with outputs not quite being outputs all the time, and a real serial-connected programmer is $49 instead of $400. --
I'm sorry I come across this way. Most of what motivates me to post on Slashdot is reading articles that push my buttons; as with most other folks, articles written with that kind of motivation will come across as less than positive. I do try to be positive, but don't succeed as often as I, and apparently you, would like.
Such is the case with this thread. I'd read enough of the Stevens thread to be thoroughly sickened by the behavior of the Perl bigots there, and Tom Christiansen's post simply iced the cake. When this article was posted, I saw something those same people would pounce on, and wrote my message in the hope that it would draw whatever nasty comments there were away from the real discussion. As it happens, the nasty comments didn't appear, something for which I'm grateful. --
Maybe a) No Perl programmers bother to react b) Perl programmers are not bigots c) You scared them away before they got started.
I hope it's b, as well, but after reading the garbage spewed in the Stevens thread, I rather suspect it's c. My purpose in posting my comment was to act as a lightning rod, hopefully drawing their fire away from the more meaningful discussion. --
If you think NCI's position was strange, look at Bill Tynan's reply comment.
I did...and filed my own reply comment this morning, which I hope will refute some of his arguments.
This is not what I expected from the former president of AMSAT North America. I think the Phase 3D debacle must have stressed him heavily - I can find no other explanation.
Me either...though I've come to the conclusion that he's scared that the weak signal bands will be overrun and put the weak signal crowd out of business by force of numbers. If that's his view of the future, then his statements make sense: nobody likes to be driven forcibly out of their chunk of the hobby.
Bill and I had about a 2-hour discussion at the Austin hamfest the weekend before he filed his reply comments, where he made the same points. Neither of us convinced the other (obviously!), but we did get a good feel for each other's position. --
Slashdot Mirror
I'll agree on doing away with software patents. The rest of it is fine the way it is. First-to-file is inherently unfair. The one who comes up with an idea first, even if it takes him longer to reduce it to a patentable state, should be the one who gets to benefit from it. The risk of falsified invention dates is offset by the lack of benefit of industrial espionage - something the Europeans are very good at. Same thing with patenting ideas that someone else has disclosed: if you invent it first, you get to benefit from it.
--
That's all well and good until they try to pull a Unisys and claim royalties on a firmly entrenched standard.
Allow me to introduce a concept that most slashdotters appear to have no concept of: fiduciary duty. The officers and directors have a legally binding and enforceable duty to their shareholders - and NOBODY ELSE - to use the assets of the corporation to maximize the value of the corporation itself. If the corporation has an asset and fails to take best advantage of it, then the shareholders can sue and the officers and directors can be held personally responsible for the lost value.
This principle means that a corporation that has a patentable invention has a duty to its shareholders to patent it, and a corporation that holds a patent has a duty to exploit it to the best advantage of the shareholders.
I don't like the way Unisys is handling the LZW patent either, but they're hardly evil for doing so. It's quite likely that they are only doing what the law requires of them.
--
First-to-file is even more likely to raise the ire of slashdotters than first-to-invent: it destroys the relevance of prior art. Under a first-to-file system, the existence of another object prior ro rht filing date that meets the same claims as those in the patent is completely meaningless.
--
This is a common misconception. The patent office does not have the duty to search for prior art. The patent applicant has the duty to notify the patent office of any and all material prior art. The patent office may find some on its own, but the job is not theirs, at least not under US patent law.
The reason behind this is twofold:
- The patent process is not adversarial. If the application meets the requirements, the patent office is obliged to grant the patent, and nobody but the applicant has the right to participate in the process.
- The patent office is not expert in the field of the invention. By definition, the inventor/applicant knows more about the subject area than the patent office. The inventor is much more likely to know of applicable prior art than the patent office.
Failure to tell the patent office of all relevant prior art is one legal ground for overturning a patent in court. If there really is prior art, then Intel's patent is invalid and unenforceable...however, the mere existence of distributed.net and SETI@home may not be enough: they must embody elements of every claim in IBM's patent to completely invalidate it, which may or may not be the case. Check with your friendly neighborhood patent attorney for details (and no, I'm not one).--
I hope that this is merely a matter of limited resources, and not, like Netscape, a matter of the code being so thoroughly non-64-bit clean that it'll never work on an Alpha...
--
AIX and HP-UX are dead as soon as someone finds a hole deep enough to bury the remains.
I wouldn't be so sure about AIX...after all, IBM is one of the lead developers of Monterey, the commercial Unix for Merced...
--
(Oh, and please lose or break up the wide .signature...it screws up browser formatting, by forcing side scrolling when it wouldn't otherwise be needed.)
--
My main Linux server at home is an AlphaStation 200 4/166, for which I paid less than $500, less RAM and disk. I'm about to replace it with a system based on the PC164 motherboard and a 500 MHz Alpha. The motherboard and CPU were on eBay for $249. The biggest expense with these is that you have to use true parity (36-bit) RAM and SCSI disk, but the reward is good, solid performance. Running Linux on one gives you a good vaccine against many script kiddie attacks, since they nearly always depend on replacing a binary, and the payload is almost always an Intel binary.
I'll probably pop for a copy of Tru64 for the AS200; I've liked it ever since my first Unix job that I could put on my resume, with 1.3.
--
Unfortunately, the Multia suffers from a common failure: a chip on the bottom of the board overheats and fails, and the machine throws repeated machine checks. I ran a Multia for a year or so as an NT primary domain controller; when it died, that was it. It'd probably be fine for an intermittent user who doesn't leave it on all the time, but I'd recommend staying away from it for server-style use.
--
Oh? I thought the ability to fork was a key feature of the GPV, one that its zealots hold up as a Truly Good Thing. You mean it's not?
The problem with X and BSD licensing schemes is that they're only free as long as the principal maintainers decide it should be.
You're missing the point, again. A maintainer has the absolute right to decide his work, henceforth, will be released on something other than Open Source terms. Fine. Even so, he CANNOT change the terms of his previous releases. If those releases were once free, they will always and forever remain free.
This is where the above link comes in real handy. I suggest you try it.
I read that post the first time around. In it, you agree with me that RMS and his zealots use a different meaning for "free" than the rest of the world; in so doing, they commit intellectual fraud upon the populace. Only in that limited definition of "free" does the GPV maximize freedom.
I think it's really amusing that you think I'm the clueless one, so much so that you think I don't know about the XFree86 Project.
If you do not wish to be seen as clueless, it would behoove you to act as if you had two clues to rub together.
By the way, this wasn't a flame war until you made it one.
This has been an ongoing flame war for nearly 10 years. This thread on Slashdot is merely the latest iteration.
--
Once again, you distort the truth - or ignore it - in your blind zealotry for the GPV.
The truth is that the X Window System cannot, could not, and was in no danger of being "lost". Yes, the X Consortium was on the verge of changing the license terms so that future releases would have been proprietary. So what? The code that was freely available would have continued to be so, and there was not a damned thing the X Consortium could do to change that. The XFree86 folks were going to go ahead with supporting their software and keeping it freely available, and the X Consortium would have been powerless to stop them.
He wants to empower free software. BSD style licensing has nothing to do with that..
Only in the limited, communistic definition of "free" that RMS and his zealots use. Here's a clue for you, though I have little hope it'll stick: True freedom necessarily includes the freedom to do things that piss you off. Until you realize that, this flamewar will never end.
--
[...] unless they provide some actual functionality to non-Turbo Linux clustering users, they *shouldn't* be incorporated into the main kernel fork.
I disagree, for a simple reason: Putting the functionality into the main kernel would allow the development of open source userland tools to do the same job as the tools TurboLinux is releasing as proprietary. How long do you think it'd be before something like that sprang up?
--
What a lovely picture...geeks being targeted by computers. Wonder if a geek wrote the code.
--
In short, the goal is, say it with me kids, "Total World Domination".
Why do you think my main Linux box is named thebrain? (Narf.)
--
Perhaps these comments are really an indictment of the average reading comprehension of GPV zealots...after all, anyone that had READ the article would have seen that 1) the restrictions don't apply to any code but the stuff Corel is developing themselves, and 2) that Corel intends to release that code as Open Source as well once they think it measures up.
Reasonable people can understand Corel's position, especially when they explain it as they have. Only the most rabid GPV zealot, it seems, can misinterpret it.
--
How about, instead:
(Please don't flame me if I missed the JR (jump relative) mnemonic; it's been years.) To me, the sheer breadth of resources available to the Z-80 programmer outweighs the somewhat warty nature of the architecture; Zilog was trying to build on top of the 8080, which had already gained a fair amount of acceptance, and succeeded quite well.
Were the Z-8000 not even weirder than the 8086 (no small feat!), it could well have been IBM's choice. Intel took a page out of Zilog's book and made the 8086 run code from the 8080 with only a machine translation, something the Z-8000 could not do, and thus immediately took advantage of the library of existing CP/M-80 software; the rest, as they say, is history.
--
...thus once again demonstrating that technical superiority has no bearing on product acceptance. The TIs I've been cursed with owning were junk; the HPs I've owned, from the HP-25 through to my current HP-48SX, have been rock solid performers and damned near indestructible. Now if I could just find my [ENTER] > [=] shirt...
--
Hmph. Go find some documentation on the Saturn CPU used in the HP-28/48/49 calculators. It makes the Z-80 look like a 68000 from that aspect.
(surround the LD B,0 with a PUSH/POP if needed)?instructions that don't work well together (it's a pain to add an 8bit counter to a 16bit total)
You mean like:
In general, the Z-80 was simple to learn and use, from both the hardware and software perspectives. I'm happy to see it still around. Some things I did with it in 1980 (say, a programmable sequence tone generator - in 4 chips and no RAM) were next to impossiblt to do as well or as cheaply for years afterward.
--
Actually, if you like the PIC, you'll love the Atmel AVR programmable microcontrollers. Much cleaner architecture than the PIC, no I/O pin weirdness with outputs not quite being outputs all the time, and a real serial-connected programmer is $49 instead of $400.
--
...around an oil leak.
--
What's your beef?
I'm sorry I come across this way. Most of what motivates me to post on Slashdot is reading articles that push my buttons; as with most other folks, articles written with that kind of motivation will come across as less than positive. I do try to be positive, but don't succeed as often as I, and apparently you, would like.
Such is the case with this thread. I'd read enough of the Stevens thread to be thoroughly sickened by the behavior of the Perl bigots there, and Tom Christiansen's post simply iced the cake. When this article was posted, I saw something those same people would pounce on, and wrote my message in the hope that it would draw whatever nasty comments there were away from the real discussion. As it happens, the nasty comments didn't appear, something for which I'm grateful.
--
Maybe a) No Perl programmers bother to react b) Perl programmers are not bigots c) You scared them away before they got started.
I hope it's b, as well, but after reading the garbage spewed in the Stevens thread, I rather suspect it's c. My purpose in posting my comment was to act as a lightning rod, hopefully drawing their fire away from the more meaningful discussion.
--
I did...and filed my own reply comment this morning, which I hope will refute some of his arguments.
This is not what I expected from the former president of AMSAT North America. I think the Phase 3D debacle must have stressed him heavily - I can find no other explanation.
Me either...though I've come to the conclusion that he's scared that the weak signal bands will be overrun and put the weak signal crowd out of business by force of numbers. If that's his view of the future, then his statements make sense: nobody likes to be driven forcibly out of their chunk of the hobby.
Bill and I had about a 2-hour discussion at the Austin hamfest the weekend before he filed his reply comments, where he made the same points. Neither of us convinced the other (obviously!), but we did get a good feel for each other's position.
--
:-)
(FWIW, NCI's position on RM-9673 was a bit strange to me, but they agreed that the petition should be thrown out, so they're not entirely kooks.)
--
OTOH, GvR's connection with ABC shows in Python, and that can only help in teaching...
--