Your position assumes that there is such a thing as "Intellectual Property." This is a fairly recent idea, supposedly uniting the ideas of copyright, patent, and trademark, traditionally and actually separate areas of law.
Also, regarding the word "theft," I feel compelled to throw the dictionary at you:
"Webster's Revised Unabridged Dictionary (1913)" Theft Theft, n. OE. thefte, AS. thorni'efethe,
thorn=yfethe, thorne'ofethe. See Thief.
1. (Law) The act of stealing; specifically, the felonious
taking and removing of personal property, with an intent
to deprive the rightful owner of the same; larceny.
Note: To constitute theft there must be a taking without the
owner's consent, and it must be unlawful or felonious;
every part of the property stolen must be removed,
however slightly, from its former position; and it must
be, at least momentarily, in the complete possession of
the thief. See Larceny, and the Note under Robbery.
2. The thing stolen. R.
If the theft be certainly found in his hand alive,.
. . he shall restore double. --Ex. xxii. 4.
Notice the phrase "taking and removing." This does not happen when a copy is made.
Well, as you probably know, humor is a matter of taste. I found it funny. If you've been reading Slashdot long, you should know it's not much of serious news source.
Play a halfway realistic game like DOD, then. Like various other decent multiplayer games, it started as an independent, non-commercial project. I can say from experience that running around with a rocket weapon in that game does not give one an advantage over a rifleman. The rockets are for destroying tanks and blowing holes in walls, and carrying one around makes one very vulnerable. Ability to aim, maneuver using cover, master your weapon, and support your teammates are the vital skills.
Right, so the key is that you can get away with cheating and no one will care as long as you suck. Of course, I can't really imagine why you'd want to prove that you suck even with an unfair advantage.
Re:My experiences with Gentoo
on
Gentoo Reviewed
·
· Score: 1
You also don't have to reboot anything to build a new Gentoo system. You just need some functional GNU/Linux system. The install process is all inside a chroot environment, so the external environment could be anything: a previous Gentoo install, a Debian system, a Redhat system, etc. Who knows, it might even work from a BSD. The install from scratch does take a while, but it doesn't have to interrupt your use of an already functional system, as long as you have space for both. I've installed Gentoo a couple of times, but only booted from the CD the first.
The slow startup time of typical JVM's does make it feel slow and is a major annoyance. I believe at least part of the problem is that Java was originally designed to be used in a standalone enviornment instead of running on top of a general purpose operating system like *nix or Windows. When the JVM only starts once every few hours, startup time doesn't matter much. Echidna is an attempt to avoid the memory bloat and startup time of many JVM processes. I haven't tried it yet, but I probably will if I do much more with Java.
More generally, any language or runtime environment that is significantly different from that of the operating system is at a disadvantage. I wonder if any high level, dynamic, or interpreted language might benefit from a server or memory manager for the shared parts of the runtime, instead of each program having its own, independent runtime.
I'll have to remember that the next time I need to communicate with the Blah people of Blangor to tell them all 200 of their foos are bar. Seriously, though, (X)emacs has a very similar feature. I know this because I've accidently invoked it a few times, resulting in half a line of '('s or something, though I have yet to use it properly.
I am aware of XDirectFB, and I think it's a good idea, but I think the person who first mention DirectFB was talking about using DirectFB instead of X.
I'm using the regular XFree with the Nvidia driver. You're using DirectFB as the video hardware layer. All you've proven is that you can use an X server to display X clients. Great!
This issue in question is the communications layer of X. There are some people who think it would be better to avoid all communication abstraction, limiting GUI apps in the same ways they are on Win32.
Where did you find GNOME running on DirectFB? At least some of Gtk+ is working, but DirectFB is a thin hardware abstraction layer. I haven't seen any evidence it allows multiple processes to safely share the display.
I couldn't agree more about NAT. NAT is a great technique for getting around restrictions like too few addresses (whether there's a real shortage or whether it's artificial isn't clear), but it is a kludge that I hope will one day be unnecessary.
That helps my understanding a lot! Thanks. Of particular interest to me is the global motion compensation.
I've notice that the the scrolling credits at the end of the movie tends to be encoded badly and require disproportionately large bitrates, compared to the rest of the movie. It's occurred to me that the credits are really just a single, tall raster image, instead of a series of frames. Encoding a single JPEG (or even lossless PNG) for the whole credits sequence would result in huge savings. I've started leaving the credits off when I'm trying to fit a movie into a very small space, like one CD-R. Sometimes, I encode just the audio.
It sounds like using GMC properly, the same type of savings could be gained, while still encoding compliant MPEG-4. What do you think?
Even worse, the author didn't even mention ffmpeg, whose MPEG 4 video codec seems to be at least as good as (probably superior to) both Divx5 and Xvid. There is a Direct Show filter, so Win32 use should be quite possible. The author probably isn't aware of ffmpeg, since it's been primarily *nix only so far, but if optimizing quality vs. bitrate is desired, ffmpeg should be considered.
I can play SVQ3 (Sorensen Video 3) encoded video from Quicktime movies quite well with MPlayer. It uses the Windows Quicktime library, so it only works on x86. MPlayer's Quicktime demuxer is lacking some features, so sync is off in some movies (like the Animatrix shorts), but it can be fixed by setting the offset (11 seconds for the Animatrix ones).
Oddly, MPlayer drops fewer frames playing the huge (1000x540) Matrix trailer than the Quicktime player on Win98 on my limited 800 MHz Duron machine. There was no A-V sync problem. Also, re-encoding the video to MPEG 4 using ffmpeg's libavcodec through mencoder (part of MPLayer) allows me to watch the trailer on the same machine with almost no noticeable loss in quality.
MPlayer is a real *nix application: it's primarily command-line and terminal based, extremely flexible and powerful, and has a steep learning curve. Compiled with all the libraries it wants, it can play almost any movie you throw at it without much help from the user, but it requires reading the documentation and experimentation to get the most from it, especially for encoding or transcoding. Also, since it does depend on many external libraries, you may have to compile it yourself, especially since some of the codecs (SVQ3 and RealVideo, for instance) it uses are proprietary (but free beer), so their distribution may not be possible in binary-based GNU/Linux distributions.
I agree that AMD seems to be pulling ahead of Intel with Hammer, though the 386 backward compatibility is more important to proprietary Windows apps than to Free *nix ones. It seems like a very cool architecture.
What amazes me is how both Intel and AMD have managed to evolve x86 into a modern architecture without sacrificing backward compatibility. The MIPS RISC CPU's in the SGI machines can't compete with x86 chips any more, though the architecture is much younger.
Apparently, it was possible to incorporate the design gains of RISC while keeping the external interface the same. Of course, the most power efficient chips are still RISC.
Well, the obvious difference between the two is that you can implement a DSP (or any other kind of processor) using an FPGA, but not vice-versa. However, it's a lot more expensive per gate on the FPGA; there's always a tradeoff between cost and flexibility. If you know you're going to be doing a lot of the type of signal processing for which DSP's were designed, using a DSP is probably the way to go. On the other hand, if you might be doing some signal processing, or some DESing, or experimenting with a completely new class of parallel algorithms, the flexibility of an FPGA might be warranted.
Actually, modern Intel and AMD CPU's might be more capable than all but the most expensive non-specialized DSP's, though they're a lot less power and size efficient doing the same tasks. And software's always the most flexible.
What do mean by "will be available"? Native 64-bit Linux has been available for a number of years now on venerable platforms like Alpha and Sparc/64. More recently, it's been ported to Itanium and Hammer. I'm sure other Free OS's are available on 64-bit architectures, though I don't know details.
But, realistically, how much a processor can do is more important than its number of bits. Ironically, some film studios have been switching to GNU/Linux from the likes of Irix. They're not switching because GNU/Linux is inherently better than Irix, but because it runs on x86 chips, which are a lot faster than the SGI workstations (at least for the cost), though they're still only 32 bit machines.
Why do you assume there are such gnomes? Gnomes aren't human, so why would they have the same races that we do? For all we know, Gnome races are distinguished by the number warts on their left pinky toes. I think the gnomes would be offended by your lack of understanding of Gnome issues and the way you project your Human thinking onto them.
Isn't extortion usually about the money? I do see your point, though. Generally, it is a double standard to support someone just because they attack Microsoft, using any underhanded means possible, then condemn the same person for attacking IBM using the same means. The enemies of our enemies aren't necessarily our friends. Actually, I don't think of Microsoft, as an enemy, just too much power in one place.
Slashdot Mirror
It is supposed to be static right? You can't actually play Go in gv, can you?
Also, regarding the word "theft," I feel compelled to throw the dictionary at you:
Notice the phrase "taking and removing." This does not happen when a copy is made.
Well, as you probably know, humor is a matter of taste. I found it funny. If you've been reading Slashdot long, you should know it's not much of serious news source.
Echidna already does this. Also, see my other comment.
Play a halfway realistic game like DOD, then. Like various other decent multiplayer games, it started as an independent, non-commercial project. I can say from experience that running around with a rocket weapon in that game does not give one an advantage over a rifleman. The rockets are for destroying tanks and blowing holes in walls, and carrying one around makes one very vulnerable. Ability to aim, maneuver using cover, master your weapon, and support your teammates are the vital skills.
Right, so the key is that you can get away with cheating and no one will care as long as you suck. Of course, I can't really imagine why you'd want to prove that you suck even with an unfair advantage.
You also don't have to reboot anything to build a new Gentoo system. You just need some functional GNU/Linux system. The install process is all inside a chroot environment, so the external environment could be anything: a previous Gentoo install, a Debian system, a Redhat system, etc. Who knows, it might even work from a BSD. The install from scratch does take a while, but it doesn't have to interrupt your use of an already functional system, as long as you have space for both. I've installed Gentoo a couple of times, but only booted from the CD the first.
The slow startup time of typical JVM's does make it feel slow and is a major annoyance. I believe at least part of the problem is that Java was originally designed to be used in a standalone enviornment instead of running on top of a general purpose operating system like *nix or Windows. When the JVM only starts once every few hours, startup time doesn't matter much. Echidna is an attempt to avoid the memory bloat and startup time of many JVM processes. I haven't tried it yet, but I probably will if I do much more with Java.
More generally, any language or runtime environment that is significantly different from that of the operating system is at a disadvantage. I wonder if any high level, dynamic, or interpreted language might benefit from a server or memory manager for the shared parts of the runtime, instead of each program having its own, independent runtime.
Yeah, you're right; I failed to consult the Guide before posting. Silly me.
Yeah, you can survive for about a minute in outer space if you hold your breath, leaving plenty of time for an extremely improbable rescue. :)
I'll have to remember that the next time I need to communicate with the Blah people of Blangor to tell them all 200 of their foos are bar. Seriously, though, (X)emacs has a very similar feature. I know this because I've accidently invoked it a few times, resulting in half a line of '('s or something, though I have yet to use it properly.
I am aware of XDirectFB, and I think it's a good idea, but I think the person who first mention DirectFB was talking about using DirectFB instead of X.
I'm using the regular XFree with the Nvidia driver. You're using DirectFB as the video hardware layer. All you've proven is that you can use an X server to display X clients. Great!
This issue in question is the communications layer of X. There are some people who think it would be better to avoid all communication abstraction, limiting GUI apps in the same ways they are on Win32.
Where did you find GNOME running on DirectFB? At least some of Gtk+ is working, but DirectFB is a thin hardware abstraction layer. I haven't seen any evidence it allows multiple processes to safely share the display.
I couldn't agree more about NAT. NAT is a great technique for getting around restrictions like too few addresses (whether there's a real shortage or whether it's artificial isn't clear), but it is a kludge that I hope will one day be unnecessary.
That helps my understanding a lot! Thanks. Of particular interest to me is the global motion compensation.
I've notice that the the scrolling credits at the end of the movie tends to be encoded badly and require disproportionately large bitrates, compared to the rest of the movie. It's occurred to me that the credits are really just a single, tall raster image, instead of a series of frames. Encoding a single JPEG (or even lossless PNG) for the whole credits sequence would result in huge savings. I've started leaving the credits off when I'm trying to fit a movie into a very small space, like one CD-R. Sometimes, I encode just the audio.
It sounds like using GMC properly, the same type of savings could be gained, while still encoding compliant MPEG-4. What do you think?
Even worse, the author didn't even mention ffmpeg, whose MPEG 4 video codec seems to be at least as good as (probably superior to) both Divx5 and Xvid. There is a Direct Show filter, so Win32 use should be quite possible. The author probably isn't aware of ffmpeg, since it's been primarily *nix only so far, but if optimizing quality vs. bitrate is desired, ffmpeg should be considered.
I can play SVQ3 (Sorensen Video 3) encoded video from Quicktime movies quite well with MPlayer. It uses the Windows Quicktime library, so it only works on x86. MPlayer's Quicktime demuxer is lacking some features, so sync is off in some movies (like the Animatrix shorts), but it can be fixed by setting the offset (11 seconds for the Animatrix ones).
Oddly, MPlayer drops fewer frames playing the huge (1000x540) Matrix trailer than the Quicktime player on Win98 on my limited 800 MHz Duron machine. There was no A-V sync problem. Also, re-encoding the video to MPEG 4 using ffmpeg's libavcodec through mencoder (part of MPLayer) allows me to watch the trailer on the same machine with almost no noticeable loss in quality.
MPlayer is a real *nix application: it's primarily command-line and terminal based, extremely flexible and powerful, and has a steep learning curve. Compiled with all the libraries it wants, it can play almost any movie you throw at it without much help from the user, but it requires reading the documentation and experimentation to get the most from it, especially for encoding or transcoding. Also, since it does depend on many external libraries, you may have to compile it yourself, especially since some of the codecs (SVQ3 and RealVideo, for instance) it uses are proprietary (but free beer), so their distribution may not be possible in binary-based GNU/Linux distributions.
I agree that AMD seems to be pulling ahead of Intel with Hammer, though the 386 backward compatibility is more important to proprietary Windows apps than to Free *nix ones. It seems like a very cool architecture.
What amazes me is how both Intel and AMD have managed to evolve x86 into a modern architecture without sacrificing backward compatibility. The MIPS RISC CPU's in the SGI machines can't compete with x86 chips any more, though the architecture is much younger.
Apparently, it was possible to incorporate the design gains of RISC while keeping the external interface the same. Of course, the most power efficient chips are still RISC.
I think the other guys actually has some scruples and would like to avoid shooting people if possible.
Well, the obvious difference between the two is that you can implement a DSP (or any other kind of processor) using an FPGA, but not vice-versa. However, it's a lot more expensive per gate on the FPGA; there's always a tradeoff between cost and flexibility. If you know you're going to be doing a lot of the type of signal processing for which DSP's were designed, using a DSP is probably the way to go. On the other hand, if you might be doing some signal processing, or some DESing, or experimenting with a completely new class of parallel algorithms, the flexibility of an FPGA might be warranted.
Actually, modern Intel and AMD CPU's might be more capable than all but the most expensive non-specialized DSP's, though they're a lot less power and size efficient doing the same tasks. And software's always the most flexible.
What do mean by "will be available"? Native 64-bit Linux has been available for a number of years now on venerable platforms like Alpha and Sparc/64. More recently, it's been ported to Itanium and Hammer. I'm sure other Free OS's are available on 64-bit architectures, though I don't know details.
But, realistically, how much a processor can do is more important than its number of bits. Ironically, some film studios have been switching to GNU/Linux from the likes of Irix. They're not switching because GNU/Linux is inherently better than Irix, but because it runs on x86 chips, which are a lot faster than the SGI workstations (at least for the cost), though they're still only 32 bit machines.
Are you saying the Ogre population was underrepresented?
Why do you assume there are such gnomes? Gnomes aren't human, so why would they have the same races that we do? For all we know, Gnome races are distinguished by the number warts on their left pinky toes. I think the gnomes would be offended by your lack of understanding of Gnome issues and the way you project your Human thinking onto them.
Isn't extortion usually about the money? I do see your point, though. Generally, it is a double standard to support someone just because they attack Microsoft, using any underhanded means possible, then condemn the same person for attacking IBM using the same means. The enemies of our enemies aren't necessarily our friends. Actually, I don't think of Microsoft, as an enemy, just too much power in one place.
Well, maybe I will. I just haven't needed more speed yet.