Sorry if I ruin someones dream. It might be that this desktop cluster really has a valid application, but instead of seeing it, I see someone trying to ship oil inter-continent by transporting oil-filled balloons in VW Beetles...
Don't worry, you did not ruin anybody's dream. You bleated about 10 usec network latency and otherwise don't seem to have a clue.
I'm not against Linux clusters. I'm using those for my studies. I'm just sceptical of using GbE as interconnect in anything that costs more than $10,000.
It uses 10GigE on the backplane. For good measure it has something like 80 GB of disk on each node.
I know this thing is nice because of the power requirements and the fact that you don't need a dedicated server room to store it, but for $100,000, you can get Microway to build you a pimptacular cluster with Dual-Opteron nodes, high-speed memory and a phat interconnect with either myrinet or infiniband. You will get a lot more work done for the same price.
You forgot a couple of things:
* HVAC costs
* Realestate costs
Remember, this is a deskside cluster. Try that with your dual-opteron cluster. And try adding up all the costs.
"you smell your average home machine in about 4 years"
Multiple 4 way opterons? 24 GB memory? At least 6 years way, assuming that the average home machine does not simply drop in cost at the expense of specs.
MSFT has a P/E of 24.5... By comparison, AAPL's is 40 and that other Slashdot darling, GOOG's, is at 88!
That is because both of the latter are growing an impressive rate, wherease MSFT has stagnated, not even keeping pace with the general growth of the PC industry. Taking that into account, MSFT is still overvalued... way overvalued.
And of course, we know the reason why MSFT has stagnated. And the reason it will soon begin to contract.
IMESHO PS (and so PDF) are both too powerful for this task. Or to put it another way, since there are a zillion different ways to represent text in PS, there are also a zillion different ways to push the limits on (and break) the various PS interpreters, and a zillion different ways to make content recovery difficult and imperfect. Perhaps we could use a limited subset of PS as a standard, and gzip it? But who would regulate such a standard?
Even stripped down postscript would still be a stupid markup language, even for printers. Yes, that means I think it is a stupid language, and that even considering that I am a Forth guru (and who cares about that, huh?).
We would be far better off developing an extended subset of OpenDocument for this purpose. This would answer your question about who would regulate it.
Here Stallman resorts to characterizing McVoy as a tantrum-throwing child.
Larry McVoy is a tantrum-throwing child. Take it from me, I know him personally. Or feast your eyes on some of the abundant evidence he has strewn around the net, let alone sent to private mailboxes.
Just a note, this tool assists in no way with the move away from bitkeeper, it was only of benefit when the linux kernel was still in bitkeeper. All this lets you do is pull source from a bitkeeper server, it does not replace the bitkeeper server. The way this benefits the open source community is now developers can begin intregrating this library into other development systems (like IDEs) and allowing bitkeeper integration.
Your "just a note" makes little sense. The purpose of SourcePuller is to retrieve our open source code, complete with its entire history, into a neutral, lossless dump file format that any version control tool can pull from. BitKeeper integration doesn't even come into it. The purpose of SourcePuller is to release our code from the clutches of BitKeeper so that we can forget about BitKeeper forever and get serious about improving our own tools. As we should have been right from the beginning (and as some of us were anyway, quietly, through the whole distasteful affair).
The way this benefits the open source community is, we don't have to suffer the loss of three years of versioning history. We now move forward without BitKeeper. SourcePuller is not for integrating with BitKeeper, it is for removing BitKeeper from the open source toolchain.
...and that if Tridgell held true in his heart to the noble cause of Software Freedom, hallowed be its name, then it was ok to slow down the efforts of people actually working on the open-source poster child, Linux.
That's a good example of snide innuendo. From you.
In fact, it's quite apparent that the core kernel team is generally happy with the development, and looking forward to the emergence of a really good, fully open tool. For some it goes much further than that. Personally, I feel deeply indebted to Andrew.
It's easy to see Open Source developers going "Hmm, this merge is really thorny, let's see what BK does... ah! maybe if I change my algorithm like this". McVoy's license basically said "Compete with us, but derive your own answers, don't peek at what we did". I think this is fair. Tridge doesn't seem to think this is fair.
We are not interested in what BitKeeper does, except as far as what Linus requires. Note that Tridge is not off base here in the eyes of the community, far from it. If you don't understand that, you just don't understand the community.
"Of course you can. It's trivial to get the entire version graph using bk."
You're trying to tell me that the CVS gateway provides the entire version graph? And note that the freeware client isn't available to everybody, and never was. Now it never will be.
How dense does one have to be, not to see this coming?
"He's connecting to a server. One does not generally have to agree to a license to do so."
Not true. If the license of the server says that only authorized clients are allowed to connect, then the person who installed/admins the server is violating the license if he allows non-authorized clients.
Your brain is addled. What makes you think he signed a license for the server?
it looks to me like Tridge was pissed about Linus deciding to use BK, and wanted to throw a wrench in the works. I have no respect for that
I do. I'm one of those who was locked out of the preferred means of accessing Linus's updates, because I have worked on open source version control. Others were locked out by their principles. So we think that Tridge did the noble thing by acting to provide a usable gateway for us. It's Larry McVoy's problem if he can't accept that.
His reverse engineering of BK cannot really be considered as being done with the aim of interoperability as it wasn't needed.
That is nonsense. There is no way to get the entire version graph out of a BitKeeper repository, using only tools provided by BitKeeper.
There also was no guarantee that the tools Larry McVoy did provide would not one day be taken away, which is exactly what happened. It never made sense to expose the Linux kernel version history to this risk.
One way of "building on other people's ideas" would be to license the code and use that to "build on" (ie: *pay* for it). However, since that would almost certainly involve a transaction involving money and source code - something the OSS community seems to consider almost identical to transactions involving souls and Lucifer
The is a mischaracterization. The real problem is, the result would not be free/open source, and therefore of little or no use to the OSS community.
Slashdot Mirror
Sorry if I ruin someones dream. It might be that this desktop cluster really has a valid application, but instead of seeing it, I see someone trying to ship oil inter-continent by transporting oil-filled balloons in VW Beetles...
Don't worry, you did not ruin anybody's dream. You bleated about 10 usec network latency and otherwise don't seem to have a clue.
Oh, and about 80GB of storage per node: how long would it take to do a simple checksum on that?
Huh?
try running Quake III on an FPGA - it will be killed by the CPU in processing and killed by the GPU in graphics
Oh, you mean, like this?
I'm not against Linux clusters. I'm using those for my studies. I'm just sceptical of using GbE as interconnect in anything that costs more than $10,000.
It uses 10GigE on the backplane. For good measure it has something like 80 GB of disk on each node.
I know this thing is nice because of the power requirements and the fact that you don't need a dedicated server room to store it, but for $100,000, you can get Microway to build you a pimptacular cluster with Dual-Opteron nodes, high-speed memory and a phat interconnect with either myrinet or infiniband. You will get a lot more work done for the same price.
You forgot a couple of things:
* HVAC costs
* Realestate costs
Remember, this is a deskside cluster. Try that with your dual-opteron cluster. And try adding up all the costs.
"you smell your average home machine in about 4 years"
Multiple 4 way opterons? 24 GB memory? At least 6 years way, assuming that the average home machine does not simply drop in cost at the expense of specs.
They fell 0.8% short of their projections: We've really got them on the run now!
Don't forget, this is after cutting back on employee benefits and such in order to make the business seem stronger than it actually is.
MSFT has a P/E of 24.5... By comparison, AAPL's is 40 and that other Slashdot darling, GOOG's, is at 88!
That is because both of the latter are growing an impressive rate, wherease MSFT has stagnated, not even keeping pace with the general growth of the PC industry. Taking that into account, MSFT is still overvalued... way overvalued.
And of course, we know the reason why MSFT has stagnated. And the reason it will soon begin to contract.
IMESHO PS (and so PDF) are both too powerful for this task. Or to put it another way, since there are a zillion different ways to represent text in PS, there are also a zillion different ways to push the limits on (and break) the various PS interpreters, and a zillion different ways to make content recovery difficult and imperfect. Perhaps we could use a limited subset of PS as a standard, and gzip it? But who would regulate such a standard?
Even stripped down postscript would still be a stupid markup language, even for printers. Yes, that means I think it is a stupid language, and that even considering that I am a Forth guru (and who cares about that, huh?).
We would be far better off developing an extended subset of OpenDocument for this purpose. This would answer your question about who would regulate it.
Here Stallman resorts to characterizing McVoy as a tantrum-throwing child.
Larry McVoy is a tantrum-throwing child. Take it from me, I know him personally. Or feast your eyes on some of the abundant evidence he has strewn around the net, let alone sent to private mailboxes.
PDF is a format for an exact reproduction of the appearance of documents. There is no equivalent open format.
I think you got postscript and pdf confused.
The version history was never "lost"
According to you. How about: the history, the whole history, and nothing but the history. Concentrate on the "whole" part please.
Just a note, this tool assists in no way with the move away from bitkeeper, it was only of benefit when the linux kernel was still in bitkeeper. All this lets you do is pull source from a bitkeeper server, it does not replace the bitkeeper server. The way this benefits the open source community is now developers can begin intregrating this library into other development systems (like IDEs) and allowing bitkeeper integration.
Your "just a note" makes little sense. The purpose of SourcePuller is to retrieve our open source code, complete with its entire history, into a neutral, lossless dump file format that any version control tool can pull from. BitKeeper integration doesn't even come into it. The purpose of SourcePuller is to release our code from the clutches of BitKeeper so that we can forget about BitKeeper forever and get serious about improving our own tools. As we should have been right from the beginning (and as some of us were anyway, quietly, through the whole distasteful affair).
The way this benefits the open source community is, we don't have to suffer the loss of three years of versioning history. We now move forward without BitKeeper. SourcePuller is not for integrating with BitKeeper, it is for removing BitKeeper from the open source toolchain.
...and that if Tridgell held true in his heart to the noble cause of Software Freedom, hallowed be its name, then it was ok to slow down the efforts of people actually working on the open-source poster child, Linux.
That's a good example of snide innuendo. From you.
In fact, it's quite apparent that the core kernel team is generally happy with the development, and looking forward to the emergence of a really good, fully open tool. For some it goes much further than that. Personally, I feel deeply indebted to Andrew.
I see you are not interested in answers, only in promulgating more snide innuendo.
It's easy to see Open Source developers going "Hmm, this merge is really thorny, let's see what BK does... ah! maybe if I change my algorithm like this". McVoy's license basically said "Compete with us, but derive your own answers, don't peek at what we did". I think this is fair. Tridge doesn't seem to think this is fair.
We are not interested in what BitKeeper does, except as far as what Linus requires. Note that Tridge is not off base here in the eyes of the community, far from it. If you don't understand that, you just don't understand the community.
"Of course you can. It's trivial to get the entire version graph using bk."
You're trying to tell me that the CVS gateway provides the entire version graph? And note that the freeware client isn't available to everybody, and never was. Now it never will be.
How dense does one have to be, not to see this coming?
I read that document, and I'm still not convinced.
That is because you are too dense to understand it, or you pretend to be.
"He's connecting to a server. One does not generally have to agree to a license to do so."
Not true. If the license of the server says that only authorized clients are allowed to connect, then the person who installed/admins the server is violating the license if he allows non-authorized clients.
Your brain is addled. What makes you think he signed a license for the server?
it looks to me like Tridge was pissed about Linus deciding to use BK, and wanted to throw a wrench in the works. I have no respect for that
I do. I'm one of those who was locked out of the preferred means of accessing Linus's updates, because I have worked on open source version control. Others were locked out by their principles. So we think that Tridge did the noble thing by acting to provide a usable gateway for us. It's Larry McVoy's problem if he can't accept that.
This guy is smart. He has also provided great value to the community.
Incidently, it's Doctor Andrew Tridgell.
-------------------
Since Tridge isn't talking about it at the moment, I'll try to provide some insight.
"Why he thought it was important to start reverse-engineering BitKeeper, rather than any of the many more widely-used proprietary products out there"
-- Because the Linux kernel source isn't stored in those other proprietary products.
"Whether and why he's doing it on OSDL's nickel"
-- He did it on his own time, as has been stated numerous times.
"Why he kept going when, at least according to McVoy, OSDL promised he'd stop while they negotiated"
-- Who said he promised to stop? And why should he?
"Whether screwing up Linux kernel development was worth whatever it is he thinks he's achieved"
-- Sorry, it was BitKeeper that screwsd up kernel development by creating this mess. Which anybody with a clue could see coming years ago.
"Why reverse-engineering the BitKeeper project was the only way to achieve his goals"
-- Because there is no other way to get all the revision data out of BitKeeper repositories, and into free/open source repositories.
"Whether he'll keep going with the project now that the kernel won't be in BitKeeper format anymore."
-- He surely will, until every last bit of open source code has been released from locked-in BitKeeper repositories.
If you have any more questions, could you please phrase them in a less accusatory style.
His reverse engineering of BK cannot really be considered as being done with the aim of interoperability as it wasn't needed.
That is nonsense. There is no way to get the entire version graph out of a BitKeeper repository, using only tools provided by BitKeeper.
There also was no guarantee that the tools Larry McVoy did provide would not one day be taken away, which is exactly what happened. It never made sense to expose the Linux kernel version history to this risk.
How exactly does success at SAMBA show that someone has good ethics?
If there was any way for Microsoft to attack Tridge or any other Samba team member on ethics then Microsoft surely would have done so by now.
One way of "building on other people's ideas" would be to license the code and use that to "build on" (ie: *pay* for it). However, since that would almost certainly involve a transaction involving money and source code - something the OSS community seems to consider almost identical to transactions involving souls and Lucifer
The is a mischaracterization. The real problem is, the result would not be free/open source, and therefore of little or no use to the OSS community.