Actually, you *can* use it, even in countries with brain-damaged views on patentability of algorithms. It's just not legal.:-) I've been happily using bladeenc for quite a while now, and Fraunhofer (sp?) hasn't come knocking at my door... The only people that they can (practically speaking, not legally) go after are the producers and distributors of the software. And if they're based in a country with a sane government, they're safe. And people can and will download and use it from other countries, even though it's illegal.
I don't know about you, but I do pronounce route as "r-ow!-te". "root" is what you have when you see an octothorpe, not the path something takes to arrive at its destination.
But wouldn't that only apply to distributing statically linked binaries? Dynamically linked binaries (which are almost always what is distributed) do not contain the libraries until they are linked together at runtime, which is when the derived work is formed. The only issue is whether the header files that are compiled into KDE are restricted by the Qt license. Whether this is true depends on what they contain... IANAL, but IIRC #defines and prototypes and the like are not copyrightable. If, OTOH, there are macros or inline functions in there, that could be a problem, unless Qt were to exempt the header files from their license.
The intention behind the GPL is not to deprive people of money, but to prevent proprietary modifications to GPLed code. The money Red Hat makes is not from selling proprietary versions of GPLed software, nor is the money that O'Reilly or the various other entrepreneurs you mentioned.
The GPL also does not eliminate the ablility for companies to produce proprietary software; it simply denies them the ability to incorporate GPLed software into their own. Nobody is forced to GPL their software, so it isn't depriving anyone of an opportunity to make money.
Actually, the Linux TCP/IP stack is not BSD-based, although other parts of the kernel are (several drivers, for instance).
However, do FreeBSD, NetBSD, and OpenBSD not all ship with gcc? And though it's not the default shell on BSD, bash is quite commonly used on most Unices. There are even ports of bash and other GNU utilities to windoze.
So, in terms of number of users, neither the BSD license nor the GPL have any distinct advantage over the other.
Of course, the bottleneck would then be loading the files off of the server's hard disk, so unless you've got a really slow hard disk, it still wouldn't be faster.
Actually, wouldn't the Xeon chips be the fastest shipping x86 chips, considering that the Xeons not only have integrated L2 cache, but they have more of it than the K6-3?
Now, the fastest *reasonably priced* x86 CPU is another matter entirely.:-)
Actually, the DirectX API is publicly documented; if it weren't, it would be very difficult for people to write games that use it. As such, a clean-room implementation that works from just that documentation is possible, and is being done by the Wine people.
what about the tortilla wrap ?!?!?!?
on
OSI vs Taco Bell
·
· Score: 1
My guess is that the napkin serves as a garbage collector, cleaning up after the network stack's memory allocations.
You're missing the point. It's not the games that are emulated; it's the console. Emulating the behavior of a piece of hardware does not violate anyone's copyright, while distributing copies of software that runs on it is. Emulators do the former, not the latter, and hence cannot be used for piracy. That many people choose to commit piracy to obtain games to run in the emulators is a completely separate issue, and irrelevant to the legality/morality of emulators.
You are quite capable of switching modes with fbcon, unless you use vesafb, which can only set a mode at boot time. Yes, you are limited to graphical modes, but that's really not a problem, as the console works just as well, and (with hardware accelerated drivers like matroxfb) is damned near as fast. And with the drivers that support scrollback, you can get huge scrollback buffers if you have enough video memory.
Of course, I don't suppose there's anything stopping a framebuffer from supporting text as well as graphics, seeing as there was a text-only framebuffer a while ago. It's just not as much of an issue as it might seem.
But are they really going to call the 1e+04 to 1e+05 ISPs, Universities, and managers it would require to shut everyone, or even a good portion, of them down?
Hmm, I was just thinking of the same thing. Probably the best thing would be a modified form of Usenet, with no expiration and a method of moderation/cancellation (to keep out spam and other unwanted crap, and to allow newer, more accurate versions of songs to replace older ones) while preventing abuse of such facilities (which would be difficult to accomplish... how to differentiate between someone nuking a spam that got in and the RIAA nuking legitimate songs...) Combine it with a method of distributing information about new servers going up and old servers going down, and it should do it.
Without a Usenet-type organization where individual entries propagate, a central repository would be required to prevent divergent versions, which is no good if that central repository goes away.
Heh, I've had a P166 running Linux in the 250 range through intentional fork-bombing, and managed to bring it back without a reboot. Granted it was a shell-based fork bomb, which was really easy to kill (just delete the script), but I was still able to enter that rm command, after many, many tries.:-)
I used to believe that excuse
on
e.themes.org
·
· Score: 1
Before you complain about the kernel when X brings your system down, please do an ls -l of your X server binary. Wait! Is that "rwsr-xr-x" you see? Followed by "root root"??? I think it is. *Any* program running with root privileges can completely halt *any* kernel. As a simple example on Linux/i386, try
int main() { iopl(3); asm("cli"); }
and run it as root (unmount and sync first!) The problem is not the kernel, it's that such an obscenely complex program as the X server is given complete power over the system.
I would think that software that has been patched to add the functionality of reading the number from the chip and sending it over the Net would also be patched to disable such functionality at the same time. If not, then just don't upgrade your software until it is. It's not as if existing software will automagically do this stuff.
Plus, I'm guessing that the software to be modified is the apps, not the OS, as it's the apps which talk over the network. (At least, I hope they don't plan on embedding this thing into TCP/IP itself...)
Slashdot Mirror
Actually, you *can* use it, even in countries with brain-damaged views on patentability of algorithms. It's just not legal. :-) I've been happily using bladeenc for quite a while now, and Fraunhofer (sp?) hasn't come knocking at my door... The only people that they can (practically speaking, not legally) go after are the producers and distributors of the software. And if they're based in a country with a sane government, they're safe. And people can and will download and use it from other countries, even though it's illegal.
I don't know about you, but I do pronounce route as "r-ow!-te". "root" is what you have when you see an octothorpe, not the path something takes to arrive at its destination.
Umm... I hope you mean 90F... 90C (194F) is above the maximum operating temperature for humans, too.
Isn't it $70 now?
But wouldn't that only apply to distributing statically linked binaries? Dynamically linked binaries (which are almost always what is distributed) do not contain the libraries until they are linked together at runtime, which is when the derived work is formed. The only issue is whether the header files that are compiled into KDE are restricted by the Qt license. Whether this is true depends on what they contain... IANAL, but IIRC #defines and prototypes and the like are not copyrightable. If, OTOH, there are macros or inline functions in there, that could be a problem, unless Qt were to exempt the header files from their license.
The intention behind the GPL is not to deprive people of money, but to prevent proprietary modifications to GPLed code. The money Red Hat makes is not from selling proprietary versions of GPLed software, nor is the money that O'Reilly or the various other entrepreneurs you mentioned.
The GPL also does not eliminate the ablility for companies to produce proprietary software; it simply denies them the ability to incorporate GPLed software into their own. Nobody is forced to GPL their software, so it isn't depriving anyone of an opportunity to make money.
Actually, the Linux TCP/IP stack is not BSD-based, although other parts of the kernel are (several drivers, for instance).
However, do FreeBSD, NetBSD, and OpenBSD not all ship with gcc? And though it's not the default shell on BSD, bash is quite commonly used on most Unices. There are even ports of bash and other GNU utilities to windoze.
So, in terms of number of users, neither the BSD license nor the GPL have any distinct advantage over the other.
Of course, the bottleneck would then be loading
the files off of the server's hard disk, so
unless you've got a really slow hard disk, it
still wouldn't be faster.
Actually, wouldn't the Xeon chips be the fastest
:-)
shipping x86 chips, considering that the Xeons
not only have integrated L2 cache, but they have
more of it than the K6-3?
Now, the fastest *reasonably priced* x86 CPU
is another matter entirely.
Actually, the DirectX API is publicly
documented; if it weren't, it would be very
difficult for people to write games that use it.
As such, a clean-room implementation that works
from just that documentation is possible, and is
being done by the Wine people.
My guess is that the napkin serves as a garbage collector, cleaning up after the network stack's memory allocations.
You're missing the point. It's not the games that
are emulated; it's the console. Emulating the
behavior of a piece of hardware does not violate
anyone's copyright, while distributing copies of
software that runs on it is. Emulators do the
former, not the latter, and hence cannot be used
for piracy. That many people choose to commit
piracy to obtain games to run in the emulators
is a completely separate issue, and irrelevant
to the legality/morality of emulators.
Umm, could you provide references for this claim?
fbcon, unless you use vesafb, which can only set
a mode at boot time. Yes, you are limited to
graphical modes, but that's really not a problem,
as the console works just as well, and (with
hardware accelerated drivers like matroxfb) is
damned near as fast. And with the drivers that
support scrollback, you can get huge scrollback
buffers if you have enough video memory.
Of course, I don't suppose there's anything stopping a framebuffer from supporting text as well as graphics, seeing as there was a text-only framebuffer a while ago. It's just not as much of an issue as it might seem.
But are they really going to call the 1e+04 to
1e+05 ISPs, Universities, and managers it would
require to shut everyone, or even a good portion,
of them down?
Without a Usenet-type organization where individual entries propagate, a central repository would be required to prevent divergent versions, which is no good if that central repository goes away.
Heh, I've had a P166 running Linux in the 250 :-)
range through intentional fork-bombing, and
managed to bring it back without a reboot.
Granted it was a shell-based fork bomb, which
was really easy to kill (just delete the script),
but I was still able to enter that rm command,
after many, many tries.
int main()
{
iopl(3);
asm("cli");
}
and run it as root (unmount and sync first!) The problem is not the kernel, it's that such an obscenely complex program as the X server is given complete power over the system.
Of course they care if it compiles... :-)
They couldn't possibly release *source*, could they?
Plus, I'm guessing that the software to be modified is the apps, not the OS, as it's the apps which talk over the network. (At least, I hope they don't plan on embedding this thing into TCP/IP itself...)