The disconnect is that SecureBoot as it theoretically is allowed to be implemented to cater to user control and the practical likelihood of how it is implemented is miles apart. A great deal of security isn't about what some protocol or device *can* do, it's about how it commonly ends up in real world.
SecureBoot *strongly* suggests a non-configurable scheme where it must be enabled and it must be MS signing key. Some people say MS wouldn't encourage such misbehavior, but the Surface RT from everything I hear is exactly that way (though I hear the Surface Pro is not). I don't think MS will be doing a lot to punish a vendor for being too lazy to include customer key management capability.
Initial signing key shouldn't have come in the firmware, it should have been like the TPM, the vendor has the opportunity to 'take ownership' of the platform. First OS to install gets to own the signing key. This eliminates the problem for 99.99% of MS user base as Windows preload happens at a 'trusted' vendor without putting undue burden on the rest of the industry. If your argument is that perhaps the user shouldn't trust that system vendor that much, SecureBoot isn't going to fix that. If the argument is that people with piece part systems are put at risk, it's such a small population that has to be using a malicious copy of the media.
My issue is that I'm having a hard time seeing what SecureBoot adds that cannot be acheived in a better fashion (e.g. more comprehensive use of a TPM). SecureBoot doesn't ensure that your are booting is signed by someone you trust. It assures that one efi executable was signed by someone (who you may or may not 'trust'), but most would conceive of 'what you are booting' to be the universe of everything that happens prior to the system being usable, boot loader, kernel, configuration, third party executables, etc etc, which SecureBoot does nothing to really facilitate meaningful measurement. SecureBoot is ill equipped to facilitate most of that.
It complicates use of non-microsoft OSes and I think the value of the mitigation provided is greatly overestimated due to a name that suggests more assurance than one should reasonably assume.
SecureBoot is an incomplete strategy. It only allows for attestation of software vendor provided content. It does nothing for: -custom executables -configuration data and so on
Servers in particular need to be looking for a mechanism for the customer to measure and secure their own boot stuff. Constructing a good enough root kit out of valid signed secureboot content is going to be feasible unless you render the system overly limited.
It's theoretically possible to completely break SecureBoot but still advertise SecureBoot as intact. System will merrily load up a signed hypervisor and that signed hypervisor may in turn do whatever the hell it wants including boot the 'normal' OS as a guest with firmware that will tell the OS whatever the attacker feels like. If secureboot is disabled, you can have a rootkit that advertises it as enabled without issue.
Ultimately, it's a mitigation strategy with huge gaping holes that people presume are no longer a problem because they don't take the time to understand the nuances of such a strategy. I'm not accusing the designers of this misconception, but the general population's understanding of the benefits of SecureBoot has been very misguided (I have heard some claim that PXE being wide open is ok because secureboot would protect it, in one example of how badly misunderstood Secureboot is)
If they simply stated than GTK should be considered a gnome component versus gnome independent, that doesn't necessarily bother me as it is a game of semantics. However, the key sentiment that strikes me as counter-productive:
"You can't just write something for 3.0 (be it an application, a shell plugin or a GTK theme) and expect it stay working that way forever. Instead you need to constantly improve on your work."
Which is a huge 'screw you' to backwards compatibility. To say that reworking perfectly working code repeatedly due to platform fickleness is to 'improve on your work' is extraordinarily asinine.
As a developer supporting a platform, I understand the appeal of declaring I have a free hand, but I know that attitude would make my solution impractical to consume. That's the whole point of 'major' releases with naming conventions that allow coexistence with 'older' streams on s system, to assure continued value to those who consumed the library. This is a standard that gnome has already badly broken (see MATE being forced to rename libraries because gnome reused a number of names in an incompatible fashion).
I really miss window title search, and show only one application from my compiz/kde experiences. This is after a lot of extensions which I think is a pretty atrocious replacement for simple configurabilty, but it isn't hopeless... the 'activities view' concept seems good and, most critically the alt-tab makes larger window counts actually manageable.
Yes it would. That's part of the test. Gauging relative interest in packages is part of the whole situation. Sure, enthusiasts get to come along for the ride and the developers get to try out things they would otherwise be forbidden from trying that they *want* to do, but the core mission of Fedora is, effectively, a proving ground.
It's the nature of the beast. Ubuntu is the same way, there is an ulterior motive at play. It's the simple truth of commercial linux. The question is to what degree the ulterior motives conflict, do nothing, or align with user goals. Fedora delivers cutting edge function first which causes some consternation as it fails, but for a respectable sized audience, that is a fine price of admission for experiencing new things first and, in some cases, getting to shape how immature technologies ripen.
I'm just wondering what is perceived as missing., as producing images from releases has been pretty trivial for me. I use xCAT to deploy them, but I presume cobbler is comparably equipped in this regard. Driver injection and all when I'm producing images for environments requiring out of tree drivers, but that's a pretty rare circumstance while tracking modern distros...
The credit card model has a fairly high cost of risk mitigation.
Fundamentally, you are throwing around what in any sane world would be the most secret of secrets. To hack around that reality, financial institutions bear non-trivial amounts of risk and have to do a lot to do analytics to try to detect fraud. Even with all that, the cardholder must be always vigilant as their circumstance could fall through the cracks.
I've long been amazed that my email provider offers me more rigorous prevention of unauthorized access than my financial institution.
It will also promote technologies that pass user input back to the VM like voice, video and touch inputs,
I can do all of that without dealing with the hypervisor as a middle man of any sort. Rather than using SPICE to a QXL video, I'd suggest the right answer would be a mechanism that works over IP to the hosted instance directly (e.g Xpra or RDP).
I also find PCI passthrough less interesting (it's too coarse grained) and technologies to more intelligently access GPU/Accelerator technology in a sane way more interesting. VirtualGL is a good example but doesn't include the facet of implementing that in a way accessible from a VM or OpenCL type activity, but you get the idea.
Phi is an interesting beast since it's really a host in and of itself and the best strategy to get what performance you can is to actually run things directly on it (e.g. ssh in). Even in that configuration, it currenlty doesn't match the current Tesla adapter performace for most workloads.
I'm holding out hope that this codec supports subtitles as filters, so we can bake them in without actually baking them in, if you catch my drift. One of the biggest challenges I've faced when working with video encoding is that container formats are notoriously unsupported across the entire spectrum of video players.
The issue being that whatever inconsistencies you are hitting won't be addressed by shuffling the subtitle track awkwardly into the video stream somehow. A player not being able to interpret an SSA/ASS stream won't suddenly be able to render them because it comes in the video part of the container. This just moves the problem form one part to another, and does so in a way without technical benefit.
If the meat of your gripe is that a lot of things do not understand matroska and you are really thinking that such a trick will make.mp4 servicable, that would be incorrect too. Already you can put SSA or vobsub into mp4, but because it isn't part of the mp4 spec, many.mp4 players ignore the track. The same exact thing would happen if Daala somehowe hypothetically had subtitles in it, Daala in.mp4 would be something that those players would just fail to play.
The whole article seems to be missing the fact that the developing countries are setting the pace these days.
Which is stated with a degree of surprise, but if you think about it, it makes a lot of sense.
In 'developed' countries, good enough reigns supreme. They may have state of the art infrastructure as defined by standards when the infrastructure was built. Getting tens of mbps to urban areas is 'good enough'. IPv4 is 'good enough'.
In countries that have no acceptable infrastructure, they have the opportunity to start from the correct place as it is defined now.
RHEL has been angling at shooting down vmware in the enterprise space. They have made a go of it with RHEV-M and thusfar have failed to get traction. This is despite RHEV-M having a lot of the most common capabilities available that vmware offers. It's a tad different and in some ways exposing users to quirks that don't make a lot of sense (vmware has its own quirks, but being first has advantages). Openstack in general is aimed in a pretty divergent direction than where vSphere went and isn't particularly well off in heading even in that direction. If RH couldn't dislodge vSphere with a solution that matches capabilities, I can't imagine how they come back with a less resilient architecture and suddenly be view favorably...
And it can come back just as quickly and easily. I'll use AWS as a shortcut because I'm lazy and it is representative of the wider market.
For smaller businesses, AWS does have economies of scale that ease significant portions of the cost. These businesses mostly have quite fragile IT services and moving them to AWS in a naive way is no big loss. With a marginal amount of skill, they can even gain some significant gain in robustness due to ease of getting instances in distinct availability zones. They still won't be 'enterprise grade', but still.
For larger businesses, they bring their own economies of scale. In this case, to do it just like AWS does it, it is necessarily possible to do it cheaper than AWS (AWS is after all, a for profit endeavor). This is not to say a business should not pay attention to AWS and size it, as it is a good indication of whether they are doing things right or not. If AWS *is* cheaper than internal IT, that org should look inward and understand why they are more expensive as a break-even endeavor than an external company is at a for-profit endeavor. It could be that Amazon is doing things that they can't consider (e.g. letting instances fall over pretty easily). It could be that the company should consider doing certain things more like Amazon. It could also be that they assume cost reductions that won't be realized (e.g. work that will still need to be tended to in-house on the external instances. The company may incur increase costs/skills needs to accomodate the AWS model. As an example of the last, looking at netflix's technical blog, it's clear they have more skills than the average enterprise IT shop. They seem to have to work pretty hard to keep their infrastructure working as it does. Despite that skillset, netflix pretty commonly locks out an individual client, or fails to kick off a video. They also seem to have at least one or two multi-hour total outages in a given year due to AWS failing in some way that even their design cannot tolerate.
It doesn't matter what you call your process, many development teams will devolve into this behavior. The fact of the matter is that 'agile' has the distinct honor of being the most 'hip' thing, and as such it is the set of labels of choice used to hide behind.
Of course. most of the terminology about agile stems from a host of BS that seems more infomercial than useful. The original 'manifesto' was a collection of straightforward statements that are pretty sensible, though mind numbingly obvious. It has mutated to be a large set of vocabulary generally hijacked at will.
In my experience, Impress's biggest problem is that their stock templates are pretty amateurish. Given a good professional template, it can do everything that really is necessary for presestation software to do. Excessive use of the bells and whistles in my mind takes away from a presentation rather than adds anything. Having to endure presentations where a speaker pauses to allow his bullshit aimation to finish is mind numbing.
I will say that MS is the *only* platform that doesn't have the modal dialog brought above the window being blocked. In MS I have to hunt for the dialog when I notice something doesn't work, other platforms make it far more prominent.
Hypothetically speaking, Windows tanks, MS will still do just fine with their business and solutions.
In that scenario, I would actually imagine history repeating itself. Microsoft OSes once were considered suitable *only* for trivial, non-critical home purposes and *real* work were done exclusively on Unix workstations and servers. Because of their overwhelming presence in the homes of workers, it managed to get into businesses even before they were *really* ready. No reason to think that the same hypothetical that destroys Windows on the desktop won't pull the same manuever as MS in the workspace, in before actually being ready, but *mostly* growing into it.
I personally do not share the enthusiasm for Visual Studio. The main thing is being from the same company that controls the APIs, so there is no risk of the APIs running away from the IDE that generally dings other IDE scenarios. If MS is in the boat of supporting third party OSes/APIs as the norm rather than the exception, I think Visual Studio is likely to lose a great deal of what makes it the product of choice for MS platform development.
The problem some people site is 'too much choice', but pick one set and be happy. GTK+ or Qt for GUI as an example where there is choice but the developer doesn't have to think about it if they don't want.
Their biggest problem was Hardware Compatibility causing the OS to become insecure.
No, what caused *excessive* insecurity in the 9x/ME case was a complete lack of meaningful user privilege separation. It carried over into XP because everyone pretty much had to run as Administrator to get a lot of things done with the legacy crap of 9x/ME to contend with. Vista and newer actually do weird things to fake out old applications (ugly, but necessary) and so they admittedly have done a good job of making a secure admin/user separation in spite of shitty applications relying on actions that mandate what would logically seem to be admin level privilege.
Hardware compatibility didn't cause insecurity in the XP days nor does it today. Tdoay it's just a matter of mostly popularity with some blame for having an overly complicated architecture providing ample opportunity for malware to slip itself in unexpected ways. The latter Linux used to be justified in feeling proud for having a more straightforward scheme, but a modern Linux desktop has been accumulating all sorts of weirdness approach the complexity of the MS design (dbus, dconf, etc).
In terms of the more relevant topic, the hardware picture has actually become less heterogenous in x86 over time. Once upon a time, you had to worry about Matrox, S3, 3Dfx, nVidia, ATI, and others on video cards. You had to worry about a myriad of storage controller chips and IO controllers. Now, overwhelmingly, if you cover AMD, Intel, and nVidia on graphics, you are done (there are others, but increasingly marginalized, and especially so in gaming). For storage, it's almost always integerated to the *singular* southbridge that is supported with the processor (at least on desktop). USB is exceedingly standardized such that most usb devices don't *have* a driver particular to them. On top of this, Linux is taken more seriously than it was a decade ago,
Well, the premise of the headline was *if* windows doesn't dominate. You are technically rejecting the feasibilty of that precondition.
In terms of MS owning both gaming and workplace PCs, that's not something I'd want to bet on. For one, you have Valve throwing some weight behind Linux. For another, you have consoles that include, among other things, Android platforms that are fungible. Think about how the Wii, despite exceptionally mediocre capabilities dominated share in the wider game industry. The marketplace is a lot more fickle than you give them credit for.
In the workplace, there is an ever decreasing reason to be microsoft centric. Enterprise application developers are moving stuff more and more into server-side code with decreasing expectation of browser platform. HTML/Javascript are displacing clunky activex controls for example. Office no longer is a hard requirement for 99% of their users as alternatives that are 'good enough' exist. AD and Exchange interoperability are probably the two biggest generic reasons to stick with MS in that market.
Slashdot Mirror
The disconnect is that SecureBoot as it theoretically is allowed to be implemented to cater to user control and the practical likelihood of how it is implemented is miles apart. A great deal of security isn't about what some protocol or device *can* do, it's about how it commonly ends up in real world.
SecureBoot *strongly* suggests a non-configurable scheme where it must be enabled and it must be MS signing key. Some people say MS wouldn't encourage such misbehavior, but the Surface RT from everything I hear is exactly that way (though I hear the Surface Pro is not). I don't think MS will be doing a lot to punish a vendor for being too lazy to include customer key management capability.
Initial signing key shouldn't have come in the firmware, it should have been like the TPM, the vendor has the opportunity to 'take ownership' of the platform. First OS to install gets to own the signing key. This eliminates the problem for 99.99% of MS user base as Windows preload happens at a 'trusted' vendor without putting undue burden on the rest of the industry. If your argument is that perhaps the user shouldn't trust that system vendor that much, SecureBoot isn't going to fix that. If the argument is that people with piece part systems are put at risk, it's such a small population that has to be using a malicious copy of the media.
My issue is that I'm having a hard time seeing what SecureBoot adds that cannot be acheived in a better fashion (e.g. more comprehensive use of a TPM). SecureBoot doesn't ensure that your are booting is signed by someone you trust. It assures that one efi executable was signed by someone (who you may or may not 'trust'), but most would conceive of 'what you are booting' to be the universe of everything that happens prior to the system being usable, boot loader, kernel, configuration, third party executables, etc etc, which SecureBoot does nothing to really facilitate meaningful measurement. SecureBoot is ill equipped to facilitate most of that.
It complicates use of non-microsoft OSes and I think the value of the mitigation provided is greatly overestimated due to a name that suggests more assurance than one should reasonably assume.
SecureBoot is an incomplete strategy. It only allows for attestation of software vendor provided content. It does nothing for:
-custom executables
-configuration data and so on
Servers in particular need to be looking for a mechanism for the customer to measure and secure their own boot stuff. Constructing a good enough root kit out of valid signed secureboot content is going to be feasible unless you render the system overly limited.
It's theoretically possible to completely break SecureBoot but still advertise SecureBoot as intact. System will merrily load up a signed hypervisor and that signed hypervisor may in turn do whatever the hell it wants including boot the 'normal' OS as a guest with firmware that will tell the OS whatever the attacker feels like. If secureboot is disabled, you can have a rootkit that advertises it as enabled without issue.
Ultimately, it's a mitigation strategy with huge gaping holes that people presume are no longer a problem because they don't take the time to understand the nuances of such a strategy. I'm not accusing the designers of this misconception, but the general population's understanding of the benefits of SecureBoot has been very misguided (I have heard some claim that PXE being wide open is ok because secureboot would protect it, in one example of how badly misunderstood Secureboot is)
If they simply stated than GTK should be considered a gnome component versus gnome independent, that doesn't necessarily bother me as it is a game of semantics. However, the key sentiment that strikes me as counter-productive:
"You can't just write something for 3.0 (be it an application, a shell plugin or a GTK theme) and expect it stay working that way forever. Instead you need to constantly improve on your work."
Which is a huge 'screw you' to backwards compatibility. To say that reworking perfectly working code repeatedly due to platform fickleness is to 'improve on your work' is extraordinarily asinine.
As a developer supporting a platform, I understand the appeal of declaring I have a free hand, but I know that attitude would make my solution impractical to consume. That's the whole point of 'major' releases with naming conventions that allow coexistence with 'older' streams on s system, to assure continued value to those who consumed the library. This is a standard that gnome has already badly broken (see MATE being forced to rename libraries because gnome reused a number of names in an incompatible fashion).
I really miss window title search, and show only one application from my compiz/kde experiences. This is after a lot of extensions which I think is a pretty atrocious replacement for simple configurabilty, but it isn't hopeless... the 'activities view' concept seems good and, most critically the alt-tab makes larger window counts actually manageable.
Add rpm-fusion and livna and you have everything you may want on the codec front.
I agree that Fedora could make this easier, but it isn't too onerous as it stands, install two rpms and things get in order.
Yes it would. That's part of the test. Gauging relative interest in packages is part of the whole situation. Sure, enthusiasts get to come along for the ride and the developers get to try out things they would otherwise be forbidden from trying that they *want* to do, but the core mission of Fedora is, effectively, a proving ground.
It's the nature of the beast. Ubuntu is the same way, there is an ulterior motive at play. It's the simple truth of commercial linux. The question is to what degree the ulterior motives conflict, do nothing, or align with user goals. Fedora delivers cutting edge function first which causes some consternation as it fails, but for a respectable sized audience, that is a fine price of admission for experiencing new things first and, in some cases, getting to shape how immature technologies ripen.
None of the above, since they don't track Fedora before RedHat does?
I'm just wondering what is perceived as missing., as producing images from releases has been pretty trivial for me. I use xCAT to deploy them, but I presume cobbler is comparably equipped in this regard. Driver injection and all when I'm producing images for environments requiring out of tree drivers, but that's a pretty rare circumstance while tracking modern distros...
The credit card model has a fairly high cost of risk mitigation.
Fundamentally, you are throwing around what in any sane world would be the most secret of secrets. To hack around that reality, financial institutions bear non-trivial amounts of risk and have to do a lot to do analytics to try to detect fraud. Even with all that, the cardholder must be always vigilant as their circumstance could fall through the cracks.
I've long been amazed that my email provider offers me more rigorous prevention of unauthorized access than my financial institution.
It will also promote technologies that pass user input back to the VM like voice, video and touch inputs,
I can do all of that without dealing with the hypervisor as a middle man of any sort. Rather than using SPICE to a QXL video, I'd suggest the right answer would be a mechanism that works over IP to the hosted instance directly (e.g Xpra or RDP).
I also find PCI passthrough less interesting (it's too coarse grained) and technologies to more intelligently access GPU/Accelerator technology in a sane way more interesting. VirtualGL is a good example but doesn't include the facet of implementing that in a way accessible from a VM or OpenCL type activity, but you get the idea.
Phi is an interesting beast since it's really a host in and of itself and the best strategy to get what performance you can is to actually run things directly on it (e.g. ssh in). Even in that configuration, it currenlty doesn't match the current Tesla adapter performace for most workloads.
I'm holding out hope that this codec supports subtitles as filters, so we can bake them in without actually baking them in, if you catch my drift. One of the biggest challenges I've faced when working with video encoding is that container formats are notoriously unsupported across the entire spectrum of video players.
The issue being that whatever inconsistencies you are hitting won't be addressed by shuffling the subtitle track awkwardly into the video stream somehow. A player not being able to interpret an SSA/ASS stream won't suddenly be able to render them because it comes in the video part of the container. This just moves the problem form one part to another, and does so in a way without technical benefit.
If the meat of your gripe is that a lot of things do not understand matroska and you are really thinking that such a trick will make .mp4 servicable, that would be incorrect too. Already you can put SSA or vobsub into mp4, but because it isn't part of the mp4 spec, many .mp4 players ignore the track. The same exact thing would happen if Daala somehowe hypothetically had subtitles in it, Daala in .mp4 would be something that those players would just fail to play.
I see that with their RHEV-M product and anticipated more traction, but didn't see it happen.
Going from a typical vSphere set of expectations to the Openstack vision is a whole lot bigger a leap than vCenter to RHEV-M.
Unfortunately, my sense is that as MS' solution gains maturity, it seems to get more mindshare than RHEV.
The whole article seems to be missing the fact that the developing countries are setting the pace these days.
Which is stated with a degree of surprise, but if you think about it, it makes a lot of sense.
In 'developed' countries, good enough reigns supreme. They may have state of the art infrastructure as defined by standards when the infrastructure was built. Getting tens of mbps to urban areas is 'good enough'. IPv4 is 'good enough'.
In countries that have no acceptable infrastructure, they have the opportunity to start from the correct place as it is defined now.
RHEL has been angling at shooting down vmware in the enterprise space. They have made a go of it with RHEV-M and thusfar have failed to get traction. This is despite RHEV-M having a lot of the most common capabilities available that vmware offers. It's a tad different and in some ways exposing users to quirks that don't make a lot of sense (vmware has its own quirks, but being first has advantages). Openstack in general is aimed in a pretty divergent direction than where vSphere went and isn't particularly well off in heading even in that direction. If RH couldn't dislodge vSphere with a solution that matches capabilities, I can't imagine how they come back with a less resilient architecture and suddenly be view favorably...
And it can come back just as quickly and easily. I'll use AWS as a shortcut because I'm lazy and it is representative of the wider market.
For smaller businesses, AWS does have economies of scale that ease significant portions of the cost. These businesses mostly have quite fragile IT services and moving them to AWS in a naive way is no big loss. With a marginal amount of skill, they can even gain some significant gain in robustness due to ease of getting instances in distinct availability zones. They still won't be 'enterprise grade', but still.
For larger businesses, they bring their own economies of scale. In this case, to do it just like AWS does it, it is necessarily possible to do it cheaper than AWS (AWS is after all, a for profit endeavor). This is not to say a business should not pay attention to AWS and size it, as it is a good indication of whether they are doing things right or not. If AWS *is* cheaper than internal IT, that org should look inward and understand why they are more expensive as a break-even endeavor than an external company is at a for-profit endeavor. It could be that Amazon is doing things that they can't consider (e.g. letting instances fall over pretty easily). It could be that the company should consider doing certain things more like Amazon. It could also be that they assume cost reductions that won't be realized (e.g. work that will still need to be tended to in-house on the external instances. The company may incur increase costs/skills needs to accomodate the AWS model. As an example of the last, looking at netflix's technical blog, it's clear they have more skills than the average enterprise IT shop. They seem to have to work pretty hard to keep their infrastructure working as it does. Despite that skillset, netflix pretty commonly locks out an individual client, or fails to kick off a video. They also seem to have at least one or two multi-hour total outages in a given year due to AWS failing in some way that even their design cannot tolerate.
Don't forget the consulting and speaking fees! Those are critical.
It doesn't matter what you call your process, many development teams will devolve into this behavior. The fact of the matter is that 'agile' has the distinct honor of being the most 'hip' thing, and as such it is the set of labels of choice used to hide behind.
Of course. most of the terminology about agile stems from a host of BS that seems more infomercial than useful. The original 'manifesto' was a collection of straightforward statements that are pretty sensible, though mind numbingly obvious. It has mutated to be a large set of vocabulary generally hijacked at will.
In my experience, Impress's biggest problem is that their stock templates are pretty amateurish. Given a good professional template, it can do everything that really is necessary for presestation software to do. Excessive use of the bells and whistles in my mind takes away from a presentation rather than adds anything. Having to endure presentations where a speaker pauses to allow his bullshit aimation to finish is mind numbing.
I will say that MS is the *only* platform that doesn't have the modal dialog brought above the window being blocked. In MS I have to hunt for the dialog when I notice something doesn't work, other platforms make it far more prominent.
I've never seen it on any other operating system.
You have been blessed then. I have seen modal dialogs on every platform, despite how horribly evil it is.
Hypothetically speaking, Windows tanks, MS will still do just fine with their business and solutions.
In that scenario, I would actually imagine history repeating itself. Microsoft OSes once were considered suitable *only* for trivial, non-critical home purposes and *real* work were done exclusively on Unix workstations and servers. Because of their overwhelming presence in the homes of workers, it managed to get into businesses even before they were *really* ready. No reason to think that the same hypothetical that destroys Windows on the desktop won't pull the same manuever as MS in the workspace, in before actually being ready, but *mostly* growing into it.
I personally do not share the enthusiasm for Visual Studio. The main thing is being from the same company that controls the APIs, so there is no risk of the APIs running away from the IDE that generally dings other IDE scenarios. If MS is in the boat of supporting third party OSes/APIs as the norm rather than the exception, I think Visual Studio is likely to lose a great deal of what makes it the product of choice for MS platform development.
The problem some people site is 'too much choice', but pick one set and be happy. GTK+ or Qt for GUI as an example where there is choice but the developer doesn't have to think about it if they don't want.
Their biggest problem was Hardware Compatibility causing the OS to become insecure.
No, what caused *excessive* insecurity in the 9x/ME case was a complete lack of meaningful user privilege separation. It carried over into XP because everyone pretty much had to run as Administrator to get a lot of things done with the legacy crap of 9x/ME to contend with. Vista and newer actually do weird things to fake out old applications (ugly, but necessary) and so they admittedly have done a good job of making a secure admin/user separation in spite of shitty applications relying on actions that mandate what would logically seem to be admin level privilege.
Hardware compatibility didn't cause insecurity in the XP days nor does it today. Tdoay it's just a matter of mostly popularity with some blame for having an overly complicated architecture providing ample opportunity for malware to slip itself in unexpected ways. The latter Linux used to be justified in feeling proud for having a more straightforward scheme, but a modern Linux desktop has been accumulating all sorts of weirdness approach the complexity of the MS design (dbus, dconf, etc).
In terms of the more relevant topic, the hardware picture has actually become less heterogenous in x86 over time. Once upon a time, you had to worry about Matrox, S3, 3Dfx, nVidia, ATI, and others on video cards. You had to worry about a myriad of storage controller chips and IO controllers. Now, overwhelmingly, if you cover AMD, Intel, and nVidia on graphics, you are done (there are others, but increasingly marginalized, and especially so in gaming). For storage, it's almost always integerated to the *singular* southbridge that is supported with the processor (at least on desktop). USB is exceedingly standardized such that most usb devices don't *have* a driver particular to them. On top of this, Linux is taken more seriously than it was a decade ago,
Well, the premise of the headline was *if* windows doesn't dominate. You are technically rejecting the feasibilty of that precondition.
In terms of MS owning both gaming and workplace PCs, that's not something I'd want to bet on. For one, you have Valve throwing some weight behind Linux. For another, you have consoles that include, among other things, Android platforms that are fungible. Think about how the Wii, despite exceptionally mediocre capabilities dominated share in the wider game industry. The marketplace is a lot more fickle than you give them credit for.
In the workplace, there is an ever decreasing reason to be microsoft centric. Enterprise application developers are moving stuff more and more into server-side code with decreasing expectation of browser platform. HTML/Javascript are displacing clunky activex controls for example. Office no longer is a hard requirement for 99% of their users as alternatives that are 'good enough' exist. AD and Exchange interoperability are probably the two biggest generic reasons to stick with MS in that market.