Takes up Connector Space - your desktop machine probably doesn't care, but on laptops it's more annoying, and on pocket-sized machines it's even more annoying. For USB, you only need one or two small connectors, and use hubs if you need to expand the number of connections. Laptop makers often address this problem by using ugly and often fragile proprietary connectors and making you buy custom cables; might as well use USB instead.
Takes up Motherboard Space - Again, that's not a big issue for a desktop computer, but it _is_ an issue, and it's much more of an issue on laptops, palmtops, and various appliances. The issue isn't just the connectors, each of which have motherboard frobs to attach to - it's also hardware driver chips, though the logic parts of those are increasingly integrated into Southbridge chips and such.
The Need for Speed - Serial ports were fine back in the day, but it's nice to have higher speed connections, and USB can do that job, while RS232 sometimes gets flaky above 19200, often by 56000, and usually by 115.2k.
Power Supply issues - Each interface type that needs yet another voltage level is going to affect the power supply and/or motherboard. It's much nicer if you can avoid all that stuff.
IRQs - Each legacy interface out there has interrupt-handling baggage. If you've got to have USB anyway (and these days, enough things you might want to connect to a PC use USB as more than just a power supply), might as well use it for as many applications as make sense, rather than needing hardware-oriented driver support.
Cluttery Things You Don't Use - OK, maybe you're a gamer and you _want_ a soundcard-based joystick port and an interrupt or two that get tied up supporting it. I don't, and I'd much rather have things like joystick support be optional features on USB than making the soundcard driver situation worse than it has to be, especially since those game port things all look like they're really emulating older interfaces anyway.
Devices that don't have useful standard legacy interfaces, like monitors - I'm not thrilled with USB as a monitor-control inteface, but apparently it's becoming popular. Sigh.
Differently Broken Device Drivers - OK, I confess, the reason I'm using the parallel port for my printer instead of that perfectly good USB cable is that the device driver support seems to be broken. I think my WinME desktop could probably work ok with the USB, but the cable was the right length for my desk, and I needed the longer USB cable to reach my laptop:-) But my work laptop runs Win2000 in "You're Not The Sysadmin" mode, and for some reason it thinks that plugging anything into a USB port requires administrator permissions [expletive deleted] - Not just to install the software the first time, but every time I want to plug it in! Arrrgh!
Adequate substitutes for most interfaces - Sure, sometimes you _do_ need a serial interface because there's some device out there that wants it, but that's increasingly rare except for things like old Palm Pilots or some GPS hardware, and most of the people who need that kind of thing can use desktop machines with serial or parallel PCI cards if they can't get USB-to-serial frobs to work.
On the other hand, legacy ports have the advantage that the drivers usually work, and the hardware is either documented or old enough that it's been reverse-engineered if anybody cared about it. USB is another opportunity for manufacturers to put out documentation that says "Here's what you tell Microsoft Word to use this scanner" "Here's how you set Photoshop to use your camera" instead if "here's the set of messages the box sends" or "It's TCP/IP, it's port 31337, have a good time".
Paul Kocher is one of the well-known experts in the practical crypto field. As you can see from his web site, he's done some innovative mean nasty approaches to cracking cryptosystems (mathematical proofs are a fine thing, but if you can figure out the state of the CPU by measuring its response time or detecting the power consumption, your system isn't as secure as you thought:-)
The station doesn't need an engineer to copy every copy-protected CD, just to set up the equipment. Trained monkeys _can_ handle the job of popping the CD into the "Broken CD Ripper Drive" and clicking on the "RIP Broken CDs" software. And for bigger networks, they'll have somebody back at headquarters who can do that, and either ship out the MP3s on line or else copy the tracks they want onto MP3-CDs or regular CDs.
While it's possible that the boss's "didn't understand" meant that he was a Luddite who was scared of anything that sounded complicated, it's much more likely that "didn't understand" included not knowing exactly what the undocumented copy protection software was going to do to his machines, or what software designed to prevent you from doing things would prevent him from doing, or whether it would mess up the software that he's using to handle music beyond what a basic MP3 player would do, given that copy-protection applications are _designed_ to mess up software like that. Or it could mean that he didn't understand what, if any, legal remedies he'd have if the copy-protection software messed up his station software, but since it was probably a cross-jurisdictional thing, he didn't expect to have much remedy.
Shorten is a lossless audio compression system that typically gets about 2:1 compression. It's used a lot by the etree jam band music trading community, which tends to start with audience recordings and doesn't want to degrade them further (unlike the old days on Nth-generation analog tape copies:-) That obviously takes a lot more space than small MP3s, but it still lets you fit twice as much music on a disk drive. So that 120GB disk drive that cost $120 at Fry's can now hold 240 CDs (Hmmm... I think the CD jukeboxes I saw could hold about 200 CDs for about $200. I remember when the computer WORM drive jukeboxes were more like $100K for that kind of capacity:-)
Yes, I realize that it's possible to do good-quality MP3 recordings, and that FM or especially AM radio will also distort the sound, but if they're using random MP3s downloaded from the net, most of those are encoded at lower bit rates for portable players and often with lousy coders. I hope they're at least using really good audio cards instead of the random-quality cards built into motherboards...
In practice, as long as you use decent quality equipment, this does sound like a practical way to run a radio station. If the DJs are in control or the music, it lets them find and queue up material quickly, and arrange it so they can easily go from one tune to the next or cut in to talk or patch in commercials, and makes it easier for things to run on autopilot if they need it to. And with the changes in disk drive cost over the last few years, they can store a few thousand songs at decent compression levels. On the other hand, if the radio station is one of those centrally controlled things that don't have real DJs at each station, they can upload each song once and cue things remotely.
Hi. This is my usual rant about Slashdot articles announcing that Some-Random-Name has reached Version N+1 or added Some-Generic-Feature-Like-Themes without saying what the product actually is or does. (Of course, people who don't know Enlightenment's version history won't get the April Fools' Joke here...)
With some kinds of badly written rules, you can pick whichever interpretation annoys you least and work from there. This doesn't appear to be one of them - if somebody can use the VPN/firewall/NAT/etc. to conceal the identity of the user from the carrier (or for that matter, from an eavesdropper), or conceal the subscriber's identity, or conceal which machine behind the firewall the packets are from (thus concealing that you've got more than one, which violates _some_ carrier's terms of service), then it's potentially illegal in Michigan, and you can't sell them your VPN/firewall/NAT/etc. hardware without risking violating it, because the law is quite clear that it not only applies to Michiganders who rip off their cable companies (like most of the other states' laws), it applies to any of them who buy equipment they _could_ use to rip off service or conceal that they're doing it, and it applies to anybody who sells equipment to anybody in Michigan that they could use to rip off service or conceal it.
I work for a big ISP that sells several kinds of VPN services, as well as selling routers to users who want to manage the routers themselves. I'd rather not see our Michigan sales reps risk being hauled into jail
because that Cisco we installed on their premises can do NAT, or
because that firewall conceals their machines from crackers, or
because their VPN box conceals data from eavesdroppers, or
because their SSL conceals web-visitors' credit card numbers from thieves, or
because their email system conceals real email addresses from spammers.
And I'd rather not see our sales people out of work either. But until somebody gets a temporary restraining order on enforcement, it's a real problem.
Reorganization won't help ICANN, because that was never the fundamental problem. ICANN publicized itself as having the goal of replacing Jon Postel, making the DNS system run well and perhaps managing other things like IP address space. But its definitions of "DNS running well" weren't about technology, and the IP they cared about wasn't the Internet Protocol, but Intellectual Property, and their definitions of "DNS running well" were about Intellectual Property Owners being able to control the ways that the DNS system affected their IP, particularly trademarks, and secondarily about having business models that let it fund itself stably, and only after that doing anything about technology.
That's why you'll see clumsy UDRP mechanisms that work much better for big corporations than for individuals. It's also why whois records are inherently concerned with privacy invasion (making sure to get your True Name and True Address so subpoenas work, and that everybody who manages any part of the domain registration process has to collect that rather than setting their own local policies) but don't require whois records to have actual email addresses that get to actual people who respond to fix things.
Now, some of the problems can be attributed to incompetence rather than malice, and some of them can be attributed to wise conservatism rather than indecision, and reorganization might affect both. Deploying additional TLDs has always been a very visible thing that lots of people wanted ICANN to do, but once they're deployed, they're deployed, and undoing stupid deployments is much harder than delaying. And sure, they probably couldn't have predicted the dot-com crash which radically affected the market value of domain names. But deploying more TLDs is more interesting to people who want to do new and interesting businesses than to major trademark owners who don't want to have to hassle with pre-protecting example.newTLD when they already own example.com, especially when Example Semiconductors has as good a claim to example.newTLD as the Example Soft Drinks Company which owns example.com.
Removable disk mounts like that are critical for backups and upgrades. In addition to the "easily install/run other operating systems" that somebody else wrote about, the rapid drop in disk drive costs and increase in sizes over the last couple of years have made extra hard disks one of the most cost-effective backup media available, and they're pretty much the only thing that won't go obsolete or incompatible quickly, unlike many of the writable DVD formats, which seem to be the only near competition.
Encryption doesn't hurt VOIP quality.
on
Snooping on VOIP
·
· Score: 1
If you've got problems with VOIP quality when you're using a VPN, the problem isn't the encryption, it's the rest of the system. It's only bad if it's done badly. The encryption itself isn't the problem - it's much less CPU work than voice compression, even with something slow like 3DES. If encryption were handled by the VOIP system, instead of tacked on by a VPN, it wouldn't be a problem at all.
Headers - For most VOIP systems, the compressed voice isn't very big - it's smaller than the RTP and IP headers, so Cisco routers that do VOIP use a cRTP compressed header format, somewhat like the compressed SLIP/PPP things, but they can't use that over IPSEC. With compressed headers, that 8kbps stream of compressed voice typically expands to 11-12 kbps, while with uncompressed headers, it's about 24kbps. On a modem, which has 28-33kbps upstream, this is not good:-)
Prioritization by Type of Service (ToS) bits - IP packet headers have some bits to indicate priority, which aren't widely supported, but even without them, it's nice to look at the TCP/UDP port numbers to be able to send VOIP and telnet and other latency-sensitive small packets before sending big file transfer packets. But most dedicated VPN hardware and software doesn't know how to do this, either by port number or TOS, and IPSEC standards tend not to support passing TOS bits from the inside of the tunnel to the outside, because that not only leaks information about the encrypted traffic (crypto purists don't like this), but also might result in packets from the VPN stream getting reordered (which tends to break the crypto.) So if you want your packets prioritized, you need to be careful about what order you use to put the packets into the tunnel, and either don't mark the VPN tunnel with TOS bits or else mark the whole thing high-priority, both of which can be rude and suboptimal.
Also, it doesn't help that IPSEC tunnels aren't TCP or UDP, they're ESP or (rarely) AH, so anything that handles them later that would like to prioritize by port number can't do that.
On an overloaded network, prioritization is important. On an unloaded network, it's not much of an issue.
They could sort of get a wiretap order now
on
Snooping on VOIP
·
· Score: 1
Assuming you're using a VOIP-to-telephony gateway in the US, various sets of police could probably get a wiretap order now, but they'd have trouble implementing it, because the connection to your home isn't the kind of equipment they're good at wiretapping. If they did a tap at Vonage's gateway, that part is a shared trunk from their VOIP routers to a telco, so there isn't a convenient relationship that says that "Line 3 is Doug Naka's phone". They could tap _all_ the lines, and only keep the ones they really want (or the ones that sound like fun), but that's lots more work than they want to do, so they want to be able to force other people to do the work for them. Also, if VOIP carriers _do_ start using encryption, if it's not convenient to wiretap the wireline side, they want to be able to wiretap the IP side.
Another problem is non-telco VOIP carriers. The regulations are pretty clear for regulated telcos - they're much less clear for people who aren't. For instance, if the PBX at your office acts as a gateway for all your coworkers who have VOIP hardware phones or software phones on their PCs, and DSL at home with VPNs to the office - CALEA lets the telco wiretap your company's phone system at the telco trunk, but they don't know that extension 1234 is your coworker "Bob" who's also selling ganja on the side. And as VOIP carriers become less legacy-telco dependent, what about calls that only use the carrier as a presence server (e.g. ICQ or equivalent) to set up the connections and do the actual VOIP part user-to-user - they'd like to be able to wiretap your ISP.
IPSEC is a better choice
on
Snooping on VOIP
·
· Score: 2, Insightful
SSH is too far up the protocol stack - if you're going to wrap encryption around an unencrypted VOIP stack, IPSEC is the right layer to work at. There's still a bit of weirdness there (Cisco's cRTP Compressed RTP implementation doesn't work over IPSEC, unless they've updated it recently, so you need to use uncompressed headers, which inflates packets sizes a lot), but it's better than doing Layer 4/5 solutions.
The right choice is to build the encryption into the VOIP protocols themselves, which the initial H.323 and (I think) SIP standards didn't do. That way, it's not something that might or might not get patched on later, it's secure by default. The amount of CPU overhead is trivial - RC4 is blazingly fast, but even if you're using Triple-DES, it's on data you've compressed down to 8-16kbps, and the voice compression takes a lot more horsepower than encryption. I think some of the later standards have some crypto, but I don't know if they're in use.
Of course, crypto only covers the VOIP part - if you're using a VOIP-to-telco gateway in either direction, the telco side is unencrypted and subject to CALEA regulations, which are as technically onerous as they are invasive.
Declan's story points to the Executive Order itself, and it only applies to information about the Federally owned parts of the infrastructure and things owned, built for, or under control of the Federal Government. The Internet doesn't fit into that, as much as ICANN might like. That fact re-does emphasize the importance of having critical infrastructure that's not owned by any single government or under the control of any single government - it's better off in the private sector, and distributed around the world. But if the Feds want to classify the details of the infrastructure of Milnet, fine, as long as they're not too mean to the next 14-year-old gamer kid from Seoul who cracks into it.
I can sympathize with the problem - I recently bought a ($14) sound card that claimed to have MS Windows drivers, and says "works with Windows XP" on the box. What it doesn't say is "rather broken with Windows ME, but that's in fact true:-) Stuff is much more likely to have drivers that worked under previous versions of Windows but haven't been ported to XP, but it happens both ways.
And my 802.11b card, which worked fine under Win98, would probably also work fine in Windows 2000, except the office laptops run in "You're Not The Administrator mode, so if I get the admin to let me plug it into the machine, it'll stop again if I pop the card out and later pop it in again. (Sigh....)
So they're patenting a technique that makes CPUs Not Go Fast. The usual anti-patent arguments are that patents stifle innovation by preventing people from doing things, which in this case means that they're preventing their competition from making their chips Not Go Faster. While, ok, there may be good reasons that somebody would want to do this, it doesn't bother me anywhere near as much as much as doing something to prevent their competition from using techniques that do make their chips Go Faster.:-)
On the other hand, it's a somewhat narrow patent - it doesn't prevent their competition from making chips that Go Slower, or Go Faster, or using other techniques to Not Go Faster. So it's not a total non-loss:-) Now, as far as how obvious it is or how overbroad the claims are, I'm not a chip designer, so I'll shut up now....
Has anybody who's succeeded in downloading this thing set it up for BitTorrent, the P2P thing that's designed for applications like this? (Also, did anybody do this for the recent Knoppix? I saw one for version N-2 or whatever.) It's really the right choice for flash-crowd release slashdottings (and Mandrake and RedHat etc. ought to go hire Bram to help them:-)
If you're not familiar with BitTorrent, it takes a large file (typically CD-size) chunks it up into ~1MB pieces, and client/peers who want the file either get chunks from the server or get pointed to other clients who already have them, and after receiving chunks correctly, make them available for other client/peers to download. The server keeps track of who's got what, manages its outgoing rates to something it can handle, and does some optimization to make sure all the chunks are getting handed out widely and efficiently, and either the client or server (I don't remember which, probably the server) does some anti-leech scheduling so that clients basically end up receiving at about the rate they're letting other people download from them if there's demand.
One big difference between BitTorrent and the eDonkey/Kazaa/etc. P2P systems is that it's designed on a per-file basis - anybody who wants to export a given file can be a server for that file, and the client/peer process only exports files that it's actively connected to (either still downloading or being friendly and letting other people download after it's done), rather than exporting everything in your file-sharing directory.
Slashdot Mirror
Put the CDROM in the slot, boot the machine, and nobody gets hurt. ARRRRRRRR!!
On the other hand, legacy ports have the advantage that the drivers usually work, and the hardware is either documented or old enough that it's been reverse-engineered if anybody cared about it. USB is another opportunity for manufacturers to put out documentation that says "Here's what you tell Microsoft Word to use this scanner" "Here's how you set Photoshop to use your camera" instead if "here's the set of messages the box sends" or "It's TCP/IP, it's port 31337, have a good time".
The Print This Article URL has the article as one long clean simple relatively standard relatively undecorated web page. It's the one you want.
Paul Kocher is one of the well-known experts in the practical crypto field. As you can see from his web site, he's done some innovative mean nasty approaches to cracking cryptosystems (mathematical proofs are a fine thing, but if you can figure out the state of the CPU by measuring its response time or detecting the power consumption, your system isn't as secure as you thought :-)
... Nova...
The station doesn't need an engineer to copy every copy-protected CD, just to set up the equipment. Trained monkeys _can_ handle the job of popping the CD into the "Broken CD Ripper Drive" and clicking on the "RIP Broken CDs" software. And for bigger networks, they'll have somebody back at headquarters who can do that, and either ship out the MP3s on line or else copy the tracks they want onto MP3-CDs or regular CDs.
While it's possible that the boss's "didn't understand" meant that he was a Luddite who was scared of anything that sounded complicated, it's much more likely that "didn't understand" included not knowing exactly what the undocumented copy protection software was going to do to his machines, or what software designed to prevent you from doing things would prevent him from doing, or whether it would mess up the software that he's using to handle music beyond what a basic MP3 player would do, given that copy-protection applications are _designed_ to mess up software like that. Or it could mean that he didn't understand what, if any, legal remedies he'd have if the copy-protection software messed up his station software, but since it was probably a cross-jurisdictional thing, he didn't expect to have much remedy.
Shorten is a lossless audio compression system that typically gets about 2:1 compression. It's used a lot by the etree jam band music trading community, which tends to start with audience recordings and doesn't want to degrade them further (unlike the old days on Nth-generation analog tape copies :-) That obviously takes a lot more space than small MP3s, but it still lets you fit twice as much music on a disk drive. So that 120GB disk drive that cost $120 at Fry's can now hold 240 CDs (Hmmm... I think the CD jukeboxes I saw could hold about 200 CDs for about $200. I remember when the computer WORM drive jukeboxes were more like $100K for that kind of capacity :-)
In practice, as long as you use decent quality equipment, this does sound like a practical way to run a radio station. If the DJs are in control or the music, it lets them find and queue up material quickly, and arrange it so they can easily go from one tune to the next or cut in to talk or patch in commercials, and makes it easier for things to run on autopilot if they need it to. And with the changes in disk drive cost over the last few years, they can store a few thousand songs at decent compression levels. On the other hand, if the radio station is one of those centrally controlled things that don't have real DJs at each station, they can upload each song once and cue things remotely.
Wow! A hat trick!
And apparently this is only the evil beginning....
Hi. This is my usual rant about Slashdot articles announcing that Some-Random-Name has reached Version N+1 or added Some-Generic-Feature-Like-Themes without saying what the product actually is or does. (Of course, people who don't know Enlightenment's version history won't get the April Fools' Joke here...)
There was a while that my work PC had this as its Windows Wallpaper icon - "Hey, what am I doing on this piece of Intel hardware? :-(".
I work for a big ISP that sells several kinds of VPN services, as well as selling routers to users who want to manage the routers themselves. I'd rather not see our Michigan sales reps risk being hauled into jail
- because that Cisco we installed on their premises can do NAT, or
- because that firewall conceals their machines from crackers, or
- because their VPN box conceals data from eavesdroppers, or
- because their SSL conceals web-visitors' credit card numbers from thieves, or
- because their email system conceals real email addresses from spammers.
And I'd rather not see our sales people out of work either. But until somebody gets a temporary restraining order on enforcement, it's a real problem.That's why you'll see clumsy UDRP mechanisms that work much better for big corporations than for individuals. It's also why whois records are inherently concerned with privacy invasion (making sure to get your True Name and True Address so subpoenas work, and that everybody who manages any part of the domain registration process has to collect that rather than setting their own local policies) but don't require whois records to have actual email addresses that get to actual people who respond to fix things.
Now, some of the problems can be attributed to incompetence rather than malice, and some of them can be attributed to wise conservatism rather than indecision, and reorganization might affect both. Deploying additional TLDs has always been a very visible thing that lots of people wanted ICANN to do, but once they're deployed, they're deployed, and undoing stupid deployments is much harder than delaying. And sure, they probably couldn't have predicted the dot-com crash which radically affected the market value of domain names. But deploying more TLDs is more interesting to people who want to do new and interesting businesses than to major trademark owners who don't want to have to hassle with pre-protecting example.newTLD when they already own example.com, especially when Example Semiconductors has as good a claim to example.newTLD as the Example Soft Drinks Company which owns example.com.
Nah, probably someone would try to ban that...
.... always wondered how those things worked....
Removable disk mounts like that are critical for backups and upgrades. In addition to the "easily install/run other operating systems" that somebody else wrote about, the rapid drop in disk drive costs and increase in sizes over the last couple of years have made extra hard disks one of the most cost-effective backup media available, and they're pretty much the only thing that won't go obsolete or incompatible quickly, unlike many of the writable DVD formats, which seem to be the only near competition.
What, were they thinking???
The answer, of course, is "no!"
Another problem is non-telco VOIP carriers. The regulations are pretty clear for regulated telcos - they're much less clear for people who aren't. For instance, if the PBX at your office acts as a gateway for all your coworkers who have VOIP hardware phones or software phones on their PCs, and DSL at home with VPNs to the office - CALEA lets the telco wiretap your company's phone system at the telco trunk, but they don't know that extension 1234 is your coworker "Bob" who's also selling ganja on the side. And as VOIP carriers become less legacy-telco dependent, what about calls that only use the carrier as a presence server (e.g. ICQ or equivalent) to set up the connections and do the actual VOIP part user-to-user - they'd like to be able to wiretap your ISP.
The right choice is to build the encryption into the VOIP protocols themselves, which the initial H.323 and (I think) SIP standards didn't do. That way, it's not something that might or might not get patched on later, it's secure by default. The amount of CPU overhead is trivial - RC4 is blazingly fast, but even if you're using Triple-DES, it's on data you've compressed down to 8-16kbps, and the voice compression takes a lot more horsepower than encryption. I think some of the later standards have some crypto, but I don't know if they're in use.
Of course, crypto only covers the VOIP part - if you're using a VOIP-to-telco gateway in either direction, the telco side is unencrypted and subject to CALEA regulations, which are as technically onerous as they are invasive.
Declan's story points to the Executive Order itself, and it only applies to information about the Federally owned parts of the infrastructure and things owned, built for, or under control of the Federal Government. The Internet doesn't fit into that, as much as ICANN might like. That fact re-does emphasize the importance of having critical infrastructure that's not owned by any single government or under the control of any single government - it's better off in the private sector, and distributed around the world. But if the Feds want to classify the details of the infrastructure of Milnet, fine, as long as they're not too mean to the next 14-year-old gamer kid from Seoul who cracks into it.
And my 802.11b card, which worked fine under Win98, would probably also work fine in Windows 2000, except the office laptops run in "You're Not The Administrator mode, so if I get the admin to let me plug it into the machine, it'll stop again if I pop the card out and later pop it in again. (Sigh....)
On the other hand, it's a somewhat narrow patent - it doesn't prevent their competition from making chips that Go Slower, or Go Faster, or using other techniques to Not Go Faster. So it's not a total non-loss :-) Now, as far as how obvious it is or how overbroad the claims are, I'm not a chip designer, so I'll shut up now....
If you're not familiar with BitTorrent, it takes a large file (typically CD-size) chunks it up into ~1MB pieces, and client/peers who want the file either get chunks from the server or get pointed to other clients who already have them, and after receiving chunks correctly, make them available for other client/peers to download. The server keeps track of who's got what, manages its outgoing rates to something it can handle, and does some optimization to make sure all the chunks are getting handed out widely and efficiently, and either the client or server (I don't remember which, probably the server) does some anti-leech scheduling so that clients basically end up receiving at about the rate they're letting other people download from them if there's demand.
One big difference between BitTorrent and the eDonkey/Kazaa/etc. P2P systems is that it's designed on a per-file basis - anybody who wants to export a given file can be a server for that file, and the client/peer process only exports files that it's actively connected to (either still downloading or being friendly and letting other people download after it's done), rather than exporting everything in your file-sharing directory.