People like Linus, Larry Wall and Richard Stallman have become something like heroes among geeks, and I think there's nothing wrong with that. After all, what they have accomplished is quite remarkable. And I really don't think most of the geeks take it too far.
But because of the success of Linux and its potential threat to MS's dominance, the media have caught on to Linus Torvalds, and I think they make it a bit ridiculous sometimes.
I totally disagree that memory allocation is an unnessecary complication. If you are writing Perl code, how can you guarantee that it will run regardless of the amount of memory on the machine running it?
Perl automatically allocates memory for the data you declare, and will automatically increase or decrease allocation for aggregate structures such as arrays and hashes as you add or remove data from them. And it releases that memory for temporary varaiables efficiently if you make good use of the scoping rules, since they can be de-allocated at end of scope (which is one of the main reasons for using Perl 5 properly). It will do this until all of your virtual memory is exhausted.
By default, Perl uses its own malloc, which maintains a pool of memory that is a little larger than what you need for speed. If you want, you can compile the interpreter to use the built-in malloc for stingy memory allocation. But after years of developing Perl on major projects, I have never had to use the stingy malloc option, and have never had an out-of-memory error that wasn't caused by my own bug -- and these have been extremely rare, and have always been found before code went into production.
Even if it does gracefully exit from the code, can you control the execution? What happens if it is some security critical application (e.g. credit card transaction) and you have no idea where the transaction was terminated?
If you get an out-of-memoty error, execution terminates at the point where Perl couldn't get enough memory. If you want, you can force error messages to print a complete backtrace of the calling stack, so you can see exactly where it happened. How you recover depends on what you're implementing. If I'm programming against an Oracle database, for example, I can tell it not to commit transactions until I explicitly say so. With MySQL I can't do that, so I have to come up with some ither precaution.
But frankly, none of this has much to do with the language or even with memory allocation. You need to program critical transations robustly in any language, against any potential failure. How do you expect this to be any better with malloc() and free()? If you write it in C, you better trap the SEGV signal, and your signal handler better do something fast -- and you can define a signal handler in Perl, too.
If you cannot decide where a memory allocation failed then you have not programmed for all eventualities. I see this is the main weakness of Perl.
I couldn't disagree with you more. malloc and free are a major source of bugs and headaches, and they are almost completely superfluous. The fact that Perl makes them invisible is one of its greatest strengths.
I've seen the Dante-esque code written for complicated web applications. Not only is the syntax unreadable, but because of the loose scoping and typing rules, its faulty and a nightmare to reverse-engineer.
This is the most common criticism of Perl, but I am convinced that it reflects on the the programmers more than on the language. A skilled Perl programmer can be counted on to write clear, maintainable code; in recent years, the language has acquired a number of features to make self-documentation very easy. But I, too, have inherited abonimable code, and it has invariably been the due to the cluelessness of my predecessors.
One of the main problems, I think, is that the WWW began to boom while Perl was still in version 4, when it took off as a favored language for CGI programming. Perl 4 had a number of misfeatures that were corrected in Perl 5. But although Perl 5 has been around for years, too many programmers have never unlearned the bad habits they picked up back then.
True, its good that you don't have to worry about memory allocation, exception, etc. But these constructs are there for a very good reason: what happens when your Perl code runs out of memory. It will probably crash irrecovarably.
Of course you have to worry about exceptions, and Perl helps you with that if you use it properly. But the bit about memory allocation is nonsense. You never have to tear your hair out malloc()-ing and free()-ing all over the place in Perl, and a programmer should never have to. You can eat up too much memory in Perl, say by leaking references or allocating arrays that are excessively large, but that again is a sign of poor programming skill. No language can save from your own weaknesses; a less experienced programmer will create much more havoc with malloc() and free() in any case. And Perl doesn't crash on exhausted memory, it exits politely with an error message.
I wrote my first CGI project entirely in C, and I will surely never do that again. In three years of programming, almost every bug I had was caused by malloc's or array allocations that were too short, or string or array manipulations that were off by one or ran off the end. I've never had these problems with Perl.
Strange that ESR didn't mention Sun and Solaris, I would like to have known if he expects them to join the trend.
I can't picture it. Sun has made too much of a commitment to Solaris and is still profiting from it. And as much as I like Linux in particular and open source software in general, I must admit that Solaris is a quality product that doesn't need to be abandoned.
I recently began coding a module for Apache for the first time, and thus got to find out how well the API is documented. I'd say about half of what a programmer needs to know is formally documented, and the rest you have to get by looking through the include directories and at other people's code.
The HTML manual pages in the distribution include a section about the module API, which is quite thorough in some areas, but some of the sections have so far not got past the author's outline. Naturally, some of those incomplete sections cover topics I needed to know more about over the course of my project. I'd say this document is a pretty common specimen in software engineering: The author probably spent as much time as he could with it, and did a very good job in some parts but didn't have time to finish the rest, and it had to get distributed with the software in this incomplete state, or else the distribution never would have happened at all.
There's also a mod_example.c with illustrations of the various handlers. Working sample code like this is a great help, obviously, but mod_example.c isn't perfect either, particularly because it doesn't seem to have been updated for API version 1.3.
All of this helps you understand the general architecture and philosophy of Apache server configuration and request handling, but you'll never get a module written without looking at other module code and perusing include/*.h. For one thing, most of the really useful explanations I've found are programmer comments in the source code. Also, this is the only way you can find out about the useful and tested function calls in the package. Apache has a rich supply of useful code, for everything from MD5 hashing to output formatting to iterating over the request headers and who knows what all, and I've often caught myself trying to re-invent some wheel or another before I realized that another Apache developer had already got the job done.
So what can we conclude about this? The Apache documentation for programmers could clearly be much better, but that has evidently not prevented it from being a remarkably successful project -- and the module API is one of the principal reasons for its success. I guess this is just a fact of life. Good software cannot be completely undocumented, but in all likelihood the documentation will be spotty, very good in some areas, incomplete and out of date in others. The project programmers will always view documentation as a secondary priority. If you really need to know exacly what's going on, there is no substitute for reading the source code.
Re:news at 11 - hackers shut down all M$ computers
on
UCITA is passed
·
· Score: 1
No joke, this sounds fair enough to me. If it will be legal for MS to remotely disable software because they believe that a user has violated a license, how can users retaliate when they believe that MS is the violator? MS has made it clear that they will not pay the refunds that they owe to countless Linux users. Do Linux users get to hack into the Redmond complex and shut down the company until they pay up? Why the hell not?
You mean liberals like Tipper Gore and Bill Clinton?
Tipper Gore the censorship advocate is no liberal.
Bill Clinton, the welfare-abolishing, free-trading, death-penalty-expanding censorship advocate is not even remotely similar to a liberal.
It's just astonishing how people with clearly conservative views are referred to as liberals these days. The political center has shifted so drastically to the right that we hardly have an sense of the center any more.
Taco, I'm happy for you. If I were you, I would have succumbed to a temptation like this much sooner.
I'm reminded of my high school years, when we had factions of The Who and Led Zeppelin fans in constant verbal battle. (All of us affected abonimable British accents, which we learned either from Monty Python or the two bands' concert films.) This was very serious stuff; our debates were impassioned and sometimes hilarious. We were always very objective about it, you know.
Years later, I can finally admit that I always liked The Who a lot (but don't tell any of my classmates I said that). Nevertheless, I'm still a loyal Zeppelin fan. Zeppelin kicks ass.
But where did you get the idea to start off with: Libertarianism looks better by the day? It isn't specific to libertarianism to oppose censorship in the cinema and elsewhere -- that's a civil liberties issue, the sort of thing that libertarians and liberals generally tend to agree about.
One of your recent articles focused on the disparity in Net access between rich and poor and black and white in America. You emphasized that this kind of economic disparity is a moral issue, a kind of moral question politicians should be addressing, and I agreed with you. But a lot of respondents, true to the libertarian world view, saw no moral problem at all. I don't think libertarianism is what you're looking for, Jon.
I think the problem is that companies are making their whole businesses far too dependent on too brittle technology and too few people. So many companies these days simply grind to a halt if their network infrastructure isn't functional, and they often have just a handful of administrators to keep it running. Those people sure are in a good position to demand good pay, but if something goes wrong, they'll just have to keep working and working until it gets better; business is at a standstill until then.
Notice that Morrigan kept going for that long not just because his bosses were telling him to (although they certainly were); he stayed on out of a sense of obligation. Everyone was waiting for him to get the job done, and he felt guilty going home to grab some sleep before it was done.
I'm not a network- or sysadmin, but a programmer for Web sites -- database access and that sort of thing. While a crisis in my area is not quite as disastrous as a broken network, I nevertheless have had projects where some problem (which I didn't necessarily cause) has to be fixed right now and there's no one else besides me who can do it. I suppose I get a lot of job security that way, but in fact the situation creates nothing but stress for both me and the customer.
I don't think businesses are going to be able operate this way for very much longer. What if the only guy you've got who can maintain your network or your Web site gets run over by a truck? Or just gets fed up and leaves? If a company can afford to make itself dependent on some technology, they're going have to afford a team of administrators who can maintain it; who can cover for each other while one of them's off; and who can relieve each other in shifts if a problem is taking too long to solve. Maybe you can't pay three or four sysadmins as much as you can pay one or two, but you can offer them better working conditions and a chance to have lives of their own. I'll bet more than a few admins will take that deal.
This guy has only himself to blame for all of his work.
How the hell do you know? What if it was the idiot before him, the one who got fired, who left the mess for him to clean up? God knows I've been stuck with someone else's pile of crap often enough.
I think this theory is, like, wrong. The universe isn't a subatomic particle in another universe, it's a subatomic particle in itself. I mean, that's my theory. Not like I wanna, you know, fucking blow your mind or anything.
A situation like this, as unpleasant as it is, will eventually work itself out when the "market", i.e. the community of users, decide which software they will use.
One very important factor in that decision is the trust that you are able to place in the author, and that will be effective enough as a brake on miscreant behavior. I know if I read a mailing list full of rantings from the software maintainer, I will be concerned about his ability to responsibly maintain the project; particularly if it leads to something as wasteful as a code fork. If it's bad enough, it'll cost him users and kill the project.
BTW, J.Q. Hacker's text gives me a strong sense of reading just one side of the story. I wonder how the so-called Mr. Jerk would tell it.
Apache for NT IS stable. It may not be as stable as Apache for Linux or Solaris, but how would you know if it was, on NT?
%^) Point taken. Nevertheless, the Apache Group has stated quite candidly that the NT port is not as good as they'd like it to be, and they plan to improve it.
If Apache can get an NT port completed in a reasonable amount of time (say, before W2K is released), it'll be very hard for MS to push IIS so much that they can start dictating protocols, even if IIS is faster. One of the reasons for this, I think, is the existence of so many extension modules for Apache. Is there any such thing as mod_perl, FastCGI, PHP for IIS? (I really don't know.) A heavily loaded site can hardly get by without tools like these.
This was not mentioned in the article. The Apache Group could fend off such an attack if they get a stable port done before MS manages to pull any of these tricks off. And what with the delays in W2K, they could probably do it.
MS must have thought of this, though, and they are probably thinking of ways to hinder Apache for NT. My guess is that W2K will have undocumented system code for TCP/IP, which they'll use to make their own servers faster and more stable, while the documented code will be slow and buggy.
I wholeheartedly agree. Any penalty less severe than breakup would be woefully inadequate, and one of the greatest tragedies for consumers in this century.
There has been talk of the judge imposing injunctions on MS's anti-competitive behavior, but that is clearly not good enough. MS was already enjoined in 1995, and they are facing this trial precisely because they defied that order. One of the witnesses testified that Gates declared, in so many words, that he would not obey the court. The judge cannot respond to this with more wrist-slapping -- he must impose sanctions that will genuinely punish Gates and his company, and deter others in the future.
Re:with that attitude - enjoy unemployment
on
Feature:Geek Jobs
·
· Score: 1
Nice attitude. I take it you're in college? You seem to think you're the only person on the planet who can program Java or some shit like that?
We chew up punks like you for fun in our engineering group.
Oh, you're so virile! The testosterone is dripping off my screen!
So your faux-macho engineering group requires prospective chewy punks to suck up to HR morons who require them to know things that have nothing to do with the job? Well, then it's no wonder you've got so many punks to chew on. Seems to me that you've got too much time to waste.
Maybe one day the current demand for skilled IT workers will subside, and job applicants will have to put up with braindead recruiters and this kind of sorry Stallone imitation, but not these days.
Ya know, a respectable case can be made for Windows beating Linux in the future. Not that I'd agree, but you don't have to make a fool of yourself saying so.
But this is the sort of article that just makes me embarassed for the author.
It's hardly worth commenting on, but I'll reiterate two points. First of all, Unix's age ("30-year-old technology") is a strength, not a weakness. Unix has retained the solutions that have worked well through all that time. NT developers have to re-implement an awful lot from scratch, a good way to repeat history's mistakes.
Second, this is a good example of how political prejudices ("open source is communism!") can ruin someone's ability to make a competent analysis.
Slashdot Mirror
... it just shouldn't be exaggerated.
People like Linus, Larry Wall and Richard Stallman have become something like heroes among geeks, and I think there's nothing wrong with that. After all, what they have accomplished is quite remarkable. And I really don't think most of the geeks take it too far.
But because of the success of Linux and its potential threat to MS's dominance, the media have caught on to Linus Torvalds, and I think they make it a bit ridiculous sometimes.
I totally disagree that memory allocation is an unnessecary complication. If you are writing Perl code, how can you guarantee that it will run regardless of the amount of memory on the machine running it?
Perl automatically allocates memory for the data you declare, and will automatically increase or decrease allocation for aggregate structures such as arrays and hashes as you add or remove data from them. And it releases that memory for temporary varaiables efficiently if you make good use of the scoping rules, since they can be de-allocated at end of scope (which is one of the main reasons for using Perl 5 properly). It will do this until all of your virtual memory is exhausted.
By default, Perl uses its own malloc, which maintains a pool of memory that is a little larger than what you need for speed. If you want, you can compile the interpreter to use the built-in malloc for stingy memory allocation. But after years of developing Perl on major projects, I have never had to use the stingy malloc option, and have never had an out-of-memory error that wasn't caused by my own bug -- and these have been extremely rare, and have always been found before code went into production.
Even if it does gracefully exit from the code, can you control the execution? What happens if it is some security critical application (e.g. credit card transaction) and you have no idea where the transaction was terminated?
If you get an out-of-memoty error, execution terminates at the point where Perl couldn't get enough memory. If you want, you can force error messages to print a complete backtrace of the calling stack, so you can see exactly where it happened. How you recover depends on what you're implementing. If I'm programming against an Oracle database, for example, I can tell it not to commit transactions until I explicitly say so. With MySQL I can't do that, so I have to come up with some ither precaution.
But frankly, none of this has much to do with the language or even with memory allocation. You need to program critical transations robustly in any language, against any potential failure. How do you expect this to be any better with malloc() and free()? If you write it in C, you better trap the SEGV signal, and your signal handler better do something fast -- and you can define a signal handler in Perl, too.
If you cannot decide where a memory allocation failed then you have not programmed for all eventualities. I see this is the main weakness of Perl.
I couldn't disagree with you more. malloc and free are a major source of bugs and headaches, and they are almost completely superfluous. The fact that Perl makes them invisible is one of its greatest strengths.
I've seen the Dante-esque code written for complicated web applications. Not only is the syntax unreadable, but because of the loose scoping and typing rules, its faulty and a nightmare to reverse-engineer.
This is the most common criticism of Perl, but I am convinced that it reflects on the the programmers more than on the language. A skilled Perl programmer can be counted on to write clear, maintainable code; in recent years, the language has acquired a number of features to make self-documentation very easy. But I, too, have inherited abonimable code, and it has invariably been the due to the cluelessness of my predecessors.
One of the main problems, I think, is that the WWW began to boom while Perl was still in version 4, when it took off as a favored language for CGI programming. Perl 4 had a number of misfeatures that were corrected in Perl 5. But although Perl 5 has been around for years, too many programmers have never unlearned the bad habits they picked up back then.
True, its good that you don't have to worry about memory allocation, exception, etc. But these constructs are there for a very good reason: what happens when your Perl code runs out of memory. It will probably crash irrecovarably.
Of course you have to worry about exceptions, and Perl helps you with that if you use it properly. But the bit about memory allocation is nonsense. You never have to tear your hair out malloc()-ing and free()-ing all over the place in Perl, and a programmer should never have to. You can eat up too much memory in Perl, say by leaking references or allocating arrays that are excessively large, but that again is a sign of poor programming skill. No language can save from your own weaknesses; a less experienced programmer will create much more havoc with malloc() and free() in any case. And Perl doesn't crash on exhausted memory, it exits politely with an error message.
I wrote my first CGI project entirely in C, and I will surely never do that again. In three years of programming, almost every bug I had was caused by malloc's or array allocations that were too short, or string or array manipulations that were off by one or ran off the end. I've never had these problems with Perl.
Strange that ESR didn't mention Sun and Solaris, I would like to have known if he expects them to join the trend.
I can't picture it. Sun has made too much of a commitment to Solaris and is still profiting from it. And as much as I like Linux in particular and open source software in general, I must admit that Solaris is a quality product that doesn't need to be abandoned.
... and man, do I feel like a macho adventurer. Harrison Ford ain't got nothing on me!
I recently began coding a module for Apache for the first time, and thus got to find out how well the API is documented. I'd say about half of what a programmer needs to know is formally documented, and the rest you have to get by looking through the include directories and at other people's code.
The HTML manual pages in the distribution include a section about the module API, which is quite thorough in some areas, but some of the sections have so far not got past the author's outline. Naturally, some of those incomplete sections cover topics I needed to know more about over the course of my project. I'd say this document is a pretty common specimen in software engineering: The author probably spent as much time as he could with it, and did a very good job in some parts but didn't have time to finish the rest, and it had to get distributed with the software in this incomplete state, or else the distribution never would have happened at all.
There's also a mod_example.c with illustrations of the various handlers. Working sample code like this is a great help, obviously, but mod_example.c isn't perfect either, particularly because it doesn't seem to have been updated for API version 1.3.
All of this helps you understand the general architecture and philosophy of Apache server configuration and request handling, but you'll never get a module written without looking at other module code and perusing include/*.h. For one thing, most of the really useful explanations I've found are programmer comments in the source code. Also, this is the only way you can find out about the useful and tested function calls in the package. Apache has a rich supply of useful code, for everything from MD5 hashing to output formatting to iterating over the request headers and who knows what all, and I've often caught myself trying to re-invent some wheel or another before I realized that another Apache developer had already got the job done.
So what can we conclude about this? The Apache documentation for programmers could clearly be much better, but that has evidently not prevented it from being a remarkably successful project -- and the module API is one of the principal reasons for its success. I guess this is just a fact of life. Good software cannot be completely undocumented, but in all likelihood the documentation will be spotty, very good in some areas, incomplete and out of date in others. The project programmers will always view documentation as a secondary priority. If you really need to know exacly what's going on, there is no substitute for reading the source code.
No joke, this sounds fair enough to me. If it will be legal for MS to remotely disable software because they believe that a user has violated a license, how can users retaliate when they believe that MS is the violator? MS has made it clear that they will not pay the refunds that they owe to countless Linux users. Do Linux users get to hack into the Redmond complex and shut down the company until they pay up? Why the hell not?
... now that clueless marketdroids are dropping your name.
You mean liberals like Tipper Gore and Bill Clinton?
Tipper Gore the censorship advocate is no liberal.
Bill Clinton, the welfare-abolishing, free-trading, death-penalty-expanding censorship advocate is not even remotely similar to a liberal.
It's just astonishing how people with clearly conservative views are referred to as liberals these days. The political center has shifted so drastically to the right that we hardly have an sense of the center any more.
Taco, I'm happy for you. If I were you, I would have succumbed to a temptation like this much sooner.
I'm reminded of my high school years, when we had factions of The Who and Led Zeppelin fans in constant verbal battle. (All of us affected abonimable British accents, which we learned either from Monty Python or the two bands' concert films.) This was very serious stuff; our debates were impassioned and sometimes hilarious. We were always very objective about it, you know.
Years later, I can finally admit that I always liked The Who a lot (but don't tell any of my classmates I said that). Nevertheless, I'm still a loyal Zeppelin fan. Zeppelin kicks ass.
Katz, great job raising a ruckus at the cinema.
But where did you get the idea to start off with: Libertarianism looks better by the day? It isn't specific to libertarianism to oppose censorship in the cinema and elsewhere -- that's a civil liberties issue, the sort of thing that libertarians and liberals generally tend to agree about.
One of your recent articles focused on the disparity in Net access between rich and poor and black and white in America. You emphasized that this kind of economic disparity is a moral issue, a kind of moral question politicians should be addressing, and I agreed with you. But a lot of respondents, true to the libertarian world view, saw no moral problem at all. I don't think libertarianism is what you're looking for, Jon.
I think the problem is that companies are making their whole businesses far too dependent on too brittle technology and too few people. So many companies these days simply grind to a halt if their network infrastructure isn't functional, and they often have just a handful of administrators to keep it running. Those people sure are in a good position to demand good pay, but if something goes wrong, they'll just have to keep working and working until it gets better; business is at a standstill until then.
Notice that Morrigan kept going for that long not just because his bosses were telling him to (although they certainly were); he stayed on out of a sense of obligation. Everyone was waiting for him to get the job done, and he felt guilty going home to grab some sleep before it was done.
I'm not a network- or sysadmin, but a programmer for Web sites -- database access and that sort of thing. While a crisis in my area is not quite as disastrous as a broken network, I nevertheless have had projects where some problem (which I didn't necessarily cause) has to be fixed right now and there's no one else besides me who can do it. I suppose I get a lot of job security that way, but in fact the situation creates nothing but stress for both me and the customer.
I don't think businesses are going to be able operate this way for very much longer. What if the only guy you've got who can maintain your network or your Web site gets run over by a truck? Or just gets fed up and leaves? If a company can afford to make itself dependent on some technology, they're going have to afford a team of administrators who can maintain it; who can cover for each other while one of them's off; and who can relieve each other in shifts if a problem is taking too long to solve. Maybe you can't pay three or four sysadmins as much as you can pay one or two, but you can offer them better working conditions and a chance to have lives of their own. I'll bet more than a few admins will take that deal.
This guy has only himself to blame for all of his work.
How the hell do you know? What if it was the idiot before him, the one who got fired, who left the mess for him to clean up? God knows I've been stuck with someone else's pile of crap often enough.
Maybe MS and AOL will nuke each other, and we'll be rid of both of them.
...
Both of the Big Browsers will be gone then! Everyone will be using lynx!
I gotta dream, you know
I think this theory is, like, wrong. The universe isn't a subatomic particle in another universe, it's a subatomic particle in itself. I mean, that's my theory. Not like I wanna, you know, fucking blow your mind or anything.
A situation like this, as unpleasant as it is, will eventually work itself out when the "market", i.e. the community of users, decide which software they will use.
One very important factor in that decision is the trust that you are able to place in the author, and that will be effective enough as a brake on miscreant behavior. I know if I read a mailing list full of rantings from the software maintainer, I will be concerned about his ability to responsibly maintain the project; particularly if it leads to something as wasteful as a code fork. If it's bad enough, it'll cost him users and kill the project.
BTW, J.Q. Hacker's text gives me a strong sense of reading just one side of the story. I wonder how the so-called Mr. Jerk would tell it.
%^) Point taken. Nevertheless, the Apache Group has stated quite candidly that the NT port is not as good as they'd like it to be, and they plan to improve it.
If Apache can get an NT port completed in a reasonable amount of time (say, before W2K is released), it'll be very hard for MS to push IIS so much that they can start dictating protocols, even if IIS is faster. One of the reasons for this, I think, is the existence of so many extension modules for Apache. Is there any such thing as mod_perl, FastCGI, PHP for IIS? (I really don't know.) A heavily loaded site can hardly get by without tools like these.
This was not mentioned in the article. The Apache Group could fend off such an attack if they get a stable port done before MS manages to pull any of these tricks off. And what with the delays in W2K, they could probably do it.
MS must have thought of this, though, and they are probably thinking of ways to hinder Apache for NT. My guess is that W2K will have undocumented system code for TCP/IP, which they'll use to make their own servers faster and more stable, while the documented code will be slow and buggy.
I wholeheartedly agree. Any penalty less severe than breakup would be woefully inadequate, and one of the greatest tragedies for consumers in this century.
There has been talk of the judge imposing injunctions on MS's anti-competitive behavior, but that is clearly not good enough. MS was already enjoined in 1995, and they are facing this trial precisely because they defied that order. One of the witnesses testified that Gates declared, in so many words, that he would not obey the court. The judge cannot respond to this with more wrist-slapping -- he must impose sanctions that will genuinely punish Gates and his company, and deter others in the future.
Oh, you're so virile! The testosterone is dripping off my screen!
So your faux-macho engineering group requires prospective chewy punks to suck up to HR morons who require them to know things that have nothing to do with the job? Well, then it's no wonder you've got so many punks to chew on. Seems to me that you've got too much time to waste.
Maybe one day the current demand for skilled IT workers will subside, and job applicants will have to put up with braindead recruiters and this kind of sorry Stallone imitation, but not these days.
Ya know, a respectable case can be made for Windows beating Linux in the future. Not that I'd agree, but you don't have to make a fool of yourself saying so.
But this is the sort of article that just makes me embarassed for the author.
It's hardly worth commenting on, but I'll reiterate two points. First of all, Unix's age ("30-year-old technology") is a strength, not a weakness. Unix has retained the solutions that have worked well through all that time. NT developers have to re-implement an awful lot from scratch, a good way to repeat history's mistakes.
Second, this is a good example of how political prejudices ("open source is communism!") can ruin someone's ability to make a competent analysis.