I don't really see the point in comparing this device to a €139 device that sells millions.
It isn't comparing two different devices, it's showing two price points for the *exact same device*, with different software loads, both of which are OSS.
Of course, it oversimplifies things. On one hand you have the practical market evident price for a device already on sale. On the other hand, what is effectively 'MSRP' as suggested at announce. Rarely in this sort of situation does MSRP have a particularly strong correlation to the price it sells at. I wouldn't be surprised if pricing ended up being about even when things settle in.
Software is one of the products most amenable to offshoring. Cost savings of manufacturing in China has to be balanced against logistic and shipping costs that fluctuate over time, but software has no such factor to offset. It's also a market rife with potential IP controversy (with patents, it's hard to get started before getting smacked by a big player with tons of patents, without patents it may still be hard to get started as a big player rips off your work, copyright can get messy regardless of patent situation).
We don't need more work visas, good local developers are in no short supply.
That's a good one. Server operators in internal Enterprise IT has by and large not progressed beyond the "you must use browser X". Much of the complaints around buggy HTTP 1.1 revolve around buggy 'enterprise' products that no one with more sense than money would ever elect to use. Nothing stops those buggy implementations from being fixed. The same forces that you may need to rely upon for SPDY to get rolled out would have been the same forces that would have forced existing technology to be fixed.
Face it, the same people afflicted with broken HTTP 1.1 will either see SPDY blocked entirely or tortured into a hideous proxy. Maybe someone can explain how it is easier to get SPDY 'right' and therefore less likely to be bug ridden even coded by random kindergartners, but I've seen even the most straightforward concepts in the world completely screwed over by 'enterprise' IT vendors.
I have seen enough to be convinced there is more to SPDY than HTTP 1.1 enhancements can provide, but blind faith that people implementing it will implement the architecture correctly is not a good bet.
The other major difference being the Roku device is designed to not be 'rooted' and Raspberry Pi explicitly is a 'do whatever the hell you want' project, with the latter being cheaper. Adding Wifi and a IR sensor to this is a relative cakewalk and will end up in all probability being cheaper than a Roku in addition to being more open.
'lighter' oversimplifies things. I don't think Cinnamon is any 'lighter' than Gnome shell, it's largely the same compentry with a different UI philosophy applied. Similarly, KDE v. Gnome is a debatable topic as well.
Also, there is WindowMaker, blackbox/derivatives, lxde, e, and tons tons tons more out there too.
If i remember correcly http 1.1 does have some buggy implementation...SPDY might be a solution.
I'm willing to believe SPDY covers some cases that http 1.1 failed to get, *but* I fail to understand the argument that http 1.1 was just implemented buggy but SPDY will magically be better implemented by the same groups that have failed to get http 1.1 over all these years.
It's not that video content is fundamentally bad and must die off for a more benevelont industry to take hold, it's that the organizations that *currently* have a stranglehold on the industry does that. Every industry had some presence trying to prop up SOPA (ESA was for it until it was clear they needed to throw it under the bus after it showed no chance of making it). So 'games' aren't the answer because those 'publishers' did the exact same thing as the movies. Independent game developers do make it further than independent filmmakers I suppose...
It's not the medium, it's the topheavy publishing and producing organizations. Organizations that derive their power from resources required to make movies formerly being scarce. It's not the the writers, the actors, or really anyone putting in tangible contributions the consumer sees. It's the financiers, the ones who take the opportunity to suck profits from the consumers and try to cheat the talent as much as they can. They were and still are needed because they had the resource to begin with to fund production and deal with the logistics of getting it in the world. The barrier to entry has lowered quite a bit for some very notable independent video content to make it to the masses at relatively low cost, and this scares the crap out of people who see their leverage one day evaporating. There certainly is still a large gap between low-budget stuff posted to youtube and a high-production value movie on blu-ray, but there will come a day where the gap diminishes enough to not matter. That is, unless they gut the internet. It doesn't matter if the media is game, video, or music, either way it's all in how it's managed.
Datacenters with hundreds of rackmount servers that come with no OS on that will be destined for Linux. You may envision only the desktop deployment case where mass centralized Linux deployment is rare (though some corporations *do* end up with windows installed systems as the only thing they can source and want to churn out Linux too), but they are pushing for this sort of stuff on server systems as well, where many never see so much as a monitor connected or a human ever explicitly touch it other than placing it into a rack or chassis.
Linux they could run WINE and then access x86 applications that Windows 8 ARM cannot.
Wine on non-x86 can't run x86 Windows applications. Qemu in theory could... very slowly, but then again that can run on Windows too. They certainly want tight control over the ecosystem from top to bottom, but they are probably more afraid of consumers getting cozy with sideloading apps instead of the more profitable 'market' rather than Linux replacing their OS at this stage in the game. They are envious of Apple's model and desperately want that for themselves.
out-innovate on it as a community better then MS can (think kinect there).
I know many examples where OSS world has outmanuvered MS in terms of interesting work, but Kinect is a pretty bad example, nearly *all* the interesting work done to date has been atop MS platforms using MS SDK resources. The specific Kinect implementation has pretty much gone precisely as Microsoft could have hoped.
I do think Win8 ARM (if it *really* happens) is a very bad idea for MS strategically speaking. MS OS is nothing particularly special in and of itself and at this point is propped up by popular software support. They dilute that message and it could mean significant trouble.
If you're using a different bootloader to load Linux, Microsoft doesn't care if your system gets infected with a rootkit.
But, if a signed grub.efi exists that is *ostensibly* for linux loading but doesn't validate content it boots, then a malware could bundle that and use it to chain their malware to rootkit MS instead of linux It's not like grub can't execute arbitrary efi executables. Even if in theory the loader *could* only do linux kernels, then a malware author can still make a rootkit that has entry points that resemble a linux kernel but instead rootkits MS.
This is really the challenge in 'secure boot' in any innocuous way. You either lock it down so tight as to be anti-competitive and restrict the users, or you give users power but effectively give up the security benefit. The 'attacker' and 'legitimate user' are pretty well indistinguishable from each other.
I'm still unsure how mass deployments will go on systems equipped for secure boot. If you allow the service processor to disable the feature, then malware can use that same vector. If you require manual F1 setup action, then that's very anti-automation. I suppose you could only allow modification of that prior to POST exit (e.g. mass-deployers would have to leave the system off).
MS will sign other bootloaders, if someone will submit one, allowing Linux folks to take partial advantage of UEFI secure boot.
Don't see why MS should be required (or should perform) signature of other vendor content. I would assume they'd want to verify that the grub efi executable in turn validates payload, or else refuse to sign (after all, a signed open ended chainloader pretty well defeats the whole point of the mechanism).
MS is requiring user-configurable trust anchors on x86, which is exactly what Red Hat and Canonical asked for.
I had various revisions and acronyms and I honestly couldn't keep it all straight. Someone implied the first pass was MS trust anchor only and a subsequent pass was going to have configurable trust anchors (though how those trust anchors got installed was a point of some centention). The impression they gave was of a more reluctant MS for the third party trust anchors...
If they stick to a Cell design, they could almost certainly do it. If they deviate (seems likely, IBM and Toshiba are pretty well out of the game, though a process shrunk Cell 2 may still provide some boost, but even that design is already years old) that's going to be nearly impossible. Cross-arch emulation around the same generation is nearly impossible to do right.
I could see them making a dent, but not by WoA. WoA is MS trying to beat iOS and Android at their own respective games. If they instead recognize the form factor benefits but with AMD fusion, Atom, and Ivy Bridge CULV parts, then they could carve out a segment of that tablet segment.
I'd actually be kind of enthusiastic about this turn of events, *if* the Windows 8 x86 model is preserved where 'secure boot' is user controllable. The Android market despite *technically* propping up linux has created platforms that are not nearly as open-ended as the x86 market in terms of OS support.
I'm surprised MS is ostensibly going with the flow of ARM. MS *really* needs to reinforce x86 dominance or they pretty well lose any edge at all. I would have figured they'd do this design and push the manufacturers to pump out x86 tablets on CULV based platforms. MS is delusional and completely ignoring their relative lack of success in the phone market if they think sufficient numbers of people *explicitly* want Windows. Every time I say this someone comes out of the woodwork to say 'but I want it', and I accept some people do, but I think most people don't.
We are talking about if the manufacturer can legally put a sticker on the box, not their capability to install Windows 8.
I don't think so. Well, maybe capability, but *preload* I think requires it. I haven't reviewed the legalese to be fair, but I have been on teams where they had to make the call to go without WHQL, and basically I was told 'we can't preload if we don't get whql'.
Plain and simple, bullshit. It's a smoke screen. When malware manages to infect boot sector or equivalent, the attack comes from within the OS. Microsoft has every capability of treating writes to the boot area and EFI configuration as special and performing their own security checks to prevent 'unauthorized' writes to that area (going even beyond their permissions to also require signed code). It still regretably break things like Ubuntu's in-windows installer, but I would accept that wasn't their goal and I think the tradeoff is more defensible. Malware because the computer boots off removeable media 'accidentally' is pretty unlikely in EFI case (where OS forces the firmware to skip all that and go straight to boot loader unless user takes action). Attacks where someone maliciously mangles a system they have complete control of is not even a blip on the radar of malware (it may happen, but certainly nothing worth breaking an entire industry over). Incidentally, 'boot sector' type infections are relatively rare in the scheme of MS malware, most malware doesn't bother to infect the boot area, and still they are all over MS platforms.
Also keep in mind, MS is the *only* party who gets to control those keys. The users are not allowed to add new trusted keys. The hardware vendors are not allowed to put another vendor's keys instead of Microsoft's. The vendor *must* use MS key or no one's at all, they are forbidden from using the facility to the benefit of someone like Red Hat for example. The vendor gets in trouble with MS if they use the facility in a way that would prevent MS code from running. How the *hell* is that possibly considered right in the context of 'just improving their security'?
There are plenty of phone/tablet devices with measures to explicitly prevent other OSes from being put in place. Telling is that the 'OS' in PC world is considered software and in the phone/tablet world they have sucessfully got people calling it 'firmware'. This market is trying to blur the division between the platform and the OS to significant success. Every 'OS' vendor is expected to compete by getting a partner to release hardware around the OS. That means less room for startups or grass-roots OS creation, only certain Android hardware devices are a viable target.
That market is a plethora of monolithic devices with no configurability in hardware or software. This is a huge step back from the state of x86 systems where so much is socketed and mixing and matching is possible by the consumer thanks to rigorous standards in place to make it all possible. The 'primary' targeted OS runs as well as the primary OS on any of these devices, and while an alternative OS may fail to integrate properly with the device (Linux-Vendor ACPI was a sore spot for eternity, better now), the user can make the tradeoffs if they choose.
Core still has a GUI. Just because all you get is a cmd prompt to start, notepad can still work, for example.
I presume in WIndows 8 the leap is an actual text mode. So various things like console logging become feasible. MS has had EMS for a long time, but I'm guessing this is a bit more 'full-fledged'. Additionally, some server vendors have been wanting to ship low cost systems and omit any VGA chip whatsoever.
In practice I see even lightly used systems upgraded frequently. A few reasons:
-They get infested with malware and do not realize it. Their system starts getting slow and unreliable. They assume "it's just 'because it's old". Their assumption is 'proven' when a brand new system feels faster. -Increasing share of 'all-in-one'/netbooks. This means that if, say, the screen breaks, for most people the realistic answer is buy a whole new one. Similarly, if they get sold on *any* aspect of new technology, they refresh the whole thing. Better displays can actually bring along some processor and memory sales when not needed.
Slashdot Mirror
How big is your desk?
I don't really see the point in comparing this device to a €139 device that sells millions.
It isn't comparing two different devices, it's showing two price points for the *exact same device*, with different software loads, both of which are OSS.
Of course, it oversimplifies things. On one hand you have the practical market evident price for a device already on sale. On the other hand, what is effectively 'MSRP' as suggested at announce. Rarely in this sort of situation does MSRP have a particularly strong correlation to the price it sells at. I wouldn't be surprised if pricing ended up being about even when things settle in.
Software is one of the products most amenable to offshoring. Cost savings of manufacturing in China has to be balanced against logistic and shipping costs that fluctuate over time, but software has no such factor to offset. It's also a market rife with potential IP controversy (with patents, it's hard to get started before getting smacked by a big player with tons of patents, without patents it may still be hard to get started as a big player rips off your work, copyright can get messy regardless of patent situation).
We don't need more work visas, good local developers are in no short supply.
That's a good one. Server operators in internal Enterprise IT has by and large not progressed beyond the "you must use browser X". Much of the complaints around buggy HTTP 1.1 revolve around buggy 'enterprise' products that no one with more sense than money would ever elect to use. Nothing stops those buggy implementations from being fixed. The same forces that you may need to rely upon for SPDY to get rolled out would have been the same forces that would have forced existing technology to be fixed.
Face it, the same people afflicted with broken HTTP 1.1 will either see SPDY blocked entirely or tortured into a hideous proxy. Maybe someone can explain how it is easier to get SPDY 'right' and therefore less likely to be bug ridden even coded by random kindergartners, but I've seen even the most straightforward concepts in the world completely screwed over by 'enterprise' IT vendors.
I have seen enough to be convinced there is more to SPDY than HTTP 1.1 enhancements can provide, but blind faith that people implementing it will implement the architecture correctly is not a good bet.
The other major difference being the Roku device is designed to not be 'rooted' and Raspberry Pi explicitly is a 'do whatever the hell you want' project, with the latter being cheaper. Adding Wifi and a IR sensor to this is a relative cakewalk and will end up in all probability being cheaper than a Roku in addition to being more open.
Or, alternatively, a soft-3d render path which is really perceived as the goal that will be hit...
'lighter' oversimplifies things. I don't think Cinnamon is any 'lighter' than Gnome shell, it's largely the same compentry with a different UI philosophy applied. Similarly, KDE v. Gnome is a debatable topic as well.
Also, there is WindowMaker, blackbox/derivatives, lxde, e, and tons tons tons more out there too.
If i remember correcly http 1.1 does have some buggy implementation...SPDY might be a solution.
I'm willing to believe SPDY covers some cases that http 1.1 failed to get, *but* I fail to understand the argument that http 1.1 was just implemented buggy but SPDY will magically be better implemented by the same groups that have failed to get http 1.1 over all these years.
The ship's computer would always oblige when asked where to find a crewman.
"Computer, locate Ensign Smith"
"Ensign Smith is currently in Holodeck 3 running his porn program again"
It's not that video content is fundamentally bad and must die off for a more benevelont industry to take hold, it's that the organizations that *currently* have a stranglehold on the industry does that. Every industry had some presence trying to prop up SOPA (ESA was for it until it was clear they needed to throw it under the bus after it showed no chance of making it). So 'games' aren't the answer because those 'publishers' did the exact same thing as the movies. Independent game developers do make it further than independent filmmakers I suppose...
It's not the medium, it's the topheavy publishing and producing organizations. Organizations that derive their power from resources required to make movies formerly being scarce. It's not the the writers, the actors, or really anyone putting in tangible contributions the consumer sees. It's the financiers, the ones who take the opportunity to suck profits from the consumers and try to cheat the talent as much as they can. They were and still are needed because they had the resource to begin with to fund production and deal with the logistics of getting it in the world. The barrier to entry has lowered quite a bit for some very notable independent video content to make it to the masses at relatively low cost, and this scares the crap out of people who see their leverage one day evaporating. There certainly is still a large gap between low-budget stuff posted to youtube and a high-production value movie on blu-ray, but there will come a day where the gap diminishes enough to not matter. That is, unless they gut the internet. It doesn't matter if the media is game, video, or music, either way it's all in how it's managed.
Datacenters with hundreds of rackmount servers that come with no OS on that will be destined for Linux. You may envision only the desktop deployment case where mass centralized Linux deployment is rare (though some corporations *do* end up with windows installed systems as the only thing they can source and want to churn out Linux too), but they are pushing for this sort of stuff on server systems as well, where many never see so much as a monitor connected or a human ever explicitly touch it other than placing it into a rack or chassis.
I honestly don't see a compelling need to be able to turn it off remotely
If it comes disabled by default, sure. If enabled by default, need to mass deploy....
DisplayPort is compatible with DVI. You just need a passive cable to make the pinouts line up...
Linux they could run WINE and then access x86 applications that Windows 8 ARM cannot.
Wine on non-x86 can't run x86 Windows applications. Qemu in theory could... very slowly, but then again that can run on Windows too. They certainly want tight control over the ecosystem from top to bottom, but they are probably more afraid of consumers getting cozy with sideloading apps instead of the more profitable 'market' rather than Linux replacing their OS at this stage in the game. They are envious of Apple's model and desperately want that for themselves.
out-innovate on it as a community better then MS can (think kinect there).
I know many examples where OSS world has outmanuvered MS in terms of interesting work, but Kinect is a pretty bad example, nearly *all* the interesting work done to date has been atop MS platforms using MS SDK resources. The specific Kinect implementation has pretty much gone precisely as Microsoft could have hoped.
I do think Win8 ARM (if it *really* happens) is a very bad idea for MS strategically speaking. MS OS is nothing particularly special in and of itself and at this point is propped up by popular software support. They dilute that message and it could mean significant trouble.
If you're using a different bootloader to load Linux, Microsoft doesn't care if your system gets infected with a rootkit.
But, if a signed grub.efi exists that is *ostensibly* for linux loading but doesn't validate content it boots, then a malware could bundle that and use it to chain their malware to rootkit MS instead of linux It's not like grub can't execute arbitrary efi executables. Even if in theory the loader *could* only do linux kernels, then a malware author can still make a rootkit that has entry points that resemble a linux kernel but instead rootkits MS.
This is really the challenge in 'secure boot' in any innocuous way. You either lock it down so tight as to be anti-competitive and restrict the users, or you give users power but effectively give up the security benefit. The 'attacker' and 'legitimate user' are pretty well indistinguishable from each other.
I'm still unsure how mass deployments will go on systems equipped for secure boot. If you allow the service processor to disable the feature, then malware can use that same vector. If you require manual F1 setup action, then that's very anti-automation. I suppose you could only allow modification of that prior to POST exit (e.g. mass-deployers would have to leave the system off).
MS will sign other bootloaders, if someone will submit one, allowing Linux folks to take partial advantage of UEFI secure boot.
Don't see why MS should be required (or should perform) signature of other vendor content. I would assume they'd want to verify that the grub efi executable in turn validates payload, or else refuse to sign (after all, a signed open ended chainloader pretty well defeats the whole point of the mechanism).
MS is requiring user-configurable trust anchors on x86, which is exactly what Red Hat and Canonical asked for.
I had various revisions and acronyms and I honestly couldn't keep it all straight. Someone implied the first pass was MS trust anchor only and a subsequent pass was going to have configurable trust anchors (though how those trust anchors got installed was a point of some centention). The impression they gave was of a more reluctant MS for the third party trust anchors...
I would add to that restore PS2 compatibility.
If they stick to a Cell design, they could almost certainly do it. If they deviate (seems likely, IBM and Toshiba are pretty well out of the game, though a process shrunk Cell 2 may still provide some boost, but even that design is already years old) that's going to be nearly impossible. Cross-arch emulation around the same generation is nearly impossible to do right.
I could see them making a dent, but not by WoA. WoA is MS trying to beat iOS and Android at their own respective games. If they instead recognize the form factor benefits but with AMD fusion, Atom, and Ivy Bridge CULV parts, then they could carve out a segment of that tablet segment.
I'd actually be kind of enthusiastic about this turn of events, *if* the Windows 8 x86 model is preserved where 'secure boot' is user controllable. The Android market despite *technically* propping up linux has created platforms that are not nearly as open-ended as the x86 market in terms of OS support.
I'm surprised MS is ostensibly going with the flow of ARM. MS *really* needs to reinforce x86 dominance or they pretty well lose any edge at all. I would have figured they'd do this design and push the manufacturers to pump out x86 tablets on CULV based platforms. MS is delusional and completely ignoring their relative lack of success in the phone market if they think sufficient numbers of people *explicitly* want Windows. Every time I say this someone comes out of the woodwork to say 'but I want it', and I accept some people do, but I think most people don't.
We are talking about if the manufacturer can legally put a sticker on the box, not their capability to install Windows 8.
I don't think so. Well, maybe capability, but *preload* I think requires it. I haven't reviewed the legalese to be fair, but I have been on teams where they had to make the call to go without WHQL, and basically I was told 'we can't preload if we don't get whql'.
Plain and simple, bullshit. It's a smoke screen. When malware manages to infect boot sector or equivalent, the attack comes from within the OS. Microsoft has every capability of treating writes to the boot area and EFI configuration as special and performing their own security checks to prevent 'unauthorized' writes to that area (going even beyond their permissions to also require signed code). It still regretably break things like Ubuntu's in-windows installer, but I would accept that wasn't their goal and I think the tradeoff is more defensible. Malware because the computer boots off removeable media 'accidentally' is pretty unlikely in EFI case (where OS forces the firmware to skip all that and go straight to boot loader unless user takes action). Attacks where someone maliciously mangles a system they have complete control of is not even a blip on the radar of malware (it may happen, but certainly nothing worth breaking an entire industry over). Incidentally, 'boot sector' type infections are relatively rare in the scheme of MS malware, most malware doesn't bother to infect the boot area, and still they are all over MS platforms.
Also keep in mind, MS is the *only* party who gets to control those keys. The users are not allowed to add new trusted keys. The hardware vendors are not allowed to put another vendor's keys instead of Microsoft's. The vendor *must* use MS key or no one's at all, they are forbidden from using the facility to the benefit of someone like Red Hat for example. The vendor gets in trouble with MS if they use the facility in a way that would prevent MS code from running. How the *hell* is that possibly considered right in the context of 'just improving their security'?
There are plenty of phone/tablet devices with measures to explicitly prevent other OSes from being put in place. Telling is that the 'OS' in PC world is considered software and in the phone/tablet world they have sucessfully got people calling it 'firmware'. This market is trying to blur the division between the platform and the OS to significant success. Every 'OS' vendor is expected to compete by getting a partner to release hardware around the OS. That means less room for startups or grass-roots OS creation, only certain Android hardware devices are a viable target.
That market is a plethora of monolithic devices with no configurability in hardware or software. This is a huge step back from the state of x86 systems where so much is socketed and mixing and matching is possible by the consumer thanks to rigorous standards in place to make it all possible. The 'primary' targeted OS runs as well as the primary OS on any of these devices, and while an alternative OS may fail to integrate properly with the device (Linux-Vendor ACPI was a sore spot for eternity, better now), the user can make the tradeoffs if they choose.
I don't have to, I can love bash and a server ecosystem that has been CLI optimized for decades.
Core still has a GUI. Just because all you get is a cmd prompt to start, notepad can still work, for example.
I presume in WIndows 8 the leap is an actual text mode. So various things like console logging become feasible. MS has had EMS for a long time, but I'm guessing this is a bit more 'full-fledged'. Additionally, some server vendors have been wanting to ship low cost systems and omit any VGA chip whatsoever.
In practice I see even lightly used systems upgraded frequently. A few reasons:
-They get infested with malware and do not realize it. Their system starts getting slow and unreliable. They assume "it's just 'because it's old". Their assumption is 'proven' when a brand new system feels faster.
-Increasing share of 'all-in-one'/netbooks. This means that if, say, the screen breaks, for most people the realistic answer is buy a whole new one. Similarly, if they get sold on *any* aspect of new technology, they refresh the whole thing. Better displays can actually bring along some processor and memory sales when not needed.