There's a similar loop around government regulation, what's called the "revolving door". Hire people who used to be government regulators with a fat paycheck; tell existing regulators they'll earn more that way than their government job pays; use profits from unregulated activities to hire more regulators. This is how financial companies in the US cracked regulation by the SEC, food manufacturers avoid the FDA, etc.
It's hilarious how an AC thought your history lesson here was a plan for the future.
No, because modding down the bullshit is an essential part of what the user community being ignored by beta does. If you want there to be some impact from a boycott, let Dice see what happens when the moderators go away.
The Beta design team doesn't need a UX lead. It needs some cranky, low UID asshole who has complete and utter veto power over everyone else. My suggested test for whether someone is qualified is to look at their moderation history and note how much of it is bashing down the goddamn trolls. No UI redesign is going to matter one bit if you drive that crowd off.
His point was that any number of language+library stacks give such similar abstractions for everything from HTTP to database persistence, it doesn't even matter which one you pick.
Reallocated sectors indicate things are starting to go wrong with the drive, and those skyrocket starting at only 100TB of writes.. Admittedly they're busy servers, but I do have systems on SSD I've measured hitting 75TB of writes in only a year of heavy use. And while extremely heavy on writes, this test rig is pretty simple compared to the mess real world drives go through. As my parent post pointed out, there's more to TLC wear than just writes, and it's not hard at all to imagine workloads that will start hitting reallocations in a small number of years. Any amount of reallocation is scary when one potential outcome from wear is forgetting your data.
Recent reliability testing has been downright horrifying for the TLC based drives. I predict a whole lot of people buying Samsung 840 drives because they're cheap are going to regret that.
One of the patterns I've noticed with Seagate is that drive failures seem to spike when manufacturing moves. The reliable Barracuda IV models made in Singapore were replaced by shoddy ones made by newer facilities in Thailand. Then around 2009-2010 they shifted a lot more manufacturing into China, and from that period the Thailand drives were now the more reliable ones from the mature facility. A lot of the troubled 1.5TB 7200.11 models came out of that, and perhaps some of your 500GB enterprise drives too.
If you think about this in terms of individual plants being less reliable when new, that would explain why manufacturers go through cycles of good and bad. I think buying based on what's been good the previous few years is troublesome for a lot of reasons. From the perspective of the manufacturer, if a plant is above target in terms of reliability, it would be tempting to cut costs there. Similarly, it's the shoddy plants that are likely to be improved because returns are costing from there are costing too much. There's a few forces here that could revert reliability toward the mean, and if that happens buying the company that's been the best recently will give you the worst results.
At this point I try to judge each drive model individually, rather than to assume any sort of brand reliability.
If you want to compare Soylent to its true competition, look at meal replacement products from real medical research firms, not diet products. I like Alpha ENF, the vanilla flavor mixed with orange juice. If you like the EFA angle of Soylent's products, it's easy enough to pick up a bottle of that and squirt some in too.
SSDs have their own longevity problems. In the race to get prices down, some of the new models are using some pretty shady flash in their designs, with the Samsung models being the worst right now.
TLER is a marketing term used by Western Digital, so of course Seagate doesn't have it. Seagate's similar feature is called Error Recovery Control (ERC), while Hitachi calls it Command Completion Time Limit (CCTL). There's a similar set of terms for vibration limitation features that are important when you put a bunch of drives into one chassis, and those are also specific to each manufacturer.
I've found Western Digital's cheapest line of consumer drives do terrible things when hitting a failure, basically retrying forever in ways that will make a RAID go insane. But their NAS drives work fine, and I agree with Backblaze about the WD Red 3TB being one of the best drives on the market right now. Seagate's cheapest consumer drives (like the 7200.X series) have better sector error reporting firmware than the cheapest WD models, but the failure rate is high enough--and enough of the failures are controller/power level ones--that this doesn't matter much.
Mercurial is missing a few key features that make it less appropriate for solving some difficult collaboration problems, and some of those turn out to be important to people outside of Linux kernel development too. That's the technical part underneath what you're dismissing as a fanboy phenomenon.
Allowing octopus merges and making it easy to rewrite/rebase local branches are two such important features. The way those fit together into git's remote tracking branch concept is a particularly useful mental model for widely distributed development. And the way git (but not Mercurial) forces explicit branch naming and sharing gets people thinking in a way that usefully leads toward using these features for collaborative development. Mercurial vs Git; it’s all in the branches covers most of the important area usefully.
Basically, git includes some weird features that were built specifically for the style of distributed development done by the Linux kernel. But those turn out to be similarly powerful for other widespread collaborative software efforts too. These things aren't really appreciated by people until they've used git seriously for a while, and therefore they don't show up on most of these formal "which DVCS should we switch to" documents done by people still evaluating their options. That link I just referenced goes over how Google completely missed out on that in their comparison. You can't just compare the opinion of new users. The interesting thing to compare is what git is capable of on a project with some number of serious git users involved.
Once you've gotten used to things like git's remote tracking branches, good rebasing practices for code sharing, and malleable history when in tough spots, it's impossible to take Mercurial seriously for some of those jobs. Eventually Mercurial got some of the rebasing features, but by that point it had already lost quite a bit of the mind share war. They still are struggling with how the branch name model mismatches what some people want.
MAX_PATH is a Windows API limitation. You can get around it by using Unicode aware versions of some functions, but since that has limitations, too, you can't just swap to those without adding a new set of problems.
There is a lot of Windows software that suffers from this same limitations, most of them just don't talk about it. git is just taking the less troublesome of the two bad options presented by the OS. The standard workaround is to map a drive letter to some subset of the path when it grows large enough to hit this limit. As for the 80's calling, this part of the Windows code is in fact still worrying about 8.3 file names from DOS too...
I tried to punt the details here toward the references provided, but you raise a good question: why not just use the lifetime percentage exposed at attributed 202/0xCA "Percent Lifetime Remaining". There's two problems with that data.
First off, that SMART attribute hasn't been consistent since the drive was released. See M500 960GB MU03 SMART Issue as one observation about the biggest firmware change. I believe that happened after the Tech Report review. The fact that Crucial changed exposing wear data over the life of the drive is itself enough to get it booted from some companies as an immature product.
But let's say you consider that ancient history now. The other side of the complaints here is that the M500 doesn't give wear data in terms of bytes written. If you have two M500 drives that show identical wear data as measured by 202/0xCA, what does that tell you about their respective workloads? Unfortunately, it doesn't tell you anything useful for that purpose without more context. And that's a critical failure for the standard way such things are rated and evaluated now.
Intel publishes white papers for the recommended drive in TFA like DC S3500 Series RAID Workload Characterization, and that gives a lot of data about how to compare production deployments against drive specifications. I did exactly that for their earlier drives in the blog article I referenced.
There's just not quite enough data available from a Crucial M500 to do a similar analysis on it. "Erase count" is really an implementation detail specific to the drive; you can't compare those across different manufacturers. The most useful standard that aims to eliminate the workload specific aspect from lifespan ratings is JESD218. That also looks at lifetime in terms of terabytes written. There are some really fundamental detaisl that so far seem missing on Crucial's drives. You can back out write data from some of the other statistics, but without a hard published spec for such things I don't consider that very useful.
SSD vendors have some history of lying about sync writes being finished when they're actually still going on. Even Intel's early drives got that wrong, wasn't until their 3rd generation (320/710 series) that things worked correctly. Anyone burned by SSD deployments in that era, or by more recent drives that still don't worry about power loss protection, runs their own tests. To be safe here, you have to assume the drives are not being honest about sync writes.
Intel's 320, 710, DC S3500, and DC S3700 are the only inexpensive SATA plug drives I recommend nowadays, with the newer DC models being much better than the now obsolete 320/710 ones. There are more expensive card slot models like FusionIO that are also fine. Intel's "DC" drives are the safe mainstream choice here now, so other vendors have to really outperform them in some way and be cost effective to be worth consideration.
Seagate 600 Pro should work fine, just haven't gotten one of those yet. Samsung's 840 and 840 Pro don't have power protection, and their more expensive models I've considered haven't been price competitive to the Intel models yet.
The write cache on the Crucial M500 survived my power plug testing with similar properties to this article, but it doesn't have SMART data for drive wear. Can't take that one seriously for business use. I've been very happy with the figures I've seen from Intel drives on their internal lifespan tracking; see my Intel SSD lifespan for example. I'm not the only one who noticed this flaw in the M500, the Tech Report review has another complaint.
None of the cheap and easy to buy Samsung drives (840 and 840 Pro) claim any power loss protection, and they all fail this sort of test. They have enterprise models that might work, but those wouldn't fit within the budget parameters here. I find it hard to take those seriously when the 840 drive they share design features with are so terrible handling lifespan failures.
I'm not aware of any Sandisk models with that feature, but I haven't gone looking for them either.
The only drive really missing here that might have passed are the Seagate 600 Pro models. Those haven't been shipping long enough for me to recommend them yet.
Intel has a lot of SSD product lines. Some of them are pretty terrible. The DC S3500 recommended here is one of the good product lines, along with its bigger brother the DC S3700. I doubt you have either of those, because they cost quite a bit more than the ones that don't have power protection.
RAID cards like that Adaptec only work if the individual write disk caches are disabled. I publish guides on how to setup all of the caches involved in that sort of system correctly, and you have to pay attention to that on the Adaptec models; just haven't published that guide yet. On many cards disabling the drive write cache is the default, safe setting.
The problem here is that SSDs require their write cache, both to meet their published longevity and performance specs. Disabling the cache makes them much slower and very short lived. Accordingly, SSD manufacturers don't even support disabling the cache in some cases. Intel's early drives had that problem, and it meant database corruption. They sorted the problem out on drives with power loss protection starting with the 320 series, and the models since have been fine. Not sure if you can turn the write cache off on them, but with the power loss protection you never need to.
All regular drives fail this sort of test. However, if you turn their write caches off, they then pass. So that's how people deploy them for "enterprise" use--with the disk write cache disabled. Add a battery-backed RAID cache for durable write caching when needed. I even publish guides on how to setup all of the caches involved in such a setup correctly.
The problem here is that SSDs require their write cache, both to meet their published longevity and performance specs. Disabling the cache makes them much slower and very short lived. Accordingly, SSD manufacturers don't even support disabling the cache in some cases. Intel's early drives had that problem, and it meant database corruption. They sorted the problem out on drives with power loss protection, starting with the 320 series, and the models since have been fine. Not sure if you can turn the write cache off on them, but with solid power loss protection you never need to.
Samsung's 840 models don't make any claims for power loss shutdown, and even the 840 Pro models fail this sort of testing. You have to step up to their SM843 to get something appropriate for serious deployments. The main problem with those drives is price/availability. If I need another Intel DC S3500, those are relatively cheap and plentiful, and I can even find them in my local Microcenter. Samsung's enterprise drives are much harder to obtain, which makes people nervous about deploying them. Nobody wants to return to the day when you needed rare and magical blessed drives in "enterprise" storage.
Samsung doesn't claim any power loss protection even in the 840 Pro models, and as you've seen it shows in the real world. The 840 models are fast and cheap, but if you care at all about longevity they're just unacceptable. It was no surprise to find the 840 was the first to fail in the largest longevity test I know of.
Slashdot Mirror
There's a similar loop around government regulation, what's called the "revolving door". Hire people who used to be government regulators with a fat paycheck; tell existing regulators they'll earn more that way than their government job pays; use profits from unregulated activities to hire more regulators. This is how financial companies in the US cracked regulation by the SEC, food manufacturers avoid the FDA, etc.
It's hilarious how an AC thought your history lesson here was a plan for the future.
Slashdot isn't a news site, it's a debate site.
No it isn't.
No, because modding down the bullshit is an essential part of what the user community being ignored by beta does. If you want there to be some impact from a boycott, let Dice see what happens when the moderators go away.
The Beta design team doesn't need a UX lead. It needs some cranky, low UID asshole who has complete and utter veto power over everyone else. My suggested test for whether someone is qualified is to look at their moderation history and note how much of it is bashing down the goddamn trolls. No UI redesign is going to matter one bit if you drive that crowd off.
Wanting to get paid for consuming news release propaganda and sometimes crapping out some truth is what ruined blogging.
His point was that any number of language+library stacks give such similar abstractions for everything from HTTP to database persistence, it doesn't even matter which one you pick.
Reallocated sectors indicate things are starting to go wrong with the drive, and those skyrocket starting at only 100TB of writes.. Admittedly they're busy servers, but I do have systems on SSD I've measured hitting 75TB of writes in only a year of heavy use. And while extremely heavy on writes, this test rig is pretty simple compared to the mess real world drives go through. As my parent post pointed out, there's more to TLC wear than just writes, and it's not hard at all to imagine workloads that will start hitting reallocations in a small number of years. Any amount of reallocation is scary when one potential outcome from wear is forgetting your data.
Recent reliability testing has been downright horrifying for the TLC based drives. I predict a whole lot of people buying Samsung 840 drives because they're cheap are going to regret that.
One of the patterns I've noticed with Seagate is that drive failures seem to spike when manufacturing moves. The reliable Barracuda IV models made in Singapore were replaced by shoddy ones made by newer facilities in Thailand. Then around 2009-2010 they shifted a lot more manufacturing into China, and from that period the Thailand drives were now the more reliable ones from the mature facility. A lot of the troubled 1.5TB 7200.11 models came out of that, and perhaps some of your 500GB enterprise drives too.
If you think about this in terms of individual plants being less reliable when new, that would explain why manufacturers go through cycles of good and bad. I think buying based on what's been good the previous few years is troublesome for a lot of reasons. From the perspective of the manufacturer, if a plant is above target in terms of reliability, it would be tempting to cut costs there. Similarly, it's the shoddy plants that are likely to be improved because returns are costing from there are costing too much. There's a few forces here that could revert reliability toward the mean, and if that happens buying the company that's been the best recently will give you the worst results.
At this point I try to judge each drive model individually, rather than to assume any sort of brand reliability.
If you want to compare Soylent to its true competition, look at meal replacement products from real medical research firms, not diet products. I like Alpha ENF, the vanilla flavor mixed with orange juice. If you like the EFA angle of Soylent's products, it's easy enough to pick up a bottle of that and squirt some in too.
SSDs have their own longevity problems. In the race to get prices down, some of the new models are using some pretty shady flash in their designs, with the Samsung models being the worst right now.
TLER is a marketing term used by Western Digital, so of course Seagate doesn't have it. Seagate's similar feature is called Error Recovery Control (ERC), while Hitachi calls it Command Completion Time Limit (CCTL). There's a similar set of terms for vibration limitation features that are important when you put a bunch of drives into one chassis, and those are also specific to each manufacturer.
I've found Western Digital's cheapest line of consumer drives do terrible things when hitting a failure, basically retrying forever in ways that will make a RAID go insane. But their NAS drives work fine, and I agree with Backblaze about the WD Red 3TB being one of the best drives on the market right now. Seagate's cheapest consumer drives (like the 7200.X series) have better sector error reporting firmware than the cheapest WD models, but the failure rate is high enough--and enough of the failures are controller/power level ones--that this doesn't matter much.
I'm probably the wrong person to comment on this, since by your classification I'm one of the jerks.
The world is full of monkeys with precious little comprehension about the things they write let alone their theory of application
Fixed that for you. Ninety percent of everything is crud.
Mercurial is missing a few key features that make it less appropriate for solving some difficult collaboration problems, and some of those turn out to be important to people outside of Linux kernel development too. That's the technical part underneath what you're dismissing as a fanboy phenomenon.
Allowing octopus merges and making it easy to rewrite/rebase local branches are two such important features. The way those fit together into git's remote tracking branch concept is a particularly useful mental model for widely distributed development. And the way git (but not Mercurial) forces explicit branch naming and sharing gets people thinking in a way that usefully leads toward using these features for collaborative development. Mercurial vs Git; it’s all in the branches covers most of the important area usefully.
Basically, git includes some weird features that were built specifically for the style of distributed development done by the Linux kernel. But those turn out to be similarly powerful for other widespread collaborative software efforts too. These things aren't really appreciated by people until they've used git seriously for a while, and therefore they don't show up on most of these formal "which DVCS should we switch to" documents done by people still evaluating their options. That link I just referenced goes over how Google completely missed out on that in their comparison. You can't just compare the opinion of new users. The interesting thing to compare is what git is capable of on a project with some number of serious git users involved.
Once you've gotten used to things like git's remote tracking branches, good rebasing practices for code sharing, and malleable history when in tough spots, it's impossible to take Mercurial seriously for some of those jobs. Eventually Mercurial got some of the rebasing features, but by that point it had already lost quite a bit of the mind share war. They still are struggling with how the branch name model mismatches what some people want.
MAX_PATH is a Windows API limitation. You can get around it by using Unicode aware versions of some functions, but since that has limitations, too, you can't just swap to those without adding a new set of problems.
There is a lot of Windows software that suffers from this same limitations, most of them just don't talk about it. git is just taking the less troublesome of the two bad options presented by the OS. The standard workaround is to map a drive letter to some subset of the path when it grows large enough to hit this limit. As for the 80's calling, this part of the Windows code is in fact still worrying about 8.3 file names from DOS too...
I tried to punt the details here toward the references provided, but you raise a good question: why not just use the lifetime percentage exposed at attributed 202/0xCA "Percent Lifetime Remaining". There's two problems with that data.
First off, that SMART attribute hasn't been consistent since the drive was released. See M500 960GB MU03 SMART Issue as one observation about the biggest firmware change. I believe that happened after the Tech Report review. The fact that Crucial changed exposing wear data over the life of the drive is itself enough to get it booted from some companies as an immature product.
But let's say you consider that ancient history now. The other side of the complaints here is that the M500 doesn't give wear data in terms of bytes written. If you have two M500 drives that show identical wear data as measured by 202/0xCA, what does that tell you about their respective workloads? Unfortunately, it doesn't tell you anything useful for that purpose without more context. And that's a critical failure for the standard way such things are rated and evaluated now.
Intel publishes white papers for the recommended drive in TFA like DC S3500 Series RAID Workload Characterization, and that gives a lot of data about how to compare production deployments against drive specifications. I did exactly that for their earlier drives in the blog article I referenced.
There's just not quite enough data available from a Crucial M500 to do a similar analysis on it. "Erase count" is really an implementation detail specific to the drive; you can't compare those across different manufacturers. The most useful standard that aims to eliminate the workload specific aspect from lifespan ratings is JESD218. That also looks at lifetime in terms of terabytes written. There are some really fundamental detaisl that so far seem missing on Crucial's drives. You can back out write data from some of the other statistics, but without a hard published spec for such things I don't consider that very useful.
SSD vendors have some history of lying about sync writes being finished when they're actually still going on. Even Intel's early drives got that wrong, wasn't until their 3rd generation (320/710 series) that things worked correctly. Anyone burned by SSD deployments in that era, or by more recent drives that still don't worry about power loss protection, runs their own tests. To be safe here, you have to assume the drives are not being honest about sync writes.
Intel's 320, 710, DC S3500, and DC S3700 are the only inexpensive SATA plug drives I recommend nowadays, with the newer DC models being much better than the now obsolete 320/710 ones. There are more expensive card slot models like FusionIO that are also fine. Intel's "DC" drives are the safe mainstream choice here now, so other vendors have to really outperform them in some way and be cost effective to be worth consideration.
Seagate 600 Pro should work fine, just haven't gotten one of those yet. Samsung's 840 and 840 Pro don't have power protection, and their more expensive models I've considered haven't been price competitive to the Intel models yet.
The write cache on the Crucial M500 survived my power plug testing with similar properties to this article, but it doesn't have SMART data for drive wear. Can't take that one seriously for business use. I've been very happy with the figures I've seen from Intel drives on their internal lifespan tracking; see my Intel SSD lifespan for example. I'm not the only one who noticed this flaw in the M500, the Tech Report review has another complaint.
None of the cheap and easy to buy Samsung drives (840 and 840 Pro) claim any power loss protection, and they all fail this sort of test. They have enterprise models that might work, but those wouldn't fit within the budget parameters here. I find it hard to take those seriously when the 840 drive they share design features with are so terrible handling lifespan failures.
I'm not aware of any Sandisk models with that feature, but I haven't gone looking for them either.
The only drive really missing here that might have passed are the Seagate 600 Pro models. Those haven't been shipping long enough for me to recommend them yet.
Intel has a lot of SSD product lines. Some of them are pretty terrible. The DC S3500 recommended here is one of the good product lines, along with its bigger brother the DC S3700. I doubt you have either of those, because they cost quite a bit more than the ones that don't have power protection.
RAID cards like that Adaptec only work if the individual write disk caches are disabled. I publish guides on how to setup all of the caches involved in that sort of system correctly, and you have to pay attention to that on the Adaptec models; just haven't published that guide yet. On many cards disabling the drive write cache is the default, safe setting.
The problem here is that SSDs require their write cache, both to meet their published longevity and performance specs. Disabling the cache makes them much slower and very short lived. Accordingly, SSD manufacturers don't even support disabling the cache in some cases. Intel's early drives had that problem, and it meant database corruption. They sorted the problem out on drives with power loss protection starting with the 320 series, and the models since have been fine. Not sure if you can turn the write cache off on them, but with the power loss protection you never need to.
All regular drives fail this sort of test. However, if you turn their write caches off, they then pass. So that's how people deploy them for "enterprise" use--with the disk write cache disabled. Add a battery-backed RAID cache for durable write caching when needed. I even publish guides on how to setup all of the caches involved in such a setup correctly.
The problem here is that SSDs require their write cache, both to meet their published longevity and performance specs. Disabling the cache makes them much slower and very short lived. Accordingly, SSD manufacturers don't even support disabling the cache in some cases. Intel's early drives had that problem, and it meant database corruption. They sorted the problem out on drives with power loss protection, starting with the 320 series, and the models since have been fine. Not sure if you can turn the write cache off on them, but with solid power loss protection you never need to.
Samsung's 840 models don't make any claims for power loss shutdown, and even the 840 Pro models fail this sort of testing. You have to step up to their SM843 to get something appropriate for serious deployments. The main problem with those drives is price/availability. If I need another Intel DC S3500, those are relatively cheap and plentiful, and I can even find them in my local Microcenter. Samsung's enterprise drives are much harder to obtain, which makes people nervous about deploying them. Nobody wants to return to the day when you needed rare and magical blessed drives in "enterprise" storage.
Samsung doesn't claim any power loss protection even in the 840 Pro models, and as you've seen it shows in the real world. The 840 models are fast and cheap, but if you care at all about longevity they're just unacceptable. It was no surprise to find the 840 was the first to fail in the largest longevity test I know of.