Are there any real programs that ever modify their own code, or compilers that output code that does so? OpenBSD seems to be assuming not, and I'd guess they've done their research, but it seems that whenever you forbid something that used to be legal you're inevitably going to break something that used to work.
does *nix not allow self-modifying code?
on
OpenBSD 3.3 Released
·
· Score: 3, Funny
That was all the fun of DOS assembler programming...
If there were a database of textads for major sites continually updated, an average person could download updates. This is very similar to virus definition updates for an anti-virus program or spyware signature updates for Ad-Aware, which many people have no trouble using.
First of all, this is just an issue of genetic algorithms, which don't require you to explicitly have a logic circuit coded in DNA -- there's many other analogous ways of "evolving" software or circuits.
Secondly, they do come up with very interesting results (sometimes), but often these results are not really what you'd want. I can't seem to recall details (if anyone has a reference I'd appreciate it), but I recall about a decade ago someone evolved a timing circuit that used something like 20% fewer gates than the standard human-engineered design. The catch? It used weird interactions between unconnected components, so it only worked in the exact environment (temperature, humidity, surrounding magnetic/electrical fields, etc.) it was evolved in, and stopped working entirely when the conditions changed.
For complex circuits, it's very difficult to make sure your evolving circuit is not "cheating" and making any assumptions that will cause it to break unexpectedly when those assumptions are no longer true.
I've only tried out the PC version of their QuickTime AAC encoder. You're technically correct in that it's not CBR, but it's ABR -- you specify a target bitrate, and it flexes up and down a bit to accomodate the music, but averages very close to what you specify. When I've specified "128kbps" I get a file that's very nearly 128kbps. That's completely different from VBR, where you specify a desired quality level and the psychoacoustic model attempts to choose an appropriate bitrate.
I'm not sure what to make of his observations. If the 128kbps and 320kbps settings were ABR, the 320kbps should definitely have been larger. If they were VBR, it wouldn't even make sense to call them "128kbps" and "320kbps" settings, but if those are poorly-named aliases for "medium quality" and "high quality" or something, it still shouldn't result in the same filesizes; picking a higher quality should result in larger files, except in very rare cases (like recording a pure sine wave or something).
- Try MP3 encoded with LAME's "--preset standard". It's far better than whatever you're using. If that's still not good enough, try "--preset insane" (which is a highly-tuned version of 320kbps).
- Download an ABX tool and actually do a proper blind test. Most people who complain about MP3 artifacts can't in fact ABX them.
I've only heard samples encoded with either 6.0 or 6.1, I forget which, but definitely not 6.2.
Another reason Nero has been higher quality though is that it supports VBR (variable bitrate), whereas QuickTime (at least in the versions I know about) only supports CBR.
I'm pretty okay with a car company saying that if you overhauled your car, it's your responsibility to deal with it if it breaks. Even if you were responsible, proving so would require them to go through each of your dozen amateurish modifications to find and prove which one caused the problem, which raises the cost for the rest of us.
Now granted, there's some reasonable middle between "can't touch it without voiding the warranty" and "manufacturer has to honor the warranty even if you turned your car into a rice rocket," but I certainly oppose the latter.
I think with the car example, if you install an important part yourself and are not a qualified professional, the company may be able to argue you did an improper installation job. Similarly, if you install your own heatsink, AMD could argue that you installed it improperly (not a farfetched notion, as a lot of heatsinks are improperly installed).
This has nothing to do with OEM status, this has to do with voiding your warranty through improper usage. If you hook up the wrong battery to your car and it dies, you're not eligible for warranty service. Same here -- don't use the heatsink that comes with it, and it's your problem if it dies.
128kbps AAC is easily distinguishable from the CD is very many cases, especially anything with sharp transients. It is indeed significantly better than 128kbps MP3, but not by as much as you insinuate. I'd consider it more comparable to a 160-192 kbps MP3, which is not a range in which MP3 is reliably transparent.
Theoretically, 128kbps AAC should be transparent on nearly all samples, but that would require significantly more tuning than has been done thus far. Currently, the best-performing transparent codec is MPC (Muspack), which achieves its almost-always-transparent quality at 150-160kbps; AAC at these bitrates will be inferior (with current tunings) but still very good.
Note also that it depends heavily on the encoder. I sincerely hope Apple is using a better encoder than the currently available QuickTime AAC implementation, which is frankly horrible (the Nero AAC encoder is vastly better quality).
It's hard to say for sure, but SARS simply doesn't seem that deadly. With worse hygiene and containment certainly far more people would be infected, but it's unlikely such a huge percentage of them would die. Currently fatality rates are in the 2-4% range. Even if that'd double to 4-8% without modern medical care, that's still not near 40% (and that's not even necessarily the case; a lot of people that have recovered just recovered on their own, similarly to how you recover from a cold, not due to wonders of medical care).
Nature designs things in an incredibly complex way, because that's simply how evolution works -- there's certainly no software engineering notion of clean component separation and so on in evolution. So it ends up certainly being complex, working, and possibly even beautiful, but a nearly impossible to decipher mess of spaghetti. Sort of like an old-school assembly programming genius designing an enormous 500,000-line program in assembly -- it'll work beautifully, but nobody will have any idea what the hell is going on, or be able to modify it. Similar problems exist when trying to genetically engineer things; you're always going to mess something up.
an interesting comparison
on
Linus on DRM
·
· Score: 1
Especially in light of the fact that history generally looks more kindly on Einstein than on von Braun and Opennheimer.
The authors can't revoke the license; it either remains valid, or it's automatically revoked due to a violation (the authors could perhaps sue to enforce such a revocation however).
In any case, simply suing IBM is not a violation of the GPL; are there any actual violations taking place, such as not publishing source code to modified binaries they distribute?
I see what you're saying now, but I don't think it works successfully for an EULA in the same way it does for the GPL. For it to work for an EULA, you would have to be commiting a default copyright violation by using the work without a license; however, you're not, since your are not making any copies, and only are in possession of one copy that was given to you by an authorized distributor. The GPL can work because it prevents you from making further copies (which invoke copyright law), but in absence of any copying taking place, I don't see how an EULA can employ copyright law for its enforcement.
There was money in your account, and it has been removed. There is no such removal taking place in the "loss of sales" scenario.
I'm not saying copyright infringement is not wrong, just that it is wrong in a different way from theft. One is wrong due to actual removal of someone's property, while the other is wrong due to denial of potential profits.
Acceptance of the GPL isn't required to use software. The only time you have to accept the GPL is if you want to distribute GPL'd software (either the original or a derived version). Even then, you don't have to accept it because of an EULA; you have to accept it because if you don't, you have no right to distribute the software (since in absense of the GPL or any other license grant, copyright reverts to "All Rights Reserved" status).
That's "denying company money they are rightfully owned for that product or service," which is not the same as "illicitly removing an object from someone's possession." Your credit card example is theft, because nobody cares about the "copying" of credit card numbers; they care about the thief removing your money from your possession.
Slashdot Mirror
Are there any real programs that ever modify their own code, or compilers that output code that does so? OpenBSD seems to be assuming not, and I'd guess they've done their research, but it seems that whenever you forbid something that used to be legal you're inevitably going to break something that used to work.
That was all the fun of DOS assembler programming...
If there were a database of textads for major sites continually updated, an average person could download updates. This is very similar to virus definition updates for an anti-virus program or spyware signature updates for Ad-Aware, which many people have no trouble using.
If they have a consistent placement/formatting on the page, they're easy to filter out with a regexp based filter.
If you're going to have no drive, the best solution is probably something like the NCD thin clients.
First of all, this is just an issue of genetic algorithms, which don't require you to explicitly have a logic circuit coded in DNA -- there's many other analogous ways of "evolving" software or circuits.
Secondly, they do come up with very interesting results (sometimes), but often these results are not really what you'd want. I can't seem to recall details (if anyone has a reference I'd appreciate it), but I recall about a decade ago someone evolved a timing circuit that used something like 20% fewer gates than the standard human-engineered design. The catch? It used weird interactions between unconnected components, so it only worked in the exact environment (temperature, humidity, surrounding magnetic/electrical fields, etc.) it was evolved in, and stopped working entirely when the conditions changed.
For complex circuits, it's very difficult to make sure your evolving circuit is not "cheating" and making any assumptions that will cause it to break unexpectedly when those assumptions are no longer true.
I've only tried out the PC version of their QuickTime AAC encoder. You're technically correct in that it's not CBR, but it's ABR -- you specify a target bitrate, and it flexes up and down a bit to accomodate the music, but averages very close to what you specify. When I've specified "128kbps" I get a file that's very nearly 128kbps. That's completely different from VBR, where you specify a desired quality level and the psychoacoustic model attempts to choose an appropriate bitrate.
I'm not sure what to make of his observations. If the 128kbps and 320kbps settings were ABR, the 320kbps should definitely have been larger. If they were VBR, it wouldn't even make sense to call them "128kbps" and "320kbps" settings, but if those are poorly-named aliases for "medium quality" and "high quality" or something, it still shouldn't result in the same filesizes; picking a higher quality should result in larger files, except in very rare cases (like recording a pure sine wave or something).
He just now realized this? Why didn't he leave USENET 5 years ago?
On an unrelated note, I do find it funny there's still a news.announce.newusers. Perhaps ISPs should encourage all new users to post there. =]
- Try MP3 encoded with LAME's "--preset standard". It's far better than whatever you're using. If that's still not good enough, try "--preset insane" (which is a highly-tuned version of 320kbps).
- Download an ABX tool and actually do a proper blind test. Most people who complain about MP3 artifacts can't in fact ABX them.
I've only heard samples encoded with either 6.0 or 6.1, I forget which, but definitely not 6.2.
Another reason Nero has been higher quality though is that it supports VBR (variable bitrate), whereas QuickTime (at least in the versions I know about) only supports CBR.
I'm pretty okay with a car company saying that if you overhauled your car, it's your responsibility to deal with it if it breaks. Even if you were responsible, proving so would require them to go through each of your dozen amateurish modifications to find and prove which one caused the problem, which raises the cost for the rest of us.
Now granted, there's some reasonable middle between "can't touch it without voiding the warranty" and "manufacturer has to honor the warranty even if you turned your car into a rice rocket," but I certainly oppose the latter.
I think with the car example, if you install an important part yourself and are not a qualified professional, the company may be able to argue you did an improper installation job. Similarly, if you install your own heatsink, AMD could argue that you installed it improperly (not a farfetched notion, as a lot of heatsinks are improperly installed).
This has nothing to do with OEM status, this has to do with voiding your warranty through improper usage. If you hook up the wrong battery to your car and it dies, you're not eligible for warranty service. Same here -- don't use the heatsink that comes with it, and it's your problem if it dies.
128kbps AAC is easily distinguishable from the CD is very many cases, especially anything with sharp transients. It is indeed significantly better than 128kbps MP3, but not by as much as you insinuate. I'd consider it more comparable to a 160-192 kbps MP3, which is not a range in which MP3 is reliably transparent.
Theoretically, 128kbps AAC should be transparent on nearly all samples, but that would require significantly more tuning than has been done thus far. Currently, the best-performing transparent codec is MPC (Muspack), which achieves its almost-always-transparent quality at 150-160kbps; AAC at these bitrates will be inferior (with current tunings) but still very good.
Note also that it depends heavily on the encoder. I sincerely hope Apple is using a better encoder than the currently available QuickTime AAC implementation, which is frankly horrible (the Nero AAC encoder is vastly better quality).
It's hard to say for sure, but SARS simply doesn't seem that deadly. With worse hygiene and containment certainly far more people would be infected, but it's unlikely such a huge percentage of them would die. Currently fatality rates are in the 2-4% range. Even if that'd double to 4-8% without modern medical care, that's still not near 40% (and that's not even necessarily the case; a lot of people that have recovered just recovered on their own, similarly to how you recover from a cold, not due to wonders of medical care).
Nature designs things in an incredibly complex way, because that's simply how evolution works -- there's certainly no software engineering notion of clean component separation and so on in evolution. So it ends up certainly being complex, working, and possibly even beautiful, but a nearly impossible to decipher mess of spaghetti. Sort of like an old-school assembly programming genius designing an enormous 500,000-line program in assembly -- it'll work beautifully, but nobody will have any idea what the hell is going on, or be able to modify it. Similar problems exist when trying to genetically engineer things; you're always going to mess something up.
Especially in light of the fact that history generally looks more kindly on Einstein than on von Braun and Opennheimer.
I may disagree with your attempts to silence me, but I will defend to the death your right to do so.
The authors can't revoke the license; it either remains valid, or it's automatically revoked due to a violation (the authors could perhaps sue to enforce such a revocation however).
In any case, simply suing IBM is not a violation of the GPL; are there any actual violations taking place, such as not publishing source code to modified binaries they distribute?
I see what you're saying now, but I don't think it works successfully for an EULA in the same way it does for the GPL. For it to work for an EULA, you would have to be commiting a default copyright violation by using the work without a license; however, you're not, since your are not making any copies, and only are in possession of one copy that was given to you by an authorized distributor. The GPL can work because it prevents you from making further copies (which invoke copyright law), but in absence of any copying taking place, I don't see how an EULA can employ copyright law for its enforcement.
There was money in your account, and it has been removed. There is no such removal taking place in the "loss of sales" scenario.
I'm not saying copyright infringement is not wrong, just that it is wrong in a different way from theft. One is wrong due to actual removal of someone's property, while the other is wrong due to denial of potential profits.
Acceptance of the GPL isn't required to use software. The only time you have to accept the GPL is if you want to distribute GPL'd software (either the original or a derived version). Even then, you don't have to accept it because of an EULA; you have to accept it because if you don't, you have no right to distribute the software (since in absense of the GPL or any other license grant, copyright reverts to "All Rights Reserved" status).
That's "denying company money they are rightfully owned for that product or service," which is not the same as "illicitly removing an object from someone's possession." Your credit card example is theft, because nobody cares about the "copying" of credit card numbers; they care about the thief removing your money from your possession.
This is Slashdot, you're not supposed to post useful information. A "RTFA!" would've been more appropriate.
What's a PIM in this context?