This essay deserves far more exposure than merely featuring on Slashdot would give it. [PS. But *why* did Rob not accept it? Surely that was a no-brainer.]
And somehow we ought to ensure that all the free software / open source luminaries read the item. Instead of destructive flames, disgruntled people should just send off the URL of konstant's piece as a gentle reminder that egos are not the most important thing in this community.
I like following the progress of projects around the world --- I was in academia myself a decade ago, in a department where colleagues who were working with NNs would discuss their processing requirements and architectures with me. The work you describe sounds interesting.
Not half as difficult as installing Microsoft
on
CNN Installs Linux
·
· Score: 1
He should consider himself lucky that he didn't try to install a Microsoft O/S. That would have been utterly beyond him, and vastly more frustrating too because of the multiple reboots.
People forget that installing Microsoft is "easy" only because they don't have to do so as it's almost always preinstalled. In reality it's a bloody nightmare.
It's not really all that different to the way the recently announced supercomputer-on-a-desktop works, the one that translated microprocessor-type instructions into FPGA wiring on the fly, just in time, so that CPU instructions effectively run on dedicated logic intead of in generic microcode, ie. *much* faster.
This area is called Reconfigurable Computing, and it's been around for quite a few years (there's some quite reasonable supporting hardware available for it from Xilinx).
Transmeta's patent differs from that in the detail of course, but the general principle is remarkably similar, so much so that they've probably included references to it among the prior art somewhere.
I see no reason why it should be linear nor greater than linear, but plenty of reasons why it should be less than linear or possibly logarithmic.
After all, as projects near a state of completion, you'd expect fewer and fewer bug fixes and enhancements from developers both old and new. If there is any pressure for change resulting from an increase in a project's overall audience, it's certainly not very much, just a secondary effect.
Alan may have got his PhD back at Swansea along with the rest of us in the EE gang (I left around about the time of his arrival there). Or maybe he's still writing it up. Or maybe not. Dunno, ask him.
Whatever the answer is though, I bet he supports Linus's award totally. Just because so many other people have contributed to Linux doesn't in any way detract from Linus deserving this for the system which he started from scratch and for which he is the main standard bearer.
An honorary doctorate is *honorary* (would you believe it), ie. it's an honour bestowed on someone rather than a target towards which one can work.
I happen to think that Linus is worth honouring. How can anyone (at least outside of Microsoft) possibly disagree with this?
As for it not being in "as high" a category as a doctorate earned through several years of labour in academia, as some have said or implied, I think that's rubbish. I gained mine the conventional way, yet I have nothing but admiration for Linus's work and for his new title, which is well-earned and well-deserved.
Well done Linus! (And well done University of Stockholm too.)
Unless you want Linux to be as flakey as Windows, and drivers to be a security rick and kernel-specific and hence preventing you from upgrading to a new kernel whenever you want, and unless you want to wait several months for a bug to be accepted as such by the manufacturer, and more months until a fixed version is released.
Hey, maybe the usual assertion that lawyers are stupid isn't the whole story.
Maybe it's the judges that are stupid for entertaining these silly lawsuits, and the lawyers are clever enough to see that and know a profit when it's dangled in front of them.
That makes lawyers merely amoral and antisocial, rather than stupid.
If nanotech works out in accordance with current "schedules" (using the word very loosely), you'll see me working hard to get off the planet too.:-)
It's a pity that the Moon doesn't have the same romantic attraction as Mars though. On the other hand, it's far better placed w.r.to the Earth. You're probably laying the foundations for the most important gateway in the solar system. Good luck!
I can see how that would be useful in certain cases, namely when files are not huge and when their availability is not too critical so that single-point storage is acceptable. In particular, your examples of MP3 files would seem to provide a perfect match to the properties of this OS/2 solution.
And it *does* match the original poster's requirement too!:-)
That sounds very, very cool, and *hugely* complex. I sure hope that Charon doesn't give us a bad name through being visibly flakey, as in general the more complex a system, the more latent bugs it possesses. The proprietary suppliers would pounce on that immediately.
It's going to come down to control and isolation of complexity, which I presume the designers have been well aware of and focussed on. How does Charon tackle the issue, by which I mean, what's the fault-decoupling strategy?
Hmmm, maybe that's a subject for the kernel dev lists rather than Slashdot.
One way forward that might help you and which might provide some useful feedback is to try the NFS implementation on one of the free BSDs instead of Linux's. It's supposed to be a faster implementation than that of Linux anyway, although I haven't tried it myself so treat that with a pinch of salt.
It might well be more compatible with Solaris because of Sun's origins in BSD territory.
Your proposal evidently fulfils your requirements, but the query concerned a different requirement altogether: creation of a single filestore that efficiently uses all the free disk space across a set of machines because the poster was concerned about his storage being wasted.
Your solution doesn't create a single filestore, but several separate ones, ie. the path determines where a particular file resides. Nor does it distribute virtual storage across multiple machines, so it would not work at all for storing a few large files like database tablespaces. And of course the availability of any given file depends on which machine it resides, which is in turn a factor of which machines are currently up, so in your system file availability is under coarse manual control.
That may be acceptable, who knows --- horses for courses. I'm not saying that your system is not good for you, it clearly is, but it doesn't seem to meet the stated requirements of the poster nor is it a general solution. Some of the other proposals made here come much closer to being generally useful. However, that is at the cost of not using storage efficiently because they need the heavy caching and redundant distribution to provide the availability gain without which distributed storage is an untenable nightmare.
I don't think it'll happen without nanotech, not only because of the costs involved, but even more so because materials currently have a strength to weight ratio so low that it only barely lets us get those huge boosters off the ground without blowing us into little bits in the first place. We just can't blast that stuff out the back of our rockets fast enough to use the fuel efficiently, it's too dangerous. An astronaut's life is very much more in the balance during this stage than later, and tourists won't buy that in large numbers.
In contrast, with strength of materials rising by a factor of 10 purely as a result of atomic precision in nanofacturing (ie. relatively basic nanomachines would suffice), you can look forward to space planes not much more expensive than private jets for getting every well-funded man, woman and dog into space, and that *would* change all the rules.
Quite apart from nanotech changing all the rules of economics anyway, of course.:-)
... so the guy that says he owns the moon owns exactly nothing.
That principle applies to everything, by the way, even things for which you've paid money --- your receipt merely gives you some likelihood of marshalling others to defend what you say is yours. There is no other meaning to "ownership", despite what any politicians, lawyers or philosophers may say. It boils down to just this single pragmatic issue.
But what about the primary requirement, to allocate unused storage efficiently to avoid what was perceived as wasted blocks?
Files in Medley would have attrocious availability if it weren't for the extensive caching and redundancy, ie. if it weren't for a "prime directive" to trade efficiency for availability.
The goal of using spare storage for something is a good one, but not if the party in question is seeking efficient use of storage! Good idea, wrong requirement.
Actually, I understated the availability and reliability problem if virtual file blocks are assigned uniquely to single real blocks chosen from spare storage across a set of machines.
The probability of the file being accessible would be equal not to that of the weakest link, but to the product of the probabilities of all the links and machines possessing a part of the virtual file going down, each probability being less than = 1.0 of course. It's the classic MTBF calculation, and the result is uniformly bad.
Which is of course why systems that do this kind of thing typically feature lots of redundancy and caching, which takes us back to the last point about storage efficiency.
Have you actually thought this requirement of yours through? It sounds fairly dodgy to me.
For a start, you can't seriously be advocating that spare blocks from a variety of machines be used to provide unique bits and pieces of storage for virtual files distributed across those machines, I hope. This would make the availability and reliability of those files extremely low, ie. as low as the weakest link in the system.
Secondly, what happens when one of the contributing filestores requires more space, but can't use it because it's been allocated to one of those distributed files? You could no longer just delete something from the machine concerned without going through that hypothetical distributed filestore manager, because it would be the only party that would know whether the item in question is part of a distributed file and hence whether it can be deleted. (This assumes that it creates real files in the local filespace for allocating to distributed files, which it would have to do otherwise the space it allocates would evaporate if the distributing daemon died.) In other words, *all* of your storage becomes dependent on this new manager, slows to a crawl, and probably loses a lot of the reliability of your native filesystem to boot. No, no, no...
If the new distributed filesystem manager actually *does* make space on one machine as requested, it would clearly have to push out the data onto some other machine to compensate. If you think about it, the policy issues in this area are "interesting". (Aka "horrid".)
Finally, since the first point (unavailability cased by one machine going down) makes the idea completely untenable in most cases, you'd have to be talking about a system in which blocks are allocated in multiple places for each virtual file block. That's great, but notice that such a scheme is *not* storage-efficient, yet your requirement is based on not wanting to waste storage space!!!
No, I don't think you've thought this requirement through.
I found it hilarious that a proponent of Weak AI should come out with a conclusion that, in effect, is a tacit (but unspoken) admission that only Strong AI can produce really worthwhile results.
The Strong AI community has always known that it has a hard task ahead, but that's no reason to believe that the Strong AI direction is flawed and to take instead a less ambitious path.
Slashdot Mirror
This essay deserves far more exposure than merely featuring on Slashdot would give it. [PS. But *why* did Rob not accept it? Surely that was a no-brainer.]
And somehow we ought to ensure that all the free software / open source luminaries read the item. Instead of destructive flames, disgruntled people should just send off the URL of konstant's piece as a gentle reminder that egos are not the most important thing in this community.
Are your research materials online?
I like following the progress of projects around the world --- I was in academia myself a decade ago, in a department where colleagues who were working with NNs would discuss their processing requirements and architectures with me. The work you describe sounds interesting.
He should consider himself lucky that he didn't try to install a Microsoft O/S. That would have been utterly beyond him, and vastly more frustrating too because of the multiple reboots.
People forget that installing Microsoft is "easy" only because they don't have to do so as it's almost always preinstalled. In reality it's a bloody nightmare.
It's not really all that different to the way the recently announced supercomputer-on-a-desktop works, the one that translated microprocessor-type instructions into FPGA wiring on the fly, just in time, so that CPU instructions effectively run on dedicated logic intead of in generic microcode, ie. *much* faster.
This area is called Reconfigurable Computing, and it's been around for quite a few years (there's some quite reasonable supporting hardware available for it from Xilinx).
Transmeta's patent differs from that in the detail of course, but the general principle is remarkably similar, so much so that they've probably included references to it among the prior art somewhere.
I see no reason why it should be linear nor greater than linear, but plenty of reasons why it should be less than linear or possibly logarithmic.
After all, as projects near a state of completion, you'd expect fewer and fewer bug fixes and enhancements from developers both old and new. If there is any pressure for change resulting from an increase in a project's overall audience, it's certainly not very much, just a secondary effect.
What makes you think the opposite?
Alan may have got his PhD back at Swansea along with the rest of us in the EE gang (I left around about the time of his arrival there). Or maybe he's still writing it up. Or maybe not. Dunno, ask him.
Whatever the answer is though, I bet he supports Linus's award totally. Just because so many other people have contributed to Linux doesn't in any way detract from Linus deserving this for the system which he started from scratch and for which he is the main standard bearer.
Sigh.
I guess that's a recruitment site for PHBs.
An honorary doctorate is *honorary* (would you believe it), ie. it's an honour bestowed on someone rather than a target towards which one can work.
I happen to think that Linus is worth honouring. How can anyone (at least outside of Microsoft) possibly disagree with this?
As for it not being in "as high" a category as a doctorate earned through several years of labour in academia, as some have said or implied, I think that's rubbish. I gained mine the conventional way, yet I have nothing but admiration for Linus's work and for his new title, which is well-earned and well-deserved.
Well done Linus! (And well done University of Stockholm too.)
Unless you want Linux to be as flakey as Windows, and drivers to be a security rick and kernel-specific and hence preventing you from upgrading to a new kernel whenever you want, and unless you want to wait several months for a bug to be accepted as such by the manufacturer, and more months until a fixed version is released.
Who's side are you on?
Hey, maybe the usual assertion that lawyers are stupid isn't the whole story.
Maybe it's the judges that are stupid for entertaining these silly lawsuits, and the lawyers are clever enough to see that and know a profit when it's dangled in front of them.
That makes lawyers merely amoral and antisocial, rather than stupid.
The Moon is certainly a worthwhile challange.
:-)
If nanotech works out in accordance with current "schedules" (using the word very loosely), you'll see me working hard to get off the planet too.
It's a pity that the Moon doesn't have the same romantic attraction as Mars though. On the other hand, it's far better placed w.r.to the Earth. You're probably laying the foundations for the most important gateway in the solar system. Good luck!
OK, gotcha re the single filesystem.
:-)
I can see how that would be useful in certain cases, namely when files are not huge and when their availability is not too critical so that single-point storage is acceptable. In particular, your examples of MP3 files would seem to provide a perfect match to the properties of this OS/2 solution.
And it *does* match the original poster's requirement too!
As you say, the DFS mud pit is truly nasty, but I think Charon deserves the benefit of the doubt if they've been working hard on it, as reported.
:-)
Off to the kernel dev lists for information before criticising!
That sounds very, very cool, and *hugely* complex. I sure hope that Charon doesn't give us a bad name through being visibly flakey, as in general the more complex a system, the more latent bugs it possesses. The proprietary suppliers would pounce on that immediately.
It's going to come down to control and isolation of complexity, which I presume the designers have been well aware of and focussed on. How does Charon tackle the issue, by which I mean, what's the fault-decoupling strategy?
Hmmm, maybe that's a subject for the kernel dev lists rather than Slashdot.
Ouch, your symptoms sound awful.
One way forward that might help you and which might provide some useful feedback is to try the NFS implementation on one of the free BSDs instead of Linux's. It's supposed to be a faster implementation than that of Linux anyway, although I haven't tried it myself so treat that with a pinch of salt.
It might well be more compatible with Solaris because of Sun's origins in BSD territory.
Your proposal evidently fulfils your requirements, but the query concerned a different requirement altogether: creation of a single filestore that efficiently uses all the free disk space across a set of machines because the poster was concerned about his storage being wasted.
Your solution doesn't create a single filestore, but several separate ones, ie. the path determines where a particular file resides. Nor does it distribute virtual storage across multiple machines, so it would not work at all for storing a few large files like database tablespaces. And of course the availability of any given file depends on which machine it resides, which is in turn a factor of which machines are currently up, so in your system file availability is under coarse manual control.
That may be acceptable, who knows --- horses for courses. I'm not saying that your system is not good for you, it clearly is, but it doesn't seem to meet the stated requirements of the poster nor is it a general solution. Some of the other proposals made here come much closer to being generally useful. However, that is at the cost of not using storage efficiently because they need the heavy caching and redundant distribution to provide the availability gain without which distributed storage is an untenable nightmare.
I don't think it'll happen without nanotech, not only because of the costs involved, but even more so because materials currently have a strength to weight ratio so low that it only barely lets us get those huge boosters off the ground without blowing us into little bits in the first place. We just can't blast that stuff out the back of our rockets fast enough to use the fuel efficiently, it's too dangerous. An astronaut's life is very much more in the balance during this stage than later, and tourists won't buy that in large numbers.
:-)
In contrast, with strength of materials rising by a factor of 10 purely as a result of atomic precision in nanofacturing (ie. relatively basic nanomachines would suffice), you can look forward to space planes not much more expensive than private jets for getting every well-funded man, woman and dog into space, and that *would* change all the rules.
Quite apart from nanotech changing all the rules of economics anyway, of course.
... so the guy that says he owns the moon owns exactly nothing.
That principle applies to everything, by the way, even things for which you've paid money --- your receipt merely gives you some likelihood of marshalling others to defend what you say is yours. There is no other meaning to "ownership", despite what any politicians, lawyers or philosophers may say. It boils down to just this single pragmatic issue.
But what about the primary requirement, to allocate unused storage efficiently to avoid what was perceived as wasted blocks?
Files in Medley would have attrocious availability if it weren't for the extensive caching and redundancy, ie. if it weren't for a "prime directive" to trade efficiency for availability.
The goal of using spare storage for something is a good one, but not if the party in question is seeking efficient use of storage! Good idea, wrong requirement.
Actually, I understated the availability and reliability problem if virtual file blocks are assigned uniquely to single real blocks chosen from spare storage across a set of machines.
The probability of the file being accessible would be equal not to that of the weakest link, but to the product of the probabilities of all the links and machines possessing a part of the virtual file going down, each probability being less than = 1.0 of course. It's the classic MTBF calculation, and the result is uniformly bad.
Which is of course why systems that do this kind of thing typically feature lots of redundancy and caching, which takes us back to the last point about storage efficiency.
Have you actually thought this requirement of yours through? It sounds fairly dodgy to me.
...
For a start, you can't seriously be advocating that spare blocks from a variety of machines be used to provide unique bits and pieces of storage for virtual files distributed across those machines, I hope. This would make the availability and reliability of those files extremely low, ie. as low as the weakest link in the system.
Secondly, what happens when one of the contributing filestores requires more space, but can't use it because it's been allocated to one of those distributed files? You could no longer just delete something from the machine concerned without going through that hypothetical distributed filestore manager, because it would be the only party that would know whether the item in question is part of a distributed file and hence whether it can be deleted. (This assumes that it creates real files in the local filespace for allocating to distributed files, which it would have to do otherwise the space it allocates would evaporate if the distributing daemon died.) In other words, *all* of your storage becomes dependent on this new manager, slows to a crawl, and probably loses a lot of the reliability of your native filesystem to boot. No, no, no
If the new distributed filesystem manager actually *does* make space on one machine as requested, it would clearly have to push out the data onto some other machine to compensate. If you think about it, the policy issues in this area are "interesting". (Aka "horrid".)
Finally, since the first point (unavailability cased by one machine going down) makes the idea completely untenable in most cases, you'd have to be talking about a system in which blocks are allocated in multiple places for each virtual file block. That's great, but notice that such a scheme is *not* storage-efficient, yet your requirement is based on not wanting to waste storage space!!!
No, I don't think you've thought this requirement through.
I found it hilarious that a proponent of Weak AI should come out with a conclusion that, in effect, is a tacit (but unspoken) admission that only Strong AI can produce really worthwhile results.
The Strong AI community has always known that it has a hard task ahead, but that's no reason to believe that the Strong AI direction is flawed and to take instead a less ambitious path.
It's written in the same style as Simoleons, but without the same degree of humour.
Yes, I suppose it is about geeky folk as you say, but more like Hackers than like Slashdot.
Unfortunately, he's right.
It's going to take a lot of ingenious work by a lot of people to avoid that particular end game. I hope to play a part.
Well done, Gnrc.
... :-)
It's a great short story, I think, and it would be a shame if it disappeared off the net like a few other early works of authors have done.
I just love the Jolt-guzzling sloth