UI is important...
detented knobs, trump push buttons ALWYAYS.
Impedence and other characteristics of available probes.. determenines what you can use the scope for..
On a DSO, see how fast you can get "to" a part of a single waveform... This it the part you are going to have to play with, every one does it different.
I haven't checked out software RAID on Linux since '06. Made some desperate pleas to the Kernel mailing list, but could not take part as an employee from Maxtor (GPL, lawyers, patents, "oh my")...
Its the right strategy, will have to go back and play with it. However, it should be an activity that is always running in the back ground without requiring an Admin or cron job to fire it off...
I worked at Maxtor up till 2006, and had the privilege of being able to play with several raid controllers, and that coincidently is how I got started with Linux at home (software RAID).
At the time, and mind you I only had 160 GB and 250 GB drives to play with, I build a number of raid-5 arrays up to 2 TB.
When people think about RAID failure, they generally think about a hardware failure - a sector that can't be read etc. That is only the "obvious" problems. Even under ideal conditions, the 1e15 - 1e17 error rates published by the disk drive vendors also includes data errors that ARE NOT detected in hardware. It does not take a sector read failure to generate a data miscompare.
What I found back in '06, is that with a 2TB Raid5 made up of 8 drives, there was about a 10% probability of a RAID data failure every time the raid array was read, sector, by sector for the entire 2TB span. That implies that in the event of a real disk failure, there was about a 10% probability that the rebuild would fail because of an otherwise undetected data read error.
I am not sure where state of the art is with Linux Software RAID, and perhaps the "scrub" operation mentioned above does the trick, but the biggest failing in RAID systems I have used, is that when a data error occurs, the algorithms don't/didn't calculate the missing block, and write it back to the failing device giving it a chance to push off the sector in error.
Most disk drives can "heal" with most of the common problems in a RAID system. Whats missing is back ground grooming that deals with a missing data slice, and gives the device the chance to recover from it, while alerting the admin that a problem was "handled".
Its not the 3%/year hard disk failure we should be worried about - its corrected error rate. 1e15 is very unforgiving when you are talking about terabytes... As long as RAID doesn't do the "right thing" and try to recapture the missing data, RAID-5 is in trouble.
Funny, just got in from a weekend of self imposed computer exile, read here on slash, what I discovered last week.
In my case, my installer, in addition to installing the core application, installed a service. Found I had a need to respond to some normal, globally broadcase win messages, and "do" things in responce to them that normally required admin privilege.
What I found/discovered, is that my service could hang around waiting for an interactive user to log-in, get copy the security tokens for any number of processes that ALWAYS run when a user logs in, and then and again from the service, launch my choice of executable code with the same credentials as the user (and in their desktop), but with all the privilege of trusted system service.
As all it takes is the one UAC prompt at the time of installation of the service (which users click almost like Pavlov's dog responded to a bell), I do see this as a glaring security hole that I hope (as a developer), is never "fixed".
I have finally found a way to be able to deploy on Vista ALMOST as flexibly as I can deploy on XP.
So in the end, I strongly agree all microsoft did with UAC is to screw honest 3rd party developers, and find a way to blame users for all of Microsoft's security issues.
Brilliant bit of humor. Then my laughter turned to humiliation as I realized that I was just a "sophisticated" tool being used by another kind of monkey.
Slashdot Mirror
UI is important... detented knobs, trump push buttons ALWYAYS. Impedence and other characteristics of available probes.. determenines what you can use the scope for.. On a DSO, see how fast you can get "to" a part of a single waveform... This it the part you are going to have to play with, every one does it different.
I haven't checked out software RAID on Linux since '06. Made some desperate pleas to the Kernel mailing list, but could not take part as an employee from Maxtor (GPL, lawyers, patents, "oh my")... Its the right strategy, will have to go back and play with it. However, it should be an activity that is always running in the back ground without requiring an Admin or cron job to fire it off...
I worked at Maxtor up till 2006, and had the privilege of being able to play with several raid controllers, and that coincidently is how I got started with Linux at home (software RAID). At the time, and mind you I only had 160 GB and 250 GB drives to play with, I build a number of raid-5 arrays up to 2 TB. When people think about RAID failure, they generally think about a hardware failure - a sector that can't be read etc. That is only the "obvious" problems. Even under ideal conditions, the 1e15 - 1e17 error rates published by the disk drive vendors also includes data errors that ARE NOT detected in hardware. It does not take a sector read failure to generate a data miscompare. What I found back in '06, is that with a 2TB Raid5 made up of 8 drives, there was about a 10% probability of a RAID data failure every time the raid array was read, sector, by sector for the entire 2TB span. That implies that in the event of a real disk failure, there was about a 10% probability that the rebuild would fail because of an otherwise undetected data read error. I am not sure where state of the art is with Linux Software RAID, and perhaps the "scrub" operation mentioned above does the trick, but the biggest failing in RAID systems I have used, is that when a data error occurs, the algorithms don't/didn't calculate the missing block, and write it back to the failing device giving it a chance to push off the sector in error. Most disk drives can "heal" with most of the common problems in a RAID system. Whats missing is back ground grooming that deals with a missing data slice, and gives the device the chance to recover from it, while alerting the admin that a problem was "handled". Its not the 3%/year hard disk failure we should be worried about - its corrected error rate. 1e15 is very unforgiving when you are talking about terabytes... As long as RAID doesn't do the "right thing" and try to recapture the missing data, RAID-5 is in trouble.
Funny, just got in from a weekend of self imposed computer exile, read here on slash, what I discovered last week. In my case, my installer, in addition to installing the core application, installed a service. Found I had a need to respond to some normal, globally broadcase win messages, and "do" things in responce to them that normally required admin privilege. What I found/discovered, is that my service could hang around waiting for an interactive user to log-in, get copy the security tokens for any number of processes that ALWAYS run when a user logs in, and then and again from the service, launch my choice of executable code with the same credentials as the user (and in their desktop), but with all the privilege of trusted system service. As all it takes is the one UAC prompt at the time of installation of the service (which users click almost like Pavlov's dog responded to a bell), I do see this as a glaring security hole that I hope (as a developer), is never "fixed". I have finally found a way to be able to deploy on Vista ALMOST as flexibly as I can deploy on XP. So in the end, I strongly agree all microsoft did with UAC is to screw honest 3rd party developers, and find a way to blame users for all of Microsoft's security issues.
Brilliant bit of humor. Then my laughter turned to humiliation as I realized that I was just a "sophisticated" tool being used by another kind of monkey.