SSDs are coming down every day - this would be the *next* step past SSDs. People want SSDs because it makes things faster -the same thing will (well, could) happen with this technology.
Everyone says the "Good enoughh for average joe" line every year, about every new technology.... I've tried to use Average Joe's computer often - it usually sucks.
I'd agree - buy enough ram, have a good caching mechanism, and you shouldnt' need all this new quasi-RAM like stuff - but it's semsible that at some point we can leverage more layers of storage with decreased latency and increased speed into our computing models, things will get faster and better.
Certainly "everything" won't be much faster - but we're always after faster storage. I/O is a very common bottleneck. Sticking everything in RAM will make a big difference to a multi-use computer.
IT really depends on the use-case - given enough ram, and a good caching algorithm, and a simple use-case, maybe it won't help once the cache is primed (say serving static content from a fast webserver). Everything ends up in RAM anyway.
But running a system from a fast SSD, or even from a ramdisk, as you say, leads to significant improvements in usability for general-purpose-ADHD-computer use. Apps load instantly.
To go back to the SSD example - more and more people are finding an SSD for a system drive makes things significantly faster, and ram-backed drives DO make databases much faster.
Sure, it won't make the network faster - and if everyone actually bought *enough* ram for the task at hand, caching would take care of it, but for some reason, you know, most poeple don't.
And the low priority placed on adding that feature mirrors the fact that reducing filesystem size is just not a commonly needed feature. If you really need to do it - there are other ways to get there.
There is a reason they called it "send/receive" and not "backup/restore" - the zfs team have been quite adamant that these features were not intended as an solution. That's what backup software is for.
I like git to - but in the end, it's just easy branching and merging. The same development methodology can (and should) be used in many situations with those. With git, it just comes naturally.
(each developers work is on a branch, and merged back into the appropriate target branch when they deem it ready by the appropriate manager.
Why not two drives....your performance drive, OS, shared libraries, commonly accessed software and files on super fast SSD.
Data libraries, video, photos, etc, on cheap hard disk storage.
One could also throw in the idea of SSD as cache like ZFS can incorporate now - so your working data-set ends up in SSD. The speed advantage of SSD (once the cache is primed) and the cheap value for storage.
The PS3 disables one (the GPU) out of six cores - the other five being very fast, and useable.
The very reason labs all over were building small clusters of PS3's was because, dollar for dollar, it provided a much cheaper alternative than any other solution.
They probably didn't expect people to buy them en-masse to build huge clusters - that's a losing proposition for sony, as PS3's are sold below cost as a loss-leader assuming they will make up the money on game sales.
No - the PS3 uses the Cell processor architecture, and even with the GPU unit disabled, they et 6 out of 7 processors operative (or is it 5 out of 6, I forget). It's not raw GPU performance, but it's fantastic number-crunching performance and cheap. The libraries exists to make efficient use of these - it's nothing like using a VM.
And remember, they're sold as a loss leader, subsidized by game revenue - try to get the same power (MIPS and power consumption) in the same sized package for $300 - you won't find it.
The significant point is really just the cost savings - the PS3 is subsidized by game sales, so if you are buying it for raw computing power, it's a good deal cheaper than anything else.
Good encryption practices can make this type of thing useless - but, having had to reverse engineer passwords on all kinds of systems before, a *lot* of people don't follow best practices.
It's natural for a computer crimes division to have a cluster to crack passwords, and good of them to be open minded enough to seek slightly weird ways to leverage technology to do it.
Nothing groundbreaking though, for sure. The giant arrays of god-knows-what the NSA likely has likely make this look like a grain of sand on a beach the size of the moon.
While I agree on the control issue - and I think product tying is an anti-competitive practice in general, and should be discouraged legally (ie: Use only brand X oil in brand Y car or void your warrantee...)
I think there is a special case when the hardware and software are designed by the same entity to work together as a product. To state that this is always illegal, and everyone always has the right to take software separate from hardware would be over generalizing.
The judge and court precedent quite clearly disagree with you.
I'm fine with someone buying a copy of OS X and installing it on a machine of their choice.
This wasn't that. This was someone buying OS X, installing it on a machine, modifying it, then modifying it (creating a derived work) and installing it on a second non-apple machine machine (against the license terms in both the type and number of machines). Then installing MORE of those copies on other machines and selling them to people - and throwing in an original boxed copy of OSX to make it all better.
I'm with Apple on this one - they aren't going after hobbyists. They're going after a commercial enterprise that's trying to piggyback on their work - which is a hardware/software combination.
Re:10 years ago, they had the same problem
on
The NoSQL Ecosystem
·
· Score: 1
Right - but the solution to your problem wasn't within the RDBMS itself - it was outside that context, and your apps had to be aware of that abstraction.
I think it's a misunderstanding of context. He's not saying that it's wrong to serve policy information over DNS - but that it's wrong to have DNS making policy decisions as to what data to return.
It's anarchy.... actually. Unless they are preventing you from using other nameservers, you are only using theirs for convenience, and if you don't like what theirs do, you can use another one. As long as that avenue is open, there is no issue.
If they *prevented* you from using any others (this is where net neutrality could com into play) then it's a problem.
IT's not a problem per-se - but everyone running a caching DNS server on their PC, because they can't trust the ISP, while seemingly beneficial now, has problems in theory down the road. The point of an ISP having a caching nameserver is so that queries get cached closer to home, and for a larger segment of the network. If *every* end client had their own full caching nameserver, rather than relying on a heirarchy, we'd have a tragedy of the commons, and the load on the authoritative servers would go way, way up.
If network operators stuck to not interfering with DNS, and used it as intended, people wouldn't see the need to work around (and potentially, eventually, invalidate) the model.
Whether a star can decay into a black-hole is separate from whether a black-hole can exist the same size as the star - it just started out as something bigger.
They address that in the article - when you do the math, the likelyhood of having a hash collision in SHA256, given a zetabyte filesystem with 128KB blocks is still orders of magnitude less likely than the known rate of data loss due to block level hardware failure.
Slashdot Mirror
SSDs are coming down every day - this would be the *next* step past SSDs. People want SSDs because it makes things faster -the same thing will (well, could) happen with this technology.
Everyone says the "Good enoughh for average joe" line every year, about every new technology.... I've tried to use Average Joe's computer often - it usually sucks.
I'd agree - buy enough ram, have a good caching mechanism, and you shouldnt' need all this new quasi-RAM like stuff - but it's semsible that at some point we can leverage more layers of storage with decreased latency and increased speed into our computing models, things will get faster and better.
Nonsense.
Certainly "everything" won't be much faster - but we're always after faster storage. I/O is a very common bottleneck. Sticking everything in RAM will make a big difference to a multi-use computer.
IT really depends on the use-case - given enough ram, and a good caching algorithm, and a simple use-case, maybe it won't help once the cache is primed (say serving static content from a fast webserver). Everything ends up in RAM anyway.
But running a system from a fast SSD, or even from a ramdisk, as you say, leads to significant improvements in usability for general-purpose-ADHD-computer use. Apps load instantly.
To go back to the SSD example - more and more people are finding an SSD for a system drive makes things significantly faster, and ram-backed drives DO make databases much faster.
Sure, it won't make the network faster - and if everyone actually bought *enough* ram for the task at hand, caching would take care of it, but for some reason, you know, most poeple don't.
And the low priority placed on adding that feature mirrors the fact that reducing filesystem size is just not a commonly needed feature. If you really need to do it - there are other ways to get there.
There is a reason they called it "send/receive" and not "backup/restore" - the zfs team have been quite adamant that these features were not intended as an solution. That's what backup software is for.
Or you could have ZFS where you don't even need to resize.. it just happens.
And you still have block device representations if you want them, along with all the other benefits of zfs.
I like git to - but in the end, it's just easy branching and merging. The same development methodology can (and should) be used in many situations with those. With git, it just comes naturally.
(each developers work is on a branch, and merged back into the appropriate target branch when they deem it ready by the appropriate manager.
Why not two drives....your performance drive, OS, shared libraries, commonly accessed software and files on super fast SSD.
Data libraries, video, photos, etc, on cheap hard disk storage.
One could also throw in the idea of SSD as cache like ZFS can incorporate now - so your working data-set ends up in SSD. The speed advantage of SSD (once the cache is primed) and the cheap value for storage.
The PS3 disables one (the GPU) out of six cores - the other five being very fast, and useable.
The very reason labs all over were building small clusters of PS3's was because, dollar for dollar, it provided a much cheaper alternative than any other solution.
They left it in as a hobbyist thing.
They probably didn't expect people to buy them en-masse to build huge clusters - that's a losing proposition for sony, as PS3's are sold below cost as a loss-leader assuming they will make up the money on game sales.
Storage is cheap - they may be rate-limited, but you can also pre-compute them. Lots and lots and lots of them.
No - the PS3 uses the Cell processor architecture, and even with the GPU unit disabled, they et 6 out of 7 processors operative (or is it 5 out of 6, I forget). It's not raw GPU performance, but it's fantastic number-crunching performance and cheap. The libraries exists to make efficient use of these - it's nothing like using a VM.
And remember, they're sold as a loss leader, subsidized by game revenue - try to get the same power (MIPS and power consumption) in the same sized package for $300 - you won't find it.
The significant point is really just the cost savings - the PS3 is subsidized by game sales, so if you are buying it for raw computing power, it's a good deal cheaper than anything else.
Good encryption practices can make this type of thing useless - but, having had to reverse engineer passwords on all kinds of systems before, a *lot* of people don't follow best practices.
It's natural for a computer crimes division to have a cluster to crack passwords, and good of them to be open minded enough to seek slightly weird ways to leverage technology to do it.
Nothing groundbreaking though, for sure. The giant arrays of god-knows-what the NSA likely has likely make this look like a grain of sand on a beach the size of the moon.
While I agree on the control issue - and I think product tying is an anti-competitive practice in general, and should be discouraged legally (ie: Use only brand X oil in brand Y car or void your warrantee...)
I think there is a special case when the hardware and software are designed by the same entity to work together as a product. To state that this is always illegal, and everyone always has the right to take software separate from hardware would be over generalizing.
The judge and court precedent quite clearly disagree with you.
I'm fine with someone buying a copy of OS X and installing it on a machine of their choice.
This wasn't that. This was someone buying OS X, installing it on a machine, modifying it, then modifying it (creating a derived work) and installing it on a second non-apple machine machine (against the license terms in both the type and number of machines). Then installing MORE of those copies on other machines and selling them to people - and throwing in an original boxed copy of OSX to make it all better.
I'm with Apple on this one - they aren't going after hobbyists. They're going after a commercial enterprise that's trying to piggyback on their work - which is a hardware/software combination.
Right - but the solution to your problem wasn't within the RDBMS itself - it was outside that context, and your apps had to be aware of that abstraction.
The reason you can't just keep throwing more boxes at it boils down to CAP -
Consitency, Availability, and Partition Toleranace.
In designing any distributed system, you can only get two out of three.
http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
Psychologically better and physically better.
Exercise is good, period. Whether you lose weight or not, you will be healthier, mentally and physically.
I think it's a misunderstanding of context. He's not saying that it's wrong to serve policy information over DNS - but that it's wrong to have DNS making policy decisions as to what data to return.
Yes - as long as the routes are relatively stable.
It's anarchy.... actually. Unless they are preventing you from using other nameservers, you are only using theirs for convenience, and if you don't like what theirs do, you can use another one. As long as that avenue is open, there is no issue.
If they *prevented* you from using any others (this is where net neutrality could com into play) then it's a problem.
IT's not a problem per-se - but everyone running a caching DNS server on their PC, because they can't trust the ISP, while seemingly beneficial now, has problems in theory down the road. The point of an ISP having a caching nameserver is so that queries get cached closer to home, and for a larger segment of the network. If *every* end client had their own full caching nameserver, rather than relying on a heirarchy, we'd have a tragedy of the commons, and the load on the authoritative servers would go way, way up.
If network operators stuck to not interfering with DNS, and used it as intended, people wouldn't see the need to work around (and potentially, eventually, invalidate) the model.
They are even more closely tied together than that.
Without authentication, encryption (in this context) does not provide any security at all.
He means the radius likely.
Whether a star can decay into a black-hole is separate from whether a black-hole can exist the same size as the star - it just started out as something bigger.
Because the big black hole in the center of the galaxy doesn't explain it....
They address that in the article - when you do the math, the likelyhood of having a hash collision in SHA256, given a zetabyte filesystem with 128KB blocks is still orders of magnitude less likely than the known rate of data loss due to block level hardware failure.