Domain: realworldtech.com
Stories and comments across the archive that link to realworldtech.com.
Comments · 215
-
Re:Bandwidth will be a problem. NOT
Intel already has processors at 1333Mhz FSB, check the 5100 series, chipset and processors.
And my point was that 1333 MHz, while plenty for two cores, is not nearly enough bandwidth for 4 cores on a single bus. Their advanced L2 cache can hide the huge latency to memory, but it cannot make up for bandwidth starvation.
Additionally, I seriously doubt that Intel will be able to clock the FSB any faster than 1066 MHz. In the past, Intel has not been able to run multi-processor systems at the same bus speed as single processors. According to this link, Cloverton will be a 1066 MHz part, and I expect the same of Kentsfield.
Don't expect Intel's performance beyond 4 cores to be anything amazing. AMD's K8L, with an additional HT link and the ability to use "half links," will be the shining star of 8 and 16-core systems next year. -
Incorrect, they cannot come from the same wafer.
Merom and Yonah are basically dual-core Pentium M chips - 3 instruction decoders, 3-wide instruction issue / retire. They include the Pentium M's instructional units, including 2 64-bit SSE units per core.
Conroe and Woodcrest are complete redesigns of the Pentium M architecture, and are 4 + 1 decode, 4-wide issue and retire. Intel completely revamped the execution units: they include additional execution ports, and more floating-point power (ncluding full 128-bit wide SSE processing paths).
While they are both of the same pedigree (P6 -> Pentium M), they are NOT AT ALL the same. One is designed for efficiency, and the other tosses some efficiency out the window in favor of increased performance. See the preview article here at Real World Technologies.
You are thinking of the AMD Athlon / Opteron / Turion, which are the exact same chip with different microcode paths enabled. These chips can most certainly be taken from the same wafer. -
Re:Still feature limited
Which is why these 64-bit Linux benchmarks show that Woodcrest scales as good as (and sometimes better than) Opterons at 4p. The vast majority of x86 servers are in the 4p range. Even Opterons have a worse-than-expected scaling issue past 4p, anyway, if you bother to look around to find the benchmarks.
The Optron's scaling issues beyond 4P is not "worse then expected," because it is entirely expected of the architecture.
The high-end Opteron has 3 HT links. This means it can work with up to 8 sockets "gluelessly," but it really performans much better with 4-socket systems. The architecture for a 4-way Opteron server uses the extra HT link to reduice the number of hops, so only one case has two hops.
But you can imagine that the 8-way configurations have a much higher average number of hops between processors, PLUS much more data flowing over the same HT links. No, the K8 Opteron is not really designed well for 8-socket systems.
But K8L IS designed for 8-socket systems.
Take a look at a page on this in the K8L preview article on Real World Technologies. Adding a 4th HT link will really make a difference.
4-socket K8L systems benefit because they take advantage of the 4 HT links to provide 1-hop latency to all sockets in the mesh, and can now have external I/O hooked up to ALL processors.
8-socket K8L systems take advantage of two things: the extra HT link is beneficial, and the advanced mesh created by splitting up the HT bus widths means MUCH better performance for 8-way systems.
Woodcrest is impressive as hell, but I will tell you one thing: there's no way in hell it's going to scale well beyond 4-socket systems. This is for the same reasons that have been holding back performance on 4-way Xeon syetems (reduced bus speeds with 4 processors on the bus, too much traffic). The Dual-Independent Bus allows Intel to scale well to 4-way, but no higher. K8L will allow for glueless scaling to 8-way, and will still provide a a cheaper solution than Intel's Dual-Independent Bus for 4-way chipsets and motherboard designs. -
Is it a tradeoff issue?
Whether monolithic or microkernel, what it is expected from an OS is to manage resources, implement basic services et cetera in an effective and efficient way.
I think that the number of lines of code in either design direction tend to be almost the same, unless some code refactoring.
Also the number of "services" done by the OS tend to be the same.
Ease of maintenance, robustness, efficiency and so on are problems that should be faced in both cases with an overall need for resources that should be the same in both cases.
So, instead of debating, I'd do some real world tests, instrumentation and profiling in order to find out a reasonable solution. Being it shared memory or copy buffer, it really doesnt' matter.
Real effectivenes and afficiency do.
Prof. Tanenbaum and Dr. Torvalds (as well as a number of other people at their same level) have shown their deep knowledge in this area. A real advance in OS technology would be a constructive debate after the real world data analysis.
So the final question is: why not?
P.S. The referenced web site is still hot and smoking! -
Linus the asshole hypocriteNeither Linus nor Theo would ever use a rude name against an individual developer or organisation unless they truly were not smart.
Would Linus trash one of his open-source peers for, *gasp*, reverse engineering a closed-source protocol?
"He didn't create something new and impressive. He just tore down something new (and impressive) because he could, and rather than helping others, he screwed people over. And you expect me to _respect_ that kind of behaviour?" --Linus Torvalds
-
Re:Intel should be ashamed.
Hey, I agree wholehartedly, and I've been an AMD fanboy since the release of the P4.
Anyone who can look at this breakdown of the new Core design, understand it, and STILL proclaim AMD the performance leader is retarded. The extra simple decoder means potentially 33% more thoroughput out the gate, and the fused micro-ops can add another 5-10% performance improvement (assuming you have enough execution units to use all this). The 128-bit SSE unit, plus the ability for simple decoders to handle packed SSE instructions, also means double the speed at vector operations.
That said, at least I had my just desserts. I always said superpipelined Netburst was a retarded design, and the fact that Intel went and developed Conroe only validates my claim.
I am still curious to see the power usage of Core. It should be less than the P4, but whether it is competitive with AMD may be another story. Hopefully AMD will finally get off their ass and improve their own design, which hasn't changed much since the K7 (onboard memory controller aside). Who knows, I may end up buying Conroe, and becomean Intel fanboy again. -
Re:A start, but no 64-bit? 667 Mhz front-side bus?This is just a stepping stone. See the recent article in Real World Tech for lots of details on Intel's upcoming server chips. This 32-bit model is just a quickie model (it's just the new laptop design packaged for the blade-server market): the REAL fun models are coming in a few months.
I've actually been accused of being a bit of an AMD fan boy myself, but the upcoming Intel chips are no joke either. It really looks like they've almost fully recovered from the Netburst mis-step. The race is back on.
-
Re:Wikipedia article question
I remember some early Risc chips that didn't have branch prediction hardware - they would simply predict a backward branch as taken, and a forward one as not.
Which would be ok for most loops.
http://en.wikipedia.org/wiki/Branch_prediction
Incidentally, SPEs have rather short pipelines, so a mispredicted branch is not the catastophe it would be on a desktop CPU.
http://www.realworldtech.com/includes/templates/ar ticles.cfm?ArticleID=RWT021005084318&mode=print -
A much better description of the architecture
is available on Real World Technolgies http://www.realworldtech.com/page.cfm?ArticleID=R
W T102405055354 -
Re:Apple
Indeed, it is too late for Apple right now
... just as they switch to Intel something comes out that *may* be vastly more performant per Watt and far more integrated (meaning cost savings).
Anyway, for more information on the core of this new processor: http://www.realworldtech.com/page.cfm?ArticleID=RW T102405055354&p=3
The last line is very interesting: "per core typical power at 4W and worst case at 7W" -
Re:Embedded market
You mean the embedded market that needs a chip that can fill a 10Gbps pipe with a choice of IPSec or SSL traffic all on its own?
http://www.realworldtech.com/page.cfm?ArticleID=RW T102405055354 -
Great interview with Horus' Engineers
Real World Tech has a great interview between David Kanter and two of the engineers working on Horus. If you're interested in actual information about how it works and what it does, its good reading.
BTW, Linus Torvalds posts to RWT
:-D -
Re:Spoiled brats
Split your game engine into a generic CPU-orientated thread, plus 6 threads designed to work well with the various cores in Cell.
What are you going to put on 6 different threads that all have to talk to each other and share data now and then? Remembering that the use of the co-processors on the cell is very limited, and completely different in design than the triple core approach of the x-box? Your approach would work for x-box/PC games, but not with Cell.
It's a bit of a hassle, and there will have to be platform specific tweaks, but I don't think that's what's really getting to developers. I think they're not used to having to deal with the issues related to multi-threading, and that's what scares them.
Can you blame them ? They're being asked to use a technique (multi-threading) which often causes programmers a lot of pain even when they're working in small teams, in an environment where they have large teams, sometimes with rapid turnover, working to impossible deadlines over several years, often with inherited spaghetti code. It's the the worst possible environment for trying to write multi-threaded code and keep the bugs under control. Add to that the complication of the CELL architecture which isn't actually a normal multi-core system at all (which is what he was complaining about).
More detail :In essence, the asymmetric nature of the CELL processor means that two separate tool chains are needed to create an application for the CELL processor. Programmers coding for the CELL processor need to think in terms of software modules and separate tool chains are needed to deal with PPE modules and SPE modules.
The SPE modules are really very basic and have to be programmed separately, it's not as if you just split your program into an 'audio', AI, and a few drawing threads and you're done. Things just aren't that simple. In some ways the CELL would be more useful for scientific calculations than for games. It's more like a sophisticated Altivec unit (1 or more) than several cores. -
More information at Real World Tech
There's a better explanation of why the Inq article's speculation is bogus here:
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3655&Thread=3&entryID=55310&room ID=11 -
Detailed commentary on realworldtech
The computer-architecture blog "realworldtech" has been slogging this one out in extreme detail (particularly as regards integer performance, where the Itanium has seemed to lag); see http://www.realworldtech.com/forums/index.cfm?act
i on=detail&PostNum=3510&Thread=1&entryID=52549&room ID=11 -
Thread on the same question at RealWorldTech.com
I asked the same question at RealWorldTech.Com about 6 months ago and got a fair number of replies - several of which I thought were fairly insightful.
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=2978&Thread=1&entryID=43600&room ID=11
You can see the full thread at the bottom of the linked page. -
Re:Backwards compatability - this will help
The PS3 does not use PPC. It uses the cell architecture, and while IBM was part of the STI that created the Cell (which also includes Sony and Toshiba, as the 'S' and the 'T'), which in no way is the power pc archetecture.
...except the cells have a PPC core to handle basic processing and the feeding of instructions out to the cell cores, which handle your vector operations and floating point mathematics. This is a "new" PowerPC core which is "a two issue, in-order, 64 bit processor that supports 2 way SMT". It allegedly has a somewhat longer pipeline than other PPC processors (to allow higher clock rates) so it can be expected to perform somewhat more poorly clock-for-clock than the G5. -
The reason
[Torvalds] ranted against Tridgell, but that's misplaced, I think. Torvalds isn't fully into the "Free Software" philosophy (despite his use of the GPL for Linux), and so doesn't see any value in Tridgell's work and calls it "evil."
I think you are mistaken here. Please read Linus's own words on the subject before judging him. A quote:
[Tridgell] didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about.
He didn't create something new and impressive. He just tore down something new (and impressive) because he could, and rather than helping others, he screwed people over. And you expect me to _respect_ that kind of behaviour?
Everyone having any feelings about this Linux SCM change topic, I urge you to hold your comments until you've read Linus's explanation of his feelings and actions and also his other replies in the thread, like this, this, this and this. It's really worth the little time it takes, for you'll find detailed explanations on what made BitKeeper so great, what's Linus's opinion of reverse engineering, why isn't he pissed off at BitMover, Inc. and much more.
-
The reason
[Torvalds] ranted against Tridgell, but that's misplaced, I think. Torvalds isn't fully into the "Free Software" philosophy (despite his use of the GPL for Linux), and so doesn't see any value in Tridgell's work and calls it "evil."
I think you are mistaken here. Please read Linus's own words on the subject before judging him. A quote:
[Tridgell] didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about.
He didn't create something new and impressive. He just tore down something new (and impressive) because he could, and rather than helping others, he screwed people over. And you expect me to _respect_ that kind of behaviour?
Everyone having any feelings about this Linux SCM change topic, I urge you to hold your comments until you've read Linus's explanation of his feelings and actions and also his other replies in the thread, like this, this, this and this. It's really worth the little time it takes, for you'll find detailed explanations on what made BitKeeper so great, what's Linus's opinion of reverse engineering, why isn't he pissed off at BitMover, Inc. and much more.
-
The reason
[Torvalds] ranted against Tridgell, but that's misplaced, I think. Torvalds isn't fully into the "Free Software" philosophy (despite his use of the GPL for Linux), and so doesn't see any value in Tridgell's work and calls it "evil."
I think you are mistaken here. Please read Linus's own words on the subject before judging him. A quote:
[Tridgell] didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about.
He didn't create something new and impressive. He just tore down something new (and impressive) because he could, and rather than helping others, he screwed people over. And you expect me to _respect_ that kind of behaviour?
Everyone having any feelings about this Linux SCM change topic, I urge you to hold your comments until you've read Linus's explanation of his feelings and actions and also his other replies in the thread, like this, this, this and this. It's really worth the little time it takes, for you'll find detailed explanations on what made BitKeeper so great, what's Linus's opinion of reverse engineering, why isn't he pissed off at BitMover, Inc. and much more.
-
The reason
[Torvalds] ranted against Tridgell, but that's misplaced, I think. Torvalds isn't fully into the "Free Software" philosophy (despite his use of the GPL for Linux), and so doesn't see any value in Tridgell's work and calls it "evil."
I think you are mistaken here. Please read Linus's own words on the subject before judging him. A quote:
[Tridgell] didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about.
He didn't create something new and impressive. He just tore down something new (and impressive) because he could, and rather than helping others, he screwed people over. And you expect me to _respect_ that kind of behaviour?
Everyone having any feelings about this Linux SCM change topic, I urge you to hold your comments until you've read Linus's explanation of his feelings and actions and also his other replies in the thread, like this, this, this and this. It's really worth the little time it takes, for you'll find detailed explanations on what made BitKeeper so great, what's Linus's opinion of reverse engineering, why isn't he pissed off at BitMover, Inc. and much more.
-
The reason
[Torvalds] ranted against Tridgell, but that's misplaced, I think. Torvalds isn't fully into the "Free Software" philosophy (despite his use of the GPL for Linux), and so doesn't see any value in Tridgell's work and calls it "evil."
I think you are mistaken here. Please read Linus's own words on the subject before judging him. A quote:
[Tridgell] didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about.
He didn't create something new and impressive. He just tore down something new (and impressive) because he could, and rather than helping others, he screwed people over. And you expect me to _respect_ that kind of behaviour?
Everyone having any feelings about this Linux SCM change topic, I urge you to hold your comments until you've read Linus's explanation of his feelings and actions and also his other replies in the thread, like this, this, this and this. It's really worth the little time it takes, for you'll find detailed explanations on what made BitKeeper so great, what's Linus's opinion of reverse engineering, why isn't he pissed off at BitMover, Inc. and much more.
-
Tridge's silenceWas on legal advice.
What's not fine is phoning their employer and asking for them to get the sack because of the code they were knocking together at home.
If which was the case Tridge would have contacted his lawyer even though he did clearly did nothing illegal w.r.t. bitkeeper, but if Linus has influence with OSDL then he would have needed advice regarding suing for unfair dismissal.
-
Re:Why shoud I have to sign...
"Yes, yes, all well and good except that MS has been found guilty of using unfair business practices to maintain and extend their monopoly."
The classic /. whine. Microsoft must be bad, a court said so. But if when that court upholdes patents, or the DMCA or anything we don;t liek the courts are obviously too stupid to understand technology situations.
As Linus said (sorta), Hypocrisy (is) the worst of human traits -
Rvrs-engineer BK = lincensee breaks terms
This is really the better place to start reading.
-
Reverse-engin. = someone breaks terms of license
I'm sure someone pointed this out before, but Bitkeeper's distributed nature means a licensee has to cooperate with the reverse-engineer, thus there is much breaking of terms.
-
who is the "git"?
But hey, I'm making the best of the situation. I wrote my
I really admire Linus's clarity on all this, over at RWT. I can see why he has had so much success, both in leading others and in getting things done himself. Someone worth learning from.
own tools, and as usual (conceited bastard that I am), I
named the new project after myself: "git".
LinusAnd then you've just gotta smile at the self-depreciation.
-
This is about politics folks
Last year, I had to see my preferred political candidate for president lose the race all because he made the fatal mistake of expressing enthusiam during a political speech in Iowa. Boy, he was an idiot for doing that. Not like that great thinker GW Bush, and all the brilliant things he's said. Or that superior thinker, John Kerry, who knew never to express an opinion on anything other than he's a better candidate than GWB. Or fight back hard when slandered by a bunch of political operators like the "Swift Boat Veterans".
The lesson to be learned here is that anyone can be portrayed to look like an idiot. It doesn't mean they are. More important, one must closely observe what the pack of jackals say. Then you have to be able to discern the untruths and misreprentations. Then realize what are the consequences.
Realize that F/OSS is a philosophy. It stops being a philosophy and starts being an ideology when its proponent try to coerce their views on people with a different philosophy. Much like how people think the U.S. must conform to a Fundamentalist Christian value set. (After all, is it wrong to value life? Or the gov't showing respect to the Christian God? Aren't public schools denying religion by not permitting a Christian prayer in class? Or teaching something we don't believe because its relies on scientific research and methodology for its arguments?)
The key thing here is observe the positions that F/OSS zealots take, and the tactics they employ.
Torvalds was wrong for adopting a proprietary tool and "making" developers use it.
The problem here was that quite a few, if not the majority, of developers did not want to use BK and chose not to use BK. It did not prevent them from making contributions to kernel development. So how did Torvalds compel developers, against their will, to adopt a tool?
This proprietary tool would abscond the software and the changeset data!
But as Torvalds points out here, its baseless. But gee, it sounds real scary, doesn't it. And who cares if its claptrap? So many Slashdotters think its the reason why Torvalds was an idiot to adopt a proprietary tool!
Why, according to Torvalds, is exploring proprietary Microsoft protocols good, while exploring proprietary Bitmover protocols is bad? This does not compute.
That's because F/OSS zealots Orlowski and Perens prefer to misrepresent Torvalds' position. Torvalds does not attack reverse-engineering, he attacks Tridgell for messing up his agreement with McVoy WITHOUT PROVIDING AN ALTERNATIVE.
Perens:It seems to me hypocritical. I can't tell Linus Torvalds what to say. But it's Andrew Tridgell who is literally not allowed to reply, here, and Linus is being very severely unfair."
Tridgell is not "literally not allowed to reply". He will not lose his job if he replies. Tridgell merely does not have the character to publicly defend his beliefs if it will result a (miniscule) risk to his financial wellbeing. (But he's more than happy to dismiss McVoy's concerns towards his financial wellbeing when he conducts his reverse-engineering activities.)
But perhaps Perens is right. Linus is being severely unfair, the way people are being unfair about commenting on Scott Pedersen during his trial, and Michael Jackson during his trial. This world is ridden with filthy, unethical people. Oh wait, Tridgell is not actually under indictment. I guess Torvalds should respect Tridgell's reputation and desire to protect his financial welfare after Tridgell screwed Torvalds' deal with McVoy, and gladly suffer the glaring misrepresentations made by Perens and his ilk. (See Swift Boat Veterans.) Oh yes, the hypocrisy!
Folks, its really simple. F/OSS ze
-
Read this
It looks like most people who have replied haven't read this. (AFAIK, this wasn't reported on slashdot, but was on the Register. Another reason to have sources of news other than
/.) -
Re:So...
Again, I'll let Linus speak for himself
:-)
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=85&entryID=49486&roo mID=11
Here's the extract:
Steven Van Langendonck on 4/15/05 wrote:
>
>This would mean that to work with the tool you need to
>connect it the installation of those developers that you
>which to cooperate with?!
Yes. Well. Only one of them.
But yes, it does mean that for at least that one
developer, your point of:
>And this would drag them automatically into the conflict
>between BM and Tridge.
Exactly.
So Tridge is entirely correct in saying that he
didn't violate any licenses, since he never agreed to a
BK license in the first place. But for the tool to be
useful, somebody ends up having to be the fall
guy.
So I think Tridge is coming from a "free software is always
useful" argument, whether it's true from a technical
standpoint or not. Because you can always extend of it,
and as such it's "useful" as a thing to hack on. That's
certainly a valid point in one sense, but...
Linus
This, looks like he was snooping on the network with the co-operation of a licensed user. Another info, Linus says he would have been OK with the reverse engineering if the result was a good enough replacement for BK.
On a positive note, he says:
I'm sure Linux will be stronger for it, since
it forced me to get off my fat ass and write my own tool.
It's the old "whatever doesn't kill you.." thing. -
Maybe Linus should just shut upFrom Linus Torvald..
I'm not going to do flame-wars in public with anonymous trolls, but I'll respond once just because RWT is not slash-dot.
And you, my anonymous troll, probably didn't do anything constructive in your life, so this argument probably went way over your head.
Linus
Dear Linus, it is great that you refrain from adding to the Slashdot chatter because someone would have to mod you flamebait for being such a prick. And leave your belly button alone.
-
Re:Difference between Samba and Bitkeeper situatio
Here's the way Linus views the difference between Samba and BK:
Anobody that compares that to Open Office (or even samba, which Tridge did write) is an idiot. Open office and samba are constructive projects that actually do something useful,and are technically advanced quite regardless of the fact that they can interoperate with the competition. They look at the file data because they then _use_ it (...)" (I bolded it).
Just so one has more context, before he said that, he also said: "Tridge could have done something constructive: he could have written the best damn SCM on the planet, and believed that open source generates better things, and competed against BitKeeper that way. (...) But that's not what Tridge did. He didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about."
You can read the whole post here -
This is about the *project*, not morality
Linus is right in what he said. He may look like an idiot right now, but he isn't. Please read his posts (cited below), and don't believe hearsay.
He said this episode is damaging to the Linux kernel *project*, because he took advantage of, and depended on, BK's *functionality*, not BK per se. He said there isn't any other app (open or closed) that offers that functionality, and that he would rather write a new one himself.
[...] It's unquestionably true that BitKeeper has advanced the state of SCM technology. Anybody who argues against that just doesn't know what the hell he is talking about. But I'd have loved even an "almost-as-good" open source SCM, because that would obviously just be a good idea.
[...]
Now, I'm dealing with the fall-out, and I'll write my own kernel source tracking tool because I can't use the best any more. That's ok - I deal with my own problems, thank you very much. But what I find sad is how some people are so _gleeful_ about a commercial program becoming less useful, only because it was commerical.
If BK was a crappy tool, I'd at least understand the glee. But in this case it was the commercial people who did the impressive technology and pushed technology forward. And I'm just honest enough to be able to say that.
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=2&entryID=49312&room ID=11So: true support for totally distributed development (replication doesn't count), performance, and trust. Nothing else matters. And BK does those better than anything else I've seen.
(Well, at least I hope those are the only three things that matter. The quick-hack framework I'm putting together bases its entire design on just those three things, and maybe I'll find out that I'm wrong, and that there are three other things that I just took for granted ;)
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=5&entryID=49321&room ID=11He said he doesn't believe in the open-or-nothing 'solution'.
So I think open source tends to become technically better over time (but it does take time), but I don't think it's a moral imperative. I do open source because it's fun, and because I think it makes sense in the long run.
For some reason that is hard for a lot of free software people to accept. Too many people see things as a war of "free software" against "proprietary evil". This is, btw, the real difference between the "open source" crowd and the "free software" crowd, as far as I'm concerned.
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=2&entryID=49312&room ID=11He did NOT say Tridgell didn't have a right to do what he did. He said Tridgell's goal was not to develop an alternative to BK right now (and therefore his current work wasn't a solution to his dependence 'problem'), and now the *project* is going to suffer.
But that's not what Tridge did. He didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about.
He didn't create something new and impressive. He just tore down something new (and impressive) because he could, and rather than helping others, he screwed people over. And you expect me to _respect_ that kind of behaviour? -
This is about the *project*, not morality
Linus is right in what he said. He may look like an idiot right now, but he isn't. Please read his posts (cited below), and don't believe hearsay.
He said this episode is damaging to the Linux kernel *project*, because he took advantage of, and depended on, BK's *functionality*, not BK per se. He said there isn't any other app (open or closed) that offers that functionality, and that he would rather write a new one himself.
[...] It's unquestionably true that BitKeeper has advanced the state of SCM technology. Anybody who argues against that just doesn't know what the hell he is talking about. But I'd have loved even an "almost-as-good" open source SCM, because that would obviously just be a good idea.
[...]
Now, I'm dealing with the fall-out, and I'll write my own kernel source tracking tool because I can't use the best any more. That's ok - I deal with my own problems, thank you very much. But what I find sad is how some people are so _gleeful_ about a commercial program becoming less useful, only because it was commerical.
If BK was a crappy tool, I'd at least understand the glee. But in this case it was the commercial people who did the impressive technology and pushed technology forward. And I'm just honest enough to be able to say that.
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=2&entryID=49312&room ID=11So: true support for totally distributed development (replication doesn't count), performance, and trust. Nothing else matters. And BK does those better than anything else I've seen.
(Well, at least I hope those are the only three things that matter. The quick-hack framework I'm putting together bases its entire design on just those three things, and maybe I'll find out that I'm wrong, and that there are three other things that I just took for granted ;)
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=5&entryID=49321&room ID=11He said he doesn't believe in the open-or-nothing 'solution'.
So I think open source tends to become technically better over time (but it does take time), but I don't think it's a moral imperative. I do open source because it's fun, and because I think it makes sense in the long run.
For some reason that is hard for a lot of free software people to accept. Too many people see things as a war of "free software" against "proprietary evil". This is, btw, the real difference between the "open source" crowd and the "free software" crowd, as far as I'm concerned.
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=2&entryID=49312&room ID=11He did NOT say Tridgell didn't have a right to do what he did. He said Tridgell's goal was not to develop an alternative to BK right now (and therefore his current work wasn't a solution to his dependence 'problem'), and now the *project* is going to suffer.
But that's not what Tridge did. He didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about.
He didn't create something new and impressive. He just tore down something new (and impressive) because he could, and rather than helping others, he screwed people over. And you expect me to _respect_ that kind of behaviour? -
This is about the *project*, not morality
Linus is right in what he said. He may look like an idiot right now, but he isn't. Please read his posts (cited below), and don't believe hearsay.
He said this episode is damaging to the Linux kernel *project*, because he took advantage of, and depended on, BK's *functionality*, not BK per se. He said there isn't any other app (open or closed) that offers that functionality, and that he would rather write a new one himself.
[...] It's unquestionably true that BitKeeper has advanced the state of SCM technology. Anybody who argues against that just doesn't know what the hell he is talking about. But I'd have loved even an "almost-as-good" open source SCM, because that would obviously just be a good idea.
[...]
Now, I'm dealing with the fall-out, and I'll write my own kernel source tracking tool because I can't use the best any more. That's ok - I deal with my own problems, thank you very much. But what I find sad is how some people are so _gleeful_ about a commercial program becoming less useful, only because it was commerical.
If BK was a crappy tool, I'd at least understand the glee. But in this case it was the commercial people who did the impressive technology and pushed technology forward. And I'm just honest enough to be able to say that.
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=2&entryID=49312&room ID=11So: true support for totally distributed development (replication doesn't count), performance, and trust. Nothing else matters. And BK does those better than anything else I've seen.
(Well, at least I hope those are the only three things that matter. The quick-hack framework I'm putting together bases its entire design on just those three things, and maybe I'll find out that I'm wrong, and that there are three other things that I just took for granted ;)
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=5&entryID=49321&room ID=11He said he doesn't believe in the open-or-nothing 'solution'.
So I think open source tends to become technically better over time (but it does take time), but I don't think it's a moral imperative. I do open source because it's fun, and because I think it makes sense in the long run.
For some reason that is hard for a lot of free software people to accept. Too many people see things as a war of "free software" against "proprietary evil". This is, btw, the real difference between the "open source" crowd and the "free software" crowd, as far as I'm concerned.
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=2&entryID=49312&room ID=11He did NOT say Tridgell didn't have a right to do what he did. He said Tridgell's goal was not to develop an alternative to BK right now (and therefore his current work wasn't a solution to his dependence 'problem'), and now the *project* is going to suffer.
But that's not what Tridge did. He didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about.
He didn't create something new and impressive. He just tore down something new (and impressive) because he could, and rather than helping others, he screwed people over. And you expect me to _respect_ that kind of behaviour? -
What Linus wroteFYI what Linus wrote:
Name: Linus Torvalds (torvalds@osdl.org) 4/13/05
blah (blah@blah.com) on 4/13/05 wrote:
>
>Yes its ok to ride on the coat tails of UNIX and MS but
>no no dont do that to Bitmover my friend.
I'm not going to do flame-wars in public with anonymous trolls, but I'll respond once just because RWT is not slash-dot.
> Yah its fine for people to take others ideas and reverse
>engineering them unless it hits someone a person happen to
>know. Then its BAD!
Actually, in this case I knew and respected _both_ sides, which makes it so interesting to me personally. Not to mention that it directly affected how I work, which made
it even more so.
Unlike some people, I don't judge people for whether they are commercial or "free software" people, which means that to me it wasn't a case of knowing which side was "evil"
(and thus wrong by default - isn't that how it works ;) to start with.
In my book, what matters is what you do - whether you want to sell things is your personal choice, but even more importantly it is not a moral negative or positive. I'm a
big believer in open source as creating good stuff, but I don't think it's a moral issue. It's engineering.
So I think open source tends to become technically better over time (but it does take time), but I don't think it's a moral imperative. I do open source because it's fun, and because I think it makes sense in the long run.
For some reason that is hard for a lot of free software people to accept. Too many people see things as a war of "free software" against "proprietary evil". This is, btw, the real difference between the "open source" crowd and the "free software" crowd, as far as I'm concerned.
Tridge could have done something constructive: he could
have written the best damn SCM on the planet, and believed
that open source generates better things, and competed
against BitKeeper that way.
He'd have been a hero to me. It's unquestionably true that
BitKeeper has advanced the state of SCM technology. Anybody
who argues against that just doesn't know what the hell he
is talking about. But I'd have loved even an "almost-as-
good" open source SCM, because that would obviously just
be a good idea.
But that's not what Tridge did. He didn't write a "better
SCM than BK". He didn't even try - it wasn't his goal. He
just wanted to see what the protocols and data was,
without actually producing any replacement for the
(inevitable) problems he caused and knew about.
He didn't create something new and impressive. He just
tore down something new (and impressive) because he could,
and rather than helping others, he screwed people over.
And you expect me to _respect_ that kind of behaviour?
Anobody that compares that to Open Office (or even samba,
which Tridge did write) is an idiot. Open office and samba
are constructive projects that actually do something useful,
and are technically advanced quite regardless of the fact
that they can interoperate with the competition. They look
at the file data because they then _use_ it, and they never
tore down other peoples work.
Now, I'm dealing with the fall-out, and I'll write my own
kernel source tracking tool because I can't use the best
any more. That's ok - I deal with my own problems, thank
you very much. But what I find sad is how some people are
so _gleeful_ about a commercial program becoming less
useful, only because it was commerical.
If BK was a crappy tool, I'd at least understand the glee.
But in this case it was the commercial people who did the
impressive technology and pushed technology forward. And
I'm just honest enough to be able to say that.
And you, my anonymous troll, probably didn't do anything
constructive in your life, so this argument probably went
way over your head.
     Linus -
Re:So...
no.... Linus explains clearly enough
:
'Tridge wanted to create a tool that checked out BK trees
for people who didn't sign the license. But it still
needed BK to actually do anything useful - since it would
not actually do the work that BK did.
"Hey, that's a useful helper". Yes, except when it isn't.
And it isn't, if releasing it just causes the BK protocols
to change, and people who used BK in the first place to
have to stop using it, and when using the tool against a
BK repository is a violation of the license that the BK
user agreed to.'
I wish people would read Linus' comment that I have linked to. He makes is point very cleary there. I really don't need to add anything to that. To avoid linking to some more comments of his, people would not read those either, I clarify: Keep in mind that to reverse engineer BK, one would HAVE to violate the license with BM. Now, once that was getting violated, BM had full authority to refuse to license it anymore.
The entire discussion thread where Linus explains himself is here: http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=2&entryID=49312&room ID=11 -
Linus' valid issue:Here Steven Van Langendonck ponts out: (and I quote in case you don't want to follow the link:)
BK is distributed. And Tridge's tool is 'accessing the server'.
Wait a moment. Which server??? Distributed means no central server...
Does the distributed nature of BK not imply that every environment is at the same time server and client?
This would mean that to work with the tool you need to connect it the installation of those developers that you which to cooperate with?! An this would drag them automatically into the conflict between BM and Tridge.
To which Linus replies: (AIQICYDWTFTL)
This would mean that to work with the tool you need to connect it the installation of those developers that you which to cooperate with?!
Yes. Well. Only one of them.
But yes, it does mean that for at least that one developer, your point of:
And this would drag them automatically into the conflict between BM and Tridge.
Exactly.
So Tridge is entirely correct in saying that he didn't violate any licenses, since he never agreed to a BK license in the first place. But for the tool to be useful, somebody ends up having to be the fall guy.
-
Come ON.
Wow, for once the Slashdot groupthink isn't pro-Linus. But I am. I'll explain why. First, you need to read the original thread to get a feel for what Linus is saying. At least read the first 15 posts there.
After you've read it, you'll come away with a few realizations:
- The Register is courting controversy. There really is a dispute, don't get me wrong. But they've boiled down a lengthy, nuanced discussion into a few hotheaded soundbytes.
- Torvalds really is saying some stupid stuff, granted.
- But Torvalds also makes some good points. From reading that thread I linked to, I can see that Linus has a very real, legitimate problem that only BitKeeper could solve. Read it. He saved hours or in some cases days of down time -- time that other SCM tools would have sucked up and wasted. For a man in his position, that's really serious.
Just think: if you were a bottleneck, if data and people were coming at you at a very fast pace all the time, and if there was tremendous pressure on you to build a platform that would rival Microsoft, one coping mechanism is to find tools that increase productivity. A lot. (Other good coping mechanisms include heavy drinking and vanishing without a trace.)
Now Linus, who has no ready alternative is staring down a barrel of loaded source code, knowing it's going to fire off in his face real soon now. And someone else has yanked his defense right out from under him. He has a real problem now. He's pissed. I can put myself in his shoes, I can understand his frustration. Basically, it's this: "Well great. WTF do I do now? Oh shit, stuff is backing up already. Thanks! That's fucking great!"
Is Torvalds wrong to blame Trigdell for reverse engineering? Yes. Is Torvalds wrong to feel horribly, disastrously inconvenienced by this? No, he has every right. Forget the technical arguments for a day or a week. This is a human issue right now. People were inconsiderate of each other, and now they're walking around with bloddy noses. Give them time to assess the situation. If Torvalds doesn't soften his position in a short while, fork, screw him, whatever. But give him some time for the fight or flight instinct to be peter out before you all write him off.
-
Linus' Stance
Read the Real World Tech thread to get a better idea of where Linus is coming from. Personally I find his stance very strange indeed. I think most of us do, which is why this is such a big story.
-
Did you actually read Linus' reply?
The Register has been completely biased about the matter so I wouldn't take their word on anything. Linus is pissed off at Tridge because he messed up the deal with McVoy and wasn't even trying to produce anything functional to replace BK. "He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about."
Everybody seems to forget that McVoy contributed more than $500 000 worth of software to the osdl. Without the contribution, Tridge would have never been able to even try to reverse engineer the program.
Linus lost the use of the best SCM there is. Why shouldn't he be pissed?
Proprietary isn't (always) evil!
-
Re:So...
Linus' views are here: http://www.realworldtech.com/forums/index.cfm?act
i on=detail&PostNum=3322&Thread=19&entryID=49354&roo mID=11
Here's a relevant extract:
Tridge's tool would have been useful
if that usage had been sanctioned by BitMover. But since
that tool ends up invalidating your right to use BK in
the first place, and since that tool can not replace
what BK did, then yes, the tool is pointless.
So you have three choices
- don't use the tool (which makes it useless)
- use the tool, but stop using BK (which makes it useless)
- use the tool _and_ use BK, which violates the BK
license
Two useless cases, and one outright license violation.
Now, let's look at a _constructive_ case: let's say that
Tridge had written a really good SCM. Now the choice would
be:
- use the tool (cool, that works)
- use BK (cool, that also works)
and everybody would be happy. If a developer wanted to
switch to Tridges hypothetical tool, BK comes with the
stuff needed to export your own data.
See? Open Office and Samba are both in that "happy" case.
You can use them and be happy. They are _useful_ tools.
They actually _replace_ the tool they were meant to replace,
rather than just hook into it in ways that are against
the license.
Do not assume I represent any side of the argument. I just thought you people should know his rationale. -
Torvalds takes a quick shot at Slashdot too
"I'll respond once just because RWT is not slash-dot." - Linus Torvalds flaming on Real World tech
-
Re:read the whole article, folks
This is not a debate about Openness. This is not a debate about Freedom.
Not true. For those on the Free Software side it is *exactly* about Freedom. The problem is the "pragmatists" the ones who are said to have "common sense" are the ones who are blind to the concerns of the other side. Have you read Linus's responses to the allegations brought up in this thread?
Look here.
In one of the responses, Linus says:
Tridge's tool would have been useful
if that usage had been sanctioned by BitMover. But since
that tool ends up invalidating your right to use BK in
the first place, and since that tool can not replace
what BK did, then yes, the tool is pointless.
So you have three choices
- don't use the tool (which makes it useless)
- use the tool, but stop using BK (which makes it useless)
- use the tool _and_ use BK, which violates the BK
license
Two useless cases, and one outright license violation.
Now just about any FS person out there will have an enormous problem with this. Why? Because amazingly, Linus had little concern over the freedom of the code/data. Being required to use BK and agree to its license is not even an issue in his mind. In Linus's mind Tridge's tool was pointless because it didn't replace BK, but most FS people, probably beginning with Alan Cox, who refused to use BK from the start, would tell you that the crucial point all along was being able to access the repository code/data of the kernel source code WITHOUT HAVING TO USE BK OR AGREE TO ITS ONEROUS LICENSE (his point #2 above is wrong). In their minds, Tridge's tool is FAR from pointless, its value lies in its ability to retrieve what arguably *belongs* to them without having to agree to terms they find unethical or reprehensible. It was never meant to be a replacement of BK, but something that would allow them to retrieve the data for migration to another SCM when the time came. This concern is not even on Linus's radar, it doesn't occur to him even now.
When Linus chose to start using BK, he wasn't the sole author of the kernel anymore, hundreds of contributors were involved by then, and Linus was well aware that many of them had strong views about BK and that there would be problems in the future. He chose the pragmatic route and used proprietary software for a free software project, indirectly forcing Free Software people to rely on a system for their own Free code that itself wasn't free. Sadly, I have to agree with the one previous poster that had the courage to say the raw truth: if *anyone* is to blame for the mess we have now, its Linus himself, not Tridge. To use the Matrix analogy, Linus created the flaw, or imperfection, in the system, and that made the creation of a "Neo" at some point in the future inevitable. We know RMS saw this coming from the get-go, but if we go back to the LKML archives at the time, I would not be at all surprised if several other Linux developers outside the FS camp didn't end up predicting the coming of Tridge back then too.
I am not trying to denigrate Linus, far from it, you have to respect his enormous programming skills, but when it comes to the larger issues of the use of software in our society, its RMS and Moglen that I listen to, not Linus, because Linus doesn't really "get it". He's clearly "Open Source", and not "Free Software", and that's OK really, but he was working with a lot of FS people back then, so for a guy famous for being able to herd cats, he simply did not (and seemingly still doesn't) understand half of his "cats" well enough to realize that the use of BK was guarantteed to be a disaster in the making.
This isn't really worth an argument now, and I'm not here to bash Linus, and especially not to open up the FS vs OS fight again, but please stop bashing Tridge (not to the parent, but many previous posts), there is enough blame to go around on this one. Lets move on. -
Linus replies
-
Re:Do you have a source for the 120M transistors ?
Keep in mind that the Montecito has 24MB of L3 cache, plus 2.5MB of L2 and 32K of L1 cache. You also need to include links between the two cores, the cores themselves, tags, bus interface and arbiter, plus redundant SRAM cells so that one or two defects doesn't render the die worthless.
I don't know how many additional SRAM cells Intel is planning in each of the cache levels, so the 1.2B transistors for cache can climb up to 1.4-1.6B.
Someone posted a number of 1.47B transistors for the L3 cache at Real World Tech. I'm not sure how credible or accurate that number is.
Another article on RWT shows approximate die floor plan and othat info at:
http://www.realworldtech.com/page.cfm?ArticleID=RW T100404214638&p=4 -
Re:Do you have a source for the 120M transistors ?
Keep in mind that the Montecito has 24MB of L3 cache, plus 2.5MB of L2 and 32K of L1 cache. You also need to include links between the two cores, the cores themselves, tags, bus interface and arbiter, plus redundant SRAM cells so that one or two defects doesn't render the die worthless.
I don't know how many additional SRAM cells Intel is planning in each of the cache levels, so the 1.2B transistors for cache can climb up to 1.4-1.6B.
Someone posted a number of 1.47B transistors for the L3 cache at Real World Tech. I'm not sure how credible or accurate that number is.
Another article on RWT shows approximate die floor plan and othat info at:
http://www.realworldtech.com/page.cfm?ArticleID=RW T100404214638&p=4 -
Re:CELL Supercomputer
Sorry but the CELL potential for 25GFlops single precision not double.
Nope , it's 256 GFlops single precision. 25 GFlops is for double precision. Granted, this is only for highly parallizable code, but what else does someone use a 1000+ node supercomputer for? -
Re:Blow by Sony? Hahaha
Can post a link to these "official statenements". Sony hasn't officially disclosed details about PS3.
BTW. Real World Technologies has some estimates for the power consumption of Cell:
"The power consumption characteristics of the processor were not disclosed by IBM. However, estimates in the range of 50 to 80 Watts @ 4 GHz and 1.1 V were given."
Changes of PS3 having four 8 SPE Cells are zero (unless Sony will ship canister of liquid nitrogen with it). -
Re:I'll believe it when I see itAccording to the paper the per stage circuit delay is 11 F04 throught the entire design.
Figure 2 - Per stage circuit delay depth of 11 FO4 often left only 5~8 FO4 for logic flow
The author of the article seems to think an 11 F04 is pretty aggressive.