Windows 7 includes window tiling features to help with this. Drag the window title until the cursor touches the right side of the screen, release, and the window will take up the entire right half of the screen. Same for left half. There is also a key combination, and it will work with multiple monitors.
Supporting ClearType style subpixel rendering in your FSAA might help too. But the big problem with doubling pixel density is that so many Windows applications other than games are hardcoded for 96 dpi, ignoring Display Properties > Settings > Advanced > General > DPI setting.
Vista already supports full DPI independence for applications written for WPF. For older applications it will draw the application at 96DPI and then scale the image. If you precisely doubled the DPI, then newer applications would look amazing, while older applications look the same.
In practice, because the DPI is usually scaled by some odd amount, older applications can look a bit fuzzy. Most users seem to be fine with this as they will often change the display resolution on an LCD to get text bigger to make it easier to read. This makes everything fuzzy, so having at least the OS and newer applications render sharply and larger is just a plus.
Vista has been out for close to 3 years, so this seems to be something of a non-issue for Windows. I know there was talk about adding it for OSX, but I don't know if it was added in Snow Leopard. I can only assume people have fit things together for X based window managers, but again I don't know.
My current calculus professor allows us to use whatever calculator we want on the tests, which is extremely useful as it allows us to check our work and see if we made some mundane mistake somewhere. As the answer provided by the calculator is rarely in a form that is even recognizable as the answers we get, this involves simply subtracting our answer from the calculators answer to get zero (or some other constant or variable).
Points are awarded based on work steps, so an answer without work gets you nothing.
Most ERs won't report an illegal immigrant to authorities. This is actually part of the problem as illegal immigrants don't pay many taxes, but take advantage of things like free schooling and health care at the ER. One of the reasons that an ER visit is so expensive is to cover the cost of treating illegal immigrants that they will never be able to contact about paying bills.
I just want them to become legal citizens and start paying their bills and contributing to society.
I asked to verify I understood correctly, and he indicated that it was a quick implemented feature based on metadata copies, so basically not to expect much out of it. It's possible he was wrong or there was a miscommunication though.
Looking more at the documentation though seems to indicate that the only time this would happen is if the other drive(s) do not have the space available for the copies, in which case multiple copies will be written to the same drive. http://blogs.sun.com/relling/entry/zfs_copies_and_data_protection
The chances to catch fire depend heavily on the makeup of the cardboard. This appears to be cheap, uncoated board, so there is likely to be a lot of loose surface fiber. If a capacitor blows on the motherboard and produces a shower of sparks, I wouldn't be at all surprised to see the case begin to burn.
As the other poster mentioned though, this can be mitigated by adding flame retardants.
ZFS now has triple parity, as well as actively checksumming every disk block.
You can also store multiple copies of blocks, however there is a caveat on this. From the #zfs channel on Freenode:
[2009-09-12 09:24:03] [kjetilho] in ZFS, you need to add multiple disks at a time to get redundancy
[2009-09-12 09:24:49] [kjetilho] you can specify "copies=2" which means all data will be stored twice, but you're not guaranteed the copies will be on different disks
So you can store multiple copies of blocks, but you can't guarantee the copies will be on different drives? I don't know whether to laugh or cry.
Unfortunately, many RAID implementations do exactly that -- a single read/write error and the drive is marked bad and taken offline, and a rebuild is required.
That's pretty much been my experience with the multiple RAID controller cards we've used. There are simpler/better ways to handle the error, but they seem to be ignored. Especially with the size of drives, a single error that has nothing to do with the drive's long term reliability marks the drive as bad. Sure you can pull the drive and pop it back in, but that requires a full rebuild. A controller card should make the drive read/write to that area a few times to get the drive to mark it back it bad and remap the sector, then just write the stripe back in place. (And log/email a notification of the error.)
This is basically what Xiotech does, and they make a bundle because it is all seamless and they never have to replace any drives in their storage boxes.
It does file level replication across NTFS formatted drives of dissimilar sizes. You can add/remove drives easily. If you have a 20 drive array and half of you drives fail, you only lose the files that were just on those drives. You can pull any one of the drives out and hook it to another computer (Windows/Linux/etc) and you can read all of the files stored on that drive in their original directory structure.
There can be performance gains, but there might not be depending on usage (whether or not people are accessing files that have copies on different drives). It's perfect for home uses as recovery is brain dead simple and the storage scalability is great for storing videos on.
Nothing like this exists yet in Linux (or anywhere else that I've seen). There are some pretty flexible Linux distros out there that do some magic form of RAID, but there are still serious performance penalties with writing the parity, and they simple (connect drive to any other machine) recovery method.
The magic happens through the Windows SMB share, so if the feature were to be replicated in Linux, it'd probably be through a modification/hack of Samba. Ideally the storage would be on ZFS/BTRFS so that data integrity is hashed at the block level. I'm basically waiting around for someone to figure out how to do this in Linux.
Actually, reliability quickly scales towards RAID 1+0 as the number of drives increases. In a 14 drive array, a single drive failure in both is fine. A second drive failure has the possibility of destroying the RAID 1+0 array, but the chance of the right drive failing is low. With 3 total drive failures, RAID 6 will fail, while RAID 1+0 has a low probability of failure.
Rebuild times are also much shorter on RAID 1+0 as only a single drive has to be read, which reduces heat produced and the chance of a second failure.
There are some papers that describe the math of the statistical analysis to prove it, but I can't track it down at the moment. It is a rather counter intuitive. But, you have significantly less drive space, so RAID 6 may still be the better option for some circumstances.
There was an article a few months back about using blue food dye in spinal cords immediately after injury having a significant effect. Possibly this is what you are thinking of?
Write speeds for a given rotational speed have been getting better over the years, and any real system is going to be using a battery backed cache anyway. With a properly tuned file system I don't see any benefit from an SSD for purely sequential writes. Add in cache on a controller card, and you don't even need that. Modern drives can cache the fsync() operations and perform them as a long single write.
Most ASICs really aren't that good. For instance, the efficiency of compression on most cameras is not that good, but it only has to be good enough to compress down to a size that it can write fast enough to its medium. On a PC the encoders are heavily optimized towards efficiency as you want to reduce storage and transfer costs as much as possible.
Today, with the sheer number of transistors on a general purpose CPU, it would cost way too much to develop an ASIC that is faster for many purposes in raw power. But an ASIC is going to be more efficient in performance/watt due to its specialized nature.
(20 years ago CPUs were much less complex and fast, so a simple ASIC would smoke an general purpose CPU at its task, but this is no longer the case.)
An application that needs to commit a write to a database, ensuring that the bits are actually written to a physical medium, will be be able to utilise flash rather than a hard disk.
Log files are sequential, so there is no speed benefit in using flash media instead of hard drives.
I ended up listening to the second half of the WoT books on tape while working out as I couldn't stand to actually read them. The EG sequels weren't terribly great to me, but I did enjoy the Hedgemon series, which parallels Ender's Game for a part of it. It's interesting to view the events of Ender's Game from a different perspective, and I get the feeling that it would have been interesting for the WoT series too. The problem seemed that he was trying to show it from 10 different perspectives simultaneously in his books, which just makes it exceedingly drawn out for anything to happen.
It just occurred to me that it would have been like if Orson Card had never finished the book Ender's Game. If instead he had started it, but then started pumping out books to deal with the various sub plots and people on the station and what happened to them. Later on he did actually write separate series for the characters, which is what (I think) Jordan should have done. Instead we have 10,000 unfinished subplots.
(Disclaimer: I've read the Wheel of Time series four times.
That just sounds painful. I'm with the others though, the books are far too long. He has whole books devoted to fleshing out sub-plots that don't matter and aren't going anywhere. Sure it might be a bit interesting, but I'd rather go back and deal with that huge dangling piece of the primary plot that you left 3000 pages ago in book four.
It was like he began a basic plot framework, and then decided to devote a book to each little subplot and minor character that came along. What he should have done was finish the plot, and then add in books later that fulfilled his need to recount each and every little detail.
Nah. You just use redundancy to ensure reliability. Lots and lots of redundancy. MD-RAID and LVM offer all that's needed to make this work -- though doing it on a large scale requires lots of elbow grease.
I agree that "Just plug in another drive" is a far cry from what you have to do with these tools, but you can make it work.
Well, good luck to them. In the long term I expect there to be a Linux distro that you can boot and add to a storage cluster (at least I really hope so). But for now organizing a syncing that kind of data set is going to be a real pita to get all of the kinks worked out.
Those are a lot of "what if" needs, so I'm guessing the answer is more along the lines of, "Amazon provides a lot of services that can be well worth the cost if you need them all."
On the other hand, if you know what you're doing, and your needs are simple, then then there could be significant cost savings. Buying a couple of these and setting up redundancy at multiple locations wouldn't be that difficult, but there are a lot of little things that just can't be done. For instance, EMC has all sorts of options for how data is distributed, options that simply aren't available on any open source package.
I'm really looking forward to the day when there is a Linux distro that you just install and select to join a storage cluster.
I would say that most of the innovation happening for the past 30 years boils down to two areas:
1. Computer and networking hardware
2. Software development
Computers began to be well organized and designed to communicate with each other in the 1970s. From there they've become faster, obtained better networking, and have significantly better storage.
The second area (software development) though is the overlooked part. People completely forget about it. Millions (billions?) of man hours have been put into designing new algorithms and new uses for hardware/software. The advances made in software are astounding, and make possible things that were never imagined in 1960.
If people are looking for where development has happened, point them to software.
Slashdot Mirror
Windows 7 includes window tiling features to help with this. Drag the window title until the cursor touches the right side of the screen, release, and the window will take up the entire right half of the screen. Same for left half. There is also a key combination, and it will work with multiple monitors.
Supporting ClearType style subpixel rendering in your FSAA might help too. But the big problem with doubling pixel density is that so many Windows applications other than games are hardcoded for 96 dpi, ignoring Display Properties > Settings > Advanced > General > DPI setting.
Vista already supports full DPI independence for applications written for WPF. For older applications it will draw the application at 96DPI and then scale the image. If you precisely doubled the DPI, then newer applications would look amazing, while older applications look the same.
In practice, because the DPI is usually scaled by some odd amount, older applications can look a bit fuzzy. Most users seem to be fine with this as they will often change the display resolution on an LCD to get text bigger to make it easier to read. This makes everything fuzzy, so having at least the OS and newer applications render sharply and larger is just a plus.
Vista has been out for close to 3 years, so this seems to be something of a non-issue for Windows. I know there was talk about adding it for OSX, but I don't know if it was added in Snow Leopard. I can only assume people have fit things together for X based window managers, but again I don't know.
My current calculus professor allows us to use whatever calculator we want on the tests, which is extremely useful as it allows us to check our work and see if we made some mundane mistake somewhere. As the answer provided by the calculator is rarely in a form that is even recognizable as the answers we get, this involves simply subtracting our answer from the calculators answer to get zero (or some other constant or variable).
Points are awarded based on work steps, so an answer without work gets you nothing.
Most ERs won't report an illegal immigrant to authorities. This is actually part of the problem as illegal immigrants don't pay many taxes, but take advantage of things like free schooling and health care at the ER. One of the reasons that an ER visit is so expensive is to cover the cost of treating illegal immigrants that they will never be able to contact about paying bills.
I just want them to become legal citizens and start paying their bills and contributing to society.
I asked to verify I understood correctly, and he indicated that it was a quick implemented feature based on metadata copies, so basically not to expect much out of it. It's possible he was wrong or there was a miscommunication though.
Looking more at the documentation though seems to indicate that the only time this would happen is if the other drive(s) do not have the space available for the copies, in which case multiple copies will be written to the same drive.
http://blogs.sun.com/relling/entry/zfs_copies_and_data_protection
The chances to catch fire depend heavily on the makeup of the cardboard. This appears to be cheap, uncoated board, so there is likely to be a lot of loose surface fiber. If a capacitor blows on the motherboard and produces a shower of sparks, I wouldn't be at all surprised to see the case begin to burn.
As the other poster mentioned though, this can be mitigated by adding flame retardants.
ZFS now has triple parity, as well as actively checksumming every disk block.
You can also store multiple copies of blocks, however there is a caveat on this. From the #zfs channel on Freenode:
[2009-09-12 09:24:03] [kjetilho] in ZFS, you need to add multiple disks at a time to get redundancy
[2009-09-12 09:24:49] [kjetilho] you can specify "copies=2" which means all data will be stored twice, but you're not guaranteed the copies will be on different disks
So you can store multiple copies of blocks, but you can't guarantee the copies will be on different drives? I don't know whether to laugh or cry.
Unfortunately, many RAID implementations do exactly that -- a single read/write error and the drive is marked bad and taken offline, and a rebuild is required.
That's pretty much been my experience with the multiple RAID controller cards we've used. There are simpler/better ways to handle the error, but they seem to be ignored. Especially with the size of drives, a single error that has nothing to do with the drive's long term reliability marks the drive as bad. Sure you can pull the drive and pop it back in, but that requires a full rebuild. A controller card should make the drive read/write to that area a few times to get the drive to mark it back it bad and remap the sector, then just write the stripe back in place. (And log/email a notification of the error.)
This is basically what Xiotech does, and they make a bundle because it is all seamless and they never have to replace any drives in their storage boxes.
While it isn't likely to gain many fans on Slashdot, Drive Extender feature of Windows Home Server is the perfect RAID replacement for home uses.
http://en.wikipedia.org/wiki/Windows_Home_Server#Drive_Extender
It does file level replication across NTFS formatted drives of dissimilar sizes. You can add/remove drives easily. If you have a 20 drive array and half of you drives fail, you only lose the files that were just on those drives. You can pull any one of the drives out and hook it to another computer (Windows/Linux/etc) and you can read all of the files stored on that drive in their original directory structure.
There can be performance gains, but there might not be depending on usage (whether or not people are accessing files that have copies on different drives). It's perfect for home uses as recovery is brain dead simple and the storage scalability is great for storing videos on.
Nothing like this exists yet in Linux (or anywhere else that I've seen). There are some pretty flexible Linux distros out there that do some magic form of RAID, but there are still serious performance penalties with writing the parity, and they simple (connect drive to any other machine) recovery method.
The magic happens through the Windows SMB share, so if the feature were to be replicated in Linux, it'd probably be through a modification/hack of Samba. Ideally the storage would be on ZFS/BTRFS so that data integrity is hashed at the block level. I'm basically waiting around for someone to figure out how to do this in Linux.
Actually, reliability quickly scales towards RAID 1+0 as the number of drives increases. In a 14 drive array, a single drive failure in both is fine. A second drive failure has the possibility of destroying the RAID 1+0 array, but the chance of the right drive failing is low. With 3 total drive failures, RAID 6 will fail, while RAID 1+0 has a low probability of failure.
Rebuild times are also much shorter on RAID 1+0 as only a single drive has to be read, which reduces heat produced and the chance of a second failure.
There are some papers that describe the math of the statistical analysis to prove it, but I can't track it down at the moment. It is a rather counter intuitive. But, you have significantly less drive space, so RAID 6 may still be the better option for some circumstances.
There was an article a few months back about using blue food dye in spinal cords immediately after injury having a significant effect. Possibly this is what you are thinking of?
Write speeds for a given rotational speed have been getting better over the years, and any real system is going to be using a battery backed cache anyway. With a properly tuned file system I don't see any benefit from an SSD for purely sequential writes. Add in cache on a controller card, and you don't even need that. Modern drives can cache the fsync() operations and perform them as a long single write.
Most ASICs really aren't that good. For instance, the efficiency of compression on most cameras is not that good, but it only has to be good enough to compress down to a size that it can write fast enough to its medium. On a PC the encoders are heavily optimized towards efficiency as you want to reduce storage and transfer costs as much as possible.
Today, with the sheer number of transistors on a general purpose CPU, it would cost way too much to develop an ASIC that is faster for many purposes in raw power. But an ASIC is going to be more efficient in performance/watt due to its specialized nature.
(20 years ago CPUs were much less complex and fast, so a simple ASIC would smoke an general purpose CPU at its task, but this is no longer the case.)
An application that needs to commit a write to a database, ensuring that the bits are actually written to a physical medium, will be be able to utilise flash rather than a hard disk.
Log files are sequential, so there is no speed benefit in using flash media instead of hard drives.
I ended up listening to the second half of the WoT books on tape while working out as I couldn't stand to actually read them. The EG sequels weren't terribly great to me, but I did enjoy the Hedgemon series, which parallels Ender's Game for a part of it. It's interesting to view the events of Ender's Game from a different perspective, and I get the feeling that it would have been interesting for the WoT series too. The problem seemed that he was trying to show it from 10 different perspectives simultaneously in his books, which just makes it exceedingly drawn out for anything to happen.
D'oh! Well, at least there might be enough space to tie up all the subplots that were started.
Any idea of the length of the three books? Are these going to be three 1000 page books, or 300 page books?
Agreed. My interest in WoT was largely due to its new ideas. Saying it is basically a derivative of Tolkien is just odd.
It just occurred to me that it would have been like if Orson Card had never finished the book Ender's Game. If instead he had started it, but then started pumping out books to deal with the various sub plots and people on the station and what happened to them. Later on he did actually write separate series for the characters, which is what (I think) Jordan should have done. Instead we have 10,000 unfinished subplots.
The parent is lying. Whatever you do, do not listen to him.
(Disclaimer: I've read the Wheel of Time series four times.
That just sounds painful. I'm with the others though, the books are far too long. He has whole books devoted to fleshing out sub-plots that don't matter and aren't going anywhere. Sure it might be a bit interesting, but I'd rather go back and deal with that huge dangling piece of the primary plot that you left 3000 pages ago in book four.
It was like he began a basic plot framework, and then decided to devote a book to each little subplot and minor character that came along. What he should have done was finish the plot, and then add in books later that fulfilled his need to recount each and every little detail.
The plan is to have files cached already on boot. With DRAM you would have to continuously power it, which would sort of defeat the point.
That and 64GB of DRAM would be insanely expensive.
Nah. You just use redundancy to ensure reliability. Lots and lots of redundancy. MD-RAID and LVM offer all that's needed to make this work -- though doing it on a large scale requires lots of elbow grease.
I agree that "Just plug in another drive" is a far cry from what you have to do with these tools, but you can make it work.
Well, good luck to them. In the long term I expect there to be a Linux distro that you can boot and add to a storage cluster (at least I really hope so). But for now organizing a syncing that kind of data set is going to be a real pita to get all of the kinks worked out.
Those are a lot of "what if" needs, so I'm guessing the answer is more along the lines of, "Amazon provides a lot of services that can be well worth the cost if you need them all."
On the other hand, if you know what you're doing, and your needs are simple, then then there could be significant cost savings. Buying a couple of these and setting up redundancy at multiple locations wouldn't be that difficult, but there are a lot of little things that just can't be done. For instance, EMC has all sorts of options for how data is distributed, options that simply aren't available on any open source package.
I'm really looking forward to the day when there is a Linux distro that you just install and select to join a storage cluster.
I would say that most of the innovation happening for the past 30 years boils down to two areas:
1. Computer and networking hardware
2. Software development
Computers began to be well organized and designed to communicate with each other in the 1970s. From there they've become faster, obtained better networking, and have significantly better storage.
The second area (software development) though is the overlooked part. People completely forget about it. Millions (billions?) of man hours have been put into designing new algorithms and new uses for hardware/software. The advances made in software are astounding, and make possible things that were never imagined in 1960.
If people are looking for where development has happened, point them to software.