It's a reciprocity clause. Suppose A holds some patents, and they've contributed them to software S and licensed them for use there. Now, B comes along and sues everybody using software S (including A) claiming that it infringes some other patents held by B. If B uses S themselves, the clause is intended to insure that B loses their license to A's patents, opening them to being counter-sued by A for patent infringement. The idea is to force a situation where a patent-holder can't block everyone else from benefiting from a piece of software while continuing to benefit from it themselves.
Fallacy: that physically taking something is the only way to harm them. If someone steals your personal information (SSN and such) and uses it to take out a bunch of loans in your name, then defaults on them, they haven't taken anything from you but they've definitely harmed you nonetheless. They did the hard work, you want to make your profit based on that work without doing it yourself and without compensating them. Not kosher.
I know several off-hand. In some cases they're people I've gifted with computers but who can't afford the ongoing price of phone service. In others it's because they live in places where there simply is no Internet service. No, cel phones don't work, there's no towers in range. No, dial-up doesn't work, the phone lines don't run out that far. Yes, there are place like this around, a fair lot of them in fact.
And even if that weren't the case, the FSF is still clear about it: you cannot place restrictions or limitations on the rights granted by the GPL. If the person simply doesn't want to get an Internet connection, they still are entitled to contact you and get source code from you. The GPL doesn't say they're only entitled to request source code if they have an Internet connection, if you attempt to add such a condition (explicitly or implicitly) then you're in violation of the GPL.
And no, before you ask, a court won't find this particularly novel. Every company in the US, for example, is required to have a snail-mail address as an official corporate contact address for legal purposes. That requirement exists for the same reason: if you're in a position to need to serve legal papers on a company, the law doesn't require you to have telephone service to do so so the company can't require it either.
Save for one problem: copyright law vests the sole right to create that new work in the original author. The translator had no right to create his new work regardless of how much effort went into it or how much value it created. It's the same thing as someone stealing money and using it to start a successful business. When all's said and done, he still stole the money and the law isn't going to leave the fruits of that crime in his hands.
And the recipient who doesn't have Internet access is supposed to use the URL how? As I noted, the FSF looked at this and concluded that just because the recipient doesn't have an Internet connection doesn't lift the distributor's obligation to provide them with source code. And a URL is unacceptable as a contact point for the same reason: it leaves recipients without an Internet connection with no usable contact point to request the source code as they're entitled to do.
Ask yourself this. Suppose you wrote a book. Suppose I go and translate it into another language (without a license from you) and begin selling copies. Suppose I record someone reading it onto audio tape and begin selling copies. Suppose I run it through a scanner and turn the scanned images into a PDF and begin selling it. What does copyright law hold on those scenarios? Answer that and you've answered your questions.
Short form, copyright applies to the source code. That copyright carries over into any derivative works such as a compiled binary.
I think the judge looked at the paragraph a bit further on in that section where it talks about providing access to the source as a download from a server, and noted that that case is explicitly allowed only when the software itself is also distributed as a download. That led him to the conclusion that clause B that you quote, when it talks of "medium customarily used for software interchange", means exactly what it says: an actual copy on some storage medium, logic being that if it allowed downloads from servers then it wouldn't have been neccesary later to explicitly allow downloads from servers. Combine that with failing to include the license text when the license says plainly in section 1 that you must include a copy of it's text and the judge's decision doesn't seem unreasonable.
And I know the issue of downloads of source has been discussed, and IIRC the FSF's position is that it's not acceptable on it's own. Network servers can be taken down, files on them can be removed, some recipients may not have Internet access but none of those cases lifts the obligation to provide source code. The only way a distributor can guarantee he'll always be able to meet that obligation is to be prepared to provide source on a physical medium. The case of providing downloadable source for downloadable software was actually viewed as falling under 3a, not 3b, that is source code being provided along with the software itself, which makes a world of difference in the distributor's obligations.
Yes and no. If you dynamically link against glibc (the default situation for every compiler and system I know of), then the LGPL explicitly says that you do not have to place your work under the GPL. This is, BTW, the primary purpose of the LGPL: to make exactly this exception to the GPL for libraries.
If you staticly link against glibc, it becomes a bit more complicated. The LGPL says you don't have to place your work under the GPL just because it's linked against an LGPL'd library, but that you do have to provide the user with a way of modifying the LGPL'd portion (the library code) and relinking it with your program. In practice this means distributing your program as object modules and providing all the makefiles or compiler/linker commands to let the user perform the link step and produce the executable. You'll also have to provide usable copies of all the other libraries your program uses (unless they come standard with the target system), you aren't allowed to foist off the problem of getting all the neccesary libraries on the user. This can be problematic if your program uses non-open-source libraries, since you may not have a license to distribute standalone copies of them (ie. not linked into an executable). But to be honest, static linking has enough technical issues that I'd recommend not doing it regardless of licensing. It's a maintenance nightmare for you (having to re-release executables every time any of the linked-in libraries has a bug-fix release) and a headache for your users (who have to deal with those re-releases and programs with library versions that don't match their installed versions and have incompatibilities with installed configuration and data files) and it's usually best to just Not Go There.
There won't be an issue with GCC, under either GPL v2 or v3. The compiler's license only matters if the code you wrote is a derivative work of the compiler, which means it physically includes code that's part of the compiler, and the small bit of code that's part of GCC that must be included in the compiled code is explicitly exempted from the GPL provisions (the terms are essentially BSD-no-attribution).
You might want to also consider that you have the same worries using Visual Studio as you do using GCC. Code compiled with MS's compiler needs the same bit of code from the compiler included in the final program as code compiled with GCC, and for the same reasons. There's also several library files that may be needed for VC++-compiled programs, depending on which options you use when compiling. Those files are classified as "redistributables", and they are under a license. The terms shouldn't be a problem for normal programs, just as the GCC bits aren't a problem for normal programs, but if you're worried about the GCC issues you need to worry about the same issues in Visual Studio for the same reason.
What prevents it would be this clause in the recommended language for placing a work under the GPL:
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
Note the "as published by the Free Software Foundation" in there. Something called the General Public License published by someone other than the FSF wouldn't qualify under that language. Section 14 of GPLv3 has similar language, so the "or any later version" language in the license wouldn't include any purported GPL version published by someone other than the FSF.
Difference between the EGCS fork and this
on
GCC 4.2.1 Released
·
· Score: 1
The EGCS fork had one big thing different from this work: time and weight of code. EGCS happened because GCC wasn't being maintained, wasn't being updated to support new CPUs and wasn't accepting contributions. EGCS ran for quite a few years and amassed a considerable volume of code by the time GCC restarted. The FSF "conceded defeat" and merged GCC into EGCS simply because there was too much code that was only in EGCS and it simply wasn't feasible to replicate that many years worth of work. In any GPLv2/GPLv3 fork of GCC, the GPLv2 branch won't have a mass of code and time in existence to give it weight. The GPLv3 branch won't either, but it will have the advantage of the name and recognition as the "official" branch in the community. It'll also be able to use any contributions to the GPLv2 fork that are under v2-or-later license terms, while the v2 fork won't be able to use any contributions to the v3 mainline. Unless the GPLv2 fork attracts a lot of the major GCC contributors and convinces them to change their license to GPLv2-only, I don't see a v2 fork staying viable for long under those circumstances.
Why? Casinos give away money all the time. I go to Vegas, just about every hotel and motel in town gives me a package of coupons good for free money at one casino or another, whether it be free chips, free credits for slot machines, a free meal at the restaurants or whatnot. Casinos do it directly too, with "clubs" that give free credits for joining or playing a certain amount. So what would be so unusual about a casino running a "10 for 1" promo deal on a single machine, where for a limited time anyone playing that machine gets 10 credits for every coin they put in?
Not likely. In CA, and the other states I've lived in, the law on gas-pump prices is straightforward: the maximum price the station can charge is the lowest of the price posted on any visible sign and the price showing on the pump. If the pump shows $0.419 as the price, any attempt to charge more than that is in itself illegal (CA considers it a misdemeanor IIRC). Doesn't matter why the pump's showing that, that's the station's problem. Now, the station isn't obliged to sell fuel at all at that price, they're allowed to simply shut the pump down and refuse everybody, but if they're selling fuel at all they've got to abide by the prices they post.
LiON batteries slowly discharge over time. If the laptop's plugged in and the battery's installed, as the battery loses charge a bit the charging circuit kicks on to top it up. That puts the battery through a charge cycle, and LiON cells only have a certain number of charge cycles they can do before they start losing the ability to take a charge.
What I want is for charging circuits to be smarter: if you're on wall power and the battery starts out at more than 75% charge, disable charging until the battery drops below 50% unless the operator explicitly asks for charging.
These same "researchers" predicted that computers would make paper disappear from the office. Today offices deal with more paper than ever because electronic documents just don't do the job.
Laptops are popular with businesses because they can do double duty: plug into a docking station with a fixed monitor and keyboard for desktop use, but allow employees to take it home to do work after hours or on weekends. At the same time, though, those laptops are no end of hassle when dealing with the corporate network. Desktops, being nailed down to just one network, can just be configured and you're set. The laptops have to be able to deal with being on insecure outside networks, and the extra software to handle that is just a nightmare when they're attached to the corporate network. Not to mention that almost all of them currently are infected with several viruses and they're spreading them to the company net. The desktops aren't nearly as much of a problem in this regard. Business likes the cost savings, but a lot of people where I work are opting to keep their desktop boxes and use their own laptops instead of having the company give them a laptop (and take away their nice reliable desktop machine).
Then of course there's gaming. Very few laptops compare well to a desktop box when it comes to gaming performance. Gaming hardware eats too much power and throws off too much heat, and gamers don't like sacrificing performance.
My sense is that desktop PC shipments are dropping not because of any lack of demand for desktops. It's more that most people are satisfied with the box they've got now and are just upgrading components for a couple hundred dollars rather than buying a whole new system, and that people are going to white-box builders locally rather than buying from the big-name vendors. I know I can find higher-spec systems locally for better prices than I can find at Dell or the like. I mean, I built one for my niece earlier this year with hardware the equal of Dell's best gaming box but a cost around that of their mid-range non-gaming boxes. I've had to decline 4 requests to build systems since then, and pointed all 4 to local shops. I'm not surprised to see the big names seeing a drop-off in shipments.
Actually I think it is. The problem is that the sending MTA isn't talking to the receiving MTA. It's talking to a front-end server, which sends the mail to a spam-filtering service, which sends the mail to the actual mailserver that'll put it in the user's mailbox. At every step mail is queued so the front-end server's the only one that ever has a connection to the sender, but it's the filtering and delivery servers that'll generate the errors if errors there be. So it's either report errors by bouncing to an envelope or header address, or drop the mail into the bit-bucket without any error report. I can understand admins not wanting to report an error, I just this morning had to delete 250 bogus bounce messages from mailservers who believed a spammer when he forged my address as the From address in his spam run.
The only problem with going on the offensive is who to go on the offensive against. On a computer network it's fairly easy for the attacker to mask his identity behind that of third parties who don't even know they're being used, and it's very hard for the attacked party to tell whether any given attacker is a real one or merely an unwitting dupe (and all but impossible to determine who the true party behind it all is). If you lash out at a large number of parties who didn't realize they were involved in an attack on you and who the public at large views as innocent parties, you give yourself a major public-image problem along with a major legal problem. If you want to go on the offensive, you'd best be absolutely completely certain you're right and be able to back it up in court. And even then, I'd think twice before doing it.
Fast-flux takes advantage of the ability to set extremely low time-to-lives on DNS resource records. The shorter the TTL, the faster changes propagate out through the DNS cache network. This suggests a way of neutering fast-flux: implement a minimum TTL in DNS servers. Since most people depend on their ISP's DNS servers rather than going directly to the roots, this would effectively prevent the fast-flux record changes from propagating as fast as they need to to be effective. If, for example, an ISP put a 30-minute minimum TTL in place, then the A record for a given name would remain fixed for 30 minutes (modulo cache being filled and the record being forced out) regardless of what the fast-flux network did. And since the DNS servers enforcing the minimum typically aren't under the control of either the botnet or the infected machines, there's nothing the botnet operators can do about the situation. As a side-effect, this also cuts the load on the DNS network caused by PHBs who order 60-second TTLs on their records "so customers won't be inconvenience when we change our IP addresses".
Two glitches with the idea:
Changes to the NS records for a domain are also slowed down. When changing your NS records you need to make the changes but leave the old servers running in parallel long enough for the changes to trickle out to everybody.
Load balancing via round-robin DNS would be broken unless the caching servers also do rotation of the cached records in responses. I think BIND already does that.
Perfectly legal. In fact, forks based on code after the purchase date but before any change to a non-GPL license would be perfectly legal too. The GPL gives you all the rights you need, and you've got the code under that license regardless of anything Apple does. You only have a problem once Apple changes the license terms to something other than the GPL and releases new code under those terms. At that point you can still do everything you could before with the old code (Apple's change doesn't make your GPL-based license go away), you just can't touch the new code.
How major the fork is depends a lot on where the code's coming from. As the X Consortium found out way back when it tried to change the license on XFree86, when the majority of the code contributions come from other people it may be you that suffers when they fork and now the majority of the new code's being submitted to the fork and not your mainline.
Licensing of patches depends on the project. Normally copyright of code always remains with the author so copyright on the contributed code would lie with the contributor, not the CUPS author. Some projects, though, require assignment of copyright to the project before they'll accept submissions (the FSF's GNU toolset is the most well-known example) specifically to insure that the project retains complete control over licensing. I'm not sure which route CUPS took, but if they didn't require copyright assignment then they wouldn't have the right to change the license terms for any contributed code and would have to go to the actual authors to get permission for any changes.
My response to people who say "You've got nothing to hide, what's the problem?" is this:
Well then, you'll have no objection to having the transaction register of your checking account and credit cards published daily in the newspaper, will you. Nor a record of your phone calls, incoming and outgoing. Or having all your e-mail, personal as well as work, automatically copied to your boss, co-workers and spouse. After all, you've got nothing to hide, right?
It's not a matter of having nothing to hide. Even people with nothing to hide nonetheless have a lot of things that they don't want broadcast to the world. It's called one's personal business. A really good example is buying your wife an anniversary gift. There's absolutely nothing to hide there, but you still don't want her finding out about it until you give it to her. There's many things in life that're nothing to hide in the sense the "nothing to hide" crowd is using the phrase, but that nonetheless you want to keep private (at least from all but a selected few).
This is going to bite the rating company big-time. First thing, a fair percentage of the userbase does things that severely interfere with time-on-site measurements. Blocking cookies is an obvious one. Another is blocking of various Javascript functions like onunload that prevent the page from seeing the user leaving the site. Unless the site eliminates direct off-site links and always redirects through it's own page, which users tend not to like either. And even after resolving all those issues, what constitutes visiting or leaving a site in this day and age of tabbed browsing? Suppose I pull up a Google page and then open 10 search-result links in new tabs, all without closing any tabs. Who gets credit for my time on site? Surely if I spend 10 seconds looking at the Google page and 10 minutes looking at one of the search-result tabs it should be the site I'm looking at that gets credit for my time, but how can the monitoring page code know that I've switched to another tab? Not to mention how the monitoring code handles my leaving the site, and then leaving the site again 5 minutes later, and then leaving the site again a minute after that, as I open links in new tabs, close those tabs and open new ones without reloading the original page.
Done Web analytics. It ain't as easy as the Web analytics' company's salescritters would like you to believe.
There've been several, including the famous Linksys case. The thing is, only the defendant will be arguing to enforce the GPL in court. The plaintiff, the copyright holder, will be claiming only bog-standard copyright law. Copyright law that prohibits the defendant from making and distributing copies of the plaintiff's copyrighted work. The defendant would then be arguing that the GPL is a valid license that gives them the right to make and distribute those copies. If the defendant were to argue that the GPL isn't valid, the plaintiff would simply agree and then go "OK then, so what license do you have?". Defendant's in a pickle then, because the GPL was the only license he could point to and he's just succeeded in taking it out of the picture. Oops.:)
Seriously, I mainly work with desktop tower systems. Power consumption's an issue mainly when it comes to the monthly power bill, and the delta from one computer burning an extra 150 watts is rarely a killer there. Cooling mainly comes into play when deciding what sort of CPU cooler to install and what fans I'm going to put where in the case. Or maybe whether I'm going to stick to air or go to a water cooling system. It'd be a different matter if I was designing high-density rack-mount systems or laptops, or embedded or appliance systems where there's little or no ventilation or fan noise is intolerable, but for an ordinary tower system the big question is just "Can I get a big enough power reduction to make a >5% difference in the power bill while still hitting my target performance?".
Price points based on what? dollar to Hz? Dollar to power consumed? Straight Dollar to dollar?
Straight dollars. Essentially, if I spend $300, how much performance will that buy me from each company?
A well designed 2.5Ghz would be a better chip than a poorly designed 3GHz. what about duel/quad/infintium core chips?
Which is why I noted in that item that it's not a reliable guide for buying chips. There's a lot of things that affect performance anymore, FSB speed, FSB architecture, memory subsystem, cache, core interconnect, it gets slightly insane. But if you're a techie and like laying all that out on the table and analyzing it, it gets to be fairly interesting. I just wouldn't advise deciding on which chip to buy based on clock-speed-based comparisons (or any other single aspect, for that matter).
Slashdot Mirror
It's a reciprocity clause. Suppose A holds some patents, and they've contributed them to software S and licensed them for use there. Now, B comes along and sues everybody using software S (including A) claiming that it infringes some other patents held by B. If B uses S themselves, the clause is intended to insure that B loses their license to A's patents, opening them to being counter-sued by A for patent infringement. The idea is to force a situation where a patent-holder can't block everyone else from benefiting from a piece of software while continuing to benefit from it themselves.
Fallacy: that physically taking something is the only way to harm them. If someone steals your personal information (SSN and such) and uses it to take out a bunch of loans in your name, then defaults on them, they haven't taken anything from you but they've definitely harmed you nonetheless. They did the hard work, you want to make your profit based on that work without doing it yourself and without compensating them. Not kosher.
I know several off-hand. In some cases they're people I've gifted with computers but who can't afford the ongoing price of phone service. In others it's because they live in places where there simply is no Internet service. No, cel phones don't work, there's no towers in range. No, dial-up doesn't work, the phone lines don't run out that far. Yes, there are place like this around, a fair lot of them in fact.
And even if that weren't the case, the FSF is still clear about it: you cannot place restrictions or limitations on the rights granted by the GPL. If the person simply doesn't want to get an Internet connection, they still are entitled to contact you and get source code from you. The GPL doesn't say they're only entitled to request source code if they have an Internet connection, if you attempt to add such a condition (explicitly or implicitly) then you're in violation of the GPL.
And no, before you ask, a court won't find this particularly novel. Every company in the US, for example, is required to have a snail-mail address as an official corporate contact address for legal purposes. That requirement exists for the same reason: if you're in a position to need to serve legal papers on a company, the law doesn't require you to have telephone service to do so so the company can't require it either.
Save for one problem: copyright law vests the sole right to create that new work in the original author. The translator had no right to create his new work regardless of how much effort went into it or how much value it created. It's the same thing as someone stealing money and using it to start a successful business. When all's said and done, he still stole the money and the law isn't going to leave the fruits of that crime in his hands.
And the recipient who doesn't have Internet access is supposed to use the URL how? As I noted, the FSF looked at this and concluded that just because the recipient doesn't have an Internet connection doesn't lift the distributor's obligation to provide them with source code. And a URL is unacceptable as a contact point for the same reason: it leaves recipients without an Internet connection with no usable contact point to request the source code as they're entitled to do.
Ask yourself this. Suppose you wrote a book. Suppose I go and translate it into another language (without a license from you) and begin selling copies. Suppose I record someone reading it onto audio tape and begin selling copies. Suppose I run it through a scanner and turn the scanned images into a PDF and begin selling it. What does copyright law hold on those scenarios? Answer that and you've answered your questions.
Short form, copyright applies to the source code. That copyright carries over into any derivative works such as a compiled binary.
I think the judge looked at the paragraph a bit further on in that section where it talks about providing access to the source as a download from a server, and noted that that case is explicitly allowed only when the software itself is also distributed as a download. That led him to the conclusion that clause B that you quote, when it talks of "medium customarily used for software interchange", means exactly what it says: an actual copy on some storage medium, logic being that if it allowed downloads from servers then it wouldn't have been neccesary later to explicitly allow downloads from servers. Combine that with failing to include the license text when the license says plainly in section 1 that you must include a copy of it's text and the judge's decision doesn't seem unreasonable.
And I know the issue of downloads of source has been discussed, and IIRC the FSF's position is that it's not acceptable on it's own. Network servers can be taken down, files on them can be removed, some recipients may not have Internet access but none of those cases lifts the obligation to provide source code. The only way a distributor can guarantee he'll always be able to meet that obligation is to be prepared to provide source on a physical medium. The case of providing downloadable source for downloadable software was actually viewed as falling under 3a, not 3b, that is source code being provided along with the software itself, which makes a world of difference in the distributor's obligations.
Yes and no. If you dynamically link against glibc (the default situation for every compiler and system I know of), then the LGPL explicitly says that you do not have to place your work under the GPL. This is, BTW, the primary purpose of the LGPL: to make exactly this exception to the GPL for libraries.
If you staticly link against glibc, it becomes a bit more complicated. The LGPL says you don't have to place your work under the GPL just because it's linked against an LGPL'd library, but that you do have to provide the user with a way of modifying the LGPL'd portion (the library code) and relinking it with your program. In practice this means distributing your program as object modules and providing all the makefiles or compiler/linker commands to let the user perform the link step and produce the executable. You'll also have to provide usable copies of all the other libraries your program uses (unless they come standard with the target system), you aren't allowed to foist off the problem of getting all the neccesary libraries on the user. This can be problematic if your program uses non-open-source libraries, since you may not have a license to distribute standalone copies of them (ie. not linked into an executable). But to be honest, static linking has enough technical issues that I'd recommend not doing it regardless of licensing. It's a maintenance nightmare for you (having to re-release executables every time any of the linked-in libraries has a bug-fix release) and a headache for your users (who have to deal with those re-releases and programs with library versions that don't match their installed versions and have incompatibilities with installed configuration and data files) and it's usually best to just Not Go There.
There won't be an issue with GCC, under either GPL v2 or v3. The compiler's license only matters if the code you wrote is a derivative work of the compiler, which means it physically includes code that's part of the compiler, and the small bit of code that's part of GCC that must be included in the compiled code is explicitly exempted from the GPL provisions (the terms are essentially BSD-no-attribution).
You might want to also consider that you have the same worries using Visual Studio as you do using GCC. Code compiled with MS's compiler needs the same bit of code from the compiler included in the final program as code compiled with GCC, and for the same reasons. There's also several library files that may be needed for VC++-compiled programs, depending on which options you use when compiling. Those files are classified as "redistributables", and they are under a license. The terms shouldn't be a problem for normal programs, just as the GCC bits aren't a problem for normal programs, but if you're worried about the GCC issues you need to worry about the same issues in Visual Studio for the same reason.
What prevents it would be this clause in the recommended language for placing a work under the GPL:
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
Note the "as published by the Free Software Foundation" in there. Something called the General Public License published by someone other than the FSF wouldn't qualify under that language. Section 14 of GPLv3 has similar language, so the "or any later version" language in the license wouldn't include any purported GPL version published by someone other than the FSF.
The EGCS fork had one big thing different from this work: time and weight of code. EGCS happened because GCC wasn't being maintained, wasn't being updated to support new CPUs and wasn't accepting contributions. EGCS ran for quite a few years and amassed a considerable volume of code by the time GCC restarted. The FSF "conceded defeat" and merged GCC into EGCS simply because there was too much code that was only in EGCS and it simply wasn't feasible to replicate that many years worth of work. In any GPLv2/GPLv3 fork of GCC, the GPLv2 branch won't have a mass of code and time in existence to give it weight. The GPLv3 branch won't either, but it will have the advantage of the name and recognition as the "official" branch in the community. It'll also be able to use any contributions to the GPLv2 fork that are under v2-or-later license terms, while the v2 fork won't be able to use any contributions to the v3 mainline. Unless the GPLv2 fork attracts a lot of the major GCC contributors and convinces them to change their license to GPLv2-only, I don't see a v2 fork staying viable for long under those circumstances.
Why? Casinos give away money all the time. I go to Vegas, just about every hotel and motel in town gives me a package of coupons good for free money at one casino or another, whether it be free chips, free credits for slot machines, a free meal at the restaurants or whatnot. Casinos do it directly too, with "clubs" that give free credits for joining or playing a certain amount. So what would be so unusual about a casino running a "10 for 1" promo deal on a single machine, where for a limited time anyone playing that machine gets 10 credits for every coin they put in?
Not likely. In CA, and the other states I've lived in, the law on gas-pump prices is straightforward: the maximum price the station can charge is the lowest of the price posted on any visible sign and the price showing on the pump. If the pump shows $0.419 as the price, any attempt to charge more than that is in itself illegal (CA considers it a misdemeanor IIRC). Doesn't matter why the pump's showing that, that's the station's problem. Now, the station isn't obliged to sell fuel at all at that price, they're allowed to simply shut the pump down and refuse everybody, but if they're selling fuel at all they've got to abide by the prices they post.
LiON batteries slowly discharge over time. If the laptop's plugged in and the battery's installed, as the battery loses charge a bit the charging circuit kicks on to top it up. That puts the battery through a charge cycle, and LiON cells only have a certain number of charge cycles they can do before they start losing the ability to take a charge.
What I want is for charging circuits to be smarter: if you're on wall power and the battery starts out at more than 75% charge, disable charging until the battery drops below 50% unless the operator explicitly asks for charging.
These same "researchers" predicted that computers would make paper disappear from the office. Today offices deal with more paper than ever because electronic documents just don't do the job.
Laptops are popular with businesses because they can do double duty: plug into a docking station with a fixed monitor and keyboard for desktop use, but allow employees to take it home to do work after hours or on weekends. At the same time, though, those laptops are no end of hassle when dealing with the corporate network. Desktops, being nailed down to just one network, can just be configured and you're set. The laptops have to be able to deal with being on insecure outside networks, and the extra software to handle that is just a nightmare when they're attached to the corporate network. Not to mention that almost all of them currently are infected with several viruses and they're spreading them to the company net. The desktops aren't nearly as much of a problem in this regard. Business likes the cost savings, but a lot of people where I work are opting to keep their desktop boxes and use their own laptops instead of having the company give them a laptop (and take away their nice reliable desktop machine).
Then of course there's gaming. Very few laptops compare well to a desktop box when it comes to gaming performance. Gaming hardware eats too much power and throws off too much heat, and gamers don't like sacrificing performance.
My sense is that desktop PC shipments are dropping not because of any lack of demand for desktops. It's more that most people are satisfied with the box they've got now and are just upgrading components for a couple hundred dollars rather than buying a whole new system, and that people are going to white-box builders locally rather than buying from the big-name vendors. I know I can find higher-spec systems locally for better prices than I can find at Dell or the like. I mean, I built one for my niece earlier this year with hardware the equal of Dell's best gaming box but a cost around that of their mid-range non-gaming boxes. I've had to decline 4 requests to build systems since then, and pointed all 4 to local shops. I'm not surprised to see the big names seeing a drop-off in shipments.
Actually I think it is. The problem is that the sending MTA isn't talking to the receiving MTA. It's talking to a front-end server, which sends the mail to a spam-filtering service, which sends the mail to the actual mailserver that'll put it in the user's mailbox. At every step mail is queued so the front-end server's the only one that ever has a connection to the sender, but it's the filtering and delivery servers that'll generate the errors if errors there be. So it's either report errors by bouncing to an envelope or header address, or drop the mail into the bit-bucket without any error report. I can understand admins not wanting to report an error, I just this morning had to delete 250 bogus bounce messages from mailservers who believed a spammer when he forged my address as the From address in his spam run.
The only problem with going on the offensive is who to go on the offensive against. On a computer network it's fairly easy for the attacker to mask his identity behind that of third parties who don't even know they're being used, and it's very hard for the attacked party to tell whether any given attacker is a real one or merely an unwitting dupe (and all but impossible to determine who the true party behind it all is). If you lash out at a large number of parties who didn't realize they were involved in an attack on you and who the public at large views as innocent parties, you give yourself a major public-image problem along with a major legal problem. If you want to go on the offensive, you'd best be absolutely completely certain you're right and be able to back it up in court. And even then, I'd think twice before doing it.
Fast-flux takes advantage of the ability to set extremely low time-to-lives on DNS resource records. The shorter the TTL, the faster changes propagate out through the DNS cache network. This suggests a way of neutering fast-flux: implement a minimum TTL in DNS servers. Since most people depend on their ISP's DNS servers rather than going directly to the roots, this would effectively prevent the fast-flux record changes from propagating as fast as they need to to be effective. If, for example, an ISP put a 30-minute minimum TTL in place, then the A record for a given name would remain fixed for 30 minutes (modulo cache being filled and the record being forced out) regardless of what the fast-flux network did. And since the DNS servers enforcing the minimum typically aren't under the control of either the botnet or the infected machines, there's nothing the botnet operators can do about the situation. As a side-effect, this also cuts the load on the DNS network caused by PHBs who order 60-second TTLs on their records "so customers won't be inconvenience when we change our IP addresses".
Two glitches with the idea:
Perfectly legal. In fact, forks based on code after the purchase date but before any change to a non-GPL license would be perfectly legal too. The GPL gives you all the rights you need, and you've got the code under that license regardless of anything Apple does. You only have a problem once Apple changes the license terms to something other than the GPL and releases new code under those terms. At that point you can still do everything you could before with the old code (Apple's change doesn't make your GPL-based license go away), you just can't touch the new code.
How major the fork is depends a lot on where the code's coming from. As the X Consortium found out way back when it tried to change the license on XFree86, when the majority of the code contributions come from other people it may be you that suffers when they fork and now the majority of the new code's being submitted to the fork and not your mainline.
Licensing of patches depends on the project. Normally copyright of code always remains with the author so copyright on the contributed code would lie with the contributor, not the CUPS author. Some projects, though, require assignment of copyright to the project before they'll accept submissions (the FSF's GNU toolset is the most well-known example) specifically to insure that the project retains complete control over licensing. I'm not sure which route CUPS took, but if they didn't require copyright assignment then they wouldn't have the right to change the license terms for any contributed code and would have to go to the actual authors to get permission for any changes.
My response to people who say "You've got nothing to hide, what's the problem?" is this:
It's not a matter of having nothing to hide. Even people with nothing to hide nonetheless have a lot of things that they don't want broadcast to the world. It's called one's personal business. A really good example is buying your wife an anniversary gift. There's absolutely nothing to hide there, but you still don't want her finding out about it until you give it to her. There's many things in life that're nothing to hide in the sense the "nothing to hide" crowd is using the phrase, but that nonetheless you want to keep private (at least from all but a selected few).
This is going to bite the rating company big-time. First thing, a fair percentage of the userbase does things that severely interfere with time-on-site measurements. Blocking cookies is an obvious one. Another is blocking of various Javascript functions like onunload that prevent the page from seeing the user leaving the site. Unless the site eliminates direct off-site links and always redirects through it's own page, which users tend not to like either. And even after resolving all those issues, what constitutes visiting or leaving a site in this day and age of tabbed browsing? Suppose I pull up a Google page and then open 10 search-result links in new tabs, all without closing any tabs. Who gets credit for my time on site? Surely if I spend 10 seconds looking at the Google page and 10 minutes looking at one of the search-result tabs it should be the site I'm looking at that gets credit for my time, but how can the monitoring page code know that I've switched to another tab? Not to mention how the monitoring code handles my leaving the site, and then leaving the site again 5 minutes later, and then leaving the site again a minute after that, as I open links in new tabs, close those tabs and open new ones without reloading the original page.
Done Web analytics. It ain't as easy as the Web analytics' company's salescritters would like you to believe.
There've been several, including the famous Linksys case. The thing is, only the defendant will be arguing to enforce the GPL in court. The plaintiff, the copyright holder, will be claiming only bog-standard copyright law. Copyright law that prohibits the defendant from making and distributing copies of the plaintiff's copyrighted work. The defendant would then be arguing that the GPL is a valid license that gives them the right to make and distribute those copies. If the defendant were to argue that the GPL isn't valid, the plaintiff would simply agree and then go "OK then, so what license do you have?". Defendant's in a pickle then, because the GPL was the only license he could point to and he's just succeeded in taking it out of the picture. Oops. :)
In my case ventilation and cooling. :)
Seriously, I mainly work with desktop tower systems. Power consumption's an issue mainly when it comes to the monthly power bill, and the delta from one computer burning an extra 150 watts is rarely a killer there. Cooling mainly comes into play when deciding what sort of CPU cooler to install and what fans I'm going to put where in the case. Or maybe whether I'm going to stick to air or go to a water cooling system. It'd be a different matter if I was designing high-density rack-mount systems or laptops, or embedded or appliance systems where there's little or no ventilation or fan noise is intolerable, but for an ordinary tower system the big question is just "Can I get a big enough power reduction to make a >5% difference in the power bill while still hitting my target performance?".
Price points based on what? dollar to Hz? Dollar to power consumed? Straight Dollar to dollar?
Straight dollars. Essentially, if I spend $300, how much performance will that buy me from each company?
A well designed 2.5Ghz would be a better chip than a poorly designed 3GHz. what about duel/quad/infintium core chips?
Which is why I noted in that item that it's not a reliable guide for buying chips. There's a lot of things that affect performance anymore, FSB speed, FSB architecture, memory subsystem, cache, core interconnect, it gets slightly insane. But if you're a techie and like laying all that out on the table and analyzing it, it gets to be fairly interesting. I just wouldn't advise deciding on which chip to buy based on clock-speed-based comparisons (or any other single aspect, for that matter).