A typical RAID implementation writes stripes at a time, by issuing a series of writes to each drive. If your disks have the same geometry, then each write will be at the same physical location on each drive and so complete in almost exactly the same time. If they are not, then the different disks will be moving their heads at different times. The RAID controller (hardware or software) will then be bottlenecked by the slowest drive. To make things worse, the slowest drive can be different for each write. One write may require moving the head sideways on one disk, the next may require moving the head sideways on the other. In both cases, you are limited by the worst-case performance for the disk. The same is true for reads on RAID-5, but not RAID-1, which can just use the result for whichever disk returns first.
Is it worth keeping a spare for the sole purpose of having the same model available in the event of a failure when you can get a newer and faster drive in the future? Is the difference in performance between modern SATA drives so significant? This is the point I am trying to make.
And what allot of people don't realize is if you build a RAID array and a drive fails can you replace the drive with the exact make and model? Raids work best when every disk in the array is the same model and revision.
Do you have any evidence for this claim?
There is no need to go throguh the extra effort to use the same model of disks throughout an array or even keep a spare solely so you can have the same model in the event of a failure.
making reads quicker (mirrored disks, and sometimes, but not necessarily, RAID5/6), though you have a performance penalty for writes
My software RAID6 arrays have higher read and write speed than a single drive. Read speed is limited by bus bandwidth, and write speed is limited by seek time and CPU time.
Wrong. You need to buy at least two of these controllers, at the same time, or else when your "real" RAID card dies (and they do), you'll lose all your data unless you can find an identical card (you may even need the exact same firmware version).
Some vendors explicitly advertise disk format compatibility with past and future controller models. RAID is not a substitute for backup.
I'm not sure why you wouldn't be able to use different drive models in the same array on a hardware RAID implementation. And there's no reason why a hardware RAID implementation can't use all the space available on the drives, even though some implementations may not.
OS X updates break software... Early OS X 10.5 patches broke some older games and OS X 10.5.7 broke 3D acceleration for VMware Fusion on ATI cards.
And classic Mac OS software won't work at all on modern Intel Macs with OS X - only Carbonized software can. On the other hand, lots of Win32 software from the 90s still works on modern Windows...
So your problem is not that Apple doesn't contribute to open source projects, or share, but that they don't share the bits you particularly like?
I never said that I have a problem with Apple or their contribution(s) to open source - just that the parts that differentiate OS X from other Unix(like) systems are not open source.
I don't really care if the source is open or not; if OS X was completely closed source, it wouldn't make a difference to me.
It is only a small part of the Apple Mac software that is non-Free and you could even run Darwin which is Free. The bulk of the software on any Apple Mac is GPL.
Darwin without the closed soruce bits is just another Unixlike (or UNIX) operating system, and not a particularly good/useful one. Without the closed-source window server and applications, there's really no reason to use Darwin.
Valid foreign SIM cards would work, providing the foreign carrier has a roaming agreement in place and people had unlocked devices... at least until the local network operator caught on.
Again with the "but its better by 3%", my point is that once it looks fine, and it fits on a C D, the question of quality and size are done.
Who uses CDs for video distribution?
"looks fine" is entirely subjective, but in subjective tests, well-encoded H.264 looks better than well-encoded MPEG-4 Part 2. Why settle for "looks fine" when we can get "indistinguishable from the source" at the same file size? If everyone settled for "good enough" a decade ago, we'd be stuck with 128 kbit MP3s and MPEG-2.
You shouldn't believe that size and quality are all that matters. What about computational complexity?
Not a problem - this is 2009. It's worth spending more time encoding if there's a significant benefit in file sizes and/or picture quality.
Unless Theora is close to H.264 or even VC-1, I don't think it's acceptable. I don't want to use mediocre technlogy just because it is open source and patent-unencumbered.
Why is anyone worried about the quality of videos your going to watch in your browser? The vast majority of those videos are not going to be interesting enough to want to see them in full HD glory.
That's a bullshit assumption. I watch streaming video on my TV from sites like Hulu and YouTube, and the higher quality video, the better.
Also, hackability can be a downside. If it's easy to replace the bootloader or kernel with a modified and unsigned one from a cold boot, it doesn't matter if the software is secure; attackers can secretly install their modified kernel / bootloader on a device while the owner isn't looking.
On devices that perform signature checking of firmware updates, this is less of an issue.
BlackBerries support content encryption, and Windows Mobile supports encrypting the entire user editable partition. I think the iPhone 3G S may also support device encryption as well. All support some sort of private channels of communication (SSL with http, imap, smtp, along with VPNs.)
Well, processing requests in separate processes has the advantage that a crashing application module has no chance of bringing the server down. You may call it antiquated when you have found a method to guarantee that software never crashes. This will also give you the right to call the Halting theorem antiquated...
And yet all those web servers that don't use forking are stable enough that they haven't been rewritten...
What are you talking about? There is settings in IIS regarding max connections as well and presumably would be effected in the same manner if these are set too low. This has nothing to do with fork (process) or non forked (lightweight process) method of serving.... or are you telling me that IIS is currently completely on Fiber level instead of their "Threads" ?
The problem is a combination of a single client being able to reach the maximum connection limit in the default configuration, and this is more likely on servers that use a forking model (becuase they must set lower limits to avoid exhausting resources.) It does not mean that servers that use a forking process model are inherently vulnerable, and I never said that it did.
Servers found to be invulnerable to this specific attack might have a default configuration that sets the session limit high and limits the amount of requests from a single host, or they might handle idle connections differently when the amount of idle connections is sufficiently high.
Just tested on www.microsoft.com and I sat there in the header negotiating part for over 3 minutes before the pipe broke on remote end (I didn't do anything.) Slight change in that slowloris makes IIS* vulnerable too.
Keeping idle sessions open on the server for some period of time is not the flaw. The flaw is that some servers (in default configurations) only handles so many of these idle sessions open before reaching a limit and refusing to accept any new sessions, and that this limit is sufficiently low, and that one client can easily reach this limit.
This particularly affects web servers that fork separate processes to service multiple requests at the same time - and this includes the default configuration of Apache 2 on many systems. (Last I checked, PHP's Apache module implementation only works well with the forking proces model because of thread safety issues.)
IIS does not use this antiquated process model - it's threaded. Apache can be configured to use a threaded model too. Unfortunately, thread-unsafe code is still common.
Slashdot Mirror
Is it worth keeping a spare for the sole purpose of having the same model available in the event of a failure when you can get a newer and faster drive in the future? Is the difference in performance between modern SATA drives so significant?
This is the point I am trying to make.
If the controller screws up and writes crap to your raid, your data is dead. Not sure if your expectations are realistic.
Try a drobo instead.
So instead, you rely ony a proprietary *external* RAID system.
Do you have any evidence for this claim?
There is no need to go throguh the extra effort to use the same model of disks throughout an array or even keep a spare solely so you can have the same model in the event of a failure.
My software RAID6 arrays have higher read and write speed than a single drive. Read speed is limited by bus bandwidth, and write speed is limited by seek time and CPU time.
Parallel SCSI is obsolete. New systems come with SAS controllers, and (most?) SAS (Serial Attached SCSI) controllers support SATA drives as well.
Some vendors explicitly advertise disk format compatibility with past and future controller models. RAID is not a substitute for backup.
I'm not sure why you wouldn't be able to use different drive models in the same array on a hardware RAID implementation. And there's no reason why a hardware RAID implementation can't use all the space available on the drives, even though some implementations may not.
This is not a hardware RAID controller; it's a SATA controller with a software RAID implementation.
Western Digital "RAID" drives feature Time-Limited Error Recovery, and it is a user adjustable setting on many WD consumer drives via a DOS utility.
Never heard of a mass exploit, but I've seen a few Linux systems with rootkits. Always unpatched at the time of infection.
Code Red and Nimda infected systems using already patched vulnerabilities.
Bullshit. What exactly is all this about? And this?
What do you think jailbreaking is? Older firmware could even do it over the Web.
A while back, there was even a bug that let anyone bypass the lock screen (and the password).
OS X updates break software... Early OS X 10.5 patches broke some older games and OS X 10.5.7 broke 3D acceleration for VMware Fusion on ATI cards.
And classic Mac OS software won't work at all on modern Intel Macs with OS X - only Carbonized software can. On the other hand, lots of Win32 software from the 90s still works on modern Windows...
I never said that I have a problem with Apple or their contribution(s) to open source - just that the parts that differentiate OS X from other Unix(like) systems are not open source.
I don't really care if the source is open or not; if OS X was completely closed source, it wouldn't make a difference to me.
Darwin without the closed soruce bits is just another Unixlike (or UNIX) operating system, and not a particularly good/useful one. Without the closed-source window server and applications, there's really no reason to use Darwin.
Valid foreign SIM cards would work, providing the foreign carrier has a roaming agreement in place and people had unlocked devices... at least until the local network operator caught on.
Bullshit. There is no evidence showing that Theora is better than H.264.
Who uses CDs for video distribution?
"looks fine" is entirely subjective, but in subjective tests, well-encoded H.264 looks better than well-encoded MPEG-4 Part 2. Why settle for "looks fine" when we can get "indistinguishable from the source" at the same file size? If everyone settled for "good enough" a decade ago, we'd be stuck with 128 kbit MP3s and MPEG-2.
Not a problem - this is 2009. It's worth spending more time encoding if there's a significant benefit in file sizes and/or picture quality.
What are you talking about?
By using H.264 instead of MPEG-4 Part 2, you can have equivalent quality with smaller files.
The situation you describe isn't what's actually happening. Theora isn't close to H.264.
Unless Theora is close to H.264 or even VC-1, I don't think it's acceptable. I don't want to use mediocre technlogy just because it is open source and patent-unencumbered.
That's a bullshit assumption. I watch streaming video on my TV from sites like Hulu and YouTube, and the higher quality video, the better.
Also, hackability can be a downside. If it's easy to replace the bootloader or kernel with a modified and unsigned one from a cold boot, it doesn't matter if the software is secure; attackers can secretly install their modified kernel / bootloader on a device while the owner isn't looking.
On devices that perform signature checking of firmware updates, this is less of an issue.
BlackBerries support content encryption, and Windows Mobile supports encrypting the entire user editable partition. I think the iPhone 3G S may also support device encryption as well. All support some sort of private channels of communication (SSL with http, imap, smtp, along with VPNs.)
And yet all those web servers that don't use forking are stable enough that they haven't been rewritten...
The problem is a combination of a single client being able to reach the maximum connection limit in the default configuration, and this is more likely on servers that use a forking model (becuase they must set lower limits to avoid exhausting resources.) It does not mean that servers that use a forking process model are inherently vulnerable, and I never said that it did.
Servers found to be invulnerable to this specific attack might have a default configuration that sets the session limit high and limits the amount of requests from a single host, or they might handle idle connections differently when the amount of idle connections is sufficiently high.
Keeping idle sessions open on the server for some period of time is not the flaw. The flaw is that some servers (in default configurations) only handles so many of these idle sessions open before reaching a limit and refusing to accept any new sessions, and that this limit is sufficiently low, and that one client can easily reach this limit.
This particularly affects web servers that fork separate processes to service multiple requests at the same time - and this includes the default configuration of Apache 2 on many systems. (Last I checked, PHP's Apache module implementation only works well with the forking proces model because of thread safety issues.)
IIS does not use this antiquated process model - it's threaded. Apache can be configured to use a threaded model too. Unfortunately, thread-unsafe code is still common.