AH <3
At last some well-thought criticism to reply.
I know WMD and others hashed a lot of this but this guy has some facts wrong.
I might have, since I have only done some small admin progs for my friends ... and even with those ABI breaks with C++ sucks donkey cocks.
Why I code admin stuff with C++? Maybe I am a total noob, but C++ just makes code mainteinance easier, since with method/data capsulation it is easy to separately test different components.
Actually, no. On Windows, one must download a install maker (which usually costs money) and use it to create the installer. Sounds right? Yeah. However on Linux, it's the same thing, in fact the standardized installer maker for Linux (defacto anyway) is Loki's installer tool which I have seen more instances of in the last three days than ever before (downloading games and proprietary software, it abounds). The tool is here:
http://www.lokigames.com/development/setup.php3
Loki Installer is actually better than any of those RPM or DEB alternatives, since it enforces the software's binaries and libraries to be runtime-relocatable. And that is just a king idea.
Yeah there were several glibc compat breaks in the past, and frankly I agree that glibc needs to take more initiative to keep API compatibility. And yes, this *can* make binary redistribution difficult. However, you must remember that the people behind Glibc and the people behind Linux and even the people behind KDE are all *different* *people*. And up until the last few years they weren't in the limelight at all, which gave them little incentive to make users every dream and wish come true. In fact there are still a lot of developers who remember such a time and deliberately try not to given to a user's every whim. Given time and new leadership, things begin to change, for instance only introducing binary incompatibility with new major versions so that old major versions can be kept around.
Major-Version ABI compatibility scheme is a good practice. Heck, even the LSB people consider this to be a "best practice". It should be THE ONLY PRACTICE for GNU linker based system, till sombody invent some mechanics to do the versioning at binary level (the ELF binary format has symbol versioning properties, but only GNU "base-system" developers use these).
And I think that no "FREE SOFTWARE IS THE ONLY WAY" -type dickheads should not be allowed leadership in ANY OSS project. Those guys forcefully break the binary compatibility, just because it makes source-distribution the only viable way for the apps that use the software component
I might be a little fascist, but I do know the needs of the Enterprise (the the God and the Devil of our realm). Current world needs enterprises, so GNU/Linux MUST fit in, and respect the enterprise, or no mass exodus for proprietary apps will happen ...
There is the second point of Mono and what it will mean with further adoption. Binaries produced from Mono (like any other CIL-targetting compiler) will work on Windows, will work on Linux, will work on Mac OS X, Hell, if you can get a runtime working on BeOS you could run it. Of course this cross-platformness works with all different forms of Linux as well. I do believe it will be the saving grace for this problem if Glibc and other projects continue introducing problems.
Hmm.
I know that mono compiles the userland-spesific parts of the binary into a bytecode ...
but will this slow down program execution?
I mean, can the bytecode-part of MONO be compiled into a platform-spesific binary form on the fly, and then use the precompiled binary instead of the mono-binary?
If this is so, then I personally think MONO will be the best shot our chaotic GNU/Linux scene has. Otherwise it will never be adopted by enterprises, which require runtime compatibility across all Linuces.
By the way you forgot Linux with it's refusal to introduce a stable ABI for drivers. Linus claims he will never change his mind, but frankly, who cares if he never changes his mind because the opportunity is open for someone else to fix it with some magical solution. Stranger things have happened to Linux in the past, like the introduction of the Composite and Damage extensions. Everyone involved in X11 development (including me, slightly) expected alpha channels on Linux to appear as a single extension and have the semantics of blending windows together be built into the server, but because of the vast difficulty of doing that, an even better solution was devised that made an infinite amount of effects possible and implementable by any capable dev who tries.
Yeah, and this is why I think Linus is not so good leader after all. He is more like a visionary than a practical leader.
Bill Gates thought right, when they implemented their HAL component, and made a stable driver ABI.
If somebody knew enough Linux kernel driver programming, he/she could easily make a kernel module, which implements some high-level driver ABI abstraction like the NT-kernel HAL. This ABI abstraction would incur some overhead, since the abstraction needs to be binary-compatible even if the kernel subsystems get redesigned ... and that means that this Linux-HAL would need to implement quick-n-dirty patches to make things work.
Linux binary HAL would be possible, but it would need A LOT of designing so, that the base-ABI interfaces can stay the same for years to come. Very hard this would be i tell ye ...
Given your personal frustrations with working with inconsistent APIs and ABIs, I tell you that people are working on such matters, in fact, I am (komodoware.com).
And I appreciate your distro. Just watched the documentations on yer platform runtime, and it is just GREAT.
At last somebody understood, that consistent runtime ABI is a good thing
Let's hope that enterprise starts embracing your platform/runtime. Would make LSB-groups work easier, if they could integrate your ideas into their own, and so acquire a stable runtime for the third-party proprietary ISV's <3
Just as Windows may have fucked something up. Just the othe rday I tried to get my USB CD burner working (has worked fine in Windows forever) but Windows failed to notify me about me pluggin it in and in fact I had to go to the device manager (something few home users know about) and try to figure out why Windows wasnt using the correct driver for it. I went to the manufacturers site and got their drivers, but still no avail! Windows has just the same problems if not more. Just because you have had success on Windows and failure on Linux doesnt mean thats everybody's opinion. *Not* simple as that.
Linux doesnt have standards for plug and play because neither does Windows. All plug and play is, is a marketing term describing a piece of software which detects the hardware and uses the proper driver. So who can be blamed when a device doesn't work? Blame your distribution! Duh! The people who put together the combination of individual tools into an OS are the people who have failed to get your USB mouse working or whatever.
In commercial world one can blame the guys who make the third-party app/driver, or the dickos who make the crappy OS
Reporting bugs is always taken into account, since the corporations behind the software are monetarily bound to satisfy their customers.
In OSS world nobody is responsible for anything. The GPL license even ENFORCES this policy. Some company CAN take some responsibility on some degree, like issuing a customer a working GNU/Linux server system, but even they cannot guarantee that some individual component in the OS works.
Again, you are going on false facts here. You should hold your distro responsible for any problems using it. Thsi is why distros so commonly have someone working upstream with OSS projects, so that they can fix the problems users complain about. And please do not generalize "Open Source" to what you see on your Linux distribution. "Open Source" is 100% seperate from Linux. That's like jumping up and yelling at IBM (makers of OS/2 at one point remember) for Windows not working!! Remember Mac OS X is based on Darwin, which is open source.
Yeah, here you are right ...
Maybe i should just blame Linux coders spesifically.
Would this make people listen to me more? Possibly
You're right, but you just made all your previous points moot. If you want to do it yourself, it won't be easy. And I dont get the kings of nothing thing.
Since when does Windows have a "standard installer ABI" unless you mean the registry which maps installed applications to uninstallers. That in itself is merely in it's beginning stages on Linux. All it takes is the right toolkit for developers to use which would interact with the package manager which was available on the machine and do the right stuff. There are several solutions in library and program form which attempt this. By moving the process of dealing with multiple package managers into the toolkit, the application is free to do what it was designed for. And if Mono does in fact keep growing in usage a copy of the toolkit can be sent with the binary distribution of your software so that it really will work everywhere. Such libs are small of course, what with not including the other stuff that comes with packages such as documentation, source code, and the overhead of the package manager being used. Once Linux distros get used to this happening with proprietary software, they'll create tools which remove unneeded libraries and files from the individual install directories (remember that toolkit?).
In Windows they got this Install Shield -API, which is quite a good ... it contains all stuff like authorization, dll installing, software registering and the like ...
Most proprietary software use Install Shield. OpenSource Win32 software may not use it, but it is their problem. Install Shield makes things easier, since it is designed to be the Ultimate Installer for the Win32. It is even partly integrated into the userland, if i recall right ...
I like the idea of many-to-one pkgmanager toolkit library. Woudl require a LOT of work, since library dependencies are distro-spesifically named ... and only in RPM libraries are automatically mapped to provide soname dependencies.
The package manager and filesystem layout are perhaps the only large inhibitors of such packages: the ABI of most projects *does* stay pretty stable, and this is just reiterating my point about using Mono once again (there is no such thing as ABIs, only APIs--you can add members anywhere and dependent code will still use the correct struct/class layout).
Funny you should mention filesystem layout when the toolkit I've been so fondly speaking of has just this feature. The ability to define the layout of the filesystem from a system global layout file in a place that doesn't require you to bend over to a certain layout in order to support it. Right now (its still pre-release) it reads /.System/Layout.xml. On the system it was built for (my Komodo distribution) it maps stuff to /System, /System/Software, /Software, /System/Temp etc but on a traditional Linux system a Layout.xml could specify to use paths like /usr/bin/ and /etc. Again, the app doesn't really care.
Okay, enough of the ABI then.
This does NOT take awat the problem with statically --prefix:ed binaries.
Prefixing just sucks! Binaries/Libraries should just get their runtime location, and use HFS2.3 standard to get their data from relative (../share/
) location(s). This runtime-relocation would allow users/userland-admin-apps to install software into isolated places, so that they can be easily managed without some huge database.
I just mean ... currently pkgmanager database is THE only thing that keeps userland working. Without it would be hard to do package upgrading. With runtime-relocatable binaries/libraries it is possible to place them into isolated locations, and trust that they got all the /lib, /bin or whatever components they specify during installation. In this model we would use pkgmanager database ONLY AS A CACHE to make quick file/soname search across multiple packages. Neat huh?
BTW Win32 API has this GetModuleDirectory() which just rocks! It is actually the only thing I like in Win32 API. Makes binary distribution very easy, since one can make just one .zip with a decent directory layout, and get all the data with paths relative to GetModuleDirectory() at runtime
You act as though we have a big OSS-dev only forum where we all communicate and coordinate. The open source community is not a single body, so it takes time for things like that to be adopted. You wait half a year and I'm sure there will be a lot more support. Also, 90% of the code which comprises GNU/Linux distributions is built with autotools, which generates the "configure" files that choose how the software should be compiled. If autotools put some work into building with LSB conventions by default, the code doesnt even have to change. Rarely do C/C++ based projects write their own makefiles.
I was talking about the GNU/Linux OSS scene ... they have multiple forums yes, but some of them are straight flaming the guys at LSB. Some people diss about "LSB being enterprise whore standard" or such (a little exagerated example . Many GNU/Linux coders who I know are complaining about "the extra steps needed to make an LSB binary" and most comlain about this "RPM IS THEIR PACKAGE FORMAT AND IT SUCKS" thing ... tho lsb apps need not be RPM packaged, if they conform with LSB standards otherwise.
GNU/Linux distribution developers need not but read the LSB spec, hack their userland a bit and that would do it. Still, many refrain from such.
I just hope LSB becomes something big, among with this Komodo system which just plain rules (proof of consept), so that these egoistic hippie-commie coders would need to eat their words, suffocate and die of shame
Or, try new distributions which incorporate these new technologies which better Linux and make it easier to do such things. In fact, yeah you could stick with your big distros which are established because they are all becoming LSB compliant anyway. SuSE *has been* LSB compliant for quite awhile, and googling "LSB linux distribution" gets many hits about distributions aiming for LSB, consortiums declaring LSB dedication, etc.
And this I do. I am using Debian, which has a decent LSB-runtime support.
Yes you are right, but I know for a fact that the "runtime conventions" are not as different as you think. My distro can install software from RPMs, Slackware PKGs, and DEBs, without many problems. Of course, it's not perfect: Fedora's RPMs don't work with the RPM unpacker we have but all that can be improved as development continues.
Well these distro's were at the same glibc/stdc++/gcc versioning interval, so of course such binaries will work.
However, if some of those go out of sync between two distros, then there MAY be problems.
I am waiting a lot of problems with bin-compat when some distros go and move to GCC 4.0 (GCC 4 broke stdc++ ABI, hooray for the GCC/glibc hippies!) =)
Yes but like I asserted earlier, these "multiple Linuces" are not that different from each other, and even though a lot of Linux software is still pretty stupid in relation to where they install stuff, it's all a matter of the efforts for cross-Linux compatibility which *are* active and which *are* producing things. Even smaller developers such as myself think about these problems and apply more force to fixing them. You put a ton of OSS devs in front of one of you people and we soak it all in. We think deeper about where the merit is and try to fix it. The beauty is, any capable free Linux developer who came across these posts would only be emplored to find solutions.
That's my conclusion. Heartbreaking baby.
I am grateful for the cross-linux solutions you and your Komodo comrades do. They really seem to be intuistic and genuine, not like the most other (APT, RPM) out there ...
I just added your project into my list of OSS projects, that bring something revolutionary to GNU/Linux. The other project is LSB, but heck, they are already being pissed on by some smaller OSS-devs ;D
You gonna make a distro-neutral Komodo-runtime package?
Anyway, I can't apology enough for my coarse language. I am just fed up with the people who make this scene roll ... many of them (especially the "leader" characters like Linus and Richard Stallman) have idealisms that seem too unpractical for the enterprise.
That is why we NEED middleware app-components and standards like Mono/LSB/whatever to make The Holy Enterprise to believe into GNU/Linux ... but these technologies are being pissed on by the zealots who think OpenSource distribution is the only way. Sigh.
Umm ... I got nothing more to say this time.
