Oh, I'm not going to claim that VS is the best IDE. It's my personal preference, in large part because it's the one I use at my job so I'm very comfortable with it, but I don't think I can make the claim that it's objectively better or anything, and I like other IDEs too. I was just saying VIM vs VS is a silly comparison, same as VIM vs Eclipse would be.
Visual Studio vs VIM is like an aircraft carrier vs the world's greatest compound bow. I'll grant you, it is the best goddamned bow the world has ever seen. A good bowman can take shots a sniper would be hard-pressed to make, and there is a simple joy to using such a powerful and versatile tool. And if you want, you can call it the rustiest piece of shit aircraft carrier that's ever wallowed the seas. But come on. Be real. They're hardly even the same thing.
Yeah, that's what I was saying--it's pretty unlikely that the power failure caused this, so the author should try to find the true root of the problem.
That seems very strange--the only files that should really be corrupted, unless something extremely rare and catastrophic happened, are the ones that were being written when power went out, or were cached. And even then, a flush usually flushes everything, or at least whole files at once, or areas of disk. Is the partition highly fragmented or something?
I know this doesn't do much for your question, but that kind of failure mode is almost exactly what filesystems do their damnedest to avoid. HFS+, being journaled, should be even more proof against, well, exactly what happened to you. Maybe the Linux driver is poor, but man, if you got silent data corruption on a multitude of files that weren't even being written, that's really bad and the driver should be classified "EXPERIMENTAL" at best, and certainly not compiled into distros' default kernels.
To answer your question, I don't have experience with any tools (I automate my backups, and any archival files go on a RAID volume that does a full integrity scan nightly), but once you find one, you should separate your files into two categories--"must be good", and "can be bad". The "must be good" files (serial #s, source code, etc.), you hand-check, so you know for certain that every one of them is good. It'll also motivate you to replace them now, instead of later when replacements will only get harder to come by. The "can be bad" files (music, pictures, etc.), you do the automated check on and then just delete as you run into ones that the check missed. This has the advantage of concentrating your effort into where it's useful. If you try to check all of your files, you'll just burn out before you finish. You may even want to do more advanced triaging, but you'll have to come up with the categories and criteria there. The main thing is, split this problem up.
Blame our shitty patent system. Oracle is just doing what any rational actor would do in a system where being "nice" has practically zero reward, and where anybody can shut you down and steal your money at any time. When defense is not possible, you must attack first.
That doesn't make Oracle any less shitty, and we certainly shouldn't forgive them for their actions, but they're a sociopathic institution, and yelling at them about it will have just as much effect as trying to make Ted Bundy feel guilty. It's futile. If you're looking to actually make the situation better instead of pointlessly laying blame, well, you need to fix the patent system. Anything else is less than temporary.
Well then get the shears because I'm in the herd... for this.
I'm not sure how I can support this thing while giving him the absolute minimum power in the future, it's certainly not worth getting him re-elected unless it's practically certain he can pull it off, and probable it won't happen without him, but man he's right about this one, and any help I can give to this specific endeavor, I will. His views on abortion, civil rights, and other libertarian nuttiness are unconscionable, but if there's a way to work with an enemy toward a common goal without getting too fucked over by the cooperation... well, the TSA is enough of a threat that it's worth working with an enemy to get rid of it. I'd say the same about the wiretap insanity and data sharing with other countries. I imagine Paul sees people like me the same way--an enemy, but with a common goal. Maybe we can use each other.
If he handles it well, pulls it off, and doesn't turn it into a power-grab, I'd probably be... less... skeptical of him in the future. I think there's about a 2% chance he does any one of those things, let alone all three, but I wholeheartedly agree with simply scrapping the TSA and I'm willing to hear him out on this.
Man, wouldn't it be sweet if nukes were no longer viable because they couldn't accomplish anything, instead of because they're so effective they're practically guaranteed to end civilization the next time they're used?
It depends--is there a total of 6 TB of drives that doesn't include the 3 TB drive?
Take each disk, make an LVM physical volume from it. From those physical volumes, logical volumes. You don't have to make all of them the size of your smallest drive, you just have to be careful. Say you have the following:
On your 2 TB drive, make partitions matching the drives under 1 TB.
On your 3 TB drive, make the following partitions:
1 TB: RAID-5 with #3 and #4
750 GB: RAID-5 with #2 and #5
750 GB: RAID-5 with #2 and #6
150 GB: RAID-5 with #2 and #7
150 GB: RAID-5 with #2 and #8
100 GB: RAID-5 with #2 and #9
100 GB: RAID-5 with #2 and #10
Then take those, LVM the RAIDed LVM volumes (fairly certain you can stack [traditional meaning of "stack"] as a contiguous disk, just use an easy FS like ext3, I've run into problems with stack size [programming meaning of "stack"] using XFS on LVM). You end up with 6 TB total space, and, just like normal RAID-5, you don't lose anything unless two disks from one of those groups die. That is, if a disk in 200 GB #6 dies, and a disk in the 1.5 TB #3 dies, you still haven't lost anything. Even if your 3 TB drive dies, which is clearly the worst case since it has data for every array, or the 2 TB which is nearly as bad, you'd still need to lose a second disk to lose any data, so for failure rates it should be the same as a 10-drive RAID-5 array, which isn't quite advisable although it's not murderously bad, but this isn't work and the primary motivation is probably maximizing space with a decent reliability increase, not making next to certain it never goes down. I'm sure it feels really weird, but I don't think you're actually increasing your odds of failure at all over the 10-disk-all-same-size RAID we're used to, other than not trusting older drives--and I'm not so sure those are much more likely to fail than new ones. After all, they've lasted this long, and I've had brand new drives die within weeks. But in point of fact, there's some 2-drive failures that don't take anything down, so I think overall you're doing slightly better than the 10-same-size disk case.
Now, your disks probably won't divide up as nicely, and you might end up having to either leave some space on the floor or subdivide in weirder ways or both, but with very careful partitioning (never put two stripes of the same array on the same disk), you can do this. Set all the arrays to verify weekly (mdadm can do this) and e-mail you on a failure. Don't set up an audible alarm, you're not going to lose a second disk at 3 AM (but you will wake up to fix it, and be worthless at work the next day for probably nothing) and even if you did lose another disk, you're not using RAID as a replacement for backups, right? Right?
ZFS would be really nice if it did all this complex stuff for you, but do you have enough control/is it smart enough to allow you to ensure that you get as good or better reliability? It'd be ridiculously easy to make a bad mistake in layout with the above scenario. Because overall, I agree with the title: It's just not worth all this effort so you can use that crappy 100 GB disk. Once it goes down, now you have to replace it.
They get multi-million dollar contracts because they're exceptionally talented athlete celebrities. They're at or very near the peak of athletic ability, but there's probably 10 people out there just as capable for every 1 playing the game. I doubt you'd have much trouble at all finding people willing to get a concussion at $1,000 a shot, a tiny fraction of what these players make. Their willingness to accept injury is the least valuable thing about them.
No, the most valuable thing about these people is that they're known. Both known as talented athletes because those 10 others out there who are just as capable look the same as the 1,000 others out there who seem extremely talented until you look very closely and reach the limits of their training, possibly years into their career--and known by their fans, who are ultimately the bodies that pay for premium television, good seats, etc., just so their eyeballs can be sold to advertisers, who pay again to get a nicely-packaged demographic.
Cripple isn't nice because of what it describes. Every single word we ever use to describe the condition will, over time, become a pejorative.
The concept of calling it "developmentally disabled" or whatever seems like a good idea though. It's such a stupid term that it has a high probability of replaced by something else before it gets the chance to be offensive. Although... it's already starting to be used sarcastically. Give it a decade or so, it'll have a shortened version that's exclusively offensive, and once that becomes well-known it's only a matter of time before the long version becomes offensive too due to its connotation with the shortened form. The best part is, the euphemism treadmill has been going on for the entirety of recorded history, so there's basically no chance it's not just human nature, so we'll never get to stop! Yay!
Yeah, you wouldn't want to end up like one of those fools that bought Google stock from August 2004 - Dec 2005 and sold it at literally any time that wasn't Oct 2008 - May 2009. Or even worse, one of those morons that bought it in the first month when it was under $150 a share! I bet they feel dumb now for buying stock in a company that's already successful.
Slashdot Mirror
"Ping"
"Your tits look nice today."
Replied very inappropriately!
I only work with the full version so I don't know this, but can you debug 64-bit code that way too?
If only we'd finished our ladder to Heaven first.
No, we're here, we just sensibly realize that trying to convince either side of anything is futile.
Oh, I'm not going to claim that VS is the best IDE. It's my personal preference, in large part because it's the one I use at my job so I'm very comfortable with it, but I don't think I can make the claim that it's objectively better or anything, and I like other IDEs too. I was just saying VIM vs VS is a silly comparison, same as VIM vs Eclipse would be.
GVIM runs natively on Windows, and it does so fantastically. If you're ever stuck on Windows I highly recommend it.
Visual Studio vs VIM is like an aircraft carrier vs the world's greatest compound bow. I'll grant you, it is the best goddamned bow the world has ever seen. A good bowman can take shots a sniper would be hard-pressed to make, and there is a simple joy to using such a powerful and versatile tool. And if you want, you can call it the rustiest piece of shit aircraft carrier that's ever wallowed the seas. But come on. Be real. They're hardly even the same thing.
The expression "If you call that living..." comes to mind.
Yeah, that's what I was saying--it's pretty unlikely that the power failure caused this, so the author should try to find the true root of the problem.
That seems very strange--the only files that should really be corrupted, unless something extremely rare and catastrophic happened, are the ones that were being written when power went out, or were cached. And even then, a flush usually flushes everything, or at least whole files at once, or areas of disk. Is the partition highly fragmented or something?
I know this doesn't do much for your question, but that kind of failure mode is almost exactly what filesystems do their damnedest to avoid. HFS+, being journaled, should be even more proof against, well, exactly what happened to you. Maybe the Linux driver is poor, but man, if you got silent data corruption on a multitude of files that weren't even being written, that's really bad and the driver should be classified "EXPERIMENTAL" at best, and certainly not compiled into distros' default kernels.
To answer your question, I don't have experience with any tools (I automate my backups, and any archival files go on a RAID volume that does a full integrity scan nightly), but once you find one, you should separate your files into two categories--"must be good", and "can be bad". The "must be good" files (serial #s, source code, etc.), you hand-check, so you know for certain that every one of them is good. It'll also motivate you to replace them now, instead of later when replacements will only get harder to come by. The "can be bad" files (music, pictures, etc.), you do the automated check on and then just delete as you run into ones that the check missed. This has the advantage of concentrating your effort into where it's useful. If you try to check all of your files, you'll just burn out before you finish. You may even want to do more advanced triaging, but you'll have to come up with the categories and criteria there. The main thing is, split this problem up.
Huh, the practice is even recommended by Zend. Isn't PHP great, where a closing tag is a vector for bugs?
Modicum. Modicum of truth.
Did they not put a closing tag there just to drive us insane?> Argh!
Blame our shitty patent system. Oracle is just doing what any rational actor would do in a system where being "nice" has practically zero reward, and where anybody can shut you down and steal your money at any time. When defense is not possible, you must attack first.
That doesn't make Oracle any less shitty, and we certainly shouldn't forgive them for their actions, but they're a sociopathic institution, and yelling at them about it will have just as much effect as trying to make Ted Bundy feel guilty. It's futile. If you're looking to actually make the situation better instead of pointlessly laying blame, well, you need to fix the patent system. Anything else is less than temporary.
Well then get the shears because I'm in the herd ... for this.
I'm not sure how I can support this thing while giving him the absolute minimum power in the future, it's certainly not worth getting him re-elected unless it's practically certain he can pull it off, and probable it won't happen without him, but man he's right about this one, and any help I can give to this specific endeavor, I will. His views on abortion, civil rights, and other libertarian nuttiness are unconscionable, but if there's a way to work with an enemy toward a common goal without getting too fucked over by the cooperation ... well, the TSA is enough of a threat that it's worth working with an enemy to get rid of it. I'd say the same about the wiretap insanity and data sharing with other countries. I imagine Paul sees people like me the same way--an enemy, but with a common goal. Maybe we can use each other.
If he handles it well, pulls it off, and doesn't turn it into a power-grab, I'd probably be ... less ... skeptical of him in the future. I think there's about a 2% chance he does any one of those things, let alone all three, but I wholeheartedly agree with simply scrapping the TSA and I'm willing to hear him out on this.
Man, wouldn't it be sweet if nukes were no longer viable because they couldn't accomplish anything, instead of because they're so effective they're practically guaranteed to end civilization the next time they're used?
It depends--is there a total of 6 TB of drives that doesn't include the 3 TB drive?
Take each disk, make an LVM physical volume from it. From those physical volumes, logical volumes. You don't have to make all of them the size of your smallest drive, you just have to be careful. Say you have the following:
1: 3 TB
2: 2 TB
3: 1 TB
4: 1 TB
5: 750 GB
6: 750 GB
7: 150 GB
8: 150 GB
9: 100 GB
10: 100 GB
On your 2 TB drive, make partitions matching the drives under 1 TB.
On your 3 TB drive, make the following partitions:
1 TB: RAID-5 with #3 and #4
750 GB: RAID-5 with #2 and #5
750 GB: RAID-5 with #2 and #6
150 GB: RAID-5 with #2 and #7
150 GB: RAID-5 with #2 and #8
100 GB: RAID-5 with #2 and #9
100 GB: RAID-5 with #2 and #10
You'll end up with the following volumes:
1: 2 TB
2: 1.5 TB
3: 1.5 TB
4: 300 GB
5: 300 GB
6: 200 GB
7: 200 GB
Then take those, LVM the RAIDed LVM volumes (fairly certain you can stack [traditional meaning of "stack"] as a contiguous disk, just use an easy FS like ext3, I've run into problems with stack size [programming meaning of "stack"] using XFS on LVM). You end up with 6 TB total space, and, just like normal RAID-5, you don't lose anything unless two disks from one of those groups die. That is, if a disk in 200 GB #6 dies, and a disk in the 1.5 TB #3 dies, you still haven't lost anything. Even if your 3 TB drive dies, which is clearly the worst case since it has data for every array, or the 2 TB which is nearly as bad, you'd still need to lose a second disk to lose any data, so for failure rates it should be the same as a 10-drive RAID-5 array, which isn't quite advisable although it's not murderously bad, but this isn't work and the primary motivation is probably maximizing space with a decent reliability increase, not making next to certain it never goes down. I'm sure it feels really weird, but I don't think you're actually increasing your odds of failure at all over the 10-disk-all-same-size RAID we're used to, other than not trusting older drives--and I'm not so sure those are much more likely to fail than new ones. After all, they've lasted this long, and I've had brand new drives die within weeks. But in point of fact, there's some 2-drive failures that don't take anything down, so I think overall you're doing slightly better than the 10-same-size disk case.
Now, your disks probably won't divide up as nicely, and you might end up having to either leave some space on the floor or subdivide in weirder ways or both, but with very careful partitioning (never put two stripes of the same array on the same disk), you can do this. Set all the arrays to verify weekly (mdadm can do this) and e-mail you on a failure. Don't set up an audible alarm, you're not going to lose a second disk at 3 AM (but you will wake up to fix it, and be worthless at work the next day for probably nothing) and even if you did lose another disk, you're not using RAID as a replacement for backups, right? Right?
ZFS would be really nice if it did all this complex stuff for you, but do you have enough control/is it smart enough to allow you to ensure that you get as good or better reliability? It'd be ridiculously easy to make a bad mistake in layout with the above scenario. Because overall, I agree with the title: It's just not worth all this effort so you can use that crappy 100 GB disk. Once it goes down, now you have to replace it.
If you have to ask, you can't afford it.
They get multi-million dollar contracts because they're exceptionally talented athlete celebrities. They're at or very near the peak of athletic ability, but there's probably 10 people out there just as capable for every 1 playing the game. I doubt you'd have much trouble at all finding people willing to get a concussion at $1,000 a shot, a tiny fraction of what these players make. Their willingness to accept injury is the least valuable thing about them.
No, the most valuable thing about these people is that they're known. Both known as talented athletes because those 10 others out there who are just as capable look the same as the 1,000 others out there who seem extremely talented until you look very closely and reach the limits of their training, possibly years into their career--and known by their fans, who are ultimately the bodies that pay for premium television, good seats, etc., just so their eyeballs can be sold to advertisers, who pay again to get a nicely-packaged demographic.
up in arms
I got fuckin no arms, asshole!
Cripple isn't nice because of what it describes. Every single word we ever use to describe the condition will, over time, become a pejorative.
The concept of calling it "developmentally disabled" or whatever seems like a good idea though. It's such a stupid term that it has a high probability of replaced by something else before it gets the chance to be offensive. Although ... it's already starting to be used sarcastically. Give it a decade or so, it'll have a shortened version that's exclusively offensive, and once that becomes well-known it's only a matter of time before the long version becomes offensive too due to its connotation with the shortened form. The best part is, the euphemism treadmill has been going on for the entirety of recorded history, so there's basically no chance it's not just human nature, so we'll never get to stop! Yay!
Facebook is over this way --> Facebook.
Cool. Gonna go fly the air to the grocery store, which is shopping all over the place.
Yeah, I can see how only being able to quadruple your money once would be an issue.
Yeah, you wouldn't want to end up like one of those fools that bought Google stock from August 2004 - Dec 2005 and sold it at literally any time that wasn't Oct 2008 - May 2009. Or even worse, one of those morons that bought it in the first month when it was under $150 a share! I bet they feel dumb now for buying stock in a company that's already successful.