You know, if they had come out and openly admitted this, I could actually have respected them. Well, almost; they have certainly made a lot of money over the years selling road-hogging, polluting, gas-guzzling SUVs at healthy markups, so I don't think they would have gone broke meeting CARB's modest ZEV mandate. And mass production has a way of driving incremental costs way down.
No, it was their bald-faced lie that "nobody wanted EVs" that really got to me. Even the CARB commissioners had to laugh when GM said this with a straight face at public hearings with hundreds of EV supporters in the audience.
GM has shown that the "Big Lie" still works. Never mind that what you say can be easily and conclusively disproven with facts and logic. As long as you keep saying it over and over, with studied conviction, enough people will believe you to tilt the scales in your favor. But you must be consistent. Under no circumstances can you ever concede even the most obvious point of your opposition.
From 1998 until 2003 I was the very satisfied driver of two GM EV1s: a 1997 lead-acid model and then a 1999 NiMH model. I lost my first car in the 2000 recall, and the second when my lease ended in August 2003. When I turned my car back in, I felt as though I had just euthanized a young and perfectly healthy family pet at the vet.
I've never had a car that was as much fun to drive as the EV1. They were outstanding vehicles, with excellent handling and performance. Everyone who ever rode in my car got out with a broad smile. The EV1 handily demolished the myth of the electric car as slow and impractical. Its 100-125 mile range was more than enough for my needs. I never had to go to a gas station except occasionally to top off the tires.
I even believed, for a time, that GM wanted the EV1 to succeed. But it became increasingly obvious that, despite the slick brochures and the marketing propaganda, their hearts were never in it. They'd been under pressure for years to put EVs on the road, so the EV1 became their cynical "Final Solution" to that annoying California EV mandate.
GM was taken aback by the strong response to this vehicle. They had expected and planned for a flop. They only made a few hundred in each model year, claiming that they could always make more if demand warranted. But even after the existing EV1s quickly sold out and long waiting lists formed, no more EV1s were forthcoming. Instead, they repeatedly told the California Air Resources Board (CARB), with straight faces, that there was simply no public demand for electric vehicles. Each time they said this, they were greeted with laughter and guffaws by the hundreds of EV1 enthusiasts who drove to Sacramento just for the hearings.
But GM still won. Dangling the far-off promise of fuel cells as bait, they quickly closed down the EV1 program and took cars away from hundreds of satisfied customers who would have gladly bought them. Have you noticed that we haven't heard much about fuel cells lately? That's because, as far as GM and the other automakers were concerned, fuel cells have already served their purpose -- getting rid of the ZEV mandate.
GM's action in pulling the EV1 off the market is utterly inexcusable.
I will never again buy or lease a GM vehicle. This isn't much of a sacrifice on my part, as no other GM car has ever excited me very much.
Normally, two-factor authentication would increase security. But that assumes you can trust the environment in which it runs. And that's just not the case with any Microsoft operating system.
Adding two-factor authentication to Windows would be like using a Medeco lock on a bike chain made of overcooked spaghetti.
Having had my fill of Fry's "rebates", with all the little deadlines and requirements for original UPC codes, etc, hidden in the fine print, I'd love to see them just go away. You know that most rebates must never be claimed; the cost just to process each rebate claim probably rivals the face value of the rebate.
I've stopped buying much stuff at Fry's anyway. Nowadays if I need something generic like a hard drive and I can wait a day, I'll usually just order it online from Newegg or some other nearby e-tailer for the same or an even lower price as Fry's, and there's no paperwork hassle.
Back in the 1980s, I published a paper at the ARRL Computer Network Conference on a "Collision-free Network" that used separate radio channels in a mesh network. Each node had its own assigned frequency to which its neighbors listened, and since no one else (within range) transmitted on each frequency, collisions couldn't occur. It also meant that each node could operate in full duplex. I actually built such a node near my house, and it worked pretty well. Of course, we were hobbled by the slow radios of the day.
I mention this just in case these guys have tried to patent my old idea. Wouldn't be the first time some company has tried to claim sole credit for something done a decade or two earlier by radio hams.
Yes, those environment variables would be a very nice feature. It wouldn't work in the non-cooperative case as you point out, but it would work very well in the home environment.
Thanks for your suggestions about raising everything but P2P and leaving P2P at the "best effort" level. When I think about it, I realize that my own traffic falls into only a few easily-identified categories (dns, web, ssh, ftp, smtp), so they'd be easy to recognize and mark. I'll give it a try!
Re:Has anyone managed to short SCO stock?
on
SCO On the Rocks
·
· Score: 1
To track the short ratio, follow this page: http://finance.yahoo.com/q/ks?s=SCOXE
Looks like the short ratio is either 34% or 43.86% as of January 10, depending on how you count shares.
Doesn't tcpmux itself run on a well-known port? Otherwise, how would you find it? If so, then the ISP could simply block the tcpmux port, and you're right back where you started -- unable to move mail or whatever off the well-known port number.
I do like the DNS idea if only because it would be somewhat harder for the ISP to censor that information. But since they generally run the DNS resolvers that you use, they could still filter any new records you propose along these lines. And if you try to run your own DNS resolver, they'd just block or transparently proxy UDP port 53, as some already do...
The only truly effective way to block ISP censorship on the basis of packet content is to encrypt that content so your ISP can't read it. Then, to stop them from blocking encrypted traffic, you'll have to look just like an encrypted service that's already so widespread that no ISP in their right mind would dare block it. I can think of only one candidate: SSL-encrypted HTTP over TCP port 443. We all know that the only legitimate use of the Internet (according to the corporations) is to buy lots of stuff with our credit cards, so would you want to be the ISP that brings down the wrath of Amazon or eBay or Yahoo for restraint of trade?
But then they'll just compile a list of "authorized" SSL-speaking hosts, and block access to all others. I think we're hosed.
Question for the VoIP network engineer/planner: are there any "standard" DSCP values for VoIP (high priority) or for peer-to-peer (lower than default priority) traffic? I set up a Linux QoS router on my DSL modem, and it works well with heuristic classification, but I'd like to try making use of Differentiated Services to do a more reliable job of marking packets at the source so they'll go into the right traffic classes. Relying on port numbers doesn't always work, because people often use nonstandard port numbers for P2P applications.
The documents I've seen on Differentiated Services don't seem to give any standard values for real-world use, other than 0 meaning "default priority". Maybe they aren't needed since DS is usually set and interpreted inside the same administrative domain, but if there are any de-facto standards I'd rather use them.
That's also been my experience: your own uplink is the only bottleneck worth worrying about, and that's a point you can control.
I have fast Speakeasy ADSL service: 768 up, 6000 down. I also have their VoIP service, resold from Level3. But my DSL uplink is still slow enough and the buffer in the DSL modem big enough that VoIP packets in the outbound direction will be delayed for over 3 seconds if they have to fight in an ordinary FIFO queue with traffic from my computers. Running Bit Torrent made my VoIP phone unusable, and interactive sessions very painful.
While the Bit Torrent applications have rate limiting, and the VoIP terminal adapter has an internal prioritizer, I wanted a more general and elegant solution. I especially wanted more than two priority levels so I could run Bit Torrent without affecting my interactive network use, which in turn would not affect VoIP.
I brought up Linux on a Soekris Engineering net4801 box and configured it as a dedicated router with QoS. There are four hierarchical token bucket classes, with the aggregate rate to the DSL modem shaped so that no more than 1 packet would ever be queued in the DSL modem. Each class uses stochastic fair queuing to ensure that one connection cannot dominate the whole class; the connections have to take turns.
Packets from the VoIP adapter go into the top priority class, followed by two intermediate priority classes for routine traffic, and that in turn is followed by a low priority class for Bit Torrent traffic.
The hard part was in finding all the right tuning numbers. I found that by limiting my aggregate outbound traffic to 626 kb/s, I avoided queue growth in the DSL modem. (My link is nominally 768 kb/s, but the modem won't necessarily train to full rate, and you also have to deduct the 5/53 = 9.4% ATM "tax".) Since Speakeasy's VoIP service uses uncompressed 64kb u-law PCM in 172 byte packets, I guaranteed 88 kb/s to VoIP. This can be "borrowed back" by the lower priority classes when VoIP is inactive so it doesn't go to waste.
Bit Torrent gets a guarantee of only 10 kb/s, so if I have anything else that needs the whole link, it will drop way back without actually halting.
When I did all this, I found to my satisfaction that there's basically nothing I could do to upset VoIP calls. They always got first priority on the DSL uplink, and queues never build there -- they're pushed back to the router. SSH sessions are nice and fast even with multiple uploads in progress.
Naturally, I can't do anything to affect how my downstream packets are queued, as that's the job of Speakeasy's router. But I figure they must give priority to VoIP packets, as I've never noticed any voice latency even when I try to saturate the downlink with data. In any event, that link is so much faster than my uplink that it rarely saturates.
So basically, with a well-tuned QoS router on just your DSL modem, you can get excellent VoIP quality without having to manually stop or restrict your computer file transfers. It really does work!
I do have one unsolved problem. Currently, I identify and mark Bit Torrent traffic by its use of one of the "standard" TCP ports starting at 6881. But many Bit Torrent users use non-standard ports, presumably to evade filters, and I flag their traffic as normal computer traffic. This doesn't bother VoIP, since VoIP always gets top priority, but it isn't given the low priority that I'd prefer. My Bit Torrent client, Azureus, recently added a feature to allow setting a Differentiated Services Code Point in the IP header that I could use as a flag, but the Java network stack on which it runs doesn't seem to implement application-specified DSCP settings. Anyone have a solution for this?
Maybe it was fake, maybe it was real. After an offline conversation, which you haven't seen, I think it was more likely real than not.
But let's say it wasn't. Why in hell should that bother me? Are you really saying that it's better to let someone die than to take the horrible risk of possibly being thought a fool by someone whose opinion I couldn't care less about? If so, I think you should take some time to carefully re-examine your values about what's important in life.
Last fall I lost a high school friend to a heart attack at age 50. His father had also died young, and my friend had already had a prior heart attack and was grossly overweight. Despite these risk factors and several hours of clear warning signs in the presence of friends who repeatedly offered help, he turned them down, went home and died. I've heard similar stories from a paramedic friend who had seen her share of people in clear cardiac distress denying that they had any problem at all -- most of whom later died. So I'm well aware of how important it can be to light a fire under someone who thinks they might be having a heart attack, and I don't see any reason to feel otherwise.
The obvious answer: because they can cram in far more channels with digital than with analog, and thereby sell more commercial time.
It's amazing how many digital music services still use the line "CD-quality" to describe their programs when the original CD data has been heavily compressed. It may (or may not) sound reasonably good, but by definition it is not "CD quality".
The content cartel has no trouble spooking Congress with this "CD-quality" line when they wring their hands about peer-to-peer filesharing, even though the vast majority of music and movie files on P2P are very heavily compressed. Even the legal, for-pay services like iTunes and eMusic compress heavily. (There are a few notable exceptions, such as Magnatune, which make FLAC files available for download.)
The content cartel even managed a few years back to convince Congress to add "digital transmission" to the list of rights reserved to the copyright holder, over and above those that apply to ordinary analog broadcasting. This has resulted in substantially higher royalty rates for digital music broadcasters. Perhaps somebody should point this out to any Congressmen still wondering why digital broadcasting hasn't taken off yet.
See a doc now. Please don't wait. Chest pain/squeezing, shortness of breath, sweating, and pain that radiates down your left arm are classic signs of a heart attack.
Even if it's something else, you'll be relieved to find that out.
The question comes to mind, why doesn't Ethernet adopt some for of compression?
Ahem. I take it you've already upgraded everything to gigabit Ethernet, and that's still not fast enough for you?
Even the oldest, slowest form of ethernet is orders of magnitude faster than dialup, and a lot of people don't even bother to use the fastest version. There's just no point to adding compression as that would provide, at best, another 2-4x on text. And none at all on much of the bulk data that people commonly send, such as images, sound files and tarballs, because they're already compressed at the application layer.
Also, a good compression algorithm would necessarily increase latency, and that's usually totally unacceptable on a LAN. Otherwise, why ever have LAN parties?
Communication links have an amazing range of speeds and costs. Compression is wholly appropriate for those in the low speed, high cost region relative to the CPUs that can do the compression. That leaves out local links. In the local area, wires have gotten so fast that compression just makes no sense.
You're only about 137 years out of date. Read the 14th Amendment, passed in 1868 as one of the three "reconstruction amendments" after the US Civil War.
Read also how the Supreme Court applies the 14th Amendment to "incorporate" the protections of the Bill of Rights against the states as well as the federal government. Since the 14th amendment, it has been no more legal for a state to sponsor or promote religion than for the federal government.
A particularly readable book on the Bill of Rights and its interpretation is In Our Defense by Ellen Alderman and Caroline Kennedy.
Check out magnatune. They're small, but they've got some interesting music and just the business model you're looking for.
I only discovered them recently, but I've already given them much more business than I'll ever give iTunes.
I can get as many old versions of a file as I have offline drives in my backup rotation cycle.
I didn't say this was the only backup system you'll ever need. But it's a nice solution to the problem of making complete images that I can boot from if an online drive fails or the system it's in catches fire. It's certainly easier and faster than full tape backups.
If you really want to save each and every version of a file as it rapidly changes, use RCS, CVS or some other versioning system and back that up frequently with RAID mirror swaps.
I use a much simpler and easier method to back up my primary Linux server: software RAID-1. Every month or so, I shut down, pull the secondary drive in the array, put it in the safe, and replace it with either an old drive or a new drive bought at the store. Then I reboot and let the mirror rebuild onto the new drive.
Because RAID-1 is an exact mirror, I get a complete, bootable backup copy of my system at the time of the shutdown. Downtime is limited to the few minutes it takes to shut down and swap drives. The lengthy process of mirror rebuilding takes place while the system runs normally. And of course, RAID also protects me against random (single) hard drive failures.
This solves the full image backup problem, leaving only the more frequent partial backups you should also be doing. For this, rsync is your friend. The stuff that changes most often on my system are my IMAP folders, which I periodically (several times per day) rsync to my laptop. Besides backing up my mail server, this gives me copies I can carry around and read when I'm offline.
Tape is obsolete. It's just too slow, expensive, unreliable and small. Hard drives are so cheap, fast and capacious that there's little excuse to not run RAID on any machine that can physically hold more than one hard drive. Unfortunately, this leaves out most laptops.
It's now easier than ever before to routinely encrypt the bulk of your own IP traffic. These steps can make passive eavesdropping of your broadband connection a lot less interesting:
Select the SSL/TLS options on your SMTP, IMAP and POP sessions to your mailserver. Mozilla/Thunderbird has full support for SSL/TLS, and I think most other modern email clients do as well.
If your mailservers don't support SSL/TLS, ask the admins to enable it. If they refuse, switch to ISPs that do. (Speakeasy supports SSL/TLS for IMAP and SMTP.)
Run your own personal SMTP server and enable the STARTTLS option. Most SMTP senders -- even many spammers! -- will automatically invoke the STARTTLS option if the server advertises it. This finally turns spam into something useful -- a constant background stream of encrypted fill traffic from all over the planet. What better way to thwart traffic analysis?
Configure your own webservers to support https. Make it available for all your webpages, not just the "sensitive" ones.
Use SSH for all remote login/file transfer between machines on which you have accounts.
Web surf over a SSH tunnel into a shared proxy cache with logging turned off.
Set up IPSEC in opportunistic mode.
If you have a flat-rate broadband connection, run background scripts to ship big random files to your friends with various P2P applications. Set up a traffic-shaping router and configure it to give low priority to P2P traffic so it won't bother your foreground activities.
Sure, it would be a lot better if you could convince everybody you exchange email with to encrypt everything on an end-to-end basis with S/MIME or GPG/PGP, but this stuff is quite doable and it's a lot better than just giving up on your privacy and security.
I think the two cases are much more similar than you think. While the infringing uses of P2P networks get all the press (and Congressional) attention, these networks and software packages also have many perfectly legitimate and socially beneficial uses -- just like VCRs. IMHO it's vital to protect those legitimate uses even if some copyright infringement also results, just as the Bill of Rights protects the innocent at the cost of letting some of the guilty go free.
Bit Torrent, in particular, is about the only practical way many individuals can distribute their own large works, such as home made movies, to the public at large. Not everyone has the money to establish a web site and pay the associated bandwidth bills. If the creators of P2P software like Bit Torrent were held liable for everything anyone might do with it, freedom of the press would again belong only to those rich enough to own an (expensive) printing press, and to hire the lawyers necessary to defend it.
I hope that in the RIAA/MPAA-stoked hysteria over copyright infringement, the Supreme Court realizes that there are some major First Amendment issues at stake here.
In fact, I can't think of a good definition for "peer to peer network" that clearly distinguishes it from, say, a set of personal FTP servers. The Internet is intentionally designed as a "peer to peer network", and it has been operating as one long before that term came into popular use to describe certain Internet applications that happen to be widely used for copyright infringement.
So I think it not too extreme to conclude that a holding for the RIAA and MPAA in this case could mean the end of the entire Internet as we know it, not just the end of Kazaa, Morpheus and other so-called "peer-to-peer" applications.
Not that they'd mind the death of the Internet, of course. It's been siphoning away "their" customers for a long time. Without the Internet, we'd all have to go back to broadcast television and the movie theaters out of sheer boredom. Perhaps that's their real goal here...
I have a web page with information on how to get the Sierra Wireless 5220 PC card working with Linux. The 5220 is, at present, the only supported device on Verizon's WirelessBroadband service (their name for CDMA 1xEV-DO).
Yeah, I can see how this could be a problem. I run into it sometimes at work when I have both 6to4 and a 6bone address. It seems that if both ends have a 6to4 address starting with 2002::/16, that should probably be preferred, but I wouldn't want to hard-wire a rule like that.
IPv6 has the advantage that it pushes some of the route selection back to the application where the user can control it. IPv6 also has the disadvantage that it pushes some of the route selection back to the application where the user must control it.:-)
Homeopathic "medicine" is provably worthless. See this site for the details. If your friend thinks she's doing better, it's because of a) the placebo effect, b) the other therapies she's getting.
Even opioids are rarely addictive when properly used for pain management under the supervision of a doctor. Do not mistake physical dependence (a routine, expected and manageable occurrence with long-term opioid use) for "addiction", by definition a harmful psychological disorder. Countless people suffer needlessly from chronic pain because of unfounded fears of addiction. Opioids are actually much less toxic than many over-the-counter pain drugs, especially acetaminophen (Tylenol).
If you do control your NAT box, a much better alternative to running Teredo through it is to install a 6to4 gateway on the same box as the NAT. This is trivial if the NAT box is running Linux. IPv4 users on your home LAN still see a NAT, but anything that supports IPv6 can get transparent, end-to-end connectivity.
I would really like to see a 6to4 gateway function become a standard vendor feature on popular mass-market routers like the Linksys WRT54G. Since most DSL and cable modem ISPs still give their customers a (single) globally routable IPv4 address, this could go a long way toward eliminating UPnP, manual port-forwarding hacks and other brain-dead NAT workarounds.
Slashdot Mirror
No, it was their bald-faced lie that "nobody wanted EVs" that really got to me. Even the CARB commissioners had to laugh when GM said this with a straight face at public hearings with hundreds of EV supporters in the audience.
GM has shown that the "Big Lie" still works. Never mind that what you say can be easily and conclusively disproven with facts and logic. As long as you keep saying it over and over, with studied conviction, enough people will believe you to tilt the scales in your favor. But you must be consistent. Under no circumstances can you ever concede even the most obvious point of your opposition.
I've never had a car that was as much fun to drive as the EV1. They were outstanding vehicles, with excellent handling and performance. Everyone who ever rode in my car got out with a broad smile. The EV1 handily demolished the myth of the electric car as slow and impractical. Its 100-125 mile range was more than enough for my needs. I never had to go to a gas station except occasionally to top off the tires.
I even believed, for a time, that GM wanted the EV1 to succeed. But it became increasingly obvious that, despite the slick brochures and the marketing propaganda, their hearts were never in it. They'd been under pressure for years to put EVs on the road, so the EV1 became their cynical "Final Solution" to that annoying California EV mandate.
GM was taken aback by the strong response to this vehicle. They had expected and planned for a flop. They only made a few hundred in each model year, claiming that they could always make more if demand warranted. But even after the existing EV1s quickly sold out and long waiting lists formed, no more EV1s were forthcoming. Instead, they repeatedly told the California Air Resources Board (CARB), with straight faces, that there was simply no public demand for electric vehicles. Each time they said this, they were greeted with laughter and guffaws by the hundreds of EV1 enthusiasts who drove to Sacramento just for the hearings.
But GM still won. Dangling the far-off promise of fuel cells as bait, they quickly closed down the EV1 program and took cars away from hundreds of satisfied customers who would have gladly bought them. Have you noticed that we haven't heard much about fuel cells lately? That's because, as far as GM and the other automakers were concerned, fuel cells have already served their purpose -- getting rid of the ZEV mandate.
GM's action in pulling the EV1 off the market is utterly inexcusable. I will never again buy or lease a GM vehicle. This isn't much of a sacrifice on my part, as no other GM car has ever excited me very much.
Adding two-factor authentication to Windows would be like using a Medeco lock on a bike chain made of overcooked spaghetti.
I've stopped buying much stuff at Fry's anyway. Nowadays if I need something generic like a hard drive and I can wait a day, I'll usually just order it online from Newegg or some other nearby e-tailer for the same or an even lower price as Fry's, and there's no paperwork hassle.
I mention this just in case these guys have tried to patent my old idea. Wouldn't be the first time some company has tried to claim sole credit for something done a decade or two earlier by radio hams.
Thanks for your suggestions about raising everything but P2P and leaving P2P at the "best effort" level. When I think about it, I realize that my own traffic falls into only a few easily-identified categories (dns, web, ssh, ftp, smtp), so they'd be easy to recognize and mark. I'll give it a try!
Looks like the short ratio is either 34% or 43.86% as of January 10, depending on how you count shares.
I do like the DNS idea if only because it would be somewhat harder for the ISP to censor that information. But since they generally run the DNS resolvers that you use, they could still filter any new records you propose along these lines. And if you try to run your own DNS resolver, they'd just block or transparently proxy UDP port 53, as some already do...
The only truly effective way to block ISP censorship on the basis of packet content is to encrypt that content so your ISP can't read it. Then, to stop them from blocking encrypted traffic, you'll have to look just like an encrypted service that's already so widespread that no ISP in their right mind would dare block it. I can think of only one candidate: SSL-encrypted HTTP over TCP port 443. We all know that the only legitimate use of the Internet (according to the corporations) is to buy lots of stuff with our credit cards, so would you want to be the ISP that brings down the wrath of Amazon or eBay or Yahoo for restraint of trade?
But then they'll just compile a list of "authorized" SSL-speaking hosts, and block access to all others. I think we're hosed.
The documents I've seen on Differentiated Services don't seem to give any standard values for real-world use, other than 0 meaning "default priority". Maybe they aren't needed since DS is usually set and interpreted inside the same administrative domain, but if there are any de-facto standards I'd rather use them.
I have fast Speakeasy ADSL service: 768 up, 6000 down. I also have their VoIP service, resold from Level3. But my DSL uplink is still slow enough and the buffer in the DSL modem big enough that VoIP packets in the outbound direction will be delayed for over 3 seconds if they have to fight in an ordinary FIFO queue with traffic from my computers. Running Bit Torrent made my VoIP phone unusable, and interactive sessions very painful.
While the Bit Torrent applications have rate limiting, and the VoIP terminal adapter has an internal prioritizer, I wanted a more general and elegant solution. I especially wanted more than two priority levels so I could run Bit Torrent without affecting my interactive network use, which in turn would not affect VoIP.
I brought up Linux on a Soekris Engineering net4801 box and configured it as a dedicated router with QoS. There are four hierarchical token bucket classes, with the aggregate rate to the DSL modem shaped so that no more than 1 packet would ever be queued in the DSL modem. Each class uses stochastic fair queuing to ensure that one connection cannot dominate the whole class; the connections have to take turns.
Packets from the VoIP adapter go into the top priority class, followed by two intermediate priority classes for routine traffic, and that in turn is followed by a low priority class for Bit Torrent traffic.
The hard part was in finding all the right tuning numbers. I found that by limiting my aggregate outbound traffic to 626 kb/s, I avoided queue growth in the DSL modem. (My link is nominally 768 kb/s, but the modem won't necessarily train to full rate, and you also have to deduct the 5/53 = 9.4% ATM "tax".) Since Speakeasy's VoIP service uses uncompressed 64kb u-law PCM in 172 byte packets, I guaranteed 88 kb/s to VoIP. This can be "borrowed back" by the lower priority classes when VoIP is inactive so it doesn't go to waste.
Bit Torrent gets a guarantee of only 10 kb/s, so if I have anything else that needs the whole link, it will drop way back without actually halting.
When I did all this, I found to my satisfaction that there's basically nothing I could do to upset VoIP calls. They always got first priority on the DSL uplink, and queues never build there -- they're pushed back to the router. SSH sessions are nice and fast even with multiple uploads in progress.
Naturally, I can't do anything to affect how my downstream packets are queued, as that's the job of Speakeasy's router. But I figure they must give priority to VoIP packets, as I've never noticed any voice latency even when I try to saturate the downlink with data. In any event, that link is so much faster than my uplink that it rarely saturates.
So basically, with a well-tuned QoS router on just your DSL modem, you can get excellent VoIP quality without having to manually stop or restrict your computer file transfers. It really does work!
I do have one unsolved problem. Currently, I identify and mark Bit Torrent traffic by its use of one of the "standard" TCP ports starting at 6881. But many Bit Torrent users use non-standard ports, presumably to evade filters, and I flag their traffic as normal computer traffic. This doesn't bother VoIP, since VoIP always gets top priority, but it isn't given the low priority that I'd prefer. My Bit Torrent client, Azureus, recently added a feature to allow setting a Differentiated Services Code Point in the IP header that I could use as a flag, but the Java network stack on which it runs doesn't seem to implement application-specified DSCP settings. Anyone have a solution for this?
But let's say it wasn't. Why in hell should that bother me? Are you really saying that it's better to let someone die than to take the horrible risk of possibly being thought a fool by someone whose opinion I couldn't care less about? If so, I think you should take some time to carefully re-examine your values about what's important in life.
Last fall I lost a high school friend to a heart attack at age 50. His father had also died young, and my friend had already had a prior heart attack and was grossly overweight. Despite these risk factors and several hours of clear warning signs in the presence of friends who repeatedly offered help, he turned them down, went home and died. I've heard similar stories from a paramedic friend who had seen her share of people in clear cardiac distress denying that they had any problem at all -- most of whom later died. So I'm well aware of how important it can be to light a fire under someone who thinks they might be having a heart attack, and I don't see any reason to feel otherwise.
Now go away.
It's amazing how many digital music services still use the line "CD-quality" to describe their programs when the original CD data has been heavily compressed. It may (or may not) sound reasonably good, but by definition it is not "CD quality".
The content cartel has no trouble spooking Congress with this "CD-quality" line when they wring their hands about peer-to-peer filesharing, even though the vast majority of music and movie files on P2P are very heavily compressed. Even the legal, for-pay services like iTunes and eMusic compress heavily. (There are a few notable exceptions, such as Magnatune, which make FLAC files available for download.)
The content cartel even managed a few years back to convince Congress to add "digital transmission" to the list of rights reserved to the copyright holder, over and above those that apply to ordinary analog broadcasting. This has resulted in substantially higher royalty rates for digital music broadcasters. Perhaps somebody should point this out to any Congressmen still wondering why digital broadcasting hasn't taken off yet.
Could be. But we took it offline and exchanged a few more messages that make me think it was more likely to have been real.
Even if it's something else, you'll be relieved to find that out.
Ahem. I take it you've already upgraded everything to gigabit Ethernet, and that's still not fast enough for you?
Even the oldest, slowest form of ethernet is orders of magnitude faster than dialup, and a lot of people don't even bother to use the fastest version. There's just no point to adding compression as that would provide, at best, another 2-4x on text. And none at all on much of the bulk data that people commonly send, such as images, sound files and tarballs, because they're already compressed at the application layer.
Also, a good compression algorithm would necessarily increase latency, and that's usually totally unacceptable on a LAN. Otherwise, why ever have LAN parties?
Communication links have an amazing range of speeds and costs. Compression is wholly appropriate for those in the low speed, high cost region relative to the CPUs that can do the compression. That leaves out local links. In the local area, wires have gotten so fast that compression just makes no sense.
Read also how the Supreme Court applies the 14th Amendment to "incorporate" the protections of the Bill of Rights against the states as well as the federal government. Since the 14th amendment, it has been no more legal for a state to sponsor or promote religion than for the federal government.
A particularly readable book on the Bill of Rights and its interpretation is In Our Defense by Ellen Alderman and Caroline Kennedy.
Check out magnatune. They're small, but they've got some interesting music and just the business model you're looking for. I only discovered them recently, but I've already given them much more business than I'll ever give iTunes.
I didn't say this was the only backup system you'll ever need. But it's a nice solution to the problem of making complete images that I can boot from if an online drive fails or the system it's in catches fire. It's certainly easier and faster than full tape backups.
If you really want to save each and every version of a file as it rapidly changes, use RCS, CVS or some other versioning system and back that up frequently with RAID mirror swaps.
Because RAID-1 is an exact mirror, I get a complete, bootable backup copy of my system at the time of the shutdown. Downtime is limited to the few minutes it takes to shut down and swap drives. The lengthy process of mirror rebuilding takes place while the system runs normally. And of course, RAID also protects me against random (single) hard drive failures.
This solves the full image backup problem, leaving only the more frequent partial backups you should also be doing. For this, rsync is your friend. The stuff that changes most often on my system are my IMAP folders, which I periodically (several times per day) rsync to my laptop. Besides backing up my mail server, this gives me copies I can carry around and read when I'm offline.
Tape is obsolete. It's just too slow, expensive, unreliable and small. Hard drives are so cheap, fast and capacious that there's little excuse to not run RAID on any machine that can physically hold more than one hard drive. Unfortunately, this leaves out most laptops.
Select the SSL/TLS options on your SMTP, IMAP and POP sessions to your mailserver. Mozilla/Thunderbird has full support for SSL/TLS, and I think most other modern email clients do as well.
If your mailservers don't support SSL/TLS, ask the admins to enable it. If they refuse, switch to ISPs that do. (Speakeasy supports SSL/TLS for IMAP and SMTP.)
Run your own personal SMTP server and enable the STARTTLS option. Most SMTP senders -- even many spammers! -- will automatically invoke the STARTTLS option if the server advertises it. This finally turns spam into something useful -- a constant background stream of encrypted fill traffic from all over the planet. What better way to thwart traffic analysis?
Configure your own webservers to support https. Make it available for all your webpages, not just the "sensitive" ones.
Use SSH for all remote login/file transfer between machines on which you have accounts.
Web surf over a SSH tunnel into a shared proxy cache with logging turned off.
Set up IPSEC in opportunistic mode.
If you have a flat-rate broadband connection, run background scripts to ship big random files to your friends with various P2P applications. Set up a traffic-shaping router and configure it to give low priority to P2P traffic so it won't bother your foreground activities.
Sure, it would be a lot better if you could convince everybody you exchange email with to encrypt everything on an end-to-end basis with S/MIME or GPG/PGP, but this stuff is quite doable and it's a lot better than just giving up on your privacy and security.
Bit Torrent, in particular, is about the only practical way many individuals can distribute their own large works, such as home made movies, to the public at large. Not everyone has the money to establish a web site and pay the associated bandwidth bills. If the creators of P2P software like Bit Torrent were held liable for everything anyone might do with it, freedom of the press would again belong only to those rich enough to own an (expensive) printing press, and to hire the lawyers necessary to defend it.
I hope that in the RIAA/MPAA-stoked hysteria over copyright infringement, the Supreme Court realizes that there are some major First Amendment issues at stake here.
In fact, I can't think of a good definition for "peer to peer network" that clearly distinguishes it from, say, a set of personal FTP servers. The Internet is intentionally designed as a "peer to peer network", and it has been operating as one long before that term came into popular use to describe certain Internet applications that happen to be widely used for copyright infringement.
So I think it not too extreme to conclude that a holding for the RIAA and MPAA in this case could mean the end of the entire Internet as we know it, not just the end of Kazaa, Morpheus and other so-called "peer-to-peer" applications.
Not that they'd mind the death of the Internet, of course. It's been siphoning away "their" customers for a long time. Without the Internet, we'd all have to go back to broadcast television and the movie theaters out of sheer boredom. Perhaps that's their real goal here...
I have a web page with information on how to get the Sierra Wireless 5220 PC card working with Linux. The 5220 is, at present, the only supported device on Verizon's WirelessBroadband service (their name for CDMA 1xEV-DO).
IPv6 has the advantage that it pushes some of the route selection back to the application where the user can control it. IPv6 also has the disadvantage that it pushes some of the route selection back to the application where the user must control it. :-)
Even opioids are rarely addictive when properly used for pain management under the supervision of a doctor. Do not mistake physical dependence (a routine, expected and manageable occurrence with long-term opioid use) for "addiction", by definition a harmful psychological disorder. Countless people suffer needlessly from chronic pain because of unfounded fears of addiction. Opioids are actually much less toxic than many over-the-counter pain drugs, especially acetaminophen (Tylenol).
I would really like to see a 6to4 gateway function become a standard vendor feature on popular mass-market routers like the Linksys WRT54G. Since most DSL and cable modem ISPs still give their customers a (single) globally routable IPv4 address, this could go a long way toward eliminating UPnP, manual port-forwarding hacks and other brain-dead NAT workarounds.