get the Government out of it altogether and let private capital fund this research.
On the contrary, this is why it makes more sense to point out, like JFK did, that leaders must lead their people, rather than pander to them. Sometimes this means doing things that your constituents do not want, but nonetheless, desperately need.
I think it is high time for a leader who does what is needed and not what is wanted. Whether Obama is the person remains to be seen.
Nonsense. The tradeoff is small. Generally speaking, the politically-motivated decision makers are the appointees. They can set the direction of an organization, but they do not do the work. There are thousands of government scientists. They do good SCIENCE, which by it's very nature is truth-driven. Now whether you consider the pursuit of truth "politically motivated" or not is a matter of interpretation.
My brother works for the BFRL at NIST. Now, a lot of what they work on does not affect you. It's pure science. Fire in zero-G, for instance. This stuff would not be funded by commercial science, and much of it is too expensive for non-profit research institutions.
But this pure science-- it spins off in ways you couldn't imagine ahead of time. Being able to synchronize clocks around the world. Being able to buy something that weighs "1 kg" and knowing that, when you get it, it's the same "1 kg" that you meant.
The BFRL at NIST also looks at lots of practical things. Things like "How can we find people trapped in fires?" or "Can we develop a method for city planners to make smart staffing decisions for fire departments?" These practical things are often a direct consequence of pure science that was published many years before. And the scientists themselves, who work down the hall from each other, interact in many unexpected and positive ways. All of these things are of great value, but in many cases, they would not be done for lack of direct money-making potential. Government science keeps us safe, and it keeps our country competitive. It is absolutely essential.
In the case of the router vulnerability, this is something that you can control on the corporate side of things by simply not accepting packets down the VPN tunnel that don't come from the IP address that's the far endpoint of that tunnel. I'm not a VPN expert, but I would be surprised if this isn't how your VPN is configured by default.
You can also filter packets on the receiving end of the VPN. That's how I configured our firewall at work. The VPN tunnel simply looks like another network interface to our firewall, so I apply a slightly less restrictive set of rules to that connection than I do to the default external interface. Giving someone keys to your network just because they are an authenticated VPN user is not a very good idea.
My main complaint with DNS tampering is the outright DNS hijacking that Sprint does with their AirCard (EVDO) service. You can't even query a different DNS server-- your packets are intercepted and redirected to Sprint's own DNS. Unfortunately, their records are often out-of-date as it appears that they also manipulate TTLs to keep the churn down on their servers. It's a real problem when you're relying on something like an AirCard for doing things like network penetration testing.
It's not copyright-- you are granted a copyright automatically under US law. I believe you are thinking of trademarks, which have nothing to do with DRM.
As someone who is involved with having to decide whether DRM goes into our products or not (I work for a book publisher), I can tell you that we are most certainly aware that DRM does not 'work'. We are under no illusions that it is tamperproof. However, we are also aware that DRM can make something 'hard enough' to copy that only really motivated people will bother-- the rest will just say, "heck, I'll just pay for this thing." Our financial people claim that they can show this is indeed the case. We are, of course, looking into alternatives, like the Books24x7-type solution which is DRM-free, but which is also a total PITA to copy.
I strongly advocate copyleft, so my role is occasionally difficult. But in the end, my company signs the paychecks, so my responsibility is to them. At the very least, it forces me to see the issue from both sides. A _lot_ of money goes into developing and printing books, so you really don't want to see that go down the drain.
Seconded. Almost done with my CS degree, despite taking two grad classes and having to travel for work. This semester was a bitch, but I learned a lot.
Unlike other support departments, however, IT, done correctly, is also a productivity multiplier, and that's because technology is a productivity multiplier. But keeping that technology running and training people to use it requires people who do nothing but specialize in IT. It's sad-- I do see IT people getting axed regularly, like they're just some kind of expense, but when management does this, they shoot themselves in the foot. Otherwise valuable employees spend their time, e.g., doing tedious calculations with spreadsheets when the IT department could have set them up with a simple database that would do most of this work for them.
Air traffic control systems should not be connected to the Internet. Period. Use of IPv4 as a messaging system in that case should be fine-- because all that address space will be private.
I love OpenBSD. We use it everywhere at work. But our computers do not control airplanes. A general-purpose OS is appropriate in the kind of environment where you have hard real-time limits and where bounds-checking errors have the potential to kill lots of people. This is a case where rolling-your-own is actually a good idea, and worth the money.
If you're trying to decide what kind of IDS to put on your air-traffic-control net, you need to back up and undo some of your decisions.
Yeah, but all of those fancy features found in Atom, like floating point, branch prediction, long pipelines, large caches, and so on... they aren't RISC. They are the antithesis of RISC. I think that's what's making low-power devices difficult for Intel and AMD to achieve.
"saving grace" is a little bit of a strange for an architecture that essentially dominates the entire embedded space, but I'll bite. The "saving grace" for ARM is that you can make them cheaply. I don't think anyone has ever looked at the Intel architecture and went "wow, that's beautiful". You think, "wow, I can't believe they crammed so much shit into that package!" Intel arch chips are orders of magnitude more expansive.
ARM is elegant, consistent, very programmer-friendly, and amazingly powerful. A lot of the things that should be handled correctly, like interrupts, are. There are plenty of registers to play with. I think we're only seeing the beginning of what ARM is capable of. Don't need an MMU? No problem. I mean, heck, if you want an ARM that has a Harvard arch for real-time use, you can get one, and you don't need to learn a new architecture.
Mod parent up. At my company, the telecommuters were the first to go. Now as to why, exactly, I'm not sure... It could be that they were "telecommuters" because they were a bunch of lazy good-for-nothings, who didn't actually do much "work from home". But I think the more likely answer is that their absence would be less noticed, and I think the management felt that this would be better for morale than laying off people who were more visible, if maybe, less productive.
The Metro sucks? Man, your standards are high! I frequently use the Metro as a shining example of how to do public transportation right. Sure, it closes at midnight. It does here in Boston, too. But compared to DC, Boston's public transportation is frequently broken-down, overcrowded, and extremely late. Homeless people pretty much live in the subway system. And DC's system is open all day. In Boston, I've had irritable passengers challenge me to fistfights because I was "too close" (this is despite the fact that they got onto a train that I was on first... if it's too crowded for you, why get on? And yes, they're usually drunk Red Sox fans... but I digress).
Every time I've been to DC, the trains have been clean, run on time, and actually made it to their destination. In Boston-- I started carrying a headlamp, because the trains frequently broke down in tunnels. Not fun.
NYC may have an expansive and convenient subway system, but in my opinion, the DC system is much more pleasant to ride. I don't mind walking a little further to get to the next station.
That said, now that I live in the city limits (Boston), I run or ride my bike everywhere. I am a much happier human. Still, having the public transportation option is nice, even if the Green Line and I are mortal enemies.
This is exactly true. People are looking at XenApp, which is mind-fuckingly-expensive, but, as it turns out, is much cheaper than paying several IT staffers full-time to put out the fires resulting from actually having end-users run old software natively.
Please correct me if I am wrong, but Exchange server is a database with a web interface. Don't we have all the components already? Compared to the Wine project goals, it would be almost trivial to throw some stuff together to make a feature-equivalent app.
As much as I would love to belittle Microsoft's work, replicating Exchange's functionality would be a monumental undertaking. God knows how much time I've spent battling lock-in to get decent interoperability with other systems. To give you some idea of this complexity, you can run Exchange on an X.25 network (and I think, in Exchange 5.5, the daemon spoke directly to the hardware). The overview of Microsoft's Exchange protocol suite runs to 81 pages!
Now, certainly, 95% of Microsoft's Exchange customers could get by without things like X.25 support. For lots of people email DB + IMAP + webmail is pretty good. But many Microsoft customers can't get by without a groupware platform, a highly-integrated distributed authentication database (with Kerberos support) and directory service (with an LDAP interface) with a customizable schema, and on, and on, and on... When you look at it that way, Exchange is a pretty good deal. It certainly functions reliably in our environment, and trust me, I would make a stink about it if it didn't.
The big tradeoff, of course, is that your data is locked up. But I think most IT managers say, hey, we're already running Windows, so what's the big deal? Anyway, if you could switch people off of Exchange without any trouble, people would do it. As it stands for most IT shops, that's like switching out an Apollo flight computer mid-mission. It ain't gonna happen.
There's a Windows-lover in my graduate OS class. He defends every architectural decision that Microsoft made, even when they are blatantly stupid. It's really sad, actually. We try not to be too hard on him, since his head's so mushy.
"Mammon slept. And the beast reborn spread over the earth and its numbers grew legion. And they proclaimed the times and sacrificed crops unto the
fire, with the cunning of foxes. And they built a new world in their own image as promised by the
sacred words, and spoke of the beast with their children. Mammon awoke, and lo! it was
naught but a follower." --from The Book of Mozilla, 11:9
(10th Edition)
As far as anyone can tell, the OpenDocument Foundation was basically a Microsoft shill. As other people have pointed out, they had no role in hashing out the OpenDocument formats. Their bait-and-switch tactic makes me highly suspicious that they ever had interoperability as a goal. More info here.
As for the formula specification: Microsoft could have easily downloaded one of a half-dozen format parsers with source code for ODF to test their own parser against. Just because the spec doesn't describe all of the features ad-nauseum is not a reason for not implementing it correctly.
I should point out that the convention with the RFC process is to have a working implementation first; that implementation is essentially the reference. I doubt Microsoft has ever had any difficulty implementing an RFC despite not having a formal standards document. Probably because, in that scenario, Microsoft is introducing a competing product as opposed to the current scenario of being asked to interoperate with a newcomer. They're clearly in a position of strength, and do not want to give that up. Providing an technically correct implementation that nonetheless does not work allows them to say to governments: hey, we complied like you asked, now please keep buying our stuff.
Having just finished a semester project writing a bootloader for an ARM processor, I can say without a doubt that there's no way you can get around BIOS. Linux most certainly needs BIOS. But not only does it need BIOS, it needs a bootloader. Linux is all kinds of cool things, but ain't magic, you know.
and that reason is that journalism is essential to the proper functioning of democracy. Without it, the populace will not be informed of the inner workings of the government. As history has shown-- and we only know about these things because of journalists, who have often risked their lives for the greater good-- the government needs to be constantly watched. Watching the government is a heck of a lot easier than refreshing the tree of liberty from time to time with the blood of patriots and tyrants (to paraphrase Jefferson). We wouldn't even know about things like Watergate, the Pentagon Papers, Abu Ghraib, the current torture discussion, without inquisitive journalists.
The 1st Amendment was first for a reason. Ever wonder why?
I recently picked up On the Edge: the Spectacular Rise and Fall of Commodore. This book nicely illustrates your point. Fascinating read-- the guy running the company was a complete bastard. He had developed a 'survival' ethos, from his experience as a child in German concentration camps, and he carried this into the way he did business in his adult life.
For example-- he would contract with small suppliers, but then stretch out repaying them, so that when they were on the verge of bankruptcy, he could buy their entire company cheaply. This allowed Commodore to have some impressive vertical integration, like the acquisition of MOS Technology, the maker of the 6502 processor. He offered employees bonus packages for achieving certain goals, and when they did, he reneged on his promises. In other cases, he would knowingly set unreasonable deadlines so that when systems were not delivered on time, he could penalize his engineers.
The worst part is that after his employees left for poor treatment, he sued them! He clearly did this for vengeful purposes, and to discourage other engineers from leaving, because when the C64 group left, to work on a completely different product, Commodore brought a lawsuit against them for intellectual property theft without even knowing what it was they were working on!
As far as I can tell, Commodore mostly operated within the law, but they had no qualms about operating in whatever legal grey areas there were at the time. If it was unethical, it did not matter at all. Commodore destroyed the lives of many people who gave large chunks of their lives to the company, because the company made many promises they did not keep (which they shrewdly did not write on paper).
I agree that this is to be expected. Business should be expected to push everything to the limit, including the law. But we must also expect, then, that we have to scrupulously enforce the law when they do break it. I personally think that the best use of the government would be to encourage an environment where the 'greedy solution' is the one that best aligns with our standards for good behavior.
Seriously, replacing cable is gigantic pain in the ass, when you could be doing better things with your time. Not to mention, it's expensive if you have a large enough installation-- this is why people are spending so much to keep Cat5e creaking along.
If it's working, and you're happy with it, keep it. If you need something faster, or it doesn't work anymore, or you need to meet new fire codes, well, that answers your question.
Remember, wires are solid state electronics. There's not much to go wrong there unless you're in extreme environments.
Actually, this is not true. We did this evaluation recently, and ended up going with Macs for our employees. It has had the added, unexpected, benefit that our employees who switched are stupidly happy now.
Anyway, in the past, we've gone with WinXP machines for the reasons you mention. They're dirt cheap, the hardware is pretty reliable (you can get great deals from HP when buying in bulk, and their machines are a pleasure to work with), and the software... well, it functions anyway. Macs always came out more expensive, but not significantly so.
The crucial thing that always tipped the scale in favor of MS was: legacy application support. We have a number of legacy apps-- some are more than 10 years old. XP mostly handled these apps OK. With Vista-- they simply do not work anymore. Unfortunately, they were written well before my time, so we do not have access to code, and the original developers have now moved on to other things. We're stuck with them until we replace them.
So we're now faced with having to run them inside a virtualization environment until we can replace them. Heck, if we're going to do that... why stick with Windows?
We looked at Linux, Vista, and the Mac. Linux seemed like a great option, and maybe in the future, it will be, but there were some dealbreakers, since it would require quite a bit more IT overhead to get going than, say, a Mac. Vista was disappointing, and frustrating to use, even for IT folk. Now, the Mac... it turned out to be quite easy to get going! We have it integrated into our AD. We've so far opted not to go with schema changes, but setting up Macs has been a breeze, and deploying them has been even easier than deploying Windows. No problems with SATA/IDE/driver problems-- the same disk image can be applied to ANY Intel Mac, and the image deployment tools come built-in! User templates can be set up just as easily as they can with Windows, and Macs can use our existing CIFS shares. SSO works!
When we compared the price per machine (including software) between Windows and the Mac, the Windows machines were marginally cheaper (like $25 per machine)-- UNTIL we mentioned this to our Apple rep. She dropped the price for us, and we ended up with a package that was cheaper than the Windows machines.
Add on the fact that administrating these machines is easy (no AV required!), we can do SSH and remote desktop out of the box, and for us, using Macs has been a clear winner.
We'd go with Macs again, and this is despite the fact that I have previous ranted here about how Apple's enterprise support sucks. Their AppleCare program for consumer-level stuff is actually pretty good.
For the record, all of my personal machines are Linux or OpenBSD. No Apple or Windows machines (not including my iPod).
Slashdot Mirror
Seriously, if they think this stuff is any good, they should send it to all us good-natured Slashdot people to try it out. Wimps.
get the Government out of it altogether and let private capital fund this research.
On the contrary, this is why it makes more sense to point out, like JFK did, that leaders must lead their people, rather than pander to them. Sometimes this means doing things that your constituents do not want, but nonetheless, desperately need.
I think it is high time for a leader who does what is needed and not what is wanted. Whether Obama is the person remains to be seen.
Nonsense. The tradeoff is small. Generally speaking, the politically-motivated decision makers are the appointees. They can set the direction of an organization, but they do not do the work. There are thousands of government scientists. They do good SCIENCE, which by it's very nature is truth-driven. Now whether you consider the pursuit of truth "politically motivated" or not is a matter of interpretation.
My brother works for the BFRL at NIST. Now, a lot of what they work on does not affect you. It's pure science. Fire in zero-G, for instance. This stuff would not be funded by commercial science, and much of it is too expensive for non-profit research institutions.
But this pure science-- it spins off in ways you couldn't imagine ahead of time. Being able to synchronize clocks around the world. Being able to buy something that weighs "1 kg" and knowing that, when you get it, it's the same "1 kg" that you meant.
The BFRL at NIST also looks at lots of practical things. Things like "How can we find people trapped in fires?" or "Can we develop a method for city planners to make smart staffing decisions for fire departments?" These practical things are often a direct consequence of pure science that was published many years before. And the scientists themselves, who work down the hall from each other, interact in many unexpected and positive ways. All of these things are of great value, but in many cases, they would not be done for lack of direct money-making potential. Government science keeps us safe, and it keeps our country competitive. It is absolutely essential.
In the case of the router vulnerability, this is something that you can control on the corporate side of things by simply not accepting packets down the VPN tunnel that don't come from the IP address that's the far endpoint of that tunnel. I'm not a VPN expert, but I would be surprised if this isn't how your VPN is configured by default.
You can also filter packets on the receiving end of the VPN. That's how I configured our firewall at work. The VPN tunnel simply looks like another network interface to our firewall, so I apply a slightly less restrictive set of rules to that connection than I do to the default external interface. Giving someone keys to your network just because they are an authenticated VPN user is not a very good idea.
My main complaint with DNS tampering is the outright DNS hijacking that Sprint does with their AirCard (EVDO) service. You can't even query a different DNS server-- your packets are intercepted and redirected to Sprint's own DNS. Unfortunately, their records are often out-of-date as it appears that they also manipulate TTLs to keep the churn down on their servers. It's a real problem when you're relying on something like an AirCard for doing things like network penetration testing.
It's not copyright-- you are granted a copyright automatically under US law. I believe you are thinking of trademarks, which have nothing to do with DRM.
As someone who is involved with having to decide whether DRM goes into our products or not (I work for a book publisher), I can tell you that we are most certainly aware that DRM does not 'work'. We are under no illusions that it is tamperproof. However, we are also aware that DRM can make something 'hard enough' to copy that only really motivated people will bother-- the rest will just say, "heck, I'll just pay for this thing." Our financial people claim that they can show this is indeed the case. We are, of course, looking into alternatives, like the Books24x7-type solution which is DRM-free, but which is also a total PITA to copy.
I strongly advocate copyleft, so my role is occasionally difficult. But in the end, my company signs the paychecks, so my responsibility is to them. At the very least, it forces me to see the issue from both sides. A _lot_ of money goes into developing and printing books, so you really don't want to see that go down the drain.
Seconded. Almost done with my CS degree, despite taking two grad classes and having to travel for work. This semester was a bitch, but I learned a lot.
Unlike other support departments, however, IT, done correctly, is also a productivity multiplier, and that's because technology is a productivity multiplier. But keeping that technology running and training people to use it requires people who do nothing but specialize in IT. It's sad-- I do see IT people getting axed regularly, like they're just some kind of expense, but when management does this, they shoot themselves in the foot. Otherwise valuable employees spend their time, e.g., doing tedious calculations with spreadsheets when the IT department could have set them up with a simple database that would do most of this work for them.
Air traffic control systems should not be connected to the Internet. Period. Use of IPv4 as a messaging system in that case should be fine-- because all that address space will be private.
I love OpenBSD. We use it everywhere at work. But our computers do not control airplanes. A general-purpose OS is appropriate in the kind of environment where you have hard real-time limits and where bounds-checking errors have the potential to kill lots of people. This is a case where rolling-your-own is actually a good idea, and worth the money.
If you're trying to decide what kind of IDS to put on your air-traffic-control net, you need to back up and undo some of your decisions.
Yeah, but all of those fancy features found in Atom, like floating point, branch prediction, long pipelines, large caches, and so on... they aren't RISC. They are the antithesis of RISC. I think that's what's making low-power devices difficult for Intel and AMD to achieve.
"saving grace" is a little bit of a strange for an architecture that essentially dominates the entire embedded space, but I'll bite. The "saving grace" for ARM is that you can make them cheaply. I don't think anyone has ever looked at the Intel architecture and went "wow, that's beautiful". You think, "wow, I can't believe they crammed so much shit into that package!" Intel arch chips are orders of magnitude more expansive.
ARM is elegant, consistent, very programmer-friendly, and amazingly powerful. A lot of the things that should be handled correctly, like interrupts, are. There are plenty of registers to play with. I think we're only seeing the beginning of what ARM is capable of. Don't need an MMU? No problem. I mean, heck, if you want an ARM that has a Harvard arch for real-time use, you can get one, and you don't need to learn a new architecture.
Mod parent up. At my company, the telecommuters were the first to go. Now as to why, exactly, I'm not sure... It could be that they were "telecommuters" because they were a bunch of lazy good-for-nothings, who didn't actually do much "work from home". But I think the more likely answer is that their absence would be less noticed, and I think the management felt that this would be better for morale than laying off people who were more visible, if maybe, less productive.
But we can't let that stop us from blaming our lack of personal responsibility on the subway system, now, can we?
The Metro sucks? Man, your standards are high! I frequently use the Metro as a shining example of how to do public transportation right. Sure, it closes at midnight. It does here in Boston, too. But compared to DC, Boston's public transportation is frequently broken-down, overcrowded, and extremely late. Homeless people pretty much live in the subway system. And DC's system is open all day. In Boston, I've had irritable passengers challenge me to fistfights because I was "too close" (this is despite the fact that they got onto a train that I was on first... if it's too crowded for you, why get on? And yes, they're usually drunk Red Sox fans... but I digress).
Every time I've been to DC, the trains have been clean, run on time, and actually made it to their destination. In Boston-- I started carrying a headlamp, because the trains frequently broke down in tunnels. Not fun.
NYC may have an expansive and convenient subway system, but in my opinion, the DC system is much more pleasant to ride. I don't mind walking a little further to get to the next station.
That said, now that I live in the city limits (Boston), I run or ride my bike everywhere. I am a much happier human. Still, having the public transportation option is nice, even if the Green Line and I are mortal enemies.
This is exactly true. People are looking at XenApp, which is mind-fuckingly-expensive, but, as it turns out, is much cheaper than paying several IT staffers full-time to put out the fires resulting from actually having end-users run old software natively.
Please correct me if I am wrong, but Exchange server is a database with a web interface. Don't we have all the components already? Compared to the Wine project goals, it would be almost trivial to throw some stuff together to make a feature-equivalent app.
As much as I would love to belittle Microsoft's work, replicating Exchange's functionality would be a monumental undertaking. God knows how much time I've spent battling lock-in to get decent interoperability with other systems. To give you some idea of this complexity, you can run Exchange on an X.25 network (and I think, in Exchange 5.5, the daemon spoke directly to the hardware). The overview of Microsoft's Exchange protocol suite runs to 81 pages!
Now, certainly, 95% of Microsoft's Exchange customers could get by without things like X.25 support. For lots of people email DB + IMAP + webmail is pretty good. But many Microsoft customers can't get by without a groupware platform, a highly-integrated distributed authentication database (with Kerberos support) and directory service (with an LDAP interface) with a customizable schema, and on, and on, and on... When you look at it that way, Exchange is a pretty good deal. It certainly functions reliably in our environment, and trust me, I would make a stink about it if it didn't.
The big tradeoff, of course, is that your data is locked up. But I think most IT managers say, hey, we're already running Windows, so what's the big deal? Anyway, if you could switch people off of Exchange without any trouble, people would do it. As it stands for most IT shops, that's like switching out an Apollo flight computer mid-mission. It ain't gonna happen.
The worst part is that somehow, in Perl, even your own comments don't make sense later on.
There's a Windows-lover in my graduate OS class. He defends every architectural decision that Microsoft made, even when they are blatantly stupid. It's really sad, actually. We try not to be too hard on him, since his head's so mushy.
Which reminds me...
"Mammon slept. And the beast reborn spread over the earth and its numbers grew legion. And they proclaimed the times and sacrificed crops unto the fire, with the cunning of foxes. And they built a new world in their own image as promised by the sacred words, and spoke of the beast with their children. Mammon awoke, and lo! it was naught but a follower." --from The Book of Mozilla, 11:9 (10th Edition)
As far as anyone can tell, the OpenDocument Foundation was basically a Microsoft shill. As other people have pointed out, they had no role in hashing out the OpenDocument formats. Their bait-and-switch tactic makes me highly suspicious that they ever had interoperability as a goal. More info here.
As for the formula specification: Microsoft could have easily downloaded one of a half-dozen format parsers with source code for ODF to test their own parser against. Just because the spec doesn't describe all of the features ad-nauseum is not a reason for not implementing it correctly.
I should point out that the convention with the RFC process is to have a working implementation first; that implementation is essentially the reference. I doubt Microsoft has ever had any difficulty implementing an RFC despite not having a formal standards document. Probably because, in that scenario, Microsoft is introducing a competing product as opposed to the current scenario of being asked to interoperate with a newcomer. They're clearly in a position of strength, and do not want to give that up. Providing an technically correct implementation that nonetheless does not work allows them to say to governments: hey, we complied like you asked, now please keep buying our stuff.
Having just finished a semester project writing a bootloader for an ARM processor, I can say without a doubt that there's no way you can get around BIOS. Linux most certainly needs BIOS. But not only does it need BIOS, it needs a bootloader. Linux is all kinds of cool things, but ain't magic, you know.
and that reason is that journalism is essential to the proper functioning of democracy. Without it, the populace will not be informed of the inner workings of the government. As history has shown-- and we only know about these things because of journalists, who have often risked their lives for the greater good-- the government needs to be constantly watched. Watching the government is a heck of a lot easier than refreshing the tree of liberty from time to time with the blood of patriots and tyrants (to paraphrase Jefferson). We wouldn't even know about things like Watergate, the Pentagon Papers, Abu Ghraib, the current torture discussion, without inquisitive journalists.
The 1st Amendment was first for a reason. Ever wonder why?
How do you have sex with the computer off? Wait... I think I need to go back to that Wikipedia article.
Best post ever.
I recently picked up On the Edge: the Spectacular Rise and Fall of Commodore. This book nicely illustrates your point. Fascinating read-- the guy running the company was a complete bastard. He had developed a 'survival' ethos, from his experience as a child in German concentration camps, and he carried this into the way he did business in his adult life.
For example-- he would contract with small suppliers, but then stretch out repaying them, so that when they were on the verge of bankruptcy, he could buy their entire company cheaply. This allowed Commodore to have some impressive vertical integration, like the acquisition of MOS Technology, the maker of the 6502 processor. He offered employees bonus packages for achieving certain goals, and when they did, he reneged on his promises. In other cases, he would knowingly set unreasonable deadlines so that when systems were not delivered on time, he could penalize his engineers.
The worst part is that after his employees left for poor treatment, he sued them! He clearly did this for vengeful purposes, and to discourage other engineers from leaving, because when the C64 group left, to work on a completely different product, Commodore brought a lawsuit against them for intellectual property theft without even knowing what it was they were working on!
As far as I can tell, Commodore mostly operated within the law, but they had no qualms about operating in whatever legal grey areas there were at the time. If it was unethical, it did not matter at all. Commodore destroyed the lives of many people who gave large chunks of their lives to the company, because the company made many promises they did not keep (which they shrewdly did not write on paper).
I agree that this is to be expected. Business should be expected to push everything to the limit, including the law. But we must also expect, then, that we have to scrupulously enforce the law when they do break it. I personally think that the best use of the government would be to encourage an environment where the 'greedy solution' is the one that best aligns with our standards for good behavior.
"If it ain't broke, don't replace it with Cat6."
Seriously, replacing cable is gigantic pain in the ass, when you could be doing better things with your time. Not to mention, it's expensive if you have a large enough installation-- this is why people are spending so much to keep Cat5e creaking along.
If it's working, and you're happy with it, keep it. If you need something faster, or it doesn't work anymore, or you need to meet new fire codes, well, that answers your question.
Remember, wires are solid state electronics. There's not much to go wrong there unless you're in extreme environments.
Actually, this is not true. We did this evaluation recently, and ended up going with Macs for our employees. It has had the added, unexpected, benefit that our employees who switched are stupidly happy now.
Anyway, in the past, we've gone with WinXP machines for the reasons you mention. They're dirt cheap, the hardware is pretty reliable (you can get great deals from HP when buying in bulk, and their machines are a pleasure to work with), and the software... well, it functions anyway. Macs always came out more expensive, but not significantly so.
The crucial thing that always tipped the scale in favor of MS was: legacy application support. We have a number of legacy apps-- some are more than 10 years old. XP mostly handled these apps OK. With Vista-- they simply do not work anymore. Unfortunately, they were written well before my time, so we do not have access to code, and the original developers have now moved on to other things. We're stuck with them until we replace them.
So we're now faced with having to run them inside a virtualization environment until we can replace them. Heck, if we're going to do that... why stick with Windows?
We looked at Linux, Vista, and the Mac. Linux seemed like a great option, and maybe in the future, it will be, but there were some dealbreakers, since it would require quite a bit more IT overhead to get going than, say, a Mac. Vista was disappointing, and frustrating to use, even for IT folk. Now, the Mac... it turned out to be quite easy to get going! We have it integrated into our AD. We've so far opted not to go with schema changes, but setting up Macs has been a breeze, and deploying them has been even easier than deploying Windows. No problems with SATA/IDE/driver problems-- the same disk image can be applied to ANY Intel Mac, and the image deployment tools come built-in! User templates can be set up just as easily as they can with Windows, and Macs can use our existing CIFS shares. SSO works!
When we compared the price per machine (including software) between Windows and the Mac, the Windows machines were marginally cheaper (like $25 per machine)-- UNTIL we mentioned this to our Apple rep. She dropped the price for us, and we ended up with a package that was cheaper than the Windows machines.
Add on the fact that administrating these machines is easy (no AV required!), we can do SSH and remote desktop out of the box, and for us, using Macs has been a clear winner.
We'd go with Macs again, and this is despite the fact that I have previous ranted here about how Apple's enterprise support sucks. Their AppleCare program for consumer-level stuff is actually pretty good.
For the record, all of my personal machines are Linux or OpenBSD. No Apple or Windows machines (not including my iPod).