Search for "kill" in this document. The previous poster probably meant J++ and not J#, which was obviously hopeless and died a quick death. It still stands, however, as a descendent of Microsoft's most prominent effort to kill Java.
Yes, and you'll note that said reply was in response to something comparing animal deaths by solar to animal deaths by wind. This is also known as a wandering discussion, and is usually truncated shortly after the mods show up with "-1, Offtopic" scores, but can be carried out for months once the story is off the front page.
1. There are lots of cases where the only currently-existing way to get data produced is in a patent-encumbered or indecipherably complex format. There's no reworking or resubmitting; there's just one vendor-specific program that does the magic, its storage format, and an export feature that only captures one viewpoint of the data. The only solution in such a case is getting this original storage format changed.
2. In general, I think you're out of touch with the culture at universities. In general, labs are self-managed and do not have anything remotely resembling a general IT department that they run software purchasing decisions by. There's a very good reason for this: maximum independence and self direction enables maximum efficiency in producing worthwhile results. That's partially to blame for the problems that TFA is about—people not sharing research with each other—but what you're proposing is impossible on many levels.
We're talking about people running experiments, here. They may be inventing new kinds of data (and needing to bring in new software tools) on a very regular basis. A university that encumbers this process with red tape about tools of choice is harming its ability to compete as a research institution, which is its ultimate goal. In practice, no university has policies regarding what labs can run on their computers (which, further, are almost always self-purchased by the labs) much less any restrictions on file formatting. The amount of work that would be required to track all of the tools and utilities used by hundreds of graduate students, postdocs and professors is far greater than you seem to assume, (particularly since it would require understanding of the research, in many cases) and would be extremely invasive and disruptive to productivity.
Deciphering some of these formats is, as I've said, non-trivial. Your "start building tools/filters" step is where I take fault, especially when some combinations of closed tools can produce files that aren't lossless, e.g. a Windows metafile of a graph embedded in a FileMaker Pro database. How do you get the data points back out of the graph?
It also doesn't stop the world from continuing to produce files in formats with non-open specifications, even if you've fixed the institutions that have hired you, because you're only treating the symptoms, not the root problem. It ultimately is in the best interest of vendors to be compatible and open, because it's far more convenient for users, and what they want. (And, many organizations and companies are already moving this way, so it's not like no one's ever thought about it.) Consider that this same situation has happened in a number of IT arenas: video encoding being a recent prominent example. When there are open alternatives close enough in quality to closed software—which use widely-supported formats—people tend to prefer them by default. There's no de facto closed standard here, unlike Microsoft Office documents, which is why we often shuffle DNA around in the very simple FASTA format (one line starting with a > for the title of the sequence, and then another line containing the nucleotides, which lacks many useful features.)
As to your other comment: most university IT departments aren't well-prepared for application-specific material. They do things like make sure everyone has a network connection, that the computer labs all work, that every department has its own web-accessible site (which most departments write and maintain themselves), that course scheduling proceeds as normal, etc. Professors are too self-important—and university IT staff are too content to focus on their own material—for their paths to ever cross. The computer situation in most labs I've been to resembles a home LAN, and is generally completely under the control of the lab staff. They wouldn't generally tolerate externally-managed machines, as the time to resolve complications would mean a significant hit to productivity.
To make your batch idea work, you'd have to do the conversions as part of a nightly backup process, requiring no intervention on the part of the user to produce the record. You then have to hope to the gods that you get informed whenever a professor adds a new obscure format to his or her roster, and then personally know enough field-specific information to interpret the format involved. This is a great way to ensure you remain employed forever, but it's not a solution to the problem. And you can bet that running overnight wouldn't be good enough for their every-day conversion needs—many labs are open 24/7 so that staff can get exclusive access to equipment, just like the hackers of the seventies staying up to wait for mainframe access. We need to have a file format flag day, but there's too much mass to do so efficiently.
It may in theory be smarter to budget for data conversion specialists, yes, given their flexibility (we'll assume for simplicity that they're all worth their paychecks), but it's just not practical to do on the scale we're looking at: The average small university would need one per biology/biochemistry/life sciences department, and institutions of that kind of bureaucratic gravitas are hard to move. Rather than pushing for embedding my classmates in every biomedical sciences department in the world, (even though I personally feel that postdocs are staggeringly computer-illiterate sometimes and really need some technically-minded adults to supervise them) it's much more practical to lobby vendors to open their stuff up, so that we can move everything into future-proof formats once, and never have to deal with it ever again.
A lot of biotechnology companies are already appreciating the OSS movement and go so far as to document their file formats in the user's manual for their hardware (e.g. Applied Biosystems's DNA sequencing hardware) but in general, biomedical software companies, such as MacVector and DNAStar from my first example, are still in the "Let's emulate Microsoft!" mindset when it comes to data storage.
You're ignoring my point completely in order to make a stand for your own job security, like an assembly line worker insisting that car-building robots can't cope with the unexpected, and thus car-building robots should be banned. The entire problem can be eliminated by making the data more consistent in the first place. Also, in this case, it's possible that in a few years the people who "already know how to handle it" are dead because the format specs were never released.
I am actually working as a DBA right now supporting a very fucked up genealogy database that uses numbers for table and column names for deliberate obfuscation reasons. This job sucks, because the vendor's shit isn't remotely fucking extensible, and it's a huge amount of work to find the data in its back-end (an old version of Sybase) and manipulate it externally. But at the same time, this database platform provides features that are patent-encumbered and can't be reimplemented, even if we had the money for hiring the developers required. So we have to cope with it. My predecessor left me a book correlating column numbers, table numbers, and data, that had to be reverse-engineered by probing over an SQL connection. We still don't know where significant portions of the input from the UI is stored. All of this was created to prevent customers from migrating away, but that doesn't matter because there's nothing to migrate to.
Your fantasy world that geeks + money = results ignores the amount of pain and suffering that these bad designs are creating in the first place. The whole point of computer technology is to simplify people's lives and work, and data standardization is critical to that, just like quality control of parts was critical to automating assembly lines. Yes, there's still a place for experts, and someone always needs to know how to keep the machines running, but would you personally rather be doing that, or programming the next generation of better automation tools?
Your argument is essentially that of the Luddite. I remind you that there are still artisan textile workers in the world, and suggest that you start your own business pursuing your dreams.
Very nice post—I had no idea that wavelength influenced depth of penetration. I had been under the impression that prior to the oxygen catastrophe, photosynthesizers used the other portions of the spectrum because of better atmospheric transmittance, and that green plants only flourished to exploit the new wavelengths that were being transmitted better. I hadn't considered that most of those photosynthesizers were probably the ancestors of e.g. red algae. Thanks for that insight.
Very true, but unfortunately the "general trend of high-tech gizmos" isn't the only factor at work here. The same principles that keep the US cellular network wrapped up in ridiculous pricing are at work in technology intended for hospital use in most developed countries, even moreso because of insurance affordances. The developer will probably never let that gem out of its grasp, as they risk cutting into their own monopoly; at least, not without hundreds of millions of dollars in licensing fees first. Notice how much of the process they have worked out—they're convinced it's a divine cash cow.
It isn't, but they're still jerks for doing it in the first place. Also, your assumptions about the organization sizes involved are a bit high—often we're talking about labs with two or three PhDs and a handful of masters students. Not a major resource of deep computer expertise, or large enough to have a DBA. That they have to export all of their old material and re-import it into a new format when they upgrade their software is an obstacle (albeit a defeatable one!) to getting things done, and before you know it, you're wasting time and company/grant money.
On top of that, you have the same format obsolescence problem we see with physical media: if DNAStar goes out of business, and everyone switches to MacVector, then Microsoft discontinues support for 32-bit executables in Windows 12, how do we interpret what header bytes 8-12 mean in their proprietary SBD format when we need to access Professor (Emeritus) Recently Deceased's early graduate work on a cancer cure, the programmers have been dead for fifty years, and no format documentation was released because people were expected to export to FASTA first? We may be able to recover the sequence from the file (it's stored in lower-case ASCII) but not the annotations. Laboratory work must be redone to confirm hypotheses about the precise format of the binary-encoded addresses, and this could cost months of work and tens of thousands of dollars (today) if Prof. Deceased was working in mammalian cells, which require very expensive techniques to transform with modified DNA.
In short, the hacker's approach fails here, and hard. Your technique is valid for sensible things like firewall scripts that are all well-commented, but the quantity of file formats in this world that are undocumented (and not self-explanatory) is far greater than that of those which are generally understood. This is the whole point of formats like FASTA and GenBank, and even the hacker's arch-nemesis XML, which are ASCII-encoded and easy to comprehend, but there are many programs that continue to store their material in obscure binary structures for convenience and legacy compatibility, and those companies have yet to cough up any scrap of documentation—in the aforementioned example, MacVector can't read DNAStar's native format, and the manufacturer recommends exporting from the LaserGene suite into a more common format first. Again, hours of headache for semi-computer-literate experimentalists, and potentially months of headache for people digging into historical archives.
Regular expressions are a rudimentary programming language (not Turing-complete) most commonly used for matching strings based on patterns. This is similar to the * and ? wildcards used by Unix- and Windows-derived/inspired operating systems for filenames, but more powerful. The answer to the joke consists of a regular expression containing the following four symbols:
^ indicates the start of a line . indicates any character other than a linebreak * indicates "zero or more repetitions of the previous character $ indicates the end of a line
Thus, the regular expression is starting at one "side", "crossing" any characters it passes over, and stopping at the other "side". This particular road-crossing joke is unique in that it completely describes the method by which the subject crosses the road, instead of just a brief summary of the goal or, as in the few other jokes that use "how" instead of "why", a vague descriptor of the manner in which the road was crossed.
As programmers, I would like to think we are positioned to criticize those who don't respect applicable standards. Simply because a brain-dead decision can be accommodated doesn't mean it deserves to live!
And these are simple things, very often—dozens of different metadata and header formats for wrapping and annotating DNA, for example. Totally bogus.
Well, although you're right, there is still something that I believe is usually called a "clusterfuck" when it comes to data transfer formats for biology and chemistry, and it's not helping the open-ification process any. (Note that this list seems to omit most of the proprietary formats, at least a dozen of which I can name off the top of my head.) It's symptomatic of the commercial land-grab that took place in biomedical computing (mostly) in the nineties.
1. The image is 250 x 250 px at 44 fps.
2. It's so tiny that there's no way it could have a useful FOV for anything macroscopic, much less be able to focus on anything more than a few cm away.
3. This is medical technology we're talking about, so there's probably a hundred-thousand licensing fee to even look at it, even if the camera itself is only a few pennies.
For the security-conscious, all bank forms will now include a ten-page instructional booklet on how to perform an MD5 hash by hand. This will be superseded by a number of handy and free online tools provided by the Russian Business Network.
Well, that's splitting a few more hairs than is common these days, as much as it hurts. Shadowmist (the great grandparent) was not using a mindset that made the distinction. But we can dream, especially now that so many hardware-tweaking sites are using 'to hack' as a positive verb. It's certainly made a resurgence since the dot-com era.
Some conservatives actually debate that these days. There have been a lot of spelling and grammar reforms over the past century, and the kind of Greek that's on the test (looks like Attic, which is arguably the most complex of the Mediterranean languages) is completely incomprehensible to the average modern Greek. The more determined of the aforementioned conservatives maintain a dialect modeled after biblical Greek, but that's still hundreds of years and a major simplification away from Attic.
Actually, this may amuse you: the APIs have been present since Windows NT 4, and fully functional, but no official UI existed until the XP PowerToy came out. LiteStep virtual desktops have taken advantage of native VDM support since forever, IIRC.
I think then perhaps you should stop using "hacker" as a blanket term and accept that many people mean different things by it. Obviously, lifehacker.com doesn't use the word the same way foxnews.com does. Just mentally replace it with "technically-capable and imaginative person with a disinterest in authoritarianism" and your problems will go away.
Security: read this and check out what Exec Shield and PaX do. Microsoft's security strategy has been, for years, reactive—no one there seems to wake up and say "hey, we can go further" when it comes to basic underlying system components. I heard once that no one person really knew the full interior of the Windows kernel because it was so big, and that Russinovich was as close as it got. Mad props to Russinovich, a lot of concern for the rest of the company.
Interoperability: more effort into native POSIX support. Mingw32, Cygwin, SFU, [...] shouldn't have to exist; this is a consequence of too much difference, most of it deliberately engineered for vendor lock-in purposes. If you've ever written a native Windows C++ program, even console-based, you'll know it's a lot more work to interact with the kernel than on a POSIX system. Outside of the core OS, we also have the crap-fest that is SMB.
"Real" command shell: if you think PowerShell is not a joke, then perhaps you're acquainted with its super-compact syntax? Check out this nugget:
PowerShell:
$a = Read-Host "Please enter your name"
bash:
echo "Please enter your name:" read name
A much bigger WTF is the decision to use a back-tick as a line continuation indicator. e.g., if you want to insert a linebreak into an echo statement (oh wait, it's fucking called write-host. So elegant!) you do so like this:
Write-Host `
"This is a continuation of the line."
No \n. Some more absurdities are move-item instead of cmd's move, copy-item instead of cmd's copy, and rename-item instead of cmd's rename. A command-line scripting language should be file-oriented from top to bottom, yet these -item suffixes are in some of the most commonly-used commands! Total bullshit.
Slashdot Mirror
Search for "kill" in this document. The previous poster probably meant J++ and not J#, which was obviously hopeless and died a quick death. It still stands, however, as a descendent of Microsoft's most prominent effort to kill Java.
Yes, and you'll note that said reply was in response to something comparing animal deaths by solar to animal deaths by wind. This is also known as a wandering discussion, and is usually truncated shortly after the mods show up with "-1, Offtopic" scores, but can be carried out for months once the story is off the front page.
1. There are lots of cases where the only currently-existing way to get data produced is in a patent-encumbered or indecipherably complex format. There's no reworking or resubmitting; there's just one vendor-specific program that does the magic, its storage format, and an export feature that only captures one viewpoint of the data. The only solution in such a case is getting this original storage format changed.
2. In general, I think you're out of touch with the culture at universities. In general, labs are self-managed and do not have anything remotely resembling a general IT department that they run software purchasing decisions by. There's a very good reason for this: maximum independence and self direction enables maximum efficiency in producing worthwhile results. That's partially to blame for the problems that TFA is about—people not sharing research with each other—but what you're proposing is impossible on many levels.
We're talking about people running experiments, here. They may be inventing new kinds of data (and needing to bring in new software tools) on a very regular basis. A university that encumbers this process with red tape about tools of choice is harming its ability to compete as a research institution, which is its ultimate goal. In practice, no university has policies regarding what labs can run on their computers (which, further, are almost always self-purchased by the labs) much less any restrictions on file formatting. The amount of work that would be required to track all of the tools and utilities used by hundreds of graduate students, postdocs and professors is far greater than you seem to assume, (particularly since it would require understanding of the research, in many cases) and would be extremely invasive and disruptive to productivity.
Deciphering some of these formats is, as I've said, non-trivial. Your "start building tools/filters" step is where I take fault, especially when some combinations of closed tools can produce files that aren't lossless, e.g. a Windows metafile of a graph embedded in a FileMaker Pro database. How do you get the data points back out of the graph?
It also doesn't stop the world from continuing to produce files in formats with non-open specifications, even if you've fixed the institutions that have hired you, because you're only treating the symptoms, not the root problem. It ultimately is in the best interest of vendors to be compatible and open, because it's far more convenient for users, and what they want. (And, many organizations and companies are already moving this way, so it's not like no one's ever thought about it.) Consider that this same situation has happened in a number of IT arenas: video encoding being a recent prominent example. When there are open alternatives close enough in quality to closed software—which use widely-supported formats—people tend to prefer them by default. There's no de facto closed standard here, unlike Microsoft Office documents, which is why we often shuffle DNA around in the very simple FASTA format (one line starting with a > for the title of the sequence, and then another line containing the nucleotides, which lacks many useful features.)
As to your other comment: most university IT departments aren't well-prepared for application-specific material. They do things like make sure everyone has a network connection, that the computer labs all work, that every department has its own web-accessible site (which most departments write and maintain themselves), that course scheduling proceeds as normal, etc. Professors are too self-important—and university IT staff are too content to focus on their own material—for their paths to ever cross. The computer situation in most labs I've been to resembles a home LAN, and is generally completely under the control of the lab staff. They wouldn't generally tolerate externally-managed machines, as the time to resolve complications would mean a significant hit to productivity.
To make your batch idea work, you'd have to do the conversions as part of a nightly backup process, requiring no intervention on the part of the user to produce the record. You then have to hope to the gods that you get informed whenever a professor adds a new obscure format to his or her roster, and then personally know enough field-specific information to interpret the format involved. This is a great way to ensure you remain employed forever, but it's not a solution to the problem. And you can bet that running overnight wouldn't be good enough for their every-day conversion needs—many labs are open 24/7 so that staff can get exclusive access to equipment, just like the hackers of the seventies staying up to wait for mainframe access. We need to have a file format flag day, but there's too much mass to do so efficiently.
It may in theory be smarter to budget for data conversion specialists, yes, given their flexibility (we'll assume for simplicity that they're all worth their paychecks), but it's just not practical to do on the scale we're looking at: The average small university would need one per biology/biochemistry/life sciences department, and institutions of that kind of bureaucratic gravitas are hard to move. Rather than pushing for embedding my classmates in every biomedical sciences department in the world, (even though I personally feel that postdocs are staggeringly computer-illiterate sometimes and really need some technically-minded adults to supervise them) it's much more practical to lobby vendors to open their stuff up, so that we can move everything into future-proof formats once, and never have to deal with it ever again.
A lot of biotechnology companies are already appreciating the OSS movement and go so far as to document their file formats in the user's manual for their hardware (e.g. Applied Biosystems's DNA sequencing hardware) but in general, biomedical software companies, such as MacVector and DNAStar from my first example, are still in the "Let's emulate Microsoft!" mindset when it comes to data storage.
Oh, Ebenezer. So good of you to drop by.
You're ignoring my point completely in order to make a stand for your own job security, like an assembly line worker insisting that car-building robots can't cope with the unexpected, and thus car-building robots should be banned. The entire problem can be eliminated by making the data more consistent in the first place. Also, in this case, it's possible that in a few years the people who "already know how to handle it" are dead because the format specs were never released.
I am actually working as a DBA right now supporting a very fucked up genealogy database that uses numbers for table and column names for deliberate obfuscation reasons. This job sucks, because the vendor's shit isn't remotely fucking extensible, and it's a huge amount of work to find the data in its back-end (an old version of Sybase) and manipulate it externally. But at the same time, this database platform provides features that are patent-encumbered and can't be reimplemented, even if we had the money for hiring the developers required. So we have to cope with it. My predecessor left me a book correlating column numbers, table numbers, and data, that had to be reverse-engineered by probing over an SQL connection. We still don't know where significant portions of the input from the UI is stored. All of this was created to prevent customers from migrating away, but that doesn't matter because there's nothing to migrate to.
Your fantasy world that geeks + money = results ignores the amount of pain and suffering that these bad designs are creating in the first place. The whole point of computer technology is to simplify people's lives and work, and data standardization is critical to that, just like quality control of parts was critical to automating assembly lines. Yes, there's still a place for experts, and someone always needs to know how to keep the machines running, but would you personally rather be doing that, or programming the next generation of better automation tools?
Your argument is essentially that of the Luddite. I remind you that there are still artisan textile workers in the world, and suggest that you start your own business pursuing your dreams.
Very nice post—I had no idea that wavelength influenced depth of penetration. I had been under the impression that prior to the oxygen catastrophe, photosynthesizers used the other portions of the spectrum because of better atmospheric transmittance, and that green plants only flourished to exploit the new wavelengths that were being transmitted better. I hadn't considered that most of those photosynthesizers were probably the ancestors of e.g. red algae. Thanks for that insight.
Very true, but unfortunately the "general trend of high-tech gizmos" isn't the only factor at work here. The same principles that keep the US cellular network wrapped up in ridiculous pricing are at work in technology intended for hospital use in most developed countries, even moreso because of insurance affordances. The developer will probably never let that gem out of its grasp, as they risk cutting into their own monopoly; at least, not without hundreds of millions of dollars in licensing fees first. Notice how much of the process they have worked out—they're convinced it's a divine cash cow.
But yes, it would be totally frickin' awesome.
It isn't, but they're still jerks for doing it in the first place. Also, your assumptions about the organization sizes involved are a bit high—often we're talking about labs with two or three PhDs and a handful of masters students. Not a major resource of deep computer expertise, or large enough to have a DBA. That they have to export all of their old material and re-import it into a new format when they upgrade their software is an obstacle (albeit a defeatable one!) to getting things done, and before you know it, you're wasting time and company/grant money.
On top of that, you have the same format obsolescence problem we see with physical media: if DNAStar goes out of business, and everyone switches to MacVector, then Microsoft discontinues support for 32-bit executables in Windows 12, how do we interpret what header bytes 8-12 mean in their proprietary SBD format when we need to access Professor (Emeritus) Recently Deceased's early graduate work on a cancer cure, the programmers have been dead for fifty years, and no format documentation was released because people were expected to export to FASTA first? We may be able to recover the sequence from the file (it's stored in lower-case ASCII) but not the annotations. Laboratory work must be redone to confirm hypotheses about the precise format of the binary-encoded addresses, and this could cost months of work and tens of thousands of dollars (today) if Prof. Deceased was working in mammalian cells, which require very expensive techniques to transform with modified DNA.
In short, the hacker's approach fails here, and hard. Your technique is valid for sensible things like firewall scripts that are all well-commented, but the quantity of file formats in this world that are undocumented (and not self-explanatory) is far greater than that of those which are generally understood. This is the whole point of formats like FASTA and GenBank, and even the hacker's arch-nemesis XML, which are ASCII-encoded and easy to comprehend, but there are many programs that continue to store their material in obscure binary structures for convenience and legacy compatibility, and those companies have yet to cough up any scrap of documentation—in the aforementioned example, MacVector can't read DNAStar's native format, and the manufacturer recommends exporting from the LaserGene suite into a more common format first. Again, hours of headache for semi-computer-literate experimentalists, and potentially months of headache for people digging into historical archives.
Do you understand now?
Regular expressions are a rudimentary programming language (not Turing-complete) most commonly used for matching strings based on patterns. This is similar to the * and ? wildcards used by Unix- and Windows-derived/inspired operating systems for filenames, but more powerful. The answer to the joke consists of a regular expression containing the following four symbols:
. indicates any character other than a linebreak
^ indicates the start of a line
* indicates "zero or more repetitions of the previous character
$ indicates the end of a line
Thus, the regular expression is starting at one "side", "crossing" any characters it passes over, and stopping at the other "side". This particular road-crossing joke is unique in that it completely describes the method by which the subject crosses the road, instead of just a brief summary of the goal or, as in the few other jokes that use "how" instead of "why", a vague descriptor of the manner in which the road was crossed.
Now hand in your geek card, forever.
As programmers, I would like to think we are positioned to criticize those who don't respect applicable standards. Simply because a brain-dead decision can be accommodated doesn't mean it deserves to live!
And these are simple things, very often—dozens of different metadata and header formats for wrapping and annotating DNA, for example. Totally bogus.
You had pencils? Why, in my day, (etc.)
I really think we should just ban this form of comment.
Well, although you're right, there is still something that I believe is usually called a "clusterfuck" when it comes to data transfer formats for biology and chemistry, and it's not helping the open-ification process any. (Note that this list seems to omit most of the proprietary formats, at least a dozen of which I can name off the top of my head.) It's symptomatic of the commercial land-grab that took place in biomedical computing (mostly) in the nineties.
1. The image is 250 x 250 px at 44 fps.
2. It's so tiny that there's no way it could have a useful FOV for anything macroscopic, much less be able to focus on anything more than a few cm away.
3. This is medical technology we're talking about, so there's probably a hundred-thousand licensing fee to even look at it, even if the camera itself is only a few pennies.
Stop the presses! I have a brilliant proposal!
They can use MD5 hashes of SSNs instead! Yeah!
For the security-conscious, all bank forms will now include a ten-page instructional booklet on how to perform an MD5 hash by hand. This will be superseded by a number of handy and free online tools provided by the Russian Business Network.
Well, that's splitting a few more hairs than is common these days, as much as it hurts. Shadowmist (the great grandparent) was not using a mindset that made the distinction. But we can dream, especially now that so many hardware-tweaking sites are using 'to hack' as a positive verb. It's certainly made a resurgence since the dot-com era.
Some conservatives actually debate that these days. There have been a lot of spelling and grammar reforms over the past century, and the kind of Greek that's on the test (looks like Attic, which is arguably the most complex of the Mediterranean languages) is completely incomprehensible to the average modern Greek. The more determined of the aforementioned conservatives maintain a dialect modeled after biblical Greek, but that's still hundreds of years and a major simplification away from Attic.
Actually, this may amuse you: the APIs have been present since Windows NT 4, and fully functional, but no official UI existed until the XP PowerToy came out. LiteStep virtual desktops have taken advantage of native VDM support since forever, IIRC.
I think eating pieces of SCO is likely to cause indigestion.
Perhaps you shouldn't have suggested it, then? I mean, you kinda created your own problem here.
Well, I can't take him like that. It's against regulations.
Let's not forget those Libertarians!
I think then perhaps you should stop using "hacker" as a blanket term and accept that many people mean different things by it. Obviously, lifehacker.com doesn't use the word the same way foxnews.com does. Just mentally replace it with "technically-capable and imaginative person with a disinterest in authoritarianism" and your problems will go away.
Right, nice para-trolling. Let's see:
Security: read this and check out what Exec Shield and PaX do. Microsoft's security strategy has been, for years, reactive—no one there seems to wake up and say "hey, we can go further" when it comes to basic underlying system components. I heard once that no one person really knew the full interior of the Windows kernel because it was so big, and that Russinovich was as close as it got. Mad props to Russinovich, a lot of concern for the rest of the company.
Interoperability: more effort into native POSIX support. Mingw32, Cygwin, SFU, [...] shouldn't have to exist; this is a consequence of too much difference, most of it deliberately engineered for vendor lock-in purposes. If you've ever written a native Windows C++ program, even console-based, you'll know it's a lot more work to interact with the kernel than on a POSIX system. Outside of the core OS, we also have the crap-fest that is SMB.
"Real" command shell: if you think PowerShell is not a joke, then perhaps you're acquainted with its super-compact syntax? Check out this nugget:
PowerShell:
$a = Read-Host "Please enter your name"
bash:
echo "Please enter your name:"
read name
A much bigger WTF is the decision to use a back-tick as a line continuation indicator. e.g., if you want to insert a linebreak into an echo statement (oh wait, it's fucking called write-host . So elegant!) you do so like this:
Write-Host `
"This is a continuation of the line."
No \n. Some more absurdities are move-item instead of cmd's move, copy-item instead of cmd's copy, and rename-item instead of cmd's rename. A command-line scripting language should be file-oriented from top to bottom, yet these -item suffixes are in some of the most commonly-used commands! Total bullshit.