Slashdot Mirror
Big Names Back Possible Linux Standards
Sean Feryl writes "Adobe Systems, IBM, Intel, Hewlett-Packard, Novell, RealNetworks and Red Hat are all backing the new Linux standards effort led by the Free Standards Group to form standards for key components of Linux desktop software, including libraries, application runtime and install time. The goal is to encourage the development of more applications for the Linux platform. 'With this complex and costly development and support environment, independent software vendors may choose not to target the Linux desktop, leading to reduced choice for end users and an inability to compete with proprietary operating systems', the group said." Also covered on FoxNews.
Adobe? Does this mean Photoshop could be on the cards?
(and yes, I've used the Gimp, and no, it doesn't do what Photoshop can do)
Sigs are so 1990s. No way would I be seen dead with one.
I find all this talk of "Linux standards" amusing. To me it appears like POSIX, etc, all over again and I expect it will have about just as much success and impact as POSIX and friends did in standardising Un*x.
The first problem here is most of the "new blood" involved weren't around to witness the mistakes of Un*x in the early 1990s and so Linux has been as different as it can be whilst still being POSIX compliant.
What everyone needs to understand is that standards will never deliver what people are claiming they will.
What we should do is just accept that RedHat, Ubuntu, SuSE, Caldera, Debian, etc, are all different operating systems that happen to share a common source code -base-.
In the end, I expect that the standard will be nice but "not enough" because there will be "differences" in key places to allow each vendor to provide more functionality, expand, etc.
Can't the others just copy for compatibility? Yes and they can do so today but they don't because of different ideals.
All that said, I would love it if the mechanism to install a new software package and have it enabled at bootup was the same on _all_ Linux platforms. Unfortunately, today, it isn't and given the gratuitous differnces in how this is done, I'm not confident that it ever will be the same everywhere.
How many of the distros will follow the standard? I know that it is commercially important for the major distros to follow the standard, but newer and more innovative distibutions may forgo them. If you spend much time running Red Hat or SuSE, you can get frustrated sitting down and attempting to edit scripts on Debian, or at least that had been a problem in the past. Gentoo seems to follow its own path, and I haven't spent more than a few hours working with Slackware in five years. These are just a few of the different approaches to linux file management (especially the rc scripting). Then there are the various package management systems, updaters, and user scripts. I haven't had time to play with Ubantu, but it would take me time to work through the directory tree to see how things are arranged as well.
Linux standards are a great idea, but I don't know how many of the dozens of distros will follow it.
"Rocky Rococo, at your cervix!"
It is not about having no choice. It is about having a stable platform to target for development. Kind of like the appeal of Java is not the language, it is the platform.
It's the non-standard nature of the directory tree that gets on my nerves. /bin, /usr/bin, /usr/share/bin, /usr/local/bin, /usr/local/share/bin... Aargh!
Whats non-standard about that?
http://www.pathname.com/fhs/pub/fhs-2.3.html
All these package managers are great for distributing OSS, but once you get into the situation of "I paid hundreds for this photoshop CD" things might get complicated. Releasing OSS and even "free" software like adobe reader is easier than something like photoshop. Free software can be distributed and it's up to the distros to make .debs, .rpms, .ebuilds, etc. But how do you do that with something like photoshop or illustrator? People want to buy the CD and pop it into any computer and install it. And adobe can't possibly make a different package for each distro, even the popular ones.
/usr/portage/distfiles and have an ebuild work from there (as in sun-jdk, crossover office, etc.).
I'm using gentoo and ubuntu right now. I love them because thousands of software titles are available either with the click of the mouse or a few keystrokes in a console. But this works because people get those free packages and configure them for each distro either because their distro paid them or out of the goodness of their heart. But it'd be illegal for someone to make a photoshop ebuild that distributed all the files. And it's a pain to copy the photoshop files into
So yeah, this is a problem without an easy solution. Probably the best thing would be to make a common installer such as autopackage and leave it up to the distro to support it and work with it. Whether the distro wants to use autopackage exclusively isn't required.
The reason apps are not ported from Windows and OS X to Linux is that it is a poor use of resources. Why port apps to an OS that such a small fraction of users use? LSB will not solve that problem.
Linux needs to gain popularity from the ground up, not the top down. Especially given the nature of F/OSS and community driven development, the Linux community should not be looking to big software companies for handouts. How much would Adobe have to sell Linux Photoshop for in order to make money off of it?
Yes, I know there are arguments that companies should be trying to steer their users toward Linux, but without an apparent bottom-line payoff, this will be the exception, not the rule.
From an LSB whitepaper: "without a widely supported binary standard for linux, a single vendor, de facto standard will emerge, effectively removing choice and locking end users in". I feel that as long as linux competes with itself it won't effectively compete with other commercial OS (at least for mass adoption on the desktop). Also, I'd be more interested in learing compiling stuff if the differences between distros didn't create such a moving target for the student. I'm keen to learn, but make it too hard and I'll go off and learn something different.