LSB Not Enough [LWN.net]

LSB Not Enough

Posted Sep 9, 2004 22:20 UTC (Thu) by doodaddy (guest, #10649) [Link]

# How does your "main" Linux distribution relate to the "tweaks [...] that provide competitive advantage"?

The "main" Linux distribution would provide *less* choice and a uniform file structure.

1) Less choice means that there would be one desktop, for instance. Linux has pretty much chosen one thread library, one order-preserving network protocol (TCP), one rule for SIGCHILD on sub-program termination, and one graphics lib (X). A desktop should be no different. If the "wrong" choice is made, that can be replaced over time. Is Gnome harder to program than KDE? Maybe, but tough titty. Just like C, Gnome is prickly but fully open-source. As a programmer I'd rather work with a harder tool than have to code to TWO tools!

2) Unless something has changed, Red Hat has a different directory structure with files in different places than other dists. I believe this is why the LSB got started. I don't think it was a complete accident that RH "improved on a standard" as Microsoft euphemistically calls such practices. You might think that creating multiple releases with multiple file structures is no big deal, but it's unnecessary and shops won't bother. This would eventually mean Red Hat would lead and your average small business would assume they need RH because they don't want to figure out which of 3 or 4 downloads to get from their favorite tax program. It's all so unnecessary. I don't think the average development shop is gung-ho to re-configure for all these cases either. I'm at my 5th workplace and I have yet to see a company that was stocked with enough QA and SCM folks. That's just a way of life.

So, once the basics are firmly established, a particular distribution that branches off and customized for "real-time" or "palm top" or "fully loaded" won't be so bad because most of the distribution is shared (including app installation) and dists that attempt to vary too much will be avoided by customers. A major "main" dist upgrade will surely be merged into the boutique dists. (Notice that right now, each dist has several of these boutique variations for itself.)

# What do you imagine the support contracts will look like?

I don't care, personally. But as Mr. Perens is trying to establish, the contract choices *will be* endless. Right now, your contract choice is to tie in RHs contract with RHs dist or SUSE's contract with SUSE's dist. Why should these be paired? It's a form of lock-in. Using a car analogy, the last place I go for auto repair is the dealer. I don't need a fox guarding a hen house. (But Lord knows the dealer tries hard to lock us all in.)

# How did you measure the "bigger trend towards Windows"?

I really should have put an "In my opinion" on that. Sorry.

I have been disturbed over the last four years with a "trend" I see. For example, at the last place, we had Linux for Apache and PHP. We dealt with three external vendors during my tenure. One was to get an IVR upgrade, but as of that year, they had dropped UNIX options and the new IVR was Windows 2000 Server only. (Not a trend yet.) Next, a marketing guy had snuck around and used an ISV to create a web site to communicate with customers. When he was found out (and fired), we had to bring it in house. Unfortunately it was ASP on IIS so we had to convert it. Next, we had to deal with a business by simply providing a URL to their site. However we wanted to do it securely by sending an encrypted credit card number, but to no avail. They used Cold Fusion (on Windows). (Close to a trend now.) Now I'm at a new shop which has it's roots in Unix. We have our own cross-platform toolkit, but last year an entire new app was written for Windows only including some toolkit components that won't be supported on UNIX. I just finished a meeting where a new daemon we'll need to write can be Windows only. This is because the new project is only going to run on Windows anyway. I won't bother with the job before last, but the stories are similar. Meanwhile, my ex-girlfriend and my brother work in "Windows only" shops on *systems* that would be better on Linux. My other job offer this time was a Windows only shop even though they were doing lots of component and *system* level work. (By "system," I mean that they need to manipulate files, search for strings, check directories periodically (cron), and write batch files. Things I consider obvious on UNIX. I wouldn't be so hard on a shop that writes office applications.)

So I call it a trend because it should be getting easier for me to push Linux, but it seems to be getting harder.

# Where did you come up with the idea that "Government contracts are demanding Windows now"?

Again, I should say I don't have stats, but my current job involves a good proportion of government work and they are the major pushers of a Windows based distributed computing environment. (Again, DCE is mostly a UNIX thing for now. There is a limited port of Condor for Windows which I will be using.)

# What idiots do you work with that would let the choice of a particular distribution stand in the way of porting an application?

Huh, what? Well maybe you know the intricacies of RPM databases and directory structures, plus other potential unknown nuances, but these guys don't want to get a thesis in it. There are probably a million lines of code across 900 "sub-projects" written over 20 years, including cross-platform toolkits, error-reporting subsystems, modes of operation, inter-process communication... Considering the relatively vile state of source control, their hands are too full to start exploring the options. Besides, just because we say it *should* work on Mandrake doesn't mean the customer will be impressed. We have to *support* it. I believe those with power but not time to explore (most places, wouldn't you think?) are waiting for the Linux push based on THE Linux distribution.

# Why shouldn't we pretend that competition (some would call it choice) between KDE and Gnome is good?

Are PNG and GIF a good idea? I don't think so. One should win, probably PNG due to rights issues (though they are now resolved). At least, PNG probably kept the GIF owners from extracting licensing cash. But now having both is just more trouble, more libraries to parse and for no benefit. On the other hand, JPG and GIF make sense. They don't "compete" as much as have separate niches JPG does lossy and extreme compression, best for natural scenes or pictures that just need to be recognized; and GIF does loss-less but less compact compression but retains the image perfectly.

So here we are with two desktops which are matching up as Windows-like, full-featured, desktop environments, like PNG and GIF and for the same reasons. (One has proprietary base code and has moved farther and farther to free due to the competition.) In the meantime, if half the desktops in the world get Gnome and half get KDE, programming shops will have to code two system trays, two drag and drop systems, two COM-like component engines... Sorry, it's not only obnoxious, it just won't happen! You are fooling yourself to think it will. And while you are fooling yourself, application after application is *not* being ported to Linux because it's too much trouble and shops would rather wait to "see what the customer wants."

On the other hand, if we had one heavy desktop, like Gnome and one light desktop that didn't have all those features, that would be reasonable, I think. People with the light desktop would be counting on X-level drag and drop and no real frills. For instance, maybe a cheap (little memory, slow processor, lame graphics card) library terminal for browsing only. Just an idea, but probably not a great one, but I hope I made my point.

LSB Not Enough

Posted Sep 9, 2004 23:42 UTC (Thu) by hppnq (guest, #14462) [Link]

Repeat after me: "I will lay off the drugs. I will lay off the drugs."

And at least please get your facts straight.

LSB Not Enough

Posted Sep 10, 2004 2:34 UTC (Fri) by bojan (subscriber, #14302) [Link]

> Huh, what? Well maybe you know the intricacies of RPM databases and directory structures, plus other potential unknown nuances, but these guys don't want to get a thesis in it.

RPM packages are extremely easy to build. There is a single file, called a spec file, which defines how things are going to be done. Nobody has to get a thesis on any directory structures or databases - various RH distros are very FHS compliant. Also, one can make choices *inside* this spec file to follow minor, distro dependent differences in order to create the RPMS. The spec file can be stored inside a vanilla tarball, which can be turned into binary/source RPMS with a single command. In fact, if designed properly, your build farm running target distros can build new versions of RPMS automatically from this vanilla tarball. Who knows, one may even find companies that do a similar thing and share the build farm resources with them...

If the software that you are building is not open source, then you'll have to do all those minor tweaks yourself, once only. If it is open source, others interested in using it on their favourite RPM based distro can do that for you, thus saving you the effort.

LSB Not Enough

Posted Sep 10, 2004 21:22 UTC (Fri) by gvy (guest, #11981) [Link]

Better yet: if you can get the build system under apt, you can use tools to prepare a chrooted build environment, build the package inside it, and have your build and install dependencies linted with build being *repeatable*.

In ALT Linux, there are two such tools -- sandman client/server system (which does far more than that, including integration with VC software, bugtracker and ProjectView but executes package installs as root and thus the access must be controlled to avoid compromise) and hasher tool (which is more self-comtained and is designed with high security in mind).

They are both used for different purposes and they're *published* -- contrary to e.g. RH and SuSE build systems.

I do know that sandman was used with RH7.x plus a few more packages (apt among them).

ftp://ftp.altlinux.ru/pub/people/ldv/hasher/hasher.7.html

sandman

Posted Sep 14, 2004 0:47 UTC (Tue) by koide (guest, #22687) [Link]

It reads like a great tool, but is it ALT Linux dependant, or just apt dependant?

On a related issue, why does ALT Linux get so little attention? It looks like a great alternative.

sandman

Posted Sep 15, 2004 7:53 UTC (Wed) by angdraug (subscriber, #7487) [Link]

It reads like a great tool, but is it ALT Linux dependant, or just apt dependant?

Just APT-dependent, but it also needs a correctly formed package repository. ALT Linux Sisyphus happens to be such suitable repository, but, with varying amount of effort, virtually any RPM-based distro can be adopted for use with Sandman.

Sandman was originally developed by Sergey Bolshakov for Optifacio and SaM Solutions to facilitate repeatable builds of a Network Attached Storage system, which is a small (think ~100 MB iso) subset of Sisyphus. ALT Linux didn't manage to adapt it to their whole distribution, so they resorted to a more limited solution, Hasher, which only builds individual packages, much like Debian's pbuilder. Sandman's complexity is one of the reasons why Optifacio offers Sandman-based distribution building as a service: it takes an insider knowledge to set it up.

Right now Sergey is re-implementing Sandman to take care of its most fundamental flaw: limited package repository versioning. A team in SaM Solutions is working on a more ambitious build system, which, in addition to proper version control, will add support for arbitrary package formats (Debian, BSD ports, etc.) and plug-and-play build servers.

On a related issue, why does ALT Linux get so little attention? It looks like a great alternative.

It appears they have no incentive to go international. Besides, outside of Russia, where, as I've already said, ALT Linux has zero marketing, this same niche is nicely filled by Debian, which is bigger, better, and known world-wide. Disclaimer: I am a DD.

LSB Not Enough

Posted Sep 15, 2004 7:53 UTC (Wed) by angdraug (subscriber, #7487) [Link]

In ALT Linux, there are two such tools -- sandman (...)

Typical example of the problem with the ALT Linux business model. Even if it were unintentional, this sentence sounds as if the company is claiming credit to something that it had very little to do with (as in "the company providing network infrastructure for a community project that produced a package repository that is used as a basis for an independent product by another company that actually developed the tool for its customer who agreed to contribute it to the community"). No wonder the customer now requests a "vendor-neutral solution".

LSB Not Enough

Posted Sep 13, 2004 5:19 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

you guys must be deliberatly trying to misunderstand the problem

the problem is with companies that are not writing open source code, they are not writing infrastructure catagory programs, theya re writing programs for specific tasks and want to continue doing so.

they are willing to support 'Linux' but are not willing to support 20 different flavors of 'Linux'. while we all know that 90% or more of things will work just fine with no effort across all the different flavors, that's not good enough, they have to KNOW that their software will work and they don't want to have to run it through QA 20 times to prove that it will work (and when you have redhat doing non-standard stuff it's very easy to get software that requires non-trivial changes between distros)

if there was a good standard that would let the software function everywhere then this issue could fade away, unfortunantly the LSB takes so long to standardise and covers so little that in practice it's not good enough (I buy software from a company that currently supports 4+ distros and they ignore the LSB becouse it wouldn't help them at all, their management couldn't be sure that someone didn't accidently use a non LSB piece so they still wuld have to test it on every distro)

the problem of commercial software only working on some distros IS a real limitation right now. and now that you can't get a supported OS to run the software on without substantial per-seat licenses it makes it harder to get linux into new places

and once a company buys into the 'enterprise distro' they tend to want to run it everywhere becouse it is expensive in terms of support people to run multiple distros

LSB Not Enough

Posted Sep 13, 2004 10:42 UTC (Mon) by hppnq (guest, #14462) [Link]

The problem does not seem to exist when it comes to porting apps to proprietary Unix systems, so I fail to see why the Linux case would be exceptionally difficult.

I agree that the LSB has not (yet) brought us the standards base we were hoping for. Smart software vendors that want to make their software run on Linux platforms will want to take a good, hard look at their own configuration methods and probably make use of, for instance, autoconf. Just like they would in other cases, by the way.

Could you hand me the list of "20 different flavours", or were you just trying to make the problem look bigger than it is?

LSB Not Enough

Posted Sep 14, 2004 0:31 UTC (Tue) by koide (guest, #22687) [Link]

Because each Linux flavor is comparable to a single proprietary Unix (AFAIK there're no different flavors of solaris, hp/ux, etc.). So supporting Linux is supporting each different distro, and there're certainly more than 20.

Thinking on widely used ones you might get to 5 or 6 instead of 20, but the problem is still far from trivial for not trivial systems, especially when you're focused on users which won't be happy compiling each part of the system.

A good approach for this issue might be to install in a specific, non standard location while LSB is LNSB, such as Sun's jre (/usr/java), though this doesn't solve library naming issues, so you end up with duplicate libraries (see OpenEV or FGS).

You might ask, why not use RPM/apt/whatever? Because then the maintenance cost is huge (updating each part of the system, and tracking each distro specific change, which happens in between versions of the same distro). You can use your package format of choice once you've built the tree in an independant way, of course, but that's against the spirit of packages, I'd say.

LSB Not Enough

Posted Sep 14, 2004 8:05 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

each distro is different enough to be a seperate flavor, and frequently each release of a distro is enough different from previous releases to count as a seperate flavor. with commercial Unix vendors there is less variation between different releases then there is between different linux distro releases (so binaries compiled for Solaris 2.6 still work on Solaris 10, but try to take a binary compiled for RedHat 7 and make it work on Fedora Core2)

it's the same problem as supporting multiple Unix vendors and the software companies don't support all variations on Unix, they support a small handful of them, and in Linux they only support a small handful as well (mostly RedHat releases historicly)

One problem that Linux has along these lines is that it changes faster then the competeing OS's do. that makes the newer linux systems far better, but it makes it harder for the software vendor (even if they only support a single distro)