Basically, it all boils down to a wild ass guess. They are guessing about allocation of brain for visual processing based on measurements of eye sockets in skulls and conjecture about evolutionary response to the environment.
The problem is that "configuration" exists... there is this utterly artificial distinction between configuration and code, the user and developer, because of languages like C where the skill jump from using to writing is obscene
Actually, I'd characterize the erosion of that as one of the problems as of late. E.g. complex facilities are considered ok when presented in a language like python. Because if you don't have to compile it, it's as easy as simple config files (oversimplification I admit), therefore why bother facilitating simple text files when they just need to navigate a sea of python modules that are also 'just text'.
Gnome shell excuses lack of configurability because you can just open up some javascript and/or css and tweak to your hearts content, and seem to think this is so good, they can skip configurability altogether. It's a nice ability to have, but to have it in lieu of traditional configuration for common popular options is madness.
I'll also add that the answer is *not* to pile on more layers to 'fix' complexity, codewise that gets even worse. That is the way MS has done (hence the exceeding fragile winmgmt service), which looks nice when it works, but breaks in mysterious ways...
I agree in theory, but at some point the overly complex and structured implementation is sufficiently infathomable that it hardly makes a practical difference whether it is open or not to a poor schmuck trying to script things in a modern linux distribution.
It's interesting, because I feel like the prevaling development ecosystem recognized and rightfully derided the mistakes MS was making. The prevailing ecosystem nowadays seems to think MS had it right all along (maybe it's the relative flood of people who 'program' for a living overwhelming the people who developed only as a means to the end of getting their job done).
Yes, the criticisms of Ubuntu are that they are largely fragmenting from the norm without a lot of coordination with community projects, not that they are making Linux 'too easy', that would be absurd. It is ironic, as one of the things I appreciated about it versus suse or fedora back in the day was how they made the most straightforward use of 'upstream' function whereas other distros added a lot of distro-specific fluff for management. I was out at Unity, and they continued on to Mir.
I will say that I am also disappointed at what the Linux desktop has been becoming. Ten years ago, Windows was an inscrutable mess of an OS under the covers. If you wanted to do nearly anything from a programming/scripting perspective in terms of managing the platform, you had to understand a ton of obscure stuff off of MSDN if it were possible at all. Linux was a lot more transparent and easy to understand how it worked at a glance. There were some limitations that were rough going from workstation/server to desktop/laptop market (e.g. making a wifi config without root privilege wasn't feasible, handling the acpi sleep button took some contortions, and controlling shutdown/restart similarly required explicit root authentication all the time).
Ten years later, MS has either replaced or hidden much of their overly complex stuff as they have advanced powershell (still a ways to go, and winmgmt is still a lot more fragile than it should be). Meanwhile, the typical Linux distro now has dconf, network manager, polkit, systemd, and worst of all dbus. Some more capability has come about, but it has become pretty inscrutable to the admins with a bourne shell scripting level of understanding. More advanced programmers appreciate some of the additional structure, but shell commands to script some capabilities are no longer easy (complex dbus-send commands, non-obvious configuration location and no longer human readable content) or impossible. The Linux desktop of today is growing a lot of the badness of the Windows desktop of a decade ago, and the Windows desktop is growing a lot of the goodness of the Linux desktop of a decade.
But they didn't just 'tack always-online' on as a form of DRM
I think this point is debatable. EA has shown time and time again they seem to only greenlight games that have an always-on aspect to them. I think if SimCity 5 *had* facilitated an offline experience, EA would have never approved it. Games get bonus points for *meaningful* use of online connectivity when applied, but at the end of the day DRM leaning motivations are almost certainly at the core of the design.
At least MPI PingPong over PCIe connected Mellanox adapters with a Sandy Bridge server is about the same as what I recall seeing last time I tested an HT attached infiniband adapter. Admittedly I have not measured HT connected interconnects in a few years now, so HT latencies could have improved, though certainly it seems fewer companies are eager to produce a product that requires AMD.
The only thing they haven't beaten yet is AMD's interconnect technology.
Actually, as of Nehalem Intel put forth QPI which bests Hypertransport. Now AMD did/does have some things like Infiniband cards that speak straight Hypertransport rather than doing PCIe, but most of that market got burned and PCIe caught up. Even if they could pursue straight QPI interconnect, PCIe is a safer bet with no downside anymore. Sure, there is theoretically more bandwidth to be had in HT/QPI world, but the long haul technologies can barely push 54 gigabit over a single link anyway, Even pushing dual link can be done with current PCIe with 16 lanes and the lanes go straight to processor package.
I'll argue that it is not. Here are a few ways in which someone might consider another option better: -It's heavier than some -It cannot detach screen and/or flip in such a way to get keyboard out of the way -The keyboard doesn't have a nipple mouse -It can't run Windows -It doesn't have as much ram as others -It doesn't have as fast a processor as others -It doesn't have as much battery life as others. -It doesn't support pen input
The truth is, there is no such thing as 'the' greatest laptop on the market today. Everyone has different preferences and priorities.
The problem is the execution. In my mind SecureBoot both restricts the user power *and* comes up short of a comprehensive solution. I can't imagine a comprehensive solution that wouldn't completely supersede SecureBoot strategy and allow user control.
I considered the 'application specific' passwords as just 'hard for human to remember password' and that divulging the password to the program meant I explicitly trust the program with access to my account (the big fat clue being no app specific configuration data other than a helpful descriptive tag).
I suppose they could enrich it by forbidding account management function, or scoping it more (e.g. mail versus jabber versus whatever as limited scope).
What I don't get is all the industry affinity for the Atom. It's horribly crippled (because Intel fears cannibalizing i3 sales) and AMD offers competitive options in the space without the platform restrictions Atom carries and a respectable GPU. I'd love to find some decent AMD tablets (because the i-series based ones are so expensive).
In the case of Adobe, their market was, mostly saturated. Switching to a rental model doesn't do much to erode future revenue opportunity since the unwilling parties probably were already not buying new copies, and Adobe really doesn't have that much of a vested interest beyond the explicit revenue on the offering.
MS does have a wider vested interest in Windows though. They want to monetize facilitating and curating an application ecosystem and services like skydrive. They need users. MS would probably do better to make their OS free as in beer. This is, incidently, more the Google model, who doesn't burden ChromeOS or Android with advertising or anything nor do they charge up front or periodically (yes, vendor usage gets complicated, but end users are free to do whatever) and instead it is a means to an end of getting users into their ecosystem.
MS is instead stuck in the mindset that each individual component must be considered on its own and be a profit center in and of itself, meanwhile Google threatens to eat their lunch more and more every day.
This is an 'all of the above' strategy. Assuming HP's entries into the market are respectable in the respective fields (which at least the Slate 7 does not seem to be), then no matter the 'winner' HP is equipped to support it.
UEFI can and has been booting Linux, Windows 7, Vista (with limitations), and OSX (significant limitations). If by 'UEFI', you mean 'SecureBoot', then on x86 platform, so far, I'm willing to believe that malware mitigation is at least part of it (though I question the efficacy), but I think it's giving them, mostly, the facility to lock out competitors on MS 'subsidized' devices like Surface.
Sadly, another false interpretation of the state of affairs.
Windows historically was a victim of both their poor security practices and their own success. They've actually done a lot in the Vista and up days to mitigate the need for users to 'run as administrator' to essenitally get anything done and acheive a fundamental security model roughly on par with modern Unix and Unix-like systems.
They are left with being a victim of their own success, malware authors target platforms of high popularity. Frankly, any system designed to empower the user has a damn near impossible time trying to distinguish behavior the user truly desired and intended from behavior the user was tricked into authorizing on behalf of a malware vendor (either saying yes to UAC/sudo prompt or just having their own account data compromised without even bothering to do things to the 'system' software). iOS takes the approach of forbidding any interpreted languages capable of loading more payloads and a whitelist of allowed applications to run, with the natural consequence of severely limiting what power users can 'legitimately' do with their device. In the Windows ecosystem, a tedious code blacklist approach has been adopted to try to mitigate things (aka 'anti-virus'). Formerly, anti-virus on OSX and Linux was about protecting windows systems from getting malware propogated to them, increasingly it is about blacklisting content that actually could run on OSX and Linux.
No, next week is Whitman stepping down and a new CEO. LG acquisition is the week *after* that. HP only changes their mind as often as they change leadership, so it takes a couple weeks for a complete about face on any given move.
One: I don't think they ever fully open sourced every last bit.
Two: Either way, the copyright holder can always do whatever they want. If some proprietary component got open sourced, the community can fork the specifically open sourced vintages with impunity, but the component can be closed again for future development.
Actually, his criticisms aren't about personal computing freedom and secureboot. His criticism is that crafting a PE executable for the express purposes of containing certificate data is utterly asinine. The correct response would be for MS to accomodate signing data in the more usual ways. I suspect a proposol to wrap the x509 data with a dummy ELF file would be met with similar rejection. The difference being no one would propose such a dumbass approach so we'd never find out, it's only thanks to MS dickishness that such a workaround would even be proposed.
Actually, his explicit concern is that it is a complete and total hack to create PE executables for the express purpose of being dumb containers for x509 certificate data.
MS already supports alternative signing schemes (e.g..PS1 scripts can have the ASN.1 content appended in Base64), so getting MS to support ASN.1 content without a PE executable seems like a much more sane solution for the problem Red Hat wants to 'solve'.
While others have already said 'this specific bit *IS* Microsoft's', I'll also say that UEFI is largely designed around MS conventions and requirements, just like BIOS specs were in the 1980s.
UEFI interfaces are defined in terms of Microsoft calling conventions and using a binary format defined by Microsoft. The behavior of the system clock is defined in terms of MS expectation of local timezone instead of GMT. All of these things are areas where MS has explicitly deviated from everyone else in the industry, and UEFI happens to follow MS on every last single deviation that presents itself.
At the core of UEFI, it's genesis was Intel trying to push an incompatible architecture (Itanium) and working closely with MS to assure there would be 'a' Windows running on it which was perceived to be the sole requirement to make the industry dump x86, even if it couldn't run x86 compiled applications. Thinks have evolved from there, but that relationship still defines most of what UEFI continues to be.
We are in a world where Linux at least has some sort of clout. The right answer is to exercise that to push forward a better model and not kowtow to MS security model. Even if you think the goal of securely measured and protected boot is good, MS as the root of trust is bad idea. I'd go further and say the mechanism's inability to measure/protect custom configuration and script content make it nearly a moot point. It's difficult to imagine a system that would be able to cover custom config and script content that would not at the same time render the 'SecureBoot' concept completely and utterly redundant.
The reality is, if you outsource your hosting to a single company, there will always be single points of failure.
There will be architectural ones, like root of trust expiring resulting in security framework taking everything down.
There will be bugs that can bite all of their instances in the same way at the same time.
There will be business realities like failing to pay electric bills, or collapsing, or simply closing down their hosting business for the sake of other business interests.
Ideally: -You must keep ownership of all data required to set up anywhere at all time. Even if you host nothing publicly yourself, you must assure all your data exists on storage that you own. -You either do not outsource your hosting (in which case your single point of failure business wise would take you out anyway) or else you outsource to financially independent companies. "Everything to EC2" is a huge mistake, just as much as "everything to azure" is a huge mistake. -Never trust a providers security promises beyond what they explicitly accept liability for. If you consider the potential risk to be "priceless", then you cannot host it. If you do know what your exposure is (e.g. you could be sued for 20 million, then only host it if the provider will assume liability to the tune of 20 million)
There is no reason their total lifetime earnings should exceed that of the grunt plus the cost of their education unless they are working more hours overall and then the increase should be relative to the number of extra hours.
An economy cannot work that way, sadly. If so, everyone would do the easiest job with the lowest investment required. Scarcity necessarily carves out different compensation levels for different work. If you are a burger flipper, the population of people who can do your job and would be willing to do so given no financial incentive to do something else just as well as you is nearly anyone. Meanwhile, you have jobs that demand you spend huge amounts of time away from home, which generally means no one would do it unless it were more profitable. You have highly skilled jobs that require a large upfront investment which is senseless to do if the net outcome is no better than flipping burgers. You have highly dangerous jobs that no one in their right mind would even conceive of doing (e.g. mining). You have disgusting jobs like sewer worker that no one would take unless they had to.
Sure, some relatively small population might undertake a career of highly skilled out of pure love for the craft, but not that many and certainly you won't find people lining up to volunteer for sewer worker duty unless circumstances make that a more valuable or available job than another.
Slashdot Mirror
Basically, it all boils down to a wild ass guess. They are guessing about allocation of brain for visual processing based on measurements of eye sockets in skulls and conjecture about evolutionary response to the environment.
The problem is that "configuration" exists... there is this utterly artificial distinction between configuration and code, the user and developer, because of languages like C where the skill jump from using to writing is obscene
Actually, I'd characterize the erosion of that as one of the problems as of late. E.g. complex facilities are considered ok when presented in a language like python. Because if you don't have to compile it, it's as easy as simple config files (oversimplification I admit), therefore why bother facilitating simple text files when they just need to navigate a sea of python modules that are also 'just text'.
Gnome shell excuses lack of configurability because you can just open up some javascript and/or css and tweak to your hearts content, and seem to think this is so good, they can skip configurability altogether. It's a nice ability to have, but to have it in lieu of traditional configuration for common popular options is madness.
I'll also add that the answer is *not* to pile on more layers to 'fix' complexity, codewise that gets even worse. That is the way MS has done (hence the exceeding fragile winmgmt service), which looks nice when it works, but breaks in mysterious ways...
I agree in theory, but at some point the overly complex and structured implementation is sufficiently infathomable that it hardly makes a practical difference whether it is open or not to a poor schmuck trying to script things in a modern linux distribution.
It's interesting, because I feel like the prevaling development ecosystem recognized and rightfully derided the mistakes MS was making. The prevailing ecosystem nowadays seems to think MS had it right all along (maybe it's the relative flood of people who 'program' for a living overwhelming the people who developed only as a means to the end of getting their job done).
Yes, the criticisms of Ubuntu are that they are largely fragmenting from the norm without a lot of coordination with community projects, not that they are making Linux 'too easy', that would be absurd. It is ironic, as one of the things I appreciated about it versus suse or fedora back in the day was how they made the most straightforward use of 'upstream' function whereas other distros added a lot of distro-specific fluff for management. I was out at Unity, and they continued on to Mir.
I will say that I am also disappointed at what the Linux desktop has been becoming. Ten years ago, Windows was an inscrutable mess of an OS under the covers. If you wanted to do nearly anything from a programming/scripting perspective in terms of managing the platform, you had to understand a ton of obscure stuff off of MSDN if it were possible at all. Linux was a lot more transparent and easy to understand how it worked at a glance. There were some limitations that were rough going from workstation/server to desktop/laptop market (e.g. making a wifi config without root privilege wasn't feasible, handling the acpi sleep button took some contortions, and controlling shutdown/restart similarly required explicit root authentication all the time).
Ten years later, MS has either replaced or hidden much of their overly complex stuff as they have advanced powershell (still a ways to go, and winmgmt is still a lot more fragile than it should be). Meanwhile, the typical Linux distro now has dconf, network manager, polkit, systemd, and worst of all dbus. Some more capability has come about, but it has become pretty inscrutable to the admins with a bourne shell scripting level of understanding. More advanced programmers appreciate some of the additional structure, but shell commands to script some capabilities are no longer easy (complex dbus-send commands, non-obvious configuration location and no longer human readable content) or impossible. The Linux desktop of today is growing a lot of the badness of the Windows desktop of a decade ago, and the Windows desktop is growing a lot of the goodness of the Linux desktop of a decade.
But they didn't just 'tack always-online' on as a form of DRM
I think this point is debatable. EA has shown time and time again they seem to only greenlight games that have an always-on aspect to them. I think if SimCity 5 *had* facilitated an offline experience, EA would have never approved it. Games get bonus points for *meaningful* use of online connectivity when applied, but at the end of the day DRM leaning motivations are almost certainly at the core of the design.
At least MPI PingPong over PCIe connected Mellanox adapters with a Sandy Bridge server is about the same as what I recall seeing last time I tested an HT attached infiniband adapter. Admittedly I have not measured HT connected interconnects in a few years now, so HT latencies could have improved, though certainly it seems fewer companies are eager to produce a product that requires AMD.
The only thing they haven't beaten yet is AMD's interconnect technology.
Actually, as of Nehalem Intel put forth QPI which bests Hypertransport. Now AMD did/does have some things like Infiniband cards that speak straight Hypertransport rather than doing PCIe, but most of that market got burned and PCIe caught up. Even if they could pursue straight QPI interconnect, PCIe is a safer bet with no downside anymore. Sure, there is theoretically more bandwidth to be had in HT/QPI world, but the long haul technologies can barely push 54 gigabit over a single link anyway, Even pushing dual link can be done with current PCIe with 16 lanes and the lanes go straight to processor package.
Big picture mode will invariably crash after a while is one I've particularly noticed.
They have worked various performance problems with their overlay as well.
I'll argue that it is not. Here are a few ways in which someone might consider another option better:
-It's heavier than some
-It cannot detach screen and/or flip in such a way to get keyboard out of the way
-The keyboard doesn't have a nipple mouse
-It can't run Windows
-It doesn't have as much ram as others
-It doesn't have as fast a processor as others
-It doesn't have as much battery life as others.
-It doesn't support pen input
The truth is, there is no such thing as 'the' greatest laptop on the market today. Everyone has different preferences and priorities.
The problem is the execution. In my mind SecureBoot both restricts the user power *and* comes up short of a comprehensive solution. I can't imagine a comprehensive solution that wouldn't completely supersede SecureBoot strategy and allow user control.
I considered the 'application specific' passwords as just 'hard for human to remember password' and that divulging the password to the program meant I explicitly trust the program with access to my account (the big fat clue being no app specific configuration data other than a helpful descriptive tag).
I suppose they could enrich it by forbidding account management function, or scoping it more (e.g. mail versus jabber versus whatever as limited scope).
What I don't get is all the industry affinity for the Atom. It's horribly crippled (because Intel fears cannibalizing i3 sales) and AMD offers competitive options in the space without the platform restrictions Atom carries and a respectable GPU. I'd love to find some decent AMD tablets (because the i-series based ones are so expensive).
Windows presents MS with a conundrum.
In the case of Adobe, their market was, mostly saturated. Switching to a rental model doesn't do much to erode future revenue opportunity since the unwilling parties probably were already not buying new copies, and Adobe really doesn't have that much of a vested interest beyond the explicit revenue on the offering.
MS does have a wider vested interest in Windows though. They want to monetize facilitating and curating an application ecosystem and services like skydrive. They need users. MS would probably do better to make their OS free as in beer. This is, incidently, more the Google model, who doesn't burden ChromeOS or Android with advertising or anything nor do they charge up front or periodically (yes, vendor usage gets complicated, but end users are free to do whatever) and instead it is a means to an end of getting users into their ecosystem.
MS is instead stuck in the mindset that each individual component must be considered on its own and be a profit center in and of itself, meanwhile Google threatens to eat their lunch more and more every day.
This is an 'all of the above' strategy. Assuming HP's entries into the market are respectable in the respective fields (which at least the Slate 7 does not seem to be), then no matter the 'winner' HP is equipped to support it.
UEFI can and has been booting Linux, Windows 7, Vista (with limitations), and OSX (significant limitations).
If by 'UEFI', you mean 'SecureBoot', then on x86 platform, so far, I'm willing to believe that malware mitigation is at least part of it (though I question the efficacy), but I think it's giving them, mostly, the facility to lock out competitors on MS 'subsidized' devices like Surface.
Sadly, another false interpretation of the state of affairs.
Windows historically was a victim of both their poor security practices and their own success. They've actually done a lot in the Vista and up days to mitigate the need for users to 'run as administrator' to essenitally get anything done and acheive a fundamental security model roughly on par with modern Unix and Unix-like systems.
They are left with being a victim of their own success, malware authors target platforms of high popularity. Frankly, any system designed to empower the user has a damn near impossible time trying to distinguish behavior the user truly desired and intended from behavior the user was tricked into authorizing on behalf of a malware vendor (either saying yes to UAC/sudo prompt or just having their own account data compromised without even bothering to do things to the 'system' software). iOS takes the approach of forbidding any interpreted languages capable of loading more payloads and a whitelist of allowed applications to run, with the natural consequence of severely limiting what power users can 'legitimately' do with their device. In the Windows ecosystem, a tedious code blacklist approach has been adopted to try to mitigate things (aka 'anti-virus'). Formerly, anti-virus on OSX and Linux was about protecting windows systems from getting malware propogated to them, increasingly it is about blacklisting content that actually could run on OSX and Linux.
No, next week is Whitman stepping down and a new CEO. LG acquisition is the week *after* that. HP only changes their mind as often as they change leadership, so it takes a couple weeks for a complete about face on any given move.
One: I don't think they ever fully open sourced every last bit.
Two: Either way, the copyright holder can always do whatever they want. If some proprietary component got open sourced, the community can fork the specifically open sourced vintages with impunity, but the component can be closed again for future development.
Actually, his criticisms aren't about personal computing freedom and secureboot. His criticism is that crafting a PE executable for the express purposes of containing certificate data is utterly asinine. The correct response would be for MS to accomodate signing data in the more usual ways. I suspect a proposol to wrap the x509 data with a dummy ELF file would be met with similar rejection. The difference being no one would propose such a dumbass approach so we'd never find out, it's only thanks to MS dickishness that such a workaround would even be proposed.
Actually, his explicit concern is that it is a complete and total hack to create PE executables for the express purpose of being dumb containers for x509 certificate data.
MS already supports alternative signing schemes (e.g. .PS1 scripts can have the ASN.1 content appended in Base64), so getting MS to support ASN.1 content without a PE executable seems like a much more sane solution for the problem Red Hat wants to 'solve'.
While others have already said 'this specific bit *IS* Microsoft's', I'll also say that UEFI is largely designed around MS conventions and requirements, just like BIOS specs were in the 1980s.
UEFI interfaces are defined in terms of Microsoft calling conventions and using a binary format defined by Microsoft. The behavior of the system clock is defined in terms of MS expectation of local timezone instead of GMT. All of these things are areas where MS has explicitly deviated from everyone else in the industry, and UEFI happens to follow MS on every last single deviation that presents itself.
At the core of UEFI, it's genesis was Intel trying to push an incompatible architecture (Itanium) and working closely with MS to assure there would be 'a' Windows running on it which was perceived to be the sole requirement to make the industry dump x86, even if it couldn't run x86 compiled applications. Thinks have evolved from there, but that relationship still defines most of what UEFI continues to be.
We are in a world where Linux at least has some sort of clout. The right answer is to exercise that to push forward a better model and not kowtow to MS security model. Even if you think the goal of securely measured and protected boot is good, MS as the root of trust is bad idea. I'd go further and say the mechanism's inability to measure/protect custom configuration and script content make it nearly a moot point. It's difficult to imagine a system that would be able to cover custom config and script content that would not at the same time render the 'SecureBoot' concept completely and utterly redundant.
The reality is, if you outsource your hosting to a single company, there will always be single points of failure.
There will be architectural ones, like root of trust expiring resulting in security framework taking everything down.
There will be bugs that can bite all of their instances in the same way at the same time.
There will be business realities like failing to pay electric bills, or collapsing, or simply closing down their hosting business for the sake of other business interests.
Ideally:
-You must keep ownership of all data required to set up anywhere at all time. Even if you host nothing publicly yourself, you must assure all your data exists on storage that you own.
-You either do not outsource your hosting (in which case your single point of failure business wise would take you out anyway) or else you outsource to financially independent companies. "Everything to EC2" is a huge mistake, just as much as "everything to azure" is a huge mistake.
-Never trust a providers security promises beyond what they explicitly accept liability for. If you consider the potential risk to be "priceless", then you cannot host it. If you do know what your exposure is (e.g. you could be sued for 20 million, then only host it if the provider will assume liability to the tune of 20 million)
There is no reason their total lifetime earnings should exceed that of the grunt plus the cost of their education unless they are working more hours overall and then the increase should be relative to the number of extra hours.
An economy cannot work that way, sadly. If so, everyone would do the easiest job with the lowest investment required. Scarcity necessarily carves out different compensation levels for different work. If you are a burger flipper, the population of people who can do your job and would be willing to do so given no financial incentive to do something else just as well as you is nearly anyone. Meanwhile, you have jobs that demand you spend huge amounts of time away from home, which generally means no one would do it unless it were more profitable. You have highly skilled jobs that require a large upfront investment which is senseless to do if the net outcome is no better than flipping burgers. You have highly dangerous jobs that no one in their right mind would even conceive of doing (e.g. mining). You have disgusting jobs like sewer worker that no one would take unless they had to. Sure, some relatively small population might undertake a career of highly skilled out of pure love for the craft, but not that many and certainly you won't find people lining up to volunteer for sewer worker duty unless circumstances make that a more valuable or available job than another.