- RMS poses a risk to the progress of good software and real competition. In many respects, RMS is the Bill Gates the open-source movement - a monopolist who wishes to control software development and the people that practice it. If it's not GPL, it's not free. If it's not GPL, it's not good. If it's not GPL, you shouldn't use it. Sounds like FUD to me, and that's scary.
Yes, but RMS receives no MORE benefit from software released under the GPL than you or I. Nor is there a FSF stock whose value he's deeply interested in. RMS does want to control software development, but only isofar as licensing does. I don't see him ever encouraging GNOME developers to break stuff so it's no longer compatible with KDE in whatever regard.
And free -- by his definition, is software licensed under the GPL. He is merely stating a definition. Whether or not it's good and whether or not I should use it aren't up to RMS, but rather myself. I do my own thinking.
Clock for clock, the G4 may wack a p3/4/athlon, but dollar for dollar, that Apple machine is getting smacked in the hoopla like nobodies business.
Moreover, at least AFAIK, there isn't a G3/4 chip out faster than 500 mhz, right? And given that we have STABLE 1.1 ghz Athlons shipping in decent quantities, the faster PC platorm out there right now (umm, the GeForce2 Ultra isn't out for Mac either, yet, right?) would be an IBM clone.
Python is believed to have better object-orientation than Perl. Since I don't have the OO religion, this makes very little impression on me.
After reading Dr. Conway's _Object Oriented Perl_, I'd tend to agree with Python having 'better object-orientation.' But this isn't due by any means to features, but rather to standardization:
the Python OO model is standardized enough that you don't have to roll your own, and also includes quite a few gee-whiz features like being able to replace methods at runtime, I believe. This leads to good object interoperability, and likely superior speed since OO _is_ somewhat less of a hack.
Perl is a lot less standardized, but equivalent at least in power. With the above example of subroutine replacement at runtime, this could be achieved by designing the class so that all methods are called through subroutine refs, and then just assigning to that subref for a new method.
The main problem that I see with Perl OO right now is the non-interoperability that is achieved when everyone rolls their own. The power is definitely amazing, but the ease-of-use between modules is fairly low. I believe that someone might even have a Perl6 RFC or two written up about this?
Yeah. Perl6 is supposed to be about 18 months away, when it will be available in early but stable alpha. Seeing, however, as some of the objectives for the "shame dates" haven't yet been made (overdue for a month, some of them), I'd suspect that the project will, as all of them tend to do, take a little longer than initially projected.
And as for radical changes: I'm expecting some, but nothing truly off-the-wall (RFC to toss out @% was retracted, etc.) You can see the ones that have been frozen so far as well as the ones that have been retracted here.
That said, I've seen some really cool stuff in the RFCs, regarding things like higher-order functions and co-routines. It's been my experience that Perl has always managed to take complicated computer-science concepts and make them into incredibly powerful yet easy-to-use features that even a newbie can understand, and I'm personally very excited to see a lot of RFC suggestions for more functional-oriented programming styles (and of course, as always, for improvement in the object-oriented side of Perl).
Well, they very well might be just playing, but I'm guessing (and no, I've not done order-of-magnitude calculations for this) that things like long-range weather prediction, and possibly other forms of "predicting the future" might see a benefit from this kind of expansion in computational speed and storage capacity?
Well, this would probably only really work for well-known sites that distribute signed clients, IMHO.
You're certainly correct in that no sane person should/would trust some newbie company that claims they wanna pay you for your extra cycles.
Agreed. And it's my assertion that in the case of computer security, breaking and implementing security are merely two sides of the same coin, and that the cracker has already been practicing many of the skills of a security specialist. But that's just IMO, of course.
Now, now. You seem to believe that science of criminology is already at its acme. I merely don't happen to agree. There can be small and non-obvious behavior signs shared by various subclasses of criminals, that a former criminal might just happen to be sensitive to. I'm not saying that anyone who looks like a trucker who hasn't bathed for a few weeks is gonna be a child molestor.
Either way, it would be accurate to say that a pedophile would be more likely to know, or be aware of methods used by other pedophiles.
It's a fact that if you're a career criminal at [bank-robbing | child-molesting | computer-cracking] that finally got your self a stay at the state bed-and-breakfast, and you're now looking for a security job in the private sector guarding against whatever you used to do, you'd have an edge over some luser who's out of the latest training proggie in security for whatever...
Putting a person convicted of computer stealing computer data in conputer security is similar to putting an embezzler in a cash counting room or a child molester in a job at a day care provider or a convicted drunk driver as a school bus driver or a perjurer as an attorney.
Bzzzt! You lose.
An embezzeler who has stolen cash (presumably at least with some success, otherwise he'd be "petty thief," and not "embezzeler,") knows how other embezzelers work, and can help guard against them. I'm also willing to bet that a pedophile is far better at picking out other possible pedophiles by just looking, etc. etc.
Hiring someone convicted of a computer crime has some pretty obvious benefits: yes, the person got caught, so they're probably not The Best. But they're probably also fairly good, and probably knows a bit more about the trade than your average Minesweeper Consultant.
On the other hand, Definition 2 of the hacker ethic in the Jargon File 4.22 says:
2: The belief that system-cracking for fun and exploration is ethically OK as long as the cracker commits no theft, vandalism, or breach of confidentiality.
Granted, ethical != lawful, but seeing as how the employment is essentially that of becoming a samurai, I don't see how these people have violated the standards of their trade.
I believe that the companies that make the hardware don't own the rights to the greater majority of old roms in many cases.
Thus, they see no great incentive to support the emu market, but instead (rightfully) see roms as being a 'competitor' of sorts to titles that are being published for their current platform.
This does sound like it would require some kind of IP stack interception, or a client.exe hack.
That said, I was under the impression that it's okay to modify files on your computer, even if they're not technically owned by you?
I mean, look, theoretically, a virus can overwrite part of my EverQuest.exe, and I'd be liable, because I let something modify my executable? Or because my old-sk001 antivirus program inserts a self-check into my Everquest executable?
Here's an analogy; I take the Perl source code to Slashdot, port it to Python (this would be a good idea anyway) and don't release the source. When the GPL zealots come breathing down my neck, I claim to have "reverse engineered" a slashdot "emulator". Do I have a case? Like hell.
Obviously not, as you've said, since porting implies translation of source code, which entails looking at the original. If you can prove that you've recreated all the functionality in a clean-room environment (a la Compaq with the original PC), then you're home free.
The other thing would be that the GPL zealots couldn't come breathing down your neck unless you released the compiled Python bytecode without the source. If you don't release anything, they have no case.
Incidentally, what is the lowest common denominator when it comes to sleep? Obviously not at the species level... phyla? Or does the entire animal kingdom sleep?
Take source of ILOVEYOU, modify to include DeCSS source at the bottom, with font color as white. Nobody notices, except that their printer spits out a couplea extra blank pages at the end of every document...
Regarding the potential use of Web bugs to track Word documents, Microsoft said that there is no evidence that such activities are occurring.
Um, well, let's see: regardless of the potential use of cyanide to murder people, the U.S. government said that there is no evidence that such activities are occuring. It then refused to regulate sales or fix the problem in any other way.
... oh wait. The government does regulate cyanide...
IANAAstronomer, but I do remember reading that for smaller black holes vs. bigger ones, the gravitational increase after passing the event horizon is curves up much more quickly for small holes vs. big ones (with gravity on the y axis and time on the x, I believe).
Not sure if this has anything to do with how much matter is being consumed by a smaller black hole, however?
... and from the world of PC gaming, we see... Unreal. And Halflife. Two games that missed their release dates by a mile. And kicked ass. We also see the (in)famous Daikatana. Which missed its release date, and sucks more than a whore hopped up on a bag full of crack rocks.
Release dates have nothing to do with quality, and quality is all that we should care about.
Oh, I agree with pretty much everything you've said there.:)
I think that in this case, the testers did exactly what you said: To do this on a voodoo board, they need to split the triangle into a few hundred of smaller ones, with one different texture to each.
They in effect did a larger version of the Creative driver hack that let people use 512x512 Quake3 textures. The tests were indeed biased in favor of the i740, and mainly served to demonstrate that pulling textures over PCI sucked compared to AGP (but by no means trying to show that local memory on the graphics card was unnecessary).
Believe it or not, I have a Voodoo2 board, and understand how it works quite well, thanks.
You're certainly correct about the Voodoo2 not supporting more than a 256x256 texture size -- I believe in this case that they simply tiled textures to simulate said test conditions.
That said, swapping small textures should actually be easier than swapping one large texture, and only still serves to prove that the PCI bus is limiting in this case.
Moreover, LOD isn't always a suitable answer, and neither is compression. Both are compromises that reduce quality in some way, which is what companies like 3dfx and nVidia are trying to avoid with newer and newer generation cards.
Although actually texturing from RAM was generally a flop, the technology has some very interesting features, mainly involving situations in which there are just too many large textures to fit in video RAM.
I remember a test case involving an i740 and a Voodoo2, both rendering a triangle. First the triangle had oh, something like a 2 or 4 meg texture on it, and the Voodoo2 kicked the i740s ass. Then, the test was performed with a 180mb texture mapped on it. The i740 maintained a steady 30 fps (not far from what it had been doing with the previous test conditions), while the Voodoo2 started to produce those stunning 1.5 frames a second.
Granted, that's an extreme case, but thrashing over the PCI bus isn't pretty, especially when you have to do it constantly. Not to mention that other devices occasionally kinda wanna use the PCI bus too, and tend to get upset when the bandwidth is hogged too much.
There's actually a lot more than just the songs for the transformation sequences... the series has an incredible number of CDs associated with it, somewhere upwards of 50, perhaps more. A lot of songs were done under the series' name, but never used in the actual anime.
Compleat used to have all of them up in MP3 format, but I've lost track of where that site is now. I luckily have all of them burned to CD, but don't have the space to host 7 CDRs on my harddrive as of yet...
- RMS poses a risk to the progress of good software and real competition. In many respects, RMS is the Bill Gates the open-source movement - a monopolist who wishes to control software development and the people that practice it. If it's not GPL, it's not free. If it's not GPL, it's not good. If it's not GPL, you shouldn't use it. Sounds like FUD to me, and that's scary.
Yes, but RMS receives no MORE benefit from software released under the GPL than you or I. Nor is there a FSF stock whose value he's deeply interested in. RMS does want to control software development, but only isofar as licensing does. I don't see him ever encouraging GNOME developers to break stuff so it's no longer compatible with KDE in whatever regard.
And free -- by his definition, is software licensed under the GPL. He is merely stating a definition. Whether or not it's good and whether or not I should use it aren't up to RMS, but rather myself. I do my own thinking.
And you can assign an integer to the same variable which until then contained a string.
Um, Perl does that too. Scalars can contain numbers, strings, and even pointers (except they're called referencers).
Um, because a Debian release _is_ a (very) good thing? :-)
Clock for clock, the G4 may wack a p3/4/athlon, but dollar for dollar, that Apple machine is getting smacked in the hoopla like nobodies business.
Moreover, at least AFAIK, there isn't a G3/4 chip out faster than 500 mhz, right? And given that we have STABLE 1.1 ghz Athlons shipping in decent quantities, the faster PC platorm out there right now (umm, the GeForce2 Ultra isn't out for Mac either, yet, right?) would be an IBM clone.
Python is believed to have better object-orientation than Perl. Since I don't have the OO religion, this makes very little impression on me.
After reading Dr. Conway's _Object Oriented Perl_, I'd tend to agree with Python having 'better object-orientation.' But this isn't due by any means to features, but rather to standardization:
the Python OO model is standardized enough that you don't have to roll your own, and also includes quite a few gee-whiz features like being able to replace methods at runtime, I believe. This leads to good object interoperability, and likely superior speed since OO _is_ somewhat less of a hack.
Perl is a lot less standardized, but equivalent at least in power. With the above example of subroutine replacement at runtime, this could be achieved by designing the class so that all methods are called through subroutine refs, and then just assigning to that subref for a new method.
The main problem that I see with Perl OO right now is the non-interoperability that is achieved when everyone rolls their own. The power is definitely amazing, but the ease-of-use between modules is fairly low. I believe that someone might even have a Perl6 RFC or two written up about this?
Yeah. Perl6 is supposed to be about 18 months away, when it will be available in early but stable alpha. Seeing, however, as some of the objectives for the "shame dates" haven't yet been made (overdue for a month, some of them), I'd suspect that the project will, as all of them tend to do, take a little longer than initially projected.
:-)
And as for radical changes: I'm expecting some, but nothing truly off-the-wall (RFC to toss out @% was retracted, etc.) You can see the ones that have been frozen so far as well as the ones that have been retracted here.
That said, I've seen some really cool stuff in the RFCs, regarding things like higher-order functions and co-routines. It's been my experience that Perl has always managed to take complicated computer-science concepts and make them into incredibly powerful yet easy-to-use features that even a newbie can understand, and I'm personally very excited to see a lot of RFC suggestions for more functional-oriented programming styles (and of course, as always, for improvement in the object-oriented side of Perl).
Of course, Rule 1 continues to apply.
Well, they very well might be just playing, but I'm guessing (and no, I've not done order-of-magnitude calculations for this) that things like long-range weather prediction, and possibly other forms of "predicting the future" might see a benefit from this kind of expansion in computational speed and storage capacity?
Well, this would probably only really work for well-known sites that distribute signed clients, IMHO.
You're certainly correct in that no sane person should/would trust some newbie company that claims they wanna pay you for your extra cycles.
Agreed. And it's my assertion that in the case of computer security, breaking and implementing security are merely two sides of the same coin, and that the cracker has already been practicing many of the skills of a security specialist. But that's just IMO, of course.
Now, now. You seem to believe that science of criminology is already at its acme. I merely don't happen to agree. There can be small and non-obvious behavior signs shared by various subclasses of criminals, that a former criminal might just happen to be sensitive to. I'm not saying that anyone who looks like a trucker who hasn't bathed for a few weeks is gonna be a child molestor.
Either way, it would be accurate to say that a pedophile would be more likely to know, or be aware of methods used by other pedophiles.
It's a fact that if you're a career criminal at [bank-robbing | child-molesting | computer-cracking] that finally got your self a stay at the state bed-and-breakfast, and you're now looking for a security job in the private sector guarding against whatever you used to do, you'd have an edge over some luser who's out of the latest training proggie in security for whatever...
Putting a person convicted of computer stealing computer data in conputer security is similar to putting an embezzler in a cash counting room or a child molester in a job at a day care provider or a convicted drunk driver as a school bus driver or a perjurer as an attorney.
Bzzzt! You lose.
An embezzeler who has stolen cash (presumably at least with some success, otherwise he'd be "petty thief," and not "embezzeler,") knows how other embezzelers work, and can help guard against them. I'm also willing to bet that a pedophile is far better at picking out other possible pedophiles by just looking, etc. etc.
Hiring someone convicted of a computer crime has some pretty obvious benefits: yes, the person got caught, so they're probably not The Best. But they're probably also fairly good, and probably knows a bit more about the trade than your average Minesweeper Consultant.
A big no duh there.
On the other hand, Definition 2 of the hacker ethic in the Jargon File 4.22 says:
2: The belief that system-cracking for fun and exploration is ethically OK as long as the cracker commits no theft, vandalism, or breach of confidentiality.
Granted, ethical != lawful, but seeing as how the employment is essentially that of becoming a samurai, I don't see how these people have violated the standards of their trade.
Cello? :)
I believe that the companies that make the hardware don't own the rights to the greater majority of old roms in many cases.
Thus, they see no great incentive to support the emu market, but instead (rightfully) see roms as being a 'competitor' of sorts to titles that are being published for their current platform.
IANAL. Usual disclaimer applies.
.exe hack.
.exe, and I'd be liable, because I let something modify my executable? Or because my old-sk001 antivirus program inserts a self-check into my Everquest executable?
This does sound like it would require some kind of IP stack interception, or a client
That said, I was under the impression that it's okay to modify files on your computer, even if they're not technically owned by you?
I mean, look, theoretically, a virus can overwrite part of my EverQuest
I would hope not...
Here's an analogy; I take the Perl source code to Slashdot, port it to Python (this would be a good idea anyway) and don't release the source. When the GPL zealots come breathing down my neck, I claim to have "reverse engineered" a slashdot "emulator". Do I have a case? Like hell.
Obviously not, as you've said, since porting implies translation of source code, which entails looking at the original. If you can prove that you've recreated all the functionality in a clean-room environment (a la Compaq with the original PC), then you're home free.
The other thing would be that the GPL zealots couldn't come breathing down your neck unless you released the compiled Python bytecode without the source. If you don't release anything, they have no case.
Incidentally, what is the lowest common denominator when it comes to sleep? Obviously not at the species level ... phyla? Or does the entire animal kingdom sleep?
Take source of ILOVEYOU, modify to include DeCSS source at the bottom, with font color as white. Nobody notices, except that their printer spits out a couplea extra blank pages at the end of every document...
Should be reasonably easy, you'd think.
Regarding the potential use of Web bugs to track Word documents, Microsoft said that there is no evidence that such activities are occurring.
... oh wait. The government does regulate cyanide...
Um, well, let's see: regardless of the potential use of cyanide to murder people, the U.S. government said that there is no evidence that such activities are occuring. It then refused to regulate sales or fix the problem in any other way.
IANAAstronomer, but I do remember reading that for smaller black holes vs. bigger ones, the gravitational increase after passing the event horizon is curves up much more quickly for small holes vs. big ones (with gravity on the y axis and time on the x, I believe).
Not sure if this has anything to do with how much matter is being consumed by a smaller black hole, however?
... and from the world of PC gaming, we see ... Unreal. And Halflife. Two games that missed their release dates by a mile. And kicked ass. We also see the (in)famous Daikatana. Which missed its release date, and sucks more than a whore hopped up on a bag full of crack rocks.
Release dates have nothing to do with quality, and quality is all that we should care about.
Oh, I agree with pretty much everything you've said there. :)
I think that in this case, the testers did exactly what you said:
To do this on a voodoo board, they need to split the triangle into a few hundred of smaller ones, with one different texture to each.
They in effect did a larger version of the Creative driver hack that let people use 512x512 Quake3 textures. The tests were indeed biased in favor of the i740, and mainly served to demonstrate that pulling textures over PCI sucked compared to AGP (but by no means trying to show that local memory on the graphics card was unnecessary).
Believe it or not, I have a Voodoo2 board, and understand how it works quite well, thanks.
You're certainly correct about the Voodoo2 not supporting more than a 256x256 texture size -- I believe in this case that they simply tiled textures to simulate said test conditions.
That said, swapping small textures should actually be easier than swapping one large texture, and only still serves to prove that the PCI bus is limiting in this case.
Moreover, LOD isn't always a suitable answer, and neither is compression. Both are compromises that reduce quality in some way, which is what companies like 3dfx and nVidia are trying to avoid with newer and newer generation cards.
AGP did quite a bit for gamers, actually.
Although actually texturing from RAM was generally a flop, the technology has some very interesting features, mainly involving situations in which there are just too many large textures to fit in video RAM.
I remember a test case involving an i740 and a Voodoo2, both rendering a triangle. First the triangle had oh, something like a 2 or 4 meg texture on it, and the Voodoo2 kicked the i740s ass. Then, the test was performed with a 180mb texture mapped on it. The i740 maintained a steady 30 fps (not far from what it had been doing with the previous test conditions), while the Voodoo2 started to produce those stunning 1.5 frames a second.
Granted, that's an extreme case, but thrashing over the PCI bus isn't pretty, especially when you have to do it constantly. Not to mention that other devices occasionally kinda wanna use the PCI bus too, and tend to get upset when the bandwidth is hogged too much.
There's actually a lot more than just the songs for the transformation sequences ... the series has an incredible number of CDs associated with it, somewhere upwards of 50, perhaps more. A lot of songs were done under the series' name, but never used in the actual anime.
Compleat used to have all of them up in MP3 format, but I've lost track of where that site is now. I luckily have all of them burned to CD, but don't have the space to host 7 CDRs on my harddrive as of yet...