5 ms·

Furthermore, Linus wasn't just moving off of BitKeeper, he had to and quickly. Tridge (another kernel dev) reversed BK protocol and repo structure, as trivial

Furthermore, Linus wasn't just moving off of BitKeeper, he had to and quickly. Tridge (another kernel dev) reversed BK protocol and repo structure, as trivial as they were. BK people got understandably upset about this, in part because they were providing BK to the Linux Kernel Project for free. So Tridge's little stunt basically killed any and all goodwill between BK and LKP and Linus needed a replacement. All alternatives had issues and everyone just kept going in circles, bitching and moaning. So in a true programmers way Linus sat down and wrote what he wanted. The end.

michaelmrose 10y ago
The first mistake was for a free software project to require a proprietary one to participate in development. Bitkeeper's sole claim of ownership moral or legal was to the bitkeeper software which nobody violated. What Tridge did was come up with another way for the owners of the relevant data to access their own information something wholly reasonable and justified. What you dismiss as a stunt proved in a stroke how much of a mistake the relationship with Bitkeeper was. This is approximately like sony records telling you that you can't take your cd and put it in a Samsung stereo and you defending sony except no reasonable person supposes that creators of material objects aquire moral rights to control the use thereof.
- geezerjay 10y ago
  > The first mistake was for a free software project to require a proprietary one to participate in development. This isn't true at all. Anyone could download the source code, tweak it, and submit patches. You can even use your own version control system to track your changes. The project managers may have used bitkeeper, but to everyone else the only thing that bitkeeper provided was, at best, convenience.
  - gcp 10y ago
    It's detrimental to the openness of a project if the maintainers and core contributors have other, better tooling than the rest of the world.
    - geezerjay 10y ago
      The tooling wasn't better. It was just different. It's also entirely irrelevant if people use different tools to do their job. No one was hindered by anyone else's personal choice of tools. Anyone in the world was free to download the source code, change it, and contribute patches if they seed fit. Bitkeeper did not hindered this, nor did the linux development process changed once bitkeeper was replaced.
      - gcp 10y ago
        The tooling wasn't better. It was just different. BitKeeper was better than the alternatives. This was literally Linus' rationale for using it. Nothing what you say in the second paragraph contradicts what I said, but it also doesn't address the point at all. Do you understand why a difference in tooling and ease of working reduces openness?
  - michaelmrose 10y ago
    This is extremely disingenuous. Pretending that the primary workflow of a group and metadata about its work amounts to convenience seems poorly thought out on your part.
- huhtenberg 10y ago
  What Tridge did was something to prove a point rather than to make a feasible BK alternative, so it was ultimately a stunt. I don't dismiss the importance of it and LKP should've not indeed depend on a proprietary tool, but it was one of less civil ways to go about the issue.
  - michaelmrose 10y ago
    Why ought someone expect people to be worried about politeness insofar as accessing their own data. Conflict solely existed based on a badly thought out expectation on the part of bitkeeper. If you look at the reaction this wasn't going to be something that could be delicately handled in any case.
  - vacri 10y ago
    Stunt? Here is the description of the oh-so-cunning reverse engineering: Tridgell telnetted to the port and typed 'help': https://lwn.net/Articles/132938/ https://lwn.net/Articles/132938/
    - huhtenberg 10y ago
      He did a lot more that just issuing a command over a telnet session. Google for "SourcePuller".
      - 0x0 10y ago
        The sourcepuller code looks almost trivial, at least for the clone operation? http://sourcepuller.cvs.sourceforge.net/viewvc/sourcepuller/sp/clone.c?revision=1.1.1.1&view=markup http://sourcepuller.cvs.sourceforge.net/viewvc/sourcepuller/... https://lwn.net/Articles/132938/ https://lwn.net/Articles/132938/
      - gcp 10y ago
        That's the implementation of the result. Not sure what your point is.
    - mioelnir 10y ago
gcp 10y ago
Tridge (another kernel dev) reversed BK protocol and repo structure...So Tridge's little stunt He made a connection to the BitKeeper server and typed "help". https://lwn.net/Articles/132938/ https://lwn.net/Articles/132938/ The BitKeeper developer was an ass, not need to be polite about it. He issued DMCA requests to websites that were analyzing his license, claiming that it was copyrighted.
- huhtenberg 10y ago
  https://news.ycombinator.com/item?id=12966429 https://news.ycombinator.com/item?id=12966429
  - gcp 10y ago
    This just supports what I said. Not sure you looked closely enough. BitKeeper uses SCCS format on the wire, which didn't need to be reverse engineered as it was a known format.

michaelmrose 10y ago

The first mistake was for a free software project to require a proprietary one to participate in development. Bitkeeper's sole claim of ownership moral or legal was to the bitkeeper software which nobody violated. What Tridge did was come up with another way for the owners of the relevant data to access their own information something wholly reasonable and justified. What you dismiss as a stunt proved in a stroke how much of a mistake the relationship with Bitkeeper was. This is approximately like sony records telling you that you can't take your cd and put it in a Samsung stereo and you defending sony except no reasonable person supposes that creators of material objects aquire moral rights to control the use thereof.

geezerjay 10y ago
> The first mistake was for a free software project to require a proprietary one to participate in development. This isn't true at all. Anyone could download the source code, tweak it, and submit patches. You can even use your own version control system to track your changes. The project managers may have used bitkeeper, but to everyone else the only thing that bitkeeper provided was, at best, convenience.
- gcp 10y ago
  It's detrimental to the openness of a project if the maintainers and core contributors have other, better tooling than the rest of the world.
  - geezerjay 10y ago
    The tooling wasn't better. It was just different. It's also entirely irrelevant if people use different tools to do their job. No one was hindered by anyone else's personal choice of tools. Anyone in the world was free to download the source code, change it, and contribute patches if they seed fit. Bitkeeper did not hindered this, nor did the linux development process changed once bitkeeper was replaced.
    - gcp 10y ago
      The tooling wasn't better. It was just different. BitKeeper was better than the alternatives. This was literally Linus' rationale for using it. Nothing what you say in the second paragraph contradicts what I said, but it also doesn't address the point at all. Do you understand why a difference in tooling and ease of working reduces openness?
- michaelmrose 10y ago
  This is extremely disingenuous. Pretending that the primary workflow of a group and metadata about its work amounts to convenience seems poorly thought out on your part.
huhtenberg 10y ago
What Tridge did was something to prove a point rather than to make a feasible BK alternative, so it was ultimately a stunt. I don't dismiss the importance of it and LKP should've not indeed depend on a proprietary tool, but it was one of less civil ways to go about the issue.
- michaelmrose 10y ago
  Why ought someone expect people to be worried about politeness insofar as accessing their own data. Conflict solely existed based on a badly thought out expectation on the part of bitkeeper. If you look at the reaction this wasn't going to be something that could be delicately handled in any case.
- vacri 10y ago
  Stunt? Here is the description of the oh-so-cunning reverse engineering: Tridgell telnetted to the port and typed 'help': https://lwn.net/Articles/132938/ https://lwn.net/Articles/132938/
  - huhtenberg 10y ago
    He did a lot more that just issuing a command over a telnet session. Google for "SourcePuller".
    - 0x0 10y ago
      The sourcepuller code looks almost trivial, at least for the clone operation? http://sourcepuller.cvs.sourceforge.net/viewvc/sourcepuller/sp/clone.c?revision=1.1.1.1&view=markup http://sourcepuller.cvs.sourceforge.net/viewvc/sourcepuller/... https://lwn.net/Articles/132938/ https://lwn.net/Articles/132938/
    - gcp 10y ago
      That's the implementation of the result. Not sure what your point is.
  - mioelnir 10y ago

gcp 10y ago

Tridge (another kernel dev) reversed BK protocol and repo structure...So Tridge's little stunt He made a connection to the BitKeeper server and typed "help". https://lwn.net/Articles/132938/ https://lwn.net/Articles/132938/ The BitKeeper developer was an ass, not need to be polite about it. He issued DMCA requests to websites that were analyzing his license, claiming that it was copyrighted.

huhtenberg 10y ago
https://news.ycombinator.com/item?id=12966429 https://news.ycombinator.com/item?id=12966429
- gcp 10y ago
  This just supports what I said. Not sure you looked closely enough. BitKeeper uses SCCS format on the wire, which didn't need to be reverse engineered as it was a known format.