Evaluating Elop with respect to good/bad done to Nokia: -Good: ditching Symbian -Bad: Picking MS, the last place platform -Bad: Focusing on higher end, North American market and neglecting Nokia's thriving global market.
Basically, the only measure by which Elop was 'good' would be microsoft's measurement of loyalty, willingness to sink his company for the sake of giving microsoft more of a chance.
Just imagine if Nokia had been the provider of things like Lumia 520 but with Android on it....
50 years ago, it was understandable that people were flinging account numbers back and forth because there wasn't much else feasible.
Now, probably 95% of transactions could easily be handled using a scheme where private key is used to sign transactions and the merchant is never ever privy to info that could be used multiple times.
If credit card companies did something to encourage point of sale equipment, internet merchants, and so on to work toward a scheme where private keys are kept private to the consumer rather than a loosely shared 'secret' scheme as it exists today...
Of course, the eye is not in a fixed location relative to the display. I can see more than 180 degrees without moving my head through solely moving my eyes.
A lot of people don't even like wearing watches, I can't imagine people going for full-on bracers.
Either things are going to stay pocketable or some sort of augmented reality solution are the things I could believe. If I were a betting man, I would bet that pocketable will continue to rule the day.
The problem is that some of the difficulties are by design. journalctl and systemctl are actually pretty straightforward to use. However, when things go off the rails, it's much harder to cope with than a system that retains plain text logs at the core. The argument that journalctl can give you plain text rings hollow when the tool is hard to get to (system had catastrophic failure and you are on the wrong end of a crappy connection but have a random system nearby that can peruse data. Lennart would call this a convoluted case, but it comes up surprisingly often. Meanwhile, having journal do plain text file alongside the binary file would neatly address a lot of the criticism without a whole lot of downside, but it's almost a religous objection to plain text logging rather than practical concerns keeping it soley the domain of syslog.
The old-school thinking was they failed to protect their intellectual property, and lost market share to competitors who copied their design
I don't think anyone significant believed that. Even IBM had long acknowledged that they thought the PC clones were the reason for the amount of volume they got. They knew long ago that thanks to that they got a decent chunk of a massive market instead of 100% of a pathetic small market (also, getting a decent chunk of change from all the clones that had to license a lot of patents, it's not like IBM let them 'steal', they licensed the relevant patents). IBM didn't plan that in the beginning, but they realized relatively early on that is was a blessing rather than a curse.
So one prominent example is a push to discard syslog, but at the same time rejecting any suggestion that perhaps it might be nice if the same plain text that journalctl can produce be produced as a matter of course without syslog assistance.
Yes, journalctl has more readily accessible nice filters and faster performance. The issue is that the vast majority of people didn't ever need them and made due with grep and friends. Yes it's not good stuff to build a high-end solution out of, but by the same token journalctl power is more complicated to use.
Getting early boot messages would have been a straightforward thing to do in syslog land, it was just that no one bothered. It was a good thing to add, but generally either things work fine and you don't really care much about the early boot logs, or it fails to get root fs going in which case the logs from that time won't make it to the root fs hosted journal anyway.
I don't like the linux distros of today because they are largely reimplementing much of what people ridiculed microsoft for in the 90s (binary configuration, binary logs, more complex messaging model). While it is true that generally the details of the implementation are defensibly better than microsoft did, the differences are largely academic to the vast majority of system administrators. Vast majority sees opaque binary blob that is useless without a very close match in distribution to provide tools to analyze. Even when things are humming along fine, things like dbus provide capability in a nearly impossible to explore manner. Even with all this complexity, my linux server experience is no more useful than it was 10 years ago from a managability standpoint, but I've had to jump through hoops to try to track the complexity as it emerged bit by bit without a lot of nice capability to come along for the ride.
Well, that and Lennart Poettering tends to not constructively respond to requests by users. He's done some very sophisticated work, but in many ways fails to understand the reality of most sysadmins. He wants all sysadmins to be able to handle the new capabilities rather than coddle them with plaintext log formats, even though over 95% of the audience doesn't *need* the stuff that is hard to do in a plaintext log format.
MS has done the same thing, system registry, event log, etc all act very similarly to the way systemd thinks things should be done. I know windows events are even worse in terms of format, but journal is a lot closer to windows events than it is to/var/log/messages.
So this is the point where we blindly assume our favorite 'evil' is at play and blame it for all of the problems without actual evidence one way or another?
This situation is likely to have been equally screwed up regardless of 'waterfall' vs. 'Agile'. In my experience, a team that will screw things up in this way will screw up no matter what nominal process is in place.
'No true scotsman' fallacy aside, there have been tons of practical advances in writing code.
Development and debug tools are light years better and a great deal of the code contributing to code size is reusable code that has been battle tested for a long time.
DNSSEC is mostly about having the will to bother to do it. In that respect, private industry has very little patience for anything that is hard to tie to bottom line. telnet is *still* widely in use in private companies because of the same deal.
This endeavor is very much complex by being bolted on to an existing complicated mess and trying to unify things. DNSSEC is amateur hour next to trying to corral all the health care cats. Still very much doable, but it has the misfortune of also being at the center of an extremely politicized situation. So prudent careful progression is cast aside in the name of needless urgency combined with some political shenanigans of a no-bid contract.
Does it do plugin or java web start? In the latter case, this doesn't factor in. Most things that I deal with that once were java plugin centric are now java webstart if they can't manage to pull it off in http/javascript/html
IPMI is a UDP protocol that has no direct relationship with a browser.
If you are instead implying that service processors frequently have web interfaces that employ java, at least with IBM the current state of affairs is java web start, which means no browser plugin even if it does use java. Even if they were, you don't have to worry about the vendors being too cheap to fork over the chump change.
Of the big, valuable, 'hot' companies, they all are producing increasingly dubious products.
Netflix loves to crash on me and keel off midstream ever so often. Then of course there are the outages. All this whilst their team brags about how awesome they are at availability.
Apple has had a litany of clock mistakes, unlock screen bypass, and of course the maps situation. I will say I don't use Apple products, so this is second hand experience.
Amazon... well about the only thing that seems to work really well is their own web presence. Their prime instant viewing does indeed make netflix look good by comparison. I will say I never used a Fire, so I can't attest to that. EC2 has pretty frequent outages that take down a bunch of big players. Lot's of people come out of the woodwork to white knight and say 'if the clients did it *right*, they wouldn't be so bothered', but it seems self evident that after all this time those major sites still can't figure it out, it's obviously not as viable model as some people desperately want to believe for some reason.
It's as if the entire industry has lost all patience and risks flaky, crappy behavior for the sake of releasing something that sounds exciting and novel.
You don't change the oil in your car? You've never had to replace a belt? Do you just let your car sit in a garage all the time?
Actually, not too terrible...
on
Boot To Zork
·
· Score: 1
Of those actually mucking about in implementations, the most common complaint I've heard is that vendor implementation are too inconsistent. I cannot imagine the same people making that call have had experience dealing with x86 BIOS, which is a landmine of inconsistency vendor to vendor. Should an option rom hookn int18? will hooking int19 be catastrophic? Does the vendor implement BBS or not? How should you leave the stack on exit to assure that subsequent boot devices are not hosed?
I'm not happy with everything in UEFI (mostly because it follows a lot of microsoft design guidance (executable format, ucs-2, microsoft function calling conventions), but the ability to associate functions with existing devices is exceptionally handy. For example in network device world, in BIOS the network card vendor would have to provide the full PXE implementation up to dhcp and tftp. In UEFI, the network card vendor is best off publishing only the low level interface, and then code from other people can hook ip stacks that are independent of the network hardware. It means that switching network vendors leads to less inconsistency in network boot behavior.
Another thing that's nice is the standardized interface between OS and firmware. The EFI variable space is nice. It falls short though of adequately supporting configuration, meaning it retains proprietary tools to configure firmware from OS that vary vendor to vendor.
You will get two answers, depending on reader interpretation of 'rock star'.
One connotation is that they are high maintenance douchebags, that might or might not be competent too. This comes from the fact that *usually* the only way such douchebags stay employed is having great talent. By no means is this sort of person generally required. If you have a talented person in this category, you will be screwed when they go away or stop caring, because no one will be able to do anything with their code.
The other connotation is that they are a great developer. These people are greatly valuable. You may still have retention problems due to competing offers. They can churn through problems easily and assume a leadership role. They can work with people. If someone is in this category, losing them is still a great loss, but not nearly as fatal as those who assume themselves too good to work with others.
For one, the Linux kernel probably has the fastest development rate than any other kernel out there.
For another, given that it is the kernel, I think it is good for people mucking about with it to be scared. There should be *very* compelling reason to change the status quo in kernel land before any attempt is made.
In therms of a flame ware improving a product, I think it is often better than the alternative. It's better to hash it all out, for better or worse, than sidestep discussion for fear of hurt feelings. I've seen the alternative, projects where people are more politicking than getting work done. Conversation fleshed out by more sycophants than meaningful discussion. Passive aggressive discussions where you just aren't sure what is really under the surface.
Powershell is an oddball that is part python, part perl, and part bash, with heavy amounts of.Net thrown in. While very potent, that makes for some... extraordinarily peculiar constructs and surprisingly ambiguous reaction to certain pipeline flows (e.g. the datatype of seomthing returned being an array type or a singelton type based on number of results can have disatrous results when code tested with just one match suddenly hits an array, or vice versa).
Things like perl/python are not interactive shells for good reason, and bash is a terrible syntax for efficient complex programs for good reason.
I will give them the pipeline operator is a handy shorthand for an iterator operation however.
An example of 'NIH' After years of people pretty much wanting a damn bourne shell, they... made something totally different. People wanted nicely interopable ssh access, they got the hellish monster of powershell remoting over WebServices.
Now if you are a *pure* MS shop, then *anything* but cmd was a great help and the extraordinarily complex nasty crap underlying all their remoting and WMI is tucked away so you can't see just how much it is terrible.
Seriously, in their efforts to be more 'friendly' in a mixed datacenter, they decide the answer is the world would be so much easier if they can continue to ignore decades of established behaviors of others and just get those competitors to simply change their mind.
Carriers will treat it as a smartphone. When the central point of the OS as evidenced by the name is full blown web browsing, it's going to be treated as a peer to android/ios devices, period.
With Android as it is in Jelly Bean, firefox os has a very uphill battle ahead of it. If it managed to release prior to ICS, *maybe* it could have had an in, but as it stands Android is just too capable and clean. That's not to say something better can be done or that people like me nervous about just *how* much control Google gets to exert would be interested, but I'm not going to assume for a second that constitutes enough people for a viable mobile platform.
Can you tell us how it's easy to get around Secure Boot?
Well, that rootkit had to go through quite a few hoops to avoid detection. A different set of hoops are in order here.
It'd be hard to hide a MS hypervisor because they are so bloated, but a linux hypervisor can be constructed in under 24 megabytes, which is essentially a rounding error in the typical EFI boot partition as created by MS. So the rootkit is a linux bootloader, kernel, and initrd with qemu and such. The rootkit has to fake a *lot* more stuff to fool extremely comprehensive security software (e.g. if it bothers to look at every single device in great detail, then it would have to emulate every single device). This hinges mostly on how comprehensive the security software is expected to be (and whether that security suite compromises to tolerate 'P2V' type changes) and how dedicated the malware authors are (history has shown them to be... extremely dedicated).
The concept is solid enough, but the implementation is flawed. As a consequence of mandating that the factory burns in the signing key, it pretty much forces MS to sign competitor payload or be seen as anti-competitive. This means your Microsoft install implicitly trusts software from Red Hat, Canonincal, VMware, Attachmate, and really anyone else who may enter the ring. There is no way that MS is providing adequate auditing to assure those paths aren't vulnerable and it shouldn't have to. Because it must be installed into firmware before an OS touches it, there is also *no* reasonable opportunity to provide any assurance of customer provided content like configuration.
As to that root kit you mentioned, MS could have protected itself from that without SecureBoot or any boot signing. MS could have made MBR writes from within their OS forbidden without an extreme warning. No OS bothers to do that, but it would have been actually a pretty defensible move on their part to mitigate root kits.
The problem is that Secure Boot gives MS control of the entire ecosystem but in doing so missed an opportunity to provide something that *would* have worked better and allowed MS to avoid vouching for anything but their own software at boot time.
I would certainly prefer that the vendors with razor thin margins of a few bucks a PC/motherboard in Taiwan not be burdened with 'taking ownership' of the platform.
The process would be implicit to the OS installer in the hypothetical. It's not like those cheapo vendors would incur any incremental cost at all. It's just that the UEFI firmware that everyone uses understands key installation via some EFI runtime service, and then locks it out once used. Windows PE would detect such a service without key, put MS key in at *that* point instead of having the board vendor always put it in the firmware before an OS ever touches it.
On a related note, if you are relying on the lowest bidder with the cheapest workforce to provide you a secure solution free from supply chain attacks, you are already screwed.
I think it more likely it was about Android on ARM. MS didn't want to end up selling some fantastic hardware device and getting all the 'momentum' wiped out by Android loads so people could run with a platform with some semblance of an ecosystem going (though I've not seen an RT device I'd find interesting regardless of software). x86 got to come along for the ride so that MS would be doing things in a nicely consistent fashion with more credibility on the matter of rootkit mitigation. It does mitigate rootkits, rootkits now have to be more complicated than they had to be previously. The components available to construct a rootkit may be unable to avoid tipping off a careful user that something is weird during the boot process (e.g. if SuSE's logo appears during a pure Windows boot, that would be a sign that something is afoot). Of course, the typical user that doesn't notice or has been trained to shrug off 'weird stuff' during the boot process (e.g. a lot of security suites end up branding boot process as they do their own FDE thing, so seeing a lizard on screen may make most people assume it's security software).
Slashdot Mirror
Evaluating Elop with respect to good/bad done to Nokia:
-Good: ditching Symbian
-Bad: Picking MS, the last place platform
-Bad: Focusing on higher end, North American market and neglecting Nokia's thriving global market.
Basically, the only measure by which Elop was 'good' would be microsoft's measurement of loyalty, willingness to sink his company for the sake of giving microsoft more of a chance.
Just imagine if Nokia had been the provider of things like Lumia 520 but with Android on it....
50 years ago, it was understandable that people were flinging account numbers back and forth because there wasn't much else feasible.
Now, probably 95% of transactions could easily be handled using a scheme where private key is used to sign transactions and the merchant is never ever privy to info that could be used multiple times.
If credit card companies did something to encourage point of sale equipment, internet merchants, and so on to work toward a scheme where private keys are kept private to the consumer rather than a loosely shared 'secret' scheme as it exists today...
Of course, the eye is not in a fixed location relative to the display. I can see more than 180 degrees without moving my head through solely moving my eyes.
A lot of people don't even like wearing watches, I can't imagine people going for full-on bracers.
Either things are going to stay pocketable or some sort of augmented reality solution are the things I could believe. If I were a betting man, I would bet that pocketable will continue to rule the day.
The problem is that some of the difficulties are by design. journalctl and systemctl are actually pretty straightforward to use. However, when things go off the rails, it's much harder to cope with than a system that retains plain text logs at the core. The argument that journalctl can give you plain text rings hollow when the tool is hard to get to (system had catastrophic failure and you are on the wrong end of a crappy connection but have a random system nearby that can peruse data. Lennart would call this a convoluted case, but it comes up surprisingly often. Meanwhile, having journal do plain text file alongside the binary file would neatly address a lot of the criticism without a whole lot of downside, but it's almost a religous objection to plain text logging rather than practical concerns keeping it soley the domain of syslog.
The old-school thinking was they failed to protect their intellectual property, and lost market share to competitors who copied their design
I don't think anyone significant believed that. Even IBM had long acknowledged that they thought the PC clones were the reason for the amount of volume they got. They knew long ago that thanks to that they got a decent chunk of a massive market instead of 100% of a pathetic small market (also, getting a decent chunk of change from all the clones that had to license a lot of patents, it's not like IBM let them 'steal', they licensed the relevant patents). IBM didn't plan that in the beginning, but they realized relatively early on that is was a blessing rather than a curse.
So one prominent example is a push to discard syslog, but at the same time rejecting any suggestion that perhaps it might be nice if the same plain text that journalctl can produce be produced as a matter of course without syslog assistance.
Yes, journalctl has more readily accessible nice filters and faster performance. The issue is that the vast majority of people didn't ever need them and made due with grep and friends. Yes it's not good stuff to build a high-end solution out of, but by the same token journalctl power is more complicated to use.
Getting early boot messages would have been a straightforward thing to do in syslog land, it was just that no one bothered. It was a good thing to add, but generally either things work fine and you don't really care much about the early boot logs, or it fails to get root fs going in which case the logs from that time won't make it to the root fs hosted journal anyway.
I don't like the linux distros of today because they are largely reimplementing much of what people ridiculed microsoft for in the 90s (binary configuration, binary logs, more complex messaging model). While it is true that generally the details of the implementation are defensibly better than microsoft did, the differences are largely academic to the vast majority of system administrators. Vast majority sees opaque binary blob that is useless without a very close match in distribution to provide tools to analyze. Even when things are humming along fine, things like dbus provide capability in a nearly impossible to explore manner. Even with all this complexity, my linux server experience is no more useful than it was 10 years ago from a managability standpoint, but I've had to jump through hoops to try to track the complexity as it emerged bit by bit without a lot of nice capability to come along for the ride.
Well, that and Lennart Poettering tends to not constructively respond to requests by users. He's done some very sophisticated work, but in many ways fails to understand the reality of most sysadmins. He wants all sysadmins to be able to handle the new capabilities rather than coddle them with plaintext log formats, even though over 95% of the audience doesn't *need* the stuff that is hard to do in a plaintext log format.
MS has done the same thing, system registry, event log, etc all act very similarly to the way systemd thinks things should be done. I know windows events are even worse in terms of format, but journal is a lot closer to windows events than it is to /var/log/messages.
So this is the point where we blindly assume our favorite 'evil' is at play and blame it for all of the problems without actual evidence one way or another?
This situation is likely to have been equally screwed up regardless of 'waterfall' vs. 'Agile'. In my experience, a team that will screw things up in this way will screw up no matter what nominal process is in place.
'No true scotsman' fallacy aside, there have been tons of practical advances in writing code.
Development and debug tools are light years better and a great deal of the code contributing to code size is reusable code that has been battle tested for a long time.
The contract went to the lowest bidder and/or the firm that could do the most backroom political deals to win
For reference, in this case it is very much the later since CGI was awarded the contract in a no-bid scenario.
DNSSEC is mostly about having the will to bother to do it. In that respect, private industry has very little patience for anything that is hard to tie to bottom line. telnet is *still* widely in use in private companies because of the same deal.
This endeavor is very much complex by being bolted on to an existing complicated mess and trying to unify things. DNSSEC is amateur hour next to trying to corral all the health care cats. Still very much doable, but it has the misfortune of also being at the center of an extremely politicized situation. So prudent careful progression is cast aside in the name of needless urgency combined with some political shenanigans of a no-bid contract.
Does it do plugin or java web start? In the latter case, this doesn't factor in. Most things that I deal with that once were java plugin centric are now java webstart if they can't manage to pull it off in http/javascript/html
IPMI is a UDP protocol that has no direct relationship with a browser.
If you are instead implying that service processors frequently have web interfaces that employ java, at least with IBM the current state of affairs is java web start, which means no browser plugin even if it does use java. Even if they were, you don't have to worry about the vendors being too cheap to fork over the chump change.
Of the big, valuable, 'hot' companies, they all are producing increasingly dubious products.
Netflix loves to crash on me and keel off midstream ever so often. Then of course there are the outages. All this whilst their team brags about how awesome they are at availability.
Apple has had a litany of clock mistakes, unlock screen bypass, and of course the maps situation. I will say I don't use Apple products, so this is second hand experience.
Amazon... well about the only thing that seems to work really well is their own web presence. Their prime instant viewing does indeed make netflix look good by comparison. I will say I never used a Fire, so I can't attest to that. EC2 has pretty frequent outages that take down a bunch of big players. Lot's of people come out of the woodwork to white knight and say 'if the clients did it *right*, they wouldn't be so bothered', but it seems self evident that after all this time those major sites still can't figure it out, it's obviously not as viable model as some people desperately want to believe for some reason.
It's as if the entire industry has lost all patience and risks flaky, crappy behavior for the sake of releasing something that sounds exciting and novel.
You don't change the oil in your car? You've never had to replace a belt? Do you just let your car sit in a garage all the time?
Of those actually mucking about in implementations, the most common complaint I've heard is that vendor implementation are too inconsistent. I cannot imagine the same people making that call have had experience dealing with x86 BIOS, which is a landmine of inconsistency vendor to vendor. Should an option rom hookn int18? will hooking int19 be catastrophic? Does the vendor implement BBS or not? How should you leave the stack on exit to assure that subsequent boot devices are not hosed?
I'm not happy with everything in UEFI (mostly because it follows a lot of microsoft design guidance (executable format, ucs-2, microsoft function calling conventions), but the ability to associate functions with existing devices is exceptionally handy. For example in network device world, in BIOS the network card vendor would have to provide the full PXE implementation up to dhcp and tftp. In UEFI, the network card vendor is best off publishing only the low level interface, and then code from other people can hook ip stacks that are independent of the network hardware. It means that switching network vendors leads to less inconsistency in network boot behavior.
Another thing that's nice is the standardized interface between OS and firmware. The EFI variable space is nice. It falls short though of adequately supporting configuration, meaning it retains proprietary tools to configure firmware from OS that vary vendor to vendor.
You will get two answers, depending on reader interpretation of 'rock star'.
One connotation is that they are high maintenance douchebags, that might or might not be competent too. This comes from the fact that *usually* the only way such douchebags stay employed is having great talent. By no means is this sort of person generally required. If you have a talented person in this category, you will be screwed when they go away or stop caring, because no one will be able to do anything with their code.
The other connotation is that they are a great developer. These people are greatly valuable. You may still have retention problems due to competing offers. They can churn through problems easily and assume a leadership role. They can work with people. If someone is in this category, losing them is still a great loss, but not nearly as fatal as those who assume themselves too good to work with others.
For one, the Linux kernel probably has the fastest development rate than any other kernel out there.
For another, given that it is the kernel, I think it is good for people mucking about with it to be scared. There should be *very* compelling reason to change the status quo in kernel land before any attempt is made.
In therms of a flame ware improving a product, I think it is often better than the alternative. It's better to hash it all out, for better or worse, than sidestep discussion for fear of hurt feelings. I've seen the alternative, projects where people are more politicking than getting work done. Conversation fleshed out by more sycophants than meaningful discussion. Passive aggressive discussions where you just aren't sure what is really under the surface.
Powershell is an oddball that is part python, part perl, and part bash, with heavy amounts of .Net thrown in. While very potent, that makes for some... extraordinarily peculiar constructs and surprisingly ambiguous reaction to certain pipeline flows (e.g. the datatype of seomthing returned being an array type or a singelton type based on number of results can have disatrous results when code tested with just one match suddenly hits an array, or vice versa).
Things like perl/python are not interactive shells for good reason, and bash is a terrible syntax for efficient complex programs for good reason.
I will give them the pipeline operator is a handy shorthand for an iterator operation however.
An example of 'NIH' After years of people pretty much wanting a damn bourne shell, they... made something totally different. People wanted nicely interopable ssh access, they got the hellish monster of powershell remoting over WebServices.
Now if you are a *pure* MS shop, then *anything* but cmd was a great help and the extraordinarily complex nasty crap underlying all their remoting and WMI is tucked away so you can't see just how much it is terrible.
Now MS recognizes that most datacenters are hetereogenuous. What is their answer? Linux should just start acting like Windows: http://blog.serverfault.com/2013/06/03/cross-platform-configuration-management-is-hard/
Seriously, in their efforts to be more 'friendly' in a mixed datacenter, they decide the answer is the world would be so much easier if they can continue to ignore decades of established behaviors of others and just get those competitors to simply change their mind.
Carriers will treat it as a smartphone. When the central point of the OS as evidenced by the name is full blown web browsing, it's going to be treated as a peer to android/ios devices, period.
With Android as it is in Jelly Bean, firefox os has a very uphill battle ahead of it. If it managed to release prior to ICS, *maybe* it could have had an in, but as it stands Android is just too capable and clean. That's not to say something better can be done or that people like me nervous about just *how* much control Google gets to exert would be interested, but I'm not going to assume for a second that constitutes enough people for a viable mobile platform.
Can you tell us how it's easy to get around Secure Boot?
Well, that rootkit had to go through quite a few hoops to avoid detection. A different set of hoops are in order here.
It'd be hard to hide a MS hypervisor because they are so bloated, but a linux hypervisor can be constructed in under 24 megabytes, which is essentially a rounding error in the typical EFI boot partition as created by MS. So the rootkit is a linux bootloader, kernel, and initrd with qemu and such. The rootkit has to fake a *lot* more stuff to fool extremely comprehensive security software (e.g. if it bothers to look at every single device in great detail, then it would have to emulate every single device). This hinges mostly on how comprehensive the security software is expected to be (and whether that security suite compromises to tolerate 'P2V' type changes) and how dedicated the malware authors are (history has shown them to be... extremely dedicated).
The concept is solid enough, but the implementation is flawed. As a consequence of mandating that the factory burns in the signing key, it pretty much forces MS to sign competitor payload or be seen as anti-competitive. This means your Microsoft install implicitly trusts software from Red Hat, Canonincal, VMware, Attachmate, and really anyone else who may enter the ring. There is no way that MS is providing adequate auditing to assure those paths aren't vulnerable and it shouldn't have to. Because it must be installed into firmware before an OS touches it, there is also *no* reasonable opportunity to provide any assurance of customer provided content like configuration.
As to that root kit you mentioned, MS could have protected itself from that without SecureBoot or any boot signing. MS could have made MBR writes from within their OS forbidden without an extreme warning. No OS bothers to do that, but it would have been actually a pretty defensible move on their part to mitigate root kits.
The problem is that Secure Boot gives MS control of the entire ecosystem but in doing so missed an opportunity to provide something that *would* have worked better and allowed MS to avoid vouching for anything but their own software at boot time.
I would certainly prefer that the vendors with razor thin margins of a few bucks a PC/motherboard in Taiwan not be burdened with 'taking ownership' of the platform.
The process would be implicit to the OS installer in the hypothetical. It's not like those cheapo vendors would incur any incremental cost at all. It's just that the UEFI firmware that everyone uses understands key installation via some EFI runtime service, and then locks it out once used. Windows PE would detect such a service without key, put MS key in at *that* point instead of having the board vendor always put it in the firmware before an OS ever touches it.
On a related note, if you are relying on the lowest bidder with the cheapest workforce to provide you a secure solution free from supply chain attacks, you are already screwed.
I think it more likely it was about Android on ARM. MS didn't want to end up selling some fantastic hardware device and getting all the 'momentum' wiped out by Android loads so people could run with a platform with some semblance of an ecosystem going (though I've not seen an RT device I'd find interesting regardless of software). x86 got to come along for the ride so that MS would be doing things in a nicely consistent fashion with more credibility on the matter of rootkit mitigation. It does mitigate rootkits, rootkits now have to be more complicated than they had to be previously. The components available to construct a rootkit may be unable to avoid tipping off a careful user that something is weird during the boot process (e.g. if SuSE's logo appears during a pure Windows boot, that would be a sign that something is afoot). Of course, the typical user that doesn't notice or has been trained to shrug off 'weird stuff' during the boot process (e.g. a lot of security suites end up branding boot process as they do their own FDE thing, so seeing a lizard on screen may make most people assume it's security software).