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.
they can all decide to put similar files in similar places?
/etc/X11/
Not
I LVOE IT!
It looks like companies, specifically Adobe, are realizing that people want to switch from windows to linux, but a big problem is still the native applications that are available. This is the long time chicken and egg problem facing linux growth. Adobe reader 7 for linux is great and works just as good as the windows counterpart so hopefully we'll see photoshop and the other parts of CS2 ported to linux. And if microsoft doesn't want to port their applications to linux (for obvious reasons) then I think people can still find good alternatives to their programs and use programs like photoshop that they are familiar with.
The more big companies get involved in forcing standards, the less the single developer at home has to say about what happens with the OS.
One of the strengths that Linux has is that anyone can write good code and alter the direction. If Money driven corporations start calling shots, then politics come into play, and they start promoting/forcing standards that are advantageous to how they believe the market should be, or standards that work best with their business model.
This is really a wolf in sheep's clothing.
I find it interesting and somewhat disturbing that the only way to achieve broad acceptance of an operating system is to offer the product with as few options as possible. An gross exaggeration? Yes, but consider this. The article states, "Developing applications for Linux desktops is a complicated endeavor now because of significant differences between two prevailing versions, called GNOME (GNU Network Object Model Environment) and KDE (K Desktop Environment)." So what we're saying is that an OS cannot be accepted by the masses if it has a choice of desktop environments, because it's hard to develop for two desktop environments? You know, a window is a window is a window. Is the code needed to create a window not abstracted from the window manager? Is what you display within the window dependent on the window manager? I don't see why this is so hard. Someone explain it to me. I know you will. :-)
Ouch! The truth hurts!
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!"
From TFA:
I'm all for a good set of standards; installation already varies across apts, rpms, and make installs. The article raises the issue of a standard desktop installation method, question is, will we see yet another install method?
How will this impact server systems and installation methods (apt/rpm) for non-desktop systems? What about software that operates desktop framework components and what you'd typically consider 'server' stuff...will there be two installation methods, one for the desktop and another for the service?
Cross-desktop compatibility...
I'm sure everyone here knows of KDE and Gnome as the two most popular desktops - so will these standards just be targeted at these? Or just one of these? What about the (near infinite) variety of other windowing systems - the only common thread is X-Windows (and not always that...what's about Sun's JDS Java Desktop System?)
Packaging Photoshop for linux will always be difficult because of this variety - Adobe can only support so many variations. The only way this will work is if they standardise on a single desktop system, killing off the others.
TFA talks about 'the first specification for Linux desktop software' and 'It plans to give compliant applications a "Linux Standard Base Desktop" certification mark.'. This does indeed suggest the death knell is sounding for variety on the linux desktop.
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
Filesystem Hierarchy Standard (FHS)
/media and /srv additions you see in distros now days.
http://www.pathname.com/fhs/
This is a well known standard that has been around for quite some time. Most distros that I see have finally made the move to this structure. This was the primary driving force behind the
If you must!
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.
The reasoning for having a /bin and a /usr/bin is that you can have a very small root partition. Then when /usr gets mounted you pick up the rest of the binaries that you want for a fully functioning system. Moving /usr/local/bin and /usr/bin out of /usr and into /bin would defeat the whole purpose.
/usr partition gets corrupted you can still boot and have the tools you need to get they system functioning again. Kind of like a built-in rescue disk.
/usr/local/bin directory exists for binaries that are not managed by the distribution's packaging system. That prevents add-on software from breaking dependencies in the underlying OS. That is why most software that you download and compile yourself installs itself in /usr/local.
/usr/share/bin directory is for binaries that may be shared among multiple systems. For instance an in-house network may have an NFS shared volume with binaries that are used on all systems. Man pages are often included here because they tend not to change much from system to system.
/etc directory is much more complicated than it needs to be, and that things are hard to find. After I point out how much cleaner /etc is than the windows registry those complaints tend to go away as well.
The reason you want a minimal root partition is that a smaller partition with fewer files will have less oportunity for corruption. That way if your larger
The
The
IMHO people who complain about this structure are just looknig for something to whine about. All of these directories are automaticaly added to the path, so most users should never have to think about them at all.
I often hear from windows users that the
If there is a problem with the unix directory structure its that the names are far from clear. What exactly do etc and usr stand for? If usr is for user then isn't that where the home directories should be? var makes a certain amount of sense to developers, but I don't know that most people would understand that means "stuff that changes a lot". I don't suggest that the names change because that could be an even bigger mess, but I do think that experienced users need to keep all this in mind when helping new users to understand the system.
XML is the best data format; unless your data needs to be read or written by a human or a computer.