In the imaginary humans-are-rational-animals land, I'd agree with you.
Empirically, I'd strongly suspect that only relatively strong tugs of either appetite or repletion drive most people to either get a refill or discard a partially full cup. You just sort of suck on the straw until the fluid stops coming out, without thinking about it much, across a surprisingly large set of cup sizes.
The consumer psychology research people seem to consistently be able to pull hilarious stunts in changing the amounts people eat just by changing their cutlery, or using different sized plates, or changing whether or not the waiters clear away used dishes in an 'all-you-can-eat' scenario...
Any bets on how much hand-wringing about 'big government' 'nanny state' and 'paternalism' there will be now that Bloomberg is targeting large sodas rather than the terrifying marijuana, assassin of youth?
I honestly don't much care for either reefers or Fructose-Extreme Big-Gulp Edition; but I find it endlessly curious how mere time seems to change perception of given public health and public safety crusades. Some city tells smokers to do it outside, or restarauants to cut down on their trans-fats, on pain of some paltry fine and the editorialists are ready to tell you that fascism has finally come to America; but the ones that get hunted down by actual cops and sent to real jail? Apparently not a concern...
These 'ISP record' attempts are doubly pointless(in addition to the fact that they never indicate the slightest enthusiasm to actually offer something even approaching that speed, at any reasonable price, to any of their customers) because they typically are markedly slower than the already-standard high-speed interconnects that tie more central sites together.
If you are going to play pure speed-racer games, it really makes more sense to just have a set of categories based on medium(eg. 1km legacy POTS copper, 1km legacy coax, 1km single-mode fiber, 10km of each, etc.) There are real engineering challenges, and nontrivial advances, in the ability to shove more data over a link of a given nastiness; but 'records' based on unrealistic location stunts are just pointless(Telco B could just pull some fiber to a convenient school tomorrow and pull off a 'first-to-deliver 10,000mbps internet connection! and Telco C could just pull a few more strands and deliver twice that, and so on).
If you want to boast about how cool an ISP you are, you need speed, breadth, and price. If you want to boast about your super-sneaky transmission methods, just tell us about the medium, the distance, and the bitrate; but this nonsense is a pure stunt.
Oh, I'd be the last to disagree with the notion that terminal servers suck. I have the pleasure of fighting with several on behalf of a client.
My point was just(in response to hairyfeet's point that 'cloud' is 'thin client' all over again) that 'thin client' didn't actually change staffing patterns too much(slightly fewer desktop hardware monkeys, though not too many fewer because thin clients still have to be deployed, cabled, etc. just not drive-swapped as often); but an increase in junior server admins because terminal servers require all the babying of a desktop(with the additional quirks that come with desktop applications that aren't validated or supported to run multiple-concurrent-user on server OSes. Also, nothing brings out the true horribleness of common printer drivers quite like running in an environment where one user's print job can crash the spooler for everyone and you can't 'just reboot'...). A modest change in staffing patterns; but not actually as much of a reduction in staff as one would expect.
In a true 'cloud' scenario, though, most of what you are paying for(and enduring the risk/lag/bandwidth demand of offsite delivery for) is a reduction in application management. All those exchange admins, application server jockies, low-end DB guys, and so forth. In the (at present hypothetical) 'pure cloud' environment, you'd pretty much have nothing but the junior techs who deliver replacement computers to users who need them, and rebuild the stock image every six months(assuming you haven't gone full Chromebook or something, in which case that happens remotely as well) and the network guy who makes sure that LAN and WAN keep talking to one another...
While I expect that the data security/control concerns and UX deficiencies will be(if anything) worse with served-from-offsite-across-a-WAN-by-who-knows-who 'cloud' stuff than they were with served-from-our-datacenter-over-the-network-by-IT thin client stuff, it does seem likely to me that the impact on local IT staff will be different.
In my rather painful experiences with thin clients, the client hardware itself is practically bulletproof; but the terminal servers are more than touchy enough to make up for it. Each one combines the worst aspects of managing a desktop and a server and the whole exercise largely ends up saving you a modest amount of money on clients that you spend on server gear instead.
With 'cloud', however, the care and feeding of the application server is(at least in theory) also abstracted for you. User plugs in URL, user receives email. This generation often doesn't feature particularly 'thin' client hardware, running a contemporary web browser is far more intense than running an X11/RDP/ICA client; but you hide much more of the server complexity behind the vendor.
Unfortunately, I wasn't able to dig up anything on Samsung's website that provided me any clues. They have plenty of fab projects(including some sensor stuff) and various high-end measuring instruments and things; but the only references to this gamma-detector chip were stories about this cellphone. It'd be nice to find a datasheet and a digikey catalog number...
Why don't they call a 'radiation detector' by its name? It's a Geiger Counter. Way to make a name for something fall out of common usage...
Unless it contains a Geiger–Müller tube, it isn't much of a Geiger counter. Since this phone apparently contains a 'chip'(quite possibly just a CCD of some sort packaged so that most of the pxel hits can be assumed to be from high energy radiation, possibly something cleverer/more specialized), and since cramming a gas tube and high-voltage driver circuits into a cellphone is a pain, I'm guessing that there is nothing 'Geiger' about this counter...
When it comes to DRM peddlers, it isn't clear that that will be the choice.
.
Take a look at this 'Encrypted Media Extensions' proposal. Most of it just lays out a bunch of proposed javascript for requesting keys and passing them to a decryption module whose implementation is left vague(aside from the one, seemingly completely pointless, 'simple' case where a static, known, key is used for no obvious reason).
Now, have a look at the goodies: In the diagram at the beginning "CDM may use or defer to platform capabilities". And look also at section 8.5:
"Can I ensure the content key is protected without working with a content protection provider?"
"No. Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. Establishing a standard mechanism to support this is beyond the scope of HTML5 standards and should be deferred to specific user agent solutions. In addition, it is not something that fully open source browsers could natively support."
"Can a user agent protect the rendering path or protect the uncompressed content after decoding?"
"Yes, a user agent could use platform-specific capabilities to protect the rendering path."
So, unless you want to use the (seemingly entirely pointless) 'clear-key' case, this 'open' proposal boils down to a mixture of hot air and admissions that the good stuff would necessarily be implemented in closed (probably 'platform', which increasingly means 'cryptographically locked firmware') sections.
Can an OSS browser protect the key from the user? No. The specification explicitly says as much. And if the key is known and the cyphertext has been downloaded, the game is over. Period. So, right there, only closed (either binary-only or OSS-tivoized) implementations of key handling need apply. Can an OSS media rendering path protect the content from the user? No. The specification says as much. Only if media rendering is handed off to a binary or hardware/firmware component can that be provided.
Essentially, this proposal achieves the magnificent breakthrough of allowing a DRM streaming stack to use the browser's HTTP transfer mechanisms instead of those in the flash plugin. Key handling and media path? Those are either completely in the clear, or necessarily handed off to user-opaque sections.
Further, if you want to 'protect the media path' and ensure key security(even in a binary module) that implies such radical capabilities as protected memory regions that cannot be read by even the highest-privilege user-controlled processes(so, either a locked kernel, or an 'open' kernel under a locked hypervisor, PS3 linux style) as well as locked audio and video output paths, potentially locked cache areas on mass storage devices, and so forth.
Given this, it really comes down one of two ways: The first option is Tivoization: Yeah, it's 'open'; as in 'you could build the code and run it on some other hardware without a locked bootloader'. The second is some sort of TPM-style 'secure remote attestation' setup: It's 'open' as in "yes, you can modify it if you want; but remote hosts will refuse to deal with you if your attestation signatures come back nonstandard"(see also: Google/android DRM and what happens if you root your device...)
For good or ill, you can't make a piece of hardware serve two masters. If you want DRM to work, the platform must ultimately be controlled by the vendor, possibly with little sandbox areas for the user to amuse himself. If you want the user to control the platform, DRM cannot be more than a (perhaps frustrating, perhaps trivial) exercise in obfuscation and cat-and-mouse trickery.
It's not a terribly implausible conclusion, given the prior history of school attacks, and the fact that getting your hands on reasonably noxious(though generally not lethal except in quantity) toxins is pretty damn easy in agricultural areas, especially ones that haven't exactly had OSHA breathing down their necks...
Personally, I think that the hate that is felt towards DRM should be redirected towards proprietary DRM so we can break down platform lock-in and give the obscure platforms a chance with the average consumer.
Trouble is, there is nothing but 'Proprietary DRM'. If DRM is 'open' it becomes quite trivial to produce a tool that is conformant in all respects, except that it silently ignores the various customer-hostile features(like those little HDMI converter boxes, that aren't supposed to exist, that report themselves as an HDCP compliant sink on one side; but spit out an unencrypted video stream on the other).
Thus, we see either single-party proprietary DRM(eg. 'Fairplay' where only one company holds the keys) or multi-party proprietary DRM(eg. WMDRM, where you can license the DRM system; but only by agreeing to cripple your product in specific ways). There might be a hypothetical 'open' DRM, developed under some sort of OSS model; but for it to remotely work in practice, it would just be rolled out on tivoized platforms only. And what good is 'open' in that case?
I get this funny little feeling that "Ultraviolet" will come to occupy the same in history footnote as as "DIVX"(the phone-home video player attempt by Circuit City, not the codec), "Flexplay", and "DVD-D"...
I can't think of any ways that the 'consortium' behind it could make it any more of a user nightmare; but they seem to be doing their best.
Not just the jobs... Y'know why suburban children consider getting a driver's license a rite of passage? because it lets them get the fuck out of their suburb...
Even with a lousy HDD-of-no-particular-importance, I find that the big timesuck on boot isn't the booting; but the "getting all the browser pages and documents and whatnot back to where I left them(yes, even in applications that support session restore, you still run into issues like webpages that have decided to nuke the contents of form fields and such)" problem.
For that reason alone, the only real choice is between suspend-to-RAM and suspend-to-disk. With your contemporary soft-off PSU burning a few watts so that it can detect you waking it up, the difference between 'off' and 'suspend to RAM' is the relatively low, unless you have absolute piles of the stuff, cost of keeping your RAM refreshed.
There are definitely some offenders out there; but contemporary GPUs are increasingly good at cutting back when they aren't needed. Laptop OEMs won't touch an architecture if it will utterly toast the battery just to dump the desktop to the screen, and desktop cards(while their maximum draw seems to edge ever upward) have inherited a similarly parsimonious lower end.
IE, with the possible exception of the waning days of netscape, has been a pox on the internet. However, that said, any flavor of 'BEST IF VIEWED ON', be it IE6, or something technically superior, is the real pox upon the internet...
That bombs and guns are a product of science? Or is that part of their message - to destroy science with science? Fucking assholes.
The larger question is why they are targeting high tech, rather than mass tech...
These chaps are presumably anarchists, quite possibly with a primitivist or environmental radical vein. Why, then, are they focusing on assorted minor R&D projects that may, at some point in the future, assist The Man's technocratic hegemony over his fellow man and/or nature, rather than hitting the targets that contribute in an overwhelming way, right now?
"Nanotech"(a horribly fluid term that could arguably cover anything from the developments in advanced controlled-ratio copper/tin recrystalization technology that ushered in the bronze age, to the sci-fi grey goo) is certainly an area of ongoing research; but it's a small facet of advanced materials work. "Nuclear" is arguably rather more important, since it shows signs of being the big player if fossil fuels are constrained; but it is, as yet, a comparatively niche source of energy worldwide.
If you want to hit technocratic industrial capitalism where it hurts, why are you hitting fossil fuels? Sure, shooting Dr. Somebody who works on 'p-type selectively nanopatterned selenium bandgap films' in his unguarded office is easy; but its impact is pretty much confined to a 1% difference in efficiency of film-type photovoltaic materials a decade from now. A series of, say, catastrophic refinery fires, cutting 10 or 20 percent off any major industrialized nation's supply of petrochemicals... Now, that would show people what 'inelastic supply chain' really means...
That's what I don't understand about the anti-tech radicals. I don't agree with them, in either case; but I've never understood why they insist on picking at teeny little outgrowths at the very edge of science and technology R&D,,, So long as energy and feedstock chemicals are cheap, post-industrial-revolution society will outproduce your merry little band of revolutionaries so hard it will make your head spin. The only thing you'll change is (slightly) the amount spent on rentacops and the authorities attempting to shut you down.
The only way you would have even a hope of stopping technology in its tracks would be to hit its energy and vital-resource supply. The high tech frankenfood/nanobot/evil nuclear stuff is basically a sideshow compared to the mountains of coal, the rivers of oil, and the boring old steel and cement that keep the lights on and generate a surplus on which to run all the other activities.
isn't that a sign of lack of focus? the same that afflicts google now?
Unfortunately, detecting 'lack of focus' is much trickier than just looking at number of products/number of product areas. You both need to consider the possibility that the efforts are part of the same company largely in name(The badge above the door just says who built it or bought it, not uncommon for some largely-financial entity to have their sticker on a herd of operationally-independent companies), and that the efforts in multiple areas are in some way strategic. You also have to consider, of course, the distinct possibility that the company is running around like a chicken with its head cut off, throwing shit at the wall to see what sticks because they don't know what else to do...
In case of 'Facebook Phone', the optimists's reading would go something like this: Facebook already has a substantial investment(through its API, authentication services, and whatnot) in making it possible for 3rd parties to develop on its 'platform' so that it can more efficiently farm users. It also, because smartphones are a major and growing avenue for access to facebook, has an ongoing investment in developing high-quality phone UIs. A "Facebook Phone" project is really just a software project that is an outgrowth of their API/Auth/Payment efforts and their smartphone application efforts, along with some possible hardware spec tweaks(eg. camera, certain hard buttons to speed common facebook operations) and eventually paying an OEM to slap their sticker on it and get it out the door. Best case, it works. Worst case, most of the hard work can be immediately recycled into their existing 'platform' and 'smartphone app' development processes.
Pessimist's reading: Team Zuck has just IPOed at a ridiculous P/E, and it's a known fact that an increasing percentage of their traffic is coming from smartphones that are a bit small to show ads, and for which nobody but Apple and the carriers are making any money. Everybody knows that MOBILE IS THE FUTURE!!!!1!~, so Facebook has to show that they still have it by starting a crash, cargo-cult, attempt to replicate the success of the iPhone, and will flail around for a while, burn some money, and end up hiring HTC/Samsung/the low bidder to puke up a generic Android device with a really shit UI skin and a hardware 'like' button...
It's hard to imagine Facebook wanting their own OS, when they could more easily follow the 'android with the manufacturer's crap UI customizations on top' route. (Or do the same with whatever they are calling the twitching corpse of Maemo these days)
If(and it's kind of a big if) they did want their 'own' phone, rather than just shipping applications for other phones, I'd expect something along the lines of Amazon's effort. Minimal or nonexistent changes to the boring under-the-hood OS stuff, fully branded interface on top and a hardware layout suited to the dominant use cases desired by Facebook.
I wouldn't hold my breath on the 'developer phone' concept. If you just need basic emulation of screen sizes and OS versions, the SDKs for the respective products will do that in software right from the comfort of your workstation. If you need nitty-gritty testing-of-fucked-up-OpenGLES-edge-cases-on-Android-2.3-devices-with-Mali400-GPUs, you don't just need "a developer phone" you need either a huge stack of the things, or some PC-sized device containing a frankenstein's monster of ARM SoCs and peripherals from the past five years of phone development up to the present...
Given the economics of mass production, I suspect that 'developer phone' will continue to mean "the phone the developer owns" for small-timers, a stack of purchased or gifted by platform vendors handsets for the more serious players, along with emulator testing for more basic UI reflow and screen size stuff.
Because Kangaroos are pretty awesome(basically velociraptor sheep) I offer the following advice:
Y'know why vendors price their goods absurdly high in Australia? Because they can.
Y'know why they can? Because You, the government of Australia, let them.
Allow free importation of goods from the US and other markets and watch the vendor premiums for your mysterious island continent collapse. If Australians could simply buy from Adobe US, It'd be pretty difficult for Adobe to maintain a price premium...
As a developer and, more important to me, as somebody who truly enjoys hacking all I can say is please have mercy and let the end be quick. If that's how it's going to be then just slit my wrists or better yet my throat.
Thankfully, Apple's continued quest for thinness uber alles will soon produce a macbook air thin enough to cut the vital blood vessel(s) of your choice with. Of course, the firmware will be cryptographically restricted to only support cutting those arteries that Ives sees as aesthetically pleasing; but so it goes...
I suspect that, for large enterprises, 'security' as measured by 'how fucked it is after 6 months of clueless use by Joe Pornhound, his wife Jenny Incredimail, and his son Timmy Warez' is basically irrelevant.
Home users are basically helpless cattle; but they are also low value targets. If a drive-by download or a trivial trojan can't land some malware, they are safe. If it can, they are helpless.
Your enterprise, on the other hand, likely has the desktops locked down good and hard, firewall and IDS and people paid to care. However, they are a high value target. It is plausible, indeed quite likely, that they are getting actual human attention, from actually competent attackers, customized payloads, possibly even the honor of having one or more zero-days used against them. They are also much more likely to be running complex, web-facing applications, where the security may not rely on the underlying OS that much at all(how many sites have been exploited purely through more-or-less OS agnostic attacks on their CMS?)
In this scenario, it isn't entirely clear how much better Linux is than Windows(and, also, it isn't necessarily the case that the desktop OS matters nearly as much as the competence and vigilance of the chaps watching the network for funny business).
While the role of material culture certainly can't be ignored, this seems like a situation where ignoring the other cultural factors would be nuts.
In case anybody missed the memo, acculturation of the young in preparation for their expected vocational and relational behaviors is one of those things that has historically(and to the present day, in many cases) been taken very, very seriously. In not-at-all-uncommon scenarios like arranged marriage, caste or inherited job roles, indentured apprentices, and the like far more seriously than any sort of notion of individual autonomy or agency.
Even in cases where overt force isn't used, drilling of the young for their expected roles(and anxiety about perceived failures of that drilling) is intense. Look at all the shit that traditional moralists lose when some 'immoral' novelty hits the dating scene, or archive.org's wonderful collection of 50's and 60's mental hygiene videos instructing teenagers on how to correctly develop salubrious hobbies, prepare themselves to become a housewife, and ask Sally to the dance on Friday.
Point is, lest I ramble, if we base our estimate on the amount of effort put into molding people for their positions, kids have never had a damn clue. Indeed, many cultural arrangements have, implicitly or explicitly, operated on the premise that people simply weren't going to develop a clue. Apprenticing your kid to some trade, or arranging a good match for them, or ensuring that this student was groomed for college and that one for the coal mines was considered normal, responsible, behavior.
So, then, is the (alleged, CNN doesn't exactly demand confidence intervals...) crisis in behavior a pathology, or simply a predictable response to being presented with the alternatives of a situation with amorphous or even nonexistent guidelines and a expert-crafted narrative package with clear goals, feedback, etc.?
Slashdot Mirror
In the imaginary humans-are-rational-animals land, I'd agree with you.
Empirically, I'd strongly suspect that only relatively strong tugs of either appetite or repletion drive most people to either get a refill or discard a partially full cup. You just sort of suck on the straw until the fluid stops coming out, without thinking about it much, across a surprisingly large set of cup sizes.
The consumer psychology research people seem to consistently be able to pull hilarious stunts in changing the amounts people eat just by changing their cutlery, or using different sized plates, or changing whether or not the waiters clear away used dishes in an 'all-you-can-eat' scenario...
Any bets on how much hand-wringing about 'big government' 'nanny state' and 'paternalism' there will be now that Bloomberg is targeting large sodas rather than the terrifying marijuana, assassin of youth?
I honestly don't much care for either reefers or Fructose-Extreme Big-Gulp Edition; but I find it endlessly curious how mere time seems to change perception of given public health and public safety crusades. Some city tells smokers to do it outside, or restarauants to cut down on their trans-fats, on pain of some paltry fine and the editorialists are ready to tell you that fascism has finally come to America; but the ones that get hunted down by actual cops and sent to real jail? Apparently not a concern...
These 'ISP record' attempts are doubly pointless(in addition to the fact that they never indicate the slightest enthusiasm to actually offer something even approaching that speed, at any reasonable price, to any of their customers) because they typically are markedly slower than the already-standard high-speed interconnects that tie more central sites together.
If you are going to play pure speed-racer games, it really makes more sense to just have a set of categories based on medium(eg. 1km legacy POTS copper, 1km legacy coax, 1km single-mode fiber, 10km of each, etc.) There are real engineering challenges, and nontrivial advances, in the ability to shove more data over a link of a given nastiness; but 'records' based on unrealistic location stunts are just pointless(Telco B could just pull some fiber to a convenient school tomorrow and pull off a 'first-to-deliver 10,000mbps internet connection! and Telco C could just pull a few more strands and deliver twice that, and so on).
If you want to boast about how cool an ISP you are, you need speed, breadth, and price. If you want to boast about your super-sneaky transmission methods, just tell us about the medium, the distance, and the bitrate; but this nonsense is a pure stunt.
Oh, I'd be the last to disagree with the notion that terminal servers suck. I have the pleasure of fighting with several on behalf of a client.
My point was just(in response to hairyfeet's point that 'cloud' is 'thin client' all over again) that 'thin client' didn't actually change staffing patterns too much(slightly fewer desktop hardware monkeys, though not too many fewer because thin clients still have to be deployed, cabled, etc. just not drive-swapped as often); but an increase in junior server admins because terminal servers require all the babying of a desktop(with the additional quirks that come with desktop applications that aren't validated or supported to run multiple-concurrent-user on server OSes. Also, nothing brings out the true horribleness of common printer drivers quite like running in an environment where one user's print job can crash the spooler for everyone and you can't 'just reboot'...). A modest change in staffing patterns; but not actually as much of a reduction in staff as one would expect.
In a true 'cloud' scenario, though, most of what you are paying for(and enduring the risk/lag/bandwidth demand of offsite delivery for) is a reduction in application management. All those exchange admins, application server jockies, low-end DB guys, and so forth. In the (at present hypothetical) 'pure cloud' environment, you'd pretty much have nothing but the junior techs who deliver replacement computers to users who need them, and rebuild the stock image every six months(assuming you haven't gone full Chromebook or something, in which case that happens remotely as well) and the network guy who makes sure that LAN and WAN keep talking to one another...
While I expect that the data security/control concerns and UX deficiencies will be(if anything) worse with served-from-offsite-across-a-WAN-by-who-knows-who 'cloud' stuff than they were with served-from-our-datacenter-over-the-network-by-IT thin client stuff, it does seem likely to me that the impact on local IT staff will be different.
In my rather painful experiences with thin clients, the client hardware itself is practically bulletproof; but the terminal servers are more than touchy enough to make up for it. Each one combines the worst aspects of managing a desktop and a server and the whole exercise largely ends up saving you a modest amount of money on clients that you spend on server gear instead.
With 'cloud', however, the care and feeding of the application server is(at least in theory) also abstracted for you. User plugs in URL, user receives email. This generation often doesn't feature particularly 'thin' client hardware, running a contemporary web browser is far more intense than running an X11/RDP/ICA client; but you hide much more of the server complexity behind the vendor.
I get the impression that concepts like 'volume' start to get a little tricky once you pass the event horizon...
Impossible. As everybody skilled in economics knows, there are no low salaries, only lazy workers.
Unfortunately, I wasn't able to dig up anything on Samsung's website that provided me any clues. They have plenty of fab projects(including some sensor stuff) and various high-end measuring instruments and things; but the only references to this gamma-detector chip were stories about this cellphone. It'd be nice to find a datasheet and a digikey catalog number...
Why don't they call a 'radiation detector' by its name? It's a Geiger Counter. Way to make a name for something fall out of common usage...
Unless it contains a Geiger–Müller tube, it isn't much of a Geiger counter. Since this phone apparently contains a 'chip'(quite possibly just a CCD of some sort packaged so that most of the pxel hits can be assumed to be from high energy radiation, possibly something cleverer/more specialized), and since cramming a gas tube and high-voltage driver circuits into a cellphone is a pain, I'm guessing that there is nothing 'Geiger' about this counter...
When it comes to DRM peddlers, it isn't clear that that will be the choice.
. Take a look at this 'Encrypted Media Extensions' proposal. Most of it just lays out a bunch of proposed javascript for requesting keys and passing them to a decryption module whose implementation is left vague(aside from the one, seemingly completely pointless, 'simple' case where a static, known, key is used for no obvious reason).
Now, have a look at the goodies: In the diagram at the beginning "CDM may use or defer to platform capabilities". And look also at section 8.5:
"Can I ensure the content key is protected without working with a content protection provider?"
"No. Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. Establishing a standard mechanism to support this is beyond the scope of HTML5 standards and should be deferred to specific user agent solutions. In addition, it is not something that fully open source browsers could natively support."
"Can a user agent protect the rendering path or protect the uncompressed content after decoding?"
"Yes, a user agent could use platform-specific capabilities to protect the rendering path."
So, unless you want to use the (seemingly entirely pointless) 'clear-key' case, this 'open' proposal boils down to a mixture of hot air and admissions that the good stuff would necessarily be implemented in closed (probably 'platform', which increasingly means 'cryptographically locked firmware') sections.
Can an OSS browser protect the key from the user? No. The specification explicitly says as much. And if the key is known and the cyphertext has been downloaded, the game is over. Period. So, right there, only closed (either binary-only or OSS-tivoized) implementations of key handling need apply. Can an OSS media rendering path protect the content from the user? No. The specification says as much. Only if media rendering is handed off to a binary or hardware/firmware component can that be provided.
Essentially, this proposal achieves the magnificent breakthrough of allowing a DRM streaming stack to use the browser's HTTP transfer mechanisms instead of those in the flash plugin. Key handling and media path? Those are either completely in the clear, or necessarily handed off to user-opaque sections.
Further, if you want to 'protect the media path' and ensure key security(even in a binary module) that implies such radical capabilities as protected memory regions that cannot be read by even the highest-privilege user-controlled processes(so, either a locked kernel, or an 'open' kernel under a locked hypervisor, PS3 linux style) as well as locked audio and video output paths, potentially locked cache areas on mass storage devices, and so forth.
Given this, it really comes down one of two ways: The first option is Tivoization: Yeah, it's 'open'; as in 'you could build the code and run it on some other hardware without a locked bootloader'. The second is some sort of TPM-style 'secure remote attestation' setup: It's 'open' as in "yes, you can modify it if you want; but remote hosts will refuse to deal with you if your attestation signatures come back nonstandard"(see also: Google/android DRM and what happens if you root your device...)
For good or ill, you can't make a piece of hardware serve two masters. If you want DRM to work, the platform must ultimately be controlled by the vendor, possibly with little sandbox areas for the user to amuse himself. If you want the user to control the platform, DRM cannot be more than a (perhaps frustrating, perhaps trivial) exercise in obfuscation and cat-and-mouse trickery.
It's not a terribly implausible conclusion, given the prior history of school attacks, and the fact that getting your hands on reasonably noxious(though generally not lethal except in quantity) toxins is pretty damn easy in agricultural areas, especially ones that haven't exactly had OSHA breathing down their necks...
Personally, I think that the hate that is felt towards DRM should be redirected towards proprietary DRM so we can break down platform lock-in and give the obscure platforms a chance with the average consumer.
Trouble is, there is nothing but 'Proprietary DRM'. If DRM is 'open' it becomes quite trivial to produce a tool that is conformant in all respects, except that it silently ignores the various customer-hostile features(like those little HDMI converter boxes, that aren't supposed to exist, that report themselves as an HDCP compliant sink on one side; but spit out an unencrypted video stream on the other).
Thus, we see either single-party proprietary DRM(eg. 'Fairplay' where only one company holds the keys) or multi-party proprietary DRM(eg. WMDRM, where you can license the DRM system; but only by agreeing to cripple your product in specific ways). There might be a hypothetical 'open' DRM, developed under some sort of OSS model; but for it to remotely work in practice, it would just be rolled out on tivoized platforms only. And what good is 'open' in that case?
I get this funny little feeling that "Ultraviolet" will come to occupy the same in history footnote as as "DIVX"(the phone-home video player attempt by Circuit City, not the codec), "Flexplay", and "DVD-D"...
I can't think of any ways that the 'consortium' behind it could make it any more of a user nightmare; but they seem to be doing their best.
Not just the jobs... Y'know why suburban children consider getting a driver's license a rite of passage? because it lets them get the fuck out of their suburb...
Even with a lousy HDD-of-no-particular-importance, I find that the big timesuck on boot isn't the booting; but the "getting all the browser pages and documents and whatnot back to where I left them(yes, even in applications that support session restore, you still run into issues like webpages that have decided to nuke the contents of form fields and such)" problem.
For that reason alone, the only real choice is between suspend-to-RAM and suspend-to-disk. With your contemporary soft-off PSU burning a few watts so that it can detect you waking it up, the difference between 'off' and 'suspend to RAM' is the relatively low, unless you have absolute piles of the stuff, cost of keeping your RAM refreshed.
There are definitely some offenders out there; but contemporary GPUs are increasingly good at cutting back when they aren't needed. Laptop OEMs won't touch an architecture if it will utterly toast the battery just to dump the desktop to the screen, and desktop cards(while their maximum draw seems to edge ever upward) have inherited a similarly parsimonious lower end.
Yes on (a) no on (b).
IE, with the possible exception of the waning days of netscape, has been a pox on the internet. However, that said, any flavor of 'BEST IF VIEWED ON', be it IE6, or something technically superior, is the real pox upon the internet...
That bombs and guns are a product of science? Or is that part of their message - to destroy science with science? Fucking assholes.
The larger question is why they are targeting high tech, rather than mass tech...
These chaps are presumably anarchists, quite possibly with a primitivist or environmental radical vein. Why, then, are they focusing on assorted minor R&D projects that may, at some point in the future, assist The Man's technocratic hegemony over his fellow man and/or nature, rather than hitting the targets that contribute in an overwhelming way, right now?
"Nanotech"(a horribly fluid term that could arguably cover anything from the developments in advanced controlled-ratio copper/tin recrystalization technology that ushered in the bronze age, to the sci-fi grey goo) is certainly an area of ongoing research; but it's a small facet of advanced materials work. "Nuclear" is arguably rather more important, since it shows signs of being the big player if fossil fuels are constrained; but it is, as yet, a comparatively niche source of energy worldwide.
If you want to hit technocratic industrial capitalism where it hurts, why are you hitting fossil fuels? Sure, shooting Dr. Somebody who works on 'p-type selectively nanopatterned selenium bandgap films' in his unguarded office is easy; but its impact is pretty much confined to a 1% difference in efficiency of film-type photovoltaic materials a decade from now. A series of, say, catastrophic refinery fires, cutting 10 or 20 percent off any major industrialized nation's supply of petrochemicals... Now, that would show people what 'inelastic supply chain' really means...
That's what I don't understand about the anti-tech radicals. I don't agree with them, in either case; but I've never understood why they insist on picking at teeny little outgrowths at the very edge of science and technology R&D,,, So long as energy and feedstock chemicals are cheap, post-industrial-revolution society will outproduce your merry little band of revolutionaries so hard it will make your head spin. The only thing you'll change is (slightly) the amount spent on rentacops and the authorities attempting to shut you down.
The only way you would have even a hope of stopping technology in its tracks would be to hit its energy and vital-resource supply. The high tech frankenfood/nanobot/evil nuclear stuff is basically a sideshow compared to the mountains of coal, the rivers of oil, and the boring old steel and cement that keep the lights on and generate a surplus on which to run all the other activities.
isn't that a sign of lack of focus? the same that afflicts google now?
Unfortunately, detecting 'lack of focus' is much trickier than just looking at number of products/number of product areas. You both need to consider the possibility that the efforts are part of the same company largely in name(The badge above the door just says who built it or bought it, not uncommon for some largely-financial entity to have their sticker on a herd of operationally-independent companies), and that the efforts in multiple areas are in some way strategic. You also have to consider, of course, the distinct possibility that the company is running around like a chicken with its head cut off, throwing shit at the wall to see what sticks because they don't know what else to do...
In case of 'Facebook Phone', the optimists's reading would go something like this: Facebook already has a substantial investment(through its API, authentication services, and whatnot) in making it possible for 3rd parties to develop on its 'platform' so that it can more efficiently farm users. It also, because smartphones are a major and growing avenue for access to facebook, has an ongoing investment in developing high-quality phone UIs. A "Facebook Phone" project is really just a software project that is an outgrowth of their API/Auth/Payment efforts and their smartphone application efforts, along with some possible hardware spec tweaks(eg. camera, certain hard buttons to speed common facebook operations) and eventually paying an OEM to slap their sticker on it and get it out the door. Best case, it works. Worst case, most of the hard work can be immediately recycled into their existing 'platform' and 'smartphone app' development processes.
Pessimist's reading: Team Zuck has just IPOed at a ridiculous P/E, and it's a known fact that an increasing percentage of their traffic is coming from smartphones that are a bit small to show ads, and for which nobody but Apple and the carriers are making any money. Everybody knows that MOBILE IS THE FUTURE!!!!1!~, so Facebook has to show that they still have it by starting a crash, cargo-cult, attempt to replicate the success of the iPhone, and will flail around for a while, burn some money, and end up hiring HTC/Samsung/the low bidder to puke up a generic Android device with a really shit UI skin and a hardware 'like' button...
It's hard to imagine Facebook wanting their own OS, when they could more easily follow the 'android with the manufacturer's crap UI customizations on top' route. (Or do the same with whatever they are calling the twitching corpse of Maemo these days)
If(and it's kind of a big if) they did want their 'own' phone, rather than just shipping applications for other phones, I'd expect something along the lines of Amazon's effort. Minimal or nonexistent changes to the boring under-the-hood OS stuff, fully branded interface on top and a hardware layout suited to the dominant use cases desired by Facebook.
I wouldn't hold my breath on the 'developer phone' concept. If you just need basic emulation of screen sizes and OS versions, the SDKs for the respective products will do that in software right from the comfort of your workstation. If you need nitty-gritty testing-of-fucked-up-OpenGLES-edge-cases-on-Android-2.3-devices-with-Mali400-GPUs, you don't just need "a developer phone" you need either a huge stack of the things, or some PC-sized device containing a frankenstein's monster of ARM SoCs and peripherals from the past five years of phone development up to the present...
Given the economics of mass production, I suspect that 'developer phone' will continue to mean "the phone the developer owns" for small-timers, a stack of purchased or gifted by platform vendors handsets for the more serious players, along with emulator testing for more basic UI reflow and screen size stuff.
Because Kangaroos are pretty awesome(basically velociraptor sheep) I offer the following advice:
Y'know why vendors price their goods absurdly high in Australia? Because they can.
Y'know why they can? Because You, the government of Australia, let them.
Allow free importation of goods from the US and other markets and watch the vendor premiums for your mysterious island continent collapse. If Australians could simply buy from Adobe US, It'd be pretty difficult for Adobe to maintain a price premium...
Here endeth the lesson.
iPad is your future.
As a developer and, more important to me, as somebody who truly enjoys hacking all I can say is please have mercy and let the end be quick. If that's how it's going to be then just slit my wrists or better yet my throat.
Thankfully, Apple's continued quest for thinness uber alles will soon produce a macbook air thin enough to cut the vital blood vessel(s) of your choice with. Of course, the firmware will be cryptographically restricted to only support cutting those arteries that Ives sees as aesthetically pleasing; but so it goes...
I suspect that, for large enterprises, 'security' as measured by 'how fucked it is after 6 months of clueless use by Joe Pornhound, his wife Jenny Incredimail, and his son Timmy Warez' is basically irrelevant.
Home users are basically helpless cattle; but they are also low value targets. If a drive-by download or a trivial trojan can't land some malware, they are safe. If it can, they are helpless.
Your enterprise, on the other hand, likely has the desktops locked down good and hard, firewall and IDS and people paid to care. However, they are a high value target. It is plausible, indeed quite likely, that they are getting actual human attention, from actually competent attackers, customized payloads, possibly even the honor of having one or more zero-days used against them. They are also much more likely to be running complex, web-facing applications, where the security may not rely on the underlying OS that much at all(how many sites have been exploited purely through more-or-less OS agnostic attacks on their CMS?)
In this scenario, it isn't entirely clear how much better Linux is than Windows(and, also, it isn't necessarily the case that the desktop OS matters nearly as much as the competence and vigilance of the chaps watching the network for funny business).
You don't even need to generalize. One of the two authors is the guy who brought us the famous Stanford Prison Experiment...
While the role of material culture certainly can't be ignored, this seems like a situation where ignoring the other cultural factors would be nuts.
In case anybody missed the memo, acculturation of the young in preparation for their expected vocational and relational behaviors is one of those things that has historically(and to the present day, in many cases) been taken very, very seriously. In not-at-all-uncommon scenarios like arranged marriage, caste or inherited job roles, indentured apprentices, and the like far more seriously than any sort of notion of individual autonomy or agency.
Even in cases where overt force isn't used, drilling of the young for their expected roles(and anxiety about perceived failures of that drilling) is intense. Look at all the shit that traditional moralists lose when some 'immoral' novelty hits the dating scene, or archive.org's wonderful collection of 50's and 60's mental hygiene videos instructing teenagers on how to correctly develop salubrious hobbies, prepare themselves to become a housewife, and ask Sally to the dance on Friday.
Point is, lest I ramble, if we base our estimate on the amount of effort put into molding people for their positions, kids have never had a damn clue. Indeed, many cultural arrangements have, implicitly or explicitly, operated on the premise that people simply weren't going to develop a clue. Apprenticing your kid to some trade, or arranging a good match for them, or ensuring that this student was groomed for college and that one for the coal mines was considered normal, responsible, behavior.
So, then, is the (alleged, CNN doesn't exactly demand confidence intervals...) crisis in behavior a pathology, or simply a predictable response to being presented with the alternatives of a situation with amorphous or even nonexistent guidelines and a expert-crafted narrative package with clear goals, feedback, etc.?