And here I think we get to the root of it. I commend you for saying straightforwardly what a number of other posters seem to be unable to admit they think.
But given that, I think this whole flap is still ridiculous. If Linus is such a fool, should he really be in charge? It seems to me that those who feel him incompetent should do something about that, like creating a governing body (like, say, the Apache Foundation has) and, if necessary, forking.
Or if it's just one decision that a portion of the community thinks is bad, then I'm disappointed that so many people think that just underminding Linus is a good approach, rather than something more open and honest.
Question -- if one accepts that Larry is has a right to prohibit any reverse-engineering by fiat, isn't that denying Andrew's right to reverse-engineer?
I don't think Larry has that right. I don't think anybody has claimed otherwise; I sure haven't. I agree that Tridgell had a right to reverse engineer whatever he pleases. The question is about how he chose to exercise that right, and what effects it had. We both have the legal right to say anything we want, but we both know that doesn't excuse us from accepting responsibility for what how we say affects people.
Appeasement never, never works. Domineering personalities just take further advantage.
Appeasement frequently works. It's part of the normal give and take of human relations. It may not work, as you say, with people with diagnosable personality flaws, but used in moderation it's helpful. As to whether or not McVoy is irrevocably and solely a "domineering personality", I doubt either of us is qualified to diagnose mental disorder, and even if we were, we don't have enough information.
I note, though, that he had no problem exporting a copy of the kernel tree for Linus, which suggests that he's not quite the grasping, power-mad monster you seem to think him.
He is, in effect, now advocating against Samba, against OpenOffice, against so much of the software developed using reverse-engineering due to uncooperative vendors.
Here you're just putting words in Linus's mouth. He said no such thing. If that's the only way you can interpret it, well, that's the only way you can intepret it. But if you try hard, I'd bet you can come up with other things he could have meant. I sure can. If you can't, try asking him what he meant.
From your silence on the topic, I gather that you were also just guessing at the answers to my questions for Tridgell.
That's a good example of snide innuendo. From you.
It's snide commentary about other people's posts, not about Tridgell's actions. And I don't see any innuendo there: I'm not being subtly, secretly derogatory about those other posters; I'm mocking their fundamentalist views quite openly.
Hopefully, Tridgell held to none of those positions, as I think they're all ridiculous, and I think he's smarter than that. I look forward to finding out one day.
In fact, it's quite apparent that the core kernel team is generally happy with the development
I'll take your word on that. Linus sure didn't seem to be. It'd be nice if they could have worked out their disagreements in some more civilized fashion.
[...]looking forward to the emergence of a really good, fully open tool
I've been looking forward to the emergence of a really good, fully open SCM tool for more than a decade. Presumably every open source programmer looks forward to that. I imagine I'll be waiting another decade, and it's not clear to me that throwing a monkey wrench into Linus's efforts will speed that up.
I note that for all the bitching about BitKeeper, I haven't heard of a lot of people working on, say, Subversion in a push to get it ready for moving the kernel there. If you have evidence otherwise, I'd love to hear it.
For some it goes much further than that. Personally, I feel deeply indebted to Andrew.
Ok, maybe my standards for group dynamics between hardcore programmers are a little high, but this just strikes me as sad. If such a wide array of people, yourself included, aren't willing to abide by Linus's various decisions, I'd rather see people just honestly fork rather than cheering on people who undermine decisions they don't like.
I see your point, and I think it's reasonable, but I'm afraid I still don't agree.
Again, that was Larry's doing, not Tridge's. Larry is the one who chose to employ collective punishment.
Linus accepted BitKeeper and other help from BitMover knowing that McVoy was a bit of a loon, and knowing how he felt about reverse engineering and using his work to compete with BitMover. But I presume he thought that McVoy was a loon he could work with, and given what Linus and McVoy had to say, that still seems to be the case.
I'll grant that Larry's terms are weird and probably counterproductive, but Linus thought they were, for the moment, acceptable. If Tridge didn't initially know about the terms, including McVoy's ability to withdraw the licenses if he felt he was getting a raw deal, then I'm guessing Linus explained it to him as part of asking him to stop work on his BitKeeper clone.
At that point he should have known that no good could have come of continuing. He continued to provoke McVoy, and for no benefit that I can see; Linus got McVoy to export the kernel tree without using Tridgell's work. I'm not denying Tridgell's legal right to reverse-engineer the protocol, but I think doing it in a way that got McVoy to cancel the free BitKeeper product and to get Linus's and OSDL's licenced cancelled to boot was a lame thing to do to Linus.
Assuming that's what happened, of course. I'd like to hear Tridgell's side of this.
apparently Tridge felt a calling to save the Linux kernel from that poor dupe of McVoy's, Linus Torvalds.
That's the way _I_ see it, from a long-term strategic point of view. I think Tridge was just trying to ensure that it was actually possible to migrate the change history and metadata to another SCM without going through the lossy CVS gateway.
Which is a plausible theory, but it's not clear to me why it's Tridge's place to override Linus's decision about what SCM system Linus uses. If Tridge wants the wheel so badly, he should fork and be done with it.
It looks like he was threatened with legal action and lawyered up, hence he isn't able to talk about it in detail yet.
Again, that's a plausible theory. But we don't actually know. And likely his lawyer would have let him say, "On the advice of my attorney [...]" or "Although I can't address the specifics, I regret the trouble I've caused for Linus and other kernel developers, as that wasn't my intention.
I see you are not interested in answers, only in promulgating more snide innuendo.
No, I'm actually interested in real answers. The snideness (sorry, I didn't see any innuendo in the post) comes from dealing with the 15 other people who have replied to my posts on this topic, including ones that suggest that I condone wife-beating; that the only thing I could possibly be in favor of is jackbooted corporate oligarchy; 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.
So if you have actual facts about Andrew Tridgell's intentions and current mind state, which is what I started this thread asking for, great, bring 'em on. I took you for yet another person making up guesses based on a religious (as opposed to pragmatic) devotion to software freedom, and if that's incorrect, I apologize.
You missed the point BIG TIME. Tridge did not do jack except to create. McVoy slowed down kernel development by taking away.
You don't blame somebody for doing something positive and constructive just because somebody else may get upset and throw down. How hard is that to comprehend?
No, I would blame thusly. Because if it went down as you're implying, then he in the end he didn't do something positive and constructive, no matter what his intentions were.
The actual benefit (some half-finished software for extracting info from BitKeeper servers) does not seem to come close to the actual costs (wasting Linus's time arguing with McVoy, wasting the time of a lot of kernel developers as they switch to some inferior repository, wasting OSDL's time as they switch to a new repository, triggering the cancelation of the free version of BitKeeper).
As technologists, we have should the right to create whatever technology we want. But as people working in the broader world, we have the obligation to consider the effects of our efforts. We also have the right to free speech, but we have to accept the consequences when we say something dumb, even if it seemed like a clever thing to say at the time.
I'd really like to give Tridgell credit for his good intentions, and it's possible that this is really part of some broader plan that will, in the end, create some net good for the world despite the costs. It'd be nice if he'd speak for himself to let us know what he was thinking.
Hmm, but that's not really testing the GUI directly.
This is true. If you're going for theoretical purity, that might be necessary. In a commercial effort, though, you're more interested in bang for the buck.
If you instrument your controller code (which is often easiest) then you catch all bugs except for GUI toolkit ones and in connecting the GUI library to your app, which is, I understand, not a big source of bugs, as it's simple stuff that programmers tend to hand-test pretty well.
If you go further and instrument the GUI components, then you catch everything except bugs in the GUI components themselves. If that's a big source of bugs, the first step is to unit-test your GUI components.
To take it further still, you can do screen capture and analysis. Bugs from there would be in low-level drivers and in your display hardware. Only if you're getting bugs in that would you need to do automated web-cam stuff.
Either screen-capture or artificial vision stuff would be a huge effort. To make useful tests, you'll need to come up with the same model as the GUI toolkit, but soley by looking at output. I'd estimate this as 2-5x the work of writing those GUI components from scratch. If you GUI library really sucks that much, automated vision isn't the solution; you should just spend a year or two writing a reliable one.
And even if you do build the automated vision stuff (which should include faking the mouse and keyboard, natch), it will test functionality, not aesthetics. And it will only test the things you specify; it won't notice other things wrong. For truly complete end-to-end tests, you need an artificial human, with skills equivalent to your graphic designer, your product manager, your programmers, and your QA people. Those are really expensive to build.
Which is why it's the advice of people who do a lot of test-driven development with GUI apps to do your end-to-end tests at a level just below the GUI layer, with a very thin layer on top. That way you test 99% of your code for a lot less effort then testing the whole thing. Then you catch the rest of the bugs through casual use and either frequent releases or manual QA.
It may be possible to develop something that actually verifies the entire system - software and hardware - that the Ask Slashdot question mentioned.
Sure! And if we're talking over beers, I'm happy to fill a whole stack of napkins with sketches for this sort of thing. But the guy has a practical problem in a commercial environment, so I pointed him at the practical, cost-effective approaches for bug reduction.
Are you speaking for Tridgell? Or are you another person guessing at his motivations? If the latter, I think I've addressed most of your comments elsewhere, as people have made similar guesses. I'm not so interested in the guesses, really; as it said in my post with the questions, I could also make up plausible-sounding answers.
Sorry, it was BitKeeper that screwsd up kernel development by creating this mess. Which anybody with a clue could see coming years ago.
Sorry, I'm not buying this. If you want to blame somebody other than Tridgell, blame Linus and OSDL, who accepted those terms. I think BitKeeper's policies are screwy, but they have a right to license their code any way they like, just like we have the right to license stuff via GPL. The problem isn't with the person who offers code for free under certain terms, it's with the person who accepts the license.
But if anybody could see this coming years ago, then it's still not clear to me why Tridgell, who presumably could also see this coming, chose to trigger this crisis, despite Linus asking him to stop. He seems to be a smart guy who has certainly done a lot of good work, so I'm trying to presume he had a good reason. But his statement, on top of McVoy's and Linus's, doesn't give me a lot to work with.
Sorry, I'm not buying this. I agree that McVoy's too tightly wound on this topic, and I think his attitude is bad for his business.
But really, it's his business. When Linus, et al, started using BitKeepker, they knew the terms and accepted them. Linus still doesn't seem to have a problem with them, and apparently worked well with McVoy. It wasn't Tridge's place to go screwing with that deal. I could buy that his initial foray was a well-intentioned effort, but I don't understand why he chose to keep going after Linus asked him to stop.
The way you explain it, apparently Tridge felt a calling to save the Linux kernel from that poor dupe of McVoy's, Linus Torvalds. If that's the case, that's pretty sad. If somebody is really that unhappy with how Linux kernel development is being done, I'd say they should just fork it, rather than messing with somebody's happy situation.
But I'm not convinced that's what went through Tridgell's head. I'd like to hear his side of it. It's a shame he gave out such a lame statement.
husband beats his wife
Uh, yeah. The situations are completely equivalent. We all saw Linus's bruises, and we never realized. "I just bumped into a door," he told us. That bastard McVoy!
So, basically Tridge should be grateful to his propreitary overlords for their product, rather than getting uppity and attempting to write compatible free software?
Propreitary overlords? Linus picked the tool, and could have unpicked it at any time. Other people do kernel development without using it at all. If Tridgell has a beef with somebody, it should be with Linus.
Now if Tridge just wanted to improve the state of kernel development, he did a pretty poor job of it. And if he didn't care about the kernel and just wanted to reverse engineer BitKeeper, then perhaps he could have picked somewhere other than OSDL to do it.
Or if his goal was really to improve the state of open-source SCM, then maybe he could have buckled down and started his own project. Or he could have done work to add BitKeeper features to SVN. Starting on an open-source BitKeeper tool seems weird to me, and continuing after Linus asked him to stop seems especially weird. I look forward to hearing his explanation.
Aside from finding that situation unacceptable on the face of it, I imagine Tridge also worried that Larry would continue to tighten the noose over time. From what I've heard from other people who have actually had to deal with him, it's not an unfounded concern.
I grant that McVoy's a bit of a loon. On the other hand, he's also struggled to build a business competing against larger, better-funded companies, which would certainly make him a little defensive. I'm not sure which is the cause of him flipping out, but I imagine it's a bit of both.
But either way, if Tridge felt that Linus was making a bad decision, the right thing to do was argue with Linus. Or even better, to spend the time to produce something that's both as good as BitKeeper and also free (libre), so that Linus was compelled to switch by the quality of his work. But forcing Linus off of his chosen SCM system and providing no decent alternative was either amazingly jerky or a huge miscalculation. I hope it's the latter.
And really, if we in the open-source community are going to build exact clones of other people's products rather than building new, innovative stuff, then I'd rather see us go after large, sinister companies that work against open source, rather than small ones that spend time and money helping Linus out.
Whether screwing up... Man, that's rude. He was trying to supplement the process
Let's grant that he was intending to supplement the process, that his heart was only filled with love, kindness, and puppylike eagerness to help. That still doesn't mean that he didn't screw up the kernel development process. And given that Linus Torvalds came to him and asked him to stop "supplementing", it seems to me that he should have some inkling that he wasn't being so helpful.
Regardless, I'd like to hear his side of the story. Maybe he'll have some great "it's all worth it because of X" explanation. Maybe he'll just say, "I thought it was a good idea, but now I'm sorry I caused so much trouble for Linus and other kernel developers." I dunno, and all of Slashdot's guesses don't get us much closer to knowing.
Maybe he was just exercising his legal right to reverse engineer software for the purposes of interoperability in order to accomplish a useful goal that was not provided for by BitMover?
Maybe. I'm having trouble imagining what useful goal was served given the outcome. But legal right alone isn't much of a defense in my mind. All of Slashdot has the legal right to free speech, but that doesn't keep us from heaping scorn on people who say dumb things. A big question for me is whether he wisely used his right, assuming that OSDN didn't violate their licence in giving him access, to clone McVoy's software.
This guy is smart. He has also provided great value to the community. Don't be so quick to write him off.
I'm not writing him off. The post you're responding to is a series of questions I'd like to see him answer so that I can find some good in what he's done.
Tridge tried to reverse engineer, legally and rightly
I don't think anybody here is disputing that he has a legal right to reverse-engineer a product. But I do wonder whether it was wise, as I don't see what we gained in exchange for the costs he's imposed on Linus and the other kernel maintainers who used BitKeeper.
provide actually free (as in freedom) ways to interoperate with the CMS hosting the linux kernel, you know, that kernel that GPL hippies love so much (there is the positive gain that was to be obtained).
Yeah, well it didn't work out that way. And once he got warned by his employer and by Linus Torvalds that he was causing trouble, you'd think he'd realize that maybe his plan was not so good. And as a bonus, he's managed to get BitMover to cancel their free product, so now there's no BitKeeper-compatible product that's either gratis or libre.
And Tridge is the one to blame for slowing down kernel development? Hello?
McVoy did not exactly keep his terms secret, and if Tridge didn't know them when he started, he sure knew them when he kept going. So yes, he's to blame. There were better ways to handle this, as Linus's interview comments make clear.
Larry McVoy has repeatedly insisted that the free version of BitKeeper was part of their competitive advantage.
I don't think him claiming it a competitive advantage and him thinking that he was doing something generous are mutually exclusive. People's motives are often thoroughly mixed, and McVoy doesn't strike me as a particularly introspective guy.
Say what? [...] Tridge did not (a) accept BitKeeper's generosity nor (b) "attack". He was working on building a tool that would compete with free BitKeeper.
Well, if Tridge is using the Linux kernel, it would seem that he is the beneficiary of McVoy's efforts. He's certainly benefiting from Linus's work, and Linus apparently made clear to Tridge that Tridge's work was putting Linus in a pickle. And McVoy certainly saw it as an attack; he even lists the reasons why. Whether or not it actually would have actually harmed BitMover (and I think McVoy, although a bit of a loon, is likely a better judge of that than we Slashdotters), it still puts it in biting-the-hand-that-feeds-you territory.
What exactly do you think should have gone differently here?
I think I said that in the post you answered, but if you have specific questions, don't hesitate to ask.
Basically you would like to know all about his motivations. Who the f*ck cares?
I do. It's an interesting issue.
As far ask I can tell, Tridge slowed down kernel development for everybody, and I'm not seeing any positive gain. I hope he has a better reason for it than your theory, "Because he wanted to." And I especially hope that you're wrong in thinking Tridge will stop his work on an open-source BitKeeper clone now. You paint him as a selfish prick whose only interest in the matter is to force Linus to conform to religious notions about license purity.
I'd hope that isn't the case. I'd like to think that Tridge had a better plan. Having dealt briefly with McVoy before and seen some of his other postings, I'm certainly predisposed to believe that McVoy's the bad guy in this tale. Until Tridge speaks up, though, I'm having a hard time seeing that.
Wow! An AC actually has a valid point! I'm going go buy a lottery ticket, just in case my luck holds.
I don't think anyone other than you has claimed that OSDL paid him to 'copy' Bit Mover's work. Every other account has them paying him for a completely unrelated matter.
You're right; I don't know that either way. If I could edit my comment, I'd change it to, "having somebody in the pay of OSDL copy his work". It'd be interesting to hear his side of it, in particular whether he was careful to use no OSDL resources in this. But from BitMover's perspective, there's probably not a lot of difference: either way, they feel like they're doing a lot to support Linus and OSDL, and one of their other employees goes out of his way to cause them trouble.
agreeing with McVoy means you assume reverse engineering is wrong
Hardly. I think the wrong here isn't the reverse engineering, even if that's what got McVoy's panties in a twist.
I think the wrong is accepting BitKeeper's generosity and then continuing to do things that attack the revenue model that keeps BitKeeper in business. The right thing to do would have been to let BitKeeper know that Linus, et al, were thankful for BitKeeper's help, but they switching over to a new, GPLed system. Then if BitKeeper were pricks about the switch, sure, reverse-engineering would have been fine.
This is pretty basic don't-bite-the-hand-that-feeds-you stuff, and I'm sad that it came to this. It doesn't look like the open-source community gained much, and aside from losing kernel productivity, we also have planted a big warning flag to any business that might want to give free licences to open-source projects.
The other guys told their side of the story. He could tell his. For example, I'd like to know
Why he thought it was important to start reverse-engineering BitKeeper, rather than any of the many more widely-used proprietary products out there,
Whether and why he's doing it on OSDL's nickel,
Why he kept going when, at least according to McVoy, OSDL promised he'd stop while they negotiated,
Whether screwing up Linux kernel development was worth whatever it is he thinks he's achieved,
Why reverse-engineering the BitKeeper project was the only way to achieve his goals,
Whether he'll keep going with the project now that the kernel won't be in BitKeeper format anymore.
There could be great answers to all of these things. I could even make up some reasonable guesses. But until he speaks up, we'll never know. Maybe he has a genius master plan to advance open-source projects everywhere, the Linux kernel included. Maybe he's just an ultra-dork obsessed with his legal right to reverse-engineer something, giving no thought to the practical results. I hope for the former, but based on what Linus and McVoy said, I fear it's the latter.
Somebody modded a perfectly good comment down as a troll. Perhaps they took it the wrong way. If I had mod points, I'd bump it back up. I don't, so I'm reposting it:
I'm going to disagree with you. It is immoral to reverse engineer while relying on the goodwill of the people you are reverse engineering. If you can't see that, I can't explain it any more clearly. -- winkydink
This seems pretty reasonable to me. I can understand how people have different opinions than BitKeeper's author, but his position isn't unreasonable. He went out of the way to support Linux kernel development, and he feels that having OSDL pay somebody to copy his work is a betrayal of his generosity.
Note that you will have to take the B.S. liberal arts classes, and not the interesting engineering classes.
Quick tip from somebody who hires geeks: those classes need not be BS.
If you want to use computers to solve real-world problems, knowing about computers isn't enough; you must know about the real world. Anthropology, history, business, political science, sociology, and economics all have parts that are directly applicable to most commercial software development.
Plus, you'll have a much better chance at jobs in certain industries if you have some background in them. The current poster child is bioinformatics. If in addition to your technical chops you know a fair about chemistry, biology, and/or medicine, you'll get a nice salary and the ability to play with cool, large-scale computing.
And when I'm interviewing people, I have a bias toward people with broad interests. Literature, music, philosophy, sports, and foreign languages are always a plus. Not only is that a good indicator that they have enough curiosity to get interested in what we do, but it also gives them common ground for connecting with people in the rest of the company. That communication is vital for building really kick-ass technical products.
I think you're reading more into his text than is warranted about how his feud with this gas station began. If you want to prove that his sole purpose is to be a jerk, you'll have to ask him.
You already know I disagree with your point about police attention. You seem to keep refusing to get my point that some people, inclined to be difficult, can put that to use to make things run better for those who aren't inclined to raise a fuss.
And I'm not so interested in discussing things with ACs, so if you want to keep this discussion going, get yourself an account.
I'm not saying that lesser crimes should be ignored, I'm saying that you shouldn't provoke a lesser crime in the first place just because you feel like being an asshole.
If the guy never would even want to pay with a fifty and is doing this solely to be a jerk, you might have a point. But the way I understand it, he wanted to pay with a fifty, they refused, and he pushed it. Subsequently, he refused to let them go back to their old policies. Sure, he could change his banking behavior to accommodate them. Equally, they could change their behavior to accommodate him. Since they are a) a business that's trying to get customers, b) legally obliged to take his money, and c) unreasonably and blindly following a policy, the choice seems pretty clear to me.
And really, even if the guy were doing this solely to be a jerk, my point is that he's being a jerk in a socially useful way. It might be a better world if people didn't have the urge to cause trouble, but given that the urge exists, I'd much rather see people channel it constructively. Some of the most difficult, annoying people I know ended up in high tech or as lawyers. They put most of their jerkiness into their work, and society is a better place for the work they do.
The consequences of his actions result in less cops chasing actual criminals.
This is probably untrue. It turns out that police dispatchers know that some things are more important than others. A call like this would only rise to the top of the queue if the cop were otherwise idle. Ten minutes stopped at a gas station versus ten minutes cruising up and down the street is probably a wash in public safety terms.
For what? Feeling superior to some lousy student behind the counter?
For increasing convenience for everybody, not just him. For getting people to follow the law. For getting clerks to act like people, not policy-following robots (or jobsworths as the brits call 'em). For making the world work ever so slightly better.
The state the guy posts from, Michigan, has another law, one where if something shows one price but the scanner charges you another, you get 10x the difference back. It's a great consumer protection law with a built-in enforcement mechanism. My mom regularly catches companies with this.
But by your logic, if they say no, she should just meekly go along, because cops have better things to do. In your framework, exactly how far should we take this? Until violent crime is ended, should I stop reporting thefts? Until all murders are caught, should I let a little assault go? I'm guessing not, but I'm not sure where you'd draw the line.
How do you test features that are easy for humans to observe, but not as easy for software to detect (ie, the light came on, the GUI updated when I pressed the external input, etc)?"
For the GUI, I recommend instrumenting your app so you can programatically tell what's going on. An API is one way, but a quick and dirty way is just to keep an internal event log and then probe that. Then for free, you get a detailed log you can dump if there's an error in production.
For the physical hardware, consider building a simulator. You could do it partly in hardware, adding simulation logic to your hardware controller, but running disconnected from the machinery. Or you could build another board that connects to your production board's inputs and outputs and simulates the machinery at an electrical level. Another option is to simulate your production board entirely, leaving the embedded code out of the testing loop.
The right choices depend a lot on where you can get the best bang for your test automation buck. Unfortunately, starting with a lot of untested legacy code means you have a long slog ahead of you. Start with the modules that generate the most bugs, or the bugs hardest to find during manual testing and automate your tests of those. That will teach you a lot about good ways to test in your environment.
The more expensive programmer will in the end catch more bugs with the regression test suite, so your code has less bugs when you ship. However it is expensive.
I think this can be true if you write your regression tests afterward. But if you're doing test-driven development, so that your app is designed from the beginning for testability, then I think the costs are pretty reasonable. In my experience, the time testing is more than made up for by the time and stress saved on debugging.
On a recent 9-month project, a team of four developers I know built a web application with no external testing, just self-written automated tests and product managers playing with the app. After six months in production, they've had a total of two reported bugs and no scheduled downtime.
Slashdot Mirror
he original of sex.com is quite wealthy in his own right (porn king)
I'm pretty sure that Gary Kremen, the original registrant of sex.com, got his money from founding the on-line personals site, match.com.
Linus was a fool
And here I think we get to the root of it. I commend you for saying straightforwardly what a number of other posters seem to be unable to admit they think.
But given that, I think this whole flap is still ridiculous. If Linus is such a fool, should he really be in charge? It seems to me that those who feel him incompetent should do something about that, like creating a governing body (like, say, the Apache Foundation has) and, if necessary, forking.
Or if it's just one decision that a portion of the community thinks is bad, then I'm disappointed that so many people think that just underminding Linus is a good approach, rather than something more open and honest.
Question -- if one accepts that Larry is has a right to prohibit any reverse-engineering by fiat, isn't that denying Andrew's right to reverse-engineer?
I don't think Larry has that right. I don't think anybody has claimed otherwise; I sure haven't. I agree that Tridgell had a right to reverse engineer whatever he pleases. The question is about how he chose to exercise that right, and what effects it had. We both have the legal right to say anything we want, but we both know that doesn't excuse us from accepting responsibility for what how we say affects people.
Appeasement never, never works. Domineering personalities just take further advantage.
Appeasement frequently works. It's part of the normal give and take of human relations. It may not work, as you say, with people with diagnosable personality flaws, but used in moderation it's helpful. As to whether or not McVoy is irrevocably and solely a "domineering personality", I doubt either of us is qualified to diagnose mental disorder, and even if we were, we don't have enough information.
I note, though, that he had no problem exporting a copy of the kernel tree for Linus, which suggests that he's not quite the grasping, power-mad monster you seem to think him.
He is, in effect, now advocating against Samba, against OpenOffice, against so much of the software developed using reverse-engineering due to uncooperative vendors.
Here you're just putting words in Linus's mouth. He said no such thing. If that's the only way you can interpret it, well, that's the only way you can intepret it. But if you try hard, I'd bet you can come up with other things he could have meant. I sure can. If you can't, try asking him what he meant.
From your silence on the topic, I gather that you were also just guessing at the answers to my questions for Tridgell.
That's a good example of snide innuendo. From you.
It's snide commentary about other people's posts, not about Tridgell's actions. And I don't see any innuendo there: I'm not being subtly, secretly derogatory about those other posters; I'm mocking their fundamentalist views quite openly.
Hopefully, Tridgell held to none of those positions, as I think they're all ridiculous, and I think he's smarter than that. I look forward to finding out one day.
In fact, it's quite apparent that the core kernel team is generally happy with the development
I'll take your word on that. Linus sure didn't seem to be. It'd be nice if they could have worked out their disagreements in some more civilized fashion.
[...]looking forward to the emergence of a really good, fully open tool
I've been looking forward to the emergence of a really good, fully open SCM tool for more than a decade. Presumably every open source programmer looks forward to that. I imagine I'll be waiting another decade, and it's not clear to me that throwing a monkey wrench into Linus's efforts will speed that up.
I note that for all the bitching about BitKeeper, I haven't heard of a lot of people working on, say, Subversion in a push to get it ready for moving the kernel there. If you have evidence otherwise, I'd love to hear it.
For some it goes much further than that. Personally, I feel deeply indebted to Andrew.
Ok, maybe my standards for group dynamics between hardcore programmers are a little high, but this just strikes me as sad. If such a wide array of people, yourself included, aren't willing to abide by Linus's various decisions, I'd rather see people just honestly fork rather than cheering on people who undermine decisions they don't like.
I see your point, and I think it's reasonable, but I'm afraid I still don't agree.
Again, that was Larry's doing, not Tridge's. Larry is the one who chose to employ collective punishment.
Linus accepted BitKeeper and other help from BitMover knowing that McVoy was a bit of a loon, and knowing how he felt about reverse engineering and using his work to compete with BitMover. But I presume he thought that McVoy was a loon he could work with, and given what Linus and McVoy had to say, that still seems to be the case.
I'll grant that Larry's terms are weird and probably counterproductive, but Linus thought they were, for the moment, acceptable. If Tridge didn't initially know about the terms, including McVoy's ability to withdraw the licenses if he felt he was getting a raw deal, then I'm guessing Linus explained it to him as part of asking him to stop work on his BitKeeper clone.
At that point he should have known that no good could have come of continuing. He continued to provoke McVoy, and for no benefit that I can see; Linus got McVoy to export the kernel tree without using Tridgell's work. I'm not denying Tridgell's legal right to reverse-engineer the protocol, but I think doing it in a way that got McVoy to cancel the free BitKeeper product and to get Linus's and OSDL's licenced cancelled to boot was a lame thing to do to Linus.
Assuming that's what happened, of course. I'd like to hear Tridgell's side of this.
Which is a plausible theory, but it's not clear to me why it's Tridge's place to override Linus's decision about what SCM system Linus uses. If Tridge wants the wheel so badly, he should fork and be done with it.
It looks like he was threatened with legal action and lawyered up, hence he isn't able to talk about it in detail yet.
Again, that's a plausible theory. But we don't actually know. And likely his lawyer would have let him say, "On the advice of my attorney [...]" or "Although I can't address the specifics, I regret the trouble I've caused for Linus and other kernel developers, as that wasn't my intention.
I see you are not interested in answers, only in promulgating more snide innuendo.
No, I'm actually interested in real answers. The snideness (sorry, I didn't see any innuendo in the post) comes from dealing with the 15 other people who have replied to my posts on this topic, including ones that suggest that I condone wife-beating; that the only thing I could possibly be in favor of is jackbooted corporate oligarchy; 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.
So if you have actual facts about Andrew Tridgell's intentions and current mind state, which is what I started this thread asking for, great, bring 'em on. I took you for yet another person making up guesses based on a religious (as opposed to pragmatic) devotion to software freedom, and if that's incorrect, I apologize.
You missed the point BIG TIME. Tridge did not do jack except to create. McVoy slowed down kernel development by taking away.
You don't blame somebody for doing something positive and constructive just because somebody else may get upset and throw down. How hard is that to comprehend?
No, I would blame thusly. Because if it went down as you're implying, then he in the end he didn't do something positive and constructive, no matter what his intentions were.
The actual benefit (some half-finished software for extracting info from BitKeeper servers) does not seem to come close to the actual costs (wasting Linus's time arguing with McVoy, wasting the time of a lot of kernel developers as they switch to some inferior repository, wasting OSDL's time as they switch to a new repository, triggering the cancelation of the free version of BitKeeper).
As technologists, we have should the right to create whatever technology we want. But as people working in the broader world, we have the obligation to consider the effects of our efforts. We also have the right to free speech, but we have to accept the consequences when we say something dumb, even if it seemed like a clever thing to say at the time.
I'd really like to give Tridgell credit for his good intentions, and it's possible that this is really part of some broader plan that will, in the end, create some net good for the world despite the costs. It'd be nice if he'd speak for himself to let us know what he was thinking.
Hmm, but that's not really testing the GUI directly.
This is true. If you're going for theoretical purity, that might be necessary. In a commercial effort, though, you're more interested in bang for the buck.
If you instrument your controller code (which is often easiest) then you catch all bugs except for GUI toolkit ones and in connecting the GUI library to your app, which is, I understand, not a big source of bugs, as it's simple stuff that programmers tend to hand-test pretty well.
If you go further and instrument the GUI components, then you catch everything except bugs in the GUI components themselves. If that's a big source of bugs, the first step is to unit-test your GUI components.
To take it further still, you can do screen capture and analysis. Bugs from there would be in low-level drivers and in your display hardware. Only if you're getting bugs in that would you need to do automated web-cam stuff.
Either screen-capture or artificial vision stuff would be a huge effort. To make useful tests, you'll need to come up with the same model as the GUI toolkit, but soley by looking at output. I'd estimate this as 2-5x the work of writing those GUI components from scratch. If you GUI library really sucks that much, automated vision isn't the solution; you should just spend a year or two writing a reliable one.
And even if you do build the automated vision stuff (which should include faking the mouse and keyboard, natch), it will test functionality, not aesthetics. And it will only test the things you specify; it won't notice other things wrong. For truly complete end-to-end tests, you need an artificial human, with skills equivalent to your graphic designer, your product manager, your programmers, and your QA people. Those are really expensive to build.
Which is why it's the advice of people who do a lot of test-driven development with GUI apps to do your end-to-end tests at a level just below the GUI layer, with a very thin layer on top. That way you test 99% of your code for a lot less effort then testing the whole thing. Then you catch the rest of the bugs through casual use and either frequent releases or manual QA.
It may be possible to develop something that actually verifies the entire system - software and hardware - that the Ask Slashdot question mentioned.
Sure! And if we're talking over beers, I'm happy to fill a whole stack of napkins with sketches for this sort of thing. But the guy has a practical problem in a commercial environment, so I pointed him at the practical, cost-effective approaches for bug reduction.
I'll try to provide some insight.
Are you speaking for Tridgell? Or are you another person guessing at his motivations? If the latter, I think I've addressed most of your comments elsewhere, as people have made similar guesses. I'm not so interested in the guesses, really; as it said in my post with the questions, I could also make up plausible-sounding answers.
Sorry, it was BitKeeper that screwsd up kernel development by creating this mess. Which anybody with a clue could see coming years ago.
Sorry, I'm not buying this. If you want to blame somebody other than Tridgell, blame Linus and OSDL, who accepted those terms. I think BitKeeper's policies are screwy, but they have a right to license their code any way they like, just like we have the right to license stuff via GPL. The problem isn't with the person who offers code for free under certain terms, it's with the person who accepts the license.
But if anybody could see this coming years ago, then it's still not clear to me why Tridgell, who presumably could also see this coming, chose to trigger this crisis, despite Linus asking him to stop. He seems to be a smart guy who has certainly done a lot of good work, so I'm trying to presume he had a good reason. But his statement, on top of McVoy's and Linus's, doesn't give me a lot to work with.
Larry did that, not Tridge.
Sorry, I'm not buying this. I agree that McVoy's too tightly wound on this topic, and I think his attitude is bad for his business.
But really, it's his business. When Linus, et al, started using BitKeepker, they knew the terms and accepted them. Linus still doesn't seem to have a problem with them, and apparently worked well with McVoy. It wasn't Tridge's place to go screwing with that deal. I could buy that his initial foray was a well-intentioned effort, but I don't understand why he chose to keep going after Linus asked him to stop.
The way you explain it, apparently Tridge felt a calling to save the Linux kernel from that poor dupe of McVoy's, Linus Torvalds. If that's the case, that's pretty sad. If somebody is really that unhappy with how Linux kernel development is being done, I'd say they should just fork it, rather than messing with somebody's happy situation.
But I'm not convinced that's what went through Tridgell's head. I'd like to hear his side of it. It's a shame he gave out such a lame statement.
husband beats his wife
Uh, yeah. The situations are completely equivalent. We all saw Linus's bruises, and we never realized. "I just bumped into a door," he told us. That bastard McVoy!
So, basically Tridge should be grateful to his propreitary overlords for their product, rather than getting uppity and attempting to write compatible free software?
Propreitary overlords? Linus picked the tool, and could have unpicked it at any time. Other people do kernel development without using it at all. If Tridgell has a beef with somebody, it should be with Linus.
Now if Tridge just wanted to improve the state of kernel development, he did a pretty poor job of it. And if he didn't care about the kernel and just wanted to reverse engineer BitKeeper, then perhaps he could have picked somewhere other than OSDL to do it.
Or if his goal was really to improve the state of open-source SCM, then maybe he could have buckled down and started his own project. Or he could have done work to add BitKeeper features to SVN. Starting on an open-source BitKeeper tool seems weird to me, and continuing after Linus asked him to stop seems especially weird. I look forward to hearing his explanation.
Aside from finding that situation unacceptable on the face of it, I imagine Tridge also worried that Larry would continue to tighten the noose over time. From what I've heard from other people who have actually had to deal with him, it's not an unfounded concern.
I grant that McVoy's a bit of a loon. On the other hand, he's also struggled to build a business competing against larger, better-funded companies, which would certainly make him a little defensive. I'm not sure which is the cause of him flipping out, but I imagine it's a bit of both.
But either way, if Tridge felt that Linus was making a bad decision, the right thing to do was argue with Linus. Or even better, to spend the time to produce something that's both as good as BitKeeper and also free (libre), so that Linus was compelled to switch by the quality of his work. But forcing Linus off of his chosen SCM system and providing no decent alternative was either amazingly jerky or a huge miscalculation. I hope it's the latter.
And really, if we in the open-source community are going to build exact clones of other people's products rather than building new, innovative stuff, then I'd rather see us go after large, sinister companies that work against open source, rather than small ones that spend time and money helping Linus out.
Whether screwing up... Man, that's rude. He was trying to supplement the process
Let's grant that he was intending to supplement the process, that his heart was only filled with love, kindness, and puppylike eagerness to help. That still doesn't mean that he didn't screw up the kernel development process. And given that Linus Torvalds came to him and asked him to stop "supplementing", it seems to me that he should have some inkling that he wasn't being so helpful.
Regardless, I'd like to hear his side of the story. Maybe he'll have some great "it's all worth it because of X" explanation. Maybe he'll just say, "I thought it was a good idea, but now I'm sorry I caused so much trouble for Linus and other kernel developers." I dunno, and all of Slashdot's guesses don't get us much closer to knowing.
Maybe he was just exercising his legal right to reverse engineer software for the purposes of interoperability in order to accomplish a useful goal that was not provided for by BitMover?
Maybe. I'm having trouble imagining what useful goal was served given the outcome. But legal right alone isn't much of a defense in my mind. All of Slashdot has the legal right to free speech, but that doesn't keep us from heaping scorn on people who say dumb things. A big question for me is whether he wisely used his right, assuming that OSDN didn't violate their licence in giving him access, to clone McVoy's software.
This guy is smart. He has also provided great value to the community. Don't be so quick to write him off.
I'm not writing him off. The post you're responding to is a series of questions I'd like to see him answer so that I can find some good in what he's done.
Tridge tried to reverse engineer, legally and rightly
I don't think anybody here is disputing that he has a legal right to reverse-engineer a product. But I do wonder whether it was wise, as I don't see what we gained in exchange for the costs he's imposed on Linus and the other kernel maintainers who used BitKeeper.
provide actually free (as in freedom) ways to interoperate with the CMS hosting the linux kernel, you know, that kernel that GPL hippies love so much (there is the positive gain that was to be obtained).
Yeah, well it didn't work out that way. And once he got warned by his employer and by Linus Torvalds that he was causing trouble, you'd think he'd realize that maybe his plan was not so good. And as a bonus, he's managed to get BitMover to cancel their free product, so now there's no BitKeeper-compatible product that's either gratis or libre.
And Tridge is the one to blame for slowing down kernel development? Hello?
McVoy did not exactly keep his terms secret, and if Tridge didn't know them when he started, he sure knew them when he kept going. So yes, he's to blame. There were better ways to handle this, as Linus's interview comments make clear.
Larry McVoy has repeatedly insisted that the free version of BitKeeper was part of their competitive advantage.
I don't think him claiming it a competitive advantage and him thinking that he was doing something generous are mutually exclusive. People's motives are often thoroughly mixed, and McVoy doesn't strike me as a particularly introspective guy.
Say what? [...] Tridge did not (a) accept BitKeeper's generosity nor (b) "attack". He was working on building a tool that would compete with free BitKeeper.
Well, if Tridge is using the Linux kernel, it would seem that he is the beneficiary of McVoy's efforts. He's certainly benefiting from Linus's work, and Linus apparently made clear to Tridge that Tridge's work was putting Linus in a pickle. And McVoy certainly saw it as an attack; he even lists the reasons why. Whether or not it actually would have actually harmed BitMover (and I think McVoy, although a bit of a loon, is likely a better judge of that than we Slashdotters), it still puts it in biting-the-hand-that-feeds-you territory.
What exactly do you think should have gone differently here?
I think I said that in the post you answered, but if you have specific questions, don't hesitate to ask.
Basically you would like to know all about his motivations. Who the f*ck cares?
I do. It's an interesting issue.
As far ask I can tell, Tridge slowed down kernel development for everybody, and I'm not seeing any positive gain. I hope he has a better reason for it than your theory, "Because he wanted to." And I especially hope that you're wrong in thinking Tridge will stop his work on an open-source BitKeeper clone now. You paint him as a selfish prick whose only interest in the matter is to force Linus to conform to religious notions about license purity.
I'd hope that isn't the case. I'd like to think that Tridge had a better plan. Having dealt briefly with McVoy before and seen some of his other postings, I'm certainly predisposed to believe that McVoy's the bad guy in this tale. Until Tridge speaks up, though, I'm having a hard time seeing that.
Wow! An AC actually has a valid point! I'm going go buy a lottery ticket, just in case my luck holds.
I don't think anyone other than you has claimed that OSDL paid him to 'copy' Bit Mover's work. Every other account has them paying him for a completely unrelated matter.
You're right; I don't know that either way. If I could edit my comment, I'd change it to, "having somebody in the pay of OSDL copy his work". It'd be interesting to hear his side of it, in particular whether he was careful to use no OSDL resources in this. But from BitMover's perspective, there's probably not a lot of difference: either way, they feel like they're doing a lot to support Linus and OSDL, and one of their other employees goes out of his way to cause them trouble.
agreeing with McVoy means you assume reverse engineering is wrong
Hardly. I think the wrong here isn't the reverse engineering, even if that's what got McVoy's panties in a twist.
I think the wrong is accepting BitKeeper's generosity and then continuing to do things that attack the revenue model that keeps BitKeeper in business. The right thing to do would have been to let BitKeeper know that Linus, et al, were thankful for BitKeeper's help, but they switching over to a new, GPLed system. Then if BitKeeper were pricks about the switch, sure, reverse-engineering would have been fine.
This is pretty basic don't-bite-the-hand-that-feeds-you stuff, and I'm sad that it came to this. It doesn't look like the open-source community gained much, and aside from losing kernel productivity, we also have planted a big warning flag to any business that might want to give free licences to open-source projects.
The other guys told their side of the story. He could tell his. For example, I'd like to know
There could be great answers to all of these things. I could even make up some reasonable guesses. But until he speaks up, we'll never know. Maybe he has a genius master plan to advance open-source projects everywhere, the Linux kernel included. Maybe he's just an ultra-dork obsessed with his legal right to reverse-engineer something, giving no thought to the practical results. I hope for the former, but based on what Linus and McVoy said, I fear it's the latter.
Somebody modded a perfectly good comment down as a troll. Perhaps they took it the wrong way. If I had mod points, I'd bump it back up. I don't, so I'm reposting it:
I'm going to disagree with you. It is immoral to reverse engineer while relying on the goodwill of the people you are reverse engineering. If you can't see that, I can't explain it any more clearly. -- winkydink
This seems pretty reasonable to me. I can understand how people have different opinions than BitKeeper's author, but his position isn't unreasonable. He went out of the way to support Linux kernel development, and he feels that having OSDL pay somebody to copy his work is a betrayal of his generosity.
Note that you will have to take the B.S. liberal arts classes, and not the interesting engineering classes.
Quick tip from somebody who hires geeks: those classes need not be BS.
If you want to use computers to solve real-world problems, knowing about computers isn't enough; you must know about the real world. Anthropology, history, business, political science, sociology, and economics all have parts that are directly applicable to most commercial software development.
Plus, you'll have a much better chance at jobs in certain industries if you have some background in them. The current poster child is bioinformatics. If in addition to your technical chops you know a fair about chemistry, biology, and/or medicine, you'll get a nice salary and the ability to play with cool, large-scale computing.
And when I'm interviewing people, I have a bias toward people with broad interests. Literature, music, philosophy, sports, and foreign languages are always a plus. Not only is that a good indicator that they have enough curiosity to get interested in what we do, but it also gives them common ground for connecting with people in the rest of the company. That communication is vital for building really kick-ass technical products.
I think you're reading more into his text than is warranted about how his feud with this gas station began. If you want to prove that his sole purpose is to be a jerk, you'll have to ask him.
You already know I disagree with your point about police attention. You seem to keep refusing to get my point that some people, inclined to be difficult, can put that to use to make things run better for those who aren't inclined to raise a fuss.
And I'm not so interested in discussing things with ACs, so if you want to keep this discussion going, get yourself an account.
I'm not saying that lesser crimes should be ignored, I'm saying that you shouldn't provoke a lesser crime in the first place just because you feel like being an asshole.
If the guy never would even want to pay with a fifty and is doing this solely to be a jerk, you might have a point. But the way I understand it, he wanted to pay with a fifty, they refused, and he pushed it. Subsequently, he refused to let them go back to their old policies. Sure, he could change his banking behavior to accommodate them. Equally, they could change their behavior to accommodate him. Since they are a) a business that's trying to get customers, b) legally obliged to take his money, and c) unreasonably and blindly following a policy, the choice seems pretty clear to me.
And really, even if the guy were doing this solely to be a jerk, my point is that he's being a jerk in a socially useful way. It might be a better world if people didn't have the urge to cause trouble, but given that the urge exists, I'd much rather see people channel it constructively. Some of the most difficult, annoying people I know ended up in high tech or as lawyers. They put most of their jerkiness into their work, and society is a better place for the work they do.
The consequences of his actions result in less cops chasing actual criminals.
This is probably untrue. It turns out that police dispatchers know that some things are more important than others. A call like this would only rise to the top of the queue if the cop were otherwise idle. Ten minutes stopped at a gas station versus ten minutes cruising up and down the street is probably a wash in public safety terms.
For what? Feeling superior to some lousy student behind the counter?
For increasing convenience for everybody, not just him. For getting people to follow the law. For getting clerks to act like people, not policy-following robots (or jobsworths as the brits call 'em). For making the world work ever so slightly better.
The state the guy posts from, Michigan, has another law, one where if something shows one price but the scanner charges you another, you get 10x the difference back. It's a great consumer protection law with a built-in enforcement mechanism. My mom regularly catches companies with this.
But by your logic, if they say no, she should just meekly go along, because cops have better things to do. In your framework, exactly how far should we take this? Until violent crime is ended, should I stop reporting thefts? Until all murders are caught, should I let a little assault go? I'm guessing not, but I'm not sure where you'd draw the line.
How do you test features that are easy for humans to observe, but not as easy for software to detect (ie, the light came on, the GUI updated when I pressed the external input, etc)?"
For the GUI, I recommend instrumenting your app so you can programatically tell what's going on. An API is one way, but a quick and dirty way is just to keep an internal event log and then probe that. Then for free, you get a detailed log you can dump if there's an error in production.
For the physical hardware, consider building a simulator. You could do it partly in hardware, adding simulation logic to your hardware controller, but running disconnected from the machinery. Or you could build another board that connects to your production board's inputs and outputs and simulates the machinery at an electrical level. Another option is to simulate your production board entirely, leaving the embedded code out of the testing loop.
The right choices depend a lot on where you can get the best bang for your test automation buck. Unfortunately, starting with a lot of untested legacy code means you have a long slog ahead of you. Start with the modules that generate the most bugs, or the bugs hardest to find during manual testing and automate your tests of those. That will teach you a lot about good ways to test in your environment.
The more expensive programmer will in the end catch more bugs with the regression test suite, so your code has less bugs when you ship. However it is expensive.
I think this can be true if you write your regression tests afterward. But if you're doing test-driven development, so that your app is designed from the beginning for testability, then I think the costs are pretty reasonable. In my experience, the time testing is more than made up for by the time and stress saved on debugging.
On a recent 9-month project, a team of four developers I know built a web application with no external testing, just self-written automated tests and product managers playing with the app. After six months in production, they've had a total of two reported bugs and no scheduled downtime.