There's no security value to NAT. NAT does provide a stateful firewall that disallows inbound connections, but you can do that just as well without NAT, and with a great deal more flexibility.
The one thing of some security value to NAT that a firewall doesn't provide is that it at least partially conceals the nature of the network hidden behind it. It's not a particularly big value though as it is definitely security through obscurity; you want a firewall as well. (Using multiple layers of security is a very good plan as it makes things less brittle overall.)
When I lived out in the boonies, my family expected I'd go through the motions, then drop out at 16 to help out on the farm, and really didn't see the point in academic pursuits. But I'd venture the idea that education isn't of importance to the real world basically holds sway everywhere but the suburbs.
So you were with the rural poor working class instead of the urban poor working class. The anti-education attitude is still bad.
You can also try looking at Google's cached results.
That used to work, but Google cache results are now all blocked too - category 'Proxy Avoidance'.
Sounds like your lot have got a bad dose of the Mordacs there. Time to look for work elsewhere. (Yes, there's a recession. So it might take you some time. Don't hand in your notice until you've got a firm offer.)
Take SSL/TLS for example. It is basically protection against a problem that would never happen in reality. What are the chances of someone intercepting your communications link to a website and capturing your credit card numbers? Out of the billions of packets that are flowing through the networks, the chances of someone managing to find the one packet with the 25 bytes of data comprising your credit card number are vanishingly small. The level of access you'd need would mean it'd be easier to just compromise the person's PC directly rather than sorting through all that noise.
Once someone's trapping the message flow, it's trivial to search for particular triggers. The biggest defence is current generations of routers not sending every message to every machine on the local net, but that's not really much of a defence at all. Encryption stops these trivial attacks.
There are problems with SSL as usually deployed:
Most users don't verify that who they've connected to is who they wanted to connect to.
Some CAs are grasping idiots who will sign any old shit if it gets them another dollar.
Mind you, the alternatives are mostly much worse. And in fact SSL can be very good indeed (e.g., when the client has to present a certificate to the server and a private CA that everyone knows about beforehand is the only trust root). It's just that deployment on the scale of the internet is hard; there's just no way to get everyone to know about everyone else before communications start.
100% wrong. Advertising doesn't pay enough for google to be the Iluminati. No, what google does very well is it implements huge backend systems that are cheaper and more reliable than anyone else.
And it's by selling precisely targeted ad space online that they pay for all those backend systems and services. They're profitable and have plenty of costs, so they must have at least one strong income stream. As far as anyone (outside a few who really know) can tell, that's the ad business.
but in many cases, specialized native code implementations, where the passed arguments determine the actual native code path taken and the level of optimization/performance.
Has anyone actually proven this in practice?
I've seen it with mathematics-heavy code written in a style that's not very idiomatic for Java (but still nicer than Fortran, which is what was used for the comparison baseline). I suspect that typical Java code does not get as good a speedup as that due to poor memory management at the user code level and fragmentation of programs into lots of little pieces scattered over a deep inheritance hierarchy (happens too often, hard to optimize very extensively).
OTOH, what a good JIT does seem to do is get rid of the penalty of using an object format that is not native code. (It could go better, but rarely does because the gains from compiling with profiling data available - the typical equivalent in C programming - are usually very small.)
I suspect the US has no problem handing over the information to the Canadians for similar flights.
The way to get back at the US is to require all flights over Canadian airspace by US carriers to stop at a Canadian airport and deplane all passengers and cargo for "security checks" including passing customs. A lot of flights to and from the US go over Canada right now and going round is impractical and expensive.
That wastes a line and increases the amount of scrolling you have to do, for very little gain in code clarity.
Lines are cheap. If it's causing you to have blocks of code that are too long, those blocks of code are too long anyway. (Sometimes you're stuck with long code blocks, but usually not.)
I prefer to use tabs and leave tabs as tabs. Then everyone can have the indentation to be has much or as little as they want (so that it can fit on their narrow or wide screens).
Then put a comment at the top saying how many "spaces" your tab is (or where your tab stops are), then others can read stuff the way you wrote it and still be able to switch to whatever they like.
I prefer to force tabs to be 8, and leave it optional whether or not to use them. That works better with the defaults across lots of software (e.g., web browsers for viewing patches online).
For indentation levels, 3 or 4 spaces seem to work well. Less and it's not distinctive enough (to my eyes), more and it's just wasteful.
You do realize that some of those types of comments aren't really intended for humans anyway, but more for documentation generators like javadoc and doc++ ?
They're still not helping. What you want from comments is that which is not obvious by reading the non-comment parts of the source code or which could be got from the source but only with a lot of effort. Sometimes I'll put pseudocode in a comment to show what I started out with when designing a function (before it got obscured with lots of error handling special cases). Like that it acts as a map to understanding the function implementation.
In most high level languages, description method or function names tell you why as well.
Function (and argument) names don't tell you the why of the function. They tell you why you would call the function. That's an important difference. (For example, a function might be called GenerateUniformRandomNumber(int from, int to), but that does not say anything about the particular algorithm used to do the generation, which might need a few references to the literature on PRNGs to do properly.) If the code has description metadata attached to it then that's quite possibly containing a lot of what is considered by others to be "comment" (even though it's not actually one).
Handhelds such as the iPhone and Android family don't allow for touch typing. Netbooks allow touch typing and as such, they will always have a place as a laptop replacement.
Not just that, netbooks have a display that's about large enough for running an office suite. That lets people really work on the move and with less weight than a laptop. That's an attractive combo, especially for people who are taking a lot of planes or trains. (Myself? I prefer a laptop because that's powerful enough and with a big enough screen for heavy-duty software development. I don't pretend I'm typical.)
Handhelds don't quite replicate that experience, though as we move more of our data and applications online the local operating system will become increasingly irrelevant.
They can't. The form factor is wrong for the display, and the keyboard is inadequate for heavy use. With a netbook you could (as a light user) even have it as a main computer, which would be tremendously convenient. For a handheld to truly challenge that niche, it would need a bigger screen and keyboard, at which point it would be a netbook. Both platform classes have their limitations and their strengths, and the strengths and limitations are intimately connected. Handhelds are more portable, but harder to use for work. Netbooks are less portable (but still more than laptops) and easier to work on. Laptops are less portable again, and yet are very capable machines indeed. Desktops aren't really portable at all unless you turn them off, but can support very intense usage indeed. Servers aren't portable unless you mount the whole rack in a shipping container, and can run the heaviest duty workloads (well, except for supercomputers which these days are really just servers with special plumbing and interconnect which makes them even less portable).
All these classes of platforms are different. Each has its own niche. To propose that one could replace another is to miss the whole point. (There are probably other platform classes too; I don't pretend that's a complete list.)
The OpenFiler argument is that Capital costs (buying a storage solution) involve more scrutiny than recurring Operating costs (staff labor.) This occurs in dysfunctional or under-captialized organizations. Of course, many people work in such organizations. So many, in fact, that the well managed and/or well capitalized organizations may actually be the exceptions.
Fundamentally, that's because for a lot of organizations it is easier to cut capital costs (by canceling or postponing) than staff costs. The problem with cutting staff? You lose the knowledge that those people have, and the chances are that they will have a lot locked up in their heads that isn't written down, no matter what policies you have in place to mitigate this. Recovering from a round of staff cuts can take years, recovering from delaying the purchase of a piece of kit for a year takes not much more than a year and (provided there's nothing gone catastrophically wrong with the old equipment in the meantime) can actually take less in some senses.
If you're working somewhere with plentiful capital budgets, I envy you. (I also expect that you'll probably be growing soon, and that before too long those capital budgets won't seem nearly so plentiful...)
And the fact is, municipal water, while safe to drink, isn't all that great for drinking unless it's filtered.
Depends on where you are. It varies a lot from area to area.
It's almost all great for cleaning with though. If you're seriously thinking of taking a bath in bottled water, that's a sign that you still have more money than sense.
Basically, enabling legacy applications to survive by giving them a slice of a real machine and running them that way is a great crutch. But not more. It would be more efficient to revamp the system and bring it up to contemporary code, but often that's not possible. I blame closed source and companies that wrote it going out of business, but that's me... I could ramble about shortsighted management decisions and putting the life of a company on the line and dependent on the existance of another company, but... I won't.
The open/closed status of the program code has got nothing to do with it. We use virtualization with plenty of code where we have the source (either open source or written in-house) because that lets us greatly improve the utilization of hardware. Why take up a whole rack of servers to do what one modern blade can cope with? (Most servers aren't CPU-bound.) What's more, it can do this without you having to figure out how to get all those silly deployments to work together nicely.
The other good thing about virtualization is that it lets many people have control over their own machines without needing lots of "servers" under desks. That means you can do things like ensuring that everything that the business really depends on has UPS power and sane networking. (I know. Critical stuff shouldn't be put under someone's desk. Virtualization makes it easier to bring reality closer to that ideal.)
Virtualization isn't perfect at all, but it does cure a bunch of problems that crop up in reality and at far less cost than "doing it properly". (For one thing, it's not cheap to build a new datacenter. Even fitting out a new server room isn't something that you want to have to spend on every day.)
People are against showing ID to board a plane but it's what it's going to have to come down to in the end, because the reality is this is the most efficient way to actually catch people who are trying to do bad things vs. trying to simply find the tools used to perform an attack carried by any random person.
That's correct, and that's because that's a real security step (along with things like only allowing checked luggage on if it accompanies someone). It's where you can correlate whether the person is someone who is "likely to be of interest" and where you can verify that the airline is only carrying those who it thinks it is. (Even then, that's not a perfect solution, but a perfect solution would be economically crippling and so won't happen.)
Note that terrorism by suicide bombers is not the only real threat that has to be defended against. Out-and-out crazies are at least as big a problem, and some measures are there to defend against that too. (Note that the "security theater" is much more effective against that threat.)
It isn't just being tied to legacy proprietary applications, it is also being tied to proprietary drivers. Ubuntu developers estimate 70-80% of Ubuntu users are using close-source drivers and/or software. Run on anything other than x86 and your options decrease quickly.
You're making mountains out of molehills for a company of Google's size. If you're shipping the hardware to customers as well as the OS, the whole business of proprietary drivers virtually vanishes. External hardware is just USB or Firewire. Internal hardware you supply the drivers for. You lose a little upgradability, but if you produce a popular hardware platform overall, you'll have enough leverage to work around any issues with the third-party suppliers, even if it requires some give-and-take. (If nothing else, the size of contracts/opportunities on offer is enough to stop a lot of nonsense.)
You only have a problem if you're both small and insist on using open source software all the way. But in that case you should recognize that it's a feature of your situation and at least some of it is in your hands.
Soap, ballot, ammo. So are you guys in the UK on ammo yet? Pretty goddamn close here in the US (for me anyway).
I'm not very excited about this Bill precisely because we're coming up to a general election which the incumbents are unlikely to win. At that point this Bill will be dropped (because it's associated with the previous administration) and we'll be back to square one, and *everyone* knows it. Think instead about it being there to help secure a directorship at a media company or two for outgoing politicians for the duration of the next parliament...
The GEOGRAPHIC north pole doesn't drift appreciably, or flip - ever.
It does drift, slowly and not by very much, but the main reason it doesn't flip over time (well, change its orientation massively with respect to the rest of the solar system) is that we've got a very large satellite to stabilize us. It's been conjectured that without it, there would be no higher life on Earth because the climate would be just too nasty. Thanks, Moon!
Obscurity always wins for the bad guys, companies who make money and governments.
You mean there's a difference between the three?
There are definitely individuals who are "Bad Guys" but neither profit-making corporations or governments. This is completely independent of whether or not you consider either corporations or governments to be "Bad". (FWIW, I consider them to be independent axes; a large organization - government, corporation, whatever - can be overall mainly good or mainly bad. There's no inherent implication involved.)
When will people learn? Never roll your own damn cryptography. No matter how clever or paranoid you are, you're not clever and paranoid enough. Just use AES.
What about real security experts? Are they permitted to roll their own? If not, how can we have new security algorithms invented as weaknesses in old ones are discovered?
Re:And this is a nearly unsolveable problem.
on
GSM Decryption Published
·
· Score: 4, Interesting
At a guess, they didn't use DES back when because DES is computationally intensive, i.e. slow. This is especially important when you've got a small-for-the-day device that runs on batteries and must provide something approaching real-time performance.
It's more likely that the issue was that the US Government of the day (remember, we are talking mid 80s) would have thrown a total wobbly at the use of DES in technology being installed the world over. Crypto is an area where the effective regulatory landscape has changed rather a lot over the past 25 years.
Slashdot Mirror
There's no security value to NAT. NAT does provide a stateful firewall that disallows inbound connections, but you can do that just as well without NAT, and with a great deal more flexibility.
The one thing of some security value to NAT that a firewall doesn't provide is that it at least partially conceals the nature of the network hidden behind it. It's not a particularly big value though as it is definitely security through obscurity; you want a firewall as well. (Using multiple layers of security is a very good plan as it makes things less brittle overall.)
When I lived out in the boonies, my family expected I'd go through the motions, then drop out at 16 to help out on the farm, and really didn't see the point in academic pursuits. But I'd venture the idea that education isn't of importance to the real world basically holds sway everywhere but the suburbs.
So you were with the rural poor working class instead of the urban poor working class. The anti-education attitude is still bad.
Are scientists so greedy, they need each person to pay 15$ for a fucking glance to what they are doing?
Any research institution worth the name will have a site license for the journal. The rest of you should try googling for a preprint...
You can also try looking at Google's cached results.
That used to work, but Google cache results are now all blocked too - category 'Proxy Avoidance'.
Sounds like your lot have got a bad dose of the Mordacs there. Time to look for work elsewhere. (Yes, there's a recession. So it might take you some time. Don't hand in your notice until you've got a firm offer.)
Take SSL/TLS for example. It is basically protection against a problem that would never happen in reality. What are the chances of someone intercepting your communications link to a website and capturing your credit card numbers? Out of the billions of packets that are flowing through the networks, the chances of someone managing to find the one packet with the 25 bytes of data comprising your credit card number are vanishingly small. The level of access you'd need would mean it'd be easier to just compromise the person's PC directly rather than sorting through all that noise.
Once someone's trapping the message flow, it's trivial to search for particular triggers. The biggest defence is current generations of routers not sending every message to every machine on the local net, but that's not really much of a defence at all. Encryption stops these trivial attacks.
There are problems with SSL as usually deployed:
Mind you, the alternatives are mostly much worse. And in fact SSL can be very good indeed (e.g., when the client has to present a certificate to the server and a private CA that everyone knows about beforehand is the only trust root). It's just that deployment on the scale of the internet is hard; there's just no way to get everyone to know about everyone else before communications start.
100% wrong. Advertising doesn't pay enough for google to be the Iluminati. No, what google does very well is it implements huge backend systems that are cheaper and more reliable than anyone else.
And it's by selling precisely targeted ad space online that they pay for all those backend systems and services. They're profitable and have plenty of costs, so they must have at least one strong income stream. As far as anyone (outside a few who really know) can tell, that's the ad business.
but in many cases, specialized native code implementations, where the passed arguments determine the actual native code path taken and the level of optimization/performance.
Has anyone actually proven this in practice?
I've seen it with mathematics-heavy code written in a style that's not very idiomatic for Java (but still nicer than Fortran, which is what was used for the comparison baseline). I suspect that typical Java code does not get as good a speedup as that due to poor memory management at the user code level and fragmentation of programs into lots of little pieces scattered over a deep inheritance hierarchy (happens too often, hard to optimize very extensively).
OTOH, what a good JIT does seem to do is get rid of the penalty of using an object format that is not native code. (It could go better, but rarely does because the gains from compiling with profiling data available - the typical equivalent in C programming - are usually very small.)
I suspect the US has no problem handing over the information to the Canadians for similar flights.
The way to get back at the US is to require all flights over Canadian airspace by US carriers to stop at a Canadian airport and deplane all passengers and cargo for "security checks" including passing customs. A lot of flights to and from the US go over Canada right now and going round is impractical and expensive.
As for the convention of:
{
}
That wastes a line and increases the amount of scrolling you have to do, for very little gain in code clarity.
Lines are cheap. If it's causing you to have blocks of code that are too long, those blocks of code are too long anyway. (Sometimes you're stuck with long code blocks, but usually not.)
I prefer to use tabs and leave tabs as tabs. Then everyone can have the indentation to be has much or as little as they want (so that it can fit on their narrow or wide screens).
Then put a comment at the top saying how many "spaces" your tab is (or where your tab stops are), then others can read stuff the way you wrote it and still be able to switch to whatever they like.
I prefer to force tabs to be 8, and leave it optional whether or not to use them. That works better with the defaults across lots of software (e.g., web browsers for viewing patches online).
For indentation levels, 3 or 4 spaces seem to work well. Less and it's not distinctive enough (to my eyes), more and it's just wasteful.
You do realize that some of those types of comments aren't really intended for humans anyway, but more for documentation generators like javadoc and doc++ ?
They're still not helping. What you want from comments is that which is not obvious by reading the non-comment parts of the source code or which could be got from the source but only with a lot of effort. Sometimes I'll put pseudocode in a comment to show what I started out with when designing a function (before it got obscured with lots of error handling special cases). Like that it acts as a map to understanding the function implementation.
In most high level languages, description method or function names tell you why as well.
Function (and argument) names don't tell you the why of the function. They tell you why you would call the function. That's an important difference. (For example, a function might be called GenerateUniformRandomNumber(int from, int to), but that does not say anything about the particular algorithm used to do the generation, which might need a few references to the literature on PRNGs to do properly.) If the code has description metadata attached to it then that's quite possibly containing a lot of what is considered by others to be "comment" (even though it's not actually one).
Handhelds such as the iPhone and Android family don't allow for touch typing. Netbooks allow touch typing and as such, they will always have a place as a laptop replacement.
Not just that, netbooks have a display that's about large enough for running an office suite. That lets people really work on the move and with less weight than a laptop. That's an attractive combo, especially for people who are taking a lot of planes or trains. (Myself? I prefer a laptop because that's powerful enough and with a big enough screen for heavy-duty software development. I don't pretend I'm typical.)
Handhelds don't quite replicate that experience, though as we move more of our data and applications online the local operating system will become increasingly irrelevant.
They can't. The form factor is wrong for the display, and the keyboard is inadequate for heavy use. With a netbook you could (as a light user) even have it as a main computer, which would be tremendously convenient. For a handheld to truly challenge that niche, it would need a bigger screen and keyboard, at which point it would be a netbook. Both platform classes have their limitations and their strengths, and the strengths and limitations are intimately connected. Handhelds are more portable, but harder to use for work. Netbooks are less portable (but still more than laptops) and easier to work on. Laptops are less portable again, and yet are very capable machines indeed. Desktops aren't really portable at all unless you turn them off, but can support very intense usage indeed. Servers aren't portable unless you mount the whole rack in a shipping container, and can run the heaviest duty workloads (well, except for supercomputers which these days are really just servers with special plumbing and interconnect which makes them even less portable).
All these classes of platforms are different. Each has its own niche. To propose that one could replace another is to miss the whole point. (There are probably other platform classes too; I don't pretend that's a complete list.)
The OpenFiler argument is that Capital costs (buying a storage solution) involve more scrutiny than recurring Operating costs (staff labor.) This occurs in dysfunctional or under-captialized organizations. Of course, many people work in such organizations. So many, in fact, that the well managed and/or well capitalized organizations may actually be the exceptions.
Fundamentally, that's because for a lot of organizations it is easier to cut capital costs (by canceling or postponing) than staff costs. The problem with cutting staff? You lose the knowledge that those people have, and the chances are that they will have a lot locked up in their heads that isn't written down, no matter what policies you have in place to mitigate this. Recovering from a round of staff cuts can take years, recovering from delaying the purchase of a piece of kit for a year takes not much more than a year and (provided there's nothing gone catastrophically wrong with the old equipment in the meantime) can actually take less in some senses.
If you're working somewhere with plentiful capital budgets, I envy you. (I also expect that you'll probably be growing soon, and that before too long those capital budgets won't seem nearly so plentiful...)
And the fact is, municipal water, while safe to drink, isn't all that great for drinking unless it's filtered.
Depends on where you are. It varies a lot from area to area.
It's almost all great for cleaning with though. If you're seriously thinking of taking a bath in bottled water, that's a sign that you still have more money than sense.
... being on the short list for the which hunt when something enviably goes seriously wrong...
Why would you envy something going seriously wrong? Is your life really that fscked up?
Basically, enabling legacy applications to survive by giving them a slice of a real machine and running them that way is a great crutch. But not more. It would be more efficient to revamp the system and bring it up to contemporary code, but often that's not possible. I blame closed source and companies that wrote it going out of business, but that's me... I could ramble about shortsighted management decisions and putting the life of a company on the line and dependent on the existance of another company, but ... I won't.
The open/closed status of the program code has got nothing to do with it. We use virtualization with plenty of code where we have the source (either open source or written in-house) because that lets us greatly improve the utilization of hardware. Why take up a whole rack of servers to do what one modern blade can cope with? (Most servers aren't CPU-bound.) What's more, it can do this without you having to figure out how to get all those silly deployments to work together nicely.
The other good thing about virtualization is that it lets many people have control over their own machines without needing lots of "servers" under desks. That means you can do things like ensuring that everything that the business really depends on has UPS power and sane networking. (I know. Critical stuff shouldn't be put under someone's desk. Virtualization makes it easier to bring reality closer to that ideal.)
Virtualization isn't perfect at all, but it does cure a bunch of problems that crop up in reality and at far less cost than "doing it properly". (For one thing, it's not cheap to build a new datacenter. Even fitting out a new server room isn't something that you want to have to spend on every day.)
It can't even multitask, for god's sake
Yeah, but neither can Apple Macintoshes, unlike my trusty Amiga 500. Something to do with its handle based heap management I think.
That's not been true since OSX Server came out in 1999 (2002 for the desktop version). Why? Because it's essentially Unix under the hood.
Mind you, if you're still touting your Amiga then you probably don't mind sounding a decade out of date. I'll get off your lawn now.
People are against showing ID to board a plane but it's what it's going to have to come down to in the end, because the reality is this is the most efficient way to actually catch people who are trying to do bad things vs. trying to simply find the tools used to perform an attack carried by any random person.
That's correct, and that's because that's a real security step (along with things like only allowing checked luggage on if it accompanies someone). It's where you can correlate whether the person is someone who is "likely to be of interest" and where you can verify that the airline is only carrying those who it thinks it is. (Even then, that's not a perfect solution, but a perfect solution would be economically crippling and so won't happen.)
Note that terrorism by suicide bombers is not the only real threat that has to be defended against. Out-and-out crazies are at least as big a problem, and some measures are there to defend against that too. (Note that the "security theater" is much more effective against that threat.)
You can't find thousands of packages in one repository and not in the other?
Does anybody want those "thousands of packages"? If not, the point is moot.
It isn't just being tied to legacy proprietary applications, it is also being tied to proprietary drivers. Ubuntu developers estimate 70-80% of Ubuntu users are using close-source drivers and/or software. Run on anything other than x86 and your options decrease quickly.
You're making mountains out of molehills for a company of Google's size. If you're shipping the hardware to customers as well as the OS, the whole business of proprietary drivers virtually vanishes. External hardware is just USB or Firewire. Internal hardware you supply the drivers for. You lose a little upgradability, but if you produce a popular hardware platform overall, you'll have enough leverage to work around any issues with the third-party suppliers, even if it requires some give-and-take. (If nothing else, the size of contracts/opportunities on offer is enough to stop a lot of nonsense.)
You only have a problem if you're both small and insist on using open source software all the way. But in that case you should recognize that it's a feature of your situation and at least some of it is in your hands.
Soap, ballot, ammo. So are you guys in the UK on ammo yet? Pretty goddamn close here in the US (for me anyway).
I'm not very excited about this Bill precisely because we're coming up to a general election which the incumbents are unlikely to win. At that point this Bill will be dropped (because it's associated with the previous administration) and we'll be back to square one, and *everyone* knows it. Think instead about it being there to help secure a directorship at a media company or two for outgoing politicians for the duration of the next parliament...
The GEOGRAPHIC north pole doesn't drift appreciably, or flip - ever.
It does drift, slowly and not by very much, but the main reason it doesn't flip over time (well, change its orientation massively with respect to the rest of the solar system) is that we've got a very large satellite to stabilize us. It's been conjectured that without it, there would be no higher life on Earth because the climate would be just too nasty. Thanks, Moon!
You mean there's a difference between the three?
There are definitely individuals who are "Bad Guys" but neither profit-making corporations or governments. This is completely independent of whether or not you consider either corporations or governments to be "Bad". (FWIW, I consider them to be independent axes; a large organization - government, corporation, whatever - can be overall mainly good or mainly bad. There's no inherent implication involved.)
When will people learn? Never roll your own damn cryptography. No matter how clever or paranoid you are, you're not clever and paranoid enough. Just use AES.
What about real security experts? Are they permitted to roll their own? If not, how can we have new security algorithms invented as weaknesses in old ones are discovered?
At a guess, they didn't use DES back when because DES is computationally intensive, i.e. slow. This is especially important when you've got a small-for-the-day device that runs on batteries and must provide something approaching real-time performance.
It's more likely that the issue was that the US Government of the day (remember, we are talking mid 80s) would have thrown a total wobbly at the use of DES in technology being installed the world over. Crypto is an area where the effective regulatory landscape has changed rather a lot over the past 25 years.