LSB Not Enough

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

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.