More seriously, opinionated article is substantially underinformed and, I think, substantially underestimates what Google means by "browser based". (Whether or not you like Google's thin-client 2.0 all-your-data-are-belong-to-us strategy, you should never underestimate its sophistication).
First, and foremost, "browser based" is not going to imply "brick unless internet connected". Google built Gears before the HTML5 local data persistence stuff was available, and has been quite clear that they will be implementing the HTML5 stuff.
Second, of course, is the fact that Google has the option, and will quite likely exercise it if needed, of doing "web styled", but not strictly standard, stuff through javascript extensions(like what Palm uses in WebOS to enable various platform specific stuff) or through plugins. Most notably, Google has a little project they call "NaCl". Native Client. Available now for x86, soon for ARM. Allows sandboxed native code to run in a browser plugin.
With that, "browser based" can practically mean whatever the hell they want it to. It will, at an absolute minimum, mean any capability that they have already demonstrated in-browser; but, if they feel like it, it can also mean essentially arbitrary native x86 or ARM binaries just running in plugin sandboxes with CSS/javascript driven styling, and a browser-tab windowing model. It would also, I suspect, be Not That Hard for Google to bring over a Dalvik plugin, that would allow you to run Android applications embedded in the "browser based" environment.
Yeah, if "ChromeOS" were simply "Hey, lets put a copy of chrome on a crippled ubuntu install!", it would be certain to fail. However, it is not at all likely that that is the plan. Admittedly, the plan is likely to be less "web based" than some might like, and might even involve some sorts of questionable Google-Only advantages(ie. NaCl plugins signed by Google get to be arbitrarily persistent, and occupy more of the available storage space, 3rd party stuff is subject to the standard caching algorithm, or something of that kind); but there is no reason to suspect that it won't be nearly arbitrarily powerful.(which doesn't assure it any traction; but if it fails to find its feet, it won't be because it is crippled).
In that vein, it should probably be mentioned that many progress bars are purely for psychological effect.
The ones that just have a moving gradient, or a bar that zooms back and forth don't actually indicate progress at all, they just reassure the waiting human that the machine is working, rather than frozen, which apparently makes the wait seem shorter.
Also, outside of some fairly specific niche applications(and video encoding/transcoding, which may not count as 'niche' these days), most progress bars that would last long enough to be visible are probably not there to indicate the status of a CPU constrained process. Pretty much any computer that runs on single-phase current at 15 amps or less is ridiculously powerful in the CPU department, but has severely questionable I/O performance.
I suspect that that is part of it(which is certainly an ice burn, since poor old Bill Gates has been chasing tablet computing since back before Steve Jobs got booted from apple); but I suspect that there is a secondary factor:
Margins/differentiation. IIRC, HP is, by volume, the largest mover of generic wintel crap in the world. For all that, they make fairly modest amounts of money, and most of the good margins are in their high end stuff and consulting services. This is largely because, if you ship Windows boxes, you basically don't have any differentiation potential. You can do a little bit of case styling, or ship a bit of your own shovelware; but not much else.
If this were just about Win7 sucking at tablet, HP would have gone with Android. To get WebOS, (and Palm's people), cost them 1.2 billion dollars. Android would have been free. Even if there is a de-facto cost associated with being Google's special friend and development buddy, which is certainly possible, it is probably a lot less than 1.2 billion. However, if they had shipped an Android device, they would have been just another android device maker, wholly undistinguished. Given that they paid a good bit of cash for Palm, I'm guessing that they don't want that.
Plus, while the "WebOS" design does have its downsides, the fact that most of the guts are either stock-ish linux, or mostly standard javascript and web stuff running on webkit likely makes porting pretty easy(and it isn't as though there is a huge installed base of native applications to hold them back, yet). I'd assume that Palm has had an x86 version running from day one(heck, they probably started development on x86).
HP has the option, depending on whether they value time-to-market or battery life/BOM cost more, to either dump WebOS on exactly the same hardware they were waving around with Win7, or rework the design with some ARM SoC.
I suspect, for consumer products, that the main target will be the (alleged? I've never been able to tell exactly how real it is) hatred of and confusion about wires possessed by Joe Average. Just wander into your living room, and your HDTV is automagically connected to your laptop, buy a new external drive(and plug it into the wall, because wireless power ain't there yet) and it automagically connects, and so forth.
If it is actually that LOS dependent, it isn't entirely clear that this will all be less confusion than just running a couple of wires, though, if the chipsets can silently fall back to 5GHz or 2.4GHz, at reduced speeds; but without actually breaking things as far as software can see, it might be OK.
On the other hand, where this sort of thing might get genuinely interesting, would be if emitters and receivers suitable for very short range could be fabricated directly on silicon. Being able to do die stacking just by putting one die on top of the other, and connecting power to both, and letting them chat wirelessly over very short range could save a considerable amount of money now spent on teeny-tiny gold wires, and the attachment thereof...
The secret sauce proprietary algorithm in the (puff piece) TFA sounds like a file verification mechanism, in the vein of CRC, hash verification, and friends. Which is odd; because the problem of keeping digital data reasonably uncorrupt is a serious one for Big Storage type outfits, and archivists; but it hasn't been much of a concern for team content. What they've wanted is watermarks, "traitor tracing", and all that. Now, a good verification algorithm is a terrible watermark algorithm, and vice versa, period. Verification algorithms are supposed to freak out if so much as a single bit has been twiddled. Watermark algorithms are supposed to be robust against common forms of tampering and re-encoding.
So, what's the deal?
1. It could be that "PC Authority" has been handed an NEC press release, and can't even handle the challenge of regurgitating it properly. In which case, any speculation based on the details of TFA is pointless, if TFA is so much commercial word salad.
2. It could also be that PC Authority is reading the NEC release more or less correctly; but the release was just blitzed out by some PR flack, and they lack the context. This is, in fact, an integrity verification technology, designed to work quickly on video streams, that will be included in some future standard, as an obscure convenience to future editors and producers and archivists who will have to deal with 10,000 hours of MPEG7 video in OMG-4k-Super-def-3D, and need to know, fast, if any of it is getting munged. It would be a super boring, highly specific part of the spec, of basically no interest to the general public; but it could be more or less true as described.
3. And here's the sinister conspiracy theory: Where do file integrity verification and DRM come together? If, and only if, planned devices are "default deny, play signed content only". If your Blu-ray2 player simply refused to play anything that isn't a wholly unaltered copy of a commercial release, the otherwise absurd(as noted above) notion that an integrity check algorithm can serve as a piracy deterrent becomes true... It wouldn't stop cammer kiddies from playing altered copies on general purpose PCs, if those are still alive; but making "blessed only" a condition of the licencing agreement for future STB-type devices would basically kill the unsophisticated pirated disk market(barring hardware hacks on specific devices, or really stupid mistakes in media design).
Consider: If Flash is cheap enough to distribute games on, it is cheap enough to build large mass storage devices into consoles with. Further, since a console is a one-time purchase, and its internal mass storage is re-usable, while a catridge's Flash has to come right out of the margins of the game, it will always be the case, no matter how cheap Flash gets, that a console can have a much larger mass storage block than a cartridge can. Simple economic reality. Unless the singularity strikes, and the numbers are "Catridge: a million bazillion petabytes, too cheap to price" and "Console: a trillion bazillion petabytes, too cheap to price" this difference will always matter.
Cartridges don't really offer any anti-piracy advantage anymore: again, because you have to fit into the margin of the game being sold, you are pretty limited in what security measures you can bake into the cartridge itself. Clones will be pouring out of China and onto ebay within moments. Any moderately robust system-level DRM is going to be in the console. And, if optical media really scare you, it is still cheaper to come up with a slight variant(Blu-Ray disks with embedded RFIDs or something) than it is to ship a cartridge. Downloads, of course, offer trivial per-download uniqueness opportunities.
Now, that said, I do suspect that the institution of playing/executing from optical media will die out in fairly short order(except for "watch once" stuff like movies. Optical media offer shitty latency, long load times, and are often pretty noisy. HDDs are faster and more capacious. SSDs are faster still, and capacity is climbing. I strongly suspect that most people would rather have a "15 minute 'install' consisting of dumping a disk image to internal storage, possibly in a compressed form that the console offers hardware accelerated decompression for, followed by fast level loads forever" to "Instant play, and 90 second level loads forever". Or, with a little cleverness, somebody could probably whip up a hybrid model: "Instant play, initially a touch slow as the disk image is dumped in the background, followed by gradually increasing speed as more and more reads take place from fixed storage, rather than optical disk".
Downloads, of course, will go to internal fixed storage(or external mass storage devices) no matter what.
While your suggestion is architecturally sound, the problem is that it is either A) A gigantic pain in the ass. or B) Gives enormous power to the vendor, that they will almost certainly exploit.
In the case of Linux, "A" largely applies. A properly configured SELinux setup will give you most of what you are asking for; but those are enough of a pain to set up that very few people have them.
Given that explosives can toss thousands of fragments capable of causing modest surface lacerations a fair distance beyond the "instant death/horrible injury" radius, it probably isn't at all uncommon to have situations with a dozen or two casualties per explosion, some hundreds in the course of a bombardment, all with somewhere between "multiple" and "numerous" surface wounds. All of which need to be closed before they get infected, or start collecting sand and bugs, and so forth, but during which time the cream of the medical personnel, and their support staff, are busy trying to stabilize the seriously injured.
If you can, with the right technology, make it so that anybody who can handle a syringe full of glue, basic aseptic technique, and a flashlight can swiftly close superficial wounds, you can probably reduce the mean-time-to-treatment for the lightly to moderately wounded, reduce the number of gross, scar-tastic rushed suture jobs, and preserve the time and attention of the most skilled medics for the more serious injuries.
Assuming the light source can be shrunk and hardened(which given the impressive performance of modern solid state lighting and diode lasers is a definite possibility), you could probably get the whole system down to something that consists of a funny looking flashlight and some disposable tubes of glue, suitable for forward operating use by anybody who has had cursory training...
Heck, compared to Acrobat Reader, implementing the PDF spec in Javascript and decomposing the PDF into some combination of CSS-styled text, SVG, and canvas might even be faster...
Against pretty much any other PDF reader, though, it would probably be strictly a stunt.
What you say is true; but I suspect that Military collapses are substantially nastier and more common, for the following reasons:
First, getting locked into a downward trajectory is much easier when your historical expenditures have been military. In even modest quantities, unemployed ex-soldiers can be destabilizing. In large quantities, "government disbands army" turns into "army disbands government" with fair ease. Other sorts of expenditures can command considerable cultural clout, and maybe even manage a protest or two; but the military are pretty much the only ones with the power to say "No, actually, You are disbanded."
Second, militaries are some of the more tenuously profitable sectors of society. You have to be running a fairly cheap army, and have some weak, fat neighbors, for them to turn a direct profit. Not being invaded is valuable, to other sectors of society, if they are well developed; but the military specifically is a money pit unless conditions are excellent(and, because of point 1, they are hard to defund when conditions change).
Arrogant Prima-Donna/master of the universe type whose reckless movements of millions and billions have, until now, enjoyed a very good track record? Quite possibly.
Corporations are faceless and monolithic, in a sense; but it just isn't possible for an entity constructed of people to not start being ruled by personality(either when you get high enough, in a rigorously controlled entity; Or when you get close enough to the edges, as in a slack one).
While I don't know the explanation being given in this specific situation is anything but bunk, I think that it is totally plausible that there is a subset of traders who have a track record good enough to give them serious clout, adn ego problem big enough to convince them that checks, balances, and controls just crimp their talents, who are being permitted to operate largely without programmatic control.
Joe, assistant desk monkey, obviously isn't; but Tim the golden boy, with the Midas touch, widely rumored to be moving up to senior partner any day now, can probably get some of "that IT bullshit" relaxed...
Not that there isn't some finance-clippy that pops up and asks "You appear to be tanking the Dow, would you like help with that?", or that people are allowed to do whatever stupid shit they want with the assets they have(the amount of stupid shit that people are allowed to do with assets that they don't have is somewhat concerning, however).
However, I am somewhat surprised that the guys who do UI design for financial systems don't design systems to make things like power-of-ten or million/billion errors very difficult. Having a 3 factors of 10 difference be just one key away(and phonetically not all that dissimilar) seems like a mess waiting to happen.
I've seen in doctor's offices(and I know pharmacists and pharmacy techs, especially ones where compounding and other tougher than "dispense stock pill" type activities go on get drilled hard on this) outlining acceptable and unacceptable notetaking protocols to reduce the risk of power-of-ten dosing errors(things like ".2 is wrong, there should always be a leading zero to clue you in to the decimal point, use 0.2.") Some of them are even domain specific conventions, specifically trading off other factors in favor of reducing the risk of error. In science, for instance, saying 2.0, or even 2.0000 if you have that much precision, instead of 2 is a good thing. It tells your reader how precise the value they are looking at is. In prescriptions and medical notes, "2.0" is dangerously close to "20", and is thus avoided.
One would think that, even if it meant making up arbitrary symbols, or using UI element sizes to convey magnitudes, or something, financial UIs would adopt a similar set of domain-specific tricks to head off the most common and dangerous errors.
I'm pretty sure that a programmatic(or manual, via some perverse tracing exercise) conversion from WOFF to TTF or equivalent would get just about any judge's "derivative work" sense tingling like mad...
"Real" security cameras actually vary pretty widely. An unimpressive number of them are of deeply undistinguished quality, pumping NTSC down long and dodgey coax runs, to indifferent capture cards(or old-school tape loop crap). Often weather hardened(which is one of those things that is more annoying than one might expect to DIY); but pretty miserable.
On the other hand, their are undeniably (expensive) offerings that offer contemporary-camcorder-or-better performance with real optics, good sensors, embedded logic that can intelligently prioritize between a lower quality video stream and higher quality stills of interesting or suspicious movements over channels with limited bandwidth. However, these can get really pricey really fast.
For whatever reason, the low end of the market seems to have substantially missed out on the absolutely plummeting costs of adequate sensors, optics, and single-board computers capable of tying them to a network.
Broadcast "news" consumes some extraordinarily valuable spectrum, a resource fairly tightly limited by the laws of physics. We have historically suffered it to do so because of its perceived value to our democratic society. If, however, it cannot demonstrate that value, there are much better things we could be doing with that scarce and valuable spectrum...
On the plus side, the ability of font copyrights to threaten the freedom of people who don't care is pretty limited. As long as you are blessed with somewhat undiscerning tastes, Free fonts are already available for pretty much any character set you would have reason to use. Substituting one font for another might break some design major's little dream; but it isn't hard.
Those people for who fonts don't matter much can easily just stick to the free stuff, and those people who care enough to pay can pay. Not a big deal.
I'd assume that(in a rare moment of sanity for a content industry), they concluded that while WOFF won't do much to stop an adversary who cares, neither will any "OMG SEcure!!" DRM solution running on general purpose PC hardware. Not to mention the fact that anybody who actually wants to hoard expensive fonts on their PC already got a DVD full from a friend, or from bittorrent, or from Usenet, depending on technical proficiency and age.
If they insisted on some goofy DRM scheme, they would stop a minimal number of low-skill, mostly low-value infringers, and probably ensure years more chaos on the web-fonts scene. If they went with WOFF, they'll be able to ink some lucrative licencing deals with major sites(who are the ones that actually matter), and a few people will extract fonts and use them to print greeting cards. It's a net win. Frankly, given the historical strength of DRM systems, pretty much any compression/obfuscation/weird file location trick that requires joe user to download some sort of helper utility to get past is basically as strong, for practical purposes, as some advanced DRM system that joe user would need to download a crack for.
Since home users basically don't buy fonts anyway, they don't represent a terribly valuable market. If somebody big rips you off, you can sue the shit out of them.
Why "security" cameras(ie. webcam and some sort of TCP/IP speaking computer in the same box, often with goodies like 12/24 volt tolerant GPIO, POE, and weatherproof housings) have largely lagged; but the situation isn't nearly as dire if you are willing to do a touch of DIY.
Between the substantial increase in the number of ~$100 webcams that actually work with UVC drivers and have image quality that doesn't suck, and the availability of highly capable SBCs like the Shivaplug for not much more, you can get an ugly; but surprisingly functional, setup going for ~$300 and a little linux fiddling.
The other option with good price performance punch is taking advantage of all the DV video cameras that are being upgraded by their owners, or have shot tape-transport mechanisms. All but the ghastliest DV cams will outclass virtually all webcams in terms of optics and sensors, and they all connect via firewire in a standard way. A bit bulky; but if you go after stuff being dumped by "HD" enthusiasts, or hardware with broken tape parts, you can get fairly serious image quality for peanuts.
Either I was insufficiently clear, or you utterly failed to understand my reasoning.(given that you appear to have identified me as a social conservative, I'm going with the latter).
No, sellers of pornography do not want to lure the unsuspecting(if nothing else, the shocked and horrified are unlikely to have a good conversion rate). However, and this is important, they want to make it easy for their customers to access them without interference from those around them.
Aside from those pushing for straight bans, most anti-porn crusaders advocate measures that make it more difficult to get porn without being noticed (correctly) inferring that that will, in a great many social contexts, have a strong chilling effect.
For instance, say this ".xxx" plan goes through(or the "CP80" one, which is a bit more comprehensive): it can be reasonably expected that ISPs will offer a "block *.xxx checkbox as a feature to attract worried parents and prudes of various stripes. If that comes to pass, an adult who wants access to internet porn will have to come up with some excuse, satisfactory to any other adults(ie. spouses, parents providing financial support, roommates) who have access to the bill, as to why they haven't activated that checkbox... That will be a lot of customers who want porn; but cannot reach it.
In a similar vein, imagine if it were mandated that the titles of all pay-per-view movies purchased in hotel rooms had to be itemized on the bill, rather than just the prices. That would likely have a substantially depressing effect on consumption of porn in hotel rooms; because it would be much harder to acquire without attracting spousal and/or employer scrutiny.
Yes, pornography sellers have no real interest in targeting the uninterested(barring the real bottom-feeding spammers, who are content with conversion rates under 1%); but they have a strong interest(possibly philosophical; but definitely financial) in making sure that their customers get to choose as freely of outside social pressure as possible. Measures that make that harder are a threat to them.
Since most avenues of access to porn are, at least potentially, subject to social exposure and social pressure(ie. if you have to go to a skeezy part of town, and risk being seen there, to get girlie mags, you are less likely to purchase them, if your hotel bill will reveal exactly what you watched, you are less likely to watch something salacious. If you have to request the "enable.xxx" option, visible on your monthly bill, from your ISP, fewer people will have access) this is a real concern for them.
These guys are definitely the devil's advocates; but http://www.cp80.org/ is a creepy pressure group, largely composed of slimy mormons(some of them with SCO ties...), advocating a very similar scheme. Everything on port 80 would have to be PG, with material that makes republican jesus cry relegated to other ports for easy blocking.
The lesson of Port 80 and firewalls. If the "feature" of.xxx is easy filtering, internet smut peddlers are going to be deeply apathetic about adopting it. What rational person makes their product harder for their customers to get to?
At best, if the prices are low enough, smut peddlers with high quality.coms and.nets will be forced to pick up.xxxs to match, to protect themselves from squatters, and peddlers with lousy URLs will pick up.xxxs in the hopes of grabbing some extra traffic. For the most part, though, porn sellers have no particular incentive to make themselves trivial to block.(They do have an incentive, except for the real bottom feeders, to not be perceived as resisting blocking software, or threatening innnocent children, because that could inspire a real backlash; but adults sneaking past imperfect filters are just fine by them.)
Its analogous to the number of oddball applications and protocols that have moved toward port 80, by default or as a common option, because that port is generally minimally restricted compared to the more special-purpose ports.
Slashdot Mirror
More seriously, opinionated article is substantially underinformed and, I think, substantially underestimates what Google means by "browser based". (Whether or not you like Google's thin-client 2.0 all-your-data-are-belong-to-us strategy, you should never underestimate its sophistication).
First, and foremost, "browser based" is not going to imply "brick unless internet connected". Google built Gears before the HTML5 local data persistence stuff was available, and has been quite clear that they will be implementing the HTML5 stuff.
Second, of course, is the fact that Google has the option, and will quite likely exercise it if needed, of doing "web styled", but not strictly standard, stuff through javascript extensions(like what Palm uses in WebOS to enable various platform specific stuff) or through plugins. Most notably, Google has a little project they call "NaCl". Native Client. Available now for x86, soon for ARM. Allows sandboxed native code to run in a browser plugin.
With that, "browser based" can practically mean whatever the hell they want it to. It will, at an absolute minimum, mean any capability that they have already demonstrated in-browser; but, if they feel like it, it can also mean essentially arbitrary native x86 or ARM binaries just running in plugin sandboxes with CSS/javascript driven styling, and a browser-tab windowing model. It would also, I suspect, be Not That Hard for Google to bring over a Dalvik plugin, that would allow you to run Android applications embedded in the "browser based" environment.
Yeah, if "ChromeOS" were simply "Hey, lets put a copy of chrome on a crippled ubuntu install!", it would be certain to fail. However, it is not at all likely that that is the plan. Admittedly, the plan is likely to be less "web based" than some might like, and might even involve some sorts of questionable Google-Only advantages(ie. NaCl plugins signed by Google get to be arbitrarily persistent, and occupy more of the available storage space, 3rd party stuff is subject to the standard caching algorithm, or something of that kind); but there is no reason to suspect that it won't be nearly arbitrarily powerful.(which doesn't assure it any traction; but if it fails to find its feet, it won't be because it is crippled).
In that vein, it should probably be mentioned that many progress bars are purely for psychological effect.
The ones that just have a moving gradient, or a bar that zooms back and forth don't actually indicate progress at all, they just reassure the waiting human that the machine is working, rather than frozen, which apparently makes the wait seem shorter.
Also, outside of some fairly specific niche applications(and video encoding/transcoding, which may not count as 'niche' these days), most progress bars that would last long enough to be visible are probably not there to indicate the status of a CPU constrained process. Pretty much any computer that runs on single-phase current at 15 amps or less is ridiculously powerful in the CPU department, but has severely questionable I/O performance.
I suspect that that is part of it(which is certainly an ice burn, since poor old Bill Gates has been chasing tablet computing since back before Steve Jobs got booted from apple); but I suspect that there is a secondary factor:
Margins/differentiation. IIRC, HP is, by volume, the largest mover of generic wintel crap in the world. For all that, they make fairly modest amounts of money, and most of the good margins are in their high end stuff and consulting services. This is largely because, if you ship Windows boxes, you basically don't have any differentiation potential. You can do a little bit of case styling, or ship a bit of your own shovelware; but not much else.
If this were just about Win7 sucking at tablet, HP would have gone with Android. To get WebOS, (and Palm's people), cost them 1.2 billion dollars. Android would have been free. Even if there is a de-facto cost associated with being Google's special friend and development buddy, which is certainly possible, it is probably a lot less than 1.2 billion. However, if they had shipped an Android device, they would have been just another android device maker, wholly undistinguished. Given that they paid a good bit of cash for Palm, I'm guessing that they don't want that.
Plus, while the "WebOS" design does have its downsides, the fact that most of the guts are either stock-ish linux, or mostly standard javascript and web stuff running on webkit likely makes porting pretty easy(and it isn't as though there is a huge installed base of native applications to hold them back, yet). I'd assume that Palm has had an x86 version running from day one(heck, they probably started development on x86).
HP has the option, depending on whether they value time-to-market or battery life/BOM cost more, to either dump WebOS on exactly the same hardware they were waving around with Win7, or rework the design with some ARM SoC.
I suspect, for consumer products, that the main target will be the (alleged? I've never been able to tell exactly how real it is) hatred of and confusion about wires possessed by Joe Average. Just wander into your living room, and your HDTV is automagically connected to your laptop, buy a new external drive(and plug it into the wall, because wireless power ain't there yet) and it automagically connects, and so forth.
If it is actually that LOS dependent, it isn't entirely clear that this will all be less confusion than just running a couple of wires, though, if the chipsets can silently fall back to 5GHz or 2.4GHz, at reduced speeds; but without actually breaking things as far as software can see, it might be OK.
On the other hand, where this sort of thing might get genuinely interesting, would be if emitters and receivers suitable for very short range could be fabricated directly on silicon. Being able to do die stacking just by putting one die on top of the other, and connecting power to both, and letting them chat wirelessly over very short range could save a considerable amount of money now spent on teeny-tiny gold wires, and the attachment thereof...
The secret sauce proprietary algorithm in the (puff piece) TFA sounds like a file verification mechanism, in the vein of CRC, hash verification, and friends. Which is odd; because the problem of keeping digital data reasonably uncorrupt is a serious one for Big Storage type outfits, and archivists; but it hasn't been much of a concern for team content. What they've wanted is watermarks, "traitor tracing", and all that. Now, a good verification algorithm is a terrible watermark algorithm, and vice versa, period. Verification algorithms are supposed to freak out if so much as a single bit has been twiddled. Watermark algorithms are supposed to be robust against common forms of tampering and re-encoding.
So, what's the deal?
1. It could be that "PC Authority" has been handed an NEC press release, and can't even handle the challenge of regurgitating it properly. In which case, any speculation based on the details of TFA is pointless, if TFA is so much commercial word salad.
2. It could also be that PC Authority is reading the NEC release more or less correctly; but the release was just blitzed out by some PR flack, and they lack the context. This is, in fact, an integrity verification technology, designed to work quickly on video streams, that will be included in some future standard, as an obscure convenience to future editors and producers and archivists who will have to deal with 10,000 hours of MPEG7 video in OMG-4k-Super-def-3D, and need to know, fast, if any of it is getting munged. It would be a super boring, highly specific part of the spec, of basically no interest to the general public; but it could be more or less true as described.
3. And here's the sinister conspiracy theory: Where do file integrity verification and DRM come together? If, and only if, planned devices are "default deny, play signed content only". If your Blu-ray2 player simply refused to play anything that isn't a wholly unaltered copy of a commercial release, the otherwise absurd(as noted above) notion that an integrity check algorithm can serve as a piracy deterrent becomes true... It wouldn't stop cammer kiddies from playing altered copies on general purpose PCs, if those are still alive; but making "blessed only" a condition of the licencing agreement for future STB-type devices would basically kill the unsophisticated pirated disk market(barring hardware hacks on specific devices, or really stupid mistakes in media design).
Cartridges are still mostly pointless.
Consider: If Flash is cheap enough to distribute games on, it is cheap enough to build large mass storage devices into consoles with. Further, since a console is a one-time purchase, and its internal mass storage is re-usable, while a catridge's Flash has to come right out of the margins of the game, it will always be the case, no matter how cheap Flash gets, that a console can have a much larger mass storage block than a cartridge can. Simple economic reality. Unless the singularity strikes, and the numbers are "Catridge: a million bazillion petabytes, too cheap to price" and "Console: a trillion bazillion petabytes, too cheap to price" this difference will always matter.
Cartridges don't really offer any anti-piracy advantage anymore: again, because you have to fit into the margin of the game being sold, you are pretty limited in what security measures you can bake into the cartridge itself. Clones will be pouring out of China and onto ebay within moments. Any moderately robust system-level DRM is going to be in the console. And, if optical media really scare you, it is still cheaper to come up with a slight variant(Blu-Ray disks with embedded RFIDs or something) than it is to ship a cartridge. Downloads, of course, offer trivial per-download uniqueness opportunities.
Now, that said, I do suspect that the institution of playing/executing from optical media will die out in fairly short order(except for "watch once" stuff like movies. Optical media offer shitty latency, long load times, and are often pretty noisy. HDDs are faster and more capacious. SSDs are faster still, and capacity is climbing. I strongly suspect that most people would rather have a "15 minute 'install' consisting of dumping a disk image to internal storage, possibly in a compressed form that the console offers hardware accelerated decompression for, followed by fast level loads forever" to "Instant play, and 90 second level loads forever". Or, with a little cleverness, somebody could probably whip up a hybrid model: "Instant play, initially a touch slow as the disk image is dumped in the background, followed by gradually increasing speed as more and more reads take place from fixed storage, rather than optical disk".
Downloads, of course, will go to internal fixed storage(or external mass storage devices) no matter what.
While your suggestion is architecturally sound, the problem is that it is either A) A gigantic pain in the ass. or B) Gives enormous power to the vendor, that they will almost certainly exploit.
In the case of Linux, "A" largely applies. A properly configured SELinux setup will give you most of what you are asking for; but those are enough of a pain to set up that very few people have them.
Given that explosives can toss thousands of fragments capable of causing modest surface lacerations a fair distance beyond the "instant death/horrible injury" radius, it probably isn't at all uncommon to have situations with a dozen or two casualties per explosion, some hundreds in the course of a bombardment, all with somewhere between "multiple" and "numerous" surface wounds. All of which need to be closed before they get infected, or start collecting sand and bugs, and so forth, but during which time the cream of the medical personnel, and their support staff, are busy trying to stabilize the seriously injured.
If you can, with the right technology, make it so that anybody who can handle a syringe full of glue, basic aseptic technique, and a flashlight can swiftly close superficial wounds, you can probably reduce the mean-time-to-treatment for the lightly to moderately wounded, reduce the number of gross, scar-tastic rushed suture jobs, and preserve the time and attention of the most skilled medics for the more serious injuries.
Assuming the light source can be shrunk and hardened(which given the impressive performance of modern solid state lighting and diode lasers is a definite possibility), you could probably get the whole system down to something that consists of a funny looking flashlight and some disposable tubes of glue, suitable for forward operating use by anybody who has had cursory training...
Heck, compared to Acrobat Reader, implementing the PDF spec in Javascript and decomposing the PDF into some combination of CSS-styled text, SVG, and canvas might even be faster...
Against pretty much any other PDF reader, though, it would probably be strictly a stunt.
What you say is true; but I suspect that Military collapses are substantially nastier and more common, for the following reasons:
First, getting locked into a downward trajectory is much easier when your historical expenditures have been military. In even modest quantities, unemployed ex-soldiers can be destabilizing. In large quantities, "government disbands army" turns into "army disbands government" with fair ease. Other sorts of expenditures can command considerable cultural clout, and maybe even manage a protest or two; but the military are pretty much the only ones with the power to say "No, actually, You are disbanded."
Second, militaries are some of the more tenuously profitable sectors of society. You have to be running a fairly cheap army, and have some weak, fat neighbors, for them to turn a direct profit. Not being invaded is valuable, to other sectors of society, if they are well developed; but the military specifically is a money pit unless conditions are excellent(and, because of point 1, they are hard to defund when conditions change).
I implemented a nonstandard extension to the protocol by stamping "RETURN TO SENDER" on the pigeon's head. So far, so good.
Peon? No.
Arrogant Prima-Donna/master of the universe type whose reckless movements of millions and billions have, until now, enjoyed a very good track record? Quite possibly.
Corporations are faceless and monolithic, in a sense; but it just isn't possible for an entity constructed of people to not start being ruled by personality(either when you get high enough, in a rigorously controlled entity; Or when you get close enough to the edges, as in a slack one).
While I don't know the explanation being given in this specific situation is anything but bunk, I think that it is totally plausible that there is a subset of traders who have a track record good enough to give them serious clout, adn ego problem big enough to convince them that checks, balances, and controls just crimp their talents, who are being permitted to operate largely without programmatic control.
Joe, assistant desk monkey, obviously isn't; but Tim the golden boy, with the Midas touch, widely rumored to be moving up to senior partner any day now, can probably get some of "that IT bullshit" relaxed...
Well, at least the carpets on Wall Street are generally more tasteful than the carpets in Vegas....
Not that there isn't some finance-clippy that pops up and asks "You appear to be tanking the Dow, would you like help with that?", or that people are allowed to do whatever stupid shit they want with the assets they have(the amount of stupid shit that people are allowed to do with assets that they don't have is somewhat concerning, however).
However, I am somewhat surprised that the guys who do UI design for financial systems don't design systems to make things like power-of-ten or million/billion errors very difficult. Having a 3 factors of 10 difference be just one key away(and phonetically not all that dissimilar) seems like a mess waiting to happen.
I've seen in doctor's offices(and I know pharmacists and pharmacy techs, especially ones where compounding and other tougher than "dispense stock pill" type activities go on get drilled hard on this) outlining acceptable and unacceptable notetaking protocols to reduce the risk of power-of-ten dosing errors(things like ".2 is wrong, there should always be a leading zero to clue you in to the decimal point, use 0.2.") Some of them are even domain specific conventions, specifically trading off other factors in favor of reducing the risk of error. In science, for instance, saying 2.0, or even 2.0000 if you have that much precision, instead of 2 is a good thing. It tells your reader how precise the value they are looking at is. In prescriptions and medical notes, "2.0" is dangerously close to "20", and is thus avoided.
One would think that, even if it meant making up arbitrary symbols, or using UI element sizes to convey magnitudes, or something, financial UIs would adopt a similar set of domain-specific tricks to head off the most common and dangerous errors.
I'm pretty sure that a programmatic(or manual, via some perverse tracing exercise) conversion from WOFF to TTF or equivalent would get just about any judge's "derivative work" sense tingling like mad...
"Real" security cameras actually vary pretty widely. An unimpressive number of them are of deeply undistinguished quality, pumping NTSC down long and dodgey coax runs, to indifferent capture cards(or old-school tape loop crap). Often weather hardened(which is one of those things that is more annoying than one might expect to DIY); but pretty miserable.
On the other hand, their are undeniably (expensive) offerings that offer contemporary-camcorder-or-better performance with real optics, good sensors, embedded logic that can intelligently prioritize between a lower quality video stream and higher quality stills of interesting or suspicious movements over channels with limited bandwidth. However, these can get really pricey really fast.
For whatever reason, the low end of the market seems to have substantially missed out on the absolutely plummeting costs of adequate sensors, optics, and single-board computers capable of tying them to a network.
Do we just pull the plug?
Broadcast "news" consumes some extraordinarily valuable spectrum, a resource fairly tightly limited by the laws of physics. We have historically suffered it to do so because of its perceived value to our democratic society. If, however, it cannot demonstrate that value, there are much better things we could be doing with that scarce and valuable spectrum...
Sometimes.
Some cameras do it, some cameras can be bludgeoned into doing it. Some snicker at the very idea.
It would have been a nice thing to have standardized... About 15 years ago.
On the plus side, the ability of font copyrights to threaten the freedom of people who don't care is pretty limited. As long as you are blessed with somewhat undiscerning tastes, Free fonts are already available for pretty much any character set you would have reason to use. Substituting one font for another might break some design major's little dream; but it isn't hard.
Those people for who fonts don't matter much can easily just stick to the free stuff, and those people who care enough to pay can pay. Not a big deal.
I'd assume that(in a rare moment of sanity for a content industry), they concluded that while WOFF won't do much to stop an adversary who cares, neither will any "OMG SEcure!!" DRM solution running on general purpose PC hardware. Not to mention the fact that anybody who actually wants to hoard expensive fonts on their PC already got a DVD full from a friend, or from bittorrent, or from Usenet, depending on technical proficiency and age.
If they insisted on some goofy DRM scheme, they would stop a minimal number of low-skill, mostly low-value infringers, and probably ensure years more chaos on the web-fonts scene. If they went with WOFF, they'll be able to ink some lucrative licencing deals with major sites(who are the ones that actually matter), and a few people will extract fonts and use them to print greeting cards. It's a net win. Frankly, given the historical strength of DRM systems, pretty much any compression/obfuscation/weird file location trick that requires joe user to download some sort of helper utility to get past is basically as strong, for practical purposes, as some advanced DRM system that joe user would need to download a crack for.
Since home users basically don't buy fonts anyway, they don't represent a terribly valuable market. If somebody big rips you off, you can sue the shit out of them.
Why "security" cameras(ie. webcam and some sort of TCP/IP speaking computer in the same box, often with goodies like 12/24 volt tolerant GPIO, POE, and weatherproof housings) have largely lagged; but the situation isn't nearly as dire if you are willing to do a touch of DIY.
Between the substantial increase in the number of ~$100 webcams that actually work with UVC drivers and have image quality that doesn't suck, and the availability of highly capable SBCs like the Shivaplug for not much more, you can get an ugly; but surprisingly functional, setup going for ~$300 and a little linux fiddling.
The other option with good price performance punch is taking advantage of all the DV video cameras that are being upgraded by their owners, or have shot tape-transport mechanisms. All but the ghastliest DV cams will outclass virtually all webcams in terms of optics and sensors, and they all connect via firewire in a standard way. A bit bulky; but if you go after stuff being dumped by "HD" enthusiasts, or hardware with broken tape parts, you can get fairly serious image quality for peanuts.
Either I was insufficiently clear, or you utterly failed to understand my reasoning.(given that you appear to have identified me as a social conservative, I'm going with the latter).
.xxx" option, visible on your monthly bill, from your ISP, fewer people will have access) this is a real concern for them.
No, sellers of pornography do not want to lure the unsuspecting(if nothing else, the shocked and horrified are unlikely to have a good conversion rate). However, and this is important, they want to make it easy for their customers to access them without interference from those around them.
Aside from those pushing for straight bans, most anti-porn crusaders advocate measures that make it more difficult to get porn without being noticed (correctly) inferring that that will, in a great many social contexts, have a strong chilling effect.
For instance, say this ".xxx" plan goes through(or the "CP80" one, which is a bit more comprehensive): it can be reasonably expected that ISPs will offer a "block *.xxx checkbox as a feature to attract worried parents and prudes of various stripes. If that comes to pass, an adult who wants access to internet porn will have to come up with some excuse, satisfactory to any other adults(ie. spouses, parents providing financial support, roommates) who have access to the bill, as to why they haven't activated that checkbox... That will be a lot of customers who want porn; but cannot reach it.
In a similar vein, imagine if it were mandated that the titles of all pay-per-view movies purchased in hotel rooms had to be itemized on the bill, rather than just the prices. That would likely have a substantially depressing effect on consumption of porn in hotel rooms; because it would be much harder to acquire without attracting spousal and/or employer scrutiny.
Yes, pornography sellers have no real interest in targeting the uninterested(barring the real bottom-feeding spammers, who are content with conversion rates under 1%); but they have a strong interest(possibly philosophical; but definitely financial) in making sure that their customers get to choose as freely of outside social pressure as possible. Measures that make that harder are a threat to them.
Since most avenues of access to porn are, at least potentially, subject to social exposure and social pressure(ie. if you have to go to a skeezy part of town, and risk being seen there, to get girlie mags, you are less likely to purchase them, if your hotel bill will reveal exactly what you watched, you are less likely to watch something salacious. If you have to request the "enable
These guys are definitely the devil's advocates; but http://www.cp80.org/ is a creepy pressure group, largely composed of slimy mormons(some of them with SCO ties...), advocating a very similar scheme. Everything on port 80 would have to be PG, with material that makes republican jesus cry relegated to other ports for easy blocking.
The lesson of Port 80 and firewalls. If the "feature" of .xxx is easy filtering, internet smut peddlers are going to be deeply apathetic about adopting it. What rational person makes their product harder for their customers to get to?
.coms and .nets will be forced to pick up .xxxs to match, to protect themselves from squatters, and peddlers with lousy URLs will pick up .xxxs in the hopes of grabbing some extra traffic. For the most part, though, porn sellers have no particular incentive to make themselves trivial to block.(They do have an incentive, except for the real bottom feeders, to not be perceived as resisting blocking software, or threatening innnocent children, because that could inspire a real backlash; but adults sneaking past imperfect filters are just fine by them.)
At best, if the prices are low enough, smut peddlers with high quality
Its analogous to the number of oddball applications and protocols that have moved toward port 80, by default or as a common option, because that port is generally minimally restricted compared to the more special-purpose ports.