What restriction is there on who can park on the street in front of your house? None. Anybody can do it. So while yes there's a physical radius, you have no idea who's within that radius and you know it. That one of those somebodies is from Google and they've got a tape recorder running is one of those things that everybody ought to be expecting. After all, first rule: if it's embarrassing or sensitive or otherwise might be a problem if someone found it out, and you're saying it in the middle of a crowd of strangers, you'd better assume one of them will be taking notes (because one of them will be and you'll find out about it at the least opportune moment). Ditto for standing outside the front door of your house. If you're naked except for a pink tutu and you're counting on nobody but your neighbors (who understand you were just the butt of a practical joke and accidentally latched the door chasing the pranksters out of your house) seeing you, the photographers from the local scandal rag will be cruising by and will catch you on film and it will show up in the local paper with a suitably scathing blurb. If you're really unlucky, it'll be both the photogs and the local cops.
I have one question, though: exactly how much privacy do people expect, given that what Google collected was what those people were broadcasting in the clear to the world at large? It's the equivalent of Google listening to what people are saying sitting at the corner coffee shop. Face it, when you're talking in public with strangers standing right next to you listening, you don't expect what you say to go unheard. So, why do you expect what you're broadcasting with the moral equivalent of a bullhorn to remain private? You want it private? Either don't broadcast it at all or at least encrypt it before broadcasting it.
Oh, you say the average person doesn't know better? Sorry, they should know better, and if they don't they should know better than to try without getting expert help. No excuses. This isn't rocket science. We've had personal computers for over 30 years. We carry sophisticated ones in our pockets and use them to make phone calls. It's well past high time the average person was expected to have a basic understanding of what they're so casually carrying around and using every day, and past time we stopped making excuses for the ones who just can't be bothered. You shouldn't need to know the details of how encryption works in 802.11*, but you should at least know as much as "I need encryption turned on, and if I don't know where and how to turn it on I need to either RTFM or ask someone who does know for help.".
More important than asking why Google collected this information is asking why people were so negligently reckless as to broadcast anything sensitive in the clear in the first place.
Actually IIRC IBM took code from AIX on Power and put it into Project Monterrey. SCO's claim was that IBM then took that code and contributed it to Linux, essentially claiming that they had control over anything that'd even touched Monterrey regardless of origin. The claim was even more ridiculous because the code they claimed IBM had contributed (JFS) wasn't the code contributed to Monterrey. IBM had originally written JFS for AIX on Power. Their Linux team had to create a completely new implementation of JFS from scratch, because the AIX driver couldn't be ported over to x86. And in fact the Linux team came up with such a superior implementation that IBM removed the original JFS driver (the one that got contributed to Monterrey) from AIX and ported the Linux JFS driver over to AIX on Power. So had SCO gotten past the twin hurdles of claiming control over IBM's independently-developed code just because it was contributed to Monterrey and the code they were suing over never having been contributed to Monterrey, they would've faced the hurdle of the code having come from Linux to Monterrey and not the other way around.
Of course, that's par for the course for SCO. Remember that their first allegedly infringing piece of code turned out not to even be theirs. The malloc() code they claimed was copied from SCO Unix into Linux turned out to be a piece of earlier code (released both under the BSD license multiple times and into the public domain by it's original author) that both SCO Unix and Linux had gone and used (well, SCO Unix used it, Linux had dropped it in favor of more modern code and when it was found the reaction was "What's that still doing there? Get rid of it, it's not being used and it's just cluttering things up.").
If you're a software development house, that's probably a business reason (and requirement). But if you're not a software development house then your customers don't care what you run internally (or shouldn't, anyway). As a car buyer you don't care what OS Ford runs on their corporate desktops. As a guy going to Office Depot for a new chair or file folders you don't care what their head office uses on their desktops, or even what they use on their cash registers (you care whether the registers ring everything up right, but not what they use to do it). And the vast majority of companies out there aren't software development houses.
I'd cite the same reason business will give: "Give me a single business reason to migrate. Tell me what Windows 7 will do for me that Windows XP isn't doing for me today.". Note: "XP's being EOL'd." is a very weak business reason. The primary benefit's to the vendor, my only benefit is ending up exactly where I started. Various features of Windows 7 itself aren't good business reasons either. I don't run Windows for it's own features, I run it for the applications I use every day that need Windows underneath them to run. "But your applications aren't going to support XP anymore, you have to upgrade Windows to run them." also isn't a very good business reason, again it's arguing that I need to spend a lot of money and time and effort getting right where I already am today. It's also circular, because my application vendors are going "Microsoft isn't supporting XP anymore, so you're going to have to upgrade to new versions of the applications that'll run on Windows 7.".
Now, "Windows 7 provides better security and you won't have as many problems with malware." might be a better business reason. Still weak, but better. But it'll get me to thinking: what makes me think Windows 7 really will be any better? Many of the vulnerabilities in Windows come not from Windows but from things like Internet Explorer and Outlook. I can eliminate many of them by just not having those things around, by using Firefox and Thunderbird and the like instead. Except, oh look, I can't because Microsoft doesn't allow me to remove IE. It's always there, it's always active and it's always used for certain things. And Windows 7 doesn't change that. Other vulnerabilities are caused by things like Windows' file-sharing capabilities. Except, why are my desktops even sharing files? They aren't network file servers, they've no business even having the ability to give other machines network access to their filesystems at all. Except that Windows won't let me turn that service off without crippling Windows itself, and Windows 7 doesn't change that. So why am I spending time and effort upgrading to a version of Windows that has the same basic vulnerabilities built into it's design that my existing one does, as opposed to say spending that effort convincing my application vendors to support an OS where I can completely remove the things I don't need and not have to worry about whether there's vulnerabilities in them anymore?
I'll probably have to migrate this year as a purely technical matter, because support won't be there and I can't afford not to have security updates and AV support. But it won't be because I'm deriving any real benefit from the upgrade, it'll be because a vendor needs more upgrade revenue and is in a position to twist my arm. And as a pure business matter I'm going to be looking seriously at ways to get that vendor out of a position where he can twist my arm anymore, because it's just not good business to be at someone else's mercy.
So, they've invented Dr. Wiggin's Patent Cure-All And Digestive Aid. Next they're going to be announcing the discovery of the new elements Unobtanium and Impossibilium, and their successful use in building a burrowing machine that has penetrated the Earth's mantle and restarted the rotation of the core.
The issue with per-unit data plans is that there's a big difference between my data usage and my electricity usage: who's in control. With electricity I know how much my appliances use every month, and I can control that by controlling my appliances. If my electricity bill's too high, I can elect to turn off lights more or switch to lower-wattage or more-efficient bulbs. I can turn my computer off when I'm not using it. I control how much electricity I use and when, and I have a fairly fine degree of control over it.
With data, I've nowhere near that control. When I open a Web page, I don't even know how much data it'll involve until after it's done loading. The Web site's in control of what's on it's pages, and if it decides to ship me 50 megabytes of graphics and scripts and such all I can do is not visit that site at all. And I've still eaten up that 50 megabytes finding out that I will, so really I have to avoid visiting any Web site I haven't visited before and know how much it'll send me. That, to me, isn't real control. And that lack of control's why I want a fixed-rate plan or I'm not going to use the data features much if at all.
I'd counter this by pointing to two things. First is the server arena. There, Unix (and in particular Linux) tend to dominate. Windows is a minority player. Those machines are targeted for attacks all the time, and they can't even be as protected as desktops are because they need to be publicly exposed to do their jobs. Yet do we hear of daily or weekly patches to Apache or the Linux kernel to close security holes? Do we hear of Unix/Linux servers being breached so frequently that it isn't even news anymore? No. The majority of server breaches are still in the minority of servers that run Windows. If it's simply market share, why is Windows still the most-breached OS in an arena where it's a bit player?
Second, I'd point out that Unix has been used in university environments almost since the day it was created. It's constantly open to attack by computer science majors and other students in an environment where the administrators not only can't lock the attackers out, they have to give them multiple legitimate user accounts. And yet Unix systems in that environment aren't routinely breached, their security remains intact and it's unusual for a break-in attempt to be successful. If it's merely exposure that makes Windows so vulnerable, why is it that equally-widely-used Unix systems aren't equally vulnerable?
Botnets around the world are set up using malware -- not security holes. Once you are in the system and are granted rights because the user let you have them, how can you really prevent that?
Exactly. Which is where you see the differences between Unix systems and Windows. On Windows, for instance, if you have UAC enabled and malware does something nasty, you get a prompt from Windows asking you whether to allow it or not and you get the option of allowing it. On Unix, if a piece of malware tries doing something nasty to the system, it gets told "Sorry, you don't have permission to do that.". The user does not get the option of letting the nasty thing happen. The software doesn't have permission to do that, so it doesn't get to do that. If the user wants whatever it is to happen, they first have to actively set the permissions to allow it.
Unix has the attitude of "The user didn't set things up to allow that, they must not want to allow that.". Windows takes the attitude of "The user didn't set things up to allow that, they may have made a mistake and we'd better ask them about it.".
Instead of it being "Yahoo's new features that will share users' online activities and interests with people in their address books, unless they take steps to prevent it.", how about they make it "Yahoo's new features that will share users' online activities and interests with people in their address books, if they take steps to enable it."? Problem solved.
Unless, of course, the problem is that Yahoo wants to do something it knows the majority of it's users don't want done, in which case I still think it's "Problem solved.", it's just not a solution Yahoo likes. But it isn't Yahoo's information Yahoo wants to share, so I don't see why what Yahoo likes should figure into it.
Certainly Microsoft's focus and investment surpasses everyone else's. That's because it needs to simply to tread water. The problem is that most of Microsoft's security problems aren't bugs, they're design features of their system.
There's a quote from a boss: "I don't want the industrious guy who'll keep busy doing things over and over. I want the lazy guy who'll do it once, right, so he doesn't need to keep doing it over."
Re:any of you watching the live stream?
on
Gulf Oil Leak Plugged?
·
· Score: 2, Interesting
From the looks of it, the mud is working. The outflow's brown, not black, looks like it's mostly drilling mud blowing out of the pipe and not crude oil. That'd indicate the mud's stabilizing the pressure and stopping the flow of oil up the well, which is step 1. Step 2 is to pump concrete in below where they're injecting the mud, into an area where the well fluid's under pressure but now not flowing and blowing any plug away before it can harden. Step 3 happens after the plug's big enough and hardened: backing off on the drilling mud and seeing if the plug holds under well pressure or not.
So what's he supposed to have done? All the experts on plugging wells are working in or for the oil industry, the US Government doesn't have anybody better than what BP already has access to. Start ordering BP to do things? BP will simply haul out 8 years of rulings from agencies during the Bush administration saying they don't have the authority to order companies around, and the whole thing'll end up tied up in court for years. Penalize BP for failing to meet regulatory requirements? The Bush administration gutted those regulatory requirements to the point that BP simply hasn't broken any rules here.
I'm sorry, but a year and a half isn't nearly enough to undo 8 years of "Government should get out of business's way and let it do what it does best. We can't regulate it to death, and government shouldn't be telling it what to do.". Although if I were Obama, you can bet that once the well's confirmed capped there would be a request to Congress to add specific regulations covering what went wrong here, plus a request for a 100% increase in the budgets of various regulatory agencies (eg. MSHA, OSHA, MMS) with the additional money earmarked specifically for inspections and enforcement.
Actually they probably didn't record your credit-card number. What they probably recorded was the sale number (basically a receipt serial number), the receipt information (what was bought), and the type of credit card and the authorization number. They knew your name because it was recorded off your credit card at the time of sale. To handle the refund they just use the authorization number, which the credit-card company can match to your card (but they won't tell the store the card number, they'll just give out another authorization number for the refund).
Now, the store probably doesn't need to store your name at the time of sale. But if you're paying with a credit card, you know you're leaving a connection between you and that sale anyway so IMO it's not a major thing. If you really want no connection, pay in cash and don't give them any identifying information, not even a phone number.
Actually, RedHat does. When you pull the source code for a RedHat distro, you get all the makefiles, configuration files, build scripts and everything else required to build the entire distribution from source code. You will, of course, have to first get the binary distro (or otherwise have the build tools available, but since RedHat's using the GNU toolchain that's trivial to obtain from RedHat or elsewhere), but RedHat makes their binary distribution available to you so there's no violation there.
Do they really? I upgraded my phone only about a year and a half ago. That phone's no longer available at all through my carrier. You can't even get a refurbished one. And when I got it it'd been available for less than 6 months. So, less than 2 years from initial release to completely obsolete and unavailable.
I think customers expect their phone to function for the full length of the contract, but I don't think anybody expects it to actually be current for more than a year anymore. And I think the carriers depend on that, I don't think it's a coincidence that my carrier makes me eligible for an upgrade at 18 months after purchase or last upgrade despite the contract being for 24 months.
No, the build environment doesn't provide an end-run around the GPL. Both v2 and v3 of the GPL require the distributor to provide the scripts that control the build. In GPLv2 it's in section 3, in GPLv3 it's in section 1. GPLv3 also covers this again in section 6, in a more general form when it discusses installation information.
Joel's position contradicts a paper I read years ago in an IEEE software journal that basically said you needed to plan on rewriting your application about every 7 years or have it collapse on you. The logic in the paper was based on two things I've found to be true in the real world. First, the world changes. Individually it's small changes, but looking at it on the half-decade-to-decade scale it can add up to huge differences in what's needed in the software. Second, software isn't infinitely extensible/adaptable. Any software has a basic architecture and world-view, and a limit beyond which it can't be pushed without an exponential increase in the time and effort needed to successfully make the changes. The two combine to mean that at some point it simply becomes technically infeasible to extend and adapt an existing system. The requirements have changed too much and you're having to fight the system trying to make it do, not just what it wasn't designed to do, but what it was actively designed not to do.
Now, business doesn't like this. It doesn't make sense from a business perspective, and it'd be much better to simply keep adapting and extending what's already there. But that ignores the fact that something must be technically feasible before you can even ask whether it makes business sense. If you've got the best idea in the world that'll make the business tons of money while giving you a virtual monopoly in the field and reducing costs by 99%, that basically is from a business standpoint the absolutely ideal thing to do, but it requires the manufacture of say room-temperature superconducting wire by the mile, then it just ain't gonna happen. How desirable it is from a business perspective doesn't matter because it just isn't technically possible at this point in time.
I also liken it to building a 20-story office tower. It's tempting to start with a simple one-story building and slowing add to it until you've got what you want, but the foundation of a one-story building just isn't going to be able to support a 20-story tower. You might be able to get 2 or 3 stories out of it, but at some point you're going to have to tear the whole building down and re-do the very foundations themselves to support the greater weight.
Not all. I'd bet only the HFTs would decamp, and they'd have a hard time of it when the only other people on their exchange were other HFTs and they didn't have the bulk of the normal market there to provide them with their opportunities. Think about cards. Card sharps don't play against other card sharps, they play against suckers. If there's no suckers at the table, there's no money in it for the card sharps.
No, this wouldn't be an exchange rule, it'd be an SEC rule applicable to all exchanges in the US. There'd still be foreign exchanges, of course, but at least it'd settle things on the US exchanges.
What's needed seems not so much a circuit-breaker as a brake of some form, a drag on the speed of trading. We do it in electronics all the time, we add electrical drag (in the form of reactive elements (capacitors or inductors) or feedback loops) on a circuit to keep it from being overly sensitive and going into oscillation. We even do it on car suspensions. You're all familiar with shocks and struts and springs. The springs let the wheels bounce over bumps and holes in the road surface without the car body moving, the shocks/struts limit the rate the springs can move at and damp them so your car doesn't start bouncing up and down after hitting a bump.
So. How to limit the speed at which transactions are processed. Two possibilities. One, set a market interval, say 1 second. Every trade in a given interval gets the timestamp of the interval, and at the end of the interval they're all processed as if they'd arrived at the same time. The only prohibition is that actual arrival order/sequence can't be used as a tie-breaker, some random number has to be used instead (eg. if you get two orders of the same size for the same price in the same interval and you need to decide which one to fill first, you roll the dice for each one and low man goes first). That puts paid to HFT and sub-millisecond trading, since the market won't recognize timing finer than the market interval and the trader can't predict where in line the market will put his trade. Two, set the same sort of market interval. Then, as each trade arrives, generate a random delay [0,interval) and add that delay to each trade. Again that'll put paid to HFT and sub-millisecond trading, the trader knows his trade'll be executed within a market interval but he doesn't know exactly when within that interval it'll get put. But in both cases for people not trying to time it to sub-interval precision it shouldn't make much if any difference. All it does is put a limit on the speed of trading, which should act like a shock absorber does to limit the rate the market can change over the short term without affecting the long-term movement rate.
I'd suggest floating this idea to the high-frequency traders and advocates of sub-millisecond trading and gauge their responses. If they scream bloody murder and vow to oppose it to the death, it's probably a good idea. If, after studying it, they're all in favor of it, drop it like a hot potato because they've found something in it they can exploit even more than HFT.
Actually, if you read the case law patents aren't supposed to protect ideas, they're supposed to protect exactly implementations. Eg., you can't patent the idea of smelting iron into steel, you can patent a specific method of doing that. And if someone implements the idea of smelting in a different way using a different method, you don't get to touch them.
No, not all ideas are obvious. There are plenty of ideas where, given the body of knowledge available in the art, a person of ordinary skill won't know how to make the jump from that to the solution. Those are the patentable ideas. There is a line, it merely isn't drawn at zero. It used to be, the courts considered the PHOSitA to be a mindless drone who could only do exactly what'd been previously taught exactly the way it was taught. The Supreme Court merely moved the line, saying the courts had to assume the PHOSitA had the ordinary skill and creativity you'd expect from a skilled practitioner. Patents aren't supposed to reward that, they're supposed to reward the extraordinary skill and creativity needed to come up with something an ordinary practitioner wouldn't think of.
True, 2 + 2 = 4 wasn't obvious before the invention of math. But, after the invention of math, applying that math to solve the problem of adding 2 and 2 was obvious. The invention of math may have been novel and patentable, but it's application to that specific problem isn't.
And that nobody's done it before is irrelevant. No matter how obvious something is, someone had to be the first to do it. If nothing else, someone had to be the first to address the problem. You don't look at obviousness in hindsight, but neither do you look at it from the standpoint of no motivation at all. The place to look at obviousness is at the point where a person having ordinary skill in the art is asked to solve the problem in question. An obvious solution can even involve a certain amount of creativity, if that creativity is within the realm of what a PHOSitA would be expected to have.
Easier option: the copier deletes the files from the hard drive after the copy run's completed and the images aren't needed anymore. Ditto when documents are scanned and delivered elsewhere (eg. e-mailed to the user). Only store them permanently when the user scans them in and deliberately stores them in the copier. It's not that hard to make it behave that way.
Slashdot Mirror
What restriction is there on who can park on the street in front of your house? None. Anybody can do it. So while yes there's a physical radius, you have no idea who's within that radius and you know it. That one of those somebodies is from Google and they've got a tape recorder running is one of those things that everybody ought to be expecting. After all, first rule: if it's embarrassing or sensitive or otherwise might be a problem if someone found it out, and you're saying it in the middle of a crowd of strangers, you'd better assume one of them will be taking notes (because one of them will be and you'll find out about it at the least opportune moment). Ditto for standing outside the front door of your house. If you're naked except for a pink tutu and you're counting on nobody but your neighbors (who understand you were just the butt of a practical joke and accidentally latched the door chasing the pranksters out of your house) seeing you, the photographers from the local scandal rag will be cruising by and will catch you on film and it will show up in the local paper with a suitably scathing blurb. If you're really unlucky, it'll be both the photogs and the local cops.
I have one question, though: exactly how much privacy do people expect, given that what Google collected was what those people were broadcasting in the clear to the world at large? It's the equivalent of Google listening to what people are saying sitting at the corner coffee shop. Face it, when you're talking in public with strangers standing right next to you listening, you don't expect what you say to go unheard. So, why do you expect what you're broadcasting with the moral equivalent of a bullhorn to remain private? You want it private? Either don't broadcast it at all or at least encrypt it before broadcasting it.
Oh, you say the average person doesn't know better? Sorry, they should know better, and if they don't they should know better than to try without getting expert help. No excuses. This isn't rocket science. We've had personal computers for over 30 years. We carry sophisticated ones in our pockets and use them to make phone calls. It's well past high time the average person was expected to have a basic understanding of what they're so casually carrying around and using every day, and past time we stopped making excuses for the ones who just can't be bothered. You shouldn't need to know the details of how encryption works in 802.11*, but you should at least know as much as "I need encryption turned on, and if I don't know where and how to turn it on I need to either RTFM or ask someone who does know for help.".
More important than asking why Google collected this information is asking why people were so negligently reckless as to broadcast anything sensitive in the clear in the first place.
Actually IIRC IBM took code from AIX on Power and put it into Project Monterrey. SCO's claim was that IBM then took that code and contributed it to Linux, essentially claiming that they had control over anything that'd even touched Monterrey regardless of origin. The claim was even more ridiculous because the code they claimed IBM had contributed (JFS) wasn't the code contributed to Monterrey. IBM had originally written JFS for AIX on Power. Their Linux team had to create a completely new implementation of JFS from scratch, because the AIX driver couldn't be ported over to x86. And in fact the Linux team came up with such a superior implementation that IBM removed the original JFS driver (the one that got contributed to Monterrey) from AIX and ported the Linux JFS driver over to AIX on Power. So had SCO gotten past the twin hurdles of claiming control over IBM's independently-developed code just because it was contributed to Monterrey and the code they were suing over never having been contributed to Monterrey, they would've faced the hurdle of the code having come from Linux to Monterrey and not the other way around.
Of course, that's par for the course for SCO. Remember that their first allegedly infringing piece of code turned out not to even be theirs. The malloc() code they claimed was copied from SCO Unix into Linux turned out to be a piece of earlier code (released both under the BSD license multiple times and into the public domain by it's original author) that both SCO Unix and Linux had gone and used (well, SCO Unix used it, Linux had dropped it in favor of more modern code and when it was found the reaction was "What's that still doing there? Get rid of it, it's not being used and it's just cluttering things up.").
If you're a software development house, that's probably a business reason (and requirement). But if you're not a software development house then your customers don't care what you run internally (or shouldn't, anyway). As a car buyer you don't care what OS Ford runs on their corporate desktops. As a guy going to Office Depot for a new chair or file folders you don't care what their head office uses on their desktops, or even what they use on their cash registers (you care whether the registers ring everything up right, but not what they use to do it). And the vast majority of companies out there aren't software development houses.
I'd cite the same reason business will give: "Give me a single business reason to migrate. Tell me what Windows 7 will do for me that Windows XP isn't doing for me today.". Note: "XP's being EOL'd." is a very weak business reason. The primary benefit's to the vendor, my only benefit is ending up exactly where I started. Various features of Windows 7 itself aren't good business reasons either. I don't run Windows for it's own features, I run it for the applications I use every day that need Windows underneath them to run. "But your applications aren't going to support XP anymore, you have to upgrade Windows to run them." also isn't a very good business reason, again it's arguing that I need to spend a lot of money and time and effort getting right where I already am today. It's also circular, because my application vendors are going "Microsoft isn't supporting XP anymore, so you're going to have to upgrade to new versions of the applications that'll run on Windows 7.".
Now, "Windows 7 provides better security and you won't have as many problems with malware." might be a better business reason. Still weak, but better. But it'll get me to thinking: what makes me think Windows 7 really will be any better? Many of the vulnerabilities in Windows come not from Windows but from things like Internet Explorer and Outlook. I can eliminate many of them by just not having those things around, by using Firefox and Thunderbird and the like instead. Except, oh look, I can't because Microsoft doesn't allow me to remove IE. It's always there, it's always active and it's always used for certain things. And Windows 7 doesn't change that. Other vulnerabilities are caused by things like Windows' file-sharing capabilities. Except, why are my desktops even sharing files? They aren't network file servers, they've no business even having the ability to give other machines network access to their filesystems at all. Except that Windows won't let me turn that service off without crippling Windows itself, and Windows 7 doesn't change that. So why am I spending time and effort upgrading to a version of Windows that has the same basic vulnerabilities built into it's design that my existing one does, as opposed to say spending that effort convincing my application vendors to support an OS where I can completely remove the things I don't need and not have to worry about whether there's vulnerabilities in them anymore?
I'll probably have to migrate this year as a purely technical matter, because support won't be there and I can't afford not to have security updates and AV support. But it won't be because I'm deriving any real benefit from the upgrade, it'll be because a vendor needs more upgrade revenue and is in a position to twist my arm. And as a pure business matter I'm going to be looking seriously at ways to get that vendor out of a position where he can twist my arm anymore, because it's just not good business to be at someone else's mercy.
So, they've invented Dr. Wiggin's Patent Cure-All And Digestive Aid. Next they're going to be announcing the discovery of the new elements Unobtanium and Impossibilium, and their successful use in building a burrowing machine that has penetrated the Earth's mantle and restarted the rotation of the core.
The issue with per-unit data plans is that there's a big difference between my data usage and my electricity usage: who's in control. With electricity I know how much my appliances use every month, and I can control that by controlling my appliances. If my electricity bill's too high, I can elect to turn off lights more or switch to lower-wattage or more-efficient bulbs. I can turn my computer off when I'm not using it. I control how much electricity I use and when, and I have a fairly fine degree of control over it.
With data, I've nowhere near that control. When I open a Web page, I don't even know how much data it'll involve until after it's done loading. The Web site's in control of what's on it's pages, and if it decides to ship me 50 megabytes of graphics and scripts and such all I can do is not visit that site at all. And I've still eaten up that 50 megabytes finding out that I will, so really I have to avoid visiting any Web site I haven't visited before and know how much it'll send me. That, to me, isn't real control. And that lack of control's why I want a fixed-rate plan or I'm not going to use the data features much if at all.
I'd counter this by pointing to two things. First is the server arena. There, Unix (and in particular Linux) tend to dominate. Windows is a minority player. Those machines are targeted for attacks all the time, and they can't even be as protected as desktops are because they need to be publicly exposed to do their jobs. Yet do we hear of daily or weekly patches to Apache or the Linux kernel to close security holes? Do we hear of Unix/Linux servers being breached so frequently that it isn't even news anymore? No. The majority of server breaches are still in the minority of servers that run Windows. If it's simply market share, why is Windows still the most-breached OS in an arena where it's a bit player?
Second, I'd point out that Unix has been used in university environments almost since the day it was created. It's constantly open to attack by computer science majors and other students in an environment where the administrators not only can't lock the attackers out, they have to give them multiple legitimate user accounts. And yet Unix systems in that environment aren't routinely breached, their security remains intact and it's unusual for a break-in attempt to be successful. If it's merely exposure that makes Windows so vulnerable, why is it that equally-widely-used Unix systems aren't equally vulnerable?
Botnets around the world are set up using malware -- not security holes. Once you are in the system and are granted rights because the user let you have them, how can you really prevent that?
Exactly. Which is where you see the differences between Unix systems and Windows. On Windows, for instance, if you have UAC enabled and malware does something nasty, you get a prompt from Windows asking you whether to allow it or not and you get the option of allowing it. On Unix, if a piece of malware tries doing something nasty to the system, it gets told "Sorry, you don't have permission to do that.". The user does not get the option of letting the nasty thing happen. The software doesn't have permission to do that, so it doesn't get to do that. If the user wants whatever it is to happen, they first have to actively set the permissions to allow it.
Unix has the attitude of "The user didn't set things up to allow that, they must not want to allow that.". Windows takes the attitude of "The user didn't set things up to allow that, they may have made a mistake and we'd better ask them about it.".
Instead of it being "Yahoo's new features that will share users' online activities and interests with people in their address books, unless they take steps to prevent it.", how about they make it "Yahoo's new features that will share users' online activities and interests with people in their address books, if they take steps to enable it."? Problem solved.
Unless, of course, the problem is that Yahoo wants to do something it knows the majority of it's users don't want done, in which case I still think it's "Problem solved.", it's just not a solution Yahoo likes. But it isn't Yahoo's information Yahoo wants to share, so I don't see why what Yahoo likes should figure into it.
Certainly Microsoft's focus and investment surpasses everyone else's. That's because it needs to simply to tread water. The problem is that most of Microsoft's security problems aren't bugs, they're design features of their system.
There's a quote from a boss: "I don't want the industrious guy who'll keep busy doing things over and over. I want the lazy guy who'll do it once, right, so he doesn't need to keep doing it over."
From the looks of it, the mud is working. The outflow's brown, not black, looks like it's mostly drilling mud blowing out of the pipe and not crude oil. That'd indicate the mud's stabilizing the pressure and stopping the flow of oil up the well, which is step 1. Step 2 is to pump concrete in below where they're injecting the mud, into an area where the well fluid's under pressure but now not flowing and blowing any plug away before it can harden. Step 3 happens after the plug's big enough and hardened: backing off on the drilling mud and seeing if the plug holds under well pressure or not.
So what's he supposed to have done? All the experts on plugging wells are working in or for the oil industry, the US Government doesn't have anybody better than what BP already has access to. Start ordering BP to do things? BP will simply haul out 8 years of rulings from agencies during the Bush administration saying they don't have the authority to order companies around, and the whole thing'll end up tied up in court for years. Penalize BP for failing to meet regulatory requirements? The Bush administration gutted those regulatory requirements to the point that BP simply hasn't broken any rules here.
I'm sorry, but a year and a half isn't nearly enough to undo 8 years of "Government should get out of business's way and let it do what it does best. We can't regulate it to death, and government shouldn't be telling it what to do.". Although if I were Obama, you can bet that once the well's confirmed capped there would be a request to Congress to add specific regulations covering what went wrong here, plus a request for a 100% increase in the budgets of various regulatory agencies (eg. MSHA, OSHA, MMS) with the additional money earmarked specifically for inspections and enforcement.
Actually they probably didn't record your credit-card number. What they probably recorded was the sale number (basically a receipt serial number), the receipt information (what was bought), and the type of credit card and the authorization number. They knew your name because it was recorded off your credit card at the time of sale. To handle the refund they just use the authorization number, which the credit-card company can match to your card (but they won't tell the store the card number, they'll just give out another authorization number for the refund).
Now, the store probably doesn't need to store your name at the time of sale. But if you're paying with a credit card, you know you're leaving a connection between you and that sale anyway so IMO it's not a major thing. If you really want no connection, pay in cash and don't give them any identifying information, not even a phone number.
Actually, RedHat does. When you pull the source code for a RedHat distro, you get all the makefiles, configuration files, build scripts and everything else required to build the entire distribution from source code. You will, of course, have to first get the binary distro (or otherwise have the build tools available, but since RedHat's using the GNU toolchain that's trivial to obtain from RedHat or elsewhere), but RedHat makes their binary distribution available to you so there's no violation there.
Do they really? I upgraded my phone only about a year and a half ago. That phone's no longer available at all through my carrier. You can't even get a refurbished one. And when I got it it'd been available for less than 6 months. So, less than 2 years from initial release to completely obsolete and unavailable.
I think customers expect their phone to function for the full length of the contract, but I don't think anybody expects it to actually be current for more than a year anymore. And I think the carriers depend on that, I don't think it's a coincidence that my carrier makes me eligible for an upgrade at 18 months after purchase or last upgrade despite the contract being for 24 months.
No, the build environment doesn't provide an end-run around the GPL. Both v2 and v3 of the GPL require the distributor to provide the scripts that control the build. In GPLv2 it's in section 3, in GPLv3 it's in section 1. GPLv3 also covers this again in section 6, in a more general form when it discusses installation information.
Joel's position contradicts a paper I read years ago in an IEEE software journal that basically said you needed to plan on rewriting your application about every 7 years or have it collapse on you. The logic in the paper was based on two things I've found to be true in the real world. First, the world changes. Individually it's small changes, but looking at it on the half-decade-to-decade scale it can add up to huge differences in what's needed in the software. Second, software isn't infinitely extensible/adaptable. Any software has a basic architecture and world-view, and a limit beyond which it can't be pushed without an exponential increase in the time and effort needed to successfully make the changes. The two combine to mean that at some point it simply becomes technically infeasible to extend and adapt an existing system. The requirements have changed too much and you're having to fight the system trying to make it do, not just what it wasn't designed to do, but what it was actively designed not to do.
Now, business doesn't like this. It doesn't make sense from a business perspective, and it'd be much better to simply keep adapting and extending what's already there. But that ignores the fact that something must be technically feasible before you can even ask whether it makes business sense. If you've got the best idea in the world that'll make the business tons of money while giving you a virtual monopoly in the field and reducing costs by 99%, that basically is from a business standpoint the absolutely ideal thing to do, but it requires the manufacture of say room-temperature superconducting wire by the mile, then it just ain't gonna happen. How desirable it is from a business perspective doesn't matter because it just isn't technically possible at this point in time.
I also liken it to building a 20-story office tower. It's tempting to start with a simple one-story building and slowing add to it until you've got what you want, but the foundation of a one-story building just isn't going to be able to support a 20-story tower. You might be able to get 2 or 3 stories out of it, but at some point you're going to have to tear the whole building down and re-do the very foundations themselves to support the greater weight.
Not all. I'd bet only the HFTs would decamp, and they'd have a hard time of it when the only other people on their exchange were other HFTs and they didn't have the bulk of the normal market there to provide them with their opportunities. Think about cards. Card sharps don't play against other card sharps, they play against suckers. If there's no suckers at the table, there's no money in it for the card sharps.
No, this wouldn't be an exchange rule, it'd be an SEC rule applicable to all exchanges in the US. There'd still be foreign exchanges, of course, but at least it'd settle things on the US exchanges.
What's needed seems not so much a circuit-breaker as a brake of some form, a drag on the speed of trading. We do it in electronics all the time, we add electrical drag (in the form of reactive elements (capacitors or inductors) or feedback loops) on a circuit to keep it from being overly sensitive and going into oscillation. We even do it on car suspensions. You're all familiar with shocks and struts and springs. The springs let the wheels bounce over bumps and holes in the road surface without the car body moving, the shocks/struts limit the rate the springs can move at and damp them so your car doesn't start bouncing up and down after hitting a bump.
So. How to limit the speed at which transactions are processed. Two possibilities. One, set a market interval, say 1 second. Every trade in a given interval gets the timestamp of the interval, and at the end of the interval they're all processed as if they'd arrived at the same time. The only prohibition is that actual arrival order/sequence can't be used as a tie-breaker, some random number has to be used instead (eg. if you get two orders of the same size for the same price in the same interval and you need to decide which one to fill first, you roll the dice for each one and low man goes first). That puts paid to HFT and sub-millisecond trading, since the market won't recognize timing finer than the market interval and the trader can't predict where in line the market will put his trade. Two, set the same sort of market interval. Then, as each trade arrives, generate a random delay [0,interval) and add that delay to each trade. Again that'll put paid to HFT and sub-millisecond trading, the trader knows his trade'll be executed within a market interval but he doesn't know exactly when within that interval it'll get put. But in both cases for people not trying to time it to sub-interval precision it shouldn't make much if any difference. All it does is put a limit on the speed of trading, which should act like a shock absorber does to limit the rate the market can change over the short term without affecting the long-term movement rate.
I'd suggest floating this idea to the high-frequency traders and advocates of sub-millisecond trading and gauge their responses. If they scream bloody murder and vow to oppose it to the death, it's probably a good idea. If, after studying it, they're all in favor of it, drop it like a hot potato because they've found something in it they can exploit even more than HFT.
Actually, if you read the case law patents aren't supposed to protect ideas, they're supposed to protect exactly implementations. Eg., you can't patent the idea of smelting iron into steel, you can patent a specific method of doing that. And if someone implements the idea of smelting in a different way using a different method, you don't get to touch them.
No, not all ideas are obvious. There are plenty of ideas where, given the body of knowledge available in the art, a person of ordinary skill won't know how to make the jump from that to the solution. Those are the patentable ideas. There is a line, it merely isn't drawn at zero. It used to be, the courts considered the PHOSitA to be a mindless drone who could only do exactly what'd been previously taught exactly the way it was taught. The Supreme Court merely moved the line, saying the courts had to assume the PHOSitA had the ordinary skill and creativity you'd expect from a skilled practitioner. Patents aren't supposed to reward that, they're supposed to reward the extraordinary skill and creativity needed to come up with something an ordinary practitioner wouldn't think of.
True, 2 + 2 = 4 wasn't obvious before the invention of math. But, after the invention of math, applying that math to solve the problem of adding 2 and 2 was obvious. The invention of math may have been novel and patentable, but it's application to that specific problem isn't.
And that nobody's done it before is irrelevant. No matter how obvious something is, someone had to be the first to do it. If nothing else, someone had to be the first to address the problem. You don't look at obviousness in hindsight, but neither do you look at it from the standpoint of no motivation at all. The place to look at obviousness is at the point where a person having ordinary skill in the art is asked to solve the problem in question. An obvious solution can even involve a certain amount of creativity, if that creativity is within the realm of what a PHOSitA would be expected to have.
See the Supreme Court's unanimous holding in KSR v. Teleflex.
Easier option: the copier deletes the files from the hard drive after the copy run's completed and the images aren't needed anymore. Ditto when documents are scanned and delivered elsewhere (eg. e-mailed to the user). Only store them permanently when the user scans them in and deliberately stores them in the copier. It's not that hard to make it behave that way.