Slashdot Mirror

I'm http://www.linuxbase.org/betas... open in front of me.

Mountpoints for removable media are specified as going in "/media", not under "/run/l[whatever]/[userame]/media". While revising this now allows the attached to be mounted under a subdirectory belonging to a particular user and keeping other remotely connected users off the attached media, it creates additional complexities sharing that media. It can be made to work, but it destabilizes the path to the attached media.

For "/run", the FHS says : "This directory contains system information data describing the system since it was booted. . Files under this directory must be cleared (removed or truncated as
appropriate) at the beginning of the boot process." If the systemd authors were folowing the FHS, they'd have to delete the contents of /run on reboot. Not remount them: delete them.

This is one of the typical problems of systemd: they are really making up their own standards and practices on the fly, in violations of anyone else's existing standards. New approaches can be beneficial, but many of the consequences are unclear, and it's breaking stable system software, and existing standards, everywhere.

standards-compliant

Which standards? That's always the problem with standards, there are so many of them.

If you're going to pick the Linux Standard Base, the problem there is that it's decidedly not distro-agnostic, but specifically demands RPM-based package management.

You don't understand.

Old busted == op-ed

LSB new hotness == /opt/ed

Android is a complete linux distribution that uses a different Window Manager and has a well defined consistent Object Oriented development platform.

Different window manager? It doesn't even run X-windows. Between not having X11 and not using glibc (trying building shared library for google android), means you can't even begin to compile an existing Unix GUI application for Android. That is the bigger gripe to me than if it shipped with all the normal programs I expect with a complete Linux distribution. With a Linux Standard Base distribution, download the source, compile, and run, not with Android.

A "standard base"... I think you may be on to something there.

I'm here to tell you, it ain't that easy - packaging is the least of the issues. Have you tried to build a binary that "just works" on a system other than the one you're sitting at? No console apps, please. Let's talk about X11. Hell, let's talk about GTK or Qt! Have you investigated symbol versioning? Hope you've got a nice five-year-old glibc to compile against... Or you could use the LSB SDK and try and do it that way. Have fun - it's still very much under development. The people behind it are great and very helpful... but (especially if you're using C++ instead of just straight C) I almost guarantee you'll run into problems. I love Linux, don't get me wrong. But the rule everyone seems to keep forgetting here is: "All hardware sucks, all software sucks". I've spent quite a lot of time recently trying to accomplish a "distro-agnostic" binary... and I wish you luck, sir. :)

Every single distro does its own thing and there is no standardization whatsoever.

I humblely disagree.

Filesystem Hierarchy Standard (FHS)

The filesystem standard has been designed to be used by Unix distribution developers, package developers, and system implementors. However, it is primarily intended to be a reference and is not a tutorial on how to manage a Unix filesystem or directory hierarchy.

Gentoo FHS
RedHat FHS
Suse FHS&LSB

And for binary distros there is Linux Standard Base (LSB)

The LSB specification is made up of several components, known as modules. The base specification consists the of Core, Graphics and CXX (C++) modules. The specification is further extended with the Desktop set. Each module might be subdivided into a common document plus architecture-specific documents (in some cases the subdivision is not needed). A complete binary standard for a particular processor architecture consists of the set of necessary common documents plus the matching set of architecture-specific documents.

Latest LSB Spec 3.1.0

I code for this API and the sources end up being source compatible. But then there are library paths and stuff, which is why even something as homogenous as Linux is forced to create LSB standard. The API standard OTOH, is crystal clear - look at the API tables in terms of availability. And yeah, my project is called Portable.net, so I've put in my time writing portable code for various platforms (even BeOS and SkyOS). Wish the threading models worked the same, that's all :)

Guess he's never heard of http://www.linuxbase.org/

I think it is getting to the point (maybe it's always been this way) where Linux distributions are effectively different OS's.

Probably not.

First, we have wide LSB compliance. Next, we'll be getting an LSB Desktop spec later this year, which expands on LSB to be more meaningful to end-user needs (covers GUI components, etc).

There is also the DCC Alliance, whose members (Knoppix, Xandros, Linspire, MEPIS and several others) will all share the same LSB Desktop core. Ubuntu hasn't joined, but they now have an agreement with the DCCA to synchronize their kernels.

http://www.linuxbase.org/LSBWiki/DesktopWG

Not that I've ever had that problem on Redhat or CentOS, but what you describe isn't even due to the RPM package format. And I've never had a problem managing RPMs on a Debian system. It works as a package format.

Ultimately, ALL these distros suffer from the effects of a centralized database that gridlocks users into choices made within the central repository. We must use this hideous kludge called "package manager" because there is no standard definition for desktop Linux where the OS stops and where applications begin.

It does relieve dependency hell... for the simpler installation scenarios. For independantly-distributed software its miserable.

You can read about the upcoming LSB Desktop here:
http://www.linuxbase.org/LSBWiki/DesktopWG

You can read about the LSB Desktop spec that's in development over here.

All of the DCC-based distros (Knoppix, Xandros, Linspire, MEPIS, etc.) and some others will be compliant with this standard shortly after it is finalized.

Oh man, a standard Linux base? What a crazy idea! We could call it Linux Standards Base. Dell could then support anything that claims to support LSB 3.0 which would quickly have distros moving to actually /follow/ the LSB. This would be great, as LSB would finally have some support, and I could finally stop digging around the filesystem on Red Hat to find something that isn't where I'm used to on Debian. (What, no /etc/apt/ directory? :P) Why wouldn't this work? LSB may have some implementation issues, but I think the concept is solid. Or is this a stupid idea?

GUIs and Wizards are prerequisites, certainly. But FOSS systems now have plenty of those.

What they lack is a common standard for API and installation. Give developers a way to code, test and package for one environment; Then users will have a way to download/buy software packages that are self-contained and independantly distributed.

And what about installing drivers?

If users can't do these things then all the wizards in the world won't change our very fancy thin-client model into a workable desktop.

There *is* a linux standard, ever hear of it?

Modern computing platforms have:

1. A relatively predictable set of ABIs (for both drivers and apps)

2. Standard installation procedures

3. A defacto IDE that lands new developers smack in the middle of said platform's functionality and documentation

4. The above implemented such that ISVs can easily distribute to the platform with one file or CD-ROM distributed independantly.

5. Technical decisions that do NOT force authors to distribute through a Centralized Repository just to keep their application from breaking with each OS update.

6. A developer base that can concentrate on their ideas and customers, not on the shifting sand underneath them. Whereas 'Linux' distros have 'maintainers' that insert themselves between the end-user and the developer (and make users wrestle with faltering package databases to boot). Is the distro the right focal point for customer relationships?

'Linux' is just a kernel with several OSs built upon it. And those OSs don't constitute modern computing platforms either. They are good ways to run Apache + a databse, and one could say that LAMP is a solid platform concept. But that is all for the sever room and for web development.

Our community needs a 'LAMP' for the native, desktop environment. Is LSB Desktop up to the task?

Well... are developers creating RPMs for LSB? I've never seen such an RPM. I don't think that's even possible. How will LSB Desktop fix this?

Someone from OSDL's Project Portland invited me to join after I expressed these concerns. But even with 5 years of using Linux on my desktops, I spend most of my time on a Mac now. Maybe I will anyway; It should be interesting to find out if the community is still trying to pour sugar over warmed-up server-room procedures, or if they are going to focus on meeting user expectations.

The problem I have is that even though you might be able to install a DEB or RPM from some other distro, the chances of it working are often slim. I realize different distros want to do things "their way", but it would be nice if they'd standardize on things more.

However, autopackage .package files would/should work on any distro. Also worth looking into are componentized linux, and the Linux standards base .

I'm not saying that things are perfect, however, I will say that things continue to get better.

... every single Linux distribution I've seen for the past years has used /var/www for storing web pages?

Guess you haven't seen SUSE then, or indeed any LSB-compliant (or FHS 2.3 compliant) distro then.

The Filesystem Hierarchy Standard says to put that stuff under /srv (typically in /srv/www) and the Linux Standard Base says to follow the FHS. FHS 2.3 has been the standard for nearly two years, since January 2004.

Just because RedHat screws it up... (At least AS4 has /srv)

Guess you've learned your lesson now. You're free to say KDE blows and Gnome rocks, or vice versa, and not be labelled flamebait or troll - but never dare to suggest that linux has a standard base or you're marked troll.

Amusingly enough, stories about the Linux Standard Base Project http://www.linuxbase.org/ are not labelled troll, though people often use their posts in those stories saying the whole thing is a waste of time, because by gum if they had to wrestle with dependencies for an hour to compile a program, you should too.

Linux Standard Base:
"We strive to develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux."

Yeah, clearly a waste of time, or a "Windows for Linux". Sheesh.

You can do a few different options, each with their own drawbacks. Depending on the libraries you are currently using you will possibly have to use a combination of these items.

Static linking allows you to distribute a single binary that will run on any linux system so long as you have the correct minimum kernel version and CPU. Some of the problems with this will include the license on the libraries you are using may not allow this, and the application's code image changes from what you have debugged against.

Dynamic linking and putting all of the required dynamic libraries your application requires in their own personal library directory. This is the quickest solution, but not always the best solution. It does allow you to release periodic incremental patches to the binaries used by your applicaton.

Usage of a application such as Elf Statifier to take your debugged dynamic application, and bundling the applicable libraries into your application. This is a halfway point between a completely dynamic and static application that allows you to take your "GOLD" release and package it up without changing the generated code in your application.

Just release your application as a dynamic application and mark it with the correct dependancies in RPM format and follow the Linux Standards Base.

Most commercial applications will use either the 2nd method (dynamic and distribute all their own versions of various dynamic libraries) or the 4th method. In both cases they specify a message to the effect of "We support X distro version Y. It may work on your linux distro, but we only support X version Y."

As you are planning to make money off of this game, I wish you luck, and suggest you take a look into what the most popular linux distros for your target audience will be. Based on advertisements from Wal-Mart and Fry's selling Linux preloaded I would bet Linspire and Xandros is high on that list. As with all things, don't forget the testing across many distributions to make sure the solution you choose actually works.

I'm not sure I can agree with you here. LSB specifies RPM as the standard.

In the end, I find a central repository incredibly convenient when I am an end-user. When I am a developer (that is, developing my own software), the central repository is a pain in the behind.

Binary compatability not an issue? I'd have to take exception to that. For instance, while I'm not a huge fan of the LSB because of test quality, and some other issues, please note that binary compatability is supposed to be maintained across point releases. Breaking it is one of the defining aspects of a major release.

From
http://www.linuxbase.org/LSBWiki/ReleaseNotes3

"The LSB project team is proud to announce LSB Version 3.0. The specification is available for download at [WWW] http://refspecs.freestandards.org/lsb.shtml. As this is a major release, indicated by a change in the first component of the version number, there is no guarantee of binary compatibility with previous versions. The set of interfaces, the details and symbol versions, and layout of certain data structures may have changed between this release and the previous one. Thus, applications conforming to previous versions of the LSB will require recompilation and/or relinking (see also Compabitility section below)."

Clearly, binary compatability can affect developers, packagers, system admins, etc.

Seems ironic that a 'open standards' site would not be W3C compliant.

http://www.linuxbase.org/

Let's see.. 1 error, 26 warnings! woo-

Why doesn't he blurb link to the LSB website at all? it's here Anyway's.

LSB == Linux standards base :

http://www.linuxbase.org/

But we don't need standards that handle things by way of THIS sort of answer. The link in question is a bug in the standards test. Their answer was not to fix the standards test, like it should have been- it was to, as Ulrich put it, don't use fast SMP machines. In it's current form, the standard is less than useful because you're needing "waivers" for things like this.

Combine this with silly requirements such as needing Sendmail (Uhm, shouldn't it be more along the lines of, we need an MTA of some sort- so long as it's handled properly, who cares which one, right? Sendmail's the least desireable of all of them, and it tends to get turned off for Postfix or Qmail most of the time anyway!) and it's about as useful an appendix is to a human these days.

Yes we need standards. API standards, possibly ABI standards- but not what we're getting here.

Anyone know where this link went? I get document contains no data.

From the fine article:

This applies also to the code which is written by the presumed professionals paid by the OpenGroup to write tests. Want an example? Look at this. This is no isolated incident, I've found this kind of problems on many occasions.

Anyone know where this link went? I get document contains no data.

From the fine article:

This applies also to the code which is written by the presumed professionals paid by the OpenGroup to write tests. Want an example? Look at this. This is no isolated incident, I've found this kind of problems on many occasions.

Going forward, the Linux Standards Base stuff should be the way to go. They provide tools to build software to ensure it is compliant, and tools to check the built software to make sure it adheres to the spec...

What came first of the chicken and the egg? The vendors won't release games for Linux because the userbase isn't big enough and the userbase won't switch to Linux because the lack of games..

It's called market potential. Whenever your company releases $HARDWARE or $VIDEO_GAME they have to ask the marketing people "who will buy this?" Based on the answers, you get publishers paying for development of Microsoft only hardware drivers and Microsoft only video games.

(Neither video games or hardware are Free as in Beer. Free as in Speech is possible, but discussing price-free drivers and games is beyond the scope of my argument here.)

I was asking around last year about the market potential for Linux kernel GNU systems. The biggest problem is find out just how many people use Linux in the first place (http://counter.li.org./

So, given that it takes a market of at least 100,000 units sold to turn a profit on a top-release $50 game with a $1 million to $3 million budget, are there enough desktop linux users to suppport a Linux game release? Is the market there?

Note that top-release $50 PC games for Windows sell upwards of 200,000 units in their first year, and upwards of 100,000 units for their next few. For example, Blizzard's Wold of Warcraft (http://www.blizzard.com/ cost $5-10million to make but sold 600,000 at $39-50 in its first 6 weeks. But that is on the extreme end of the spectrum.

Assume 50% of home desktop Linux users play computer video games[0].

Using counter.li.org numbers Linux desktops = 0.025% (0.0125% gamers) of all desktops, then a WoW for Linux would have sold 144 copies in it's first 6 weeks[1]. Stats at geek.com (http://www.geek.com/ for 2004 show Linux desktops = 1.12 percent of the market. Assuming the highest number of Linux desktop gamers being 0.56 percent of the total gaming market, then a WoW for Linux would have sold 3,000 copies in it's first 6 weeks at $39-50.

That means between $7,200 and $150,000 could have been spent by Linux desktop users on WoW. While $7k will only pay a Bangladeshi salary, $150,000 would nicely cover one or two interns to make sure WoW compiles and runs on Linux[2][3].

0. Or assume a higher rate of gameplay, but consider less than 100% market penetration of your game, so that 50% market penetration is reached.

1. Note that Transgaming (http://transgaming.com/ needs far more paying customers pending their $5 votes than this to start work on a title, and WoW has been voted #1 priority by transgaming.com customers for several months before being supported.

2. Assuming a baseline Linux is being supported (e.g. SDL $VER + Glib $VER or LSB (http://www.linuxbase.org/) or Distro $FOO) and no additional cost for shipping and delivering the binaries.

3.$15 per month implies $2,160 to $45,000 a month to keep that Linux port updated. Considering Blizzard.com is reporting a 1.11 patch to the 5 year old Diablo II, over a similar 5 years a WoW monthly income could have added $225,000 to Blizzard's coffiers.

Distributing and maintaining closed-source applications you have to pre-compile it into a binary distribution, and therefore in the ideal case you want to develop towards a set of standards. Currently there is no prevailing standard base which secures compatibility among Linux distributions, and therefore a company have to create individual binaries for every distribution it supports (which has it's own unique package set). The fact that there is no standard package set create dependency hell and often leads to many vendors just supporting one distribution or a version of that distribution. Fortunately there is an effort called the LSB (Linux Standard Base) which aims to develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. It seems like the LSB is slowly getting foothold in the Debian camp, but it is currenly unclear how much interest it will generate in the rpm-crowd (Mandrake, SUSE, Red Hat etc). Even if the standard is not adopted by SUSE and Red Hat, it has the prospect of unifying the Debian-based distributions so that Linux can collect a substantial amount of users on only three distribution-platforms. Proprietary software vendors has shown themselves willing to support three Linux-distribution bases.

Now, the licensing issues for proprietary vendors to develop towards the Linux standards also needs to be clear and easy to understand. Even though the plurality of open-source licenses gives the developers a good choice, it takes quite an effort to wade through the implications of all of them. I am not saying that closed-source platforms does not involve this problems, what I am saying is that on a platform like Windows you can (through paying a bunch load of money) acquire a commercial license, which can be really difficult for some GPLed projects. The problem with a library under the GPL-license is that it does not clearly define *exactly* what a derivative work is, which is left up to a whim to be interpreted by anyone, and since GPL has a viral nature a proprietary software vendor can not risk that his application will be defined as a derivate work. For instance Trolltech recommends that commercial vendors use it's alternative commercial Qt license while developing closed-source software. We have often heard about the Windows licensing hell, but this is often interpreted as licensing hell by the lawyers of proprietary software-vendors. Fortunately the Linux Standard Base addresses these problems by requiring that any package included in the LSB should be free to use for anyone to develop towards. The LGPL is a license which satisfies this criteria while still protecting the work itself from being ripped off by commercial vendors keeping the changes they have made to a LGPL project for themselves. It should be up to the devoper(s) to choose which license the software should be developed under (GPL, LGPL and proprietary).

Linux has the prospect of ma

Distributing and maintaining closed-source applications you have to pre-compile it into a binary distribution, and therefore in the ideal case you want to develop towards a set of standards. Currently there is no prevailing standard base which secures compatibility among Linux distributions, and therefore a company have to create individual binaries for every distribution it supports (which has it's own unique package set). The fact that there is no standard package set create dependency hell and often leads to many vendors just supporting one distribution or a version of that distribution. Fortunately there is an effort called the LSB (Linux Standard Base) which aims to develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. It seems like the LSB is slowly getting foothold in the Debian camp, but it is currenly unclear how much interest it will generate in the rpm-crowd (Mandrake, SUSE, Red Hat etc). Even if the standard is not adopted by SUSE and Red Hat, it has the prospect of unifying the Debian-based distributions so that Linux can collect a substantial amount of users on only three distribution-platforms. Proprietary software vendors has shown themselves willing to support three Linux-distribution bases.

Now, the licensing issues for proprietary vendors to develop towards the Linux standards also needs to be clear and easy to understand. Even though the plurality of open-source licenses gives the developers a good choice, it takes quite an effort to wade through the implications of all of them. I am not saying that closed-source platforms does not involve this problems, what I am saying is that on a platform like Windows you can (through paying a bunch load of money) acquire a commercial license, which can be really difficult for some GPLed projects. The problem with a library under the GPL-license is that it does not clearly define *exactly* what a derivative work is, which is left up to a whim to be interpreted by anyone, and since GPL has a viral nature a proprietary software vendor can not risk that his application will be defined as a derivate work. For instance Trolltech recommends that commercial vendors use it's alternative commercial Qt license while developing closed-source software. We have often heard about the Windows licensing hell, but this is often interpreted as licensing hell by the lawyers of proprietary software-vendors. Fortunately the Linux Standard Base addresses these problems by requiring that any package included in the LSB should be free to use for anyone to develop towards. The LGPL is a license which satisfies this criteria while still protecting the work itself from being ripped off by commercial vendors keeping the changes they have made to a LGPL project for themselves. It should be up to the devoper(s) to choose which license the software should be developed under (GPL, LGPL and proprietary).

Linux has the prospect of ma

At risk of answering what was possibly intended to be a (bad) joke,
You mean like standards base likethis one?

Just as logically sound, while more practical, is the focus on standards organizations:

http://www.linuxbase.org/
http://freedesktop.org/wiki/

They promote compatibilty between distributions.

Other than that, we need a superset of existing packaging systems, let's call it ".app", which will allow a binary (or source) package to be installed on all popular Linux distributions. It would contain enough metadata and be compatible and supported by all package managers.

Then the only differences between distributions would only be default settings, artwork, support and distribution-specific packages.

Now you could acurately call the differences between linux distros "flavors" rather than now where I'd call them "forks" or "reinventions"

*No intended correlation to Mac OS X .app

This is the big one really. If you want a fixed mandated core set of libraries that the user is forced to install... well, grab yourself a nice mandated controlled system like OS X, because Linux probably isn't what you're looking for. In theory you could just set up a distribution that has such a guaranteed base set of libraries, and in a sense some already exist - try Linspire, or Xandros. The catch is that people write applications for "Linux" not "Debian, stable" or "Linspire 3.1" or whatever. Given a random open source application it will make whatever assumptions about libraries it cares to - it's up to the packages to make sure those dependencies are met. FOSS applications tend to be coded against "whatever system the developer cared to use" rather than specific distributions and versions. Commercial developers maybe? Well they do have requirements - Oracle requires particular versions of Redhat in standard installs. Other commercial developers can do that if they like. Alternatively they could accept that the Linux world is a diverse world and restricting yourself to the one distribution that is guaranteed to have everything you want where you want it is a little limiting. You can always use Autopackage and handle the dependency issue elegantly in a way that's effectively invisible to the user.

In response to that is LSB. Linux Standard Base sets a set of libraries so if an app is released under LSB, it should work on any distro that supports LSB. Mandrake/Mandriva support LSB, and is LSB compliant. There is an optional package on installation for LSB system stuff. See picture for picture.

Sure, OpenOffice is great, but commercial enterprises will stick with commercial solutions for which there is support.

I don't exactly get what you mean by support. My impression from the people and businesses I know personally is that Microsoft Office format is a big success not because of "support", but because there's a wealth of products built around it by third parties.
These 3rd-party products are crucial for the enterprise, stuff like Eletronic Content Management, being able to create document workflow and revision systems, and groupware. All this stuff integrates seamlessly with the Windows desktop and the Windows office applications. In any enterprise with a huge amount of paper and workflow, document management systems are a necessity. This is point OpenOffice proponents frequently forget: office applications are not about just the single desktop user but they are also about integrating seamlessly in an eco-system of content management software provided by theird-parties and accessing legacy documents. For instance, in my country, Brazil, legislation demmands that certain financial documents be stored for a period that outruns any document format you might have seen. This means people have to migrate very old sofware document records.
This is an area ISV working on open-source platforms could explore, an unexplored niche market. AFAIK, not even COLD solutions exists and COLD goes way back decades (ever since computers started processing bills.) And there are no equivalents of proprietary software in the open-source market (this shows you that open source developers are sometimes out of touch with their would-be customer base). People are developing groupware, but there are no ECM (Enterprise Content Management) solutions. Groupware, ERM, and ECM are the bulk of enterprise software.
If only the open-source community would take something like OpenOffice, or further develop AbiWord (which has nice plug-in functionalities), and integrate these with Mono, you would have made a serious dent in the Windows dominance. I mean, who wouldn't want to avoid expensive per-seat Microsoft licenses, plus per-seat ECM licenses? And software houses that provide ECM solution (e.g., the market leader OnBase) work with year-round support and customization, and we know this is a way of doing business that is viable for open-source (of course, they have per-seat licenses).
BTW, I really mean Mono, and not Java. Java is not an alternative on the long term, not only because of the Java's proprietary nature, but because Mono is gearing itself towards Windows-*Nix interoperability, to the point where software build with Windows.Forms will work on Mono. Additionally, having to depend on Sun's finances is a a suicidal investment of resources.
But open-source has major hurdles: it nees to standardize on OpenGroup and LSB That is to say, the Free Standards Group has to advanced by libre *Nix distros and vendors, so that software developers have an easier time with all the distros. De Icaza wrote something about this in this essay. Linux distros need to be reliable in terms of time frame for releases (which the commercial ones are), too.
My feeling is that Microsoft has foreseen a trend going against its closed-source format (OASIS, the Massachusetts imbroglio) and anticipated any possible open-source incursion in the field of content management. If these formats are truly opened, they've raised the bar for the arguments of any future switching to FOSS platforms+OO.org solutions (because, right now, as I've argued, there are no FOSS replacements for content management for the enterprise AFAIK, and there's a huge amo

Here's the problem... The open-source/free-software movement is similar to an organic evolution/adaptation system, while the proprietary software industry is just that, like industrial/factory systems. Because of the factory like mechanics, proprietary software is easy to package and pump out. Open source goes in all different directions and it's an electronic survival of the fittest. If someone comes out with a better piece of software, people will tend to use it instead. If someone comes out with a better distro or packaging system, it's the same thing. Only thing is... since it all goes in a million different directions, there are alot of "extinct species" along the way. This is our trade-off for the freedom vs. convenience. However, if we can find a way to get the best of both worlds (LSB, FreeDesktop.org, Autopackage, and other open standards)....things could really get exciting.

Long term what I'd like to see is an equivalent to freedesktop.org for distributions, where distro developers can congregate and produce standards on how things should work.

Repeat after me: All your Linux Standard Base are belong to us.

Umm, that's what the Linux Standard Base is for. Blame the distro makers and packagers for not following it. After all, the LSB has been out for a *long* time...

There are many flavours of Linux which result in there being (to the user) many different OS's being called "Linux"

Aha, for herein you might just cut to the root of the problem, from a public image viewpoint -- though there is no one thing identifiably "Linux" beyond the kernel, the public (i.e. userland) sees one thing from a distance called "Linux", and is then confused when upon closer inspection this single thing turns out to be a multiplicity of distros. Hmm.

To that end, I sincerely hope the Linux Standard Base initiative currently in progress amongst some of the major distros makes headway towards providing the basic interoperability such a user base would conceivably expect, with the straightforward binary compatibility you talk about in the great-grandparent post. In fact, it seems the LSB aims to solve the very issues you presented. The mission statement on the LSB page:

To develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.

While I am a fan of variety and a stauch believer in avoiding monocultures, I do find myself thinking that the efforts of the LSB are pushing things in the right direction if we are to see greater adoption of Linux OSes, and in particular, greater participation by ISVs in the Linux-compatible software market. In such a case, there would at least be a few distributions that could, for userland, be collectively termed "Linux" without confusing things too much for the uninitiated. :)

Can someone comment on why distro's seemingly *have* to have a different filesystem hierarchy? Typically when you distinguish yourself from a competitor you add value. I don't see the value here to anyone other than the distro vendor, in that given enough scripts and whatnot, if you wanted to move to a competitor it could be more of a PITA than it's worth to switch.

Well, it's been my experience that the differences are there because the developers working on them believe that making the change makes the system "better". I put better in quotes there because their rationale behind it may be as shallow as, "it's just how I like it" or as technically sound as something like, "doing it this way decreases boot time by 30%". A good example of this is how the differnt distros handle init scripts. There are tons of different ways that have been put forth to handle this, each with their own flavor, and some arguably better than others. In FS hierarchy, it's just more fallout from people being able to decide for themselves what is "better".

Further, I've not heard any arguments to why vendors cannot agree on a standard FS (not to say there aren't any - I just don't know of 'em)? Perhaps use symlinks to keep the old path functional and implement the new path. Am I just nieve?

There is the LSB http://www.linuxbase.org/ which various distros can more or less adhere to if they choose to. Most of the "big boys" adhere to it pretty closely these days, from what I understand. Remember that "Linux as a business" is a pretty new concept, and even the major vendors are still working out choices from the garage days where someone did something one way because that was just how they liked it.

In short, the directory structures are being taken care of.

This is why more people need to get involved in projects like the Linux Standard Base. If more distros would quit trying to do their own thing and work together, Linux might be able to really take off. Autopackage will help people with installation hell between distros. And hopefully, freedesktop.org's new set of UI standards will help KDE and Gnome people get along a little better too....but then again, we are talking about human beings here.

Take a pinch of Standard Linux
Wrap it up in Xen
Add a touch of SELinux
And a little bitty bit of Globus
Oh like a Sandboxed Platform
Oh Lordy, Lordy, mixed with Free and Open Source Code
You know you lump it all together
And you got a recipe for a Multi Vendor Development scene
It is coming though, you know, you know.

What we have is a great big melting pot
Big enough enough enough to take every vendor and all IT's got
And keep it stirring for a hundred years or more
And turn out Application Service and Content Providers by the score.

With apologies to Blue Mink .

Things are improving, however. For graphics/sound/control, use SDL.

For desktop integration, go with the Freedesktop.org menu spec.

And for package management, there's RPM, standardized by all LSB-compliant distributions.

IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.

Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).

One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.

Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX . Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard basealso offer a cross vendor foundation.

The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project ( /opt/[organization]/[project]/[package] ). The distribution/OS Vendor can then ship conflicting versions of dependent packages without it breaking the project code. The in house developers can then test and port to the new version at their leisure.

Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.

When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.

If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.

Repost

IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.

Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).

One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.

Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX. Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard base also offer a cross vendor foundation.

The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project ( /opt/[organization]/[project]/[package] ). The distribution/OS Vendor can then ship conflicting versions of dependent packages without it breaking the project code. The in house developers can then test and port to the new version at their leisure.

Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.

When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.

If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.

One of my fellow Slashdot readers posted this link. The LSB faq says many distros, including a few non-RPM based ones, agreed on RPM being the standard package format. Debian, Storm, and Corel Linux were the distros named. Not only are they all Debian based, but Storm and Corel have been discontiuned for a while now

Even more interesting is the future packaging plans of the lsb. The faq states intent to implement a deb/rpm packaging format. Now this is good for Debian (probally the sole reason they agreed to rpm), but where does that leave other non-rpm based distros? Slackware is my distro de jour, yet I havene't read any plans, or heard of any consideration in the slightest for the first (and possibly the fastest) distrobution of Linux.

Before the my-format-is-better-than-your-format debate kicks into high gear, it should be said that the LSB intends to use the RPM format as a stop-gap measure

Of course, you know who is on record about how stop-gap measures "...have a way of staying around. Forever."