The Internet will remember you as long as the services that have information about you exist. The services... they'll remember you as long as their owners can make money off them one way or another. As soon as they can't make money (even if it's just milking venture capitalists for another round of financing), they'll shut the servers down and wipe the databases. A couple months after that, the search engine caches will have lost track of the pages and that'll be that. All that'll be left is what individuals have saved somewhere else, and that's disorganized enough that it probably won't turn up anywhere.
The issue for most people isn't whether the Internet remembers you, or for how long. It's that how long it remembers you is completely and utterly out of your control.
It's something anyone who grew up in a small town understands: when you do something stupid in public, everybody will know about it. In a big city, if you make a fool of yourself at a bar, you'll be the laughingstock of the patrons for a couple weeks until someone else comes along. You'll be the butt of jokes from your friends for a while. But the world at large will be pretty much oblivious. In a small town it's different. Everyone in town will know someone who was there, and what would've been a miniscule fraction of the big city will be 90% of the small town. But it'll still mostly be shrugged off, because again everyone in town's been there. Anyone who rags on you too badly will have their own foray into foolishness brought up and bandied about again, and they'll shut up and let it drop. And individually you learn early on what kinds of things will merely make you look foolish vs. what things will cause serious town-wide outrage, and you avoid doing the latter kind.
The Internet is more the small town than the big city. People assume that nobody will find out what they said or did in public, but the anonymity of the big city just isn't there. And the person in question is what makes a lot of these things such a big deal. We don't see a big flap over the thousands of stupid, racist, bigoted comments ordinary people make every day. In this case though, as with the "Duck Dynasty" case, it's not an ordinary person. It's someone who ought to know that their comments are being broadcast to a much larger audience, and who ought to know how those comments are going to be taken. And they go ahead and make them anyway. That's what makes these things go viral like they do.
A problem with business, that is, not a problem of business. All too often I see business requirements for software that specify how things must be done, rather than specifying what is to be done. The problem is that the business requirements are being written by businessmen who have no training or experience in writing software, so they no more know how things should be done when writing software than (according to those self-same businessmen) the software developers know how things should be done when running a business. The solution is always the same: let the business people lay out what they want done, and let the software developers figure out how to do it.
Sure. Now, look up how much of the US's goods come in via the ports in Los Angeles and the San Francisco Bay. After you're done with that, look up how much of what crops for the US's food supply are grown in California's central valley. California would hurt if it were kicked out of the US, but the US would be hurting a lot worse in short order. If you want to see how badly, look back to the last couple of west-coast port strikes. The last one was estimated to be costing the US $1 billion per day, and cut off 40% of the US's imports.
T-Mobile. They dropped subsidized contracts entirely. It's all month-to-month, at lower rates than before at that.
Now, you can finance a phone through them too. But it's handled as just that: you're financing your phone. The financing's separate from the service and broken out separately on your bill, the only connection being that if you cancel service you have to pay off the balance of the loan for your phone. You don't have to finance, you can pay for your new phone in full up-front or pop the new SIM in your current phone.
Pretty much. There's a lot of muggings and thefts (I believe the majority) done solely to grab the victim's cel phone. The thieves don't care about cash (not enough of it these days to be worth it) or credit cards (too easily traced), but ditch the SIM card and a modern smartphone's worth several hundred dollars in a package that fits conveniently in a pocket. They're also hard for the police to trace quickly: most people don't know their phone's IMEI, and by the time they go to the carrier and have the carrier report it the phone's probably in the hands of an unwitting phone-store customer who has no clue it was stolen.
The only way to stop this is to make it so that a stolen phone's useless and the fences and phone stores know it. Right now the phone stores don't worry too much about questionable merchandise because the cops can't prove the store knew it was stolen and the phones are still usable so they won't suffer any backlash from customers. Fences will take the phones because they know they can launder them and sell them. The kill switch changes the calculus: phone stores and other resellers know they're the ones who'll catch the flak when phones they sold start getting bricked because they were stolen, that'll make it too costly for them to take a chance on questionable merchandise. Fences won't take them if there's no market for the fence to sell them off to. And the muggers will quickly stop targeting stuff once their fences won't give them any money for it.
If the cable was damaged at the wall side but not the car side, my immediate thought is a problem in the wall socket or wiring. I've run into that with regular outlets, old hardware causes high resistance and a very hot outlet and plug (thermal conduction through the metal parts). The most common cause is age causing corrosion of the connection plates inside the socket or looseness of the plates so the prongs of the plug don't make good tight contact with them. Either way it raises the resistance of the connection inside the socket and creates a lot of heat (it's doing exactly what the heating elements on an electric stove do). My fix is to open up the outlet and replace the socket with a new one, cleaning up and tightening the wires in the process.
The #2 problem is the actual in-wall wiring being old and just not up to gauge for the current draw of modern electronics. In 1970 we didn't have home computers and Xboxes and the like, 14-gauge wiring was common and hooking up a modern home-entertainment center and computer would have the wiring in the wall hot to the touch. Plug a Tesla into older wiring like that and you've got a fire waiting to happen.
One thing though: your direct financial liability is $0, but that doesn't help much when you need to use your card and a crook's run it over-limit with a fraudulent charge. Take a real example from my life: I'm a full day's drive from home, I had to have several hundred dollars of repairs done to the coolant system on my car, if I can't pay for them the dealership won't release my car to me so I can get home and since it's at the tail end of the trip I don't have nearly that much in emergency cash in my wallet. I may not be liable for the fraudulent charge, but the credit-card company isn't going to front me money for hotel or food or lost time at work since I won't be making it back on time or any of the other costs I'll incur because of the fraud. If it's a debit card and the money came out of your checking account it can be even worse: bounced rent checks, bounced utility-bill payments, the hassles of clearing all that up and it's going to have consequences regardless (the landlord doesn't have to care why the check bounced, just that it bounced).
And that even when people do figure out how to crack the DRM that it will slow people down enough that impatience with the cracking process will cause them to give up an buy.
Here's the rub though: in many cases the DRM also slows people down enough that their impatience with the DRM process causes them to give up and pirate. Take DVDs. Side-effects of the DRM there include the inability to skip through the trailers and advertisements and logos that come between putting the disc in and actually starting to play the movie. One of the most popular reasons to rip a DVD or use an illegal player program is frankly to be able to hit Play and have the actual movie start to play instead of sitting through 10 minutes of the same cruft you've already seen a dozen times. It can also include incompatibility with antivirus programs or other forms of DRM, incompatibility with network problems (if connectivity isn't there the DRM can't contact it's servers to validate things and will refuse to decode the content), incompatibility with other DRM systems (their attempts to validate that nothing is trying to bypass the DRM at the system level get into an argument about who controls the system), having to install a custom player which constantly tries to push it's own browser toolbars and other crud on you, and so on. People get tired of fighting all that all the time, and they notice that the people who pirate stuff don't have to deal with those problems. Notice that none of the above requires that the person want to get the content for free, nor want to do anything illegal with it.
I might have some sympathy for the CEO's position, save for the fact that GM and it's management argued that as majority shareholder the US Government should not actively vote and control GM's business as anyone else with an ownership stake normally would. One of the things that goes along with taking the risk of an ownership stake is the ability to control the business, meaning that your share of the risks are essentially in your own hands. GM's management however wanted the government to shoulder all of the risks of ownership with none of the control. So to that degree GM, not the government, should be shouldering the risk of loss due to GM's business decisions.
That isn't what caused the decline, which began in the exact year the Napster came along.
And then you say:
Similarly with music: nobody really wants those flat pieces of plastic called CDs, they want their music on the computer or media player.
Perhaps your two statements aren't entirely unconnected, and the decline wasn't merely because Napster existed but because buyers, as you say, didn't want those flat pieces of plastic which were the only things the music publishers were willing to sell and did want the digital media files which were only available through Napster. Your own words go straight back to my argument: the problem the music industry has is that they refused to sell what their customers wanted and so their customers took their business elsewhere. And now that customers are used to going somewhere else for their music, the publishers are having a hard time winning them back. And antics like Disney's don't make it any easier for them, likewise attempts to sue individuals for millions of dollars for listening to music in a format the publishers didn't want to sell.
It's happening in another aspect of the music business as well: albums vs. single tracks. The industry's made it's living all these years selling albums where people only really want one or two tracks out of a dozen or more. They're tried and tried to keep selling albums even though customers keep clamoring for single tracks. iTunes and Amazon forced the issue, and now single-track sales are climbing while album sales continue to decline. Another case of the industry's woes being caused not by their customers or by pirates so much as by the industry's own refusal to sell the product their customers want to buy.
The thing is, it's been just as much of a problem since, well, just about forever. Think back to how they railed against DVD burners, CD burners, the VCR, hell even cassette tapes. And yet the industry survived all of them by releasing content. You want to know what's killing the industry? Go read this article. Now, how enthusiastic do you think your average person's going to be about buying content when they've just been reminded that the companies "selling" it to them will jerk it away the moment it suits them? I sure wouldn't put my hard-earned money into that, at least not at the prices they want to charge. Charge me the kind of price the video rental place would charge and I'll think about it.
The music and movie industries are in decline simply because they won't provide content their customers want in the form their customers want it. And of course that results in them going out of business. You don't want to sell what people want to buy, don't be surprised when people take their business elsewhere. It doesn't take an MBA to figure that one out.
" They argue that if the new ones really are so good, people will buy them on their own without being forced to do so."
The problem with this argument is that incandescents start out cheap, so the majority of people who're cash-strapped buy them because they can afford them. Without sales volume prices won't go down, and without prices going down the bottom 75% can't afford to buy them so the sales volume never goes up. It's the paradox: in the long run it's better to buy the $100 pair of boots that'll last you a decade, but if you only have $20 in your pocket you can't afford to buy that pair and have to settle for the $20 pair that you'll need to replace in a year. The only way out is to either get a windfall so you can afford to get the $100 pair that'll save you money in the long run, or for something to kick demand for the $100 pairs up enough that prices come down to what you can afford. And remember that most power companies have been offering assistance replacing incandescent bulbs with CFLs for a while now.
I started swapping out incandescents for CFLs about 7 years ago. I'd buy a couple and replace bulbs that were working, leaving the old bulbs on the shelf if I needed spares before I got more CFLs. With the CFLs lasting longer I don't need to buy replacements nearly as often, so the money I save can go to other things. I'll probably soon start the same process with LED bulbs, that way I can spread the cost out.
The problem the NSA's having is likely the same one most large businesses have when it comes to IT: the management involved has absolutely no clue about what's going on with their computer systems, and they won't believe what the technical people who do know what's going on are telling them because it disagrees with what that management thinks should be going on. End result, the steps that are taken don't fix any of the security problems and the steps that would fix the problems are vetoed. And it'll be "lather, rinse, repeat" until management starts being fired (not allowed to resign, fired for incompetence) and losing their cushy termination benefits packages because they failed to listen.
Unfortunately for the investor, the NSA would have ordered IBM not to reveal that information. IBM's obligations to investors don't trump it's obligation to obey the law, even when the law is wrong-headed. And good luck suing the NSA.
From where I sit there's no question: for compliance reasons we must be able to detail exactly what is being changed when we install updates to software. If we can't, then we have to re-certify the software from scratch before it can be deployed which is a fairly tedious and time-consuming process. Having to do that with any regularity will find us looking for alternatives.
As for a list of bug-fixes making your software look bad, remember this: I know exactly how long our unresolved-issues list is for every single bit of commercial software we use, and exactly how long some of those issues have been sitting there. That your software has bugs that needed fixed too isn't going to come as any great surprise to me. What will impress me is a) actually fixing problems, and b) being clear about what you're fixing or changing which minimizes the amount of work I get saddled with.
Numbers. Specifically, the number of employees who don't have any say in how GM is run, didn't have any say in the decisions that led to it cratering, but who'd end up without jobs, on unemployment and dependent on welfare and food stamps and the like to survive, if GM went out of business. With the state of the economy as it is, the country can't afford that, and so the government acted to prevent it. They can't do that for everyone, though, so when choosing who to bail out and who to let go the impact of that choice on the rest of the country comes into play. GM's workforce suddenly becoming unemployed could very well be enough to send the country into the next Great Depression, the neighborhood bookstore closing probably won't.
Those above are just form fields by another name. And the game engine, the application, is doing a lot more than just calculating those stats.
Also, an awful lot of what's being calculated does in fact depend on things like position relative to the mob. How hard a mob's attacks hit, for instance, often depends on how far away the player is. How effective the player's attacks are depends on whether they're in front of the mob, off to one side or behind it. Which means in practice you can't avoid that kind of frame-by-frame recalculation using the RP model. Conventional models avoid it by only updating the base numbers frame-by-frame, then doing the full calculations based on the current situation only when needed. Eg. you update the player's position relative to the mob frame-by-frame, but only calculate how effective his attacks are when he actually attacks (with game clients running at 30+ FPS and player attacks happening once every 1-3 seconds, you avoid 30-90x the calculations).
Except that then you remove the basic principle of RP: that updates are done live. Freeze things like that and you've reduced it to the current model where you just dump values into variables and then run calculations on them to set the values of other variables which then don't change until you go and recalculate them yourself.
This won't create an application. It just automates calculations that populate form fields. That's the easy part of most applications. The hard parts are the business logic that isn't just figuring out the values for form fields. In addition, you have nasty cascade effects. What happens in this system when the price for an item changes at the same time the customer's changing the number of that item they want to order, the customer's credit limit is being updated and payments are being applied to his 26 orders each of which causes an update to his balance due? You end up with a massive cascade of updates propagating up the chain, with each change causing changes to values that depend on it which in turn cause yet more changes. Multiply that by thousands of customers and it can kill the systems dead. Meanwhile a non-RP system will handle it cleanly and without dying by simply not updating values until everything's finalized. So as the accounts payable system applies payments to his 26 invoices his balance doesn't change, then when payments are done it updates the balance once to reflect the payments.
I'd use RP to help with things like forms where I want live updates and RP will help automate what I need done anyway. Lots of other areas... not so much. It'd be just another tool in the toolbox, and it's not quite as useful in the real world as it appears in simple academic examples.
Part of it's that the people describing these things often haven't dealt with truly large, complex applications before. Simple example: we have 5 fields in a request, each data file has a match value for each of those fields, and we want to grab the file that matches any one of the fields in the current request. "The" file? Um, what happens when I have 3 files each of which matches a different field of the request? Which one should be grabbed? Nobody thought of that. They say "It doesn't matter, just grab one.". And then later "We wanted file 17 that matched field 3 being X, why aren't we getting that file?", answer "Because file 9 matches when field 1 is A, which it is in your request, and we find file 9 first when checking.". Simple request, just grab an arbitrary file. Translated into the real world, complications pile up that were always there but nobody wanted to talk about because they were... well, complicated.
I've found that same problem before: recruiters look at the place where you currently live, not where you've said you're interested in working. So if I say I live in Los Angeles and am interested in jobs in Seattle, I'd expect to get lots of calls for... Los Angeles. When I switch and use the address of a friend in the area I want jobs in as where I live, suddenly I get calls for the right area. I don't see any way around this as long as the recruiters are ignoring the information in the profile this way.
I think the judge's position is that, regardless of the first case, at this point DHS knows she's supposed to be allowed to come and testify. If they continue to keep her on the list and keep her off the plane, there's no question that it's deliberate obstruction of justice and there's no argument DHS can legitimately make that he can't drop the hammer on them for it. The DHS lawyers know it too.
As for the whole question of the document not being officially "evidence", that's just procedural. She gets on the stand or submits an affidavit testifying that yes that exhibit is in fact the same letter the airline handed her. Her lawyer introduces an affidavit from the airline saying that yes the letter they gave her was in fact the same letter they were given by so-and-so from DHS, and is consistent with other no-fly orders they've received from DHS and they have no reason to believe it's not authentic. If DHS has kept their noses clean since then the judge notes that the witness is on the stand and able to testify, so no harm no foul. If they haven't... the judge can do many things, from merely drawing the inferences most unfavorable to the DHS from the testimony up to referring the DHS officials involved for prosecution for obstruction of justice and witness tampering (and even the DOJ is going to take it seriously when it's a Federal judge referring the matter). DHS doesn't want this to happen, so they're going to make sure it doesn't have to.
That's the problem: for residential ISPs #3 is a huge cost. Since they forbid users from running servers, almost all traffic is from the rest of the world (where the servers are) to their users. That means a big imbalance of traffic at their connections to the backbones, more traffic inbound to the ISP than outbound from it. Since payment and rates are based on balance of traffic, the ISPs end up paying a lot. The ISPs aren't in a good negotiating position. Individually they're each an overwhelming chunk of the backbone provider's revenue, the backbone can afford to lose a residential ISP and not take a killer hit. The ISP, though, needs the backbone connection because in the end that's what all of their customers are paying for. If as a Comcast Internet subscriber you can't browse the Web, can't play your on-line games, can't stream video from Netflix, then what use is that Comcast Internet service to you? You'd just cancel it and save yourself the money. And the alternative, allowing users to run servers to even out the traffic balance, can't be done. The ISPs have oversubscribed their networks and otherwise taken advantage of traffic asymmetry to cut costs, and their networks now can't handle heavy upstream traffic loads.
The ISPs could, of course, adjust their prices to reflect the actual cost of connections. They don't want to do that, though, because the first one to do that would lose all their customers to the rest. Plus in many cases those ISPs enjoy a local monopoly or duopoly thanks to public-right-of-way access agreements, and if they start raising prices their customers are going to push local and state governments to either regulate the ISPs or void those agreements and remove the monopoly/duopoly. The desire to keep that's at the heart of ISP opposition to municipal Internet service, you can see how much they want to keep it. They could absorb the costs, but that cuts into their profit margins and they don't want that either. So they're kind of stuck. The only thing they can do is try and wring money out of parties that don't have any direct connection to them who can't really do anything to them.
They do. The problem is, what recourse do they have if the other party fails to meet the SLA? Sure, they can sue and maybe get money. That'll take years and cost more than they could recover. And meanwhile the systems still don't work, the sites are still down and things are still at a stand-still. And the other party knows that, after all you hired them because you either couldn't do the work yourself or didn't want to and either way you don't have the people on staff to handle the job.
That's the problem in a nutshell: contracts, no matter how iron-clad, don't complete the work themselves. You need to aggressively manage progress, make sure the contractors are actually getting the work done, and take steps early if progress isn't being made. You also have to understand the biggest risk factor: in a complex system there may not be any visible progress until the last half of the project. The back end may have nothing humans can see and building tools to let humans see what it's doing may well take almost as long as building the actual front-end will, and the front-end won't be usable until enough of the back end's built to actually do useful work. That means depending on report on what the developers are reporting as far as progress goes, and you have to be aware of the Plan Effect and have some way of double-checking what you're being told with what the developers are really reporting to make sure nobody's glossing over problems. While all this is going on, you need to make sure that you a) have a plan B in case the project isn't making sufficient progress and b) you leave enough time to actually implement plan B if you need it. That means being pessimistic about schedules, which often means telling the executives "No, we can't shave 6 months off the schedule." even if technically you could if everything goes right, because you're allowing time to recover when things don't go right. Management and the executives have to live by the experienced software developer's creed: "We don't so much believe in Murphy as we keep tripping over the little blighter every time we go get coffee.". All this, of course, is far easier said than done because the executives and upper management are rarely on the hook personally for getting things done, so they never personally feel the pain of cutting corners and failing to be sufficiently cynical and pessimistic about the schedule.
One major difference between the registry and Unix config file folders: the folders aren't integrated into a single blob, the registry is (well, technically a couple of blobs corresponding to the top-level keys). Bluntly put, the files are more robust than the registry's proven to be. Less prone to corruption, less prone to damage, easier to back up and restore or transfer between machines. I can tar up my home directory on one Unix machine, untar it on another (even one running a different Unix) and everything's as I expect it modulo the expected things like differences in system-installed applications and monitor sizes. And since the config files are plain text (usually), it's trivial to go in and fix problems or make changes. Doing that with the registry... requires either that the registry be intact enough to get you into Windows and regedit, or requires lots of special tools to work on it off-line. Assuming you know where the registry hives are located physically, many people have no clue.
As far as SATA or USB drives, you're talking two different things. One is a system-level interaction, loading device drivers and connecting the physical device into the system. That's properly a system-level thing, until that's done the device doesn't exist as far as software is concerned. The second part is where Windows and Linux diverge. Windows puts a lot of the stuff to watch for devices at the system level. For instance, the Samsung software for my phone, iTunes, the Citrix ICA client, all of that is system level and none of that is system-wide. Linux... doesn't give software a choice. If it's an ordinary user installing the software, the installer doesn't get permission to put stuff at the system level, period full stop. Only sysadmins get to do that, and regular users aren't sysadmins. The only way to do it requires a manual step: entering the root password to give the installer root privileges to install things at the system level. And Linux users are taught early to be allergic to those requests. It's OK if you go in intending to install something system-wide, but when you go to install a personal music player and it asks for root the instinctive response is to hit "Cancel" and go looking for confirmation that what you downloaded is really legit because legit stuff Doesn't Do That. On Windows it's unusual to see an installer that even gives you the option of choosing per-user vs. system-wide.
Slashdot Mirror
The Internet will remember you as long as the services that have information about you exist. The services... they'll remember you as long as their owners can make money off them one way or another. As soon as they can't make money (even if it's just milking venture capitalists for another round of financing), they'll shut the servers down and wipe the databases. A couple months after that, the search engine caches will have lost track of the pages and that'll be that. All that'll be left is what individuals have saved somewhere else, and that's disorganized enough that it probably won't turn up anywhere.
The issue for most people isn't whether the Internet remembers you, or for how long. It's that how long it remembers you is completely and utterly out of your control.
It's something anyone who grew up in a small town understands: when you do something stupid in public, everybody will know about it. In a big city, if you make a fool of yourself at a bar, you'll be the laughingstock of the patrons for a couple weeks until someone else comes along. You'll be the butt of jokes from your friends for a while. But the world at large will be pretty much oblivious. In a small town it's different. Everyone in town will know someone who was there, and what would've been a miniscule fraction of the big city will be 90% of the small town. But it'll still mostly be shrugged off, because again everyone in town's been there. Anyone who rags on you too badly will have their own foray into foolishness brought up and bandied about again, and they'll shut up and let it drop. And individually you learn early on what kinds of things will merely make you look foolish vs. what things will cause serious town-wide outrage, and you avoid doing the latter kind.
The Internet is more the small town than the big city. People assume that nobody will find out what they said or did in public, but the anonymity of the big city just isn't there. And the person in question is what makes a lot of these things such a big deal. We don't see a big flap over the thousands of stupid, racist, bigoted comments ordinary people make every day. In this case though, as with the "Duck Dynasty" case, it's not an ordinary person. It's someone who ought to know that their comments are being broadcast to a much larger audience, and who ought to know how those comments are going to be taken. And they go ahead and make them anyway. That's what makes these things go viral like they do.
A problem with business, that is, not a problem of business. All too often I see business requirements for software that specify how things must be done, rather than specifying what is to be done. The problem is that the business requirements are being written by businessmen who have no training or experience in writing software, so they no more know how things should be done when writing software than (according to those self-same businessmen) the software developers know how things should be done when running a business. The solution is always the same: let the business people lay out what they want done, and let the software developers figure out how to do it.
Sure. Now, look up how much of the US's goods come in via the ports in Los Angeles and the San Francisco Bay. After you're done with that, look up how much of what crops for the US's food supply are grown in California's central valley. California would hurt if it were kicked out of the US, but the US would be hurting a lot worse in short order. If you want to see how badly, look back to the last couple of west-coast port strikes. The last one was estimated to be costing the US $1 billion per day, and cut off 40% of the US's imports.
T-Mobile. They dropped subsidized contracts entirely. It's all month-to-month, at lower rates than before at that.
Now, you can finance a phone through them too. But it's handled as just that: you're financing your phone. The financing's separate from the service and broken out separately on your bill, the only connection being that if you cancel service you have to pay off the balance of the loan for your phone. You don't have to finance, you can pay for your new phone in full up-front or pop the new SIM in your current phone.
Pretty much. There's a lot of muggings and thefts (I believe the majority) done solely to grab the victim's cel phone. The thieves don't care about cash (not enough of it these days to be worth it) or credit cards (too easily traced), but ditch the SIM card and a modern smartphone's worth several hundred dollars in a package that fits conveniently in a pocket. They're also hard for the police to trace quickly: most people don't know their phone's IMEI, and by the time they go to the carrier and have the carrier report it the phone's probably in the hands of an unwitting phone-store customer who has no clue it was stolen.
The only way to stop this is to make it so that a stolen phone's useless and the fences and phone stores know it. Right now the phone stores don't worry too much about questionable merchandise because the cops can't prove the store knew it was stolen and the phones are still usable so they won't suffer any backlash from customers. Fences will take the phones because they know they can launder them and sell them. The kill switch changes the calculus: phone stores and other resellers know they're the ones who'll catch the flak when phones they sold start getting bricked because they were stolen, that'll make it too costly for them to take a chance on questionable merchandise. Fences won't take them if there's no market for the fence to sell them off to. And the muggers will quickly stop targeting stuff once their fences won't give them any money for it.
If the cable was damaged at the wall side but not the car side, my immediate thought is a problem in the wall socket or wiring. I've run into that with regular outlets, old hardware causes high resistance and a very hot outlet and plug (thermal conduction through the metal parts). The most common cause is age causing corrosion of the connection plates inside the socket or looseness of the plates so the prongs of the plug don't make good tight contact with them. Either way it raises the resistance of the connection inside the socket and creates a lot of heat (it's doing exactly what the heating elements on an electric stove do). My fix is to open up the outlet and replace the socket with a new one, cleaning up and tightening the wires in the process.
The #2 problem is the actual in-wall wiring being old and just not up to gauge for the current draw of modern electronics. In 1970 we didn't have home computers and Xboxes and the like, 14-gauge wiring was common and hooking up a modern home-entertainment center and computer would have the wiring in the wall hot to the touch. Plug a Tesla into older wiring like that and you've got a fire waiting to happen.
One thing though: your direct financial liability is $0, but that doesn't help much when you need to use your card and a crook's run it over-limit with a fraudulent charge. Take a real example from my life: I'm a full day's drive from home, I had to have several hundred dollars of repairs done to the coolant system on my car, if I can't pay for them the dealership won't release my car to me so I can get home and since it's at the tail end of the trip I don't have nearly that much in emergency cash in my wallet. I may not be liable for the fraudulent charge, but the credit-card company isn't going to front me money for hotel or food or lost time at work since I won't be making it back on time or any of the other costs I'll incur because of the fraud. If it's a debit card and the money came out of your checking account it can be even worse: bounced rent checks, bounced utility-bill payments, the hassles of clearing all that up and it's going to have consequences regardless (the landlord doesn't have to care why the check bounced, just that it bounced).
And that even when people do figure out how to crack the DRM that it will slow people down enough that impatience with the cracking process will cause them to give up an buy.
Here's the rub though: in many cases the DRM also slows people down enough that their impatience with the DRM process causes them to give up and pirate. Take DVDs. Side-effects of the DRM there include the inability to skip through the trailers and advertisements and logos that come between putting the disc in and actually starting to play the movie. One of the most popular reasons to rip a DVD or use an illegal player program is frankly to be able to hit Play and have the actual movie start to play instead of sitting through 10 minutes of the same cruft you've already seen a dozen times. It can also include incompatibility with antivirus programs or other forms of DRM, incompatibility with network problems (if connectivity isn't there the DRM can't contact it's servers to validate things and will refuse to decode the content), incompatibility with other DRM systems (their attempts to validate that nothing is trying to bypass the DRM at the system level get into an argument about who controls the system), having to install a custom player which constantly tries to push it's own browser toolbars and other crud on you, and so on. People get tired of fighting all that all the time, and they notice that the people who pirate stuff don't have to deal with those problems. Notice that none of the above requires that the person want to get the content for free, nor want to do anything illegal with it.
I might have some sympathy for the CEO's position, save for the fact that GM and it's management argued that as majority shareholder the US Government should not actively vote and control GM's business as anyone else with an ownership stake normally would. One of the things that goes along with taking the risk of an ownership stake is the ability to control the business, meaning that your share of the risks are essentially in your own hands. GM's management however wanted the government to shoulder all of the risks of ownership with none of the control. So to that degree GM, not the government, should be shouldering the risk of loss due to GM's business decisions.
First you say:
And then you say:
Perhaps your two statements aren't entirely unconnected, and the decline wasn't merely because Napster existed but because buyers, as you say, didn't want those flat pieces of plastic which were the only things the music publishers were willing to sell and did want the digital media files which were only available through Napster. Your own words go straight back to my argument: the problem the music industry has is that they refused to sell what their customers wanted and so their customers took their business elsewhere. And now that customers are used to going somewhere else for their music, the publishers are having a hard time winning them back. And antics like Disney's don't make it any easier for them, likewise attempts to sue individuals for millions of dollars for listening to music in a format the publishers didn't want to sell.
It's happening in another aspect of the music business as well: albums vs. single tracks. The industry's made it's living all these years selling albums where people only really want one or two tracks out of a dozen or more. They're tried and tried to keep selling albums even though customers keep clamoring for single tracks. iTunes and Amazon forced the issue, and now single-track sales are climbing while album sales continue to decline. Another case of the industry's woes being caused not by their customers or by pirates so much as by the industry's own refusal to sell the product their customers want to buy.
The thing is, it's been just as much of a problem since, well, just about forever. Think back to how they railed against DVD burners, CD burners, the VCR, hell even cassette tapes. And yet the industry survived all of them by releasing content. You want to know what's killing the industry? Go read this article. Now, how enthusiastic do you think your average person's going to be about buying content when they've just been reminded that the companies "selling" it to them will jerk it away the moment it suits them? I sure wouldn't put my hard-earned money into that, at least not at the prices they want to charge. Charge me the kind of price the video rental place would charge and I'll think about it.
The music and movie industries are in decline simply because they won't provide content their customers want in the form their customers want it. And of course that results in them going out of business. You don't want to sell what people want to buy, don't be surprised when people take their business elsewhere. It doesn't take an MBA to figure that one out.
" They argue that if the new ones really are so good, people will buy them on their own without being forced to do so."
The problem with this argument is that incandescents start out cheap, so the majority of people who're cash-strapped buy them because they can afford them. Without sales volume prices won't go down, and without prices going down the bottom 75% can't afford to buy them so the sales volume never goes up. It's the paradox: in the long run it's better to buy the $100 pair of boots that'll last you a decade, but if you only have $20 in your pocket you can't afford to buy that pair and have to settle for the $20 pair that you'll need to replace in a year. The only way out is to either get a windfall so you can afford to get the $100 pair that'll save you money in the long run, or for something to kick demand for the $100 pairs up enough that prices come down to what you can afford. And remember that most power companies have been offering assistance replacing incandescent bulbs with CFLs for a while now.
I started swapping out incandescents for CFLs about 7 years ago. I'd buy a couple and replace bulbs that were working, leaving the old bulbs on the shelf if I needed spares before I got more CFLs. With the CFLs lasting longer I don't need to buy replacements nearly as often, so the money I save can go to other things. I'll probably soon start the same process with LED bulbs, that way I can spread the cost out.
The problem the NSA's having is likely the same one most large businesses have when it comes to IT: the management involved has absolutely no clue about what's going on with their computer systems, and they won't believe what the technical people who do know what's going on are telling them because it disagrees with what that management thinks should be going on. End result, the steps that are taken don't fix any of the security problems and the steps that would fix the problems are vetoed. And it'll be "lather, rinse, repeat" until management starts being fired (not allowed to resign, fired for incompetence) and losing their cushy termination benefits packages because they failed to listen.
Unfortunately for the investor, the NSA would have ordered IBM not to reveal that information. IBM's obligations to investors don't trump it's obligation to obey the law, even when the law is wrong-headed. And good luck suing the NSA.
From where I sit there's no question: for compliance reasons we must be able to detail exactly what is being changed when we install updates to software. If we can't, then we have to re-certify the software from scratch before it can be deployed which is a fairly tedious and time-consuming process. Having to do that with any regularity will find us looking for alternatives.
As for a list of bug-fixes making your software look bad, remember this: I know exactly how long our unresolved-issues list is for every single bit of commercial software we use, and exactly how long some of those issues have been sitting there. That your software has bugs that needed fixed too isn't going to come as any great surprise to me. What will impress me is a) actually fixing problems, and b) being clear about what you're fixing or changing which minimizes the amount of work I get saddled with.
Numbers. Specifically, the number of employees who don't have any say in how GM is run, didn't have any say in the decisions that led to it cratering, but who'd end up without jobs, on unemployment and dependent on welfare and food stamps and the like to survive, if GM went out of business. With the state of the economy as it is, the country can't afford that, and so the government acted to prevent it. They can't do that for everyone, though, so when choosing who to bail out and who to let go the impact of that choice on the rest of the country comes into play. GM's workforce suddenly becoming unemployed could very well be enough to send the country into the next Great Depression, the neighborhood bookstore closing probably won't.
Those above are just form fields by another name. And the game engine, the application, is doing a lot more than just calculating those stats.
Also, an awful lot of what's being calculated does in fact depend on things like position relative to the mob. How hard a mob's attacks hit, for instance, often depends on how far away the player is. How effective the player's attacks are depends on whether they're in front of the mob, off to one side or behind it. Which means in practice you can't avoid that kind of frame-by-frame recalculation using the RP model. Conventional models avoid it by only updating the base numbers frame-by-frame, then doing the full calculations based on the current situation only when needed. Eg. you update the player's position relative to the mob frame-by-frame, but only calculate how effective his attacks are when he actually attacks (with game clients running at 30+ FPS and player attacks happening once every 1-3 seconds, you avoid 30-90x the calculations).
Except that then you remove the basic principle of RP: that updates are done live. Freeze things like that and you've reduced it to the current model where you just dump values into variables and then run calculations on them to set the values of other variables which then don't change until you go and recalculate them yourself.
This won't create an application. It just automates calculations that populate form fields. That's the easy part of most applications. The hard parts are the business logic that isn't just figuring out the values for form fields. In addition, you have nasty cascade effects. What happens in this system when the price for an item changes at the same time the customer's changing the number of that item they want to order, the customer's credit limit is being updated and payments are being applied to his 26 orders each of which causes an update to his balance due? You end up with a massive cascade of updates propagating up the chain, with each change causing changes to values that depend on it which in turn cause yet more changes. Multiply that by thousands of customers and it can kill the systems dead. Meanwhile a non-RP system will handle it cleanly and without dying by simply not updating values until everything's finalized. So as the accounts payable system applies payments to his 26 invoices his balance doesn't change, then when payments are done it updates the balance once to reflect the payments.
I'd use RP to help with things like forms where I want live updates and RP will help automate what I need done anyway. Lots of other areas... not so much. It'd be just another tool in the toolbox, and it's not quite as useful in the real world as it appears in simple academic examples.
Part of it's that the people describing these things often haven't dealt with truly large, complex applications before. Simple example: we have 5 fields in a request, each data file has a match value for each of those fields, and we want to grab the file that matches any one of the fields in the current request. "The" file? Um, what happens when I have 3 files each of which matches a different field of the request? Which one should be grabbed? Nobody thought of that. They say "It doesn't matter, just grab one.". And then later "We wanted file 17 that matched field 3 being X, why aren't we getting that file?", answer "Because file 9 matches when field 1 is A, which it is in your request, and we find file 9 first when checking.". Simple request, just grab an arbitrary file. Translated into the real world, complications pile up that were always there but nobody wanted to talk about because they were... well, complicated.
I've found that same problem before: recruiters look at the place where you currently live, not where you've said you're interested in working. So if I say I live in Los Angeles and am interested in jobs in Seattle, I'd expect to get lots of calls for... Los Angeles. When I switch and use the address of a friend in the area I want jobs in as where I live, suddenly I get calls for the right area. I don't see any way around this as long as the recruiters are ignoring the information in the profile this way.
I think the judge's position is that, regardless of the first case, at this point DHS knows she's supposed to be allowed to come and testify. If they continue to keep her on the list and keep her off the plane, there's no question that it's deliberate obstruction of justice and there's no argument DHS can legitimately make that he can't drop the hammer on them for it. The DHS lawyers know it too.
As for the whole question of the document not being officially "evidence", that's just procedural. She gets on the stand or submits an affidavit testifying that yes that exhibit is in fact the same letter the airline handed her. Her lawyer introduces an affidavit from the airline saying that yes the letter they gave her was in fact the same letter they were given by so-and-so from DHS, and is consistent with other no-fly orders they've received from DHS and they have no reason to believe it's not authentic. If DHS has kept their noses clean since then the judge notes that the witness is on the stand and able to testify, so no harm no foul. If they haven't... the judge can do many things, from merely drawing the inferences most unfavorable to the DHS from the testimony up to referring the DHS officials involved for prosecution for obstruction of justice and witness tampering (and even the DOJ is going to take it seriously when it's a Federal judge referring the matter). DHS doesn't want this to happen, so they're going to make sure it doesn't have to.
That's the problem: for residential ISPs #3 is a huge cost. Since they forbid users from running servers, almost all traffic is from the rest of the world (where the servers are) to their users. That means a big imbalance of traffic at their connections to the backbones, more traffic inbound to the ISP than outbound from it. Since payment and rates are based on balance of traffic, the ISPs end up paying a lot. The ISPs aren't in a good negotiating position. Individually they're each an overwhelming chunk of the backbone provider's revenue, the backbone can afford to lose a residential ISP and not take a killer hit. The ISP, though, needs the backbone connection because in the end that's what all of their customers are paying for. If as a Comcast Internet subscriber you can't browse the Web, can't play your on-line games, can't stream video from Netflix, then what use is that Comcast Internet service to you? You'd just cancel it and save yourself the money. And the alternative, allowing users to run servers to even out the traffic balance, can't be done. The ISPs have oversubscribed their networks and otherwise taken advantage of traffic asymmetry to cut costs, and their networks now can't handle heavy upstream traffic loads.
The ISPs could, of course, adjust their prices to reflect the actual cost of connections. They don't want to do that, though, because the first one to do that would lose all their customers to the rest. Plus in many cases those ISPs enjoy a local monopoly or duopoly thanks to public-right-of-way access agreements, and if they start raising prices their customers are going to push local and state governments to either regulate the ISPs or void those agreements and remove the monopoly/duopoly. The desire to keep that's at the heart of ISP opposition to municipal Internet service, you can see how much they want to keep it. They could absorb the costs, but that cuts into their profit margins and they don't want that either. So they're kind of stuck. The only thing they can do is try and wring money out of parties that don't have any direct connection to them who can't really do anything to them.
They do. The problem is, what recourse do they have if the other party fails to meet the SLA? Sure, they can sue and maybe get money. That'll take years and cost more than they could recover. And meanwhile the systems still don't work, the sites are still down and things are still at a stand-still. And the other party knows that, after all you hired them because you either couldn't do the work yourself or didn't want to and either way you don't have the people on staff to handle the job.
That's the problem in a nutshell: contracts, no matter how iron-clad, don't complete the work themselves. You need to aggressively manage progress, make sure the contractors are actually getting the work done, and take steps early if progress isn't being made. You also have to understand the biggest risk factor: in a complex system there may not be any visible progress until the last half of the project. The back end may have nothing humans can see and building tools to let humans see what it's doing may well take almost as long as building the actual front-end will, and the front-end won't be usable until enough of the back end's built to actually do useful work. That means depending on report on what the developers are reporting as far as progress goes, and you have to be aware of the Plan Effect and have some way of double-checking what you're being told with what the developers are really reporting to make sure nobody's glossing over problems. While all this is going on, you need to make sure that you a) have a plan B in case the project isn't making sufficient progress and b) you leave enough time to actually implement plan B if you need it. That means being pessimistic about schedules, which often means telling the executives "No, we can't shave 6 months off the schedule." even if technically you could if everything goes right, because you're allowing time to recover when things don't go right. Management and the executives have to live by the experienced software developer's creed: "We don't so much believe in Murphy as we keep tripping over the little blighter every time we go get coffee.". All this, of course, is far easier said than done because the executives and upper management are rarely on the hook personally for getting things done, so they never personally feel the pain of cutting corners and failing to be sufficiently cynical and pessimistic about the schedule.
One major difference between the registry and Unix config file folders: the folders aren't integrated into a single blob, the registry is (well, technically a couple of blobs corresponding to the top-level keys). Bluntly put, the files are more robust than the registry's proven to be. Less prone to corruption, less prone to damage, easier to back up and restore or transfer between machines. I can tar up my home directory on one Unix machine, untar it on another (even one running a different Unix) and everything's as I expect it modulo the expected things like differences in system-installed applications and monitor sizes. And since the config files are plain text (usually), it's trivial to go in and fix problems or make changes. Doing that with the registry... requires either that the registry be intact enough to get you into Windows and regedit, or requires lots of special tools to work on it off-line. Assuming you know where the registry hives are located physically, many people have no clue.
As far as SATA or USB drives, you're talking two different things. One is a system-level interaction, loading device drivers and connecting the physical device into the system. That's properly a system-level thing, until that's done the device doesn't exist as far as software is concerned. The second part is where Windows and Linux diverge. Windows puts a lot of the stuff to watch for devices at the system level. For instance, the Samsung software for my phone, iTunes, the Citrix ICA client, all of that is system level and none of that is system-wide. Linux... doesn't give software a choice. If it's an ordinary user installing the software, the installer doesn't get permission to put stuff at the system level, period full stop. Only sysadmins get to do that, and regular users aren't sysadmins. The only way to do it requires a manual step: entering the root password to give the installer root privileges to install things at the system level. And Linux users are taught early to be allergic to those requests. It's OK if you go in intending to install something system-wide, but when you go to install a personal music player and it asks for root the instinctive response is to hit "Cancel" and go looking for confirmation that what you downloaded is really legit because legit stuff Doesn't Do That. On Windows it's unusual to see an installer that even gives you the option of choosing per-user vs. system-wide.