One, for me, the choice to buy at a local store isn't about instant gratification, it's a scenario where I feel a need to browse and actually see what I'm buying. Plenty of stuff I buy online, and I am never really phased whether it would take two days or over a week. It's about the in-person evaluation.
Also, a *whole* lot of people seem to assume that if Amazon did maintain warehouses in every city as well stocked as their currently less numerous warehouses, that Amazon's prices would stay the same. Prices might have to drift up to cover the inherent costs associated with the model. Hell, even today maybe 10-15% of the time my brick and mortar store actually beats the best Amazon deal I can find for whatever reason.
wait_for_a_better_offer needs to warn the human of the condition, particularly trending that suggests a continuing drop. Business person may want to take a smaller loss in a scenario that indicates he will never be able to sell his inventory at cost and things will just get more severe over time. If they have Gadget 1.0 and Gadget 2.0 comes out with MSRP lower than Gadget 1.0 base cost but with undeniably better capability, then you better offload Gadget 1.0 before it's too late.
Taking FSF asssement at face value, the implication is that if you acquire hardware and software independent of each other and put them together, neither vendor is accountable for the others distribution model. If Asus releases a motherboard that requires signing but without linux, and Ubuntu distributes a bootloader that is signed and can work but cannot be modified and still work with that motherboard, then that falls outside the scope of Tivoization. If this is *not* true and somehow that arrangement would be construed as some sort of GPL3 violating collusion, then maybe Canonical can worry.
On the other hand, let's say the FSF gets their way and Canonical confidently ships Grub2 with GPL3 and things are signed and the world is happy. FSF likes this approach as it suggests that it legally forces OEMs to allow owner to disable SecureBoot even if the OEM wanted to force it on. This is overly optimistic. If an OEM really wanted to preload Ubuntu but wanted Secureboot locked in, they don't need to use Ubuntu's provided Grub, they could just use elilo or efilinux or whatever to load Ubuntu's platform.
This is the very question I keep posing, but no one seems to respond to. At what point is allowing owner-controlled code to execute 'ok' to qualify as adequate root kit deterrence?
I think it would go a looong way toward sanity for this to be clarified. If it is a matter of 'anything as fine as long as it makes drawing an obvious banner a first item so it can't be subtle', then I'm not overly bothered by it.
FYI, SC2 was also open sourced by the creators, can be found at sc2.sourceforge.net. In cases like this, it's a case where the creators that hold copyright over the work love the work itself. They see nearly zero opportunity to continue monetizing it, so they release the work to let it continue living. In many other cases, however, the copyright holder will refuse to do *anything* like this if there is no money to be made. Especially since a significant amount of money has been made in the console world reselling old games for new platforms, often with little to no work involved. In fact, a very significant barrage of requests intent on showing how loved the work is may backfire. While the intent may be to show a now unprofitable software is still well loved and warrants being set free to live anew, the business people note the potentially profitable interest that remains in a product that is already developed.
In the case of Blender, creditors observed what amounted to a failed commercial endeavor with nearly no hope of monetizing beyond the cost of support. They accepted a moderate amount of money to open source it rather than let it die. In this case, it was about a copyright holder with purely financial interests where open source was more profitable than not.
The teardown lists the chips and *potential* points of origin, a few which could not have been produced domestically. The proportion of chips that actually might have been sourced from US is actually pretty significant (more than I thought would have been possible). Of the components that might have been sourced from overseas or domestically, they have no idea how those parts were fulfilled (though at least for DIMMs, the SPD reveals the manufacturing plant if you understand the manufacturer specific location codes).
Not having a touch device, can't comment on how the interface changes, however:
of course it defaults to apps, since the Start Screen is all about listing and launching apps.
What I referred to was how I, in Win 7, will type a string in the 'search' and it will highlight "applications", "Files", and "control panel settings" (and probably other things) and present all results it finds, space allowing. In Win8, I wanted to do an update, I typed 'update' to search for windows update. It said no results. I stumbled over that, since "Windows Update" has always shown up there (in fact before Win 8 it showed up as an 'Application'). It took me a minute to realize I needed to click the "Settings Category" to get more results. When I pondered that a bit too long, the side bar even giving me the hint that 'Settings had 9 results' auto-hid, leaving the entirety of my screen real estate dedicated to the task of telling me it found nothing, and hiding the dozen or so hits it got out of site.
The premise that Metro is a forgone conclusion for the way a tablet/phone experience succeeds is a poor one. The market has not shown that to be true. I figure Win8 is their move to try to force the issue and gain some traction by effectively throwing the desktop market under the bus, since they don't have to worry about losing those to competitors by and large (Vista proved that in relatively modern history).
I've always hated hot corners, and Windows 8 demands they be used a lot. Both in the annoying 'mouse happened to go to a corner of a screen, do something without user 'clicking' anything' and the somewhat more forgiveable hidden UI element to click on and do things. The hotcorners aren't as bad as the 'activities' hot corner of Gnome 3, but I find it a questionable choice, *particularly* in the context of touch interfaces where hot corners don't even have their 'auto-find' aspect that people like so much.
The jarring difference between 'Metro UI' and Desktop applications is unfortunate. It's especially bad where you have two 'Internet Explorers" that behave very differently. OSX full-screen really did this right, the full-screen app management pretty much let's the apps be the same in windowed and fullscreen mode, and just tweak the navigation/task switching.
The search feature is 'hidden' (a common theme in the Metro interface) as there is no visual indication of it's availability. For a keyboard user, I consider this minor, but wonder how it plays in a tablet UI, where typically a text field is a cue for virtual keyboard. More annoying is that the search by default hides all but 'Apps' results, meaning you have to note the non-Apps categories count when searching. Worse yet, that summary will auto-hide, leading you with no UI indication of actual results that you actually want.
All that said, conceptually there is one thing I think is nice about Metro and Gnome 3, the general concept that when you do 'Start' or 'Activities', that the entire screen real estate is dedicated to the action. I kind of prefer Gnome 3's view over the Metro start (the former giving better consideration for task switching rather than just launching).
Turning point as in linux desktop being 'close enough' to a leading popular gaming console to enable desktop linux gaming for most mainstream games in the not too-distant future. If the likelihood of a linux desktop getting to run a game becomes roughly equivalent to xbox 360 getting a port, then I'd say that's pretty significant. If there is one company that might be inclined to make that happen *and* has the clout to do so, it would be Valve. It all depends on how the Linux and Steambox rumors pan out or not.
A lot of indie studios seem to do Linux, but more specificly... Unigine (OilRush) Frictional Games (Amnesia/Penumbra) Anything in the Humble Indie Bundles (in no small part due to Ryan Gordon's contribution). EVE Online (when I demoed it, it seemed like it was a half-assed wine based effort, but still it was some small explicit effort toward Linux).
If some of the buzz is to be believed (I'll believe it when I see it), Valve will be throwing their hat into the ring by year's end. If the various rumors come together, this actually could be a pretty big turning point in Linux gaming (a Steam 'console'), though it remains to be seen whether that would carry over to the Linux desktop in addition to whatever specialized setup the hypothetical steambox would employ.
So no crytek (despite a rumored CryEngine3 port somewhere in the universe), no Infinity Ward, no Blizzard, no EA (aside from flash games), no Bethesda, no Bioware, but there are some out there.
Linux is getting the benefit of more OpenGL oriented platforms establishing a firm foothold in the industry, making Linux support a far less significant additional workload.
To say the price difference is *solely* due to the US labor cost is disingenious. Apple TV has half the ram, a single core A5 SoC, and no amp. You could probably pick apart the design more, but I would say that most of the cost delta is how they specced it out, *not* where it is made. Google has over-speced it for now and their initial marketed value proposition. If they do have long term plans and recognize that it will flop until those plans are realized, then so be it.If they did this as an exercise to 'prove' that USA manfacturing is non-competitive, well that would be regretable.
If the scenario sold into is HDMI connected, then it's hard to argue that it won't be an apple TV competitor.
If you argue that it is going to be mostly connected directly to speakers and primarily a hub for music streaming, then it is competing against a myriad of bookshelf stereo systems, including those with Apple iPhone/iPod/iPad integration that would be analagous to the way Q extends Android device(s). I suppose you could say the novelty is the multi-master scenario being explicitly brought front and center, and maybe that's what they think is the key, I'd say they are being very optimistic. I'd also say that if that is specifically the use case envisioned, they way over-sized the hardware and priced themselves out (the bookshelf systems run in the low 100s even *with* included speakers, and we can't pretend it competes with the higher end receivers that are sold without speakers).
If they think this is going to usher in a new age of end-user extensibility atop their platform, then their competition is the HTPC environment. This is the only scenario where Google could be construed as competitively priced, but with lower feature set.
My impression was that TPM's relationship to SecureBoot was, well, non-existant. That discussions of TPM data sealing and SecureBoot are necessarily compeletly separate as neither infrastructure currently says much about the other...
The challenge being that for $299 you can get a comparably powerful x86 system, which is a lot more familiar and people are very comfortable with how open it is with an established market that is pretty solid.
The problem with this is that without Google pulling off a miracle making this some hot ticket item, the 'hobbyist' community isn't going to have access to this device in a worthwhile way. Will a generic Linux run on it with Xorg, will XBMC be able to offload video decode to support high def video? If all that pans out, you *still* are limiting your possibilities compared to the $300 PC given the inabliity to use windows or wine for some stuff you may really want to do.
Yes being made in the USA is cool and all but that doesn't justify three times the price over something like the Roku
While I share the head scratching over the market chances of the Q, I think this statement could be taken the wrong way. It's hard to say the extent that 'made in the USA' is a price liability when, spec-wise, the Q has far more expensive features than a Roku. Roku-like devices make use of much lower-end SoCs, lower ram, and don't bother including things like an amp. For Google's marketed purposes, a Roku device largely sufficies (except for the amp bit, but that making a difference seems to be wishful thinking on Google's part) and thus the Q is likely going to be DOA. The price delta is due at *least* in large part due to design choices other than 'made in the USA'.
This is the part where things seem very muddy. RH/Fedora seem to be along this line of thinking by pushing things down even to the module signing bit. However I wonder if even that is sufficient, what's to stop a rootkit from using KVM to start over again and ultimately land in the Windows environment with a 'fake' secure boot indication?
Canonical seems to be assuming they can boot unsigned kernel or at least a kernel that loads unsigned modules. Are they mistaken, will MS have Canonical keys revoked should they push a UEFI boot loader that can execute EFI binaries without verifying signatures?
What is materially different between the bootloader chaining and having a Linux system do KVM? Is it just matter of complexity of constructing a rootkit giving some subjective comfort? Is it some specific display behaviors on boot that would be obvious to the *user* that something is not acting the way they would expect it to? If the former, that seems pretty weak and useless as a strategy. If the latter, that would make sense and in which case chaining all-day long would be acceptable, so long as the entry point made some very visible indication of its existtance (e.g. a splash screen with the vendor logo on it for a second).
No, a few purists decry the implicit endorsement of closed binary by Ubuntu working to automatically lead a user to use the nVidia binary instead of the less featureful Nouveau drivers. They appreciate Fedora's stance, hoping that one day it will topple nVidia's thinking and result in a quality open source driver, but see players like Canonical ruining that opportunity to change reality for the better.
More pragmatic Linux users express a sentiment that they appreciate Ubuntu's efforts to more carefully consider and play in the reality of nvidia/fglrx type drivers needed for most consumers of those GPUs, since many Linux users can't realisticly sit around and hope for a miracle to use the hardware they want to buy now.
The parent and grandparent posts aren't the same mind or anything.
RedHat have tried to work with Vendors and educate folks about why this is a bad thing
The key word here being 'tried'. It really hasn't done anything to change the ubiquity of MP3 and h264. In that case, the momentum (mp3 is as good as the alternatives technically and has been around longer) or technical merit (h264 hs *no* unencumebered competition to acheive the same results) far offsets the ideology of 'free' for most of the world that we must live in. We aren't sufficiently better off in drivers due to RH's stance (fglrx and nvidia drivers are still pretty much required to extract value out of the respective hardware). What gains have been made have been mostly occured due to the inconvenience of the hardware makers (easier to just provide source than maintain shims) and not due to hard user demands. Practically speaking, you add rpm-fusion or download from the hardware vendor in Fedora. Ubuntu makes that easier, and while some might appreciate the purity, the common end user is simply annoyed that their hardware choices they are driven to make aren't as supported as they reasonably could be.
they've even undone this feat with kneeling towards Redmond (secureboot)
Actually, from a practical perspective, Ubuntu states a plan to not have signing as soon as possible, meaning user-compiled drivers are still viable. Fedora/RH plans to be signed all the way up the stack, meaning you will have more difficult time with self-compiled modules. It seems like Canonical's aversion to GRUB2 is due more to lack of due diligence on GPLv3 implications and not of some sort of MS agenda. I also wonder if MS will ultimately block Canonical's plan for lack of protection against the boot loader becoming a circumvention mechanism for Windows 'secure' boot.
All in all, I think Canonical on a technical level is losing it, some out of what seems to be desperation in chasing a business model now (ubuntu tv, now ubuntu phone) some out of hubris (some statements around unity's lack of configurability has been met with some strong hubris), but I don't think they are trying to close up the ecosystem and I don't think that Debian free and Red Hat's stance make a meaningful difference to the freedom of the components we use.
At least for this round, FSF is saying that Fedora is using Grub 2 and Ubuntu is not. Both will be able to do 'SecureBoot' without divulging private keys, even though the former is using a GPLv3 bootloader. In a hypothetical where someone ships Red Hat Enterprise Linux on a system, they say the onus is on the hardware/firmware vendor and *not* Red Hat to facilitate the load. For that reason, Canonical also would not be forced to release keys, just that Canonical preloaded systems must include a contingency for disabling or user loaded keys.
I could see a scenario where this could be weird: -Vendor ships an ostensibly Windows-only tablet, without option to replace keys or disable signing in firmware (I know, MS currently doesn't allow, but this is hypothetical) -Fedora can still be installed, the boot loader they ship is signed. -User has no signing key that would permit them to load without the approval of MS, and whatever costs are associated with that.
I presume from the writing that this is considered outside the scope of the anti-tivoization clause of GPLv3, which I now understand to specifically apply to preloaded GPLv3 software, and the software provider has no obligation to divulge signing secrets they use to work on the hardware vendor product. If all of x86 ecosystem one day was entirely MS signed and never pre-loaded Linux, would that prevent end-user freedom (a sort of holistic tivoization of an entire platform)?
Considering one of the focus areas of recent MS endeavours is to provide a richer baked-in shell (powershell), OSX has the same CLI credentials as the rest of the *nix world, it's silly at this point to say CLI is dead or dying.
I understand the sentiment that nothing should 'require' a GUI, but that's actually a pretty poor sentiment that can lead to an atrocious GUI experience. What you want is a clean GUI that enables what most of your users have to cope with. The CLI in a sense is freeing for the GUI developers. If you have advanced capability that is rarely going to be used by a small portion of the population, you can make it CLI only and keep the GUI clean. Similarly, there are some things the CLI just inherently does better, and any attempts to cater to some of those use cases in GUI is similarly going to ruin the GUI for the things that it currently does well.
I have dealt with software that held the philosophy of 'must provide all function and do it via GUI because CLI is dead'. The GUI had a labyrinth of menus and UI elements. Any attempt to do the most simple tasks prompted a 'wizard', to cover the 'well, 99% of the time, what you wanted to do was obvious, but to cover the corner cases, we are going to force you down a wizard that wants to make sure you want to do it now instead of later, when later you might want to do it, do you want to repeatedly do this same thing, while you are here, are there other things you want me to do this for, occasionally it might make sense for this to be combined with another usually unrelated task, do you want to do that this time? The data that will be processed, would you like the data exported for consumption elsewhere or thrown away?'. While it may be argued this particular piece of software was poorly designed and maybe it could've been done better, if you are trying to cater to all those scenarios trying to be *competitive* with a CLI strategy there aren't a lot of ways really to do that...
When I played with Win8 I thought it was a tad awkward on the desktop, and heard cries of 'but it's designed for tablet and would be an *awesome* tablet interface. I was left scratching my head, perfectly aware of all the tiny hotcorners and hidden UI features. Hotcorners are very much a mouse-type feature that is awkward for touch. And the 'right click' to bring up metro menus (which are somewhat similar to the lower right hotcorner but not really) I didn't see mapping to a tablet either... I *assumed* that at least the windows key would exist on a tablet, but the rest.....
Slashdot Mirror
One, for me, the choice to buy at a local store isn't about instant gratification, it's a scenario where I feel a need to browse and actually see what I'm buying. Plenty of stuff I buy online, and I am never really phased whether it would take two days or over a week. It's about the in-person evaluation.
Also, a *whole* lot of people seem to assume that if Amazon did maintain warehouses in every city as well stocked as their currently less numerous warehouses, that Amazon's prices would stay the same. Prices might have to drift up to cover the inherent costs associated with the model. Hell, even today maybe 10-15% of the time my brick and mortar store actually beats the best Amazon deal I can find for whatever reason.
wait_for_a_better_offer needs to warn the human of the condition, particularly trending that suggests a continuing drop. Business person may want to take a smaller loss in a scenario that indicates he will never be able to sell his inventory at cost and things will just get more severe over time. If they have Gadget 1.0 and Gadget 2.0 comes out with MSRP lower than Gadget 1.0 base cost but with undeniably better capability, then you better offload Gadget 1.0 before it's too late.
Either way you slice it....
Taking FSF asssement at face value, the implication is that if you acquire hardware and software independent of each other and put them together, neither vendor is accountable for the others distribution model. If Asus releases a motherboard that requires signing but without linux, and Ubuntu distributes a bootloader that is signed and can work but cannot be modified and still work with that motherboard, then that falls outside the scope of Tivoization. If this is *not* true and somehow that arrangement would be construed as some sort of GPL3 violating collusion, then maybe Canonical can worry.
On the other hand, let's say the FSF gets their way and Canonical confidently ships Grub2 with GPL3 and things are signed and the world is happy. FSF likes this approach as it suggests that it legally forces OEMs to allow owner to disable SecureBoot even if the OEM wanted to force it on. This is overly optimistic. If an OEM really wanted to preload Ubuntu but wanted Secureboot locked in, they don't need to use Ubuntu's provided Grub, they could just use elilo or efilinux or whatever to load Ubuntu's platform.
This is the very question I keep posing, but no one seems to respond to. At what point is allowing owner-controlled code to execute 'ok' to qualify as adequate root kit deterrence?
I think it would go a looong way toward sanity for this to be clarified. If it is a matter of 'anything as fine as long as it makes drawing an obvious banner a first item so it can't be subtle', then I'm not overly bothered by it.
FYI, SC2 was also open sourced by the creators, can be found at sc2.sourceforge.net. In cases like this, it's a case where the creators that hold copyright over the work love the work itself. They see nearly zero opportunity to continue monetizing it, so they release the work to let it continue living. In many other cases, however, the copyright holder will refuse to do *anything* like this if there is no money to be made. Especially since a significant amount of money has been made in the console world reselling old games for new platforms, often with little to no work involved. In fact, a very significant barrage of requests intent on showing how loved the work is may backfire. While the intent may be to show a now unprofitable software is still well loved and warrants being set free to live anew, the business people note the potentially profitable interest that remains in a product that is already developed.
In the case of Blender, creditors observed what amounted to a failed commercial endeavor with nearly no hope of monetizing beyond the cost of support. They accepted a moderate amount of money to open source it rather than let it die. In this case, it was about a copyright holder with purely financial interests where open source was more profitable than not.
The teardown lists the chips and *potential* points of origin, a few which could not have been produced domestically. The proportion of chips that actually might have been sourced from US is actually pretty significant (more than I thought would have been possible). Of the components that might have been sourced from overseas or domestically, they have no idea how those parts were fulfilled (though at least for DIMMs, the SPD reveals the manufacturing plant if you understand the manufacturer specific location codes).
What's the keyboard equivalent to bring up the menu that lets me click 'settings' so I can get to 'power'? That's the one I *really* want...
Not having a touch device, can't comment on how the interface changes, however:
of course it defaults to apps, since the Start Screen is all about listing and launching apps.
What I referred to was how I, in Win 7, will type a string in the 'search' and it will highlight "applications", "Files", and "control panel settings" (and probably other things) and present all results it finds, space allowing. In Win8, I wanted to do an update, I typed 'update' to search for windows update. It said no results. I stumbled over that, since "Windows Update" has always shown up there (in fact before Win 8 it showed up as an 'Application'). It took me a minute to realize I needed to click the "Settings Category" to get more results. When I pondered that a bit too long, the side bar even giving me the hint that 'Settings had 9 results' auto-hid, leaving the entirety of my screen real estate dedicated to the task of telling me it found nothing, and hiding the dozen or so hits it got out of site.
The premise that Metro is a forgone conclusion for the way a tablet/phone experience succeeds is a poor one. The market has not shown that to be true. I figure Win8 is their move to try to force the issue and gain some traction by effectively throwing the desktop market under the bus, since they don't have to worry about losing those to competitors by and large (Vista proved that in relatively modern history).
I've always hated hot corners, and Windows 8 demands they be used a lot. Both in the annoying 'mouse happened to go to a corner of a screen, do something without user 'clicking' anything' and the somewhat more forgiveable hidden UI element to click on and do things. The hotcorners aren't as bad as the 'activities' hot corner of Gnome 3, but I find it a questionable choice, *particularly* in the context of touch interfaces where hot corners don't even have their 'auto-find' aspect that people like so much.
The jarring difference between 'Metro UI' and Desktop applications is unfortunate. It's especially bad where you have two 'Internet Explorers" that behave very differently. OSX full-screen really did this right, the full-screen app management pretty much let's the apps be the same in windowed and fullscreen mode, and just tweak the navigation/task switching.
The search feature is 'hidden' (a common theme in the Metro interface) as there is no visual indication of it's availability. For a keyboard user, I consider this minor, but wonder how it plays in a tablet UI, where typically a text field is a cue for virtual keyboard. More annoying is that the search by default hides all but 'Apps' results, meaning you have to note the non-Apps categories count when searching. Worse yet, that summary will auto-hide, leading you with no UI indication of actual results that you actually want.
All that said, conceptually there is one thing I think is nice about Metro and Gnome 3, the general concept that when you do 'Start' or 'Activities', that the entire screen real estate is dedicated to the action. I kind of prefer Gnome 3's view over the Metro start (the former giving better consideration for task switching rather than just launching).
Turning point as in linux desktop being 'close enough' to a leading popular gaming console to enable desktop linux gaming for most mainstream games in the not too-distant future. If the likelihood of a linux desktop getting to run a game becomes roughly equivalent to xbox 360 getting a port, then I'd say that's pretty significant. If there is one company that might be inclined to make that happen *and* has the clout to do so, it would be Valve. It all depends on how the Linux and Steambox rumors pan out or not.
Unigine?
Frictional Games?
A lot of indie studios seem to do Linux, but more specificly...
Unigine (OilRush)
Frictional Games (Amnesia/Penumbra)
Anything in the Humble Indie Bundles (in no small part due to Ryan Gordon's contribution).
EVE Online (when I demoed it, it seemed like it was a half-assed wine based effort, but still it was some small explicit effort toward Linux).
If some of the buzz is to be believed (I'll believe it when I see it), Valve will be throwing their hat into the ring by year's end. If the various rumors come together, this actually could be a pretty big turning point in Linux gaming (a Steam 'console'), though it remains to be seen whether that would carry over to the Linux desktop in addition to whatever specialized setup the hypothetical steambox would employ.
So no crytek (despite a rumored CryEngine3 port somewhere in the universe), no Infinity Ward, no Blizzard, no EA (aside from flash games), no Bethesda, no Bioware, but there are some out there.
Linux is getting the benefit of more OpenGL oriented platforms establishing a firm foothold in the industry, making Linux support a far less significant additional workload.
To say the price difference is *solely* due to the US labor cost is disingenious. Apple TV has half the ram, a single core A5 SoC, and no amp. You could probably pick apart the design more, but I would say that most of the cost delta is how they specced it out, *not* where it is made. Google has over-speced it for now and their initial marketed value proposition. If they do have long term plans and recognize that it will flop until those plans are realized, then so be it.If they did this as an exercise to 'prove' that USA manfacturing is non-competitive, well that would be regretable.
If the scenario sold into is HDMI connected, then it's hard to argue that it won't be an apple TV competitor.
If you argue that it is going to be mostly connected directly to speakers and primarily a hub for music streaming, then it is competing against a myriad of bookshelf stereo systems, including those with Apple iPhone/iPod/iPad integration that would be analagous to the way Q extends Android device(s). I suppose you could say the novelty is the multi-master scenario being explicitly brought front and center, and maybe that's what they think is the key, I'd say they are being very optimistic. I'd also say that if that is specifically the use case envisioned, they way over-sized the hardware and priced themselves out (the bookshelf systems run in the low 100s even *with* included speakers, and we can't pretend it competes with the higher end receivers that are sold without speakers).
If they think this is going to usher in a new age of end-user extensibility atop their platform, then their competition is the HTPC environment. This is the only scenario where Google could be construed as competitively priced, but with lower feature set.
My impression was that TPM's relationship to SecureBoot was, well, non-existant. That discussions of TPM data sealing and SecureBoot are necessarily compeletly separate as neither infrastructure currently says much about the other...
Of course, they are charging three times the Apple competitor, the Apple TV....
The challenge being that for $299 you can get a comparably powerful x86 system, which is a lot more familiar and people are very comfortable with how open it is with an established market that is pretty solid.
The problem with this is that without Google pulling off a miracle making this some hot ticket item, the 'hobbyist' community isn't going to have access to this device in a worthwhile way. Will a generic Linux run on it with Xorg, will XBMC be able to offload video decode to support high def video? If all that pans out, you *still* are limiting your possibilities compared to the $300 PC given the inabliity to use windows or wine for some stuff you may really want to do.
Yes being made in the USA is cool and all but that doesn't justify three times the price over something like the Roku
While I share the head scratching over the market chances of the Q, I think this statement could be taken the wrong way. It's hard to say the extent that 'made in the USA' is a price liability when, spec-wise, the Q has far more expensive features than a Roku. Roku-like devices make use of much lower-end SoCs, lower ram, and don't bother including things like an amp. For Google's marketed purposes, a Roku device largely sufficies (except for the amp bit, but that making a difference seems to be wishful thinking on Google's part) and thus the Q is likely going to be DOA. The price delta is due at *least* in large part due to design choices other than 'made in the USA'.
chaining Can't happen
This is the part where things seem very muddy. RH/Fedora seem to be along this line of thinking by pushing things down even to the module signing bit. However I wonder if even that is sufficient, what's to stop a rootkit from using KVM to start over again and ultimately land in the Windows environment with a 'fake' secure boot indication?
Canonical seems to be assuming they can boot unsigned kernel or at least a kernel that loads unsigned modules. Are they mistaken, will MS have Canonical keys revoked should they push a UEFI boot loader that can execute EFI binaries without verifying signatures?
What is materially different between the bootloader chaining and having a Linux system do KVM? Is it just matter of complexity of constructing a rootkit giving some subjective comfort? Is it some specific display behaviors on boot that would be obvious to the *user* that something is not acting the way they would expect it to? If the former, that seems pretty weak and useless as a strategy. If the latter, that would make sense and in which case chaining all-day long would be acceptable, so long as the entry point made some very visible indication of its existtance (e.g. a splash screen with the vendor logo on it for a second).
No, a few purists decry the implicit endorsement of closed binary by Ubuntu working to automatically lead a user to use the nVidia binary instead of the less featureful Nouveau drivers. They appreciate Fedora's stance, hoping that one day it will topple nVidia's thinking and result in a quality open source driver, but see players like Canonical ruining that opportunity to change reality for the better.
More pragmatic Linux users express a sentiment that they appreciate Ubuntu's efforts to more carefully consider and play in the reality of nvidia/fglrx type drivers needed for most consumers of those GPUs, since many Linux users can't realisticly sit around and hope for a miracle to use the hardware they want to buy now.
The parent and grandparent posts aren't the same mind or anything.
RedHat have tried to work with Vendors and educate folks about why this is a bad thing
The key word here being 'tried'. It really hasn't done anything to change the ubiquity of MP3 and h264. In that case, the momentum (mp3 is as good as the alternatives technically and has been around longer) or technical merit (h264 hs *no* unencumebered competition to acheive the same results) far offsets the ideology of 'free' for most of the world that we must live in. We aren't sufficiently better off in drivers due to RH's stance (fglrx and nvidia drivers are still pretty much required to extract value out of the respective hardware). What gains have been made have been mostly occured due to the inconvenience of the hardware makers (easier to just provide source than maintain shims) and not due to hard user demands. Practically speaking, you add rpm-fusion or download from the hardware vendor in Fedora. Ubuntu makes that easier, and while some might appreciate the purity, the common end user is simply annoyed that their hardware choices they are driven to make aren't as supported as they reasonably could be.
they've even undone this feat with kneeling towards Redmond (secureboot)
Actually, from a practical perspective, Ubuntu states a plan to not have signing as soon as possible, meaning user-compiled drivers are still viable. Fedora/RH plans to be signed all the way up the stack, meaning you will have more difficult time with self-compiled modules. It seems like Canonical's aversion to GRUB2 is due more to lack of due diligence on GPLv3 implications and not of some sort of MS agenda. I also wonder if MS will ultimately block Canonical's plan for lack of protection against the boot loader becoming a circumvention mechanism for Windows 'secure' boot.
All in all, I think Canonical on a technical level is losing it, some out of what seems to be desperation in chasing a business model now (ubuntu tv, now ubuntu phone) some out of hubris (some statements around unity's lack of configurability has been met with some strong hubris), but I don't think they are trying to close up the ecosystem and I don't think that Debian free and Red Hat's stance make a meaningful difference to the freedom of the components we use.
At least for this round, FSF is saying that Fedora is using Grub 2 and Ubuntu is not. Both will be able to do 'SecureBoot' without divulging private keys, even though the former is using a GPLv3 bootloader. In a hypothetical where someone ships Red Hat Enterprise Linux on a system, they say the onus is on the hardware/firmware vendor and *not* Red Hat to facilitate the load. For that reason, Canonical also would not be forced to release keys, just that Canonical preloaded systems must include a contingency for disabling or user loaded keys.
I could see a scenario where this could be weird:
-Vendor ships an ostensibly Windows-only tablet, without option to replace keys or disable signing in firmware (I know, MS currently doesn't allow, but this is hypothetical)
-Fedora can still be installed, the boot loader they ship is signed.
-User has no signing key that would permit them to load without the approval of MS, and whatever costs are associated with that.
I presume from the writing that this is considered outside the scope of the anti-tivoization clause of GPLv3, which I now understand to specifically apply to preloaded GPLv3 software, and the software provider has no obligation to divulge signing secrets they use to work on the hardware vendor product. If all of x86 ecosystem one day was entirely MS signed and never pre-loaded Linux, would that prevent end-user freedom (a sort of holistic tivoization of an entire platform)?
Considering one of the focus areas of recent MS endeavours is to provide a richer baked-in shell (powershell), OSX has the same CLI credentials as the rest of the *nix world, it's silly at this point to say CLI is dead or dying.
I understand the sentiment that nothing should 'require' a GUI, but that's actually a pretty poor sentiment that can lead to an atrocious GUI experience. What you want is a clean GUI that enables what most of your users have to cope with. The CLI in a sense is freeing for the GUI developers. If you have advanced capability that is rarely going to be used by a small portion of the population, you can make it CLI only and keep the GUI clean. Similarly, there are some things the CLI just inherently does better, and any attempts to cater to some of those use cases in GUI is similarly going to ruin the GUI for the things that it currently does well.
I have dealt with software that held the philosophy of 'must provide all function and do it via GUI because CLI is dead'. The GUI had a labyrinth of menus and UI elements. Any attempt to do the most simple tasks prompted a 'wizard', to cover the 'well, 99% of the time, what you wanted to do was obvious, but to cover the corner cases, we are going to force you down a wizard that wants to make sure you want to do it now instead of later, when later you might want to do it, do you want to repeatedly do this same thing, while you are here, are there other things you want me to do this for, occasionally it might make sense for this to be combined with another usually unrelated task, do you want to do that this time? The data that will be processed, would you like the data exported for consumption elsewhere or thrown away?'. While it may be argued this particular piece of software was poorly designed and maybe it could've been done better, if you are trying to cater to all those scenarios trying to be *competitive* with a CLI strategy there aren't a lot of ways really to do that...
In this case "Update" is a "Settings" and the search only shows results for "Apps" until you click "Settings" to see the results in there.
When I played with Win8 I thought it was a tad awkward on the desktop, and heard cries of 'but it's designed for tablet and would be an *awesome* tablet interface. I was left scratching my head, perfectly aware of all the tiny hotcorners and hidden UI features. Hotcorners are very much a mouse-type feature that is awkward for touch. And the 'right click' to bring up metro menus (which are somewhat similar to the lower right hotcorner but not really) I didn't see mapping to a tablet either... I *assumed* that at least the windows key would exist on a tablet, but the rest.....