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.

Comments

Re:Photoshop?

[jferris]

I am sure that Adobe sees Linux is gaining acceptance in the CGI industry, and are smart enough to know that there is a good amount of money to be thrown around in there. The one thing that is certain is that one or more people in a position of power at Adobe believe in Linux enough to say that it requires standardization. Who knows? It might be this lack of standardization that is the reason we haven't seen Photoshop on Linux yet, as opposed to them deciding to bring it on when standards are agreed upon and adhered to. Possibly, Adobe has been the ones patiently waiting.

Re:Photoshop?

[Geeky]

Maybe. Adobe might be under some pressure for a fully native Photoshop from the likes of Disney, who have put work into WINE in order to get PS under Linux. I'm sure they'd prefer a native release. OTOH, perhaps the success of PS under WINE makes a full Linux release less necessary.

By taking part in this initiative, Adobe may well end up with the ammunition to turn around and say there's no way they can even contemplate a Linux PS until proper standards exist. Even more ammo if the initiative descends into petty wrangling or is poorly supported.

Either way, a big problem for PS under Linux is going to be around things like colour management. Serious photographers won't touch it unless their hardware calibration tools work.

Re:Hmm

[Tinidril]

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.

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 /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.

The /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.

The /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.

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 /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.

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.