When we had the Packaging Summit in Berlin last December, one of the klik guys gave a very good presentation. So, perhaps we can help the klik folks by providing a good baseline, and klik can help us by providing an alternative installation system.
]]>We put out a set of applications as a part of our test suite that run on every LSB-compliant distribution (and even a few that aren’t). These are not trivial applications; they include Celestia, Apache, Tcl/Tk, and, yes, Python. We’re getting ready to release specifications for desktop apps, and will release serious desktop apps at the same time, Gaim and Scribus among them.
My experience with the FSG is what leads me to call you “completely batty”. I should probably add “completely ineffectual”. Have you read the comments about you from everyone else, such as those I link to? Do you think all these people are now going to follow you around? What, in short, did you expect everyone to do when they read your rants?
And while you rant, I and my colleagues at the FSG have been making real progress towards fixing some of the problems you mention, by describing and testing distro behavior and getting them to fix the problems we find. It’s not perfect, but it’s progress. How much progress has your rant produced?
I had this problem with you the last time I posted. You come out with, basically, InstallShield for Linux, and think this gives you the right to slam on everyone who doesn’t agree with your approach. Well, OK. Maybe someone will come along with a bit less of a chip on his shoulder and make your work relevant to the rest of us.
]]>I work as a consultant for Linux Game Publishing and several other vendors and there’s all kinds of “fun” things that are going on out there in the Linux world:
glibc not even being reliable for the same version on two different distributions- in the recent past, things linked against 2.1 (which SHOULD be fine- 2.2, 2.3, and 2.4 technically should have the 2.1 ABI rulesets in them) would not work at all in Mandriva (outright crash at startup of the OpenGL layer- segfault in the constructor manipulating memory allegedly just allocated for the object) and comes up with a double free error in Fedora Core 4. Same glibc version. Radically different behavior. Do we have distributions “patching” the glibc layer here? Is it a lurking bug in optimizations? It’s broken- and for the same reason Mike’s calling it that.
Then there’s the glibc, C++, and ELF woes he mentioned- I’ve been bit by all of them. I can’t talk to the Python problem, but if what he’s saying is right, then it too is a fundamental problem.
You see, folks, the problem isn’t that the stuff doesn’t work- it’s that it all needs to be hand-crafted from the ground up. There’s _currently_ all kinds of issues with someone taking a binary built on Red Hat and moving it over to Mandriva or Debian. Issues that shouldn’t be. Mike’s being perhaps too harsh in his commentary- but it’s dead on with what is wrong. I can’t say for sure if his answers are good ones, but _SOMETHING_ needs to be done as not everything is going to be Open Sourced for some time to come and I’m only about a month or two away from startting put a wedge into one segment of Microsoft’s stranglehold on things. One substantive enough that we need some better answers quickly.
]]>When people have hard, technical facts about ELF or the forking of the Python ABI by distributions then I’d be interested to see them. The blogs you linked to do not “point out inaccuracies”. Daniels post talks about something completely different to shlibdeps, which is what was being criticised, and the other blog doesn’t appear to contain any technical content at all, being simply a repeat of what you are saying.
It’s certainly true that the page in question had a bad attitude, however, it is as far as I’m aware the _only_ attempt to document the serious binary compatibility problems that Linux has. Did you seriously expect it to be butterflies and sunshine?
]]>