Wouldn't compressing the newsfeed transmission help a lot more than using a mostly-8-bit encoding method? UUencode compresses fairly well; if you're already compressing the transmission and try to send compressed data down the line, you basically get no additional compression, so 8-bit or 6-bit encoding schemes are almost identical. It'll save a bit of disk space if you're storing the newsfeed uncompressed, but disk space is cheap, right? Note that for people connected via modem, virtually all of them are already using compression, so pre-compression doesn't really help much, if any.
As an example:
bash is 316848 bytes on my machine; compressed with gzip (-6) it is 142711 bytes long; compressing again with gzip saves less than 100 bytes.
compressing with gzip, then uuencoding, then compressing with gzip again yields 148962 bytes, or about 4% more than sending the compressed bash through gzip.
if you use LZW for the transmission (e.g. as with compress), it depends on what you send; sending bash through 8-bit vs. uuencoded does give an increase of about 28%; however, if you gzip bash first, then the uuencoded version is actually smaller after compressing with compress (187423 vs. 177937).
At the same time, you're also compressing all those text messages, with all those lovely redundant headers to help increase the compression ratio. I've always assumed people pulling down large newsfeeds (as opposed to retrieving individual articles) were using compression (or connecting using compression from the modem).
Under US law, minors cannot agree to the GPL. Therefore they cannot modify or distribute code licensed under the GPL, because:
No, as several other people have said, a minor can enter into an agreement/contract/license. However, in some cases, that minor can later back out. Doesn't matter to the GPL - once you back out of the agreement, then you can't distribute it any more. At worst, it might mean that if you choose to distribute it with the written offer option for the source, you could later decide not to honor that written offer. That won't keep me up late at night, I tell you.
Was section 117, allowing copying that is necessary to run the software by a person who owns or has been authorized by someone who owns an authorized copy of the software, added after MAI v Peak? There's also a paragraph in there specifically authorizing "maintenance" type work, perhaps that was what was added.
I thought that the key element of MAI v Peak was that the clients didn't own a copy of the software, they were leasing it (along with the machine), and thus weren't able to authorize Peak to do "make copies" of the programs by running it while doing maintenance. The key decision was that copying into RAM was indeed copying. That doesn't mean you can't do it, even without an EULA.
It causes some stumbling in the writing sometimes too, but they believe it's the right thing to do.
Sony does the same thing with the PS/2 memory cards. "Insert the memory card or the memory card for PS/2 (8 MB). If the memory card or the memory card for PS/2 (8 MB) is full, insert another memory card or memory card for PS/2 (8 MB). If you have two memory cards or memory cards for PS/2 (8 MB), you can use both memory cards or memory cards for PS/2 (8 MB) at once. Do not remove a memory card or memory card for PS/2 (8 MB) while it is being accessed."
I don't understand all the "wherein"s in this patent. Are those conjunctions or unions? It's all in one claim, so I'd think that to infringe on the patent you'd have to have every single element listed in all the wherein clauses. Yet, the last two are directly contradictory:
wherein the network server and the game server are physically proximate to each other and directly connected together;
wherein the network server and the game server are geographically remote from each other and the network server interfaces with the game server via the network.
If you'd have to have every single element listed in that claim to infringe on it, this is the most ridiculously specific patent I've ever seen. Regardless of the merits with regard to innovation or creativity, or the existence of relevant prior art, I'm not sure this thing could be infringed if you tried.
If, instead, all those wherein clauses are independent, shouldn't they have each been separate claims?
The fourth-to-last wherein also seems to have a typo, I think it is missing the word "include", thus:
wherein the preferences
include a level of skill of other game players simultaneously playing a game as reflected by their game player statistics;
Haven't there been plenty of cases where an employee is held to be acting for the company, even in cases where he is not actually authorized to be doing so? Why wouldn't that be held to be the case here? It would be inequitable for people who reasonably relied on the code being released under the Artistic License and/or GPL to find that they can't continue to do work based on that code. Maybe the company owns full rights to it, and could thus release future versions under any license they wanted (though, as I understand it, under the AL there wouldn't be much need to), but it sounds to me as if the code was legitimately released, even if the person who released it wasn't authorized to do so. Of course, IANAL, I'm just a reasonable person.
They (the company and/or whoever had mandated the "contractual obligations") probably then included you in their statistics of how many drug users the drug testing managed to eliminate from their contractor base, thus justifying further drug testing...
Ok, that makes Staples the first place I've ever seen a non-upgrade version of Windows for sale (and you're right - the full version is $199, the upgrade is $99, for both ME and XP home edition). As for the OEM versions, it really depends on how they got them. If they got them unbundled from the OEM, then the OEM is in violation of their license with Microsoft. At best, they're "grey market" goods.
That's true, and I don't blame Microsoft for wanting that revenue stream. However, just because they want it doesn't mean they deserve it, nor that laws shouldn't prevent it.
While Walmart undoubtedly can license Windows for less than $300, your price points are not valid: you say that you see boxed Windows for sale for about $200 - but those are upgrade prices, aren't they? I've never seen any non-upgrade versions of Windows for sale in retail stores. Never ever.
Then you talk about vendors selling OEM versions on Pricewatch - how are they getting those OEM versions? If they're the OEM, they are certainly violating their license with Microsoft; if not, they're presumably selling unused ex-bundled copies from machines where the buyer didn't want Windows - which may be legal even if Microsoft doesn't think so - but that just shows that there is a pretty good market for machines that don't come with Windows in the first place. Or else, they're from companies that have some sort of site license with Microsoft and think that means they don't need the pre-installed version (which is false, at least for the site licenses I've heard about, and that provision has a much better likelihood of being enforceable).
Would a Web server that sends a Java applet to a browser violate that clause? I would suspect, given the emphasis on "per user" licensing, that would be OK (because it is the user at the workstation that is "running" the Java applet, even though the request was brokered by the Web server).
However, that would certainly seem to mean that you couldn't set up a personal Web page without a server license, unless you're sure that ONLY Windows XP machines can access it (or people who, for whatever reason, have a license for XP, even though they're not running it).
I don't recall any such restrictions on Mac OS X, but I don't have a copy of the terms in front of me. Their newly released "Remote Desktop" product does have a limit on number of clients, but I'm not sure if that's a traditional simultaneous connections type of license or not (they also have an unlimited license). I'm also not sure if that includes a license for the client itself, or just for an already licensed client to connect. Apple certainly makes it simple to enable a Web server and other services on your machine, so they don't seem to be trying to lock you down like Microsoft is.
That's not quite right. I just took a look at this the other day, and they've actually done a very good job of allowing you to have extensions, have extensions (but hide them from you), or not have extensions (relying only on the type/creator codes). If the file has no type, then the extension is used. If the file is transferred to another system that needs extensions to figure out the file type, then it is all ready to go. If you simply don't want the file to have a visible extension, you can turn that on or off on a per-file basis. They go to a lot of trouble to include the meta- and resource-forks on a non-HFS file system.
What they've done is made extensions much more useable, if you want them, but without forcing it down your throat, and continuing to handle seamlessly the type/creator information as well. A very good compromise for dealing with a world that still relies on extensions.
It means the recording industry should be smarter next time.
They are getting smarter. They're adding encryption and getting laws passed to make it illegal to bypass that encryption (not that they need the encryption once they have the laws - Macrovision is trivial to defeat, but all VCRs are now required to detect it - might as well have been a simple bit that says "don't copy me" - oh wait, they did that in CDs).
The problem is that the distributors want to have their cake and eat it too. If they want the benefits of a mass market, they have to accept the drawbacks of a mass market. If they were willing to negotiate with each consumer and get a signed contract specifying exactly what could and could not be done with a copy, I wouldn't have a problem with anything they did. That would simply be a matter for contract law. But to expect us to pay for the government to enforce copyright beyond what the Constitution allows for (that is, along with patents, "to promote the Arts and Sciences") is simply unreasonable.
They're getting the advantage of a mass market, and the enforcement of (limited) Copy Rights, if they can't make money on that, the "free market" (as much as it is) will find companies that can make money under those conditions. The only excuse for copyright is if it makes MORE content FREELY available to the public over time; we're exchanging a short-term scarcity for long-term plenty. That's the "Copyright Bargain".
Trade secrets are the only "natural property rights" that should be accorded to "intellectual property"; it follows the rule that "if you don't want someone to have access to it, keep it to yourself." Once you publish something, it has become public.
The word "effective" should be read as "having the effect of", not "is pretty good at". Regardless, it seems a stretch to me that putting something on a ROM and putting that ROM in a cartridge constitutes a "protection measure".
It seems to me that the major problem with the DMCA is that the protection measure that you're not allowed to circumvent only has to protect ONE right of a copyright holder in order to be banned, even if the measure protects rights that the copyright holder DOESN'T hold and you're circumventing the measure in order to do something that the copyright holder doesn't have the right to prevent.
Boiling water releases oxygen? Funny, I always thought it was the vaporized water (also known as steam, for the technically inclined) that caused water to boil, not oxygen!
Boiling water cools off fairly rapidly when poured into an uncovered ceramic cup. Much more rapidly than when poured into a styrofoam cup and covered with a lid. It also doesn't crush and spill when you try to take off the lid. Trying to compare home use of a coffee maker with serving coffee in a take-out container is foolish.
Walking from a normally lit room out into the sunlight can mean a change in ambient brightness of around a factor of 400.
A large part of that is the iris clamping down. Cameras can do the same thing. The eye is still astounding, but you're overstating the range it can see in a single scene. The interior of that room, when you're outside, would have few or no visible details.
From what I gather, it's a way of measuring light directly onto a chip, without having to go through the CCD process.
From what you quoted, DPS technology, in contrast, intelligently combines both image capture and image processing into a single system, which allows for both design simplicity and improved image quality. By marrying the quality of CCDs... it sounds like they're simply integrating a CCD with some DSP onto a single chip, hardly a way of avoiding or replacing "the CCD process".
Nope, I don't have that choice with Ameritech (now Ameritech/SBC). The only choice I have for local calls is $0.05/call (prime, something like 40 and 60% off at other times).
What if Red Hat buys their copies from someone else (who offers the sources to Red Hat, or provides the written offer, although Red Hat doesn't bother to take a copy of the source; or else, takes a copy of a source CD with each binary CD, then shreds it), then Red Hat re-sells the binary CD to you and I (without providing us with the sources)? Of course, "someone else" that they're buying from is the actual distributor, they create modified versions of GPLed software, and they sell it ONLY to Red Hat, who then does the actual end-user distribution.
I suppose you might make the argument that such a relationship between two independent companies is clearly not normal, and thus the two companies must really be one, and thus they have no right to distribute the binaries without the sources, regardless of what artificial boundaries they may throw in - but would such an argument actually work?
Since when do Microsoft own ECMA ? Microsofts implementation is controlled by Microsoft, but the standard itself isn't. Why don't Sun submit to a standards body ? It's primarily because they want to retain control,
So let me get this straight - ECMA controls the standard and will let anyone change and extend it however they want, including Microsoft, and when Microsoft does change it, that doesn't matter because everyone else will continue to use the ECMA-standardized version (or not use it the same way they've been not using it), right? But with big bad Java, since it hasn't been submitted to an independent standards body, no one can change it or implement their own version of it, but Sun can change it however they want and that's terrible, because then everyone will be forced to adopt their changes to the language. So,.NET will be so much better, because everyone will be platform independent, in so many different ways, and we can finally break that monopoly that Microsoft has been holding over the world and get on with our non-interoperable lives!
Ignoring, of course, the points that a) if you produce something that is incompatible with the ECMA standard, you won't be able to call it C# (just like Java); b) if Microsoft changes the definition, ECMA can either tag along or be stuck with an irrelevant standard; c) Microsoft has already extended the CLR well past the standard; and d) Sun doesn't have a lock on Java, either the definition or the implementation; that they wouldn't allow Microsoft to use the Java trademark on something that violated the definition of Java (instead of properly extending it, which they could have done if their motive wasn't to try to hijack it as well) does not show that Sun has either the inclination or the legal right to prevent, say, gjc or kaffe from being written, either to the standard, to a changed standard, or extending the standard.
But anyone (including Bill Gates) could create a version of Basic and call it 'Basic'. As a result everyone knew what it was. It was part of the idea space for Basic, even if it wasn't exactly a kosher 'Basic'. So Basic, despite being technically less powerful, ended up owning the most mind-share.
Excellent idea! Sun should just rename Java to Basic (maybe call it J-Basic), and all those VB programmers will start using it. After all, VB is no more BASIC than Java is (everyone knows that BASIC has line numbers; truly advanced BASIC lets you RENumber your program, too bad Applesoft never did, I'm sure that's why it isn't a mainstream version of BASIC these days).
Y'all know that a halt() call that specifies a non-powerdown halt is basically a no-op, right? I mean, it does check that you're running as root, but then it does nothing:
From linux-2.4.14/arch/i386/kernel/process.c
void machine_halt(void)
{
}
(the machine_power_off routine also does nothing unless there is a poweroff function enabled; since, the halt isn't actually doing a poweroff (or it won't be doing a good job of routing after that) it presumably isn't set).
All that's being done by the process desc ribed in the article is a) bring down all running services except for the network; b) make init wait to die (I haven't looked at init to see if it waits for a normal ctrl-alt-del interrupt, then do a reboot, or if it just sets the kernel to handle ctl-alt-del and reboot all by itself). It doesn't even kill all other running processes that might be running, just the ones that were started by init (e.g. getty) and processes that remain in those process groups. If someone starts up a background job, it will still be there. There's nothing magic about run level 0 - it is just a convention that init uses.
Not all drives are unmounted - the root device will still be mounted read-only, maybe/proc and other pseudo-file systems will still be there. init is still running. This is a lower level of security than starting the kernel up by running a shell script that enables the network and ipchains, then sleeps forever. You could even have that shell script leave you in a plain old shell if you want to do be able to do something else (you'd have to know how to mount filesystems and remember to unmount them (since init won't be running, you can't just do a simple "shutdown" anymore), etc).
Here's an example script that might be used. Start it by passing "init=/netstart" (or wherever you put the script) to the kernel when you reboot:
#!/bin/sh
mount proc/proc -t proc
mount -o ro/usr /etc/rc.d/init.d/network start /etc/rc.d/init.d/ipchains start
umount/usr
exec/bin/sh
If there's a hole in the TCP stack itself, or in the IPchains routing, that opens up some vulnerability, it doesn't really matter if there's a simple/bin/sh running or not (if you really want to be secure, have the shell script exec a simple C program that checks to make sure it is PID 1; does a kill(-1, SIGKILL) and then sigsuspend() in a loop; now you're safe unless someone's hacked your kernel, libc or compiler).
I note that in 2.2, if process 1 exits, it kills the kernel; in 2.4, it gives a "Kernel panic: Attempted to kill init!". In either case, the effect is the same: ctrl-alt-del is disabled, and the kernel stops routing packets.
I always tell my computer "<product name>: the following portions of your license agreement are hereby changed: remove all sections, replace with section 1: the use of this software is governed by the copyright laws of the United States; by allowing me into the program after I click that I agree with the modified agreement, you are agreeing that these new terms hold".
Actually, an IP lawyer I know of supposedly crosses out all the portions of a shrinkwrap license, puts his initials next to it, then opens the package. If it's a valid agreement, my changes are just as valid as their proposal; if they didn't want me to change it, they should have sent a person along to accept the agreement, instead of letting a computer click or the act of opening the package signify agreement. Or, more to the point, if it is a legally binding contract, show me YOUR copy of what I agreed to, including the indication that I actually did agree to it.
Modifying the program to not refuse to run if you click on Disagree is probably allowable under copyright law, as well.
Re:interpretation is the only way to guarantee saf
on
Bill Joy's Takes on C#
·
· Score: 1, Redundant
No, it is safe because it is verifiable. What that means is a formal proof that the code doesn't violate various constraints (such as accessing memory that it shouldn't - which usually requires some level of type safety, checking arguments to function calls, etc). Once you have that level of "safety", you can then add in security models (e.g., inhibit "unlink" calls) and be sure that the code isn't going to subvert that model (such as roaming a pointer through memory looking for the permissions your code is allowed, and changing it to give yourself more permission once you find it).
It's just a side-effect that the specific byte-codes are designed to be verifiable, where machine code is generally not (and should not - at the implementation level, you eventually have to get down and dirty, and where attempting to be "safe" would be much too slow). Once it's been verified, it can be turned into native code and it remains just as safe.
I think Microsoft is just confusing the issue by calling it "safe" and "unsafe". It should be a matrix of "verifiable" vs. "unverifiable" and "trusted" vs. "untrusted". Code marked as "safe", but which fails the verification proof, should never be run, regardless of any code-signing levels of trust. Other than that, there isn't really any reason to mark code either way, except to avoid the overhead of trying to start checking unverifiable code when you know it is going to fail. It sounds like the "unsafe" attribute is mostly just a way to mark the source code so that a programmer doesn't inadvertently use unverifiable techniques.
Then C is a scripting language also, and the term becomes meaningless. Whether a language can be translated to run directly on the hardware, or needs an interpreter, is mostly irrelevant (a true scripting language is unlikely to be able, or find it useful, to be translated into a native application.
A scripting language is more a collection of attributes than a hard-and-fast distinction. Most scripting languages are translated directly from source in an interpreter; usually the interpreter is embedded in a program that does other useful things, which the scripting language can control; usually the end user can specify and modify some or all of the scripts that get executed at different times, either to add extensions or to configure the application. Some things are more one than the other, such as various dialects of BASIC.
Slashdot Mirror
Wouldn't compressing the newsfeed transmission help a lot more than using a mostly-8-bit encoding method? UUencode compresses fairly well; if you're already compressing the transmission and try to send compressed data down the line, you basically get no additional compression, so 8-bit or 6-bit encoding schemes are almost identical. It'll save a bit of disk space if you're storing the newsfeed uncompressed, but disk space is cheap, right? Note that for people connected via modem, virtually all of them are already using compression, so pre-compression doesn't really help much, if any.
As an example:
bash is 316848 bytes on my machine; compressed with gzip (-6) it is 142711 bytes long; compressing again with gzip saves less than 100 bytes.
compressing with gzip, then uuencoding, then compressing with gzip again yields 148962 bytes, or about 4% more than sending the compressed bash through gzip.
if you use LZW for the transmission (e.g. as with compress), it depends on what you send; sending bash through 8-bit vs. uuencoded does give an increase of about 28%; however, if you gzip bash first, then the uuencoded version is actually smaller after compressing with compress (187423 vs. 177937).
At the same time, you're also compressing all those text messages, with all those lovely redundant headers to help increase the compression ratio. I've always assumed people pulling down large newsfeeds (as opposed to retrieving individual articles) were using compression (or connecting using compression from the modem).
No, as several other people have said, a minor can enter into an agreement/contract/license. However, in some cases, that minor can later back out. Doesn't matter to the GPL - once you back out of the agreement, then you can't distribute it any more. At worst, it might mean that if you choose to distribute it with the written offer option for the source, you could later decide not to honor that written offer. That won't keep me up late at night, I tell you.
Was section 117, allowing copying that is necessary to run the software by a person who owns or has been authorized by someone who owns an authorized copy of the software, added after MAI v Peak? There's also a paragraph in there specifically authorizing "maintenance" type work, perhaps that was what was added.
I thought that the key element of MAI v Peak was that the clients didn't own a copy of the software, they were leasing it (along with the machine), and thus weren't able to authorize Peak to do "make copies" of the programs by running it while doing maintenance. The key decision was that copying into RAM was indeed copying. That doesn't mean you can't do it, even without an EULA.
Sony does the same thing with the PS/2 memory cards. "Insert the memory card or the memory card for PS/2 (8 MB). If the memory card or the memory card for PS/2 (8 MB) is full, insert another memory card or memory card for PS/2 (8 MB). If you have two memory cards or memory cards for PS/2 (8 MB), you can use both memory cards or memory cards for PS/2 (8 MB) at once. Do not remove a memory card or memory card for PS/2 (8 MB) while it is being accessed."
I don't understand all the "wherein"s in this patent. Are those conjunctions or unions? It's all in one claim, so I'd think that to infringe on the patent you'd have to have every single element listed in all the wherein clauses. Yet, the last two are directly contradictory:
If you'd have to have every single element listed in that claim to infringe on it, this is the most ridiculously specific patent I've ever seen. Regardless of the merits with regard to innovation or creativity, or the existence of relevant prior art, I'm not sure this thing could be infringed if you tried.
If, instead, all those wherein clauses are independent, shouldn't they have each been separate claims?
The fourth-to-last wherein also seems to have a typo, I think it is missing the word "include", thus:
Haven't there been plenty of cases where an employee is held to be acting for the company, even in cases where he is not actually authorized to be doing so? Why wouldn't that be held to be the case here? It would be inequitable for people who reasonably relied on the code being released under the Artistic License and/or GPL to find that they can't continue to do work based on that code. Maybe the company owns full rights to it, and could thus release future versions under any license they wanted (though, as I understand it, under the AL there wouldn't be much need to), but it sounds to me as if the code was legitimately released, even if the person who released it wasn't authorized to do so. Of course, IANAL, I'm just a reasonable person.
They (the company and/or whoever had mandated the "contractual obligations") probably then included you in their statistics of how many drug users the drug testing managed to eliminate from their contractor base, thus justifying further drug testing...
Ok, that makes Staples the first place I've ever seen a non-upgrade version of Windows for sale (and you're right - the full version is $199, the upgrade is $99, for both ME and XP home edition). As for the OEM versions, it really depends on how they got them. If they got them unbundled from the OEM, then the OEM is in violation of their license with Microsoft. At best, they're "grey market" goods.
That's true, and I don't blame Microsoft for wanting that revenue stream. However, just because they want it doesn't mean they deserve it, nor that laws shouldn't prevent it.
While Walmart undoubtedly can license Windows for less than $300, your price points are not valid: you say that you see boxed Windows for sale for about $200 - but those are upgrade prices, aren't they? I've never seen any non-upgrade versions of Windows for sale in retail stores. Never ever.
Then you talk about vendors selling OEM versions on Pricewatch - how are they getting those OEM versions? If they're the OEM, they are certainly violating their license with Microsoft; if not, they're presumably selling unused ex-bundled copies from machines where the buyer didn't want Windows - which may be legal even if Microsoft doesn't think so - but that just shows that there is a pretty good market for machines that don't come with Windows in the first place. Or else, they're from companies that have some sort of site license with Microsoft and think that means they don't need the pre-installed version (which is false, at least for the site licenses I've heard about, and that provision has a much better likelihood of being enforceable).
Would a Web server that sends a Java applet to a browser violate that clause? I would suspect, given the emphasis on "per user" licensing, that would be OK (because it is the user at the workstation that is "running" the Java applet, even though the request was brokered by the Web server).
However, that would certainly seem to mean that you couldn't set up a personal Web page without a server license, unless you're sure that ONLY Windows XP machines can access it (or people who, for whatever reason, have a license for XP, even though they're not running it).
I don't recall any such restrictions on Mac OS X, but I don't have a copy of the terms in front of me. Their newly released "Remote Desktop" product does have a limit on number of clients, but I'm not sure if that's a traditional simultaneous connections type of license or not (they also have an unlimited license). I'm also not sure if that includes a license for the client itself, or just for an already licensed client to connect. Apple certainly makes it simple to enable a Web server and other services on your machine, so they don't seem to be trying to lock you down like Microsoft is.
That's not quite right. I just took a look at this the other day, and they've actually done a very good job of allowing you to have extensions, have extensions (but hide them from you), or not have extensions (relying only on the type/creator codes). If the file has no type, then the extension is used. If the file is transferred to another system that needs extensions to figure out the file type, then it is all ready to go. If you simply don't want the file to have a visible extension, you can turn that on or off on a per-file basis. They go to a lot of trouble to include the meta- and resource-forks on a non-HFS file system.
What they've done is made extensions much more useable, if you want them, but without forcing it down your throat, and continuing to handle seamlessly the type/creator information as well. A very good compromise for dealing with a world that still relies on extensions.
They are getting smarter. They're adding encryption and getting laws passed to make it illegal to bypass that encryption (not that they need the encryption once they have the laws - Macrovision is trivial to defeat, but all VCRs are now required to detect it - might as well have been a simple bit that says "don't copy me" - oh wait, they did that in CDs).
The problem is that the distributors want to have their cake and eat it too. If they want the benefits of a mass market, they have to accept the drawbacks of a mass market. If they were willing to negotiate with each consumer and get a signed contract specifying exactly what could and could not be done with a copy, I wouldn't have a problem with anything they did. That would simply be a matter for contract law. But to expect us to pay for the government to enforce copyright beyond what the Constitution allows for (that is, along with patents, "to promote the Arts and Sciences") is simply unreasonable.
They're getting the advantage of a mass market, and the enforcement of (limited) Copy Rights, if they can't make money on that, the "free market" (as much as it is) will find companies that can make money under those conditions. The only excuse for copyright is if it makes MORE content FREELY available to the public over time; we're exchanging a short-term scarcity for long-term plenty. That's the "Copyright Bargain".
Trade secrets are the only "natural property rights" that should be accorded to "intellectual property"; it follows the rule that "if you don't want someone to have access to it, keep it to yourself." Once you publish something, it has become public.
The word "effective" should be read as "having the effect of", not "is pretty good at". Regardless, it seems a stretch to me that putting something on a ROM and putting that ROM in a cartridge constitutes a "protection measure".
It seems to me that the major problem with the DMCA is that the protection measure that you're not allowed to circumvent only has to protect ONE right of a copyright holder in order to be banned, even if the measure protects rights that the copyright holder DOESN'T hold and you're circumventing the measure in order to do something that the copyright holder doesn't have the right to prevent.
Boiling water releases oxygen? Funny, I always thought it was the vaporized water (also known as steam, for the technically inclined) that caused water to boil, not oxygen!
Boiling water cools off fairly rapidly when poured into an uncovered ceramic cup. Much more rapidly than when poured into a styrofoam cup and covered with a lid. It also doesn't crush and spill when you try to take off the lid. Trying to compare home use of a coffee maker with serving coffee in a take-out container is foolish.
A large part of that is the iris clamping down. Cameras can do the same thing. The eye is still astounding, but you're overstating the range it can see in a single scene. The interior of that room, when you're outside, would have few or no visible details.
From what you quoted, DPS technology, in contrast, intelligently combines both image capture and image processing into a single system, which allows for both design simplicity and improved image quality. By marrying the quality of CCDs... it sounds like they're simply integrating a CCD with some DSP onto a single chip, hardly a way of avoiding or replacing "the CCD process".
Nope, I don't have that choice with Ameritech (now Ameritech/SBC). The only choice I have for local calls is $0.05/call (prime, something like 40 and 60% off at other times).
What if Red Hat buys their copies from someone else (who offers the sources to Red Hat, or provides the written offer, although Red Hat doesn't bother to take a copy of the source; or else, takes a copy of a source CD with each binary CD, then shreds it), then Red Hat re-sells the binary CD to you and I (without providing us with the sources)? Of course, "someone else" that they're buying from is the actual distributor, they create modified versions of GPLed software, and they sell it ONLY to Red Hat, who then does the actual end-user distribution.
I suppose you might make the argument that such a relationship between two independent companies is clearly not normal, and thus the two companies must really be one, and thus they have no right to distribute the binaries without the sources, regardless of what artificial boundaries they may throw in - but would such an argument actually work?
So let me get this straight - ECMA controls the standard and will let anyone change and extend it however they want, including Microsoft, and when Microsoft does change it, that doesn't matter because everyone else will continue to use the ECMA-standardized version (or not use it the same way they've been not using it), right? But with big bad Java, since it hasn't been submitted to an independent standards body, no one can change it or implement their own version of it, but Sun can change it however they want and that's terrible, because then everyone will be forced to adopt their changes to the language. So, .NET will be so much better, because everyone will be platform independent, in so many different ways, and we can finally break that monopoly that Microsoft has been holding over the world and get on with our non-interoperable lives!
Ignoring, of course, the points that a) if you produce something that is incompatible with the ECMA standard, you won't be able to call it C# (just like Java); b) if Microsoft changes the definition, ECMA can either tag along or be stuck with an irrelevant standard; c) Microsoft has already extended the CLR well past the standard; and d) Sun doesn't have a lock on Java, either the definition or the implementation; that they wouldn't allow Microsoft to use the Java trademark on something that violated the definition of Java (instead of properly extending it, which they could have done if their motive wasn't to try to hijack it as well) does not show that Sun has either the inclination or the legal right to prevent, say, gjc or kaffe from being written, either to the standard, to a changed standard, or extending the standard.
Excellent idea! Sun should just rename Java to Basic (maybe call it J-Basic), and all those VB programmers will start using it. After all, VB is no more BASIC than Java is (everyone knows that BASIC has line numbers; truly advanced BASIC lets you RENumber your program, too bad Applesoft never did, I'm sure that's why it isn't a mainstream version of BASIC these days).
Y'all know that a halt() call that specifies a non-powerdown halt is basically a no-op, right? I mean, it does check that you're running as root, but then it does nothing:
From linux-2.4.14/arch/i386/kernel/process.c
void machine_halt(void)
{
}
(the machine_power_off routine also does nothing unless there is a poweroff function enabled; since, the halt isn't actually doing a poweroff (or it won't be doing a good job of routing after that) it presumably isn't set).
All that's being done by the process desc ribed in the article is a) bring down all running services except for the network; b) make init wait to die (I haven't looked at init to see if it waits for a normal ctrl-alt-del interrupt, then do a reboot, or if it just sets the kernel to handle ctl-alt-del and reboot all by itself). It doesn't even kill all other running processes that might be running, just the ones that were started by init (e.g. getty) and processes that remain in those process groups. If someone starts up a background job, it will still be there. There's nothing magic about run level 0 - it is just a convention that init uses.
Not all drives are unmounted - the root device will still be mounted read-only, maybe /proc and other pseudo-file systems will still be there. init is still running. This is a lower level of security than starting the kernel up by running a shell script that enables the network and ipchains, then sleeps forever. You could even have that shell script leave you in a plain old shell if you want to do be able to do something else (you'd have to know how to mount filesystems and remember to unmount them (since init won't be running, you can't just do a simple "shutdown" anymore), etc).
Here's an example script that might be used. Start it by passing "init=/netstart" (or wherever you put the script) to the kernel when you reboot:
/proc -t proc /usr
/etc/rc.d/init.d/network start
/etc/rc.d/init.d/ipchains start /usr /bin/sh
#!/bin/sh
mount proc
mount -o ro
umount
exec
If there's a hole in the TCP stack itself, or in the IPchains routing, that opens up some vulnerability, it doesn't really matter if there's a simple /bin/sh running or not (if you really want to be secure, have the shell script exec a simple C program that checks to make sure it is PID 1; does a kill(-1, SIGKILL) and then sigsuspend() in a loop; now you're safe unless someone's hacked your kernel, libc or compiler).
I note that in 2.2, if process 1 exits, it kills the kernel; in 2.4, it gives a "Kernel panic: Attempted to kill init!". In either case, the effect is the same: ctrl-alt-del is disabled, and the kernel stops routing packets.
I always tell my computer "<product name>: the following portions of your license agreement are hereby changed: remove all sections, replace with section 1: the use of this software is governed by the copyright laws of the United States; by allowing me into the program after I click that I agree with the modified agreement, you are agreeing that these new terms hold".
Actually, an IP lawyer I know of supposedly crosses out all the portions of a shrinkwrap license, puts his initials next to it, then opens the package. If it's a valid agreement, my changes are just as valid as their proposal; if they didn't want me to change it, they should have sent a person along to accept the agreement, instead of letting a computer click or the act of opening the package signify agreement. Or, more to the point, if it is a legally binding contract, show me YOUR copy of what I agreed to, including the indication that I actually did agree to it.
Modifying the program to not refuse to run if you click on Disagree is probably allowable under copyright law, as well.
No, it is safe because it is verifiable. What that means is a formal proof that the code doesn't violate various constraints (such as accessing memory that it shouldn't - which usually requires some level of type safety, checking arguments to function calls, etc). Once you have that level of "safety", you can then add in security models (e.g., inhibit "unlink" calls) and be sure that the code isn't going to subvert that model (such as roaming a pointer through memory looking for the permissions your code is allowed, and changing it to give yourself more permission once you find it).
It's just a side-effect that the specific byte-codes are designed to be verifiable, where machine code is generally not (and should not - at the implementation level, you eventually have to get down and dirty, and where attempting to be "safe" would be much too slow). Once it's been verified, it can be turned into native code and it remains just as safe.
I think Microsoft is just confusing the issue by calling it "safe" and "unsafe". It should be a matrix of "verifiable" vs. "unverifiable" and "trusted" vs. "untrusted". Code marked as "safe", but which fails the verification proof, should never be run, regardless of any code-signing levels of trust. Other than that, there isn't really any reason to mark code either way, except to avoid the overhead of trying to start checking unverifiable code when you know it is going to fail. It sounds like the "unsafe" attribute is mostly just a way to mark the source code so that a programmer doesn't inadvertently use unverifiable techniques.
Then C is a scripting language also, and the term becomes meaningless. Whether a language can be translated to run directly on the hardware, or needs an interpreter, is mostly irrelevant (a true scripting language is unlikely to be able, or find it useful, to be translated into a native application.
A scripting language is more a collection of attributes than a hard-and-fast distinction. Most scripting languages are translated directly from source in an interpreter; usually the interpreter is embedded in a program that does other useful things, which the scripting language can control; usually the end user can specify and modify some or all of the scripts that get executed at different times, either to add extensions or to configure the application. Some things are more one than the other, such as various dialects of BASIC.