Yes, the work does need to be done. However, it doesn't have to be done by people. And it certainly doesn't need to be done by seriously over paying the bottom rung of society. You'll get very little arguement from package handlers in saying no one wants to be a handler -- the job truely sucks. If the person had any marketable skills, they'd be somewhere else.
You are willing to program for free because you find it fun. There aren't many people who find package handling sufficiently fun to do it for free.
Usually, pay is driven by things like skill, experience, hazard level, and demand. Unions fuck all that up -- people are paid what the union says they should be paid. And just to make things better, unions interfere with the normal course of hiring and firing people.
Me? Individually, my role in society is as insignificant as everyone else. If we awoke tomorrow with no package handler in society, then society would come to a halt in short order (this was proven not long ago.) However, the highly skilled portion of society would step up and, in a fashion to rival Junkyard Wars, replace the non-existant people with technology. (Images of the movie Brazil come to mind.) [This could already be done if there were no union to fight it.]
Now, if we awoke tomorrow with no computer professionals (system or network admins, engineers, programmers, etc.), society would be in trouble (read: doomed.) It'd take longer but modern society would still fall into ruins.
(Hollywood has had fun over the years presenting these what-if's to us as entertainment.)
It's still true. Some of them (union workers) make a great deal of money... like 60k to push freakin' boxes around! It's horrifying. They require no education, no training, and zero skill. In fact, I'd have to rate "package handler" as a less than zero skill job. They could all be replaced by robots if it weren't for the cries of the union.
I wouldn't be so quick to blame management. While they are still at fault, ultimately, the monkey moving the box is to blame for the damage. They drop packages (esp. heavy ones.) They throw packages (esp. those marked fragile.) And they even kick packages.
To make a sweeping generalization, the management doesn't care. And the monkeys simply don't give a damn.
And in fact, transfers between two SCSI devices can be done completely without assistance from the system CPU. I remember a Mac CD burner (long long ago) that burned CDs directly from a hard drive -- the data moved from hard drive to CD drive directly, the CPU was simply issuing SCSI commands.
(I don't think that's actually in the SCSI specs, but then it was all Apple hardware.)
Ok. At most, one can connect TWO IDE drives per chain. The fastest hard drives on the planet can only sustain just under 40MB/s directly off the platter. So, you can buy ATA-1million and it's not going to make much of a difference.
The problem is the fundamental structure of IDE... one command to one device and wait for an answer before you talk to anything else. Modern IDE isn't quite as bad, but it still sucks in a very major way. (Note: modern IDE drives, aka ATAPI, are SCSI drives. It's just transported across an IDE bus which makes it suck horribly.)
First, watermarks don't work. They are worse than worthless. The theory goes you're not supposed to be able to hear it. But for it to work and not be simple to remove, it has to make significant changes -- either insert "noise" blocks or scatter bit flips throughout the track. Noise is easy to find and remove (and audible.) An embeding carrier can be completely destroyed with simple format changes (mp3 encoding, resampling, etc.)
Of course, to place a "serial number" in all the audio sent to radio stations would require every station to get a completely different CD. How long would it take to burn one CD for each radio station in a given area? It's far too much hassle. Plus, there's a chance the watermark would survive FM transmission (which is perfectly legal to record.)
I've not done any tests lately, however, the way things were in the past (measured in years), the linux kernel sucked out loud without some swap. 1k or 100M, it didn't matter; simplying having swap available significantly changed the behavior of the system.
Surprisingly, the tivo, based on 2.1.24, performs better with swap disabled. However, that kernel is heavily modified and, well, ancient.
So? We'll obviously need more than one (of anything) won't we.
I'm just wondering why no one has suggested a few thousand modified TiVos! I'm sure whomever is doing this would have almost zero problem getting Philips or Sony and Tivo to create a special purpose system (it'd need something other than IDE for communication to an archival device.) They'd have to be replaced every three years (expected drive lifetime.)
Not to fan the SCSI vs. IDE fire... Anyone who actually cares that there data will be there when they get up in the morning has already chosen SCSI. It's expensive, but it's expensive for a reason.
Tape will always win in the battle for archival. They last much longer and cost far, far less in the long run. I invite people to do the math... 3TB of tape vs. 3TB of hard drive. (The break-even is arounf 5-6k$. Below ~3TB, drives win and vice versa.) Plus, I've never seen a hard drive auto-loader; tho' I'm sure you could trick the old exabyte loader into doing it with a bit of work.
The lifetime of a video tape depends on many factors -- not the least of which is the crappiness of the tape (which is refered to as quality:-)) The most important is the number of times it gets run through a VCR. No matter how well constucted, tuned, and aligned, all VCRs damage the tape during use. Playback/recording places the tape under tension that eventually stretches the tape beyond any hope of usefulness. I've found about 3 months of recording and playback at 6hrs/weeks (each) is about as long as they last.
Magnetic cohesion is next big problem. This is a problem for any magnetic media. If you recorded a tape, end to end, removed it from the VCR and sealed it in a plastic bag, it would physically last for hundreds of years. The magnetic charge would not last that long. Have you ever touched the north end of one magnet to the north end of another magnet? They really don't like being near each other. The video tape is just a bunch of really tiny magnetic stuck really close to each other.
I find it funny to see people worried about the oxide "flaking off"... they've obviously never tried to scratch it off.
There are scalability limits beyond 4 and 8 processors. Part of it is hardware and a lot of it is software. SGI/IRIX does both very well (hello, they make/made the CRAY!) The scheduler used for small SMP systems does not work well with large SMP systems. And PXE, the 36-bit address extensions, is a significant performance hit for machines not acutally requiring it.
Performance does not scale linearly -- on any system. "About 2x" is not "2x". IRIX scales better than most, but it still isn't perfect. And, surprise, Windows scales better than Linux (or used to.) BeOS is about the best thing I've seen for standard PC hardware -- too bad it never caught on.
Datacenter is a great deal different from the other windows'. Unlike the difference between NT Workstation and Server (two registry keys), Datacenter is very different.
The only WB and UPN local stations currently in the lineup are two NYC stations. As far as I can find, they are the only WB and UPN stations out of the 1000 channels available:-( There's a Radio Shack channel (among other private channels), five(?) national Fox feeds, and hundreds of sports channels, but they cannot find a single source for WB and UPN? Gez!
So far, Enterprise is the only thing I've not been able to find. WGN carries some stuff, albeit a week behind the antenna.
A "tv tuner card" is not an MPEG encoder. You will not integrate an MPEG encoder into either device for 25$. I doubt you could buy the Sony chip [cxd1922] (alone) for 25$.
The DirectTV units default to "grid" mode. The SA's will not allow you to display in "grid" mode (without hacking.) I saw a Sony commercial with a SA unit showing the guide in grid mode once -- I was very shocked.
If TiVo goes out of business, the tape will be pulled off a lot of mouths. There are no secrets inside there. Once there's no longer a threat of lawyers (or killing the company), a lot of previously guarded utilities will surface -- feeding them guide data is not hard at all.
So get a DirectTV unit. It requires almost zero interaction with TiVo to function. With a few minor modifications, it never needs to call tivo. Sure, you'll stop getting "TiVolution Magazine" and "Showcases", but how often does anyone use those?
Really? Maybe you should get your head out of your... never mind.
The system of "checks and balances" originally envisioned hasn't worked for many many years. People are too stupid and too greedy. The "system" failed for the DMCA. The "system" has had no effect on the recent anti-terrorism laws -- passing in HOURS. And it will fail with this bullshit as well.
This will be one more law people break with abandon. Of course, this one will be a lot harder to break with all the hardware manufacturers playing along.
Short of a cue, none of this is ever going to change.
Actually, most modern routers (at least those that an ISP would be expected to use) can handle packet filtering with exceptional efficiency even for very large filter lists -- some have hardware for dealing with it. At any rate, it's not really the traffic that's killing anything. Routers are designed to move unimaginable numbers of packets around. It's the whole thing of sending traffic to nonexistant addresses that tend to hurt routers. However, filtering at the edge wouldn't do a great deal of good as there are certainly hundreds of infected machines inside the fort. Blocking traffic at the CPE interface_s_ (thousands of them) is a nightmare I'm going to skip.
Shortly at 9am Tuesday, I started getting paged continuously about CPU loads being too high. After removing the battery from the pagers, I checked the graphs... the volume of broadcast traffic was 7x higher than normal. It's all ARP traffic from the routers looking for machines that don't exist. The actual number of packets and bits flowing around haven't changed much since 9/11.
ARP gets to be very expensive when there are hundreds or thousands of machines being probed (esp. when there are many multi-point interfaces.) Memory fragmentation, much higher memory utilization, extremely high CPU usage in keeping up with all the bookkeeping -- scanning the ARP cache, aging the ARP cache, pruning the ARP cache, creating/updating/deleting ARP timers, processing retransmissions... -- all adds up quickly. (Note: Cisco routers will crash if memory fragmentation gets too high and/or memory allocations fail repeatedly.)
BTW, LaBrea is proving to an interesting toy even if it is ill suited to a multispan network (dozens of networks on one cable.) Libnet and libpcap not working right (right, my netmask is 0x514) proved interesting.
Slashdot Mirror
Yes, the work does need to be done. However, it doesn't have to be done by people. And it certainly doesn't need to be done by seriously over paying the bottom rung of society. You'll get very little arguement from package handlers in saying no one wants to be a handler -- the job truely sucks. If the person had any marketable skills, they'd be somewhere else.
You are willing to program for free because you find it fun. There aren't many people who find package handling sufficiently fun to do it for free.
Usually, pay is driven by things like skill, experience, hazard level, and demand. Unions fuck all that up -- people are paid what the union says they should be paid. And just to make things better, unions interfere with the normal course of hiring and firing people.
Me? Individually, my role in society is as insignificant as everyone else. If we awoke tomorrow with no package handler in society, then society would come to a halt in short order (this was proven not long ago.) However, the highly skilled portion of society would step up and, in a fashion to rival Junkyard Wars, replace the non-existant people with technology. (Images of the movie Brazil come to mind.) [This could already be done if there were no union to fight it.]
Now, if we awoke tomorrow with no computer professionals (system or network admins, engineers, programmers, etc.), society would be in trouble (read: doomed.) It'd take longer but modern society would still fall into ruins.
(Hollywood has had fun over the years presenting these what-if's to us as entertainment.)
Java just makes people (read: idiots) who cannot program think they are programmers.
It's still true. Some of them (union workers) make a great deal of money... like 60k to push freakin' boxes around! It's horrifying. They require no education, no training, and zero skill. In fact, I'd have to rate "package handler" as a less than zero skill job. They could all be replaced by robots if it weren't for the cries of the union.
See Also: Nylon Threaded Tape
(Kevlar threaded tape would be too hard to open.)
The only way I could see that kind of damage inflicted on tupperware would be to hit it hard while significantly cold.
I wouldn't be so quick to blame management. While they are still at fault, ultimately, the monkey moving the box is to blame for the damage. They drop packages (esp. heavy ones.) They throw packages (esp. those marked fragile.) And they even kick packages.
To make a sweeping generalization, the management doesn't care. And the monkeys simply don't give a damn.
And in fact, transfers between two SCSI devices can be done completely without assistance from the system CPU. I remember a Mac CD burner (long long ago) that burned CDs directly from a hard drive -- the data moved from hard drive to CD drive directly, the CPU was simply issuing SCSI commands.
(I don't think that's actually in the SCSI specs, but then it was all Apple hardware.)
Ok. At most, one can connect TWO IDE drives per chain. The fastest hard drives on the planet can only sustain just under 40MB/s directly off the platter. So, you can buy ATA-1million and it's not going to make much of a difference.
The problem is the fundamental structure of IDE... one command to one device and wait for an answer before you talk to anything else. Modern IDE isn't quite as bad, but it still sucks in a very major way. (Note: modern IDE drives, aka ATAPI, are SCSI drives. It's just transported across an IDE bus which makes it suck horribly.)
Never send a ferret to do a weasel's job! :-)
First, watermarks don't work. They are worse than worthless. The theory goes you're not supposed to be able to hear it. But for it to work and not be simple to remove, it has to make significant changes -- either insert "noise" blocks or scatter bit flips throughout the track. Noise is easy to find and remove (and audible.) An embeding carrier can be completely destroyed with simple format changes (mp3 encoding, resampling, etc.)
Of course, to place a "serial number" in all the audio sent to radio stations would require every station to get a completely different CD. How long would it take to burn one CD for each radio station in a given area? It's far too much hassle. Plus, there's a chance the watermark would survive FM transmission (which is perfectly legal to record.)
Watermarked CDs are useless and infeasable.
I've not done any tests lately, however, the way things were in the past (measured in years), the linux kernel sucked out loud without some swap. 1k or 100M, it didn't matter; simplying having swap available significantly changed the behavior of the system.
Surprisingly, the tivo, based on 2.1.24, performs better with swap disabled. However, that kernel is heavily modified and, well, ancient.
So? We'll obviously need more than one (of anything) won't we.
I'm just wondering why no one has suggested a few thousand modified TiVos! I'm sure whomever is doing this would have almost zero problem getting Philips or Sony and Tivo to create a special purpose system (it'd need something other than IDE for communication to an archival device.) They'd have to be replaced every three years (expected drive lifetime.)
Not to fan the SCSI vs. IDE fire... Anyone who actually cares that there data will be there when they get up in the morning has already chosen SCSI. It's expensive, but it's expensive for a reason.
Tape will always win in the battle for archival. They last much longer and cost far, far less in the long run. I invite people to do the math... 3TB of tape vs. 3TB of hard drive. (The break-even is arounf 5-6k$. Below ~3TB, drives win and vice versa.) Plus, I've never seen a hard drive auto-loader; tho' I'm sure you could trick the old exabyte loader into doing it with a bit of work.
The lifetime of a video tape depends on many factors -- not the least of which is the crappiness of the tape (which is refered to as quality :-)) The most important is the number of times it gets run through a VCR. No matter how well constucted, tuned, and aligned, all VCRs damage the tape during use. Playback/recording places the tape under tension that eventually stretches the tape beyond any hope of usefulness. I've found about 3 months of recording and playback at 6hrs/weeks (each) is about as long as they last.
Magnetic cohesion is next big problem. This is a problem for any magnetic media. If you recorded a tape, end to end, removed it from the VCR and sealed it in a plastic bag, it would physically last for hundreds of years. The magnetic charge would not last that long. Have you ever touched the north end of one magnet to the north end of another magnet? They really don't like being near each other. The video tape is just a bunch of really tiny magnetic stuck really close to each other.
I find it funny to see people worried about the oxide "flaking off"... they've obviously never tried to scratch it off.
It'd be better if it actually worked! What "misc. preferences"?
And you weren't running on a PC either.
There are scalability limits beyond 4 and 8 processors. Part of it is hardware and a lot of it is software. SGI/IRIX does both very well (hello, they make/made the CRAY!) The scheduler used for small SMP systems does not work well with large SMP systems. And PXE, the 36-bit address extensions, is a significant performance hit for machines not acutally requiring it.
Performance does not scale linearly -- on any system. "About 2x" is not "2x". IRIX scales better than most, but it still isn't perfect. And, surprise, Windows scales better than Linux (or used to.) BeOS is about the best thing I've seen for standard PC hardware -- too bad it never caught on.
Datacenter is a great deal different from the other windows'. Unlike the difference between NT Workstation and Server (two registry keys), Datacenter is very different.
The only WB and UPN local stations currently in the lineup are two NYC stations. As far as I can find, they are the only WB and UPN stations out of the 1000 channels available :-( There's a Radio Shack channel (among other private channels), five(?) national Fox feeds, and hundreds of sports channels, but they cannot find a single source for WB and UPN? Gez!
So far, Enterprise is the only thing I've not been able to find. WGN carries some stuff, albeit a week behind the antenna.
A "tv tuner card" is not an MPEG encoder. You will not integrate an MPEG encoder into either device for 25$. I doubt you could buy the Sony chip [cxd1922] (alone) for 25$.
The DirectTV units default to "grid" mode. The SA's will not allow you to display in "grid" mode (without hacking.) I saw a Sony commercial with a SA unit showing the guide in grid mode once -- I was very shocked.
And I believe it's a GemStar (stupid) patent.
TiVo has vowed, repeatedly, to release the restrictions should they go out of business. And I beleive them.
One can set the clock via the UI. It's not very obvious and requires the backdoor codes to be enabled, but it can be done.
If TiVo goes out of business, the tape will be pulled off a lot of mouths. There are no secrets inside there. Once there's no longer a threat of lawyers (or killing the company), a lot of previously guarded utilities will surface -- feeding them guide data is not hard at all.
So get a DirectTV unit. It requires almost zero interaction with TiVo to function. With a few minor modifications, it never needs to call tivo. Sure, you'll stop getting "TiVolution Magazine" and "Showcases", but how often does anyone use those?
Translation: "This is the best way to protect my paycheck."
Really? Maybe you should get your head out of your ... never mind.
The system of "checks and balances" originally envisioned hasn't worked for many many years. People are too stupid and too greedy. The "system" failed for the DMCA. The "system" has had no effect on the recent anti-terrorism laws -- passing in HOURS. And it will fail with this bullshit as well.
This will be one more law people break with abandon. Of course, this one will be a lot harder to break with all the hardware manufacturers playing along.
Short of a cue, none of this is ever going to change.
Block inbound port 25 to stop spam? That's funny.
Actually, most modern routers (at least those that an ISP would be expected to use) can handle packet filtering with exceptional efficiency even for very large filter lists -- some have hardware for dealing with it. At any rate, it's not really the traffic that's killing anything. Routers are designed to move unimaginable numbers of packets around. It's the whole thing of sending traffic to nonexistant addresses that tend to hurt routers. However, filtering at the edge wouldn't do a great deal of good as there are certainly hundreds of infected machines inside the fort. Blocking traffic at the CPE interface_s_ (thousands of them) is a nightmare I'm going to skip.
Shortly at 9am Tuesday, I started getting paged continuously about CPU loads being too high. After removing the battery from the pagers, I checked the graphs... the volume of broadcast traffic was 7x higher than normal. It's all ARP traffic from the routers looking for machines that don't exist. The actual number of packets and bits flowing around haven't changed much since 9/11.
ARP gets to be very expensive when there are hundreds or thousands of machines being probed (esp. when there are many multi-point interfaces.) Memory fragmentation, much higher memory utilization, extremely high CPU usage in keeping up with all the bookkeeping -- scanning the ARP cache, aging the ARP cache, pruning the ARP cache, creating/updating/deleting ARP timers, processing retransmissions... -- all adds up quickly. (Note: Cisco routers will crash if memory fragmentation gets too high and/or memory allocations fail repeatedly.)
BTW, LaBrea is proving to an interesting toy even if it is ill suited to a multispan network (dozens of networks on one cable.) Libnet and libpcap not working right (right, my netmask is 0x514) proved interesting.