California is also the only state on the continental US that still bans domestic ferrets. This ban has more to do with opinion and misinformation than fact. And it ignores an estimated 500K pet ferrets already within California's borders.
I'm not suprised the same attitude is applied to fish.
This leads me to worry that if NASA is deciding what we do next, it will be the same sort of lip service-- just going to the moon for the sake of going to the moon, and not exploring what revolutionary or groundbreaking things that we could do in the process.
On the other hand, this looks like it would involve an increase in NASA's budget. I've heard it charged the problem with NASA's lack of ambition of late is not the leadership, but just that they don't have enough money to do anything more than the bare minimum.
Readers might want to take a look at the CAIB Report. Most of it is directly about the Columbia Accident - obviously. But the report itself covers a lot of territory. That includes gems about NASA's culture. And funding.
Of special interest would be Chapter 5: From Challenger to Columbia. There is a rather telling diagram (Figure 5.3-1 - pg. 102) graphing NASA's budget over the years. There's also a very interesting bit about "earmarking" - Congressional pork-barreling that ties up what little funding NASA gets.
Again - I can't recommend the CAIB Report enough. It offers a very insightful view of NASA. It is chillingly accurate. Anybody who has worked for NASA will find echos of their experience outlined in that report - whether their work directly involved the Manned Space Flight program or not. And any questions about NASA's history or future may very well be answered by this very frank document.
What they should have done is modularize their base product, and sell add-ons. They retain all of their users, all of their mind share, only have to develop one product, AND it can act as a stepping stone into your Enterprise-level services. Hell! They even had the infrastructure to do a single core product all laid out with Red Hat Network. Sell an Enterprise Web Server channel add-on to Red Hat Linux 10 for Enterprise-level prices, and so on. It would have been beautiful. Really.
...
Fedora does NO ONE any good. It's pseudo-managed by Red Hat, but with no guarantees, no support, no Red Hat Network, no Enterprise add-ons...
As I understand it, the whole Enterprise Linux push was not about adding in additional software. It was more about creating a slow-moving target for enterprise software developers like Veritas and Oracle. Developers could feel more comfortable that whatever product they were pushing would be deployed on the same platform in their customer's data center as was used to develop the product.
Sure - there were also some tweaks and bits of different software involved. But that didn't seem to be the push.
But then, I never looked under the hood of RedHat Enterprise Linux. Maybe the salespitch I heard didn't tell the entire story.
Eh? I'm running a nForce2 chipset. No issues. Is this something that automagically happens within the kernel? Or am I failing to enable something to cause this problem? Got a reference?
Perhapse you would like to add a point to copy-and-pasting the Linux Security advisory page? Maybe some context? Some sign of understanding what you're reading?
A couple of points...
1) Note that of the 15 listed advisories:
5 are the same BIND DOS vulnerability
2 (or 3 if you count Turbolinux's mega-update) are the same Ethereal vulnerability (DOS, possible arbitrary code)
2 are the same stunnel hijacking vulernability 2) None of these vulnerabilities lead to a remote exploit (although it could be argued one might be able to create a favorable condition with the ethereal issue)
Sure - Linux runs buggy code too. If that's your point, make it. But this hardly seems to be a suitable response to the parent's (semi-trollish) comment on MS' run of remote exploits.
As I said, its the misconception people have that Windows is 'easy', and anybody can do it.
But as you point this out, you have to keep in mind just who is fostering this perception.
First, it comes squarely from Microsoft. Windows has always been marketed as the easy solution. Even on the server. Heck - Microsoft even claims that Windows admins cost less. The implication here is that your admin doesn't have to be as experienced or skilled.
Secondly, Windows proponents will often push "ease of use". Whenever the *nix vs. Windows jihad starts up in some conversation in these parts, there is always the Windows proponent talking about how much easier it is to set something up in Windows. Or they talk about the ease of a GUI configuration (what's amusing is seeing one talk about how advanced the Windows GUI config utilities are while another says that critics just don't understand the depth of Windows since all they know about is the GUI). I don't bring this up to summon the jihad or get in to a debate about configuration options. The point is that "ease of use" becomes the first and foremost point in a lot of these conversations.
I agree that Windows is much more complex than many seem to believe. But this perception has nothing to do with the *nix camp.
So they try, and fail; for the most part, its hard NOT to work in IT and have no exposure to Windows, but they think being an expert on one platform somehow makes them an expert on another, and so to mask their lack of knowledge, they just say Windows is stupid and not made 'correctly'. Never mind the fact that they dont really understand that most things access the registry in some way, or how to deal with the APIs, proper Windows troubleshooting, etc.
When I was saddled with a Windows server again, I was finding myself asking my Windows friends lots of stupid questions. I had forgotten a LOT over the last few years. But even as I remembered, re-learned, and outright discovered new things about Windows... I still find myself despising the platform. I admit my bias. But that bias comes a dislike for the Microsoft / Windows way of doing things (or more accurately, an appreciation for the *nix way).
Sure. Some Windows critics could probably learn from some time in front of a Windows server. But you're too quick to dismiss all this expressed dislike for Windows as ignorance of the platform.
Im saying if you have to do something, do it right. Complaining doesnt fix problems, nor does sticking your head in the sand and acting like something is 'wrong' just because they dont want to understand it. As I said, theres nothing wrong with not wanting to learn it, but acting like it's worthless knowledge is insulting to those who actually know what they are doing.
I guess I have to agree here. When my new job had me facing a rather horrid Windows system, I buckled down and did what I had to do to administer it. That's involved a lot more Windows knowledge than I've had interest in. And I definitely value the advice from my Windows-knowledgeable friends in dealing with this albatross.
But I still think the Windows way is "wrong". And not from a lack of working with it.
BTW, its pretty lame dissing on MCSE's- the paper ones generally get exposed in the real world, and since there are lots of us out there who can fix most NT issues with our eyes closed, I can very much say a real MCSE is an asset to any company. Its not like there arent paper CCNAs, CNAs, etc.
You're right - a good MCSE is an asset to a company running Windows. Heck - a good admin familiar with his employer's arhictecture is an asset to any company. But I disagree with your dismisal of paper MCSE's.
Maybe its the difference between your working environment and mine. A real possibility since I've worked both within outstanding resource-rich environments and with organizations who, to be polite, are simply cheap. In any case, I have seen a real market for the stereotypical paper MCSE. They exist. And they keep their jobs.
Don't get me wrong - not all MCSEs are of that sort. I've met some very technical Windows types that had a rather in-depth knowledge of the platform. Which has lead to some really great technical discussions (and some very handy exchanges of expertise from time to time). But I've found them to rare.
But its easy to make fun of someone else, especially when they can fix things you cant; most *nix people just wave their hands and complain about Microsoft instead of actually *fixing* the Windows servers. Its a poor craftsman who blames his tools.
This is kind of an odd thing to say. After all, when do we throw a Windows admin at a Solaris system?
Its interesting that the tool anology comes up. The whole reason techies get impassioned about verious systems and whatnot has a lot to do with craftsmen and tools. After all, sysadmins tend to be craftsmen. And while an expert craftsman might be able to make a chair using nothing but a hammer and screwdriver, they're definately going to feel contrained. They won't be able to produce the level of work they know they could with the right tools (or at least tools they are comfortable with).
My work desktop environment right now is Win2K due to various contraints (office automation apps, a few Windows machines I have to keep an eye on, etc). Yet I go to quite a bit of trouble to make that environment as Unix-like as I can. I really prefer that environment. And I've been able to pull off a few things recently that have had my coworkers wowed (thanks to Cygwin).
One last point - I've experienced both sides. I started as a rather oblivious Windows admin. Then I had to pick up some Unix machines and found an environment that I preferred. I will only grudgingly admin a Windows machine from this point on (and I ocassionally still do). I can certainly understand why people do not want to work with Windows systems. But then - I suppose I can sypmathize with anybody who doesn't want to touch *nix (even if I don't agree with them).
Someone claiming that a *nix admin should just learn to fix Windows instead of complaining about it sounds more like ignorance to me than insight.
But if you are a company, hopefully what you profit from is the *addition* of your own work alongside other GPL'ed code, rather than someone else's GPL'ed work alone, which of course they (if anyone) should ideally be profiting from.
OK. That's fine. But this is not encoded within the GPL either.
It would be completely within the allowances of the GPL to download binaries and source code for The GIMP, burn it all on CD, and then sell that CD on eBay. At best - I'm providing the service of downloading, burning, and shipping. I'm a distribution agent. But I don't think that's what you're talking about. In this sense, I'm not adding any of my own work alongside existing code. I'm certainly profiting from other's work. And its all legal.
I believe the easiest way to sum up the GPL for the layman (and hence the company PHB, or whatever) is to describe it as the legal manifestation of the opinion that it is morally wrong to profit from the works of others*.
Except for the fact that there is nothing in the GPL that prohibits profit much less commerce itself.
The GPL is non-intuitive, and does not have any real precident. Because of this, it is widely misunderstood. When somone says free software or open source, they will assume that it is completely free, not GPL. Everyone has been selling OSS as free software, when it is explicitly not.
At first, I was in complete agreement with the idea being expressed here. It falls in line with the popular misconception that "free software" is all about "no cost". From there it isn't too far of a leap to suggest that if source code is included, Open Source code might be mistaken for something in the public domain.
But then - we're talking about professionals in the software industry. Getting software at no cost and not being aware of its licensing is a neophyte's mistake. After all, Open Source software is hardly the first time software has been available without an up-front fee.
Look at the whole range of software commonly referred to as "freeware". Some lump Open Source software under this label. However, freeware also includes quite a range of software licensed under proprietary licenses. Some proprietary licenses limit use - often delimited by commercial or non-commercial use. Sometimes these licenses don't even allow redistribution of the binaries that are freely available from the author's site.
It is very common practice within the Industry for software to be restricted in ways other than cost. And even when a fee is paid, the software in question still involves licensing restrictions. Developers know that this includes software with source code.
In the end, I agree that the GPL and many other Open Source licenses will seem odd to Industry developers. However, shrugging off these restrictions as "non-intutive" is naive. Anybody who has spent any time in the Industry knows that "free" means very little when it comes to licensing. And they should have the basic instinct to investigate and understand the license involved in any software they acquire and use.
paying software development jobs for open source projects are non-existant
Bullshit. RedHat, IBM, SuSE, OSDL are four employers of coders for Open Source projects. Cisco Systems and NASA also have coders on their payroll that develop Open Source software. Dig around - you'll find plenty more.
Is it so much to ask that institutions who have our Really Import Data take some basic steps to protect it? This whole thing could have been rendered moot with something as simple and easy as an encrypted filesystem.
But nobody, nobody is talking about it. So they'll continue putting customer data on laptops, HMOs will keel putting patient records on tablet PCs or shipping it overseas for testing or whatever... I wonder what it'll take to change it...
Hey now. Wells Fargo did put out a memo that may have something to do with this case. Obviously, its all been covered and taken care of.
Investigators knew where to look for the gear not because of unusually intrepid sleuthing but because Krastof allegedly used the computer to log on to an AOL account belonging to the system's owner, Peter Gascoyne.
while it is not a substitute for a good security policy, it is an excellent augmentation.
...
let's use a military analogy (ugh). you may put your soldiers in an armoured transport... but they still wear camoflauge.
And they wear this cammo because they're trying to look like an armored transport? No. Its because they will eventually climb out from behind that armor and expect to operate in the field. At that point, they're very vulnerable. Even when wearing body armor. So the only thing left to do is try to obscure their location. This is certainly a valid tactic in the physical world. However, it doesn't pan out well when we compare it to information security.
Physical analogies fall flat compared to information security. This is because in the physical world, we can't do much to alter the laws of physics. Granted - we spend a lot of time better understanding those laws and designing systems and strategies that were unknown before. But we are ultimately still limited in what we can do with ourselves. And our attackers are also limited.
Back on our example battlefield, our soldier is vulnerable to enemy gunfire. We can't redesign the soldier to alter this vulnerability - so we try to manage it. We either cover him in armor (paying other penalties) or we make him harder to detect (enabling him to eliminate threats faster also helps).
At the same time, our soldier is faced with a somewhat limited threat. There is only so much that can be put on a battlefield without our soldier's knowledge of it. And once it is there, it is simply a matter of finding it and eliminating the threat.
Meanwhile, on our analogical battlefield, we should have been spending the time to recreate our soldier so he wasn't vulnerable to random gunfire. Sure - we can camouflage him. We can obscure who he is or what he is or where he is. Meanwhile, our attackers can pop up from anywhere in the world at any time. They can be any number. They will sometimes fire without direction, often sweeping the entire battlefield - and they can afford to do it since ammunition is inexpensive and plentiful. In short, at any given time any given location is very likely to be under fire. If our vulnerable soldier happens to be in that location, he's toast. It doesn't matter how well hidden he was.
The limitations of the physical world do not apply to the electronic landscape. Therefore, what would be prohibitive or impossible in the physical world are both possible and likely when dealing with information systems.
This is where we get the old tenet critical of "security through obscurity." Its not that obscurity is useless - just nearly so. If whatever you're looking at from a security context relies heavily on obscurity, then it is almost certainly flawed.
Don't get me wrong - I'm not saying that taking the time to obfuscate headers or whatnot is harmful (insofar as it doesn't lead to a false sense of security). However, it IS a rather useless activity. Which is fine if you've got time to burn.
In my experience, there are few infosec or IT folk who have the luxury of an abundance of time. Or money.
Yes, RedHat 9 is considered old by the OSS community, but not by the general public. There are still many people running RH9 out there.
There are lots of people running Win95, Win98, and WinME out there too. Are these versions of Windows "new" or "latest" too? Would it be appropriate to do a review of desktop environments comparing Linux/KDE, OS X, and Win98?
As linux becomes more and more mainstream, the number of security holes shown will increase as well. More people will use linux and more "hackers" will then be attracted to developing viruses and worms that exploit the system. Regardless of what anyone thinks about Windows vs. Linux, everyone must admit that part of the reason more security holes are found in Windows is because there are many more people looking for them.
This belief that Linux is some kind of new kid on the block and untested completely ignores history. First, Linux deployments have existed in considerable strength for years now. It may not be on every desktop. It may be new to some corporate networks. But Linux has been embraced by ISPs and hosting services for far longer than Linux was even an IT industry buzz word.
The target that Linux presents also grows beyond Linux's own install base. Much of what can be attacked on a Linux server is not Linux-specific. Finding exploitable holes in common Unix subsystems can often mean the ability to attack a large base of servers - be they running Linux or common Unix systems (such as *BSD or Solaris).
In short, Linux has been exposed to scritiny for years.
My advice to linux users is to drop any pretense of Linux being infallible and to start using the same caution running a linux-based server as you would running a windows-based server.
There is certainly some good advice here. Linux's critics are right on one thing: Linux is not a silver bullet for security. Information security is a complex issue. Linux can be used to simplify this issue to a point. But popping in a Linux CD and clicking on the affirmitive button until everything installs is not the answer.
Linux advocates should be carefull that while they make their point, they don't oversimply to the extent of being misleading.
Let's be fair. Darl is being truthful here. What he's really talking about is SCO's sharing of information with various industry pundits and investors. The more wool you manage to pull over their eyes, the more wool they see.
This particular wool is simply very carefully processed and crafted. In to a yarn.
This is a joke right? I mean, as much as I dislike Microsoft, it would be good to stop free and blank bashing like that. So now, two weeks after they have announced that they will focus security, old security holes (you know, those made before the change in policy) suddenly becomes inexcusable... Pitiful.
OK. I'm all for sanity checking Microsoft criticisms. Gawd knows its needed sometimes. But let's not get carried away.
Microsoft's very public announcement of an increased focus on security is over a year old. There has definately been time for not only improving future products, but to begin shoring up current products.
But then, its a losing proposition. Critics of Microsoft's publicity campaign pointed out that security isn't a switch one flips. Its not something that drops in place with a month-long crash-corse in coding practice. Microsoft would have to face not only their existing culture - one that produced the current issues - but an existing codebase and associated product lines built on decisions made by that culture. That's a fairly shaky foundation to try to rebuild on.
Microsoft still faces that shaky foundation today.
Yes - its not really fair to claim that any given current issue is "inexcusable". What's inexcusable is the origional PR ploy implying such a fundimental change would be sudden and fast enough to handle the existing issues.
Slashdot Mirror
Of course, with SCO having the origional... you would be creating a derivitive work... and we know how they feel about that...
(besides - they already have such a script triggered by a drop in SCOX)
California is also the only state on the continental US that still bans domestic ferrets. This ban has more to do with opinion and misinformation than fact. And it ignores an estimated 500K pet ferrets already within California's borders.
I'm not suprised the same attitude is applied to fish.
Readers might want to take a look at the CAIB Report. Most of it is directly about the Columbia Accident - obviously. But the report itself covers a lot of territory. That includes gems about NASA's culture. And funding.
Of special interest would be Chapter 5: From Challenger to Columbia. There is a rather telling diagram (Figure 5.3-1 - pg. 102) graphing NASA's budget over the years. There's also a very interesting bit about "earmarking" - Congressional pork-barreling that ties up what little funding NASA gets.
Again - I can't recommend the CAIB Report enough. It offers a very insightful view of NASA. It is chillingly accurate. Anybody who has worked for NASA will find echos of their experience outlined in that report - whether their work directly involved the Manned Space Flight program or not. And any questions about NASA's history or future may very well be answered by this very frank document.
As I understand it, the whole Enterprise Linux push was not about adding in additional software. It was more about creating a slow-moving target for enterprise software developers like Veritas and Oracle. Developers could feel more comfortable that whatever product they were pushing would be deployed on the same platform in their customer's data center as was used to develop the product.
Sure - there were also some tweaks and bits of different software involved. But that didn't seem to be the push.
But then, I never looked under the hood of RedHat Enterprise Linux. Maybe the salespitch I heard didn't tell the entire story.
"I'd like to cooperate, Detective. But... you see... there's the issue of copyright..."
I'd cut back on the mystery meat, if I were you. Judging from your behavior, its got more than the normal FDA approved share of steroids mixed in it.
Eh? I'm running a nForce2 chipset. No issues. Is this something that automagically happens within the kernel? Or am I failing to enable something to cause this problem? Got a reference?
A couple of points...
1) Note that of the 15 listed advisories:
5 are the same BIND DOS vulnerability
2 (or 3 if you count Turbolinux's mega-update) are the same Ethereal vulnerability (DOS, possible arbitrary code)
2 are the same stunnel hijacking vulernability
2) None of these vulnerabilities lead to a remote exploit (although it could be argued one might be able to create a favorable condition with the ethereal issue)
Sure - Linux runs buggy code too. If that's your point, make it. But this hardly seems to be a suitable response to the parent's (semi-trollish) comment on MS' run of remote exploits.
Pretty good if you know how to spice it right. The trick is, knowing you've got crow to eat. How's that mystery meat you're chewing on?
(there's a joke about feeding trolls to be made in this somewhere)
But as you point this out, you have to keep in mind just who is fostering this perception.
First, it comes squarely from Microsoft. Windows has always been marketed as the easy solution. Even on the server. Heck - Microsoft even claims that Windows admins cost less. The implication here is that your admin doesn't have to be as experienced or skilled.
Secondly, Windows proponents will often push "ease of use". Whenever the *nix vs. Windows jihad starts up in some conversation in these parts, there is always the Windows proponent talking about how much easier it is to set something up in Windows. Or they talk about the ease of a GUI configuration (what's amusing is seeing one talk about how advanced the Windows GUI config utilities are while another says that critics just don't understand the depth of Windows since all they know about is the GUI). I don't bring this up to summon the jihad or get in to a debate about configuration options. The point is that "ease of use" becomes the first and foremost point in a lot of these conversations.
I agree that Windows is much more complex than many seem to believe. But this perception has nothing to do with the *nix camp.
When I was saddled with a Windows server again, I was finding myself asking my Windows friends lots of stupid questions. I had forgotten a LOT over the last few years. But even as I remembered, re-learned, and outright discovered new things about Windows... I still find myself despising the platform. I admit my bias. But that bias comes a dislike for the Microsoft / Windows way of doing things (or more accurately, an appreciation for the *nix way).
Sure. Some Windows critics could probably learn from some time in front of a Windows server. But you're too quick to dismiss all this expressed dislike for Windows as ignorance of the platform.
I guess I have to agree here. When my new job had me facing a rather horrid Windows system, I buckled down and did what I had to do to administer it. That's involved a lot more Windows knowledge than I've had interest in. And I definitely value the advice from my Windows-knowledgeable friends in dealing with this albatross.
But I still think the Windows way is "wrong". And not from a lack of working with it.
You're right - a good MCSE is an asset to a company running Windows. Heck - a good admin familiar with his employer's arhictecture is an asset to any company. But I disagree with your dismisal of paper MCSE's.
Maybe its the difference between your working environment and mine. A real possibility since I've worked both within outstanding resource-rich environments and with organizations who, to be polite, are simply cheap. In any case, I have seen a real market for the stereotypical paper MCSE. They exist. And they keep their jobs.
Don't get me wrong - not all MCSEs are of that sort. I've met some very technical Windows types that had a rather in-depth knowledge of the platform. Which has lead to some really great technical discussions (and some very handy exchanges of expertise from time to time). But I've found them to rare.
This is kind of an odd thing to say. After all, when do we throw a Windows admin at a Solaris system?
Its interesting that the tool anology comes up. The whole reason techies get impassioned about verious systems and whatnot has a lot to do with craftsmen and tools. After all, sysadmins tend to be craftsmen. And while an expert craftsman might be able to make a chair using nothing but a hammer and screwdriver, they're definately going to feel contrained. They won't be able to produce the level of work they know they could with the right tools (or at least tools they are comfortable with).
My work desktop environment right now is Win2K due to various contraints (office automation apps, a few Windows machines I have to keep an eye on, etc). Yet I go to quite a bit of trouble to make that environment as Unix-like as I can. I really prefer that environment. And I've been able to pull off a few things recently that have had my coworkers wowed (thanks to Cygwin).
One last point - I've experienced both sides. I started as a rather oblivious Windows admin. Then I had to pick up some Unix machines and found an environment that I preferred. I will only grudgingly admin a Windows machine from this point on (and I ocassionally still do). I can certainly understand why people do not want to work with Windows systems. But then - I suppose I can sypmathize with anybody who doesn't want to touch *nix (even if I don't agree with them).
Someone claiming that a *nix admin should just learn to fix Windows instead of complaining about it sounds more like ignorance to me than insight.
OK. That's fine. But this is not encoded within the GPL either.
It would be completely within the allowances of the GPL to download binaries and source code for The GIMP, burn it all on CD, and then sell that CD on eBay. At best - I'm providing the service of downloading, burning, and shipping. I'm a distribution agent. But I don't think that's what you're talking about. In this sense, I'm not adding any of my own work alongside existing code. I'm certainly profiting from other's work. And its all legal.
Except for the fact that there is nothing in the GPL that prohibits profit much less commerce itself.
At first, I was in complete agreement with the idea being expressed here. It falls in line with the popular misconception that "free software" is all about "no cost". From there it isn't too far of a leap to suggest that if source code is included, Open Source code might be mistaken for something in the public domain.
But then - we're talking about professionals in the software industry. Getting software at no cost and not being aware of its licensing is a neophyte's mistake. After all, Open Source software is hardly the first time software has been available without an up-front fee.
Look at the whole range of software commonly referred to as "freeware". Some lump Open Source software under this label. However, freeware also includes quite a range of software licensed under proprietary licenses. Some proprietary licenses limit use - often delimited by commercial or non-commercial use. Sometimes these licenses don't even allow redistribution of the binaries that are freely available from the author's site.
It is very common practice within the Industry for software to be restricted in ways other than cost. And even when a fee is paid, the software in question still involves licensing restrictions. Developers know that this includes software with source code.
In the end, I agree that the GPL and many other Open Source licenses will seem odd to Industry developers. However, shrugging off these restrictions as "non-intutive" is naive. Anybody who has spent any time in the Industry knows that "free" means very little when it comes to licensing. And they should have the basic instinct to investigate and understand the license involved in any software they acquire and use.
Bullshit. RedHat, IBM, SuSE, OSDL are four employers of coders for Open Source projects. Cisco Systems and NASA also have coders on their payroll that develop Open Source software. Dig around - you'll find plenty more.
Yes. But it won't share. And, in fact, it will act all shocked and smug that you haven't read one of THE important literary works in recent times.
Hey now. Wells Fargo did put out a memo that may have something to do with this case. Obviously, its all been covered and taken care of.
Or not. As the article implies.
Seems Reuters screwed up on the facts.
Huh. I thought Google's customers were those who were buying their technology , not the ones using it.
And they wear this cammo because they're trying to look like an armored transport? No. Its because they will eventually climb out from behind that armor and expect to operate in the field. At that point, they're very vulnerable. Even when wearing body armor. So the only thing left to do is try to obscure their location. This is certainly a valid tactic in the physical world. However, it doesn't pan out well when we compare it to information security.
Physical analogies fall flat compared to information security. This is because in the physical world, we can't do much to alter the laws of physics. Granted - we spend a lot of time better understanding those laws and designing systems and strategies that were unknown before. But we are ultimately still limited in what we can do with ourselves. And our attackers are also limited.
Back on our example battlefield, our soldier is vulnerable to enemy gunfire. We can't redesign the soldier to alter this vulnerability - so we try to manage it. We either cover him in armor (paying other penalties) or we make him harder to detect (enabling him to eliminate threats faster also helps).
At the same time, our soldier is faced with a somewhat limited threat. There is only so much that can be put on a battlefield without our soldier's knowledge of it. And once it is there, it is simply a matter of finding it and eliminating the threat.
Meanwhile, on our analogical battlefield, we should have been spending the time to recreate our soldier so he wasn't vulnerable to random gunfire. Sure - we can camouflage him. We can obscure who he is or what he is or where he is. Meanwhile, our attackers can pop up from anywhere in the world at any time. They can be any number. They will sometimes fire without direction, often sweeping the entire battlefield - and they can afford to do it since ammunition is inexpensive and plentiful. In short, at any given time any given location is very likely to be under fire. If our vulnerable soldier happens to be in that location, he's toast. It doesn't matter how well hidden he was.
The limitations of the physical world do not apply to the electronic landscape. Therefore, what would be prohibitive or impossible in the physical world are both possible and likely when dealing with information systems.
This is where we get the old tenet critical of "security through obscurity." Its not that obscurity is useless - just nearly so. If whatever you're looking at from a security context relies heavily on obscurity, then it is almost certainly flawed.
Don't get me wrong - I'm not saying that taking the time to obfuscate headers or whatnot is harmful (insofar as it doesn't lead to a false sense of security). However, it IS a rather useless activity. Which is fine if you've got time to burn.
In my experience, there are few infosec or IT folk who have the luxury of an abundance of time. Or money.
There are lots of people running Win95, Win98, and WinME out there too. Are these versions of Windows "new" or "latest" too? Would it be appropriate to do a review of desktop environments comparing Linux/KDE, OS X, and Win98?
Ever sit on a Solaris box and go "Gee - I miss GNU's tar." And then install it; completely replacing the as-shipped version?
Try that with Internet Explorer.
This belief that Linux is some kind of new kid on the block and untested completely ignores history. First, Linux deployments have existed in considerable strength for years now. It may not be on every desktop. It may be new to some corporate networks. But Linux has been embraced by ISPs and hosting services for far longer than Linux was even an IT industry buzz word.
The target that Linux presents also grows beyond Linux's own install base. Much of what can be attacked on a Linux server is not Linux-specific. Finding exploitable holes in common Unix subsystems can often mean the ability to attack a large base of servers - be they running Linux or common Unix systems (such as *BSD or Solaris).
In short, Linux has been exposed to scritiny for years.
There is certainly some good advice here. Linux's critics are right on one thing: Linux is not a silver bullet for security. Information security is a complex issue. Linux can be used to simplify this issue to a point. But popping in a Linux CD and clicking on the affirmitive button until everything installs is not the answer.
Linux advocates should be carefull that while they make their point, they don't oversimply to the extent of being misleading.
Let's be fair. Darl is being truthful here. What he's really talking about is SCO's sharing of information with various industry pundits and investors. The more wool you manage to pull over their eyes, the more wool they see.
This particular wool is simply very carefully processed and crafted. In to a yarn.
OK. I'm all for sanity checking Microsoft criticisms. Gawd knows its needed sometimes. But let's not get carried away.
Microsoft's very public announcement of an increased focus on security is over a year old. There has definately been time for not only improving future products, but to begin shoring up current products.
But then, its a losing proposition. Critics of Microsoft's publicity campaign pointed out that security isn't a switch one flips. Its not something that drops in place with a month-long crash-corse in coding practice. Microsoft would have to face not only their existing culture - one that produced the current issues - but an existing codebase and associated product lines built on decisions made by that culture. That's a fairly shaky foundation to try to rebuild on.
Microsoft still faces that shaky foundation today.
Yes - its not really fair to claim that any given current issue is "inexcusable". What's inexcusable is the origional PR ploy implying such a fundimental change would be sudden and fast enough to handle the existing issues.