Just bear in mind this: I'm one of those 1% of Linux users. But I'm also the guy the other 99% come to when they want a recommendation on what to buy. And I'm the guy they come to when their system's having a problem and they need it fixed. They've experienced the migraines having the manufacturer service it (all their precious files gone, all their software wiped and of course the product keys (if there were any) were in their e-mail which went with their data so they have to buy the software all over again), that's why they come to me.
Now, what do you think's going to happen when all those "normal" people come to me and I point them at vendors who don't lock down the BIOS? And when they ask me about a major vendor who does lock it down so it'll only run windows and I say "Sorry, their machines won't let any of my tools run so if you buy one I won't be able to help you with it."? They're going to go with my recommendation if only because they want their friendly neighborhood geek to be willing to fix their systems when they break.
It's like the large corporate world. The CEO's only one person in a company of tens of thousands. He probably doesn't even have any contact with any of the departments that actually buy and use the equipment. But get him mad at you and you're going to lose a lot more than just one person's purchases.
I think the big driver for OEMs telling Microsoft to rethink this will be Windows 7 and XP. A lot of major companies won't be ready to deploy Windows 8, especially with money tight. And they'll need to deploy, not stock Windows 7, but the specific image with the specific patches that they've certified compatible with all the other software they need to run. Fail to do that and IT's going to come back with a big requirement to re-certify everything that'll cost a lot of money and take a lot of time, and management'll buy off on it because it'll be phrased as "If we don't verify everything, we're risking another company-wide outage for some unknown number of weeks until the vendors get us a fix. Remember how much pain that caused last time it happened?".
The big vendors like HP and Dell aren't going to go for something that'll cost them their biggest corporate customers. And the motherboard OEMs won't go for something that'll cost them both their big vendor contracts and their boutique component sales to gamers and the like.
They're using SSL in a standard way. What the article gets confused is the difference between SSL (the protocol used to encrypt connections) and HTTP Referrer header handling (used to pass referrer information to the target site). Note that the two have nothing to do with one another.
The convention has been that when the source page is https: and the target page is http: the Referrer header is suppressed, while if both are https: the Referrer header is passed normally. Google's changed this to a different rule: if it's an organic seach link the Referrer header is suppressed always, if it's a paid placement link the Referrer header is sent always. That's a change from conventional HTTP Referrer behavior, but not a change in SSL at all.
And I'd note that it also has nothing to do with paying for position within the organic listings. You can't pay for placement there. All you can buy is advertising space separate from the organic listings.
The problem is that we've got clocks. They've got noon and midnight on them. We've also got the sun. It rises at dawn, sets at sunset, and mid-way through the day it's straight overhead. And silly humans, we expect our clocks and the sun to be sorta-kinda in sync. We expect that mid-way through the sun's cycle, when it's straight overhead at what we call noon, our clocks are also going to be mid-way through their cycle and will be reading noon. We expect midnight on the clocks to be in the middle of the night. And we expect dawn and sunset to be in the morning and evening by our clocks.
Any solution proposed needs to accomplish the same synchronization. Not for any technical reasons, but because people expect it. It's not an implementation detail, it's a system requirement. Your "solution" tries to cross that requirement off as invalid or irrelevant, which means it immediately gets dismissed as "fails to meet requirements".
What methodology is this company using to measure activity on Google+? If it's public posts, they may have a serious systemic problem: people who use G+ specifically because it's so easy to not post publicly. My guess is the majority of G+ users are posting only to their circles, in which case there'd be a plethora of stuff that Chitika Insights simply won't see.
Google isn't stupid. More importantly, Google's lawyers aren't stupid. And if there's one thing Google's good at, it's sifting through masses of data, teasing out the relationships and putting them together. So I'm assuming Google has a plan and it's not completely half-baked. We'll have to see whether it's successful or not, but they do have a plan.
The problem with debt-collection calls is that often they use a robo-calling system: when you pick up the phone you get a recording saying "It is important you take this call. All our representatives are busy servicing other customers, please stay on the line until a representative is available.". And then you sit on hold for some unknown length of time, footing the bill because the collection agency finds it cheaper to do automated calling than to actually have representatives handle each call.
My feeling is that if it's actually important to them that I talk to them, it's important enough that they'll have a human being ready to talk to me when I pick up the call. If they don't, and especially if the recording doesn't say who's calling or the name isn't one I recognize, i assume it's not that important to them and hang up. But on a cel phone that incoming call still burned up air time that I have to pay for and now can't use for legitimate calls.
So, if my physical wallet isn't going anywhere because I still need it for all the cards, cash and stuff I need to carry that I can't put on my phone, and I still need actual cards for merchants who don't have the right tech at their registers, what exactly does Google Wallet do for me? I can't think of a time when I'd have my phone and wouldn't have my wallet on me, so it's not convenience. About all it seems to do is enable Google to watch what I purchase. Sorry, I'm going to need something of benefit to me first.
OK then, what's the sales tax rate that applies to me?
Seriously. Where can Amazon go to find the sales tax rate that applies to any arbitrary person in the US? State sales tax rate won't work, that's not the sale tax rate for me. You need to take into account county and city sales taxes plus any special districts applicable to me. No, they aren't available on-line. No, you can't call a single state agency and get it. No, you can't go by ZIP code because many ZIP codes span tax boundaries (eg. part of the ZIP code is inside the city limits and subject to city sales tax, part is outside and isn't).
And if you want Amazon subject to this, then make every brick-and-mortar store subject to it too. No more ignoring where their customer lives and only collecting sales tax for the business's address, every single store has to collect tax based on the customer's address just like Amazon.
Of course none of the "solutions" will work. Laying people off will mean less service. And no, reduced volume doesn't mean they've got excess people. It takes just about as many people to handle, sort and deliver one piece of mail per address as 20 pieces. Less service means more reasons for former customers to find and use alternatives. And higher rates means more former customers find the alternatives more attractive.
And taking an honest look at my mailbox for the last couple of months, I find maybe half-a-dozen pieces of mail per week that I actually asked for. The rest is advertising of some sort or another. And of the small fraction I asked for, I only actually need a couple a month. The rest I could get through e-mail or the Web if I wanted to, I only keep them coming through snail-mail in case I'm hospitalized or something and someone else needs to handle my bills (it's already happened once). The USPS's problem is that changes in technology are steadily making them obsolete. They let UPS and Fedex and others take overnight delivery and parcel post away from them. E-mail took the regular first-class letter business away. On-line options are eating away at the use of mail for bills and payments. What's left? Advertising, and stuff where delivery by USPS carries a legal presumption of receipt. That's not much to build a business on.
If you turn on tag review, items you're tagged in don't appear on Facebook until you review and approve them. You can also turn on profile review, and set profile visibility to friends only. If you set those things appropriately and the person trying to tag you also tries to block you from seeing what they've tagged you in, they paint themselves into a corner: if you can't see it you can't review and approve it, and if you don't approve it it's not visible to anyone.
That said, the new settings feel to me like they give me less control over what my name's attached to.
The reality is that people's body rhythms aren't tied to the clock, they're tied to the sun and the day/night cycle. We sleep when it's dark, we're active when it's daylight. And that cycle likes to run at a roughly 24-hour frequency. Eliminating timezones won't change the fact that when it's noon in New York it's 2 hours after midnight in Sydney, Australia. Eliminating time zones won't change the fact that when you get off that flight from New York your body's clock will be 10 hours out of sync with Sydney's local day/night cycle. And it won't magically make the people in Sydney want to have meetings in the dead of their nighttime just because the sun's high in the sky in New York.
Besides which, you don't need to eliminate timezones if all you want is a consistent clock. The military already uses Zulu time (roughly GMT) for most purposes. You can do the same.
I think they intend the touchscreen to be used in place of the mouse. Which'd actually work well, if the games had direct support for the hardware. But that's the kicker, getting game-dev support.
The FCC doesn't really care whether the phone is fully open or not. All they care about is that the radio in the phone not operate outside the allowed parameters. The problem comes from the manufacturers wanting to use radio hardware that isn't limited to the permissible parameters, and limit it's operation using easily-changed software controls. If they used radio hardware that was itself limited to permissible parameters, there wouldn't be any problem with it being open. But that would make the hardware more expensive and cut into profit margins.
Note also that "permissible parameters" vary depending on the user, not the device. If the user happens to have an FCC operator's license, the permissible parameters for a cel phone may be radically different from what an unlicensed user would be allowed.
Two things though. First, as a software developer your contract with your employer states explicitly that the copyright on code you produce rests with your employer, not you. If it didn't, the default rules are that you own the code, not the company. Second. software developers like that are also W2 employees, not independent contractors. And that makes a difference. There's been several run-ins between companies and the IRS about employee status, and the labels may be walking into a minefield. If the artists really are employees, not independent contractors, then the labels are responsible for payroll tax withholding, unemployment insurance payments, employer's portion of SSI and Medicare taxes, etc. etc..
Google does block competitors from Android phones, but it's not because they're Android phones. Anyone can make an Android phone and use any search-engine default, any advertising network, that they want. What Google does is say that if you want to use the Google brand on the phone you can't use non-Google services on it. To me that seems to be a completely valid use of their trademark, and has nothing to do with their position in search. You want an Android phone that doesn't put Google front-and-center? Look for one that isn't Google-branded. And as far as I know Google does nothing whatsoever to stop anyone from making a non-Google-branded Android phone, correct?
How about, instead of sniffing for the browser types you (think you) know support what you need, sniff for the features you need directly? That way your app will work just fine with any browser that supports what you need, and if it doesn't support what you need you'll be able to tell the user exactly what his browser's missing so he can fix it (it may be he just needs to update his browser, or install a plug-in or optional feature he hasn't gotten around to yet).
We do need a class of certificate that simply verifies that we're talking to the host we expect to be talking to (ie. that the name of the host using the certificate matches the name of the host in the URL). That's sufficient for encryption-only purposes, where I'm using SSL not to validate the remote end's identity in any way but merely to prevent eavesdropping on the data stream by third parties. DNSSec addresses some of that, but it doesn't provide the encryption layer that SSL does.
Bluntly put, there's a lot of cases where I don't care about the absolute, real-world identity of the entity I'm talking to, only that I'm talking to the same entity every time. Think the Dread Pirate Roberts.
That depends on the area. Out West there's a lot of places where the lower speed limit will cost lives. That's because there's long stretches of cross-country freeway where the primary causes of accidents isn't speed, it's driver fatigue. The most common accident type is the single-car rollover on level, clear highway. Speed isn't usually a cause of the loss of control, it's usually either a driver falling asleep at the wheel or being drunk. Reduced speed limits won't help either of those, and will hurt in the first case. The slower you have to drive, the longer it takes to get where you're going (because the distance doesn't magically shrink along with the speed limit) and the more likely you are to get too tired before you get there. And stopping often isn't an option. This is country where that sign saying "Next services 300 miles" isn't joking, and it means "Next hint of human habitation of any sort 300 miles".
A dense urban area is a radically different environment from a rural area where highways can run straight and level for 30, 40 or 50 miles before you come to a curve, and where the best measure of traffic is hours per car. Rules that apply to one don't necessarily work well in the other.
We used to call this condition, having our attention hopping from one thing to another to another in quick succession, "running around like a chicken with it's head cut off". You deal with a lot of things, but you don't have time to really pay attention to any one of them because your attention needs to hop to the next. You waste time shifting mental gears, and more time picking up your train of thought for this item. In computer science we call it "thrashing", and it's something to be avoided because the overhead of context-switching eats up cycles that could be used for actual work. In extreme cases it gets so bad the system's doing nothing but thrash, no actual work gets done because all the cycles are eaten up by swapping and context switching. Humans are vulnerable to the same thing.
That's why geeks value being "in the zone" so much. It's nothing mysterious, it's just the condition of being able to focus on one specific thing without interruption, and it makes you so much more productive (hence why geeks seek it out).
Also: the law, read it. For instance, in California contracts with your employer governing IP ownership are subject to California Labor Code Section 2870-2872. That law limits the claims to ownership such a contract can make, and makes any such contract void to the extent that it purports to reach beyond what the law allows. I make it a point to amend any IP agreements to mention that any claims they make are limited to what's allowed by that section of the labor code, it's not necessary but it makes it completely clear that they and I understand the rules that apply. Given the breadth of claims in the standard contracts, if you work in California then any claims are more likely governed by the law rather than the contract.
I don't know about a Google cache, but you could check the Apache release notes against the version of Apache running at the time. I did. And while the version was quite a few patchlevels old and there were quite a few bugs fixed in the more recent revisions, most of those bugs were for either denial-of-service vulnerabilities (attackers could use them to crash, lock up or overload the server but couldn't gain access to data through them) or vulnerabilities specific to Apache running on Windows (SOE was using Unix-based servers so those wouldn't apply). The ones that were left were exploitable only in certain non-standard configurations, ones SOE was unlikely to be using. While there definitely was a hole somewhere, it doesn't look like SOE was recklessly running a known-vulnerable server. Rather, they were doing the sensible thing and not messing with a working production system until there was a version released that addressed a problem that applied to them.
If I had to guess, I'd say it's more likely the attackers got in through malware infecting the standard Windows PCs used inside the company, and leveraged that to gain access to the servers from the inside.
Actually I think what they wanted was to be aggregated on both Google search and news, but to have Google pay them for doing so. The problem is that the law says Google must either pay them for using the content or not use the content. Copiepresse thought they could dictate which choice Google had to make, and now they're whining that they can't and Google chose the "wrong" option and... Mommy! Mommy! He won't let me play with his toys unless I let him play with mine and IT'S NOT FAIR!
Not quite. Stephens Media would have to assign the copyrights, period. Or grant Righthaven an exclusive license to eg. publish the stories. Basically, for Righthaven to gain standing Stephens Media would have to give up some or all of their rights to those works and hand them over to Righthaven. And, as the court said, the "right to sue" is not one of those rights.
Think of it like the light from a flashlight. The light doesn't exist independently of the flashlight. If you want to give someone the ability to light up a dark room, you have to give them the flashlight. The light isn't some independent thing, it exists only as part of the flashlight and goes where the flashlight goes. Lack the flashlight, you lack the light. The "right to sue" over copyrights is the same thing: part and parcel of ownership of or control over the copyrights themselves. It goes where that ownership or control goes, and can't be separated from them.
That's the same thing I've found: to be useful you have to review such a big chunk of code that you can't do it in a reasonable amount of time. So the review ends up focusing on either stylistic crud like the exact conventions for whitespace and naming, or it focuses on things like should you use a for or a while loop there or whether you should use indexing or an iterator on a container, stuff like that. The big philosophical things that'd make a huge difference, like how functionality should be factored out, what support functions ought to be present in various classes and is all the groundwork needed for future expansion present, all get ignored because they start dragging in too much code and it takes too long for people to get their heads around why it was done the way it was in the first place (which you've got to grok before you can say whether it's right or not).
IMO the better way to do it is to team people up to do the work, and shuffle the teams around so everyone gets to work on different code with different people for different assignments. Problem here is again management, who don't like needing two programmers working on one bit of functionality when it only takes one and the other could be producing something else.
Slashdot Mirror
Just bear in mind this: I'm one of those 1% of Linux users. But I'm also the guy the other 99% come to when they want a recommendation on what to buy. And I'm the guy they come to when their system's having a problem and they need it fixed. They've experienced the migraines having the manufacturer service it (all their precious files gone, all their software wiped and of course the product keys (if there were any) were in their e-mail which went with their data so they have to buy the software all over again), that's why they come to me.
Now, what do you think's going to happen when all those "normal" people come to me and I point them at vendors who don't lock down the BIOS? And when they ask me about a major vendor who does lock it down so it'll only run windows and I say "Sorry, their machines won't let any of my tools run so if you buy one I won't be able to help you with it."? They're going to go with my recommendation if only because they want their friendly neighborhood geek to be willing to fix their systems when they break.
It's like the large corporate world. The CEO's only one person in a company of tens of thousands. He probably doesn't even have any contact with any of the departments that actually buy and use the equipment. But get him mad at you and you're going to lose a lot more than just one person's purchases.
I think the big driver for OEMs telling Microsoft to rethink this will be Windows 7 and XP. A lot of major companies won't be ready to deploy Windows 8, especially with money tight. And they'll need to deploy, not stock Windows 7, but the specific image with the specific patches that they've certified compatible with all the other software they need to run. Fail to do that and IT's going to come back with a big requirement to re-certify everything that'll cost a lot of money and take a lot of time, and management'll buy off on it because it'll be phrased as "If we don't verify everything, we're risking another company-wide outage for some unknown number of weeks until the vendors get us a fix. Remember how much pain that caused last time it happened?".
The big vendors like HP and Dell aren't going to go for something that'll cost them their biggest corporate customers. And the motherboard OEMs won't go for something that'll cost them both their big vendor contracts and their boutique component sales to gamers and the like.
They're using SSL in a standard way. What the article gets confused is the difference between SSL (the protocol used to encrypt connections) and HTTP Referrer header handling (used to pass referrer information to the target site). Note that the two have nothing to do with one another.
The convention has been that when the source page is https: and the target page is http: the Referrer header is suppressed, while if both are https: the Referrer header is passed normally. Google's changed this to a different rule: if it's an organic seach link the Referrer header is suppressed always, if it's a paid placement link the Referrer header is sent always. That's a change from conventional HTTP Referrer behavior, but not a change in SSL at all.
And I'd note that it also has nothing to do with paying for position within the organic listings. You can't pay for placement there. All you can buy is advertising space separate from the organic listings.
The problem is that we've got clocks. They've got noon and midnight on them. We've also got the sun. It rises at dawn, sets at sunset, and mid-way through the day it's straight overhead. And silly humans, we expect our clocks and the sun to be sorta-kinda in sync. We expect that mid-way through the sun's cycle, when it's straight overhead at what we call noon, our clocks are also going to be mid-way through their cycle and will be reading noon. We expect midnight on the clocks to be in the middle of the night. And we expect dawn and sunset to be in the morning and evening by our clocks.
Any solution proposed needs to accomplish the same synchronization. Not for any technical reasons, but because people expect it. It's not an implementation detail, it's a system requirement. Your "solution" tries to cross that requirement off as invalid or irrelevant, which means it immediately gets dismissed as "fails to meet requirements".
What methodology is this company using to measure activity on Google+? If it's public posts, they may have a serious systemic problem: people who use G+ specifically because it's so easy to not post publicly. My guess is the majority of G+ users are posting only to their circles, in which case there'd be a plethora of stuff that Chitika Insights simply won't see.
Google isn't stupid. More importantly, Google's lawyers aren't stupid. And if there's one thing Google's good at, it's sifting through masses of data, teasing out the relationships and putting them together. So I'm assuming Google has a plan and it's not completely half-baked. We'll have to see whether it's successful or not, but they do have a plan.
The problem with debt-collection calls is that often they use a robo-calling system: when you pick up the phone you get a recording saying "It is important you take this call. All our representatives are busy servicing other customers, please stay on the line until a representative is available.". And then you sit on hold for some unknown length of time, footing the bill because the collection agency finds it cheaper to do automated calling than to actually have representatives handle each call.
My feeling is that if it's actually important to them that I talk to them, it's important enough that they'll have a human being ready to talk to me when I pick up the call. If they don't, and especially if the recording doesn't say who's calling or the name isn't one I recognize, i assume it's not that important to them and hang up. But on a cel phone that incoming call still burned up air time that I have to pay for and now can't use for legitimate calls.
So, if my physical wallet isn't going anywhere because I still need it for all the cards, cash and stuff I need to carry that I can't put on my phone, and I still need actual cards for merchants who don't have the right tech at their registers, what exactly does Google Wallet do for me? I can't think of a time when I'd have my phone and wouldn't have my wallet on me, so it's not convenience. About all it seems to do is enable Google to watch what I purchase. Sorry, I'm going to need something of benefit to me first.
OK then, what's the sales tax rate that applies to me?
Seriously. Where can Amazon go to find the sales tax rate that applies to any arbitrary person in the US? State sales tax rate won't work, that's not the sale tax rate for me. You need to take into account county and city sales taxes plus any special districts applicable to me. No, they aren't available on-line. No, you can't call a single state agency and get it. No, you can't go by ZIP code because many ZIP codes span tax boundaries (eg. part of the ZIP code is inside the city limits and subject to city sales tax, part is outside and isn't).
And if you want Amazon subject to this, then make every brick-and-mortar store subject to it too. No more ignoring where their customer lives and only collecting sales tax for the business's address, every single store has to collect tax based on the customer's address just like Amazon.
Of course none of the "solutions" will work. Laying people off will mean less service. And no, reduced volume doesn't mean they've got excess people. It takes just about as many people to handle, sort and deliver one piece of mail per address as 20 pieces. Less service means more reasons for former customers to find and use alternatives. And higher rates means more former customers find the alternatives more attractive.
And taking an honest look at my mailbox for the last couple of months, I find maybe half-a-dozen pieces of mail per week that I actually asked for. The rest is advertising of some sort or another. And of the small fraction I asked for, I only actually need a couple a month. The rest I could get through e-mail or the Web if I wanted to, I only keep them coming through snail-mail in case I'm hospitalized or something and someone else needs to handle my bills (it's already happened once). The USPS's problem is that changes in technology are steadily making them obsolete. They let UPS and Fedex and others take overnight delivery and parcel post away from them. E-mail took the regular first-class letter business away. On-line options are eating away at the use of mail for bills and payments. What's left? Advertising, and stuff where delivery by USPS carries a legal presumption of receipt. That's not much to build a business on.
If you turn on tag review, items you're tagged in don't appear on Facebook until you review and approve them. You can also turn on profile review, and set profile visibility to friends only. If you set those things appropriately and the person trying to tag you also tries to block you from seeing what they've tagged you in, they paint themselves into a corner: if you can't see it you can't review and approve it, and if you don't approve it it's not visible to anyone.
That said, the new settings feel to me like they give me less control over what my name's attached to.
The reality is that people's body rhythms aren't tied to the clock, they're tied to the sun and the day/night cycle. We sleep when it's dark, we're active when it's daylight. And that cycle likes to run at a roughly 24-hour frequency. Eliminating timezones won't change the fact that when it's noon in New York it's 2 hours after midnight in Sydney, Australia. Eliminating time zones won't change the fact that when you get off that flight from New York your body's clock will be 10 hours out of sync with Sydney's local day/night cycle. And it won't magically make the people in Sydney want to have meetings in the dead of their nighttime just because the sun's high in the sky in New York.
Besides which, you don't need to eliminate timezones if all you want is a consistent clock. The military already uses Zulu time (roughly GMT) for most purposes. You can do the same.
I think they intend the touchscreen to be used in place of the mouse. Which'd actually work well, if the games had direct support for the hardware. But that's the kicker, getting game-dev support.
The FCC doesn't really care whether the phone is fully open or not. All they care about is that the radio in the phone not operate outside the allowed parameters. The problem comes from the manufacturers wanting to use radio hardware that isn't limited to the permissible parameters, and limit it's operation using easily-changed software controls. If they used radio hardware that was itself limited to permissible parameters, there wouldn't be any problem with it being open. But that would make the hardware more expensive and cut into profit margins.
Note also that "permissible parameters" vary depending on the user, not the device. If the user happens to have an FCC operator's license, the permissible parameters for a cel phone may be radically different from what an unlicensed user would be allowed.
Two things though. First, as a software developer your contract with your employer states explicitly that the copyright on code you produce rests with your employer, not you. If it didn't, the default rules are that you own the code, not the company. Second. software developers like that are also W2 employees, not independent contractors. And that makes a difference. There's been several run-ins between companies and the IRS about employee status, and the labels may be walking into a minefield. If the artists really are employees, not independent contractors, then the labels are responsible for payroll tax withholding, unemployment insurance payments, employer's portion of SSI and Medicare taxes, etc. etc..
Google does block competitors from Android phones, but it's not because they're Android phones. Anyone can make an Android phone and use any search-engine default, any advertising network, that they want. What Google does is say that if you want to use the Google brand on the phone you can't use non-Google services on it. To me that seems to be a completely valid use of their trademark, and has nothing to do with their position in search. You want an Android phone that doesn't put Google front-and-center? Look for one that isn't Google-branded. And as far as I know Google does nothing whatsoever to stop anyone from making a non-Google-branded Android phone, correct?
How about, instead of sniffing for the browser types you (think you) know support what you need, sniff for the features you need directly? That way your app will work just fine with any browser that supports what you need, and if it doesn't support what you need you'll be able to tell the user exactly what his browser's missing so he can fix it (it may be he just needs to update his browser, or install a plug-in or optional feature he hasn't gotten around to yet).
We do need a class of certificate that simply verifies that we're talking to the host we expect to be talking to (ie. that the name of the host using the certificate matches the name of the host in the URL). That's sufficient for encryption-only purposes, where I'm using SSL not to validate the remote end's identity in any way but merely to prevent eavesdropping on the data stream by third parties. DNSSec addresses some of that, but it doesn't provide the encryption layer that SSL does.
Bluntly put, there's a lot of cases where I don't care about the absolute, real-world identity of the entity I'm talking to, only that I'm talking to the same entity every time. Think the Dread Pirate Roberts.
That depends on the area. Out West there's a lot of places where the lower speed limit will cost lives. That's because there's long stretches of cross-country freeway where the primary causes of accidents isn't speed, it's driver fatigue. The most common accident type is the single-car rollover on level, clear highway. Speed isn't usually a cause of the loss of control, it's usually either a driver falling asleep at the wheel or being drunk. Reduced speed limits won't help either of those, and will hurt in the first case. The slower you have to drive, the longer it takes to get where you're going (because the distance doesn't magically shrink along with the speed limit) and the more likely you are to get too tired before you get there. And stopping often isn't an option. This is country where that sign saying "Next services 300 miles" isn't joking, and it means "Next hint of human habitation of any sort 300 miles".
A dense urban area is a radically different environment from a rural area where highways can run straight and level for 30, 40 or 50 miles before you come to a curve, and where the best measure of traffic is hours per car. Rules that apply to one don't necessarily work well in the other.
We used to call this condition, having our attention hopping from one thing to another to another in quick succession, "running around like a chicken with it's head cut off". You deal with a lot of things, but you don't have time to really pay attention to any one of them because your attention needs to hop to the next. You waste time shifting mental gears, and more time picking up your train of thought for this item. In computer science we call it "thrashing", and it's something to be avoided because the overhead of context-switching eats up cycles that could be used for actual work. In extreme cases it gets so bad the system's doing nothing but thrash, no actual work gets done because all the cycles are eaten up by swapping and context switching. Humans are vulnerable to the same thing.
That's why geeks value being "in the zone" so much. It's nothing mysterious, it's just the condition of being able to focus on one specific thing without interruption, and it makes you so much more productive (hence why geeks seek it out).
Also: the law, read it. For instance, in California contracts with your employer governing IP ownership are subject to California Labor Code Section 2870-2872. That law limits the claims to ownership such a contract can make, and makes any such contract void to the extent that it purports to reach beyond what the law allows. I make it a point to amend any IP agreements to mention that any claims they make are limited to what's allowed by that section of the labor code, it's not necessary but it makes it completely clear that they and I understand the rules that apply. Given the breadth of claims in the standard contracts, if you work in California then any claims are more likely governed by the law rather than the contract.
I don't know about a Google cache, but you could check the Apache release notes against the version of Apache running at the time. I did. And while the version was quite a few patchlevels old and there were quite a few bugs fixed in the more recent revisions, most of those bugs were for either denial-of-service vulnerabilities (attackers could use them to crash, lock up or overload the server but couldn't gain access to data through them) or vulnerabilities specific to Apache running on Windows (SOE was using Unix-based servers so those wouldn't apply). The ones that were left were exploitable only in certain non-standard configurations, ones SOE was unlikely to be using. While there definitely was a hole somewhere, it doesn't look like SOE was recklessly running a known-vulnerable server. Rather, they were doing the sensible thing and not messing with a working production system until there was a version released that addressed a problem that applied to them.
If I had to guess, I'd say it's more likely the attackers got in through malware infecting the standard Windows PCs used inside the company, and leveraged that to gain access to the servers from the inside.
Actually I think what they wanted was to be aggregated on both Google search and news, but to have Google pay them for doing so. The problem is that the law says Google must either pay them for using the content or not use the content. Copiepresse thought they could dictate which choice Google had to make, and now they're whining that they can't and Google chose the "wrong" option and... Mommy! Mommy! He won't let me play with his toys unless I let him play with mine and IT'S NOT FAIR!
Not quite. Stephens Media would have to assign the copyrights, period. Or grant Righthaven an exclusive license to eg. publish the stories. Basically, for Righthaven to gain standing Stephens Media would have to give up some or all of their rights to those works and hand them over to Righthaven. And, as the court said, the "right to sue" is not one of those rights.
Think of it like the light from a flashlight. The light doesn't exist independently of the flashlight. If you want to give someone the ability to light up a dark room, you have to give them the flashlight. The light isn't some independent thing, it exists only as part of the flashlight and goes where the flashlight goes. Lack the flashlight, you lack the light. The "right to sue" over copyrights is the same thing: part and parcel of ownership of or control over the copyrights themselves. It goes where that ownership or control goes, and can't be separated from them.
That's the same thing I've found: to be useful you have to review such a big chunk of code that you can't do it in a reasonable amount of time. So the review ends up focusing on either stylistic crud like the exact conventions for whitespace and naming, or it focuses on things like should you use a for or a while loop there or whether you should use indexing or an iterator on a container, stuff like that. The big philosophical things that'd make a huge difference, like how functionality should be factored out, what support functions ought to be present in various classes and is all the groundwork needed for future expansion present, all get ignored because they start dragging in too much code and it takes too long for people to get their heads around why it was done the way it was in the first place (which you've got to grok before you can say whether it's right or not).
IMO the better way to do it is to team people up to do the work, and shuffle the teams around so everyone gets to work on different code with different people for different assignments. Problem here is again management, who don't like needing two programmers working on one bit of functionality when it only takes one and the other could be producing something else.