This is important in any drive array. IF you dont have them spaced apart and have cooling fans on them
Excellent point. Most cases place the hard drive bays so close that there is neglible space to allow even active cooling flow. I typically have to fabricate mounting brackets for the large arrays (typically 10 to 12 drives) to make them all fit in a 4U case. When drilling holes, I partition the space evenly and typically end up with 1/4 to 3/8 inch gap between. Sandwiching them all together cuts your effective heat transfer area by almost a factor of two for two drives and a factor of ~5 for six drives.
on a server or a professional workstation SCSI is the way to go
I do wish to avoid yet another SCSI/IDE flamefest, but I would point out that this configuration is like most of its ilk--it is basically network attached storage. That means that no one will be reading or writing from the server system itself, but will be accessing the raid array through a network link via NFS and/or SMB. In my experience, performance of Linux Software RAID5 on Promise IDE controllers with 80-GB Maxtor 5400-RPM hard drives can exceed 50 MB/s write and 70 MB/s read. SMB/NFS even over Gbit ethernet will be hard pressed to saturate that.
Having built many of these low-budget raid5 arrays, I cannot concur that SCSI and/or hardware RAID is necessary to see acceptable performance. <Horror stories about Hardware IDE RAID5 controllers deleted.>
I do admonish would-be builders to include an extra hard drive in the raid array as a hot spare. For four drive arrays (3 data + 1 parity), it may be unnecessary. For larger system (7 data + 1 parity), I think a hot spare is a worthwhile investment. Also, avoid 7200-RPM drives if possible and actively cool all of the drives in the array. One or two fans blowing on the array can make a big difference.
Microsoft distributes the base true type fonts at no cost, in fact they either invented or popularized the (usually inexpensive) true type font system to compete with expensive fonts from other vendors.
I must concur. TTF is something that Microsoft did right! Back in the "old" days, one had to purchase Adobe Type Manager in order to have scalable fonts in Windows 3.0. When 3.1 came out, Microsoft not only one-upped Adobe with TrueType integration, but they also innovated at bit. They included on-the-fly downloadable font generation for Laserjet compatible printers.
That was a big deal back in the day. If you could not download fonts to the printer and tried to print a font other than the handful of built-in fonts in the printer, each page had to dump a bitmap! Try a 286 with 1 MB RAM dumping to an Okilaser 400 over the OLD slow parallel port. One word: painful.
It made a huge difference at the time. It was an example of Microsoft's ability to really deliver value. I guess those examples have gotten fewer and fewer over the past decade.
Not that that will stop the doom-mongers whining about private planes, like.
You might want to be a bit less cavalier. True enough, the physical kinetic energy of a small aircraft is not going to be enough to do much damage to a large structure, but even a small plane can carry a few hundred pounds of explosives. That would do some serious damage. And, it is clear that security at local airports is essentially nonexistent.
Sufficiently motivated intelligent people will always be able to find clever ways to hurt you.
OK, I admit it. It is very easy to crucify these guys. Even if they have something interesting, they deserve bashing because of the foolish PR job. But, is it *impossible* that there is something to this? I am not implying that Information Theory is in peril. Certainly not. But, as a scientist, I have to be objective enough to accept that they might have something.
I took a quick look at Prof. Smale's publications. He has been working recently in complexity theory and other related fields. If he is actively involved, there may be something worthwhile here.
One of the most interesting things about complexity theory, fractals, and cellular automata is the incredible amount of detail that can be evidenced by "simple" systems. See some of Steve Wolfram's work and his upcoming book for more on this. One of still-born technologies of image compression was based on fractals. The self-symmetry principle was able to accurately capture image details with only a handful of data passed to generator functions. In fact, these compression techniques could even produce "more" detail (zooming in) than the orginal image possessed by extrapolating these generators further.
Of course, at first blush, this seems foolishness too. How can there be *more* detail after compression!? But, the essential fact is that natural "detail" is not as random as we might think. In still images, textures are often non-repeating but still highly correlated in some sense. In moving images, frame-by-frame correlation is typically very high. In executable code, only a small fraction of all possible arrangements of bytes can actually be executed. Perhaps Shannon's only weakness is believing too strongly in absolute randomness. Information Theoretic calculations leverage the pure statistical nature of the data stream to make calculations. Practical problems don't address purely random data and in making that purely random assumption, we may be shackling ourselves to Shannon's limits unnecessarily.
While Shannon does and will likely continue to hold, I am willing to admit that "most" data of interest contains less entropy per bit then it could. (Notable exceptions would be strongly encrypted data...encryption is *designed* to exhibit statistical randomness!) Huffman and arithmatic coding work by pattern matching techniques and allow lossless compression of many data types. JPEG uses the quantization of Discrete Cosine Transforms of 8x8 pixel blocks to compress images. MPEG uses DCT quantization will motion compensation and lots of other techniques to try to capture frame to frame correlations. All of these are practical data streams. None are obviously correllation, but none are truly random either. With fairly "simple-minded" encoding tricks, we are able to significantly reduce the size of data files (gzip), sound (mp3), images (jpeg) and video (divx). Is it not possible to build a more general mechanism with which to ferret out more hidden symmetries and thus increase compression?
I guess I am willing to accept that there is something more to this than simple charlatanism. Perhaps these folks have come up with an effective way to leverage complexity theory to establish a general framework for the construction generator functions, etc. It would be a landmark discovery if they are able to uncover self-similariry or some other self-generation principles from various data streams. Note that I did't say random data streams.
Why stop at one byte?! Compress it down to 1 bit. All the knowledge in the world...1 or 0, yes or no. Anyone wanna bet which? I am a nihilist, so I am going with zero.
Re:"Covered devices" an out for the RIAA?
on
Future of Music Summit
·
· Score: 2, Insightful
she's more concerned about CD-to-MP3 copying than CD-to-CD, which might, unfortunately, render Rep. Boucher's argument moot.
I understand your point, but I don't think that will hold water. The fact that the industry has changed (mp3 compression, cheap 100 GB storage) may require that the AHRA be clarified or expanded, but that does not permit the unilateral action on the part of the recording industry to deny an expressly granted right to consumers, namely the ability to produce CD copies.
I am not a lawyer, but I certainly think that the RIAA has some explaining to do. Or they have to start lining someone's pockets...
There is nothing "proprietary" here. The techniques for reliable transmission of digital data over unreliable media has been a central area of EE research for at least three decades. The unreliable media is now UDP instead of broadcast RF or transmission lines.
Line reliability in the "normal" sense is classified by bit error rates. Here, the analogous rating would be packet dropped per second. So, it seems like a straightforward application of FEC. It is useful for the reasons that they state. TCP transmissions look like this:
Client: Request Data Packet #00001
Server: Transmit Date Packet #00001 then wait for Client to say OK or Retransmit.
Client: Request Data Packet #00002
Server: Transmit Date Packet #00002 then wait for Client to say OK or Retransmit.
....
Client: Request Data Packet #20343
Server: Transmit Date Packet #20343 then wait for Client to say OK or Retransmit.
DONE
The FEC/UDP form would look like this:
Client: Request Data FILE
Server: Transmit FEC Data Packet #00001
Server: Transmit FEC Data Packet #00002
...
Server: Transmit FEC Data Packet #20343
Client: OK...I got it. Stop Transmitting.
DONE
There is no per-packet dialog between server and client. This removes network latency from the transfer equation. Note that FEC over UDP does require redundant information to be transmitted, so there is no free lunch here, but it is certainly likely to be faster than any TCP/IP implementation.
The buy-another-hard-drive answer is easy for home applications, but it is also true in large installations too.
We have about 2.0 TBs of RAID storage that need to be backed up. I built the RAID servers using IDE Promise controllers and 80-GB Maxtor hard drives (the largest back in the day). Right now, hard drives make the most cost effective sense for backups on this scale too. The current plan is to build a backup server with 4 to 6 removable drive bays and set them up as backup devices using scripts/tar or bru.
Right now, I am testing hot swap bays with Linux to verify that the system stability will acceptable. Also, I am looking into cheap gigabit interfaces to connect the raid servers to backup server. This could be a nice backup scheme for larger applications too.
Not to bust your bubble or anything, but the "transparent" terminal hack is old. It is not done with per-window alpha transparency. It just maps the root background to the terminal background with an appropriate offset and darkening. This is obvious if you look at the screenshot. The lower portion of the./sftp window does not show through into the terminal.
It is a clever, fast hack and probably more useful than honest-to-goodness alpha transparency. Careful choice of background image and foreground text color can keep the term actually legible, which is not necessarily the case with full transparency. Having said all of that, it has been in rxvt, aterm, and countless others for a long time.
...but I know too many uneducated, good hearted people who bust their asses at a minimum wage job every day to try and pay the bills and feed their families to fully get behind giving criminals the opportunity that some law-abiding Americans won't get.
I think you are very right. The most overlooked class of people in the U.S. is the working poor. No Welfare. No Social Security Insurance. No special education programs. They are the "white trash" who work 12-hour days in the cold or wait tables for $1/hr plus tips. Most are smarter and harder working than these criminals. They are more deserving of a little help. But, they don't have the time or energy to make a stink. They are too busy working.
The great untapped resource in this country is certainly not our prisons. It is those poor lower-income families who are just treading water. If we have money to spend, let's spend it on them.
You are right. There is no chance of moving "newbies" into any of the existing Linux distributions. I have many computer literate friends can only flirt with Linux. Setting up a system from scratch is just too difficult and Mom and Aunty June and Cousin Jeb will never be able to install any of the available Linux distros
So, perhaps there is a need for a computer illiterate distro. One bootable CD with a core installation. It doesn't ask for any input from the user. It simply partitions the hard drive, installs whatever hardware it finds (ethernet cards get DHCP'd, modems get a PPP installer application and diald'd to come up on demand, video goes to a 800x600@72Hz). Make nice application buttons (think TiVo, not GNOME/KDE) that will bring up Konq or Mozilla or KOffice or whatever. Make it very limited and very simple. But Linux still lurks beneath, so a hacker-type can customize it to suit.
One idea might be to make the root X window be generated by Gecko. That would make construction of the "user interface" very easy. Average users just want to get email, write book reports, and surf for pr0n. It will take a draconian installer to make all of the choices for these uninitiated souls if Linux is ever to reach the unwashed masses.
Hydrogen is a gas under "normal" transportation conditions. If the tank ruptures, it will explode. Period. Propane and CNG are liquids so the fuel must go through a state change in order to burn, slowing the rate of reaction in the case of a leak or rupture.
So, you are missing two things. First, the pressures involved in CNG and propane are far lower than that needed for effective H2 storage. Second, the larger hydrocarbons liquify much more easily than H2 resulting in ~1000x increase in density. Without a phase change, you either need to have enormous H2 storage tanks (for a given heating value of fuel) or you have to pressurize the system to several thousand psi.
To store a reasonable mass of hydrogen in a space roughly the size of an automobile's fuel tank requires the H2 to be stored at very high pressure, and hence demands a hefty container to maintain that pressure. Should that pressure vessel be ruptured, even in a non-oxidizing environment (pure N2 say), the explosive expansion of H2 would still be quite impressive. Now add to that the heat release from oxidation...well, it would be safe to say that you would put an end to injuries arising from automobile accidents. Every accident would be spectacularly fatal.
You make a very good point and it is perhaps a damning issue. One reason to burn hydrogen (or any hydrocarbon fuel) in pure O2 or an enriched O2 oxidizer is to avoid emmissions problems, specifically the production of NOx. His engine running on hydrogen will no doubt have a very hot flame. N2 in air starts to come apart above 1000 C and when the atomic nitrogen cools down, it will become NOx in some trace amounts. This is one of the fundamental issues in combustion design...reaching high efficiencies without raising the temperature and producing NOx.
Burning pure hydrogen/oxygen will allow much high combustion temperatures without NOx production and will produce more power (no N2 to dilute the combustion process), but it is not clear that carrying the oxygen along is worthwhile. The mass of the O2 would be eight times greater than that of the necessary H2.
Sorry to pick physics nits, but one liter of H2 cannot contain 3.5 Watts of power. Power is a measure of energy release per unit time. A liter of H2 (at a given density) will contain a certain amount of chemical energy. The power released by reacting it with an oxidizer will depend on the rate of the reaction.
Having said that, your point is spot on. Safely storing hydrogen in quantity is very difficult, especially for portable applications. Hydrocarbons such as propane can be liquified at much lower pressures/higher temperatures making them much easier and safer to use.
I work in the fuel cell area (developing physics-based simulations to model fuel cell systems) so I can tell you definitively that fuel cell manufacturers are seriously considering the issue of fuel reforming. That is breaking down hydrocarbon fuels such as methane or alcohol to form reformate gas containing H2 and CO. A gas-shift reaction can slide the CO to H2 under the right catalytic conditions. The goal for systems designers is to come up with a reformer technique which will allow on-the-fly fuel processing for the fuel cell. It is just too difficult to safely store large amounts of compressed H2. Energy density is much higher with hydrocarbons.
And your point about "shifting pollution" is not really valid. There are several reasons that fuel cells produce lower emissions than other equivalent systems. First, they operate at low temperature so the classic NOx production problem goes away even for high-temperature solid-oxide fuel cells. Second, the fuel processing procedure can guarantee that all of the hydrocarbons are consumed and none are released via the exhaust stream. Finally, the thermodynamic efficiency of fuel cell systems can go as high as 60% to even 80% depending on system size and loading. The best heat-engine running on the same fuel stock will only manage 35% at best. The fact that less fuel is consumed guarantees that not only will the fuel cell system be more cost effective, it will will also release less CO2 than a heat-engine providing equivalent output.
You do not need a third LNB to have a third tuner. To understand why requires some explanation. The old single LNB's where only able to receive one polarization (clockwise or counterclockwise) at a time. With one IRD (receiver) connected to the LNB, the system would select the polarization required to tune a given channel. A problem arises if you connect a second IRD. The single LNB system will work only if both IRDs try to tune channels which are on the same polarization.
Installation of a dual LNB solves the problem. One LNB receives the clockwise polarization while the other receives the counterclockwise. You can connect 3, 4, or more IRDs to a dual LNB and all of the units may be tuned independently without causing a conflict.
DBS providers are currently using secondary satellites to provide local network and foriegn channels. The so-called "quad" LNBs are really just two dual LNBs each of which are directed at different neighboring satellites. The newer "egg-shaped" dishes have two foci for the reflector, allowing the single dish to receive from two adjacent satellites. Each focus for each satellite requires a physically separate LNB. These are generally dual LNBs which receive both polarizations simultaneously.
The use of a dual channel memory implementation is a very important issue that motherboard and chipset manufacturers have been glossing over. Nvidia is revisiting the concept of dual data channels for memory access with its Nforce chipset in addition to using DDR RAM. IMO, that is the direction that both Intel and AMD chipsets should take.
RDRAM has exceptional memory bandwidth, but it will be equalled or exceeded by the NForce dual channel DDR offering. Moreover, Rambus only provides this bandwidth by using dual channel implementations.
I do hope that Nvidia seizes the chipset market from half-assed players like VIA, or at least forces the rest to get their acts together. Nvidia needs to roll Athlon MP support into that chipset and set the whole market on it ear. Based on benchmarks I have done for high performance computing applications, the Athlon succeeds now *in spite of* the chipset and memory architecture. The P4/RDRAM is the better choice for many of these applications because of memory bandwidth limitations in the VIA/AMD DDR implementations. The same is doubly true for the Athlon MP motherboards, while the Intel 860/Xeon/RDRAM combination provides enough memory bandwidth to satisfy two P4s.
I am glad to see Nvidia setting the pace here. They are experts at getting *real* performance out of cutting-edge memory technologies. I expect the Nforce to deliver, unlike the lackluster DDR implementations we've seen from VIA and Ali.
I am sorry to be a wet blanket, but I don't see how streaming video has much of a future for mass acceptance. There is an architectual problem with this approach. True enough...broadband rollouts have made it possible to distribute video with relative ease, but the transmission requirements are just so great that it is really difficult to justify the bandwidth investment, especially on the server end. More than that, I don't see how any streaming media company can try to provide robustness of service.
My view is that there are some applications that are well suited for point-to-point communication mechanisms such as IP. If we were discussing the possibility of using this technology to enable video phone or other video conferencing applications, I would be a bit less pessimistic. But, we need to recognize the fact that some transmission modes are inherently broadcast: one source, many many listeners. We can talk about implementations of IP broadcast to save upstream bandwidth, etc, but the fundamental scaling problems are still there. Many networks need to carry identical copies of the same data.
Last Tuesday, we witnessed the fragile nature of current servers/onramps in dealing only with high levels of http traffic. How many of us got anything more than a server timeout from cnn.com last Tuesday? But it wasn't very hard to just punch 204 in the DirecTV remote and there it is. Streaming anything over IP has a long way to go to catch up with truly broadcast mechanisms.
If such streaming applications are going to be attempted, the entire process needs to be decentralized. Video-on-demand needs to stream from many servers at once to improve robustness. It needs to automatically replicate popular data to servers in different parts of the Internet, etc. The current work in P2P networks is focusing on just this type of scheme. Of course, doing so flies in the face of DMCA and the media wonks who want paid. Centralization provides control and a single point of failure. Decentralization provides robustness and loss of control.
I question whether or not streaming media will ever become the service that Sun, Sony, and MS are envisioning. The only way to make it work is by taking the P2P route and most of those approaches are "pirate" in nature. It may come to fruition with P2P swarmcast/distributed-caching schemes, but I doubt that using it will be legal.
Wow...I was a fat and bearded (but not filthy) several years ago...I got started with RH4.1. What a piece of crap! Downloaded over a 28.8. It took about four days to get it. I had to install from a hard drive because I didn't have a CDR to burn an iso. Good old 120MHz 486...watching first runs of Babylon 5. And Enlightenment was in crash-per-minute beta and Gnome/KDE were just glimmers in our collective eyes. And signed up for some piece-of-shit webboard called Slashdot...back in the day.
Slashdot Mirror
unless they get their customers to do it
The customer *will* pay for it, one way or the other.
This is important in any drive array. IF you dont have them spaced apart and have cooling fans on them
Excellent point. Most cases place the hard drive bays so close that there is neglible space to allow even active cooling flow. I typically have to fabricate mounting brackets for the large arrays (typically 10 to 12 drives) to make them all fit in a 4U case. When drilling holes, I partition the space evenly and typically end up with 1/4 to 3/8 inch gap between. Sandwiching them all together cuts your effective heat transfer area by almost a factor of two for two drives and a factor of ~5 for six drives.
on a server or a professional workstation SCSI is the way to go
I do wish to avoid yet another SCSI/IDE flamefest, but I would point out that this configuration is like most of its ilk--it is basically network attached storage. That means that no one will be reading or writing from the server system itself, but will be accessing the raid array through a network link via NFS and/or SMB. In my experience, performance of Linux Software RAID5 on Promise IDE controllers with 80-GB Maxtor 5400-RPM hard drives can exceed 50 MB/s write and 70 MB/s read. SMB/NFS even over Gbit ethernet will be hard pressed to saturate that.
Having built many of these low-budget raid5 arrays, I cannot concur that SCSI and/or hardware RAID is necessary to see acceptable performance. <Horror stories about Hardware IDE RAID5 controllers deleted.>
I do admonish would-be builders to include an extra hard drive in the raid array as a hot spare. For four drive arrays (3 data + 1 parity), it may be unnecessary. For larger system (7 data + 1 parity), I think a hot spare is a worthwhile investment. Also, avoid 7200-RPM drives if possible and actively cool all of the drives in the array. One or two fans blowing on the array can make a big difference.
Microsoft distributes the base true type fonts at no cost, in fact they either invented or popularized the (usually inexpensive) true type font system to compete with expensive fonts from other vendors.
I must concur. TTF is something that Microsoft did right! Back in the "old" days, one had to purchase Adobe Type Manager in order to have scalable fonts in Windows 3.0. When 3.1 came out, Microsoft not only one-upped Adobe with TrueType integration, but they also innovated at bit. They included on-the-fly downloadable font generation for Laserjet compatible printers.
That was a big deal back in the day. If you could not download fonts to the printer and tried to print a font other than the handful of built-in fonts in the printer, each page had to dump a bitmap! Try a 286 with 1 MB RAM dumping to an Okilaser 400 over the OLD slow parallel port. One word: painful.
It made a huge difference at the time. It was an example of Microsoft's ability to really deliver value. I guess those examples have gotten fewer and fewer over the past decade.
So exactly how do you change the kernel without rebooting?
Try the Two-Kernel Monte.
Not that that will stop the doom-mongers whining about private planes, like.
You might want to be a bit less cavalier. True enough, the physical kinetic energy of a small aircraft is not going to be enough to do much damage to a large structure, but even a small plane can carry a few hundred pounds of explosives. That would do some serious damage. And, it is clear that security at local airports is essentially nonexistent.
Sufficiently motivated intelligent people will always be able to find clever ways to hurt you.
OK, I admit it. It is very easy to crucify these guys. Even if they have something interesting, they deserve bashing because of the foolish PR job. But, is it *impossible* that there is something to this? I am not implying that Information Theory is in peril. Certainly not. But, as a scientist, I have to be objective enough to accept that they might have something.
I took a quick look at Prof. Smale's publications. He has been working recently in complexity theory and other related fields. If he is actively involved, there may be something worthwhile here.
One of the most interesting things about complexity theory, fractals, and cellular automata is the incredible amount of detail that can be evidenced by "simple" systems. See some of Steve Wolfram's work and his upcoming book for more on this. One of still-born technologies of image compression was based on fractals. The self-symmetry principle was able to accurately capture image details with only a handful of data passed to generator functions. In fact, these compression techniques could even produce "more" detail (zooming in) than the orginal image possessed by extrapolating these generators further.
Of course, at first blush, this seems foolishness too. How can there be *more* detail after compression!? But, the essential fact is that natural "detail" is not as random as we might think. In still images, textures are often non-repeating but still highly correlated in some sense. In moving images, frame-by-frame correlation is typically very high. In executable code, only a small fraction of all possible arrangements of bytes can actually be executed. Perhaps Shannon's only weakness is believing too strongly in absolute randomness. Information Theoretic calculations leverage the pure statistical nature of the data stream to make calculations. Practical problems don't address purely random data and in making that purely random assumption, we may be shackling ourselves to Shannon's limits unnecessarily.
While Shannon does and will likely continue to hold, I am willing to admit that "most" data of interest contains less entropy per bit then it could. (Notable exceptions would be strongly encrypted data...encryption is *designed* to exhibit statistical randomness!) Huffman and arithmatic coding work by pattern matching techniques and allow lossless compression of many data types. JPEG uses the quantization of Discrete Cosine Transforms of 8x8 pixel blocks to compress images. MPEG uses DCT quantization will motion compensation and lots of other techniques to try to capture frame to frame correlations. All of these are practical data streams. None are obviously correllation, but none are truly random either. With fairly "simple-minded" encoding tricks, we are able to significantly reduce the size of data files (gzip), sound (mp3), images (jpeg) and video (divx). Is it not possible to build a more general mechanism with which to ferret out more hidden symmetries and thus increase compression?
I guess I am willing to accept that there is something more to this than simple charlatanism. Perhaps these folks have come up with an effective way to leverage complexity theory to establish a general framework for the construction generator functions, etc. It would be a landmark discovery if they are able to uncover self-similariry or some other self-generation principles from various data streams. Note that I did't say random data streams.
Why stop at one byte?! Compress it down to 1 bit. All the knowledge in the world...1 or 0, yes or no. Anyone wanna bet which? I am a nihilist, so I am going with zero.
she's more concerned about CD-to-MP3 copying than CD-to-CD, which might, unfortunately, render Rep. Boucher's argument moot.
I understand your point, but I don't think that will hold water. The fact that the industry has changed (mp3 compression, cheap 100 GB storage) may require that the AHRA be clarified or expanded, but that does not permit the unilateral action on the part of the recording industry to deny an expressly granted right to consumers, namely the ability to produce CD copies.
I am not a lawyer, but I certainly think that the RIAA has some explaining to do. Or they have to start lining someone's pockets...
"Um...there is a Dr. Freud on the phone. He's asking if you have his slip?"
There is nothing "proprietary" here. The techniques for reliable transmission of digital data over unreliable media has been a central area of EE research for at least three decades. The unreliable media is now UDP instead of broadcast RF or transmission lines.
Line reliability in the "normal" sense is classified by bit error rates. Here, the analogous rating would be packet dropped per second. So, it seems like a straightforward application of FEC. It is useful for the reasons that they state. TCP transmissions look like this:
Client: Request Data Packet #00001
Server: Transmit Date Packet #00001 then wait for Client to say OK or Retransmit.
Client: Request Data Packet #00002
Server: Transmit Date Packet #00002 then wait for Client to say OK or Retransmit.
....
Client: Request Data Packet #20343
Server: Transmit Date Packet #20343 then wait for Client to say OK or Retransmit.
DONE
The FEC/UDP form would look like this:
Client: Request Data FILE
Server: Transmit FEC Data Packet #00001
Server: Transmit FEC Data Packet #00002
...
Server: Transmit FEC Data Packet #20343
Client: OK...I got it. Stop Transmitting.
DONE
There is no per-packet dialog between server and client. This removes network latency from the transfer equation. Note that FEC over UDP does require redundant information to be transmitted, so there is no free lunch here, but it is certainly likely to be faster than any TCP/IP implementation.
The buy-another-hard-drive answer is easy for home applications, but it is also true in large installations too.
We have about 2.0 TBs of RAID storage that need to be backed up. I built the RAID servers using IDE Promise controllers and 80-GB Maxtor hard drives (the largest back in the day). Right now, hard drives make the most cost effective sense for backups on this scale too. The current plan is to build a backup server with 4 to 6 removable drive bays and set them up as backup devices using scripts/tar or bru.
Right now, I am testing hot swap bays with Linux to verify that the system stability will acceptable. Also, I am looking into cheap gigabit interfaces to connect the raid servers to backup server. This could be a nice backup scheme for larger applications too.
Not to bust your bubble or anything, but the "transparent" terminal hack is old. It is not done with per-window alpha transparency. It just maps the root background to the terminal background with an appropriate offset and darkening. This is obvious if you look at the screenshot. The lower portion of the ./sftp window does not show through into the terminal.
It is a clever, fast hack and probably more useful than honest-to-goodness alpha transparency. Careful choice of background image and foreground text color can keep the term actually legible, which is not necessarily the case with full transparency. Having said all of that, it has been in rxvt, aterm, and countless others for a long time.
...but I know too many uneducated, good hearted people who bust their asses at a minimum wage job every day to try and pay the bills and feed their families to fully get behind giving criminals the opportunity that some law-abiding Americans won't get.
I think you are very right. The most overlooked class of people in the U.S. is the working poor. No Welfare. No Social Security Insurance. No special education programs. They are the "white trash" who work 12-hour days in the cold or wait tables for $1/hr plus tips. Most are smarter and harder working than these criminals. They are more deserving of a little help. But, they don't have the time or energy to make a stink. They are too busy working.
The great untapped resource in this country is certainly not our prisons. It is those poor lower-income families who are just treading water. If we have money to spend, let's spend it on them.
You are right. There is no chance of moving "newbies" into any of the existing Linux distributions. I have many computer literate friends can only flirt with Linux. Setting up a system from scratch is just too difficult and Mom and Aunty June and Cousin Jeb will never be able to install any of the available Linux distros
So, perhaps there is a need for a computer illiterate distro. One bootable CD with a core installation. It doesn't ask for any input from the user. It simply partitions the hard drive, installs whatever hardware it finds (ethernet cards get DHCP'd, modems get a PPP installer application and diald'd to come up on demand, video goes to a 800x600@72Hz). Make nice application buttons (think TiVo, not GNOME/KDE) that will bring up Konq or Mozilla or KOffice or whatever. Make it very limited and very simple. But Linux still lurks beneath, so a hacker-type can customize it to suit.
One idea might be to make the root X window be generated by Gecko. That would make construction of the "user interface" very easy. Average users just want to get email, write book reports, and surf for pr0n. It will take a draconian installer to make all of the choices for these uninitiated souls if Linux is ever to reach the unwashed masses.
Just MO.
'pity anyone who thinks they know what is *really* going on'
Well put!
Hydrogen is a gas under "normal" transportation conditions. If the tank ruptures, it will explode. Period. Propane and CNG are liquids so the fuel must go through a state change in order to burn, slowing the rate of reaction in the case of a leak or rupture.
So, you are missing two things. First, the pressures involved in CNG and propane are far lower than that needed for effective H2 storage. Second, the larger hydrocarbons liquify much more easily than H2 resulting in ~1000x increase in density. Without a phase change, you either need to have enormous H2 storage tanks (for a given heating value of fuel) or you have to pressurize the system to several thousand psi.
To store a reasonable mass of hydrogen in a space roughly the size of an automobile's fuel tank requires the H2 to be stored at very high pressure, and hence demands a hefty container to maintain that pressure. Should that pressure vessel be ruptured, even in a non-oxidizing environment (pure N2 say), the explosive expansion of H2 would still be quite impressive. Now add to that the heat release from oxidation...well, it would be safe to say that you would put an end to injuries arising from automobile accidents. Every accident would be spectacularly fatal.
You make a very good point and it is perhaps a damning issue. One reason to burn hydrogen (or any hydrocarbon fuel) in pure O2 or an enriched O2 oxidizer is to avoid emmissions problems, specifically the production of NOx. His engine running on hydrogen will no doubt have a very hot flame. N2 in air starts to come apart above 1000 C and when the atomic nitrogen cools down, it will become NOx in some trace amounts. This is one of the fundamental issues in combustion design...reaching high efficiencies without raising the temperature and producing NOx.
Burning pure hydrogen/oxygen will allow much high combustion temperatures without NOx production and will produce more power (no N2 to dilute the combustion process), but it is not clear that carrying the oxygen along is worthwhile. The mass of the O2 would be eight times greater than that of the necessary H2.
Sorry to pick physics nits, but one liter of H2 cannot contain 3.5 Watts of power. Power is a measure of energy release per unit time. A liter of H2 (at a given density) will contain a certain amount of chemical energy. The power released by reacting it with an oxidizer will depend on the rate of the reaction.
Having said that, your point is spot on. Safely storing hydrogen in quantity is very difficult, especially for portable applications. Hydrocarbons such as propane can be liquified at much lower pressures/higher temperatures making them much easier and safer to use.
I work in the fuel cell area (developing physics-based simulations to model fuel cell systems) so I can tell you definitively that fuel cell manufacturers are seriously considering the issue of fuel reforming. That is breaking down hydrocarbon fuels such as methane or alcohol to form reformate gas containing H2 and CO. A gas-shift reaction can slide the CO to H2 under the right catalytic conditions. The goal for systems designers is to come up with a reformer technique which will allow on-the-fly fuel processing for the fuel cell. It is just too difficult to safely store large amounts of compressed H2. Energy density is much higher with hydrocarbons.
And your point about "shifting pollution" is not really valid. There are several reasons that fuel cells produce lower emissions than other equivalent systems. First, they operate at low temperature so the classic NOx production problem goes away even for high-temperature solid-oxide fuel cells. Second, the fuel processing procedure can guarantee that all of the hydrocarbons are consumed and none are released via the exhaust stream. Finally, the thermodynamic efficiency of fuel cell systems can go as high as 60% to even 80% depending on system size and loading. The best heat-engine running on the same fuel stock will only manage 35% at best. The fact that less fuel is consumed guarantees that not only will the fuel cell system be more cost effective, it will will also release less CO2 than a heat-engine providing equivalent output.
You do not need a third LNB to have a third tuner. To understand why requires some explanation. The old single LNB's where only able to receive one polarization (clockwise or counterclockwise) at a time. With one IRD (receiver) connected to the LNB, the system would select the polarization required to tune a given channel. A problem arises if you connect a second IRD. The single LNB system will work only if both IRDs try to tune channels which are on the same polarization.
Installation of a dual LNB solves the problem. One LNB receives the clockwise polarization while the other receives the counterclockwise. You can connect 3, 4, or more IRDs to a dual LNB and all of the units may be tuned independently without causing a conflict.
DBS providers are currently using secondary satellites to provide local network and foriegn channels. The so-called "quad" LNBs are really just two dual LNBs each of which are directed at different neighboring satellites. The newer "egg-shaped" dishes have two foci for the reflector, allowing the single dish to receive from two adjacent satellites. Each focus for each satellite requires a physically separate LNB. These are generally dual LNBs which receive both polarizations simultaneously.
The use of a dual channel memory implementation is a very important issue that motherboard and chipset manufacturers have been glossing over. Nvidia is revisiting the concept of dual data channels for memory access with its Nforce chipset in addition to using DDR RAM. IMO, that is the direction that both Intel and AMD chipsets should take.
RDRAM has exceptional memory bandwidth, but it will be equalled or exceeded by the NForce dual channel DDR offering. Moreover, Rambus only provides this bandwidth by using dual channel implementations.
I do hope that Nvidia seizes the chipset market from half-assed players like VIA, or at least forces the rest to get their acts together. Nvidia needs to roll Athlon MP support into that chipset and set the whole market on it ear. Based on benchmarks I have done for high performance computing applications, the Athlon succeeds now *in spite of* the chipset and memory architecture. The P4/RDRAM is the better choice for many of these applications because of memory bandwidth limitations in the VIA/AMD DDR implementations. The same is doubly true for the Athlon MP motherboards, while the Intel 860/Xeon/RDRAM combination provides enough memory bandwidth to satisfy two P4s.
I am glad to see Nvidia setting the pace here. They are experts at getting *real* performance out of cutting-edge memory technologies. I expect the Nforce to deliver, unlike the lackluster DDR implementations we've seen from VIA and Ali.
I am sorry to be a wet blanket, but I don't see how streaming video has much of a future for mass acceptance. There is an architectual problem with this approach. True enough...broadband rollouts have made it possible to distribute video with relative ease, but the transmission requirements are just so great that it is really difficult to justify the bandwidth investment, especially on the server end. More than that, I don't see how any streaming media company can try to provide robustness of service.
My view is that there are some applications that are well suited for point-to-point communication mechanisms such as IP. If we were discussing the possibility of using this technology to enable video phone or other video conferencing applications, I would be a bit less pessimistic. But, we need to recognize the fact that some transmission modes are inherently broadcast: one source, many many listeners. We can talk about implementations of IP broadcast to save upstream bandwidth, etc, but the fundamental scaling problems are still there. Many networks need to carry identical copies of the same data.
Last Tuesday, we witnessed the fragile nature of current servers/onramps in dealing only with high levels of http traffic. How many of us got anything more than a server timeout from cnn.com last Tuesday? But it wasn't very hard to just punch 204 in the DirecTV remote and there it is. Streaming anything over IP has a long way to go to catch up with truly broadcast mechanisms.
If such streaming applications are going to be attempted, the entire process needs to be decentralized. Video-on-demand needs to stream from many servers at once to improve robustness. It needs to automatically replicate popular data to servers in different parts of the Internet, etc. The current work in P2P networks is focusing on just this type of scheme. Of course, doing so flies in the face of DMCA and the media wonks who want paid. Centralization provides control and a single point of failure. Decentralization provides robustness and loss of control.
I question whether or not streaming media will ever become the service that Sun, Sony, and MS are envisioning. The only way to make it work is by taking the P2P route and most of those approaches are "pirate" in nature. It may come to fruition with P2P swarmcast/distributed-caching schemes, but I doubt that using it will be legal.
Wow...I was a fat and bearded (but not filthy) several years ago...I got started with RH4.1. What a piece of crap! Downloaded over a 28.8. It took about four days to get it. I had to install from a hard drive because I didn't have a CDR to burn an iso. Good old 120MHz 486...watching first runs of Babylon 5. And Enlightenment was in crash-per-minute beta and Gnome/KDE were just glimmers in our collective eyes. And signed up for some piece-of-shit webboard called Slashdot...back in the day.
Starting to feel a little old.