Slashdot Mirror
Linux Standard Base 2.0 released
prostoalex writes "Linux Standard Base 2.0 has been released by the Free Standards Group. The release will allow application developers to ensure their product works on multiple flavors of Linux. FSG keeps a list of compliant distributions on its Web site."
It should be stated that the gcc c++ abi for 3.4 series is incompatible with later versions.
Has two products listed on the compliancy page. Caldera set to expire near the end of this week, and SCO Linux Server set to expire next month. I wonder if they'll try to get renewed.
Interoperability is a great goal, but is anyone addressing patching/updating? Currently, it seems that these updates are handled as follows: download new packages, remove old packages, install new packages.
That seems fine for smaller bits of software but for a KDE bug fix or an OO.o update, downloads can go to the 100MBs or more. Fine on a DSL line, but dial-up users are still going to get hit hard.
I understand that OSS is better at fixing bugs and that's great -- but between Mandrake 10CE and now, it feels like I've downloaded another distro worth of updates. Is there something being done (maybe the whole binary diffs thing mentioned before) to decrease the size of update files?
I'm posting this as part of an LSB thread in the speculation that binary compatibility may one day lead to (smaller) patches that can be applied to LSB-compliant distros...so a KDE bug stays a KDE bug and not a MDK bug, SUSE bug, RH bug, Debian bug, etc.
The drafts had some gcc controversy. Which gcc did they end up choosing?
considering the fact that gentoo is a source based distribution, it really can't. However gentoo trys to stay as similar as possible when it can for minimal pain
I'm kind of disappointed looking at the list of compliant distributions - there aren't many on there, especially when you consider how many distributions there are out there.
.deb, .tgz? It seems this would be more in the spirit helping free software (unless collecting fees is the real point...)
It's not surprising to me that it would be a list of marketing-oriented commercial distributions. The real disappontment, however, is the LSB itself. Rather than try to standardize the libraries and toolchain of a compliant distribution, it allows them to do whatever they want without regard to any standard (like before), but adds a bolt-on runtime environment with enough features to support most commercial software (but without all the features and optimization of the distro's own runtime environment).
Further, it appears that each distro must build this runtime environment on their own, and then pay to have it certified.
Why not just give away an official LSB compliance RPM,
I presume that LSB is simply spec'ing existing practice, correct? Or have things changed since that posting? Is this really an issue, even, since a system might be able to support an "old" and "new" C++ ABI by having both the "old" and "new" libraries installed?
Also: if the C++ symbols will be stored as (name space + package + class + method) in that order, ELF is used, and there are many hash collisions, this might create a lot of overhead loading large C++ libraries. The reason: while linking, you'd have to compare a lot of text before matching, because so many symbol entries would have a common prefix that you'd have to keep matching over and over again. Am I reading this correctly?
- David A. Wheeler (see my Secure Programming HOWTO)
Actually, it's not like Gentoo users *deal* with tarballs, however that is one of the ways (the most common I guess) that source is delivered for portage to deal with. Very practical, since almost *every* project at least releases a tarball. Makes for really good availability, really soon after releases.
Tarballs are an excellent choice for Gentoo - then again, you may not like that it compiles everything locally, then maybe it is not such a good choice for you. At least we have the choice. =)
Spine World
Terpstra himself summed it up pretty well on a debian list:
Let me repeat the operative words here: commercial software, binary only, Intel.
This has nothing to do with Free and/or Open software, except in that it's an attempt to get Free and Open Software developers to be more helpful to commercial software houses that want to use their work for free (as in beer, not speech.)
Do you think it's only a coincidence that Terpstra works for Caldera/SCO?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Certification of gentoo is almost certainly out of the picture, as you can't know from one system to annother which libraries are installed.
This might be an interesting use for slots though. Someone could build a series of ebuilds that require the specific library versions that the LSB specifies, and keeps them in slots (so they're not unmerged when they're upgraded). Then a Gentoo user who has emerged "LSB-Base" would have a decent chance to be able to run any LSB 2.0 requiring binary package.
They pay for the privilege of being certified as "no different from our competitors' offerings".
Don't blame me, I didn't vote for either of them!
The thing I like about Slackware is that Volkerding is Slackware. He really answers to nobody but himself, which means that no matter what the masses think or want they won't get that unless he sees that is it necessary and good.
This lets him keep everything working toward his ultimate vision, if what the masses demand doesn't fit in that vision it doesn't happen--this is good because that means that someday he'll arrive at that vision (if he hasn't already), and well that there actually is a vision.
Its also why slackware works... it just does.
What did you expect killall to do? It has been around since System V and kills all processes. It was introduced to Linux in the PSmisc project and took on another meaning.
The Solaris equivalent is pkill and is also available on Linux from the procps project.
The more sensible thing would be for all distributions to remove killall and standardize on pkill. killall5 could be retained if necessary.
Sorry, I seriously doubt that, as any software written for Intel will probably work for AMD as well. Also, don't agree that all commercial software is evil, nor that binaries are evil.
Finally the Linux guys agreed that there SHOULD be a standard (even if it's not implemented yet).
.os hell mentioned earlier. (No more recompiling! Halleluyah!!)
Seriously, saying Linux is 1000 times better than Microsoft is kinda being hypocritical when they make MS's same mistake: Despising standards in favor of proprietary implementations. (NO, i DON'T mean open vs closed source. I mean standard vs proprietary).
Anyway let's see if in a couple of months, this resolution helps programmers deploy Linux binaries that run on _ALL_ compliant Linux distros, ending to the
The reason there aren't any certified community distros (listed on the FSG page) is probably that community distros tend not to care much about how they are listed. I'd guess that Fedora Core is compliant with some version and just doesn't care about being listed. Most of the other ones, as people have noted, don't use RPM and are probably missing a bunch of things that are only important for strict conformance. (E.g., you're supposed to have a /lib/ld-lsb.so.2; actual programs seem mostly to use /lib/ld-linux.so.2)