Average users need not touch grub.conf. The ones that do should understand how to hit 'c' or 'e' to recover without a rescue disk.
Scenarios where I've seen someone forced to 'rescue' are when the available initrds are fubared, and 'update-grub' won't prevent that.
Two things I hate windows for are binary registry and bcd files. Steering away from plain text to protect the user is not an aspect I want to see mimicked, as when it fails to protect, it actually makes the problem worse.
The thing is Android and iOS cannot *reasonably* do this. Neither can MS but they are trying it anyway. (I repeat that criticism of Unity and Gnome 3 as well).
The reason is simple, the distinct form factors are just *too* different from one interface to work well on all of them, some interaction will be awkward. The first round of just putting standard desktop interfaces and putting them in a place with only touchscreens and no keyboard was awkward, so now they are going the other way and putting interfaces designed for touch interface on desktops.
I presume this is more on the 'exclusive' bit, not just Sprint doing the phone at all. Otherwise the doubt makes no sense.
At this point, Apple is pretty confident that probably the vast majority of the users who would buy the device would buy it no matter what, regardless of network. Apple has the brand loyalty, not AT&T and not Verizon. Sprint comes up offering a bigger subsidy chunk to let Apple charge more for a limited time and poof, instant profit without much risk. If they establish clearly that in half a year or so the iPhone 5 will land on AT&T/Verizon, that should keep users *truly* dedicated to those networks from jumping devices, and would delay (not eliminate) the revenue opportunity there.
Sprint may have agreed to such a high price in exchange for exclusivity. In this way, Sprint would be assuming the risk and Apple fanatics can still get their toy at the same price point. Apple is pretty sure at this point they can put their shiny toy on whatever network(s) they wish and customers will follow the device and not the network.
If they had a 6 month exclusive lock on it, it may well be worth it. Apple users tend to do *anything* to get the new toy, ETFs and all.
One, the timing suggests that MS can't be bothered to work this scenario. This isn't something that was (allegedly) in play before anyone even thought MS deal was happening, it happened after the MS deal was solidly in place.
I just don't see this as an appealing play for MS. We are talking about an environment that is explicitly anti-app and anti-cost. Given no per-device margins to be had by a software vendor and no promise of a rich application development and publishing ecosystem to reap revenue from, I don't see MS ever changing this situation.
No, it's think *as* you code. You do think some before starting to code, a vague rough picture of the pieces, but you don't invest a lot of time in that 'pure' design phase because the more detailed you plan without proving it out, the more you *should* throw away as you start implementation and realize how ill-conceived your design was or that maybe your design was adequate, but a better way makes itself apparent when actually implementing. Generally when I see a development team incapable of operating at all in this manner and fail to achieve any measure of 'complete', they only 'complete' under other strategies of development on a technicality and produce low quality product. Some management people think that methodology can be used to make piss-poor (cheap) developers serviceable and avoid having to reward/retain good talent.
A lot of people wrote books on patterns (design and otherwise), but in the end if no one follows these patterns the problems remain.
I think there are two aspects to this. One is that most development an organization is predestined to operate in a specifc way depending on who comprises it, regardless of what name they pick to describe it. I know organizations that did 'waterfall' and 'changed' to 'Agile', but really just renamed things they did, acted the same, and called it 'Agile'. However, I don't know if this is a bad thing. I think getting too hung up on a specific 'pattern' others preach in conferences is bad, and organically feeling your way for a process that works for your team is better. Awareness is good, but getting locked in is bad.
However, I have found in the sea of Agile and Waterfall and all sorts of buzzwords a methodology that really resonates with me: http://programming-motherfucker.com/
Well, solely blaming 'IT organizations' for developer unawareness is unfair, but in answer to you second question, yes, a good IT department can and will debug software to the extent it does not take down other services in the process. Sometimes a behavior cannot be readily replicated and knowing enough to capture viable debugging data before having to revert it to a working state can be critical. You don't want to leave it messed up until a 'developer' can get to it because you need it back to working ASAP and the bad condition might be transient anyway.
The curse of 'enterprise'
on
The Cult of DevOps
·
· Score: 3, Insightful
I've been around enough to know that this 'new' 'DevOps' philosophy is just the way it always has been done at many successful companies making extensive use of technology.
I have come to associate the phrase 'enterprise IT' with those who *don't* work that way, and make their lives needlessly complicated. Of course, every last party to the mess will generally recognize it and know what could hypothetically be done about it, but only bitch in private about it and rarely ever push for meaningful change. The reason is simple, so long as it is a complicated mess, it requires a great deal of human care and feeding, meaning job security. Management can't force things to change without huge risk as everyone has sufficiently entrenched themselves.
This is market cap based. 'Value' is the closest word for that. It doesn't directly indicate cash on hand or how much debt they hold. It doesn't indicate directly how highly viewed among potential clients they are. It indicates the perceived value of IBM by stock market participants. This translates well to their ability to borrow and *usually* indicates a healthy company with positive cash flow/good standing with their customers.
While IBM is doing well enough at creating and selling goods and services, but they get a bit *extra* credit with stockholders by using a large chunk of their income to buy back stock rather than do other things with it.
One, they at least put vfat out there as one thing. IIRC, there was some talk about random data in the 8.3 name serving as a non-infringing vfat implementation, but I still haven't seen anything one way or another. I think this is their main ammunition in going after anything, linux or not, that writes to removable storage. There may be other things, but they have put something out there.
Second, there's nothing to say they *must* be 'linux' patents. Android has it's own userspace stack and UI. The potential area for infringement is must larger. Even if they said nothing in Linux infringed, they could still go after Android.
The most interesting part of this is showing how much of a minefiled patents are for large companies. Imagine how overwhelmingly impossible it is for a startup tech company to get going in this environment. The fact these are almost always settled out of court means that the defendant is at too much risk and can't afford to pursue a battle even if they might win (more so in small business case) and that the company suing also doesn't want to put their patents to the test of legal scrutiny. Something is very very wrong with the system.
Wait, you don't think it's fair that a person -- not unlike yourself -- who owns an assembly business, should be able to attempt to sell whatever they choose? You think someone else's private business should be forced to sell what you want to buy?
The problem is that it's not the manufacturers that *want* to do this. If so, they could have done more by now. They've done the bare minimum that MS demands. It is not in their interest to potentially restrict OS choice, and the anti-rootkit benefits are dubious (unless *maybe* if you lock down only to MS). The problem is measures like this have a large potential to be very anti-competitive, which may be a lost cause since being a convicted monopolist hasn't really slowed them down in the least.
Used to be, you could purchase a computer with no OS at all. Now, the law says that it's illegal to do so.
Show me this alleged law. I can tell you already that you cannot, because you can buy tower systems all day long without an OS from IBM, Dell, and HP. Generally complete Desktop and laptop vendors don't dare to sell bare-bones systems because of market forces and logistics.
Otherwise, Best Buy would be selling computers without OS's,
WTF are you smoking there? Best Buy won't touch *anything* that could possibly 'confuse' or 'intimidate' a random person off the street.
But you (the greater you) yelled and screamed about a decade ago, forcing Best Buy to only sell computers with an OS.
I do not recall *anyone* (apart from Microsoft themselves) begging any government to forbid bare bones systems...
If you buy from Best Buy, you bought from a system builder who bought from Microsoft nearly certainly. Ignoring the money they already gave to MS and enabled secure boot by default as well and giving MS *more* money to acquire the *same* software that will also be signed in a way to pass the same secure boot checking is only different in how convoluted the scenario is.
Protesting having this enabled by default is a tad asinine for most desktop users. Demanding that Firmware be mandated to have a configuration setting allowing it to be disabled is reasonable.
There is a crowd of people with a legitimate issue. If you have an unattended mass deployment of non-signed software (e.g. you don't want a 'tech' babysitting any particular system), there is a significant problem. In enterprise system deployment, this could be construed as anti-competitive as MS is the only vendor with the leverage to get their signing keys everywhere.
Overall, however, I think Trusted Boot is a losing game in preventing malware. It means your rootkits have to get bigger and you probably have to build it out of a chain of signed software until you find a weakness, but unless you make the PC fundamentally less usable than it is today, there is going to be a weakness somewhere. For example, if you allow RH signing key and RH just signed grub and then was done with it, suddenly you have a Windows rootkit using grub chainloading malware then Windows.
My point was the 'automated' part in the second point. Human testers with a distinct, fresh perspective from development is crucial, but I've seen too many projects mimnimize the importance of human tests because of some automated test framework in play and that suffices to check off the "should test" checkbox in their minds.
It isn't as rosy as it sounds, at least in my general experience (practice always deviates from theory right?).
The theory is you write your unit tests first, and then code until you pass. In practice two things go wrong: 1) You make a mistake writing unit tests (I have seen many times where *only* buggy code could pass the incorrectly written unit tests). 2) Passing even a well-conceived unit test inspires overconfidence. I have encountered more than a few people who honestly believe passing all unit tests as an automated part of a build process was sufficient and no human testing was required.
In short, sure, officially it endorses testing, but really only speaks much to automated unit tests and less to actually taking the time to let some users dig in and do nothing but make sure those users validate you did the work correctly.
Even relatively recent, dual-core 1.2 Ghz Android devices simply do not have the horsepower to decode a 1080 stream. Note that even a Core2 at 2 Ghz won't even reliably keep up with many 1920x1080 streams, and the performance per clock is better there than ARM.
Now consider the fact that even at full tilt, it will have massive frame drop. Imagine your battery consumption.
The reason I presume Nook hardware decode is limited is because even their hardware decoder couldn't have been architected to do that decode at the price B&N wanted to set. You'll be massively disappointed trying software decode if it is available, as I imagine the Nook color is stingy with the CPU as well.
I don't know about VLC, but mplayer and xbmc do vaapi, vdpau, and dxva2 (windows) specifically because even in intel land, either the CPU will choke or at *least* destroy battery life if it has to decode the stream.
Sure, probably a little bit. You build a shoddy little app and you might have an irrational affinity for it even in the face of substantially more functional stuff. Though when you 'build' something (not assemble, as I would characterize IKEA stuff I've seen), you naturally tailor it precisely to your needs, so it generally isn't quite so irrational. The presumption that the market 'resists open source' is FUD/flamebait.
The question is how do the popular open source projects get there. The answer is that generally commercial products are built using a certain model involving marketing, project managers,testers who frequently don't understand the life of the customer, customers with little to no ability to influence the program, architects who rearely, if ever, touch code, and coders "just doing their job". In some cases this works well or at *least* won't be any better in open source land due to various factors. However, a successful open source project includes has the line blurred between intended endusers, test, and development. This means the users get *precisely* what they wanted when things are done. Even if they are not doing a lot of development, they'll participate in discussions on their favorite feature and steer the conversation correctly whenever they see someone misunderstanding. It's the same basic principle as a designed by-and-for-yourself project, but on a larger scale in a healthy community.
In commercial projects, there is a lot of signal loss as their requirements are taken down by someone not really understanding their needs, being distilled further into a short bullet point list of product requirements that ditches any semblance of the subtleties inherent in the requests, which is in turn interpreted and tested by a group who never uses the product for production and never talks to the customer, and then released to a customer who thinks "what the hell is this and what did it have to do with my requests?".
It says very little good actually. Casio undoubtedly has a lot of sunk cost in using Linux, therefore there is nothing to say that they wouldn't have chosen Windows from the start if they knew they'd do this. It also could mean casio agreed to pay some pittance to give MS some ammunition in exchange for some other consideration. In other words, there is no unambiguous endorsement of Linux as 'better' to be had.
However, it does say that through legal intimidation large companies can bully their way into revenue without actually doing work.
I mentioned this elsewhere, but AMT (which this is a part of) is a non-starter in the 'server' Intel chipsets at all, and even if it were, the second they drop an emulex or broadcom to drive the networking, it would still become non-working.
Currently, they have this tied to AMT. That only works with a pure Intel implementation (integrated Intel nic, chipset, etc). AFAIK, it's even *specefically* only the 'desktop' chipsets that bother putting in the bits. So your EP/EN/EX platforms are not invited to the party at all, even *if* your vendor didn't put Emulex or Broadcom down. They specifically segmented this off as 'desktop/laptop', and said 'IPMI' is the server equivalent (which covers most of the base capabilities, but omits KVM and has delegated that to proprietary extensions, as real men need nothing more than Serial (even windowws admins).
Ok, so some commands detect if stdout is a terminal and strip formatting and *could* do more drastic things. I don't see how it's any more intuitive to recognize whether every component in a pipe chain is backed by a win32 exe or a cmdlet versus memorizing some commands strip out color codes when piped (I can't think of an example that does something more drastic than stripping color codes, and I can forgive that since the ANSI codes would appear as 'data' counter-intuitively to pipe consumers, it's making the output more like the plaintext that the user sees, not less.
Even the most recent PowerShell terminal is restricted in silly ways (won't let me make it wider than a certain bound, and I have no idea why). Between not having a plain old bourne shell, not doing ssh, and still having text terminals that behave in boneheaded ways, I get frustrated.
It requires a script writer to be a bit more 'programmer' when outputting data. Most admins understand text data like a basic spreadsheet. Good admins can program correctly, but the notion that you throw things like '.toString' in betrays how it's not quite as straightforward as shell.
PowerShell is neat in its own way, but it doesn't excuse MS's 'not invented here' as they have *continually* failed to just include a damn bourne shell and ssh access (the wrapping remote cli invocation in unwieldy WS-Man is just absolutely insane next to ssh, powershell hides it from you but under the covers it is nasty and you don't get to ignore that cross-platform). MS can offer differentiation without precluding compatibility, and this failure to pursue that is what ticks me off very much.
On a win7/win2k8r2 system, run powershell, type 'ps|cat' In linux, they look the same. In windows, ps|cat prints binary data to the screen instead of the text you get with 'ps'
Slashdot Mirror
No EFI support. Relatively poor interactive capabilities.
Average users need not touch grub.conf. The ones that do should understand how to hit 'c' or 'e' to recover without a rescue disk.
Scenarios where I've seen someone forced to 'rescue' are when the available initrds are fubared, and 'update-grub' won't prevent that.
Two things I hate windows for are binary registry and bcd files. Steering away from plain text to protect the user is not an aspect I want to see mimicked, as when it fails to protect, it actually makes the problem worse.
The thing is Android and iOS cannot *reasonably* do this. Neither can MS but they are trying it anyway. (I repeat that criticism of Unity and Gnome 3 as well).
The reason is simple, the distinct form factors are just *too* different from one interface to work well on all of them, some interaction will be awkward. The first round of just putting standard desktop interfaces and putting them in a place with only touchscreens and no keyboard was awkward, so now they are going the other way and putting interfaces designed for touch interface on desktops.
I presume this is more on the 'exclusive' bit, not just Sprint doing the phone at all. Otherwise the doubt makes no sense.
At this point, Apple is pretty confident that probably the vast majority of the users who would buy the device would buy it no matter what, regardless of network. Apple has the brand loyalty, not AT&T and not Verizon. Sprint comes up offering a bigger subsidy chunk to let Apple charge more for a limited time and poof, instant profit without much risk. If they establish clearly that in half a year or so the iPhone 5 will land on AT&T/Verizon, that should keep users *truly* dedicated to those networks from jumping devices, and would delay (not eliminate) the revenue opportunity there.
Sprint may have agreed to such a high price in exchange for exclusivity. In this way, Sprint would be assuming the risk and Apple fanatics can still get their toy at the same price point. Apple is pretty sure at this point they can put their shiny toy on whatever network(s) they wish and customers will follow the device and not the network.
If they had a 6 month exclusive lock on it, it may well be worth it. Apple users tend to do *anything* to get the new toy, ETFs and all.
One, the timing suggests that MS can't be bothered to work this scenario. This isn't something that was (allegedly) in play before anyone even thought MS deal was happening, it happened after the MS deal was solidly in place.
I just don't see this as an appealing play for MS. We are talking about an environment that is explicitly anti-app and anti-cost. Given no per-device margins to be had by a software vendor and no promise of a rich application development and publishing ecosystem to reap revenue from, I don't see MS ever changing this situation.
Also known as the first code then think approach
No, it's think *as* you code. You do think some before starting to code, a vague rough picture of the pieces, but you don't invest a lot of time in that 'pure' design phase because the more detailed you plan without proving it out, the more you *should* throw away as you start implementation and realize how ill-conceived your design was or that maybe your design was adequate, but a better way makes itself apparent when actually implementing. Generally when I see a development team incapable of operating at all in this manner and fail to achieve any measure of 'complete', they only 'complete' under other strategies of development on a technicality and produce low quality product. Some management people think that methodology can be used to make piss-poor (cheap) developers serviceable and avoid having to reward/retain good talent.
A lot of people wrote books on patterns (design and otherwise), but in the end if no one follows these patterns the problems remain.
I think there are two aspects to this. One is that most development an organization is predestined to operate in a specifc way depending on who comprises it, regardless of what name they pick to describe it. I know organizations that did 'waterfall' and 'changed' to 'Agile', but really just renamed things they did, acted the same, and called it 'Agile'. However, I don't know if this is a bad thing. I think getting too hung up on a specific 'pattern' others preach in conferences is bad, and organically feeling your way for a process that works for your team is better. Awareness is good, but getting locked in is bad.
However, I have found in the sea of Agile and Waterfall and all sorts of buzzwords a methodology that really resonates with me:
http://programming-motherfucker.com/
Well, solely blaming 'IT organizations' for developer unawareness is unfair, but in answer to you second question, yes, a good IT department can and will debug software to the extent it does not take down other services in the process. Sometimes a behavior cannot be readily replicated and knowing enough to capture viable debugging data before having to revert it to a working state can be critical. You don't want to leave it messed up until a 'developer' can get to it because you need it back to working ASAP and the bad condition might be transient anyway.
I've been around enough to know that this 'new' 'DevOps' philosophy is just the way it always has been done at many successful companies making extensive use of technology.
I have come to associate the phrase 'enterprise IT' with those who *don't* work that way, and make their lives needlessly complicated. Of course, every last party to the mess will generally recognize it and know what could hypothetically be done about it, but only bitch in private about it and rarely ever push for meaningful change. The reason is simple, so long as it is a complicated mess, it requires a great deal of human care and feeding, meaning job security. Management can't force things to change without huge risk as everyone has sufficiently entrenched themselves.
This is market cap based. 'Value' is the closest word for that. It doesn't directly indicate cash on hand or how much debt they hold. It doesn't indicate directly how highly viewed among potential clients they are. It indicates the perceived value of IBM by stock market participants. This translates well to their ability to borrow and *usually* indicates a healthy company with positive cash flow/good standing with their customers.
While IBM is doing well enough at creating and selling goods and services, but they get a bit *extra* credit with stockholders by using a large chunk of their income to buy back stock rather than do other things with it.
Two things.
One, they at least put vfat out there as one thing. IIRC, there was some talk about random data in the 8.3 name serving as a non-infringing vfat implementation, but I still haven't seen anything one way or another. I think this is their main ammunition in going after anything, linux or not, that writes to removable storage. There may be other things, but they have put something out there.
Second, there's nothing to say they *must* be 'linux' patents. Android has it's own userspace stack and UI. The potential area for infringement is must larger. Even if they said nothing in Linux infringed, they could still go after Android.
The most interesting part of this is showing how much of a minefiled patents are for large companies. Imagine how overwhelmingly impossible it is for a startup tech company to get going in this environment. The fact these are almost always settled out of court means that the defendant is at too much risk and can't afford to pursue a battle even if they might win (more so in small business case) and that the company suing also doesn't want to put their patents to the test of legal scrutiny. Something is very very wrong with the system.
I consider that a subest of point 1, but absolutely, big-A Agile strongly suggests the developer is the one to test his own work.
Wait, you don't think it's fair that a person -- not unlike yourself -- who owns an assembly business, should be able to attempt to sell whatever they choose? You think someone else's private business should be forced to sell what you want to buy?
The problem is that it's not the manufacturers that *want* to do this. If so, they could have done more by now. They've done the bare minimum that MS demands. It is not in their interest to potentially restrict OS choice, and the anti-rootkit benefits are dubious (unless *maybe* if you lock down only to MS). The problem is measures like this have a large potential to be very anti-competitive, which may be a lost cause since being a convicted monopolist hasn't really slowed them down in the least.
Used to be, you could purchase a computer with no OS at all. Now, the law says that it's illegal to do so.
Show me this alleged law. I can tell you already that you cannot, because you can buy tower systems all day long without an OS from IBM, Dell, and HP. Generally complete Desktop and laptop vendors don't dare to sell bare-bones systems because of market forces and logistics.
Otherwise, Best Buy would be selling computers without OS's,
WTF are you smoking there? Best Buy won't touch *anything* that could possibly 'confuse' or 'intimidate' a random person off the street.
But you (the greater you) yelled and screamed about a decade ago, forcing Best Buy to only sell computers with an OS.
I do not recall *anyone* (apart from Microsoft themselves) begging any government to forbid bare bones systems...
If you buy from Best Buy, you bought from a system builder who bought from Microsoft nearly certainly. Ignoring the money they already gave to MS and enabled secure boot by default as well and giving MS *more* money to acquire the *same* software that will also be signed in a way to pass the same secure boot checking is only different in how convoluted the scenario is.
Protesting having this enabled by default is a tad asinine for most desktop users. Demanding that Firmware be mandated to have a configuration setting allowing it to be disabled is reasonable.
There is a crowd of people with a legitimate issue. If you have an unattended mass deployment of non-signed software (e.g. you don't want a 'tech' babysitting any particular system), there is a significant problem. In enterprise system deployment, this could be construed as anti-competitive as MS is the only vendor with the leverage to get their signing keys everywhere.
Overall, however, I think Trusted Boot is a losing game in preventing malware. It means your rootkits have to get bigger and you probably have to build it out of a chain of signed software until you find a weakness, but unless you make the PC fundamentally less usable than it is today, there is going to be a weakness somewhere. For example, if you allow RH signing key and RH just signed grub and then was done with it, suddenly you have a Windows rootkit using grub chainloading malware then Windows.
My point was the 'automated' part in the second point. Human testers with a distinct, fresh perspective from development is crucial, but I've seen too many projects mimnimize the importance of human tests because of some automated test framework in play and that suffices to check off the "should test" checkbox in their minds.
It isn't as rosy as it sounds, at least in my general experience (practice always deviates from theory right?).
The theory is you write your unit tests first, and then code until you pass. In practice two things go wrong:
1) You make a mistake writing unit tests (I have seen many times where *only* buggy code could pass the incorrectly written unit tests).
2) Passing even a well-conceived unit test inspires overconfidence. I have encountered more than a few people who honestly believe passing all unit tests as an automated part of a build process was sufficient and no human testing was required.
In short, sure, officially it endorses testing, but really only speaks much to automated unit tests and less to actually taking the time to let some users dig in and do nothing but make sure those users validate you did the work correctly.
Even relatively recent, dual-core 1.2 Ghz Android devices simply do not have the horsepower to decode a 1080 stream. Note that even a Core2 at 2 Ghz won't even reliably keep up with many 1920x1080 streams, and the performance per clock is better there than ARM.
Now consider the fact that even at full tilt, it will have massive frame drop. Imagine your battery consumption.
The reason I presume Nook hardware decode is limited is because even their hardware decoder couldn't have been architected to do that decode at the price B&N wanted to set. You'll be massively disappointed trying software decode if it is available, as I imagine the Nook color is stingy with the CPU as well.
I don't know about VLC, but mplayer and xbmc do vaapi, vdpau, and dxva2 (windows) specifically because even in intel land, either the CPU will choke or at *least* destroy battery life if it has to decode the stream.
Don't bring technology concerns into a decision based on the neatest sounding name.
Sure, probably a little bit. You build a shoddy little app and you might have an irrational affinity for it even in the face of substantially more functional stuff. Though when you 'build' something (not assemble, as I would characterize IKEA stuff I've seen), you naturally tailor it precisely to your needs, so it generally isn't quite so irrational. The presumption that the market 'resists open source' is FUD/flamebait.
The question is how do the popular open source projects get there. The answer is that generally commercial products are built using a certain model involving marketing, project managers,testers who frequently don't understand the life of the customer, customers with little to no ability to influence the program, architects who rearely, if ever, touch code, and coders "just doing their job". In some cases this works well or at *least* won't be any better in open source land due to various factors. However, a successful open source project includes has the line blurred between intended endusers, test, and development. This means the users get *precisely* what they wanted when things are done. Even if they are not doing a lot of development, they'll participate in discussions on their favorite feature and steer the conversation correctly whenever they see someone misunderstanding. It's the same basic principle as a designed by-and-for-yourself project, but on a larger scale in a healthy community.
In commercial projects, there is a lot of signal loss as their requirements are taken down by someone not really understanding their needs, being distilled further into a short bullet point list of product requirements that ditches any semblance of the subtleties inherent in the requests, which is in turn interpreted and tested by a group who never uses the product for production and never talks to the customer, and then released to a customer who thinks "what the hell is this and what did it have to do with my requests?".
It says very little good actually. Casio undoubtedly has a lot of sunk cost in using Linux, therefore there is nothing to say that they wouldn't have chosen Windows from the start if they knew they'd do this. It also could mean casio agreed to pay some pittance to give MS some ammunition in exchange for some other consideration. In other words, there is no unambiguous endorsement of Linux as 'better' to be had.
However, it does say that through legal intimidation large companies can bully their way into revenue without actually doing work.
I mentioned this elsewhere, but AMT (which this is a part of) is a non-starter in the 'server' Intel chipsets at all, and even if it were, the second they drop an emulex or broadcom to drive the networking, it would still become non-working.
Currently, they have this tied to AMT. That only works with a pure Intel implementation (integrated Intel nic, chipset, etc). AFAIK, it's even *specefically* only the 'desktop' chipsets that bother putting in the bits. So your EP/EN/EX platforms are not invited to the party at all, even *if* your vendor didn't put Emulex or Broadcom down. They specifically segmented this off as 'desktop/laptop', and said 'IPMI' is the server equivalent (which covers most of the base capabilities, but omits KVM and has delegated that to proprietary extensions, as real men need nothing more than Serial (even windowws admins).
Ok, so some commands detect if stdout is a terminal and strip formatting and *could* do more drastic things. I don't see how it's any more intuitive to recognize whether every component in a pipe chain is backed by a win32 exe or a cmdlet versus memorizing some commands strip out color codes when piped (I can't think of an example that does something more drastic than stripping color codes, and I can forgive that since the ANSI codes would appear as 'data' counter-intuitively to pipe consumers, it's making the output more like the plaintext that the user sees, not less.
Even the most recent PowerShell terminal is restricted in silly ways (won't let me make it wider than a certain bound, and I have no idea why). Between not having a plain old bourne shell, not doing ssh, and still having text terminals that behave in boneheaded ways, I get frustrated.
It requires a script writer to be a bit more 'programmer' when outputting data. Most admins understand text data like a basic spreadsheet. Good admins can program correctly, but the notion that you throw things like '.toString' in betrays how it's not quite as straightforward as shell.
PowerShell is neat in its own way, but it doesn't excuse MS's 'not invented here' as they have *continually* failed to just include a damn bourne shell and ssh access (the wrapping remote cli invocation in unwieldy WS-Man is just absolutely insane next to ssh, powershell hides it from you but under the covers it is nasty and you don't get to ignore that cross-platform). MS can offer differentiation without precluding compatibility, and this failure to pursue that is what ticks me off very much.
I meant that in powershell.
On a win7/win2k8r2 system, run powershell, type 'ps|cat' In linux, they look the same. In windows, ps|cat prints binary data to the screen instead of the text you get with 'ps'