One thing I notice is that IBM's patent threat isn't an opening move by IBM. TurboHercules filed an antitrust complaint against IBM first, and it appears they're trying to force IBM to let z/OS run on TH emulation (normally IBM only licenses z/OS to run on IBM hardware). IBM's patent threat is in response to this. Responding to a threat is rather different from initiating a threat.
I also notice the company TurboHercules keeps in OpenMainframe.org: Microsoft, the CCIA (known to be a Microsoft arm), Peerstone Research (what's an analyst firm doing here?), T3 Technologies (which was doing what TH is doing and has a grudge against IBM because IBM made them choose between selling the emulated solution and selling IBM mainframes). Long experience tells me that the side Microsoft's on is usually the wrong side.
Why would a company hire a paid intern? Just look at the complaints from hiring managers about the lack of qualified/skilled applicants. Typically an internship pays much less than the kind of position the person's interning for. By taking on the intern the company gets some work for much less than they'd otherwise have to pay, they get to find out whether this person's a good fit, and they provide the training they feel applicants would need for that kind of position. At the end they potentially have a trained candidate ready for a job, without having to go through the expense they'd have to to hire a regular employee and possibly have them not work out. And even if the intern doesn't work out for them, someone who interned at another company may show up with the training and experience needed for a position the company's hiring for, see the aforementioned complaints about lack of qualified candidates.
Of course the companies would like to get all the benefits of having trained, qualified people on tap without having to do anything to get them. To me, though, that's like the times I hear executives going on about how they need to charge their customers as much as possible while keeping costs to a minimum, and then they turn around and complain about how their suppliers are trying to charge as much as possible while delivering goods that barely meet the minimum standards and having poor customer service. They simply don't get the connection.
I have to disagree with Alex. Not with his summary of what happened, but with his conclusions. The OOXML standards project hasn't failed, and isn't heading for failure. It's been wildly successful. Remember that Microsoft's goal with it wasn't to produce a standard document format. It was to get an ISO standard passed with OOXML in the name so Microsoft could provide the correct tick-list item to sell to governments, while still keeping MS Office using a format that only Microsoft could reliably read and write. In fact, a document format that conformed strictly to a published standard that was completely and correctly specified was for MS an explicit non-goal, something to be kept from happening.
And if Alex expected anything else from Microsoft, I have to think he's deluded. There's nothing in Microsoft's history to suggest they'd do otherwise if they have any alternative open to them.
You aren't missing anything. The problem is HR. The people actually hiring don't evaluate resumes at companies of any size. They send a position summary to HR, who handle that. When you submit a resume, it goes to HR. HR then scans your resume for the keywords from the position summary. If your resume doesn't contain exactly the right keywords (which you don't know), then HR bins your resume and the people who know what to look for never even see it. Meanwhile the scam artists (whether the candidate themselves or the recruiter submitting their resume) know exactly how to put the right keywords in, so what does go through to the hiring manager is the people who aren't qualified. Which leaves both hiring managers and candidates griping.
Yes, I've been through this from the hiring side. After one particularly fruitless batch I got permission from my manager to go twist HR's arms until they coughed up the rejected resumes. And lo and behold, we found 5 interviewable candidates from the batch HR said weren't qualified. My manager was, needless to say, Not Amused, and made his lack of amusement felt.
It's not consoles that're holding games back. It's Windows 7. All the hard-core gamers I know are still running XP on their gaming rigs because of the hit they get to frame rates running Windows 7. These are the people who care about a 5fps difference even when they're getting over 60fps. The game companies know these people are their core audience, and if they put out a game these people can't run on their rigs that game won't sell well. Those rigs run XP, XP won't do higher than DirectX 9c, so the game companies target DX9c. It'll run on the hard-core gamers' rigs, it'll run on the average consumer's Windows 7 machine, so there's no sense in supporting DX10 or DX11. The only games I've seen that require DX10 or DX11 come from Microsoft itself.
The publisher sold the game new. The packaging reflects what the publisher sold. The publisher isn't selling it used, so why should their packaging reflect that?
Yes, game companies should be allowed to do one-time-use codes in their games. Yes, this is going to mean the games aren't particularly attractive in the used-game market. The problem is stores like GameStop that don't clearly mark their used games clearly as to what's advertised on the packaging that isn't actually going to be available because somebody else has already used it up. And I think that should be the responsibility of the used-game sellers, not the publisher. They're the ones who know that copy's used, after all.
As far as the copyrights go, it's simple: unless the original author of a bit of code transferred (or was require to transfer) the copyright to the project, the original author continues to hold the copyright. GPL has nothing to do with it, that's the rules of copyright law. Consensus also has nothing to do with it, it's a decision solely in the hands of the copyright holder whether to transfer their copyright or not. So unless the Nexuiz project required copyright transfer and refused to accept contributions from anyone who wouldn't transfer the copyrights, they don't have the right to license other people's GPL code under non-GPL terms. Even if that code is in the Nexuiz project's codebase.
For the audit-trail and change-control counterarguments, it's simple: keeping track of all those files on a computer and keeping them preserved across machine migrations and system disasters is a pain, while keeping a few file folders in my desk drawer is dead simple.
As for the monitor, it doesn't exist. My desk has a working surface of about 16 square feet. Call me when a monitor even half that big exists. And after that we need to discuss a touch-screen interface that'll let me slide documents around with my fingers the way I can rearrange papers on my desk. I don't even want to think about using a mouse on a 6'-wide display. My ideal would be a laid-flat version of the interface from Minority Report, but those just don't exist in this reality.
Seconded there. The relevant business departments should be the ones laying down the rules (since they know what the rules are supposed to be), and the SAs should be the ones to handle the implementation of those rules. You don't have the business departments deciding how Windows domain groups should be managed, just as you don't have the SAs deciding how long workman's comp documents should be retained.
OTOH there's often a conflict between what the business departments want and what the individual employees involved want or need. Eg., regardless of what HR says I want all paperwork that involves me and HR kept until at least 7 years after I leave the company, and I want it kept where I can get at it and HR can't. HR can have and manage their copies any way they want, but since it involves me I want my own copies under my control just in case HR (or the upper management who give orders to HR) find it in the company's interest to not have something exist (which has happened to me, which is why I'm so hard-line about this). And as a developer there's e-mail chains that're the only documentation of what a project's requirements were, and I want that e-mail chain kept indefinitely (it needs to exist until that project's software is decommissioned) so future developers can refer to it. I haven't seen a document-management system yet that could handle this particular dichotomy.
The problem with change control is most of those systems require you to use them. Which the people who need to won't. They've got their documents, they don't see a need to learn some new system that involves checking out and checking in. And there's no effective way to graft the change-control systems onto the My Documents folder and into Word and Excel and such so that changes get recorded just by editing and saving the document.
As far as reimaging, that's the problem. The reimaging process today involves wiping the computer clean and putting a virgin image onto it. Backups... well, if the backups were usable there'd be no need to restore from them because the computer would be working. And when upgrading the machine you can't restore from backups because that'd also restore the Windows system, drivers, etc. from the old machine and that won't work on new hardware. I know all that can be solved, but it involves doing things in a non-default way and knowing what you're doing which means IT won't do that.
Off-line use. I can refer to paper copies and make notes on them even when I'm not around the computer.
Audit trail. Most document-management systems and e-mail systems have document retention policies that're under someone else's control. Sometimes I need to control copies of the documents independently of company policies (eg. anything related to HR, records that might prove inconvenient for management later (like my detailing of exactly why something they want to do is a Bad Idea), etc.).
Change control. Many times documents can be changed in the computer and, while it records that there was a change, there's no record anymore of what the document said before the change. The paper copies in my drawer can't be changed and I can pull them out to prove that yes that was what was originally specified.
Space. My desk's a lot bigger than the computer monitor, and I can lay out a lot more papers and diagrams on it than I can have visible on the monitor at one time. Very useful, that.
Reliability. I don't have to worry about the contents of my desk drawers and noteboard going *poof* when a system upgrade goes south and it turns out the restore process requires things IT can't afford to do.
Maybe he didn't. A number of browsers nowadays have a prefetch feature: they'll follow any links on a page and fetch the pages those links point to, to help speed things up when (or if) the user clicks on those links. That results in data in the cache for pages the user never visited.
Then you end up with a neatly-formatted table with columns and rows corresponding to what was in your spreadsheet. Tables were part of the ODF 1.0 spec, no problems there.
Well, migrating an entire organization to the newest version of Windows (with the accompanying upgrades to all the other MS software) isn't exactly cheap. That's why so many corporations are still running XP: they can't justify the costs of upgrading to Vista or Windows 7.
I note that a lot of the problems they ran into weren't problems with the Linux-based software, they were problems with the proprietary (Windows and Windows-based) software not wanting to play nice with anybody else. One advantage of moving to open-source, standards-based software is competition. In the proprietary environment all those lock-in "features" that caused all the problems during the Linux migration also act to keep you locked in to a single vendor who can then charge high prices because you've no alternative. Once you're on standards-based and open-source software, though, any vendor can come in and take it over. That leads to lower costs down the road because you can dump vendors who try to over-charge without any disruption to your systems.
It also leads to lower migration costs the next time. OpenOffice doesn't provide some features you need? You can replace it with any other software that handles ODF without any disruption and without any problems with document formatting. Need to talk to another organization that doesn't use OpenOffice? No problem, as long as their software understands ODF you should be able to read each other's documents reliably and correctly (and right now I think the only major word-processing software out there that doesn't handle ODF correctly is Microsoft Word).
It's not ambiguous in the spec, it's undefined in the spec. But one thing is defined in the spec: a way to do application-specific spreadsheet formulas without breaking the standard and without conflicting with a standardized way of expressing formulas when it's finally standardized. The expectation is that applications will do formulas their own way, possibly recognizing other application-specific formulas (there actually aren't that many different formats). When formulas are finally standardized applications will begin using the standard and will convert any non-standard formulas they recognize into the standard form when the spreadsheet's read in, resulting in a quiet upgrade to the standard form.
And in the meantime, ODF can be used for things like word-processing documents that don't require formulas without having to wait for one spreadsheet-specific feature to be completed.
If Viacom were just retracting their requests, Google's lawyers wouldn't be making the statement they did. It'd have to be one of Viacom's people writing Google saying "Hey, what happened to the videos we uploaded? The page says it was taken down because of a DMCA complaint.". And Google going "Oh reeeeeeally. That's odd, the DMCA complaint was from Viacom too. Left hand and right hand not talking much?". Followed by Google's lawyers getting together with Google's engineers to do a little data mining.
At the very least they'll have copies of the requests from Viacom to restore the videos that Viacom demanded be taken down, and most likely Google required that those requests state exactly why Viacom has the authority to make that video available. They also probably traced the IP addresses, odds on more than a few times somebody slipped up and uploaded videos from an IP traceable to a machine belonging to Viacom or one of it's marketing companies. The marketers have no dog in this fight, if Google's gone to them with apparent proof that they've been uploading Viacom's videos the marketers won't have any qualms about pulling out their authorization from Viacom to cover themselves.
Google hires some pretty good lawyers. I doubt they'd be making such a strong statement in a legal action if they didn't already have what they needed to back it up.
The problem's basically one of time. Think about this: the first radio transmission on Earth was in 1866. That's 144 years ago. That means that any alien civilization more than 144 light-years away from Earth can't see us in the radio bands. They'd have to be inside the bubble formed by our first radio transmissions to even have a chance of spotting us using the methods SETI does. And that bubble isn't a sphere either, it'll eventually have an inside surface as well as an outer one. We're getting more and more efficient, wasting less and less power beaming radio waves off in all directions. Eventually we'll be broadcasting so little that we won't be detectable at any reasonable distance. Anybody inside that inner surface won't be able to see us either. That'll leave probably a 250-300 light-year thick zone moving steadily outwards that any race looking for us will have to be in to see us by looking for radio transmissions. They won't have to just be looking for us, they'll have to be looking for us during the 3-century period when they're in that zone. Look too early or too late and we're invisible to them.
And the same applies to us: we can look all we want, but if we're not in the radio-transmission zone for another species they'll be invisible to us.
Customizable won't cut it. It's not a matter of just changing the UI appearance or adding stock items or categories. The shower control system requires the POS system have code in it to talk to a system the POS programmers don't know exists. The POS can't use a standard interface because there is no standard interface for this thing. And customization doesn't extend to handling arbitrary binary data formats over arbitrary communications methods. The only way to do that is by adding custom code, which requires the POS system have hooks for calling that code. Moreover, it has to have the right hooks, and has to have a way for the code called by those hooks to call back into the POS to display things and process input (which in turn has to go back to the custom code for handling). At which point we're right back to it taking longer to learn all the ins and outs of the framework and how to hack it to add those things it's missing than it'd've taken to write things from scratch using a more primitive GUI framework. Ditto with the RFID.
Oh, and the system as a whole was modular. Shower control, RFID control, liquid-fuel interface, pump control, all were their own modules. But the POS was in the unique position of needing to talk to all those modules all the time. Even credit-card authorization was it's own module, which led to problems with off-the-shelf POS systems. They all wanted to do their own CC handling, which conflicts with the absolute requirement that they hand all that off to our in-house CC handling system. Which again has it's own interface because there isn't a standard CC-handling interface because all the off-the-shelf solutions handle it internally.
As I said, it was amusing watching the salespeople stumble on all these points. I didn't have the liberty of fast-talking it, I had to make it work and deliver it by deadline.
Take an example from one of my previous jobs: a point-of-sale cash-register system. Yep, there's plenty of those on the market. But now make those interface with the gas-pump controllers. All 4 varieties. 2 of which the manufacturers dropped support for 10 years ago. The POS system has to handle pump authorization, credit-card validation and authorization, pump limits and all the rest. And it has to display pump status on demand. You can still probably buy this, but the number of options is a lot more limited. Now add on the ability to interface with the shower-stall control system. But there aren't any commecial shower-stall control systems, you say? No, there aren't, that's why we had to write our own. And the POS system still has to interface with it. It has to handle selling shower tickets for multiple type of stalls (male, female or don't-care, regular or handicapped-accessible, etc.), it has to put the ticket into the shower-control system and it has to display shower status on demand. And since there's no standard API for this and no commercially-available systems, it's got to do all this through a custom-designed interface to an in-house system. Now add interfacing to the on-vehicle RFID system (at a time when nobody was doing on-vehicle RFID, so again the only option was a custom in-house system), the liquid fuel inventory system and so on. Oh and I forgot, the registers can't just handle regular credit cards, they have to handle the 30-odd varieties of cards we accepted plus direct-bill to various trucking companies.
By this point the sales rep's eyes are bugging out and he's sounding a lot like a motorboat. And I've just gone through the things the register software has to handle to support what the custom-written system currently does. We haven't even gotten into the things we'd like it to do to support future plans.
Thing is, it's not just a matter of writing the code. It's a matter of modifying the framework to do something it wasn't designed to do. Try modifying the controller class of a framework that you don't have in source-code form to do something that the class already does in a way that won't work for your application when the class doesn't provide any hooks for you to modify the behavior. It's nowhere near as easy as writing the code from scratch would be.
The problem Ars would have with me is that it's not Ars' ads at issue. It's the ads on hundreds of other sites that aren't as clean as Ars keeps theirs. I can't afford to hit one of those sites without ad blocking already on. By the time I can see the ads to make a decision, it's too late. If I can see the ads, my machine's already been hit with whatever payload they might be carrying. There's nothing Ars can do about this, they don't control other sites' advertising. So, I will arrive at Ars with an ad blocker running. All Ars can do is make it clear what I need to do to white-list them. Which, BTW, Ars didn't do. When I saw their pages, I saw no indication why the article wasn't appearing. I wrote it off as just more broken Javascript on their page causing a malfunction, and figured either it'd clear up in a day or two once enough users complained or it'd be permanent in which case I just wouldn't be reading Ars anymore. Since Ars gave no indication what they were doing, I had no reason to believe I needed to touch the ad blocker.
The problem is that, in my experience, there is no right framework. All of them will be missing 2-3 critical things you need to do. Different critical things, but they'll all be missing something somewhere. That's because they're written to be generic, they don't take into account your specific business cases, so there's always something the framework developer never thought of and never accommodated.
Slashdot Mirror
One thing I notice is that IBM's patent threat isn't an opening move by IBM. TurboHercules filed an antitrust complaint against IBM first, and it appears they're trying to force IBM to let z/OS run on TH emulation (normally IBM only licenses z/OS to run on IBM hardware). IBM's patent threat is in response to this. Responding to a threat is rather different from initiating a threat.
I also notice the company TurboHercules keeps in OpenMainframe.org: Microsoft, the CCIA (known to be a Microsoft arm), Peerstone Research (what's an analyst firm doing here?), T3 Technologies (which was doing what TH is doing and has a grudge against IBM because IBM made them choose between selling the emulated solution and selling IBM mainframes). Long experience tells me that the side Microsoft's on is usually the wrong side.
Why would a company hire a paid intern? Just look at the complaints from hiring managers about the lack of qualified/skilled applicants. Typically an internship pays much less than the kind of position the person's interning for. By taking on the intern the company gets some work for much less than they'd otherwise have to pay, they get to find out whether this person's a good fit, and they provide the training they feel applicants would need for that kind of position. At the end they potentially have a trained candidate ready for a job, without having to go through the expense they'd have to to hire a regular employee and possibly have them not work out. And even if the intern doesn't work out for them, someone who interned at another company may show up with the training and experience needed for a position the company's hiring for, see the aforementioned complaints about lack of qualified candidates.
Of course the companies would like to get all the benefits of having trained, qualified people on tap without having to do anything to get them. To me, though, that's like the times I hear executives going on about how they need to charge their customers as much as possible while keeping costs to a minimum, and then they turn around and complain about how their suppliers are trying to charge as much as possible while delivering goods that barely meet the minimum standards and having poor customer service. They simply don't get the connection.
I have to disagree with Alex. Not with his summary of what happened, but with his conclusions. The OOXML standards project hasn't failed, and isn't heading for failure. It's been wildly successful. Remember that Microsoft's goal with it wasn't to produce a standard document format. It was to get an ISO standard passed with OOXML in the name so Microsoft could provide the correct tick-list item to sell to governments, while still keeping MS Office using a format that only Microsoft could reliably read and write. In fact, a document format that conformed strictly to a published standard that was completely and correctly specified was for MS an explicit non-goal, something to be kept from happening.
And if Alex expected anything else from Microsoft, I have to think he's deluded. There's nothing in Microsoft's history to suggest they'd do otherwise if they have any alternative open to them.
Nothing makes you breathe, you choose to do it of your own accord. Care to try stopping?
You aren't missing anything. The problem is HR. The people actually hiring don't evaluate resumes at companies of any size. They send a position summary to HR, who handle that. When you submit a resume, it goes to HR. HR then scans your resume for the keywords from the position summary. If your resume doesn't contain exactly the right keywords (which you don't know), then HR bins your resume and the people who know what to look for never even see it. Meanwhile the scam artists (whether the candidate themselves or the recruiter submitting their resume) know exactly how to put the right keywords in, so what does go through to the hiring manager is the people who aren't qualified. Which leaves both hiring managers and candidates griping.
Yes, I've been through this from the hiring side. After one particularly fruitless batch I got permission from my manager to go twist HR's arms until they coughed up the rejected resumes. And lo and behold, we found 5 interviewable candidates from the batch HR said weren't qualified. My manager was, needless to say, Not Amused, and made his lack of amusement felt.
It's not consoles that're holding games back. It's Windows 7. All the hard-core gamers I know are still running XP on their gaming rigs because of the hit they get to frame rates running Windows 7. These are the people who care about a 5fps difference even when they're getting over 60fps. The game companies know these people are their core audience, and if they put out a game these people can't run on their rigs that game won't sell well. Those rigs run XP, XP won't do higher than DirectX 9c, so the game companies target DX9c. It'll run on the hard-core gamers' rigs, it'll run on the average consumer's Windows 7 machine, so there's no sense in supporting DX10 or DX11. The only games I've seen that require DX10 or DX11 come from Microsoft itself.
The publisher sold the game new. The packaging reflects what the publisher sold. The publisher isn't selling it used, so why should their packaging reflect that?
Yes, game companies should be allowed to do one-time-use codes in their games. Yes, this is going to mean the games aren't particularly attractive in the used-game market. The problem is stores like GameStop that don't clearly mark their used games clearly as to what's advertised on the packaging that isn't actually going to be available because somebody else has already used it up. And I think that should be the responsibility of the used-game sellers, not the publisher. They're the ones who know that copy's used, after all.
As far as the copyrights go, it's simple: unless the original author of a bit of code transferred (or was require to transfer) the copyright to the project, the original author continues to hold the copyright. GPL has nothing to do with it, that's the rules of copyright law. Consensus also has nothing to do with it, it's a decision solely in the hands of the copyright holder whether to transfer their copyright or not. So unless the Nexuiz project required copyright transfer and refused to accept contributions from anyone who wouldn't transfer the copyrights, they don't have the right to license other people's GPL code under non-GPL terms. Even if that code is in the Nexuiz project's codebase.
For the audit-trail and change-control counterarguments, it's simple: keeping track of all those files on a computer and keeping them preserved across machine migrations and system disasters is a pain, while keeping a few file folders in my desk drawer is dead simple.
As for the monitor, it doesn't exist. My desk has a working surface of about 16 square feet. Call me when a monitor even half that big exists. And after that we need to discuss a touch-screen interface that'll let me slide documents around with my fingers the way I can rearrange papers on my desk. I don't even want to think about using a mouse on a 6'-wide display. My ideal would be a laid-flat version of the interface from Minority Report, but those just don't exist in this reality.
Seconded there. The relevant business departments should be the ones laying down the rules (since they know what the rules are supposed to be), and the SAs should be the ones to handle the implementation of those rules. You don't have the business departments deciding how Windows domain groups should be managed, just as you don't have the SAs deciding how long workman's comp documents should be retained.
OTOH there's often a conflict between what the business departments want and what the individual employees involved want or need. Eg., regardless of what HR says I want all paperwork that involves me and HR kept until at least 7 years after I leave the company, and I want it kept where I can get at it and HR can't. HR can have and manage their copies any way they want, but since it involves me I want my own copies under my control just in case HR (or the upper management who give orders to HR) find it in the company's interest to not have something exist (which has happened to me, which is why I'm so hard-line about this). And as a developer there's e-mail chains that're the only documentation of what a project's requirements were, and I want that e-mail chain kept indefinitely (it needs to exist until that project's software is decommissioned) so future developers can refer to it. I haven't seen a document-management system yet that could handle this particular dichotomy.
The problem with change control is most of those systems require you to use them. Which the people who need to won't. They've got their documents, they don't see a need to learn some new system that involves checking out and checking in. And there's no effective way to graft the change-control systems onto the My Documents folder and into Word and Excel and such so that changes get recorded just by editing and saving the document.
As far as reimaging, that's the problem. The reimaging process today involves wiping the computer clean and putting a virgin image onto it. Backups... well, if the backups were usable there'd be no need to restore from them because the computer would be working. And when upgrading the machine you can't restore from backups because that'd also restore the Windows system, drivers, etc. from the old machine and that won't work on new hardware. I know all that can be solved, but it involves doing things in a non-default way and knowing what you're doing which means IT won't do that.
Some of the reasons I still use paper:
Maybe he didn't. A number of browsers nowadays have a prefetch feature: they'll follow any links on a page and fetch the pages those links point to, to help speed things up when (or if) the user clicks on those links. That results in data in the cache for pages the user never visited.
Then you end up with a neatly-formatted table with columns and rows corresponding to what was in your spreadsheet. Tables were part of the ODF 1.0 spec, no problems there.
Well, migrating an entire organization to the newest version of Windows (with the accompanying upgrades to all the other MS software) isn't exactly cheap. That's why so many corporations are still running XP: they can't justify the costs of upgrading to Vista or Windows 7.
I note that a lot of the problems they ran into weren't problems with the Linux-based software, they were problems with the proprietary (Windows and Windows-based) software not wanting to play nice with anybody else. One advantage of moving to open-source, standards-based software is competition. In the proprietary environment all those lock-in "features" that caused all the problems during the Linux migration also act to keep you locked in to a single vendor who can then charge high prices because you've no alternative. Once you're on standards-based and open-source software, though, any vendor can come in and take it over. That leads to lower costs down the road because you can dump vendors who try to over-charge without any disruption to your systems.
It also leads to lower migration costs the next time. OpenOffice doesn't provide some features you need? You can replace it with any other software that handles ODF without any disruption and without any problems with document formatting. Need to talk to another organization that doesn't use OpenOffice? No problem, as long as their software understands ODF you should be able to read each other's documents reliably and correctly (and right now I think the only major word-processing software out there that doesn't handle ODF correctly is Microsoft Word).
It's not ambiguous in the spec, it's undefined in the spec. But one thing is defined in the spec: a way to do application-specific spreadsheet formulas without breaking the standard and without conflicting with a standardized way of expressing formulas when it's finally standardized. The expectation is that applications will do formulas their own way, possibly recognizing other application-specific formulas (there actually aren't that many different formats). When formulas are finally standardized applications will begin using the standard and will convert any non-standard formulas they recognize into the standard form when the spreadsheet's read in, resulting in a quiet upgrade to the standard form.
And in the meantime, ODF can be used for things like word-processing documents that don't require formulas without having to wait for one spreadsheet-specific feature to be completed.
If Viacom were just retracting their requests, Google's lawyers wouldn't be making the statement they did. It'd have to be one of Viacom's people writing Google saying "Hey, what happened to the videos we uploaded? The page says it was taken down because of a DMCA complaint.". And Google going "Oh reeeeeeally. That's odd, the DMCA complaint was from Viacom too. Left hand and right hand not talking much?". Followed by Google's lawyers getting together with Google's engineers to do a little data mining.
At the very least they'll have copies of the requests from Viacom to restore the videos that Viacom demanded be taken down, and most likely Google required that those requests state exactly why Viacom has the authority to make that video available. They also probably traced the IP addresses, odds on more than a few times somebody slipped up and uploaded videos from an IP traceable to a machine belonging to Viacom or one of it's marketing companies. The marketers have no dog in this fight, if Google's gone to them with apparent proof that they've been uploading Viacom's videos the marketers won't have any qualms about pulling out their authorization from Viacom to cover themselves.
Google hires some pretty good lawyers. I doubt they'd be making such a strong statement in a legal action if they didn't already have what they needed to back it up.
The problem's basically one of time. Think about this: the first radio transmission on Earth was in 1866. That's 144 years ago. That means that any alien civilization more than 144 light-years away from Earth can't see us in the radio bands. They'd have to be inside the bubble formed by our first radio transmissions to even have a chance of spotting us using the methods SETI does. And that bubble isn't a sphere either, it'll eventually have an inside surface as well as an outer one. We're getting more and more efficient, wasting less and less power beaming radio waves off in all directions. Eventually we'll be broadcasting so little that we won't be detectable at any reasonable distance. Anybody inside that inner surface won't be able to see us either. That'll leave probably a 250-300 light-year thick zone moving steadily outwards that any race looking for us will have to be in to see us by looking for radio transmissions. They won't have to just be looking for us, they'll have to be looking for us during the 3-century period when they're in that zone. Look too early or too late and we're invisible to them.
And the same applies to us: we can look all we want, but if we're not in the radio-transmission zone for another species they'll be invisible to us.
Customizable won't cut it. It's not a matter of just changing the UI appearance or adding stock items or categories. The shower control system requires the POS system have code in it to talk to a system the POS programmers don't know exists. The POS can't use a standard interface because there is no standard interface for this thing. And customization doesn't extend to handling arbitrary binary data formats over arbitrary communications methods. The only way to do that is by adding custom code, which requires the POS system have hooks for calling that code. Moreover, it has to have the right hooks, and has to have a way for the code called by those hooks to call back into the POS to display things and process input (which in turn has to go back to the custom code for handling). At which point we're right back to it taking longer to learn all the ins and outs of the framework and how to hack it to add those things it's missing than it'd've taken to write things from scratch using a more primitive GUI framework. Ditto with the RFID.
Oh, and the system as a whole was modular. Shower control, RFID control, liquid-fuel interface, pump control, all were their own modules. But the POS was in the unique position of needing to talk to all those modules all the time. Even credit-card authorization was it's own module, which led to problems with off-the-shelf POS systems. They all wanted to do their own CC handling, which conflicts with the absolute requirement that they hand all that off to our in-house CC handling system. Which again has it's own interface because there isn't a standard CC-handling interface because all the off-the-shelf solutions handle it internally.
As I said, it was amusing watching the salespeople stumble on all these points. I didn't have the liberty of fast-talking it, I had to make it work and deliver it by deadline.
Wrong.
Take an example from one of my previous jobs: a point-of-sale cash-register system. Yep, there's plenty of those on the market. But now make those interface with the gas-pump controllers. All 4 varieties. 2 of which the manufacturers dropped support for 10 years ago. The POS system has to handle pump authorization, credit-card validation and authorization, pump limits and all the rest. And it has to display pump status on demand. You can still probably buy this, but the number of options is a lot more limited. Now add on the ability to interface with the shower-stall control system. But there aren't any commecial shower-stall control systems, you say? No, there aren't, that's why we had to write our own. And the POS system still has to interface with it. It has to handle selling shower tickets for multiple type of stalls (male, female or don't-care, regular or handicapped-accessible, etc.), it has to put the ticket into the shower-control system and it has to display shower status on demand. And since there's no standard API for this and no commercially-available systems, it's got to do all this through a custom-designed interface to an in-house system. Now add interfacing to the on-vehicle RFID system (at a time when nobody was doing on-vehicle RFID, so again the only option was a custom in-house system), the liquid fuel inventory system and so on. Oh and I forgot, the registers can't just handle regular credit cards, they have to handle the 30-odd varieties of cards we accepted plus direct-bill to various trucking companies.
By this point the sales rep's eyes are bugging out and he's sounding a lot like a motorboat. And I've just gone through the things the register software has to handle to support what the custom-written system currently does. We haven't even gotten into the things we'd like it to do to support future plans.
Thing is, it's not just a matter of writing the code. It's a matter of modifying the framework to do something it wasn't designed to do. Try modifying the controller class of a framework that you don't have in source-code form to do something that the class already does in a way that won't work for your application when the class doesn't provide any hooks for you to modify the behavior. It's nowhere near as easy as writing the code from scratch would be.
The problem Ars would have with me is that it's not Ars' ads at issue. It's the ads on hundreds of other sites that aren't as clean as Ars keeps theirs. I can't afford to hit one of those sites without ad blocking already on. By the time I can see the ads to make a decision, it's too late. If I can see the ads, my machine's already been hit with whatever payload they might be carrying. There's nothing Ars can do about this, they don't control other sites' advertising. So, I will arrive at Ars with an ad blocker running. All Ars can do is make it clear what I need to do to white-list them. Which, BTW, Ars didn't do. When I saw their pages, I saw no indication why the article wasn't appearing. I wrote it off as just more broken Javascript on their page causing a malfunction, and figured either it'd clear up in a day or two once enough users complained or it'd be permanent in which case I just wouldn't be reading Ars anymore. Since Ars gave no indication what they were doing, I had no reason to believe I needed to touch the ad blocker.
The problem is that, in my experience, there is no right framework. All of them will be missing 2-3 critical things you need to do. Different critical things, but they'll all be missing something somewhere. That's because they're written to be generic, they don't take into account your specific business cases, so there's always something the framework developer never thought of and never accommodated.