About the calculus for the project
About the calculus for the project
Posted Feb 9, 2012 22:03 UTC (Thu) by landley (guest, #6789)In reply to: About the calculus for the project by marcH
Parent article: A tempest in a toybox
I worked at a place that checked all the source code into horrors like "Accurev", "Rational", or whatever that one beginning with a P is I've blotted out. Starting with a tarball (no history beyond that) and checking in local changes on top of that.
Then the _fun_ ones go on to check the _result_of the build into a _second_ source control system, populated entirely with binaries and tracking the root filesystem layout (or RPM binaries, or whatever they ship).
Impedence matching between the first source control system and the second source control system is entirely ad-hoc. Bonus points if they're different technologies left over from a department merger and/or partial migration that never removed the "legacy" system. (Adding new one in parallel: easy. Removing old one: hard.)
I didn't fight with this stuff in a license enforcement context. I fought with it in a "I'm working a 3 month contract to fix accumulated customer bugs in a legacy system they've forgotten how to _build_. They have partial source code for their product, but no longer have the context it built in and the people who did this moved on years ago" context.
It's lucrative, yet horrible. (I remember a contract at Dell where they paid Red Hat to support Red Hat Enterprise 2 _after_ it was end of lifed because they'd done shared libraries in C++ which did an "extern C" around all their library exports and then returned a pointer to a class instance, so all the funky name mangling changes between gcc versions bit them on the nose and they either had to upgrade bangalore, raleigh, and austin all at the same time _and_ ship a flag day release to all customers (of this funky high-end SAS array diagnostic/monitoring tool) or stick with the old compiler forevermore. They got _into_ that state because nobody had realized the full ramifications of their build. Getting a handle on the real dependencies and reproduction sequence of modern software builds is _hard_, at least when the FSF was ever involved in any way. Grub 2. *shudder*)
The real world is messy. This is not new. You're talking about BusyBox, a project that at one point had FIVE shell implementations that didn't share code. If _we_ couldn't get that cleaned up in the first decade of the project's existence, why the heck are you holding others to a higher standard?
Rob
Posted Feb 10, 2012 14:30 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (3 responses)
This is just natural selection. Bye. It will incidentally make room for higher quality software and more interesting jobs - I'm sure you will like it.
This might delay a bit the release of the next great smartphone/set top box/you name it - we will all survive.
Poor attempts to ask the "community" to rewrite this or that piece under a BSD license for you are laughable and you will buy very little time (assuming they succeed in the first place).
Once again: nothing GPL-specific in the above.
Posted Feb 10, 2012 16:11 UTC (Fri)
by landley (guest, #6789)
[Link] (1 responses)
Let the backpedaling commence.
Posted Feb 10, 2012 16:45 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
No.
The copyright system is not perfect and probably too hard but it's fair and basically working. The current patent system is completely broken and totally unfair.
Imagine you write some code, then I copy and massage a few lines of it and bang I get the copyright on the whole thing. This is how the copyright system would look like if it were managed by the USPTO.
Posted Feb 12, 2012 15:44 UTC (Sun)
by nix (subscriber, #2304)
[Link]
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project