Normally when people want SSL VPNs, it's because they want to support browser-only users, without installing a client. If you're going to install a client anyway, you might as well use IPSEC. (Therefore, I find TFA's complaint that SSL-explorer doesn't have a full IPSEC client rather confusing - if you're using IPSEC, you don't need SSL, but the author did say he's looking for help....)
CLientless SSL-based VPNs are really convenient - some of them are genuinely clientless, and some of them have Java-glue web pages that fire up a lightweight client in the browser (unfortunately, sometimes that's IE-dependent), and as long as they do most of what you need to do most of the time, it's really nice for a sysadmin to be able to support lots of users without having to install software on their PCs, especially for an extranet or customer environment where you want more protection than just SSL web pages.
Some SSL-based VPNs also provide lots of fine-grained user permission management, so User Group A can access the Project A files, Group B can access group B's files, Engineers can see all the Secret Plans, Sales Reps can get the literature, and nobody can touch the HR files except through the limited front-end interface.
There are some other reasons people have wanted SSL VPNs in the past - they avoid some of the issues with NAT and firewalls, but most IPSEC clients have UDP-based NAT traversal that they'll use if they need it, and if firewalls are a problem (because you're working at a customer location or something), then you need to work out something with the customer's security admins, and that's even less likely to require an SSL VPN that also includes an IPSEC VPN client.
I'm not bothered by it (in spite of working for an ISP that sells services using several different vendors' equipment) - first of all, if you want supported commercial solutions, there are a number of companies that sell them, and you can go find them on Network World or Google or the other usual sources. (Getting reviews that tell you which products don't actually work very well may be harder than getting vendor-literature and PR puff pieces, but you can still get the basic facts.) And there are service providers who'll manage all this stuff for you, and you can get reviews of them too.
I've been interested in the free-beer approach myself - SSL VPNs look a lot like something that an Apache module or some Quid configuration documents could handle the easy 50-80% of the market space, which is browsing intranet websites, getting/putting files from a file server, and getting web access to Outlook or better email. Doing the job well may be a bit harder than that, in which case there's room for commercialware.
There's always room for paid support, especially for free-beer solutions, where you may need more support than the man pages and an online user forum can give you.
Back during the boom, a startup called Disappearing Inc made a similar system for email. Their tech guy explained that it was really important to define the problems you're trying to solve and the problems you're *not* trying to solve. If you're trying to help cooperating users communicate privately, you can do it, but if you're trying to prevent uncooperative users from getting around it, that's probably impossible and certainly snake oil at best. They weren't trying to keep the users from breaking the system with some kind of DRM nonsense - they were building something that would let the users make sure that they didn't keep records of their email that they weren't deliberately trying to keep. It's the Ollie North email backups problem, not the Mr. Phelps problem.
Hi, Don - I remember seeing the pie menu stuff you did on NeWS back in the 80s. It wasn't *that* hard to carry around a Sun-3 and a monitor:-)
I don't think we had sound on our workstations until the Sparcstation 1 or maybe 1+, and we mainly used that for writing to other coworkers' unprotected/dev/audio rather than for anything useful, but an IPC was also fairly easy to carry around...
While the parent poster was arguably flamebaiting or trolling about how Open Source doesn't always get the bugs found or fixed, and makes it easy for Bad Guys to write exploits, and he doesn't know that havoc is something you wreak as opposed to wrecking, he's actually hit on a couple of important problems here.
This isn't really a problem with buggy coding - it's a crypto math problem that is affected by implementation choices, and new crypto discoveries can hit some code harder than others. The code here was checked very thoroughly by *lots* of people, including some really strong crypto experts, because it's critical code for a lot of people. With RSA signatures, there's a public exponent "e" and a private exponent "d", and e is a pretty arbitrary prime, so it's common to pick a value that lets you do fast calculations. The popular values are 3, 65537, and occasionally 17, and it's hard to find a number x such that x**e mod n == y if you don't know d (or p and q.) The problem is that it's not so hard to find x and some junk such that (x,junk)**e mod n == (y,otherjunk), at least if e is small enough, and the standard ASN.1 code makes it easy to add arbitrary junk. 3 is small enough (and really fast to use), 17 might be, 65537 is pretty safe, and ASN.1 is the Mos Eisley of data representation protocols, a wretched hive of scum and villainy that nobody wants to mess around in. So some people do the right thing in checking the "otherjunk" beyond the y, but not everybody did, and until Bleichenbacher's attack you didn't need to.
Open Source does mean that you *can* update your copy of OpenSSL, without waiting for Microsoft Patch Day - and in the crypto world, the only way to trust anything is for the algorithms and implementation code to be documented and readable. They don't have to be "open" in the sense of "accepting patches from arbitrary people" or "free as in speech, not patented, not copyrighted, guaranteed to make RMS happy", but if you can't see the algorithms or install code you've recompiled from scratch yourself, you can't trust it.
So the fact that you've got to update OpenSSL and link it in to other code is really fine here - if you're paranoid, you need to do it yourself, and you've got the tools to do it; if you're not paranoid, this is a fairly tough exploit to actually do anything useful with, though you could go deleting a few certificates from your browser's security files if you're worried.
Hardware-based routers and PC-based routers are really solving much different problems. The hardware routers can handle large volumes of packet-shuffling in ASICs, without having to bother the CPU - on the other hand, if you want CPU and RAM, it's much much more cost-effective to buy a PC (even if you ignore the fact that Cisco gouges on price for standard commercial RAM.) PCI backplanes aren't made to handle all that much router traffic - they're overkill for connecting a DSL or cable modem connection, or a LAN with a few PCs on it, but don't expect lots of throughput between multiple gigabit ethernets. On the other hand, the new PCI-Express GigE cards talk about throughputs like 2 Gbps, so they're starting to catch up - a couple of $79 adapters in a $500 PC may not beat a Cisco 12000, but they could be real competition for a 7200.
Cisco sometimes adds customized processors for special applications - hardware encryption chips are especially useful for triple-DES, compared to doing the encryption in a CPU, though they're less critical for AES, and the CPU still gets involved in packet handling so it can sometimes still be a bottleneck.
I've seen two different kinds of projects like this during the Internet boom
One is that you're trying to develop something really cool, and you're raising money to let you do that
The other is that you want to have a company that pays you a lot, so you're trying to develop something cool as a hook to get investors to give you money.
It wasn't just during the Boom, and it wasn't just Internet projects, but back when you could go to Menlo Park and shake a tree and a venture capitalist would fall out, both kinds of projects were quite popular and ran like well-oiled snakes.
It sounds like the inventor *might* have the physics to be able to develop a little drive for steering spacecraft, which is a much much smaller problem than launching them, and having steering drives that ran for a long time on electricity without physical fuel could be really useful. I can't tell for sure from the article if there's really an existing prototype that generates thrust, or if it's just physics on paper. The launch engines / flying cars / etc. sounds like Pure Hype, not only without a prototype but without even the basic physics or engineering work that says that the thing can not only generate thrust, but can generate *enough* thrust to lift its weight and the weight of it's power feeds. (For steering engines that's not necessary - the big hulking chemical engine has enough power to lift the thing, and your Magic Engine only needs to be able to nudge the ship around slowly for a long time, which is much simpler.
It's been a few years since I've dealt with the cable modem industry much, but I find any claims of high reliability to be surprising.
The economics of cable modems are that you're piggybacking service on top of Cable TV service, and the reliability numbers are driven by how many technicians with trucks they hire to go fix things when they break, plus how often installers break things by accident. For telephones, that's high reliability, with lots of techs and trucks, because there's not only a century of hype and propaganda about highly reliable service service, but it's a regulated industry that really gets on their back for slow repair times because "people might die" if you don't fix their phone fast. For Cable TV, on the other hand, it's just television, and if it's not working you can read a book or watch DVDs." That clashed rather rudely with the Internet customers' expectations about 100% uptime, short downtimes, and major panic if things stay broken all weekend when a snowstorm takes out their service on a Friday night.
Also, cable TV networks were built on a town-by-town bases, with decisions usually made about how many free channels the town council could use and whose brother-in-law got the street-repair contracks, not about who had insightful vision into the future of telecommunications. So there was a lot of random equipment, often low-quality or in bad shape, running cable TV - the cable modem business has forced them to upgrade it a lot, and incresaing node density means that fewer users lose service if something fails.
I'm not sure whether my own cable TV service has been more reliable than my phones or DSL or not. Every couple of years a phone installer messes up something while working on a box down the street and I lose service for up to a day and a half before they fix it, and it takes down my DSL as well as my voice service (so I just use cellphones.) My cable TV service problems have tended to be that an individual channel stops working for a few days, or sometimes the whole thing runs black, but the main problem was lousy gradually-degrading video that took over a year to fix.
If you're seeing a MOS above 4, it's either doing a 64kbps telco-style G.711 Voice codec, which is about 80kbps after you add IP overhead (takes a big chunk of a 128kbps upstream, if you still have that), or else it's PC-to-PC calls doing a codec that takes advantage of the higher analog bandwidth you can get using a PC soundcard (e.g. 5.5, 8, or 11 kHz audio signal instead of 4kHz for telco (the clock rate's twice the bandwidth), and probably 16-bit A/D samples instead of 12-bit A/D companded down to 8-bit.) Any of the codecs below 32kbps are going to give you MOS scores less than 4.0, and worse if you're seeing jitter or packet loss, though there are codecs like iLBC which are designed to have their packets get abused in transmission.
Many of the VOIP services are designed to use the 8kbps or 5.6kbps codecs instead of 64kbps (expands to about 24kbps after RTP/UDP/IP overhead.) Mobile Phones have taught the technology market that phone transmission doesn't have to be that great as long as you've got a decent handset and there aren't trucks driving by while you're talking.
Some of the early cable voice standards weren't VOIP - they were 4KHz analog channels carved off the bottom of the transmission spectrum, connected to standard phone switches.
One reason you're paying so much for voice telco service is that they're supposed to fix things, and you can file a trouble ticket if they're broken, which yours obviously was. Back in the mid-80s, I was using 2400-baud modems from home (dialing in to the office), and the phone line I used for it started having trouble. The telco repair people really didn't understand the concept that "what's it sound like?" was "won't do 2400 baud, just 1200, even though it did 2400 just fine when the line was new". "No, really, what's that sound like?" "My screen shows }i }i }} }}} }}i a lot" "duh?".
Eventually it degraded to the point that the audio sounded like "KKKKXKXKKXKXXXXKXXXKKXKXKX", at which point the replaced the dropline that was rubbing against a tree branch, and then it did 2400 baud just fine again. On the other hand, if it's just a lame handset, it's just a lame handset.
Wouldn't happen. Cable ISPs are mostly buying large pipes - the main question is whether they buy them big enough. The big problem is that the DSL access companies are very likely to *not* QoS the packets unless their customers pay extra, so VOIP will get swamped by your BitTorrent traffic, or music downloads, or similar high-volume data traffic. The cablecos also need to manage outbound traffic appropriately, but that's not too hard, even though they're almost certainly running 80kbps voice (64kbps raw + RTP/UDP/IP headers) rather than compressed.
It seems awfully high to me. (I can't really bitch, because I had a work laptop stolen a couple of years ago, and I've had one or two coworkers who've also had them stolen, but it still seems high.) If they're seeing loss rates in that range, they definitely should be running encrypted file systems, not just boot passwords. The person who stole mine was definitely in the quick-grab hardware resale market, not the information theft market - I hope the person he fenced it to had the sense to wipe the drive and install pirated Windows:-)
I can see that kind of loss rate if the problem is employee theft by short-term temporary census workers or some similar special case.
There are lots of RTOS kinds of applications that go for light-weight because they need speed and that's sometimes faster on average and sometimes more reliable. But that's not the critical feature for real-time-ness - it's guaranteed maximum response time, not average speed, usually because the RTOS application is controlling some real-world equipment that needs it. "Going Real Fast" often helps, which is *why* many of the systems are lightweight, but it's not always necessary. Canonical applications include things like aircraft steering or chemical process controls - avoiding the occasional N millisecond latency glitch is much more important than getting average responses in N/10 ms, and that means that the OS kernel has to hand back control often enough regardless of whatever else it might want to do.
Some telephone switches could also have new operating systems installed while applications are running. Pity that most of them ran on 1970s-80s bit-slice architectures:-) And please don't insult the parent article's poster, because he's right and you're wrong....
IPv6 doesn't solve the scalability problems for routing protocols with multi-homing, which makes it really hard for ISPs to adopt it. It was *supposed* to, but the early ideas didn't work out in practice. IPv4 deals with those problems using Band-Aids, lots of RAM, and lots of complaining and worrying, but basically the limits on IPv4 address space will break other things before that totally kills the Internet, while IPv6 won't have that excuse, and replicating the Band-Aids would be really ugly and not last very long before it collapses, plus the bandaids need to be 4 times as large for 128-bit addresses.
Almost every commercial business out there wants at least two Internet connections for their web/email/etc servers, so if one connection is down, people can reach them through the other one, using the same IP address (because DNS caching is too slow to switch addresses in the middle of a transaction, plus browsers often cache DNS longer.) Smaller ISPs and hosting/colo centers have the same problems as enterprises. This turns out not to scale very well, because keeping track of multiple routes for everybody instead of just aggregates means that every router on the Internet backbones not only needs big routing tables implemented in ASICs that might not have room for them, but needs to grind N**2-sized calculations when things change so they need lots of CPU RAM and horsepower.
There are a number of different research projects like shim6 that want to solve the problem, but so far it's still fundamentally hard. The initially proposals were that everybody should only use Provider-Allocated address blocks (assigned by their ISPs), not the Provider-Independent addresses that much of the Internet uses today, and that was just not acceptable for the customer base's needs. Once somebody finds a decent fix, it's just a matter of replacing lots of big routers, redesigning ASICs to handle larger address spaces, Simple Matters of Programming, etc., and Moore's Law helps a bit with this. Until then, it's really ugly, and the IP Address Registries (ARIN, RIPE, APNIC, and their self-appointed evil ICANN overlords) have been resistant to just giving out IPv6 space the way the did with IPv4 (partly to discourage a land-rush before the technology's ready, but partly because ICANN seems to view this as another potential funding source, charging money for allocating a non-scarce resource, which has a similar effect.)
As long as you've got lots of people with good technical educations (which China and India both have) and enough capital and business people around (which they probably have, if the bureaucrats get at least partially out of the way), you can build the rest quickly. It didn't take the US very long, once the market realized that the Web was not only cool but could make money, to have millions of people working on it, all moving to Silicon Valley hoping to become Mozillionaires. Most of them failed, but that's how business and innovation work, and that's ok. Silicon Valley developed a rather special culture where lots of people could fail while trying to do Cool Stuff, and people would hand us lots of money for a while.
I've finally had to start wearing reading glasses, and most of my gaming is still Nethack and Solitaire, so I'm allowed to make old-geezer gaming jokes...
There are people who never understood the fundamental concept of SGML / HTML, which is that the Markup Language describes the objects and the Reader's Browser decides how to display them. They didn't all get it in ~1987, when I was working with standards committees where some people wanted to nail down "Level 2 Headings" as "14-point Bold-Face San-Serif" while other people wanted to be able to display aircraft repair manuals on portable readers that you could use while standing on a ladder trying to get the engine parts unstuck, which might be monospaced uppercase-only with grease on the touchscreen or use hands-free audio browsers so blind people could read hypertext.
This was much less of a problem before the early-mid Internet Boom,
when web pages were still fundamentally text with pictures written by people who wanted to say things rather than Revenue Generators written by people who wanted to attract Eyeballs,
before the flashy marketdroids took over and hired art directors,
and before enough people became web designers that they had to compete for jobs based on their Flashy Artworkz Sk177z, since any high school dropout who could type paragraph codes and match angle-brackets could now be a web designer,
before Web Design Software companies started selling products to let high school dropouts design flashy web pages without needing Artwork Sk177z or knowing how to match angle brackets, and
before Microsoft started promoting IE's non-standard incompatible features to web designers as a way to prevent Netscape+Java+Unix from killing Windows.
Now 95% of them don't get it:-)
CSS has helped a bit - it moved much of the display out of the object-markup body, so it's easier for the reader to override the author's visual preferences, and it's easier for the author to let go of some control. But Javascript has made things worse. And part of the problem is that you're probably using Firefox, not IE, so IE-specific mismarkup may be defaulting to tiny fonts because it's not the same way Firefox would render it. So switch to Lynx, and you'll be able to read it just fine:-) Cellphones/PDAs/Treos help, because they're forcing many web authors to use markup that can be rendered on wimpy screens that are no longer walled-garden WAP but still won't ever have the resolution that the author's PC has.
Me? Not only am I old and cynical, but I'm reading this on a relatively new work laptop that *still* doesn't have as many pixels as the *Sun-3* I was using two decades ago, and it's possible that the *next* laptop we get at home will only do WXGA, which is *still* slightly fewer pixels than 1152x900 (I'd rather pay less money for a faster machine with more pixels, but the one we're looking at is very small and has a very bright clear screen.) Moore's Law means that instead of that screen costing $3000, a CRT costs $29 or LCD costs under $300, but it's still lame. And that means those web-designing art directors with their 23-inch Apple displays or game designers with gimongous-memory 4-D graphics-accelerator cards will continue to design stuff that looks ugly on my machine, in spite of how beautiful it looks to them. And they continue to use pixel-based design tools - back then, when my boss had trouble reading things on his screen, we told Sun NeWS Postscript-based windowing to use bigger fonts, and it rendered them beautifully. 15-20 years later, when I had trouble reading my computer screens all day, Windows wasn't much help, so I had to get reading glasses:-)
What do I need to connect my old analog vinyl turntable to my PC's soundcard? Can I just plug it in (given a few cable adapters), or do I need to mess with pre-amps or other conversion boxes?
Ok, so the Pentium 133 laptop with the broken screen and 1 GB disk isn't much, and it's mostly acting as a spare for web browsing, but one of the back-burner projects is to install a small-Linux distro or OpenBSD on it and use it as a DNS server or spam honeypot or something. The big limitation has been that it doesn't do USB, so I'll need to fire up a SAMBA server or something to give it some more storage.
Some years ago, the Partnership for a Drug-Free America got something like 15% of its funding from Philip Morris alone. Hypocrites. Glad to see they're branching out into propaganda about things that don't directly affect them (except I suppose that global warming will make it possible to grow more tobacco in Canada:-)
It's not a total lie - he is strongly against pornography, and I'm sure if he gets the power he's trying to grab here he'll be sure to use some of it for investigating child porn.
But that's not what this is about, and I'm insulted (if not surprised) that he's being so blatant.
Slashdot Mirror
CLientless SSL-based VPNs are really convenient - some of them are genuinely clientless, and some of them have Java-glue web pages that fire up a lightweight client in the browser (unfortunately, sometimes that's IE-dependent), and as long as they do most of what you need to do most of the time, it's really nice for a sysadmin to be able to support lots of users without having to install software on their PCs, especially for an extranet or customer environment where you want more protection than just SSL web pages.
Some SSL-based VPNs also provide lots of fine-grained user permission management, so User Group A can access the Project A files, Group B can access group B's files, Engineers can see all the Secret Plans, Sales Reps can get the literature, and nobody can touch the HR files except through the limited front-end interface.
There are some other reasons people have wanted SSL VPNs in the past - they avoid some of the issues with NAT and firewalls, but most IPSEC clients have UDP-based NAT traversal that they'll use if they need it, and if firewalls are a problem (because you're working at a customer location or something), then you need to work out something with the customer's security admins, and that's even less likely to require an SSL VPN that also includes an IPSEC VPN client.
I've been interested in the free-beer approach myself - SSL VPNs look a lot like something that an Apache module or some Quid configuration documents could handle the easy 50-80% of the market space, which is browsing intranet websites, getting/putting files from a file server, and getting web access to Outlook or better email. Doing the job well may be a bit harder than that, in which case there's room for commercialware.
There's always room for paid support, especially for free-beer solutions, where you may need more support than the man pages and an online user forum can give you.
Back during the boom, a startup called Disappearing Inc made a similar system for email.
Their tech guy explained that it was really important to define the problems you're trying to solve and the problems you're *not* trying to solve. If you're trying to help cooperating users communicate privately, you can do it, but if you're trying to prevent uncooperative users from getting around it, that's probably impossible and certainly snake oil at best. They weren't trying to keep the users from breaking the system with some kind of DRM nonsense - they were building something that would let the users make sure that they didn't keep records of their email that they weren't deliberately trying to keep. It's the Ollie North email backups problem, not the Mr. Phelps problem.
I don't think we had sound on our workstations until the Sparcstation 1 or maybe 1+, and we mainly used that for writing to other coworkers' unprotected /dev/audio rather than for anything useful, but an IPC was also fairly easy to carry around...
This isn't really a problem with buggy coding - it's a crypto math problem that is affected by implementation choices, and new crypto discoveries can hit some code harder than others. The code here was checked very thoroughly by *lots* of people, including some really strong crypto experts, because it's critical code for a lot of people. With RSA signatures, there's a public exponent "e" and a private exponent "d", and e is a pretty arbitrary prime, so it's common to pick a value that lets you do fast calculations. The popular values are 3, 65537, and occasionally 17, and it's hard to find a number x such that x**e mod n == y if you don't know d (or p and q.) The problem is that it's not so hard to find x and some junk such that (x,junk)**e mod n == (y,otherjunk), at least if e is small enough, and the standard ASN.1 code makes it easy to add arbitrary junk. 3 is small enough (and really fast to use), 17 might be, 65537 is pretty safe, and ASN.1 is the Mos Eisley of data representation protocols, a wretched hive of scum and villainy that nobody wants to mess around in. So some people do the right thing in checking the "otherjunk" beyond the y, but not everybody did, and until Bleichenbacher's attack you didn't need to.
Open Source does mean that you *can* update your copy of OpenSSL, without waiting for Microsoft Patch Day - and in the crypto world, the only way to trust anything is for the algorithms and implementation code to be documented and readable. They don't have to be "open" in the sense of "accepting patches from arbitrary people" or "free as in speech, not patented, not copyrighted, guaranteed to make RMS happy", but if you can't see the algorithms or install code you've recompiled from scratch yourself, you can't trust it.
So the fact that you've got to update OpenSSL and link it in to other code is really fine here - if you're paranoid, you need to do it yourself, and you've got the tools to do it; if you're not paranoid, this is a fairly tough exploit to actually do anything useful with, though you could go deleting a few certificates from your browser's security files if you're worried.
Cisco sometimes adds customized processors for special applications - hardware encryption chips are especially useful for triple-DES, compared to doing the encryption in a CPU, though they're less critical for AES, and the CPU still gets involved in packet handling so it can sometimes still be a bottleneck.
- One is that you're trying to develop something really cool, and you're raising money to let you do that
- The other is that you want to have a company that pays you a lot, so you're trying to develop something cool as a hook to get investors to give you money.
It wasn't just during the Boom, and it wasn't just Internet projects, but back when you could go to Menlo Park and shake a tree and a venture capitalist would fall out, both kinds of projects were quite popular and ran like well-oiled snakes.It sounds like the inventor *might* have the physics to be able to develop a little drive for steering spacecraft, which is a much much smaller problem than launching them, and having steering drives that ran for a long time on electricity without physical fuel could be really useful. I can't tell for sure from the article if there's really an existing prototype that generates thrust, or if it's just physics on paper. The launch engines / flying cars / etc. sounds like Pure Hype, not only without a prototype but without even the basic physics or engineering work that says that the thing can not only generate thrust, but can generate *enough* thrust to lift its weight and the weight of it's power feeds. (For steering engines that's not necessary - the big hulking chemical engine has enough power to lift the thing, and your Magic Engine only needs to be able to nudge the ship around slowly for a long time, which is much simpler.
The economics of cable modems are that you're piggybacking service on top of Cable TV service, and the reliability numbers are driven by how many technicians with trucks they hire to go fix things when they break, plus how often installers break things by accident. For telephones, that's high reliability, with lots of techs and trucks, because there's not only a century of hype and propaganda about highly reliable service service, but it's a regulated industry that really gets on their back for slow repair times because "people might die" if you don't fix their phone fast. For Cable TV, on the other hand, it's just television, and if it's not working you can read a book or watch DVDs." That clashed rather rudely with the Internet customers' expectations about 100% uptime, short downtimes, and major panic if things stay broken all weekend when a snowstorm takes out their service on a Friday night.
Also, cable TV networks were built on a town-by-town bases, with decisions usually made about how many free channels the town council could use and whose brother-in-law got the street-repair contracks, not about who had insightful vision into the future of telecommunications. So there was a lot of random equipment, often low-quality or in bad shape, running cable TV - the cable modem business has forced them to upgrade it a lot, and incresaing node density means that fewer users lose service if something fails.
I'm not sure whether my own cable TV service has been more reliable than my phones or DSL or not. Every couple of years a phone installer messes up something while working on a box down the street and I lose service for up to a day and a half before they fix it, and it takes down my DSL as well as my voice service (so I just use cellphones.) My cable TV service problems have tended to be that an individual channel stops working for a few days, or sometimes the whole thing runs black, but the main problem was lousy gradually-degrading video that took over a year to fix.
Many of the VOIP services are designed to use the 8kbps or 5.6kbps codecs instead of 64kbps (expands to about 24kbps after RTP/UDP/IP overhead.) Mobile Phones have taught the technology market that phone transmission doesn't have to be that great as long as you've got a decent handset and there aren't trucks driving by while you're talking.
Some of the early cable voice standards weren't VOIP - they were 4KHz analog channels carved off the bottom of the transmission spectrum, connected to standard phone switches.
Eventually it degraded to the point that the audio sounded like "KKKKXKXKKXKXXXXKXXXKKXKXKX", at which point the replaced the dropline that was rubbing against a tree branch, and then it did 2400 baud just fine again. On the other hand, if it's just a lame handset, it's just a lame handset.
Wouldn't happen. Cable ISPs are mostly buying large pipes - the main question is whether they buy them big enough. The big problem is that the DSL access companies are very likely to *not* QoS the packets unless their customers pay extra, so VOIP will get swamped by your BitTorrent traffic, or music downloads, or similar high-volume data traffic. The cablecos also need to manage outbound traffic appropriately, but that's not too hard, even though they're almost certainly running 80kbps voice (64kbps raw + RTP/UDP/IP headers) rather than compressed.
I can see that kind of loss rate if the problem is employee theft by short-term temporary census workers or some similar special case.
Some telephone switches could also have new operating systems installed while applications are running. Pity that most of them ran on 1970s-80s bit-slice architectures :-) And please don't insult the parent article's poster, because he's right and you're wrong....
Almost every commercial business out there wants at least two Internet connections for their web/email/etc servers, so if one connection is down, people can reach them through the other one, using the same IP address (because DNS caching is too slow to switch addresses in the middle of a transaction, plus browsers often cache DNS longer.) Smaller ISPs and hosting/colo centers have the same problems as enterprises. This turns out not to scale very well, because keeping track of multiple routes for everybody instead of just aggregates means that every router on the Internet backbones not only needs big routing tables implemented in ASICs that might not have room for them, but needs to grind N**2-sized calculations when things change so they need lots of CPU RAM and horsepower.
There are a number of different research projects like shim6 that want to solve the problem, but so far it's still fundamentally hard. The initially proposals were that everybody should only use Provider-Allocated address blocks (assigned by their ISPs), not the Provider-Independent addresses that much of the Internet uses today, and that was just not acceptable for the customer base's needs. Once somebody finds a decent fix, it's just a matter of replacing lots of big routers, redesigning ASICs to handle larger address spaces, Simple Matters of Programming, etc., and Moore's Law helps a bit with this. Until then, it's really ugly, and the IP Address Registries (ARIN, RIPE, APNIC, and their self-appointed evil ICANN overlords) have been resistant to just giving out IPv6 space the way the did with IPv4 (partly to discourage a land-rush before the technology's ready, but partly because ICANN seems to view this as another potential funding source, charging money for allocating a non-scarce resource, which has a similar effect.)
As long as you've got lots of people with good technical educations (which China and India both have) and enough capital and business people around (which they probably have, if the bureaucrats get at least partially out of the way), you can build the rest quickly. It didn't take the US very long, once the market realized that the Web was not only cool but could make money, to have millions of people working on it, all moving to Silicon Valley hoping to become Mozillionaires. Most of them failed, but that's how business and innovation work, and that's ok. Silicon Valley developed a rather special culture where lots of people could fail while trying to do Cool Stuff, and people would hand us lots of money for a while.
I've finally had to start wearing reading glasses, and most of my gaming is still Nethack and Solitaire, so I'm allowed to make old-geezer gaming jokes...
This was much less of a problem before the early-mid Internet Boom,
CSS has helped a bit - it moved much of the display out of the object-markup body, so it's easier for the reader to override the author's visual preferences, and it's easier for the author to let go of some control. But Javascript has made things worse. And part of the problem is that you're probably using Firefox, not IE, so IE-specific mismarkup may be defaulting to tiny fonts because it's not the same way Firefox would render it. So switch to Lynx, and you'll be able to read it just fine :-) Cellphones/PDAs/Treos help, because they're forcing many web authors to use markup that can be rendered on wimpy screens that are no longer walled-garden WAP but still won't ever have the resolution that the author's PC has.
Me? Not only am I old and cynical, but I'm reading this on a relatively new work laptop that *still* doesn't have as many pixels as the *Sun-3* I was using two decades ago, and it's possible that the *next* laptop we get at home will only do WXGA, which is *still* slightly fewer pixels than 1152x900 (I'd rather pay less money for a faster machine with more pixels, but the one we're looking at is very small and has a very bright clear screen.) Moore's Law means that instead of that screen costing $3000, a CRT costs $29 or LCD costs under $300, but it's still lame. And that means those web-designing art directors with their 23-inch Apple displays or game designers with gimongous-memory 4-D graphics-accelerator cards will continue to design stuff that looks ugly on my machine, in spite of how beautiful it looks to them. And they continue to use pixel-based design tools - back then, when my boss had trouble reading things on his screen, we told Sun NeWS Postscript-based windowing to use bigger fonts, and it rendered them beautifully. 15-20 years later, when I had trouble reading my computer screens all day, Windows wasn't much help, so I had to get reading glasses :-)
What do I need to connect my old analog vinyl turntable to my PC's soundcard?
Can I just plug it in (given a few cable adapters), or do I need to mess with pre-amps or other conversion boxes?
Fortunately I don't have that problem - I've got the Ethernet card that we bought when we bought the laptop, and it still works fine...
so get yourself an A-size scanner and just scan each page in two parts?
Or if there aren't too many grayscales that you'd trash,
just run it all through a photocopier to shrink to 8.5x11 and scan that?
Yup, that's correct - No USB ports, and no, it can't do Cardbus either. I assume the Ethernet card I have is 10 Mbps - it hasn't mattered in the past.
Ok, so the Pentium 133 laptop with the broken screen and 1 GB disk isn't much, and it's mostly acting as a spare for web browsing, but one of the back-burner projects is to install a small-Linux distro or OpenBSD on it and use it as a DNS server or spam honeypot or something. The big limitation has been that it doesn't do USB, so I'll need to fire up a SAMBA server or something to give it some more storage.
Some years ago, the Partnership for a Drug-Free America got something like 15% of its funding from Philip Morris alone. Hypocrites. Glad to see they're branching out into propaganda about things that don't directly affect them (except I suppose that global warming will make it possible to grow more tobacco in Canada :-)
But that's not what this is about, and I'm insulted (if not surprised) that he's being so blatant.
He's from the Wild West, where editors use Dead Trees.