OK, so the display portion that takes milliseconds at most now takes 4-5 milliseconds less time. Meanwhile the browser's taking 10-30 seconds choking on bloated Flash, over-large images and hundreds of K of insanely-convoluted nested Javascript files. Somehow I don't think graphics acceleration will help speed up Web sites significantly.
It's kind of like cars: sure the McLaren F1 may be faster than my Ford Focus, but it's not the car that's setting the 75mph speed limit.
One thing here: the Autodesk case involved software bought directly from the vendor, where the buyer signed a contract before paying and receiving the software. In a store there's no signed contract, in which case the Uniform Commercial Code comes into play (it wouldn't in the Autodesk case). And one thing the UCC makes clear: if there's no explicit agreement prior to the buyer forking over his money and the seller handing them the box, then the terms of sale are defined by the UCC and not the seller. And one thing the UCC says is that it is a sale, not a license.
The trick is to avoid getting caught up in copyright until you've settled the issue of whether it's a sale or not. You have to decide that first, because what your rights are under copyright depend on that.
A BIOS-based bootloader has problems. The most basic one's the one that makes LILO such a pain: locating the second-stage boot file (eg. the Linux kernel itself, or the NT system loader). You either have to be able to interpret all possible boot filesystems well enough to locate and read a file on them (the GRUB method), or you need to have a list of what sectors need to be read in for each bootable OS (the LILO method). The problem with the LILO method is that anything that touchs the boot files and might result in them moving requires rebuilding the bootloader sector list. Forget to do that and your system may become unbootable, or worse may still be bootable but have loaded corrupted data as kernel code. The GRUB method means no rebuilding the boot information, but it requires the ability to update the boot software to support new filesystems as they come into use. In day-to-day use I think the GRUB method causes fewer headaches.
I think we just ought to make official the unspoken convention: the area outside of any partition (ie. the boot sector and the unallocated space between the boot sector and the start of the first partition) belongs to only two things, the partition table and the boot loader. OSes should concern themselves only with the area within the partitions. The only exception to that should be the OS-provided partitioning and boot-loader support tools, and those only if the OS's partitioning software and boot loader are actually being used. Applications should not be permitted to write to raw disk at all unless they're explicitly being run as administrator, and shouldn't be doing so even if running as administrator unless they're intended to modify boot and partition information.
Only one problem: most municipalities contemplating running their own broadband Internet service are doing it precisely because the cable and phone companies aren't providing the service. It's time to stop thinking about Internet access as a service and start thinking about it as a utility, with the changes in mindset that implies (eg. you don't want parts of your city to be without water or electricity just because the utility companies think it won't be cost-effective to serve them).
Devs are not special snowflakes either and are being outsourced/offshored/automated just as much as the admin roll.
Yes, they are. I have to deal with the results every day. I dread having to deal with code from the outsourced dev team, because it always takes twice as long as it should to unravel all the unrelated problems in their code to uncover what's actually causing our issue. And we're not allowed to bill the time to their budget.
Speaking as a developer, I want/need read-only access in production. All too often I need to dig out information while troubleshooting, and most commonly I don't know what all bits I'll need when I start. If it were easy to identify exactly what I'd need to find the problem, I usually already know what the problem is. The hard ones are the ones I can't replicate in development and I only have a starting point, something that won't identify the problem but might help me narrow down where to look next. In those cases the only place I can look is production (since I can't make it happen in a controlled development environment) and I can't give the admins a list of what I'll need (because I need to dig through logs and config files before I'll know what I need to look for next). And if we've gotten to this point, it's probably a priority problem impacting production so it needs to get fixed Right Bloody Now.
OTOH, while I may need to look at production, I don't need and don't want the ability to modify production except by going through the admins. This, of course, also requires admins who can follow basic instructions like "Look at config file FOO. Find the line in section X that starts with Y. It's value should be XYZZY followed by the number 1. Change that 1 to a unique number for that machine/instance. Repeat this for every machine/instance.". But all too often the response is "That's too complicated. Can you just give us config files to install?". And of course when I ask for the current config files, so I can be sure I'm not overwriting any other modifications to them (which may have happened since the admins control them and do modify them), I get "We can't do that, they've got production passwords in them.". Now all I can do is throw up my hands and go "Whatever.".
Bloggers getting paid isn't a problem. Bloggers not disclosing they're being paid by an entity with a vested interest, or entities not disclosing that they're paying bloggers to write stories about them, that's the problem. And as noted, while the GOP could come up with bloggers being paid by the Democrats those bloggers did in fact disclose this fact on their blogs so their readers knew they were reading paid stories. Unlike the GOP bloggers, who didn't disclose they were being paid.
Simple solution: don't report your income on federal Schedule C (or the state equivalent) when the amounts involved are that small. Just report it as miscellaneous personal income. Sure you won't be able to deduct expenses, but the amount's small enough it won't make much difference and you'll avoid the tax forms that flag you for inanity like this. If you do insist on reporting it on Schedule C, remember that the business license fee is an expense you can use on next year's forms.
I'm not sure if I'd call something like Kingdom of Loathing "successful" in the commercial sense. It sounds a long way from being nearly as successful as say Everquest 2, which at best guesstimate brings in at least $2-2.5 million a month in revenue (and EQ2's not the most successful MMORPG out there).
After reading the article, the author seems to simply not talk about two things (at least as related to conventional MMORPGs).
First, he doesn't address the question of the effect of monetization on player base. In his HappyFunTime example, for instance, he blithely assumes that both monetization systems have the same number of players. But is this true? I know many players who actively avoid games with aggressive monetization systems, especially those where the best items are available only via RMT or where progress beyond a certain point requires RMT purchases (which is not related to whether or not you can continue to play forever for free, it's a question of whether, eg., access to the best end-game instances and raid zones requires paying or not). Their thought is that games aren't a paying job for them, and those sorts of games are going to be dominated by professional players for whom the game in fact is a paying job (they either make money off of player-to-player RMT if allowed or they're employed by a plat-farming and/or power-leveling service) They're also wary of putting time and effort into developing a character in a game where their progress and ability to play with their friends may be randomly blocked by the vagaries of real-world finances (eg. your friends want to run a raid but this week your checking account just doesn't have enough in it to pay for access to that raid zone). For them it's safer to stick with games with a less aggressive monetization model, ones where they won't have those problems.
Second, there's the question of how well the player base will stick with the game when economic times get tough. We're going through a time like that right now, for instance. I'd think that when times get tight players will abandon games that effectively mandate out-of-pocket costs (ie. have aggressive monetization models) every month more readily than fluff-only or flat-subscription games. In games where RMT gets you fluff-only items, you can cut your out-of-pocket costs quickly and decisively without seriously impacting your game experience. In flat-subscription games, you don't even have to worry about your cost level since it's going to remain steady and predictable. If you can afford to play at all, your play experience doesn't depend on how much you're spending. My experience has been that those things create a player base that finds the game a better value for the money and that'll be less likely to drop it than other things when their entertainment budget starts to get squeezed. IMO designing a game that's highly vulnerable to economic ups and downs is a more risky proposition than designing one that's attractive even in the bad times.
Young people don't read newspapers. Not in the way Murdoch's thinking, at least. They don't start on page 1 and read through to the end. And they don't compile a list of subjects and read consistently on those subjects for months at a time. They get a sudden interest in a particular subject, search for stories about that specific subject right now, skim them and maybe read a few of the most interesting ones, then go on to other things until another subject piques their interest. This is why Google's so popular: it makes it easy to do exactly that. If Murdoch doesn't accept that, he's simply going to be passed over yet again.
I have all my accounts and their passwords recorded on paper. It's stored in my safe with a bunch of other paperwork that'll be needed after my death, and my executor knows where those are and how to get at them. I've also got my power-of-attorney papers and will written so as to give the executor of my estate authority over my on-line accounts for the purposes of cleaning them up and eventually closing them following my death.
Whether various services have or haven't decided how to handle user accounts upon the user's death, they'll find that their terms of service do not trump well-established law concerning power-of-attorney and estate management. And my executor has an attorney on tap who's familiar with all this and well-versed in handling estates. He anticipates minimal problems, and any that do crop up should be resolved quickly (California law mirrors the FRCP when it comes to attorney sanctions for frivolous legal positions).
My problem with this argument is that it's basic premise is false: it presupposes that I have more choice of ISPs than I have of government regulators. It so happens that this is incorrect. I have a choice of one regulator: the FCC. But I only have a choice of perhaps 2 ISPs: the cable company who serve my area, and the phone company that serves my area. That's because providing Internet service involves running wires along the public right-of-way, and those two entities have a legal monopoly on that. Normally I'd discount that, except that the monopoly exists because of the actions of those entities themselves: they refused to provide service at all unless they were granted that monopoly. This isn't a case of the government just up and granting them the monopoly, they actively worked to get it.
And their interests don't align with mine. I want, for instance, VoIP service that's cheap, reliable and of decent quality. They want to provide VoIP service that they can charge me for while spending the least they can on it. Normally they'd immediately be buried by Skype (which is exactly what actually happens), but if they can discriminate based on whose VoIP packets those are they can force Skype to be unusable by me and give me no option but to use their service if I want VoIP. The same for streaming audio, video, photo hosting, blogging, everything. The FCC, at least, isn't directly profiting by their regulations. So if I have to be subject to the whims of an entity and my alternatives are extremely limited at best and aren't radically different from each other, I'll take the one that isn't going to profit by hamstringing me.
Only one problem: the filesystem gets wiped along with the data. When these drives are powered off, they aren't just blank drives they become unformatted drives as far as the copier's concerned. And I really doubt those copiers have the brains to automatically handle an unformatted drive.
Thing is, the ISP's already granted me (as a customer) an easement across their wires. Why do you think the bill they send me every month, that if I don't pay my service will be disconnected, is for? So when I as a customer hit Google and Google sends me data, I'm just using the easement I've already paid the ISP for. And it hurts the ISP's profits not one bit if the government says they have to be even-handed in allowing me to use that easement. It doesn't let the ISP increase their profits by interfering with things that compete with services the ISP wants to offer, but then the ISP never had a legal right to increased profits just by offering a service that competitors also offer.
And of course Google's paying for it's own Internet access, so the whole "Google is free-riding!" whinge doesn't fly. Google may not be paying my ISP for Internet access, but that's OK because Google isn't getting Internet access from my ISP and they are paying the ISP they get access from. The deal between my ISP and the provider Google gets access from... well, that's between them. If my ISP isn't satisfied with their deal with Google's provider, my ISP needs to take that up with Google's provider and change the deal. It's simply not my problem nor Google's.
Probably a bit of both. The need/desire to catch building-code violations was always there. Odds on someone in the department was looking up an address on the map or on Google Earth and noticed how easy it was to spot objects like cars, buildings and swimming pools. And once they mentioned how clear the imagery was, it didn't take long for someone to put 2 and 2 together and come up with the idea of scanning the imagery for swimming pools at addresses that hadn't gotten a permit for one. Probably it started as a quick way to verify complaints, and then someone started actively looking for violations on a slow day.
Having too much storage is an easy problem. Sure it cost a bit more, but not prohibitively so or you'd never have gotten approval to spend the money. Not having enough storage, OTOH, is a hard problem. Running out of space in the middle of a job means a crashed job and downtime to add more storage. That probably just cost more than having too much would've, and then you pile the political problems on top of that. So common sense says you don't provision for the storage you're going to normally need, you provision for the maximum storage you expect to need at any time plus a bit of padding just in case.
AT&T discovered this back in the days when telephone operators actually got a lot of work. They found that phone calls tend to come in in clumps, they weren't evenly distributed, so when they staffed for the average call rate they ended up failing to meet their answer times on a very large fraction of their calls. They had to change to staffing for the peak number of simultaneous calls, and accept the idle operators as a cost of being able to meet those peaks.
Problem here: you're assuming that the disclosure causes the problem. That's incorrect. I was just as vulnerable, and just as likely to have someone exploiting the vulnerability, before the disclosure as after. If the researcher found it, odds are the black hats found it long ago and have been actively using it. But now I know about the problem and know what to look for to see if we've been breached (or are in the process of being breached).
The ostrich reaction, the "if I don't know about it it doesn't exist" response, sounds attractive, but in the end sticking your head in the sand doesn't make the tiger about to bite your butt off go away, and having your head forcibly jerked out of the sand didn't cause the tiger to appear.
In a lot of cases they're convenient but not necessary. I'd prefer to run them, they make life simpler for everyone, but I can live without them if that's what's required to keep things secure. Eg., webmail or web access to a ticket tracking system. They're nice to have, and there's a compelling business argument for having them available as an alternative to dedicated client software, but not such a compelling one that we'd be willing to sacrifice security to have them. So if they're secure we want them running, but if they're not secure then we can afford to shut them down.
If it's merely difficult, remember this: with computer code it takes just one single genius somewhere figuring it out to enable every 2-bit script-kiddie with a mouse and an ego to use it. Once there's a working method it's just a matter of packaging it up into an easy-to-use kit.
The trick, however, is in figuring out the method. Now, if you've got ring 0 then by definition you've got more power on the system than root has. If you can't turn this into user-mode root then I have to be skeptical of your claim. It sounds like what you've got is a way to get ring 0, but address-space randomization's preventing you from exploiting this to actually execute your chosen code in ring 0 without doing random probes that tend to cause the system to crash before you actually find the right spot. Which is of course exactly what it's supposed to do. Or there's something else you're not mentioning. I've run into a few of those, the "I can get root on the system if I'm allowed to load a kernel module or device driver.", or the "It'd work if the kernel implements it like this, but it doesn't so the exploit doesn't actually work.".
A deadline's always feasible. It may not be possible to come up with a clean fix in a short timeframe, but you can always come up with either a workaround or something the users can do to mitigate the damage. This may not be ideal from the vendor's point of view, but it's not the vendor who's in danger of having their systems attacked so I'm not overly concerned about their public-relations heartburn.
There's also another ethical issue: keeping me (as an administrator of vulnerable systems) in the dark about the vulnerabiility puts my systems at risk and prevents me from protecting my systems. You are hurting me in a very direct way by not disclosing the problem to me. If I know the problem exists I can for instance shut down the vulnerable services (if they aren't necessary for my systems to operate), block access to those services at the firewall and/or replace the vulnerable software with equivalent software that isn't vulnerable. I can't do this unless I know the vulnerability exists. People who want me kept in the dark about the problem strike me as the type who at least don't care how much damage the rest of us suffer, and possibly have a vested interest in having vulnerable systems exist.
In most cases you warn the vendor first, providing complete details including exploit code so they have no excuse for not being able to duplicate the problem. If the vendor won't acknowledge your report within a reasonable time (say 7 days), will not commit to a timeline for having either a fix, a workaround or a mitigation strategy for users within a reasonable time (say 14 days from acknowledgement, with the deadline being 30-90 days out depending on severity) or fails to meet the deadline, then you disclose to users including full details, exploit code (so the problem can be independently verified without having to rely on your word that it exists) and a recommended mitigation strategy. Demanding payment for the report is never appropriate unless the vendor has publicly committed to a "bug bounty" and your demand is what they've publicly committed to.
There'd be occasional exceptions to the above. If for instance the vulnerability is theoretical and you can't create actual exploit code for it, demanding the vendor fix it is inappropriate (by the same token, though, it's far less of a problem to discuss the problem in public if it truly can't be feasibly exploited). The deadline should be more flexible for less severe vulnerabilities. If the vendor has a track record of responding inappropriately to reports (eg. by threatening legal action against the researcher), immediate anonymous disclosure may be a better approach.
We generated our first real radio signals sometime around 1894, give or take. That means that we are completely and utterly invisible in the radio spectrum to any civilizations more than about 116 light-years away from Sol. Our radio signals simply haven't had time to reach them yet. And the same thing applies in reverse: if an alien civilization began transmitting radio signals 200 years ago but they're more than 200 light-years away from us, we won't be able to see them because their signals haven't had time to reach us yet.
That defines the outer edge of the visibility shell. There's also an inner edge. As a civilization develops, it eventually stops transmitting radio signals as it first gets more efficient at transmitting radio (moving from pure broadcast to directed transmissions and then refining their ability to direct the transmission into tighter and tighter beams) and then starts using things other than radio. If you start listening after the last of their detectable broadcasts has passed you, again you can't see them.
So when you're asking "If there are as many civilizations out there as the equations predict, why can't we detect them?" you also have to take into account the fact you're likely only physically able to detect a fraction of the civilizations that may exist. The rest are either too far away for their signals to have reached you, or they've been around long enough that you weren't listening when the last of their detectable transmissions passed your planet.
To me it boils down to two things. First, is this really an optional service or is it something I have no choice but to have? Things like checked-luggage charges or reservation-change fees, I don't necessarily have to buy those services. I don't always change my reservations (in fact I usually don't), and I may be traveling with only my carry-on (in fact I prefer to do that when I'm flying if I have any choice in the matter). Other things like gate fees I'm going to have to pay every single time, no matter what. To me, if I can't decline to pay it and still be able to fly then it should by rights be included in the ticket price. To call it "unbundled" is simply deceptive, it implies something's optional when in fact it's not.
Second, for truly optional services, are the terms clearly disclosed? When I buy a ticket I should be able to clearly see how much my checked luggage will cost me, how much it'll cost me to change or cancel the reservation later, how much all those unbundled services will cost and what terms I'll have to comply with. The big problem I have with the airlines is that most of the time they don't clearly disclose any of that. Last time I bought airline tickets, it took half an hour of digging to answer a simple question: what would the baggage fees be for 1 checked suitcase per person? You couldn't find this when you bought the ticket, and it took major digging into the help section of the airline's web site to find the answer. And even then it wasn't a straight answer, just a list of conditions and prices that you had to compare to your ticket's terms to match up. When I buy a ticket I ought by rights to be able to just see a list, for that particular type of ticket and that flight, how much it'll be per bag for standard and oversize/overweight bags and what the maximum number is. I know this isn't hard to do, I program computers for a living and this kind of database query and calculation's something it takes me maybe 1-2 working days to do. Note: "does take", not "would take", like I said I do this stuff for a living and I get exactly that kind of task on a regular basis.
Slashdot Mirror
OK, so the display portion that takes milliseconds at most now takes 4-5 milliseconds less time. Meanwhile the browser's taking 10-30 seconds choking on bloated Flash, over-large images and hundreds of K of insanely-convoluted nested Javascript files. Somehow I don't think graphics acceleration will help speed up Web sites significantly.
It's kind of like cars: sure the McLaren F1 may be faster than my Ford Focus, but it's not the car that's setting the 75mph speed limit.
One thing here: the Autodesk case involved software bought directly from the vendor, where the buyer signed a contract before paying and receiving the software. In a store there's no signed contract, in which case the Uniform Commercial Code comes into play (it wouldn't in the Autodesk case). And one thing the UCC makes clear: if there's no explicit agreement prior to the buyer forking over his money and the seller handing them the box, then the terms of sale are defined by the UCC and not the seller. And one thing the UCC says is that it is a sale, not a license.
The trick is to avoid getting caught up in copyright until you've settled the issue of whether it's a sale or not. You have to decide that first, because what your rights are under copyright depend on that.
A BIOS-based bootloader has problems. The most basic one's the one that makes LILO such a pain: locating the second-stage boot file (eg. the Linux kernel itself, or the NT system loader). You either have to be able to interpret all possible boot filesystems well enough to locate and read a file on them (the GRUB method), or you need to have a list of what sectors need to be read in for each bootable OS (the LILO method). The problem with the LILO method is that anything that touchs the boot files and might result in them moving requires rebuilding the bootloader sector list. Forget to do that and your system may become unbootable, or worse may still be bootable but have loaded corrupted data as kernel code. The GRUB method means no rebuilding the boot information, but it requires the ability to update the boot software to support new filesystems as they come into use. In day-to-day use I think the GRUB method causes fewer headaches.
I think we just ought to make official the unspoken convention: the area outside of any partition (ie. the boot sector and the unallocated space between the boot sector and the start of the first partition) belongs to only two things, the partition table and the boot loader. OSes should concern themselves only with the area within the partitions. The only exception to that should be the OS-provided partitioning and boot-loader support tools, and those only if the OS's partitioning software and boot loader are actually being used. Applications should not be permitted to write to raw disk at all unless they're explicitly being run as administrator, and shouldn't be doing so even if running as administrator unless they're intended to modify boot and partition information.
Only one problem: most municipalities contemplating running their own broadband Internet service are doing it precisely because the cable and phone companies aren't providing the service. It's time to stop thinking about Internet access as a service and start thinking about it as a utility, with the changes in mindset that implies (eg. you don't want parts of your city to be without water or electricity just because the utility companies think it won't be cost-effective to serve them).
Devs are not special snowflakes either and are being outsourced/offshored/automated just as much as the admin roll.
Yes, they are. I have to deal with the results every day. I dread having to deal with code from the outsourced dev team, because it always takes twice as long as it should to unravel all the unrelated problems in their code to uncover what's actually causing our issue. And we're not allowed to bill the time to their budget.
Speaking as a developer, I want/need read-only access in production. All too often I need to dig out information while troubleshooting, and most commonly I don't know what all bits I'll need when I start. If it were easy to identify exactly what I'd need to find the problem, I usually already know what the problem is. The hard ones are the ones I can't replicate in development and I only have a starting point, something that won't identify the problem but might help me narrow down where to look next. In those cases the only place I can look is production (since I can't make it happen in a controlled development environment) and I can't give the admins a list of what I'll need (because I need to dig through logs and config files before I'll know what I need to look for next). And if we've gotten to this point, it's probably a priority problem impacting production so it needs to get fixed Right Bloody Now.
OTOH, while I may need to look at production, I don't need and don't want the ability to modify production except by going through the admins. This, of course, also requires admins who can follow basic instructions like "Look at config file FOO. Find the line in section X that starts with Y. It's value should be XYZZY followed by the number 1. Change that 1 to a unique number for that machine/instance. Repeat this for every machine/instance.". But all too often the response is "That's too complicated. Can you just give us config files to install?". And of course when I ask for the current config files, so I can be sure I'm not overwriting any other modifications to them (which may have happened since the admins control them and do modify them), I get "We can't do that, they've got production passwords in them.". Now all I can do is throw up my hands and go "Whatever.".
Bloggers getting paid isn't a problem. Bloggers not disclosing they're being paid by an entity with a vested interest, or entities not disclosing that they're paying bloggers to write stories about them, that's the problem. And as noted, while the GOP could come up with bloggers being paid by the Democrats those bloggers did in fact disclose this fact on their blogs so their readers knew they were reading paid stories. Unlike the GOP bloggers, who didn't disclose they were being paid.
Simple solution: don't report your income on federal Schedule C (or the state equivalent) when the amounts involved are that small. Just report it as miscellaneous personal income. Sure you won't be able to deduct expenses, but the amount's small enough it won't make much difference and you'll avoid the tax forms that flag you for inanity like this. If you do insist on reporting it on Schedule C, remember that the business license fee is an expense you can use on next year's forms.
I'm not sure if I'd call something like Kingdom of Loathing "successful" in the commercial sense. It sounds a long way from being nearly as successful as say Everquest 2, which at best guesstimate brings in at least $2-2.5 million a month in revenue (and EQ2's not the most successful MMORPG out there).
After reading the article, the author seems to simply not talk about two things (at least as related to conventional MMORPGs).
First, he doesn't address the question of the effect of monetization on player base. In his HappyFunTime example, for instance, he blithely assumes that both monetization systems have the same number of players. But is this true? I know many players who actively avoid games with aggressive monetization systems, especially those where the best items are available only via RMT or where progress beyond a certain point requires RMT purchases (which is not related to whether or not you can continue to play forever for free, it's a question of whether, eg., access to the best end-game instances and raid zones requires paying or not). Their thought is that games aren't a paying job for them, and those sorts of games are going to be dominated by professional players for whom the game in fact is a paying job (they either make money off of player-to-player RMT if allowed or they're employed by a plat-farming and/or power-leveling service) They're also wary of putting time and effort into developing a character in a game where their progress and ability to play with their friends may be randomly blocked by the vagaries of real-world finances (eg. your friends want to run a raid but this week your checking account just doesn't have enough in it to pay for access to that raid zone). For them it's safer to stick with games with a less aggressive monetization model, ones where they won't have those problems.
Second, there's the question of how well the player base will stick with the game when economic times get tough. We're going through a time like that right now, for instance. I'd think that when times get tight players will abandon games that effectively mandate out-of-pocket costs (ie. have aggressive monetization models) every month more readily than fluff-only or flat-subscription games. In games where RMT gets you fluff-only items, you can cut your out-of-pocket costs quickly and decisively without seriously impacting your game experience. In flat-subscription games, you don't even have to worry about your cost level since it's going to remain steady and predictable. If you can afford to play at all, your play experience doesn't depend on how much you're spending. My experience has been that those things create a player base that finds the game a better value for the money and that'll be less likely to drop it than other things when their entertainment budget starts to get squeezed. IMO designing a game that's highly vulnerable to economic ups and downs is a more risky proposition than designing one that's attractive even in the bad times.
Young people don't read newspapers. Not in the way Murdoch's thinking, at least. They don't start on page 1 and read through to the end. And they don't compile a list of subjects and read consistently on those subjects for months at a time. They get a sudden interest in a particular subject, search for stories about that specific subject right now, skim them and maybe read a few of the most interesting ones, then go on to other things until another subject piques their interest. This is why Google's so popular: it makes it easy to do exactly that. If Murdoch doesn't accept that, he's simply going to be passed over yet again.
I have all my accounts and their passwords recorded on paper. It's stored in my safe with a bunch of other paperwork that'll be needed after my death, and my executor knows where those are and how to get at them. I've also got my power-of-attorney papers and will written so as to give the executor of my estate authority over my on-line accounts for the purposes of cleaning them up and eventually closing them following my death.
Whether various services have or haven't decided how to handle user accounts upon the user's death, they'll find that their terms of service do not trump well-established law concerning power-of-attorney and estate management. And my executor has an attorney on tap who's familiar with all this and well-versed in handling estates. He anticipates minimal problems, and any that do crop up should be resolved quickly (California law mirrors the FRCP when it comes to attorney sanctions for frivolous legal positions).
My problem with this argument is that it's basic premise is false: it presupposes that I have more choice of ISPs than I have of government regulators. It so happens that this is incorrect. I have a choice of one regulator: the FCC. But I only have a choice of perhaps 2 ISPs: the cable company who serve my area, and the phone company that serves my area. That's because providing Internet service involves running wires along the public right-of-way, and those two entities have a legal monopoly on that. Normally I'd discount that, except that the monopoly exists because of the actions of those entities themselves: they refused to provide service at all unless they were granted that monopoly. This isn't a case of the government just up and granting them the monopoly, they actively worked to get it.
And their interests don't align with mine. I want, for instance, VoIP service that's cheap, reliable and of decent quality. They want to provide VoIP service that they can charge me for while spending the least they can on it. Normally they'd immediately be buried by Skype (which is exactly what actually happens), but if they can discriminate based on whose VoIP packets those are they can force Skype to be unusable by me and give me no option but to use their service if I want VoIP. The same for streaming audio, video, photo hosting, blogging, everything. The FCC, at least, isn't directly profiting by their regulations. So if I have to be subject to the whims of an entity and my alternatives are extremely limited at best and aren't radically different from each other, I'll take the one that isn't going to profit by hamstringing me.
Only one problem: the filesystem gets wiped along with the data. When these drives are powered off, they aren't just blank drives they become unformatted drives as far as the copier's concerned. And I really doubt those copiers have the brains to automatically handle an unformatted drive.
Thing is, the ISP's already granted me (as a customer) an easement across their wires. Why do you think the bill they send me every month, that if I don't pay my service will be disconnected, is for? So when I as a customer hit Google and Google sends me data, I'm just using the easement I've already paid the ISP for. And it hurts the ISP's profits not one bit if the government says they have to be even-handed in allowing me to use that easement. It doesn't let the ISP increase their profits by interfering with things that compete with services the ISP wants to offer, but then the ISP never had a legal right to increased profits just by offering a service that competitors also offer.
And of course Google's paying for it's own Internet access, so the whole "Google is free-riding!" whinge doesn't fly. Google may not be paying my ISP for Internet access, but that's OK because Google isn't getting Internet access from my ISP and they are paying the ISP they get access from. The deal between my ISP and the provider Google gets access from... well, that's between them. If my ISP isn't satisfied with their deal with Google's provider, my ISP needs to take that up with Google's provider and change the deal. It's simply not my problem nor Google's.
Probably a bit of both. The need/desire to catch building-code violations was always there. Odds on someone in the department was looking up an address on the map or on Google Earth and noticed how easy it was to spot objects like cars, buildings and swimming pools. And once they mentioned how clear the imagery was, it didn't take long for someone to put 2 and 2 together and come up with the idea of scanning the imagery for swimming pools at addresses that hadn't gotten a permit for one. Probably it started as a quick way to verify complaints, and then someone started actively looking for violations on a slow day.
Having too much storage is an easy problem. Sure it cost a bit more, but not prohibitively so or you'd never have gotten approval to spend the money. Not having enough storage, OTOH, is a hard problem. Running out of space in the middle of a job means a crashed job and downtime to add more storage. That probably just cost more than having too much would've, and then you pile the political problems on top of that. So common sense says you don't provision for the storage you're going to normally need, you provision for the maximum storage you expect to need at any time plus a bit of padding just in case.
AT&T discovered this back in the days when telephone operators actually got a lot of work. They found that phone calls tend to come in in clumps, they weren't evenly distributed, so when they staffed for the average call rate they ended up failing to meet their answer times on a very large fraction of their calls. They had to change to staffing for the peak number of simultaneous calls, and accept the idle operators as a cost of being able to meet those peaks.
Problem here: you're assuming that the disclosure causes the problem. That's incorrect. I was just as vulnerable, and just as likely to have someone exploiting the vulnerability, before the disclosure as after. If the researcher found it, odds are the black hats found it long ago and have been actively using it. But now I know about the problem and know what to look for to see if we've been breached (or are in the process of being breached).
The ostrich reaction, the "if I don't know about it it doesn't exist" response, sounds attractive, but in the end sticking your head in the sand doesn't make the tiger about to bite your butt off go away, and having your head forcibly jerked out of the sand didn't cause the tiger to appear.
In a lot of cases they're convenient but not necessary. I'd prefer to run them, they make life simpler for everyone, but I can live without them if that's what's required to keep things secure. Eg., webmail or web access to a ticket tracking system. They're nice to have, and there's a compelling business argument for having them available as an alternative to dedicated client software, but not such a compelling one that we'd be willing to sacrifice security to have them. So if they're secure we want them running, but if they're not secure then we can afford to shut them down.
If it's merely difficult, remember this: with computer code it takes just one single genius somewhere figuring it out to enable every 2-bit script-kiddie with a mouse and an ego to use it. Once there's a working method it's just a matter of packaging it up into an easy-to-use kit.
The trick, however, is in figuring out the method. Now, if you've got ring 0 then by definition you've got more power on the system than root has. If you can't turn this into user-mode root then I have to be skeptical of your claim. It sounds like what you've got is a way to get ring 0, but address-space randomization's preventing you from exploiting this to actually execute your chosen code in ring 0 without doing random probes that tend to cause the system to crash before you actually find the right spot. Which is of course exactly what it's supposed to do. Or there's something else you're not mentioning. I've run into a few of those, the "I can get root on the system if I'm allowed to load a kernel module or device driver.", or the "It'd work if the kernel implements it like this, but it doesn't so the exploit doesn't actually work.".
A deadline's always feasible. It may not be possible to come up with a clean fix in a short timeframe, but you can always come up with either a workaround or something the users can do to mitigate the damage. This may not be ideal from the vendor's point of view, but it's not the vendor who's in danger of having their systems attacked so I'm not overly concerned about their public-relations heartburn.
There's also another ethical issue: keeping me (as an administrator of vulnerable systems) in the dark about the vulnerabiility puts my systems at risk and prevents me from protecting my systems. You are hurting me in a very direct way by not disclosing the problem to me. If I know the problem exists I can for instance shut down the vulnerable services (if they aren't necessary for my systems to operate), block access to those services at the firewall and/or replace the vulnerable software with equivalent software that isn't vulnerable. I can't do this unless I know the vulnerability exists. People who want me kept in the dark about the problem strike me as the type who at least don't care how much damage the rest of us suffer, and possibly have a vested interest in having vulnerable systems exist.
In most cases you warn the vendor first, providing complete details including exploit code so they have no excuse for not being able to duplicate the problem. If the vendor won't acknowledge your report within a reasonable time (say 7 days), will not commit to a timeline for having either a fix, a workaround or a mitigation strategy for users within a reasonable time (say 14 days from acknowledgement, with the deadline being 30-90 days out depending on severity) or fails to meet the deadline, then you disclose to users including full details, exploit code (so the problem can be independently verified without having to rely on your word that it exists) and a recommended mitigation strategy. Demanding payment for the report is never appropriate unless the vendor has publicly committed to a "bug bounty" and your demand is what they've publicly committed to.
There'd be occasional exceptions to the above. If for instance the vulnerability is theoretical and you can't create actual exploit code for it, demanding the vendor fix it is inappropriate (by the same token, though, it's far less of a problem to discuss the problem in public if it truly can't be feasibly exploited). The deadline should be more flexible for less severe vulnerabilities. If the vendor has a track record of responding inappropriately to reports (eg. by threatening legal action against the researcher), immediate anonymous disclosure may be a better approach.
We generated our first real radio signals sometime around 1894, give or take. That means that we are completely and utterly invisible in the radio spectrum to any civilizations more than about 116 light-years away from Sol. Our radio signals simply haven't had time to reach them yet. And the same thing applies in reverse: if an alien civilization began transmitting radio signals 200 years ago but they're more than 200 light-years away from us, we won't be able to see them because their signals haven't had time to reach us yet.
That defines the outer edge of the visibility shell. There's also an inner edge. As a civilization develops, it eventually stops transmitting radio signals as it first gets more efficient at transmitting radio (moving from pure broadcast to directed transmissions and then refining their ability to direct the transmission into tighter and tighter beams) and then starts using things other than radio. If you start listening after the last of their detectable broadcasts has passed you, again you can't see them.
So when you're asking "If there are as many civilizations out there as the equations predict, why can't we detect them?" you also have to take into account the fact you're likely only physically able to detect a fraction of the civilizations that may exist. The rest are either too far away for their signals to have reached you, or they've been around long enough that you weren't listening when the last of their detectable transmissions passed your planet.
To me it boils down to two things. First, is this really an optional service or is it something I have no choice but to have? Things like checked-luggage charges or reservation-change fees, I don't necessarily have to buy those services. I don't always change my reservations (in fact I usually don't), and I may be traveling with only my carry-on (in fact I prefer to do that when I'm flying if I have any choice in the matter). Other things like gate fees I'm going to have to pay every single time, no matter what. To me, if I can't decline to pay it and still be able to fly then it should by rights be included in the ticket price. To call it "unbundled" is simply deceptive, it implies something's optional when in fact it's not.
Second, for truly optional services, are the terms clearly disclosed? When I buy a ticket I should be able to clearly see how much my checked luggage will cost me, how much it'll cost me to change or cancel the reservation later, how much all those unbundled services will cost and what terms I'll have to comply with. The big problem I have with the airlines is that most of the time they don't clearly disclose any of that. Last time I bought airline tickets, it took half an hour of digging to answer a simple question: what would the baggage fees be for 1 checked suitcase per person? You couldn't find this when you bought the ticket, and it took major digging into the help section of the airline's web site to find the answer. And even then it wasn't a straight answer, just a list of conditions and prices that you had to compare to your ticket's terms to match up. When I buy a ticket I ought by rights to be able to just see a list, for that particular type of ticket and that flight, how much it'll be per bag for standard and oversize/overweight bags and what the maximum number is. I know this isn't hard to do, I program computers for a living and this kind of database query and calculation's something it takes me maybe 1-2 working days to do. Note: "does take", not "would take", like I said I do this stuff for a living and I get exactly that kind of task on a regular basis.