The goal of this system was always to generate lots of legal fees by having the total class awarded enough money that the lawyers' percentage of the settlement would be large, and secondarily to punish the company for making a game that offended some people. It was Grand Theft Lawsuit.
Nobody was ever really concerned about reimbursing customers who bought a game involving the criminal protagonist killing prostitutes, starting ethnic riots, and shooting cops for their shock that it might also let you change the software to find hidden pr0n. And if adults who bought it for their kids were shocked, well, if little Johnny can download the software patch that lets you decrypt the hidden pr0n, he can also download real pr0n from the net, and if that bothers them they shouldn't have bought a game called Grand Theft Auto. But awarding them a nominal $5 was enough that the total award was large, and AFAICT the lawyers get a percentage of the total award, not a percentage of the amount actually collected to the winning class.
For the last couple of years, it's been illegal to use a computer or video system in the front seat of your car except for navigation. So you can have a GPS display or a camera showing the curb as you're backing up, but DVD players are illegal.
I think the rules are draconian enough that even your front-seat passenger can't be using a laptop, though there are loopholes for devices physically mounted to the car (e.g. police-car laptop holders.)
Having them in the back seat for your kids to watch is just fine (probably aids safety, because you've heard the words to that movie they keep playing over and over enough times that you either tune them out or can say them out loud to your kids without actually needing to engage any brain cells.)
Public transportation? The 405's in LA, and isn't in the direction that most of the public transportation goes:-)
I worked on a gig down there back in the late 80s. The distance from the 101 / 405 intersection to LAX is 18 miles, which is six times the distance across Manhattan. I'd rather drive six times across Manhattan at just about any time of day, because it's faster... Maybe things have improved since then, but I doubt it. You're going to be bumper-to-bumper at a long slow crawl, might as well do something with your time.
Bah - a shaving brush and mug with the shaving soap that you add hot water to and lather up is far nicer than shaving cream. You can get one of those cigarette-lighter-powered coffee-pot heaters to heat the water for your shaving mug.
And while I might be approaching old-geezer-ness, it *was* a retro way to shave back when I started using it, and I never went as hard-core as using a straight razor, which would be a *really* bad thing to do in a car:-) I do actually use a razor occasionally to trim my beard or mustache, and every five or ten years I need to buy a new one because they no longer make refills for the kind of razor I'd bought the last time.
No, it just means that when we invent Robot Overlords, everybody will say "No, that's not Strong AI, any more than pattern recognition is - it's just Robot Overlording".
If you've got a long enough cable to reach from the computer to the TV, can you run another cable next to it for your keyboard? If that doesn't reach all the way to your couch, either do something wireless, or run a USB cable and use an infrared USB frob for the keyboard/mouse or something if you don't trust ethernet or bluetooth latency.
Or take that P200 laptop with the cracked screen that's been lying around and use it as a X server for the keyboard and mouse.
That's not actually the problem here - as you say, the encryption itself doesn't cause a size increase except for an initial key exchange. The problem is that you're taking a raw data packet of two or three 10-byte compressed-voice samples (each 10ms at 8kbps), wrapping them in RTP/UDP headers (20 bytes) and IP headers (another 20 bytes), and then if you're doing a typical VPN with tunnel-mode IPSEC, you're adding another layer of IP headers (which are slightly larger because they've got IPSEC options added), and it's not uncommon to need another UDP header somewhere for NAT evasion, which may also have its own IP header layer. On an Ethernet you don't care, but on a narrow radio channel of some sort it really matters, and in general in wide-area networks you care a bit, especially if you're trying to trunk a bunch of calls together.
If all of your equipment supports it, there are transport-layer encryption standards like SRTP which avoids the IPSEC overhead, but it does burn some bandwidth of its own on headers, checksums, etc. so it's not free either.
Asterisk avoids some of those problems for trunked connections, because it can combine the voice samples for a bunch of different calls into one packet, so the overhead gets amortized across all your calls. For a single person-to-person call it doesn't matter, but for a trunk between two business offices or similar application it can make a large difference.
2.0 was a real memory pig, and my 512MB system was paging all the time. 3.0beta5 seemed to be much tighter, and my system behaved a lot better. Then I did two things - updated to 3.0rc1, and added gig of memory. FF is now using a lot more memory than it did under beta5. Not sure if it's a change in usage between the two versions, or if it's simply using more memory because more is available.
Voice codecs are lossy, so they'll happily compress your encryption data to something smaller, treating it as if it were audio samples from a human vocal tract. Unfortunately, you won't get all the bits back when you uncompress it, so decrypting the data isn't going to reconstruct anything resembling the original voice stream:-)
1) You're seeing lots about bugging and wiretapping VOIP because VOIP use is increasing, and because the buggers in government are getting really aggressive about wanting to wiretap people. VOIP is potentially less secure than POTS, because there are more ways to tap the Internet than traditional phones (where you either use alligator clips on the wire or go to the phone company office), and it's also potentially much more secure than POTS, because the end users can do their own encryption without needing the network in between to be secure.
2)It's not that compressed VOIP would be inherently more or less secure than uncompressed - if you want it secure, you encrypt it. The problem is that if you use a crypto system that works just fine with fixed-rate voice (either uncompressed or with a fixed-rate codec, which most codecs are) and use a variable-bit-rate codec instead, suddenly lots of information leaks out through the timing, because the crypto system wasn't hiding the size or timing of the voice packets. So no, your decent VPN isn't taking care of it, because it wasn't designed to, and using a VPN instead of VOIP-specific encryption makes it easier for you to use whatever codec you like. Also, IPSEC is really inefficient for VOIP, and SSL or SSH are worse, because VOIP gives you a stream of lots of very small packets, and each layer of protocol (RTP, UDP, IP, IPSEC, etc.) adds more overhead - an 8kbps voice codec typically takes 24-28kbps of IP if you don't encrypt it, and maybe double if you do.
This isn't a simple case of a broken protocol - it's an effect of mixing different protocols in ways that don't work together.
Voice codecs are designed to support a given level of audio quality subject to bit rate and computational complexity limitations. Most codecs are fixed-rate, or fixed-rate with silence suppression. Encryption isn't part of their design; it's somebody else's problem, and many VOIP systems aren't encrypted anyway (for instance, connections between an office phone and a PBX usually aren't.) Variable bit rate codecs are sometimes a good choice, depending on the kind of sounds you're trying to compress and the networks you're transmitting them on, and they're at least an alternative to the usual fixed-rate codecs.
Encryption systems usually aren't designed to deal with real-time message streams or timing attacks. Typically VOIP encryption protocols are designed for constant bit rate codec output, which is what most codecs provide, and the codecs usually package up 10, 20, or 30ms audio samples into a data packet for transmission over IP.
The problem occurs when you're choosing your codec and encryption separately, and you take a crypto system designed for fixed-rate codecs and use a variable-bit-rate codec instead. It's difficult to keep people from doing that sort of thing, especially if they're using huge-overhead approaches like VOIP inside IPSEC as opposed to VOIP systems with the crypto built in. It's also difficult to prevent people from making bad choices like that when they're using open-source software applications, as opposed to proprietary phones that only have the small set of codecs the manufacturer built in (typically uncompressed G.711, or G.729 or a GSM codec, all of which are fixed-rate except for silence suppression.)
All of the major carriers have been upgrading their networks, improving coverage, installing higher-speed technologies as they come out, finding new ways to alienate customers with their billing practices, offering shinier phones,...
Here in Silicon Valley, there used to be areas where the higher-priced homeowners didn't want ugly cell towers so coverage was bad; AFAICT, that's mostly no longer a problem with the major carriers, though a few of the hilly areas have spotty coverage, and nobody seems to be charging for roaming any more, so any gaps are pretty transparently covered. It's a big change from five years ago, and especially from 10 years ago. And text messages between people who use different carriers seem to work fairly consistently; it used to be that they might take a day to get delivered if you were unlucky.
WiMAX can go a long distance, and it can get high bandwidths, but you don't really get both at once, and it's going to be very dependent on the RF conditions in whatever frequency band you're using with whatever collection of buildings are in the way between you and the carrier's antenna, and on how many WiMAX users are sharing the chunk of spectrum you're in as well as competing technologies. So it can be anything from excellent to terrible, or fast to slow.
The carrier you're dealing with should be able to give you some estimate of what performance they'd expect given your location, and if that sounds good enough then try it out, unless you've got serious cost/hassle issues with antenna placement (not uncommon in big cities.) On the other hand, the buildings that are big enough that getting roof access for antennas is a problem are often big enough to have fiber in the basement that somebody can use to give you fast cheap service (also not uncommon in big cities.)
One thing I really like about wireless technologies (whether it's WiMAX or cellular or other) is that while they're not as reliable as wired service, they're usually not shut down by the same things. So that backhoe driver out on the street who's trying to find the water main underneath your fiber access isn't going to trash you wireless, and while there's another backhoe driver thinking about tearing up the street in front of your wireless carrier's antenna, chances are very low that they'll both happen on the same day.
Some carriers are using licensed spectrum, others are using unlicensed. There's no such thing as "semi-licensed". Licensed spectrum is less likely to have interference, but it costs the carriers money and limits where they can use it, so it's a tradeoff. From a carrier perspective, one of the things that that affects is what you can do for Service Level Agreements - the less control you've got, the less assurance you can provide, and the more you've got to worry about the service degrading.
Back when I was dealing with 38GHz wireless (point-to-point line-of-sight service), what we found was that rain fade was a big problem, so we'd offer service only up to distances that would let us maintain the SLAs given the probable rain densities - so we could get something like 10 miles in Phoenix and 1-2 miles in Seattle.
Remember, you don't have to sign every DNS record every time anybody requests it from you - you just have to sign it once when you put it into your database, plus (depending on whether the version of DNSSEC you're using indicates negative responses) update a couple of signatures indicating absence of other names. Any time somebody does a query for a given name, you hand them the records they've asked for and the signature records. If they want to verify the signatures, that's their computational load, not yours; your real load increase is just the added data in your response. (That'd be shorter if they're using elliptical curve crypto these days; I haven't kept track.)
So if you own.com, and somebody registers the name example1.com, you sign a record indicating that example1.com's public key is [foo] and nameservers are 0.1.2.3 and 0.4.5.6 etc., delete the record that says "there aren't any names between "example0.com and example5.com" replacing it with records saying "there aren't any names between example0.com and example1.com" and "there aren't any names between example1.com and example5.com". (There reason for the negative records was so that you didn't have to go signing every response for "No such domain: Example12345.com" "No such domain: Example12346.com" etc.)
If you look at most of the Top500 supercomputers these days, they're not Fluorinert-cooled Cray2s any more - they're almost all lots of processors with some kinds of interconnection network to get data between processors, and they're running lots of SIMD to make LINPAK go fast. This machine is using the CPU interconnects because they benchmarked it and found they didn't need to mess with SLI, and it may not have quite the I/O scalability that the Earth Simulator or its faster competitors have, but it's in the same kind of space. It's not near the top, but it's certainly respectable.
Emacs used to be really big. Now it's pretty small, even with the graphics interfaces and kitchen sink written in ELisp. My browser's currently burning 300MB (the 3 Beta 5 version used much less RAM than 2.x, and I bought more RAM about the same time the RC version came out, so I don't know how much of the change is which:-) Of course, any time you take a 5-year-old application and run it on a current computer, it turns out to be small and blazingly fast, unless it has to play games with hardware emulation that can make it as slow as the original.
There's a certain extent to which students need to learn basic tools - I'm surprised to hear an assertion that they're already familiar with Excel but they should learn to use spreadsheets, because they're really convenient for many kinds of problems, just as (ahem) slide rules were when I was in college (and calculators were beginning to be, and PDP-11s were.)
But scientists are going to need to do increasing amounts of computer use as computers pervade and inform the sciences, and that means doing their own programming, including writing real programs and writing scripts to bash input or output data for other programs. So they not only need to learn some syntax, and some scripting languages, they need to learn basic data structures, efficiency issues, debugging, and one of the most important lessons from my CS100 days - "Never trust input" "Ever" . That means they need at least two semesters of programming.
As scientists, even if they don't ever end up doing much more programming than feeding input to other packages and interpreting the output, they need to be able to do it in ways that will run in finite amounts of time and produce correct output - and learning not to trust input is as basic as learning not to connect the 110volt power to a 5 volt device or use fire near flammable liquids.
Some of the people in the current Iraqi Civil War are insurgents opposing the legitimate government of Iraq that was established some years after the US invaders set it up, some of them are Resistance fighters who were opposing the US invaders before they set up their puppet government, some of them are warlords fighting each other, some are street gangs looting, some are just pissed-off individuals, some of them are tribal groups fighting their traditional enemies, some of them are armies of the US invaders and the Coalition of the Willing, some of them are foreigners who came to fight a jihad against the Great Satan, and some of them are carpetbaggers like Halliburton.
Separately, some of the fighters on multiple sides have used terrorist tactics against the civilian population, so they're terrorists. Some of those terrorists work for governments, and some are carpetbaggers who think they're part of a jihad.
And some of those fighters, terrorist or otherwise, not only don't like the US, but are getting good training and a great recruiting tool to get people to join them.
There are really two separate issues for usability - does the machine and OS support the hardware you need, and does it support the software applications you need or want with acceptable performance?
For hardware, if the machine's got an Ethernet card and you're satisfied with the graphics resolution, and have enough disk space, you're fine. You won't be adding wireless cards that didn't have drivers back in the day, and lack of USB can be annoying (and my old P133 laptop has pre-Cardbus PCMCIA slots, so those are pretty much ruled out as well), and if you don't have enough RAM it's probably cheaper to buy a new motherboard than a lot of older-format RAM. But the machine was blazingly fast back when you bought it... even if it can't play MPEGs today.
Bloated software's a somewhat different issue - I won't say that Netscape 2.0 was a great system, but it could do basic web browsing back then and still can. You'll have trouble with Flash-heavy web pages, and maybe some Javascript, and you won't be able to open 50 tabs in the background of your browser unless you find an older version of Opera which will have no trouble (remember when Opera fit on half a floppy disk?) And CSS probably won't work, so web sites won't come out with the exact same font size that the web designer wanted, but they were never supposed to.
Does all of this mean that when my PII-233 had a big purple flash from the motherboard a few years ago and let the blue smoke escape, I went looking for another PII to replace it? No:-) - I bought a Celeron-2400 or something about like that, which was below average for new hardware at the time but has done just fine, with occasional upgrades to RAM and disk.
The parent article is really good - I'm not modding it +1 Informative/Insightful/etc because I've got my own me-too story to add, but I'd appreciate if someone else does:-)
And of course there's always Xanadu....
Back in the late 1980s, when I was at Bell Labs (not Research), I was on a standards committee for Computer-Aided Logistics Support, trying to standardize computerized documentation formats. The primary directions the committee was working on were SGML for text and some vector graphics standard that I've forgotten for pictures. SGML was a predecessor to XML, and was an abstract language describing document types that were typically like HTML with whatever markings and objects you needed to define, so we were essentially trying to define a DTD for our documentation.
There were people on the committee who got the "mark up the information content, let the reader's client format it" concept, where objects are things like "a 2nd-level paragraph", and people who didn't get it, and wanted to objects to be things like "a paragraph in 14-point bold-face" or "a page break" because they wanted to electronically represent the typical paper manuals and version control where you needed to replace pages to update the document, even though the manual might be an airplane-engine repair doc that some mechanic is trying to read on a wrist-mounted 24x80 screen while poking around in the engine. You may find this familiar, given the number of people over the past decade who've been trying to make web pages look exactly the way they want even when the user's browser or screen size may not be identical to theirs.
At one point my boss (who was a PhD type, not a Dilbert boss) asked if we needed to be concerned that our presence on the committee might tell competitors the kinds of things we were working on. My reply was that "Well SGML is an obvious thing to write Hypertext in, so this is the kind of Research they'd expect us to be doing." Sigh - my mental model of hypertext was pretty much Hypercard and similar document packages, and I didn't get the linking-together-multiple-authors bit either:-)
Slashdot Mirror
The goal of this system was always to generate lots of legal fees by having the total class awarded enough money that the lawyers' percentage of the settlement would be large, and secondarily to punish the company for making a game that offended some people. It was Grand Theft Lawsuit.
Nobody was ever really concerned about reimbursing customers who bought a game involving the criminal protagonist killing prostitutes, starting ethnic riots, and shooting cops for their shock that it might also let you change the software to find hidden pr0n. And if adults who bought it for their kids were shocked, well, if little Johnny can download the software patch that lets you decrypt the hidden pr0n, he can also download real pr0n from the net, and if that bothers them they shouldn't have bought a game called Grand Theft Auto. But awarding them a nominal $5 was enough that the total award was large, and AFAICT the lawyers get a percentage of the total award, not a percentage of the amount actually collected to the winning class.
For the last couple of years, it's been illegal to use a computer or video system in the front seat of your car except for navigation. So you can have a GPS display or a camera showing the curb as you're backing up, but DVD players are illegal.
I think the rules are draconian enough that even your front-seat passenger can't be using a laptop, though there are loopholes for devices physically mounted to the car (e.g. police-car laptop holders.)
Having them in the back seat for your kids to watch is just fine (probably aids safety, because you've heard the words to that movie they keep playing over and over enough times that you either tune them out or can say them out loud to your kids without actually needing to engage any brain cells.)
Public transportation? The 405's in LA, and isn't in the direction that most of the public transportation goes :-)
I worked on a gig down there back in the late 80s. The distance from the 101 / 405 intersection to LAX is 18 miles, which is six times the distance across Manhattan. I'd rather drive six times across Manhattan at just about any time of day, because it's faster... Maybe things have improved since then, but I doubt it. You're going to be bumper-to-bumper at a long slow crawl, might as well do something with your time.
Bah - a shaving brush and mug with the shaving soap that you add hot water to and lather up is far nicer than shaving cream. You can get one of those cigarette-lighter-powered coffee-pot heaters to heat the water for your shaving mug.
And while I might be approaching old-geezer-ness, it *was* a retro way to shave back when I started using it, and I never went as hard-core as using a straight razor, which would be a *really* bad thing to do in a car :-) I do actually use a razor occasionally to trim my beard or mustache, and every five or ten years I need to buy a new one because they no longer make refills for the kind of razor I'd bought the last time.
There's an obvious application to run on a Windows cluster.
No, it just means that when we invent Robot Overlords, everybody will say "No, that's not Strong AI, any more than pattern recognition is - it's just Robot Overlording".
or "Now sells Genepax", if you pronouce Genepax as three syllables.
Or take that P200 laptop with the cracked screen that's been lying around and use it as a X server for the keyboard and mouse.
If all of your equipment supports it, there are transport-layer encryption standards like SRTP which avoids the IPSEC overhead, but it does burn some bandwidth of its own on headers, checksums, etc. so it's not free either.
Asterisk avoids some of those problems for trunked connections, because it can combine the voice samples for a bunch of different calls into one packet, so the overhead gets amortized across all your calls. For a single person-to-person call it doesn't matter, but for a trunk between two business offices or similar application it can make a large difference.
2.0 was a real memory pig, and my 512MB system was paging all the time. 3.0beta5 seemed to be much tighter, and my system behaved a lot better. Then I did two things - updated to 3.0rc1, and added gig of memory. FF is now using a lot more memory than it did under beta5. Not sure if it's a change in usage between the two versions, or if it's simply using more memory because more is available.
Voice codecs are lossy, so they'll happily compress your encryption data to something smaller, treating it as if it were audio samples from a human vocal tract. Unfortunately, you won't get all the bits back when you uncompress it, so decrypting the data isn't going to reconstruct anything resembling the original voice stream :-)
2)It's not that compressed VOIP would be inherently more or less secure than uncompressed - if you want it secure, you encrypt it. The problem is that if you use a crypto system that works just fine with fixed-rate voice (either uncompressed or with a fixed-rate codec, which most codecs are) and use a variable-bit-rate codec instead, suddenly lots of information leaks out through the timing, because the crypto system wasn't hiding the size or timing of the voice packets. So no, your decent VPN isn't taking care of it, because it wasn't designed to, and using a VPN instead of VOIP-specific encryption makes it easier for you to use whatever codec you like. Also, IPSEC is really inefficient for VOIP, and SSL or SSH are worse, because VOIP gives you a stream of lots of very small packets, and each layer of protocol (RTP, UDP, IP, IPSEC, etc.) adds more overhead - an 8kbps voice codec typically takes 24-28kbps of IP if you don't encrypt it, and maybe double if you do.
Voice codecs are designed to support a given level of audio quality subject to bit rate and computational complexity limitations. Most codecs are fixed-rate, or fixed-rate with silence suppression. Encryption isn't part of their design; it's somebody else's problem, and many VOIP systems aren't encrypted anyway (for instance, connections between an office phone and a PBX usually aren't.) Variable bit rate codecs are sometimes a good choice, depending on the kind of sounds you're trying to compress and the networks you're transmitting them on, and they're at least an alternative to the usual fixed-rate codecs.
Encryption systems usually aren't designed to deal with real-time message streams or timing attacks. Typically VOIP encryption protocols are designed for constant bit rate codec output, which is what most codecs provide, and the codecs usually package up 10, 20, or 30ms audio samples into a data packet for transmission over IP.
The problem occurs when you're choosing your codec and encryption separately, and you take a crypto system designed for fixed-rate codecs and use a variable-bit-rate codec instead. It's difficult to keep people from doing that sort of thing, especially if they're using huge-overhead approaches like VOIP inside IPSEC as opposed to VOIP systems with the crypto built in. It's also difficult to prevent people from making bad choices like that when they're using open-source software applications, as opposed to proprietary phones that only have the small set of codecs the manufacturer built in (typically uncompressed G.711, or G.729 or a GSM codec, all of which are fixed-rate except for silence suppression.)
Yes, Chuck Norris can kick trolls out of /., but only one or two at a time.
Here in Silicon Valley, there used to be areas where the higher-priced homeowners didn't want ugly cell towers so coverage was bad; AFAICT, that's mostly no longer a problem with the major carriers, though a few of the hilly areas have spotty coverage, and nobody seems to be charging for roaming any more, so any gaps are pretty transparently covered. It's a big change from five years ago, and especially from 10 years ago. And text messages between people who use different carriers seem to work fairly consistently; it used to be that they might take a day to get delivered if you were unlucky.
The carrier you're dealing with should be able to give you some estimate of what performance they'd expect given your location, and if that sounds good enough then try it out, unless you've got serious cost/hassle issues with antenna placement (not uncommon in big cities.) On the other hand, the buildings that are big enough that getting roof access for antennas is a problem are often big enough to have fiber in the basement that somebody can use to give you fast cheap service (also not uncommon in big cities.)
One thing I really like about wireless technologies (whether it's WiMAX or cellular or other) is that while they're not as reliable as wired service, they're usually not shut down by the same things. So that backhoe driver out on the street who's trying to find the water main underneath your fiber access isn't going to trash you wireless, and while there's another backhoe driver thinking about tearing up the street in front of your wireless carrier's antenna, chances are very low that they'll both happen on the same day.
Back when I was dealing with 38GHz wireless (point-to-point line-of-sight service), what we found was that rain fade was a big problem, so we'd offer service only up to distances that would let us maintain the SLAs given the probable rain densities - so we could get something like 10 miles in Phoenix and 1-2 miles in Seattle.
So if you own
If you look at most of the Top500 supercomputers these days, they're not Fluorinert-cooled Cray2s any more - they're almost all lots of processors with some kinds of interconnection network to get data between processors, and they're running lots of SIMD to make LINPAK go fast. This machine is using the CPU interconnects because they benchmarked it and found they didn't need to mess with SLI, and it may not have quite the I/O scalability that the Earth Simulator or its faster competitors have, but it's in the same kind of space. It's not near the top, but it's certainly respectable.
Emacs used to be really big. Now it's pretty small, even with the graphics interfaces and kitchen sink written in ELisp. My browser's currently burning 300MB (the 3 Beta 5 version used much less RAM than 2.x, and I bought more RAM about the same time the RC version came out, so I don't know how much of the change is which :-) Of course, any time you take a 5-year-old application and run it on a current computer, it turns out to be small and blazingly fast, unless it has to play games with hardware emulation that can make it as slow as the original.
But scientists are going to need to do increasing amounts of computer use as computers pervade and inform the sciences, and that means doing their own programming, including writing real programs and writing scripts to bash input or output data for other programs. So they not only need to learn some syntax, and some scripting languages, they need to learn basic data structures, efficiency issues, debugging, and one of the most important lessons from my CS100 days - "Never trust input" "Ever" . That means they need at least two semesters of programming.
As scientists, even if they don't ever end up doing much more programming than feeding input to other packages and interpreting the output, they need to be able to do it in ways that will run in finite amounts of time and produce correct output - and learning not to trust input is as basic as learning not to connect the 110volt power to a 5 volt device or use fire near flammable liquids.
Separately, some of the fighters on multiple sides have used terrorist tactics against the civilian population, so they're terrorists. Some of those terrorists work for governments, and some are carpetbaggers who think they're part of a jihad.
And some of those fighters, terrorist or otherwise, not only don't like the US, but are getting good training and a great recruiting tool to get people to join them.
For hardware, if the machine's got an Ethernet card and you're satisfied with the graphics resolution, and have enough disk space, you're fine. You won't be adding wireless cards that didn't have drivers back in the day, and lack of USB can be annoying (and my old P133 laptop has pre-Cardbus PCMCIA slots, so those are pretty much ruled out as well), and if you don't have enough RAM it's probably cheaper to buy a new motherboard than a lot of older-format RAM. But the machine was blazingly fast back when you bought it... even if it can't play MPEGs today.
Bloated software's a somewhat different issue - I won't say that Netscape 2.0 was a great system, but it could do basic web browsing back then and still can. You'll have trouble with Flash-heavy web pages, and maybe some Javascript, and you won't be able to open 50 tabs in the background of your browser unless you find an older version of Opera which will have no trouble (remember when Opera fit on half a floppy disk?) And CSS probably won't work, so web sites won't come out with the exact same font size that the web designer wanted, but they were never supposed to.
Does all of this mean that when my PII-233 had a big purple flash from the motherboard a few years ago and let the blue smoke escape, I went looking for another PII to replace it? No
Your engineers are in a cage, running on big iron? Are you using them to power some kind of large hamster wheel or something?
And of course there's always Xanadu....
Back in the late 1980s, when I was at Bell Labs (not Research), I was on a standards committee for Computer-Aided Logistics Support, trying to standardize computerized documentation formats. The primary directions the committee was working on were SGML for text and some vector graphics standard that I've forgotten for pictures.
SGML was a predecessor to XML, and was an abstract language describing document types that were typically like HTML with whatever markings and objects you needed to define, so we were essentially trying to define a DTD for our documentation.
There were people on the committee who got the "mark up the information content, let the reader's client format it" concept, where objects are things like "a 2nd-level paragraph", and people who didn't get it, and wanted to objects to be things like "a paragraph in 14-point bold-face" or "a page break" because they wanted to electronically represent the typical paper manuals and version control where you needed to replace pages to update the document, even though the manual might be an airplane-engine repair doc that some mechanic is trying to read on a wrist-mounted 24x80 screen while poking around in the engine. You may find this familiar, given the number of people over the past decade who've been trying to make web pages look exactly the way they want even when the user's browser or screen size may not be identical to theirs.
At one point my boss (who was a PhD type, not a Dilbert boss) asked if we needed to be concerned that our presence on the committee might tell competitors the kinds of things we were working on.
My reply was that "Well SGML is an obvious thing to write Hypertext in, so this is the kind of Research they'd expect us to be doing." Sigh - my mental model of hypertext was pretty much Hypercard and similar document packages, and I didn't get the linking-together-multiple-authors bit either