Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
There is no "v5 ABI", and other LSB issuesThere is no "v5 ABI", and other LSB issuesPosted Aug 5, 2004 3:23 UTC (Thu) by JoeBuck (subscriber, #2330)Parent article: LSB 2.0 and C++ You missed a key point. The version number for libstdc++ was not bumped between the 3.2.x and 3.3.x releases, because the original plan was to maintain strict ABI compatibility. Unfortunately this was not done correctly; 3.3 is not binary compatible with 3.2. Doubly unfortunately, RHEL 3.0's system compiler is gcc 3.2.3 (same with Fedora Core 1 and other distros that are still widely used). This makes it extremely difficult to support LSB 2.0 binaries on RHEL 3.0 without kludges. One need not side with Red Hat (I do not) to see that a standard that a major player can't live with is unlikely to be much of a standard. As you say, LSB 2.0 does not specify any existing release of GCC as the standard. The specification requires a bug fix, meaning that only an as yet unreleased version 3.3.5 would be compatible with the proposed standard. So it is incorrect to claim that the LSB project is standardizing on something that vendors are now shipping. Finally, RMS did not prohibit the steering committee from cooperating, when acting as private individuals. He prohibited the steering committee from taking an official position. It should not be surprising that he objects to something called the "Linux Standard Base" that mainly specifies the behavior of GNU software, and that has little to do with the Linux kernel (it's no more difficult to get a BSD system to comply with almost all of it). It's particularly problematic that the LSB seems to expect GCC, part of the GNU project, to ship a patch designed to their specifications (though since a 3.3.5 release was planned anyway and the requested patch is a bug fix, it will probably happen at some point). The LSB should change its name, and the new name should include neither "Linux" nor "GNU" (since it's equally possible to provide an environment that allows BSD or Solaris systems to run binaries that meet the specification).
(Log in to post comments)
A name change is in order Posted Aug 5, 2004 6:04 UTC (Thu) by uwaucs (subscriber, #6160) [Link] Particularly since Solaris 10 will support the LSB.
breakthrough on naming issue! Posted Aug 5, 2004 9:13 UTC (Thu) by bkoz (guest, #4027) [Link] Ok, most everything on this sad thread has been said and re-said in the gcc discussion. However, I've not noticed the obvious naming point yet, so I'll say it, because it has to be said.
If LSB kept the L, and just changed the "B" for base into "D" for disto, well then. That would be LSD! A much better standard already. I can't believe they missed that chance...
-benjamin
breakthrough on naming issue! Posted Aug 5, 2004 17:16 UTC (Thu) by tjc (subscriber, #137) [Link] If LSB kept the L, and just changed the "B" for base into "D" for disto, well then. That would be LSD! A much better standard already. I can't believe they missed that chance...This was discussed at length on Slashdot 4 or 5 years ago, back when Michael McLagan was promoting his own plan for Linux standardization.
breakthrough on naming issue! Posted Aug 6, 2004 1:06 UTC (Fri) by giraffedata (subscriber, #1954) [Link] I'm still waiting for the naming to go the other way: For "Linux" to start referring to a wider set of operating systems. A lot of people think it's vital to the definition of "Linux" as an operating system that the system contain the Linux Kernel. But I've always said that of all the things that characterize a "Linux" system, the kernel has relatively little influence.Already, I believe most sentences that apply to all the so-called Linux systems also apply to GNU/Hurd, FreeBSD, etc. And I remember a statement from Sun once claiming that Solaris was Sun's version of Linux. Why not? IBM did a similar thing with AIX. With IBM's help, I once outfitted a system with an AIX kernel that was hard to tell apart from Linux-kernel-based systems I use regularly. In many conversations, I referred to it as a Linux system; to do otherwise would be misleading.
breakthrough on naming issue! Posted Aug 6, 2004 1:23 UTC (Fri) by piman (subscriber, #8957) [Link] The word you're looking for exists. It's called "Unix" or maybe "POSIX-like" if you're really really pedantic.
Please let "Linux" mean the Linux kernel, otherwise we have no way to talk about it.
breakthrough on naming issue! Posted Aug 6, 2004 2:43 UTC (Fri) by giraffedata (subscriber, #1954) [Link] It's called "Unix" or maybe "POSIX-like"That's a different term, much more broad. It would include, for example, a standard AIX system, and that is quite distinguishable from Linux systems. Please let "Linux" mean the Linux kernel, otherwise we have no way to talk about it. I fought that battle valiantly when the name "Linux" was new. We have been beaten soundly. The vast majority of uses of the word "Linux" today are references to a class of operating system, not of kernel. But it's not that big a loss -- we definitely still have a way to talk about the Linux kernel -- just add that one word - "kernel." That's what I do now. And as for a word for operating systems that include the Linux kernel -- I still maintain there's no need for one.
breakthrough on naming issue! Posted Aug 7, 2004 22:51 UTC (Sat) by piman (subscriber, #8957) [Link] I seriously doubt your AIX system provided a Linux-like /proc, or sysfs/udev, or was bug-for-bug compatible with whatever thread implementation was being used at the time.
> The vast majority of uses of the word "Linux" today are references to a class of operating system, not of kernel.
I know absolutely no one that does that. Even the dumbest journalists know Solaris, Linux and BSD are different OSs.
breakthrough on naming issue! Posted Aug 7, 2004 23:50 UTC (Sat) by giraffedata (subscriber, #1954) [Link] I seriously doubt your AIX system provided a Linux-like /proc, or sysfs/udev, or was bug-for-bug compatible with whatever thread implementation was being used at the time. True, but my point is those are minor OS characteristics. I'm sure in some applications, they are critical, but they pale by comparison to all of what was the same. But more important: note that not all systems we call "Linux" share any of the things you mention (think of those that contain 2.4 kernels), yet we still use a single name for them. That's because they're minor differences on the whole. I know absolutely no one that does that. You're reading something extra, and absurd, into what I said, because when I said "Linux" is a class of OS, I certainly didn't say that Solaris and Linux are the same OS or even that Solaris is in that class called "Linux." Examples of OSes in the Linux class are Red Hat Linux, SUSE, and the myriad variations of those that their users create. Journalists hardly ever even write about kernels, so they wouldn't use "Linux" to mean the kernel. They use it to mean something like Red Hat Linux, which comprises the kernel, a bunch of GNU programs, X, OpenSsh, and so on. They compare "Linux" to Windows, which is by all accounts a whole operating system, not just a kernel.
breakthrough on naming issue! Posted Aug 8, 2004 2:54 UTC (Sun) by piman (subscriber, #8957) [Link] > True, but my point is those are minor OS characteristics.
So what's a 'major' OS characteristic? If you refer to the toolset, we have a separate name for that already, too... I see no gain by calling an AIX system with the GNU tools "Linux". It's a lie.
breakthrough on naming issue! Posted Aug 10, 2004 16:12 UTC (Tue) by giraffedata (subscriber, #1954) [Link] I don't think there are any indvidual major features. When the average person thinks of "Linux," he thinks of a vast array of features that, perhaps surprisingly, all the systems calling themselves Linux mostly have in common. Some major components that deliver these features are: the Linux kernel, Bash, GNU ls etc., sysvinit, X, KDE/Gnome, and lots and lots of other software. The kernel is less than 1% of Linux in many ways: lines and bytes of code, development effort, pages of documentation (description), questions asked about "Linux" in public mailing lists.So it's hard to see why we would define a class of OS based on the identity of that one component.
breakthrough on naming issue! Posted Aug 12, 2004 15:50 UTC (Thu) by AJWM (subscriber, #15888) [Link] I see no gain by calling an AIX system with the GNU tools "Linux".Agreed, but that's not what the original poster was saying. AIX-5L is certainly Linux-like, and it and several other Unix-derived systems will run Linux binaries (of appropriate CPU architecture). It's a lie. It is similarly a lie to brand all the FLOSS tools supplied with most Linux (and many other OS) distros as "GNU tools". Many (most?) are not part of the GNU project and many are not even distributed under the GNU license, but some other free/open license. Perhaps we do need yet another name. POSIX and UNIX both have rather rigid (and somewhat dated) requirements as to their use, you don't like "Linux" as a generic term (probably a good thing, it dilutes the trademark), and calling anything with a mish-mash of GNU, non-GNU project GPL'd, BSD, Apache, Artistic, CPL, etc, etc, licensed tools should hardly be called GNU/anything. "Freenix" has been used as a generic term to cover Linux, the BSDs, etc, but there can be vast "feel" differences between those. (Not necessarily from a user view if he's just using a graphic desktop, but certainly from an admin point of view.) Something that conveys the flavor of a modern, user-oriented unix -- "muonix", perhaps? (Pronounced "moonix", so as not to confuse it with some new electronics-like technology based on muons ;-)
RMS and LSB Posted Aug 5, 2004 9:15 UTC (Thu) by angdraug (subscriber, #7487) [Link] RMS did not prohibit the steering committee from cooperating, when acting as private individuals. He prohibited the steering committee from taking an official position. And I believe that RMS is perfectly right in prohibiting endorsement of LSB. Not only because of the name, there is a more substantial problem: LSB's primary purpose is to enable proprietary software, while position of RMS and FSF in general towards proprietary software is well known: it is negative. It would be against all principles of FSF to officially endorse proprietary software standard.
RMS and LSB Posted Aug 6, 2004 1:23 UTC (Fri) by KotH (subscriber, #4660) [Link] Well, standardization makes writing proprietary software much easier, but you have to also agree that it is a pain to write portable software, even if you just want to support all linux distributions. I actualy miss the times when a simple Makefile with a few constants at the top was enough to compile something. No mess with autoconf/automake/libtool. LSB is for me a step into the direction of enabling simple sofware to work again with simple Makefiles w/o the need to learn the autotools or to handcraft a configure script.
LSB and portable software Posted Aug 6, 2004 8:15 UTC (Fri) by angdraug (subscriber, #7487) [Link] it is a pain to write portable software True. But no amount of standardization will make all the ancient incompatible systems suddenly go away. If you want your application to be portable without fancy autotools scripts, your only option is (and will be) to use Ruby, Python, or another scripting language, and let the language developers deal with the portability thing. LSB is for me a step into the direction of enabling simple sofware to work again with simple Makefiles w/o the need to learn the autotools or to handcraft a configure script. Quoting "Introduction" to LSB 1.3: The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts (emphasys mine). You see, LSB is not about source code, it is about binary software.
RMS and LSB Posted Aug 6, 2004 3:25 UTC (Fri) by bkoz (guest, #4027) [Link]
I think RMS is completely correct on this.
It gives me pause when a group that charges $$$ for positions on its executive board, requires $$$ for certification etc. is establishing standards for free software. Hey, who spiked the water cooler, huh?
Personally, I encourage all linux hackers to work together, regardless of favorite distribution or employer.
"Nations will learn to work together only by actually working together."
The only way we are going to get true and meaningful compatibility between different distributions of linux is for the linux distributions to work on this problem directly, with full and equal rights and voting priviledges, not by some self-appointed external group.
RMS and LSB Posted Aug 6, 2004 5:28 UTC (Fri) by Xman (guest, #10620) [Link] Honestly, much as I hate to say it, committees work much better when you have to pay at least a nominal charge for a seat at the table. It ensures that everyone sitting at the table has at least some kind of a stake in the outcome. As for charging for certification, it's really hard to come up with a certification process that doesn't involve paying some kind of trusted third party to do testing. So then the question is only who pays for the testing, which inevitably leads to the testee.
I agree having $$$'s in the process makes it a pain, but frankly it works better than all the other solutions (beyond simply not having a standard and letting natural forces push a standard forward).
Design by committee Posted Aug 6, 2004 8:18 UTC (Fri) by angdraug (subscriber, #7487) [Link] I agree having $$$'s in the process makes it a pain, but frankly it works better than all the other solutions (beyond simply not having a standard and letting natural forces push a standard forward). There, you say it yourself: letting natural forces push a strandard is a better solution. Dao rules ;-)
|
|||||||||||