64-bit processors are overly expensive and will stay that way until market share provides enough economy of scale for the productions to be ramped up to make them cheap enough for the masses. It's all about acceptance. The Alpha isn't making it because it just lacks acceptance. While I'd agree it is better than IA-32, there are 2 reasons I'm not using Alpha. The first is Alpha is too expensive (but if it became accepted that might no longer be the case). The second is because it's not really all that great a CPU (as an example, some instructions, like divide, take way too long). If I had to do 64-bit today, it would more likely be UltraSparc. I look forward to Itanium, though I suspect Intel will try to rape the market with high prices on it for as long as they can.
Time and time again we hear the call for standardizing something.
The common argument tossed out is that such and such standard is needed if Linux is to succeed.
I say baloney! to that.
Linux will survive, grow, and prosper, on the basis of what has made it do so, so far: its diversity and opportunity to try things in a different way.
If we are going to standardize something, then maybe what we should standardize on first is a single type of user.
Afterall, if we only have one type of user to have to deal with, then we don't have to deal with a diversity of needs
and we can focus on exactly what this one type of user does need.
Then we can have just one distribution, one filesystem layout, one package format, one window manager.
Hell, we might even be able to narrow it down to just running a single application.
Then Linux will RULE!.
One of the things that annoys me greatly is packages that install stuff into my system configuration. I want total control over my system, including what services are started at boot time, and in what order.
OTOH, I can understand someone else not understanding at all how the system starts up, and wants the package to take care of that (if its a service to be run). Part of the difficulty of all this is that we have not standardized on one kind of user.
It was said before. If your package needs a mail agent be installed, how are you going to make sure it works when I have qmail installed instead of sendmail?
A source install package manager will also need to properly integrate local hacks/patches to the package. If it doesn't do that, then I won't be able to use it for those source packages I do have my own code hacks to (several of them, such as apache, bind, ssh, qmail). There will also need to be a standardized place for it to find any "local modifications to source" for a given package so it can automatically include them.
The goals of newbie users and the goals of sophisticated power admins are very different. RPM probably is a fine choice for newbies and others who may be more experience but don't care to worry about the administration of what is installed, especially on a home or office desktop.
OTOH, for someone like me that cares about what is installed, how it is installed, where it is installed, and the overall security of my server, I have found that RPM just gets in the way and increases the frustration. I'm personally dealing with details that RPM is supposed to help me avoid dealing with, because I need to deal with them, not avoid them. RPM is definitely NOT easy for everyone.
The correct answer is, there is no one size fits all. Standardizing on a single packaging format is the wrong thing to do, unless we want to standardize on one type of user (which the other user types are not going to be happy about, at all).
The RIAA may be looking out for the interests of its musicians, but that is only a side effect, or a front, depending on how you look at it. What they are really looking out for is the interests of their corporate music publishing members, who take a much larger chunk of every dollar, peso, pound, mark, franc, or ruble spent on CDs.
Much of that pays for CD manufacturing, distribution, marketing, and so on, and the associated profits realized to the owners of that business. That in itself is not evil. But the internet is clearly going to make that aspect of music less important (if not eventually obsolete). We just won't need that in the future, but the RIAA and its members are indeed struggling to keep hold of their revenue sources amidst all this change.
One thing of interest to note is that a great deal of investment is made by the music industry to get an unknown name artist started. What the internet now does is make that cost virtually disappear.
If you don't like C, fine. But I do like C and I use C. Again, fine. Different code for different folks. Where you're wrong is making a blanket statement as to why people use C. I won't deny that you could find people who actually believe that reason. I use C for entirely different reasons. But I won't tell you what the reasons are, because I'm not flaming you about specific reasons; I'm flaming you for generalizing totally inappropriately.
There actually are people who are very knowledgeable about these things AND want a permanent fulltime job where they work these things all the time. Trouble is, employers don't want to keep paying the higher salary of someone qualified. They want to get the consultant in, have the setup done and documented, and then get the consultant out. After that, they just want a cheap warm body. It won't do any good to train them, because if you do, they will get a batter job as a consultant, and move on. The company will then hire another warm body.
If some of these companies would just get off their duff and quit whining about there being not enough people, and just hire a couple of the many that really are out there, then maybe we wouldn't have some much of this. The trouble is, the suit types either are afraid to deal with technical people (remember, suit types and tech types don't talk the same language and neither wants to learn the other's language in a mutual standoff) or are afraid to have a tech type making as much as, if not more than, a suit type manager.
Just permit your own IP blocks as source address for outgoing packets, and deny everything else. If you have too many netblocks to do that with, then you need to get aggregated. If you don't, then you're part of the problem (e.g. flooding BGP4 prefixes).
There is a way to do this without burning up all the CPU. In an access-list, the more netblocks you have, the more filter rules you have, and each one bogs down the CPU more an more. The correct solution is different than an access-list. But it needs to be coded directly into IOS and the interface processors.
The logic for this borrows from routing. When a packet arrives on an interface, it will eventually be routed by means of looking up the destination address in the routing tables (and route-maps where configured). What needs to be done first is to use the source address of the packet and do a lookup in the route table. But instead of selecting the best route (lowest metric) just compare the arriving interface with the interface of any valid outgoing route that would be used if the source were a destination. If it matches up, let the packet go on. If not, drop it on the floor.
Once implemented, it would be just a matter of turning it on. Actually, this feature should be on by default. Someone once told me that this feature did exist, but they couldn't say what the command for it was.
Initially the FCC was not involved. My grandfather started a cable TV system in 1952 and the only government involved was the city telling him how to wire things when it involved their streets or poles. He didn't have a franchise or anything. Installation fees were $250 (which is a helluva lot more than that in today's dollars). There were 2 channels both from over 140 miles away. He had one employee. Since it was deep in the mountains of West Virginia, there was no TV without it.
You are correct about the basic reasons the FCC got involved. At first it was simple stuff like non-duplication. Why would I turn to the slightly snowier out of town DX station to get an NBC program when my local NBC affiliate carried it crystal clear?. The rule didn't apply then even if the very same show was time shifted. Apparently the broadcasters feared that people would watch local shows from the distant station and just not change the channel when the network program came on. It only got worse.
Some regulations on issues such as leakage from cable lines were necessary. Some special cable channels had the same frequencies as the aircraft radio services. Those should remain, but will obviously become more and more irrelevant as cable systems gradually migrate to immense bandwidth digital fiber.
Don't discount the funding potentials of the coming landline digital broadcasting services. While big corporations did get caught napping when the Internet came along, be aware that they have now woken up. They may not understand it all, yet, but they realize the huge potential of the technology that this has created. While I'm sure many big broadcasters will whine, others will invest. It's probably the small broadcasters that will loose out. Because the Internet itself already has a head start on this technology, I think the momentum is there to the point where it cannot be stopped even by the FCC, even if they wanted to, which I doubt because of the big name financing that is getting into this which will make the pre-Internet cable conglomerates look like Ma and Pa Cable TV partnership.
I just hope the FCC puts the vacated radio spectrum to proper use (handheld wireless access).
This would not be happening if people would just realize they don't need to use ICANN, NSI, etc. There are a number of ways to NOT use them. One of them is to use a different root zone. Once you have a root zone, you can make it point to your own.COM zone, which can have whatever domains you want, plus have a wildcard default to go to some other server (NSI?) for what isn't there.
Every DNS server that uses ICANN/NSI servers is a vote for their continued abuse of identity vs. trademark.
Depends on whose root zone you use. If you use the ICANN/NSI root zone, then you're right, the TLD.mp3 doesn't exist. I guess there are some things you haven't discovered, yet.
Open Source has far more advantages than just the ability to make Linux a functional OS. As a system administrator who knows how to program, it's a means by which I can have control over, and effectively manage, the systems I need to keep up and running.
One of the assertions made by Bill Gates regarding the stability of Windows is that many of the faults (I think he was trying to suggest that it was all of the faults) for crashes lie with third party drivers (many even distributed with Windows itself). With the increasing popularity of Linux, the concept of drivers written by third parties will be seen more and more. Some will be open source and some will not be. But what I suspect is likely to happen is that a lot of it will be poorly written. Those which are open source can be reviewed and fixed, maybe by the user, and maybe by the kernel development crew. It might even get included in the standard kernels (you can be sure a binary-only driver will not be).
One of the things that I believe open source brings is quality.
It would seem to me that the design of this hardware was made under the assumption that the driver would be closed source, and perhaps only for Windows. If I had some cool idea of a piece of hardware (like something that was faster, smarter and just better than the competition) I would put all that technology into the hardware (count the firmware that drives the onboard CPU as part of that hardware for this purpose) and let the driver be nothing more than the communication path between the abstract requests/responses the applications see, and the physical functions performed by the hardware and/or it's processor.
It's awfully easy for me to assume the driver is doing more than it should, much like the driver in the infamous winmodems that let US Robotics make the modem cheaper, eating up more of your CPU power to do stuff like compression. That was definitely the opposite of an accelerated card.
Maybe the design cycle for the next version of the hardware needs to be pushed up sooner, and this time with all the proprietary and trade secret functions hidden away in a tamper-proof chip, and a simpler hardware-to-software interface.
I suggest that the State Department provide a list of IP addresses which they want download refused for, and no more than that. It should be possible to get the addresses connecting "Cuba, Iran, Iraq, North Korea and others considered America's foes". This is sufficiently practical to manage and can be smoothly automated. Any more than that and I will certainly see it as excessive government interference in the private sector.
You're kidding, right? I hope so. Your first paragraph stated that any terrorist can easily gain access to encryption software through alternative channels, or even from within the US itself (it isn't hard to visit the US with the sole intention of blowing up the World Trade Center).
No, I'm not kidding. However the purpose is because I expect the US government to continue to have some kind of bureaucracy involved in the exporting process. That's the nature of the beast. Ideally there should be none at all. Realistically I expect there to be some, and my suggestion is what form that should be. Sorry, I should have made that clearer.
Then you casually describe a process that is sufficiently practical to manage and can be smoothly automated. Yeah, right. "Government" and "smoothly automated" should never go together. And even if our government is as capable as you feel it is, to then maintain a list of IP addresses that are from "problem" countries is impossible. And even if it was possible and feasable, it could be easily circumvented:
Of course you're right, it can easily be circumvented. The point I was making was that if the government is going to require we do something to prevent export to those countries, they should allow us to do it in a way that does not impose on those who are not in those countries. For example I just recently downloaded SecureCRT and had to fill in a form attesting that I was located in the United States. I want to get rid of that process altogether. The government may not want to get rid of all processes, hence my suggested alternative.
There is no real solution. Imposing zone-type laws on the Internet will not work in the long run. The Internet was not designed with security as the foremost thought. Reliability and more importantly a de-centralized topology were the goals.
In the long run, I expect that pro-business George W. Bush will become the next president, and these export restrictions will eventually evaporate. Even still, there will probably be some kind of restriction to those "hated" nations. I have no idea what they might be.
In a speech before the Citizens Crime Commission of New York last July, FBI Director Louis Freeh warned that encryption systems in the wrong hands were a threat to the nation's security.
Louis Freeh was never able to show that if the Unite States blocked all its encryption products from export, that this would result in terrorists being unable to get that encryption. His agenda was pure fantasy.
"A terrorist operating without a lot of sophistication, targeting a hospital, a stock exchange, a power grid, or informational systems upon which we all depend poses all kinds of different, complex but imminent threats," Freeh said. "There is real danger in fantastic technologies that are at the beck and call of fairly unsophisticated operators."
And these things are entirely possible to no less a degree even with a total ban on all export restrictions. But take a look and his reference to "fairly unsophisticated operators". That description sure sounds to me like it also fits script kiddies. With his logic, we should suspend free speech to stop such crime. Better yet, suspend the whole US Constitution. That is what many in the upper levels of law enforcement actually want.
Software experts said that although many new encryption systems cannot be broken, their U.S. makers are cooperating with federal law enforcement and intelligence agencies. Somewhere in the future, they said, are so-called quantum computers a billion times more powerful than existing home computers. These would be able to break the most sophisticated encryption systems available today.
Or, make new encryption systems which would have no hope of ever being broken.
World Trade Center bomber Ramzi Yousef, for example, used over-the-counter encryption technology in his laptop computer, according to the FBI. It included two encrypted files that it took FBI experts more than a year to decipher, law enforcement officials said. Among his plans was one to blow up 11 U.S. airliners in the Western Pacific in one day.
If he acquired this technology by means of encryption exported from the USA, then it might give the FBI some level of credibility here. If he did, but could have just as easily acquired it from somewhere else, that credibility is just shot back down. In fact, he was actually in the United States, and could have easily acquired the technology domestically. The only argument the FBI could logically derive from these events is that all encryption must be suppressed by all governments, and a massive world wide search conducted to expunge every bit of it from every corporation and individual on the planet. And we know how easily they could accomplish that. They probably know, too, so I wonder what their real agenda was, other than to just stir up emotions.
Restrictions on U.S. exports to some others would continue. They include Cuba, Iran, Iraq, North Korea and others considered America's foes.
It remains to be seen just what level of bureaucracy will be imposed on this export. The article says "sell". Does that mean we don't get to give it away (in reference to what is already legally free)? Just how much will we be required to put people through to let them download strong encryption software? Will we be able to contribute source code to crypto projects located outside the US?
I suggest that the State Department provide a list of IP addresses which they want download refused for, and no more than that. It should be possible to get the addresses connecting "Cuba, Iran, Iraq, North Korea and others considered America's foes". This is sufficiently practical to manage and can be smoothly automated. Any more than that and I will certainly see it as excessive government interference in the private sector.
Although I normally despise government interference, there are some thing I would accept. While I would NOT want the FCC to decide on what the standards are, I would find it acceptable that the standards be open for compatibility purposes (except communications not crossing a state boundary which the federals have no authority to control).
After such a court order is issued, then they (hopefully) will end up fighting it, and maybe in about a week it will be reversed for causing harm to the functionality of the business... if these technical issues truly are what is involved.
Slashdot Mirror
64-bit processors are overly expensive and will stay that way until market share provides enough economy of scale for the productions to be ramped up to make them cheap enough for the masses. It's all about acceptance. The Alpha isn't making it because it just lacks acceptance. While I'd agree it is better than IA-32, there are 2 reasons I'm not using Alpha. The first is Alpha is too expensive (but if it became accepted that might no longer be the case). The second is because it's not really all that great a CPU (as an example, some instructions, like divide, take way too long). If I had to do 64-bit today, it would more likely be UltraSparc. I look forward to Itanium, though I suspect Intel will try to rape the market with high prices on it for as long as they can.
Time and time again we hear the call for standardizing something. The common argument tossed out is that such and such standard is needed if Linux is to succeed. I say baloney! to that. Linux will survive, grow, and prosper, on the basis of what has made it do so, so far: its diversity and opportunity to try things in a different way.
If we are going to standardize something, then maybe what we should standardize on first is a single type of user. Afterall, if we only have one type of user to have to deal with, then we don't have to deal with a diversity of needs and we can focus on exactly what this one type of user does need. Then we can have just one distribution, one filesystem layout, one package format, one window manager. Hell, we might even be able to narrow it down to just running a single application. Then Linux will RULE!.
... in your dreams!
One of the things that annoys me greatly is packages that install stuff into my system configuration. I want total control over my system, including what services are started at boot time, and in what order.
OTOH, I can understand someone else not understanding at all how the system starts up, and wants the package to take care of that (if its a service to be run). Part of the difficulty of all this is that we have not standardized on one kind of user.
It was said before. If your package needs a mail agent be installed, how are you going to make sure it works when I have qmail installed instead of sendmail?
A source install package manager will also need to properly integrate local hacks/patches to the package. If it doesn't do that, then I won't be able to use it for those source packages I do have my own code hacks to (several of them, such as apache, bind, ssh, qmail). There will also need to be a standardized place for it to find any "local modifications to source" for a given package so it can automatically include them.
The goals of newbie users and the goals of sophisticated power admins are very different. RPM probably is a fine choice for newbies and others who may be more experience but don't care to worry about the administration of what is installed, especially on a home or office desktop.
OTOH, for someone like me that cares about what is installed, how it is installed, where it is installed, and the overall security of my server, I have found that RPM just gets in the way and increases the frustration. I'm personally dealing with details that RPM is supposed to help me avoid dealing with, because I need to deal with them, not avoid them. RPM is definitely NOT easy for everyone.
The correct answer is, there is no one size fits all. Standardizing on a single packaging format is the wrong thing to do, unless we want to standardize on one type of user (which the other user types are not going to be happy about, at all).
The RIAA may be looking out for the interests of its musicians, but that is only a side effect, or a front, depending on how you look at it. What they are really looking out for is the interests of their corporate music publishing members, who take a much larger chunk of every dollar, peso, pound, mark, franc, or ruble spent on CDs.
Much of that pays for CD manufacturing, distribution, marketing, and so on, and the associated profits realized to the owners of that business. That in itself is not evil. But the internet is clearly going to make that aspect of music less important (if not eventually obsolete). We just won't need that in the future, but the RIAA and its members are indeed struggling to keep hold of their revenue sources amidst all this change.
One thing of interest to note is that a great deal of investment is made by the music industry to get an unknown name artist started. What the internet now does is make that cost virtually disappear.
If you don't like C, fine. But I do like C and I use C. Again, fine. Different code for different folks. Where you're wrong is making a blanket statement as to why people use C. I won't deny that you could find people who actually believe that reason. I use C for entirely different reasons. But I won't tell you what the reasons are, because I'm not flaming you about specific reasons; I'm flaming you for generalizing totally inappropriately.
There actually are people who are very knowledgeable about these things AND want a permanent fulltime job where they work these things all the time. Trouble is, employers don't want to keep paying the higher salary of someone qualified. They want to get the consultant in, have the setup done and documented, and then get the consultant out. After that, they just want a cheap warm body. It won't do any good to train them, because if you do, they will get a batter job as a consultant, and move on. The company will then hire another warm body.
If some of these companies would just get off their duff and quit whining about there being not enough people, and just hire a couple of the many that really are out there, then maybe we wouldn't have some much of this. The trouble is, the suit types either are afraid to deal with technical people (remember, suit types and tech types don't talk the same language and neither wants to learn the other's language in a mutual standoff) or are afraid to have a tech type making as much as, if not more than, a suit type manager.
Just permit your own IP blocks as source address for outgoing packets, and deny everything else. If you have too many netblocks to do that with, then you need to get aggregated. If you don't, then you're part of the problem (e.g. flooding BGP4 prefixes).
There is a way to do this without burning up all the CPU. In an access-list, the more netblocks you have, the more filter rules you have, and each one bogs down the CPU more an more. The correct solution is different than an access-list. But it needs to be coded directly into IOS and the interface processors.
The logic for this borrows from routing. When a packet arrives on an interface, it will eventually be routed by means of looking up the destination address in the routing tables (and route-maps where configured). What needs to be done first is to use the source address of the packet and do a lookup in the route table. But instead of selecting the best route (lowest metric) just compare the arriving interface with the interface of any valid outgoing route that would be used if the source were a destination. If it matches up, let the packet go on. If not, drop it on the floor.
Once implemented, it would be just a matter of turning it on. Actually, this feature should be on by default. Someone once told me that this feature did exist, but they couldn't say what the command for it was.
Initially the FCC was not involved. My grandfather started a cable TV system in 1952 and the only government involved was the city telling him how to wire things when it involved their streets or poles. He didn't have a franchise or anything. Installation fees were $250 (which is a helluva lot more than that in today's dollars). There were 2 channels both from over 140 miles away. He had one employee. Since it was deep in the mountains of West Virginia, there was no TV without it.
You are correct about the basic reasons the FCC got involved. At first it was simple stuff like non-duplication. Why would I turn to the slightly snowier out of town DX station to get an NBC program when my local NBC affiliate carried it crystal clear?. The rule didn't apply then even if the very same show was time shifted. Apparently the broadcasters feared that people would watch local shows from the distant station and just not change the channel when the network program came on. It only got worse.
Some regulations on issues such as leakage from cable lines were necessary. Some special cable channels had the same frequencies as the aircraft radio services. Those should remain, but will obviously become more and more irrelevant as cable systems gradually migrate to immense bandwidth digital fiber.
Don't discount the funding potentials of the coming landline digital broadcasting services. While big corporations did get caught napping when the Internet came along, be aware that they have now woken up. They may not understand it all, yet, but they realize the huge potential of the technology that this has created. While I'm sure many big broadcasters will whine, others will invest. It's probably the small broadcasters that will loose out. Because the Internet itself already has a head start on this technology, I think the momentum is there to the point where it cannot be stopped even by the FCC, even if they wanted to, which I doubt because of the big name financing that is getting into this which will make the pre-Internet cable conglomerates look like Ma and Pa Cable TV partnership.
I just hope the FCC puts the vacated radio spectrum to proper use (handheld wireless access).
For what purpose do all broadcasts need licensing by some government? For censorship? Is censorship why Australian radio and TV is licensed?
This would not be happening if people would just realize they don't need to use ICANN, NSI, etc. There are a number of ways to NOT use them. One of them is to use a different root zone. Once you have a root zone, you can make it point to your own .COM zone, which can have whatever domains you want, plus have a wildcard default to go to some other server (NSI?) for what isn't there.
Every DNS server that uses ICANN/NSI servers is a vote for their continued abuse of identity vs. trademark.
Depends on whose root zone you use. If you use the ICANN/NSI root zone, then you're right, the TLD .mp3 doesn't exist. I guess there are some things you haven't discovered, yet.
Maybe not Zimbabwe. Try Serbia.
Apple can't touch this one!
Open Source has far more advantages than just the ability to make Linux a functional OS. As a system administrator who knows how to program, it's a means by which I can have control over, and effectively manage, the systems I need to keep up and running.
One of the assertions made by Bill Gates regarding the stability of Windows is that many of the faults (I think he was trying to suggest that it was all of the faults) for crashes lie with third party drivers (many even distributed with Windows itself). With the increasing popularity of Linux, the concept of drivers written by third parties will be seen more and more. Some will be open source and some will not be. But what I suspect is likely to happen is that a lot of it will be poorly written. Those which are open source can be reviewed and fixed, maybe by the user, and maybe by the kernel development crew. It might even get included in the standard kernels (you can be sure a binary-only driver will not be).
One of the things that I believe open source brings is quality.
It would seem to me that the design of this hardware was made under the assumption that the driver would be closed source, and perhaps only for Windows. If I had some cool idea of a piece of hardware (like something that was faster, smarter and just better than the competition) I would put all that technology into the hardware (count the firmware that drives the onboard CPU as part of that hardware for this purpose) and let the driver be nothing more than the communication path between the abstract requests/responses the applications see, and the physical functions performed by the hardware and/or it's processor.
It's awfully easy for me to assume the driver is doing more than it should, much like the driver in the infamous winmodems that let US Robotics make the modem cheaper, eating up more of your CPU power to do stuff like compression. That was definitely the opposite of an accelerated card.
Maybe the design cycle for the next version of the hardware needs to be pushed up sooner, and this time with all the proprietary and trade secret functions hidden away in a tamper-proof chip, and a simpler hardware-to-software interface.
No, I'm not kidding. However the purpose is because I expect the US government to continue to have some kind of bureaucracy involved in the exporting process. That's the nature of the beast. Ideally there should be none at all. Realistically I expect there to be some, and my suggestion is what form that should be. Sorry, I should have made that clearer.
Of course you're right, it can easily be circumvented. The point I was making was that if the government is going to require we do something to prevent export to those countries, they should allow us to do it in a way that does not impose on those who are not in those countries. For example I just recently downloaded SecureCRT and had to fill in a form attesting that I was located in the United States. I want to get rid of that process altogether. The government may not want to get rid of all processes, hence my suggested alternative.
In the long run, I expect that pro-business George W. Bush will become the next president, and these export restrictions will eventually evaporate. Even still, there will probably be some kind of restriction to those "hated" nations. I have no idea what they might be.
Louis Freeh was never able to show that if the Unite States blocked all its encryption products from export, that this would result in terrorists being unable to get that encryption. His agenda was pure fantasy.
And these things are entirely possible to no less a degree even with a total ban on all export restrictions. But take a look and his reference to "fairly unsophisticated operators". That description sure sounds to me like it also fits script kiddies. With his logic, we should suspend free speech to stop such crime. Better yet, suspend the whole US Constitution. That is what many in the upper levels of law enforcement actually want.
Or, make new encryption systems which would have no hope of ever being broken.
If he acquired this technology by means of encryption exported from the USA, then it might give the FBI some level of credibility here. If he did, but could have just as easily acquired it from somewhere else, that credibility is just shot back down. In fact, he was actually in the United States, and could have easily acquired the technology domestically. The only argument the FBI could logically derive from these events is that all encryption must be suppressed by all governments, and a massive world wide search conducted to expunge every bit of it from every corporation and individual on the planet. And we know how easily they could accomplish that. They probably know, too, so I wonder what their real agenda was, other than to just stir up emotions.
It remains to be seen just what level of bureaucracy will be imposed on this export. The article says "sell". Does that mean we don't get to give it away (in reference to what is already legally free)? Just how much will we be required to put people through to let them download strong encryption software? Will we be able to contribute source code to crypto projects located outside the US?
I suggest that the State Department provide a list of IP addresses which they want download refused for, and no more than that. It should be possible to get the addresses connecting "Cuba, Iran, Iraq, North Korea and others considered America's foes". This is sufficiently practical to manage and can be smoothly automated. Any more than that and I will certainly see it as excessive government interference in the private sector.
Although I normally despise government interference, there are some thing I would accept. While I would NOT want the FCC to decide on what the standards are, I would find it acceptable that the standards be open for compatibility purposes (except communications not crossing a state boundary which the federals have no authority to control).
WTF can't these corporations hire people that know WTF they are doing? Sheesh!
After such a court order is issued, then they (hopefully) will end up fighting it, and maybe in about a week it will be reversed for causing harm to the functionality of the business ... if these technical issues truly are what is involved.