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

Photoshop?

[Geeky]

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)

Re:Photoshop?

[cronot]

If Linux catches on, Adobe and many others will jump in sooner or later. I think you should rather ask if it's going to be sooner, for Adobe at least.

Somehow, I just don't think so...

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?

[Anonymous Coward]

With Linux being used so much for hollywood-style movies, and linux being standard for lots of web developement and such there is a strong demand for Adobe to port their product for Linux.

Maybe they feel that having a stable API in the form of a 'linux standards base' will enable them to be able to support their product without having to deal with incompatability issues cropping up all the time. (in time, I mean in problems cropping up in the time span of 2-5 years product lifes)

Re:Photoshop?

[hey!]

Adobe? Does this mean Photoshop could be on the cards?

No, big companies visit these kinds of initiatives the way great powers send warships on port calls arond the word -- to show the flag and to ratify that they are a great power. It doesn't mean they have any intention of taking part in any local disputes unless they have some interests at stake.

Re:Photoshop?

[CDPatten]

Adobe is just looking to take a notch out of MS, not to help Linux. They have publically said they are not afraid of any competitor but MS. Hurting your enemies biggest asset is always a plus for you.

Re:Photoshop?

[aichpvee]

Lack of "standardization" hasn't stopped a lot of high end (much higher end than Adobe) app developers from porting to Linux or developing natively on it. I think it's much more likely that they don't have the balls to take a "risk" on porting it. The slightly less likely reason is that they don't have the skills, though one would think they could afford to bring people in who do if that were the problem.

Either way, I don't see why anyone should give a fuck about a "standardized" Linux that has anything to do with Adobe. They haven't done anything for us and I for one am definitely not interested in any standard that they're involved in without some solid support.

And for what it's worth, I'd be willing to buy Photoshop for Linux today if they offered it, assuming that they make the necessary UI changes to actually integrate with a Linux desktop, which running it under WINE (that does work for doing a lot of things) fails miserably at.

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:Photoshop?

[imemyself]

Adobe's position in this does strike me as interesting as well. All of the other companies involved have major products for Linux(or have an interest in pushing Linux to sell servers/chips). Adobe has a free reader, that's it. Granted, I think there was an article on /. maybe a year or so ago about Adobe hiring a Linux marketing manager or something. And nothings happened, yet. At the least, I think this is Adobe trying to be "friends" with the Linux community so if/when Linux becomes big on the desktop, they will be in a good position to take so of the market.

Re:Photoshop?

[Dan_Bercell]

You probably hit the nail on the head with this one. Any company, especially one with so many good products dont want the support nightmare Linux currently is. With MS and Apple, they know what they are getting into, with Linux things can change so much from the 20+ ditros making supporting applications a possible nightmare (not to mention costly.)

Re:Photoshop?

[Fred_A]

Adobe had a weird version of Photoshop on SGI Irix for a while which seemed to be some kind of semi emulated Mac thing. So they might pull the same kind of stunt on Linux (except that the outcome would probably be cleaner thanks to Wine).

Re:Photoshop?

[lloydtesterman]

Actually there was a high end Acrobat server they had on Linux years ago. It did lots of cool stuff IIRC but started out @ around $5,000.00 per seat. They did not have a demo available for download then and I dunno if it still exists.

Re:Photoshop?

[bogado]

But for many people Linux can only catch on if adobe and many others jump in. Shure for many, many people who use their computer for internet and word, linux is already good enouth. But there are many other kinds of users, designers (want PS, indesign and maybe other), gamers (want the latest windows only non-opengl games), and so it goes. Sure there are many opensource tools that are adequate, but many lack the professional bits (gimp can't handle CMYK or duo-tone images).

Linux is getting there, if there is a base on witch adobe and other can count on they will probably be more eager to port their big apps to linux. but I don't think that every single dist out there should adopt this standard, only the main ones, red hat (and fedora), ubuntu (and debian), Suse and maybe others. If those adopt this standard, and there is say a PS that requires it, others will adapt if it makes sense to the project (who wants a router distribution that can run PhotoShop?).

Re:Photoshop?

[FuzzyFox]

If Adobe were smart, they would just make their own Linux distribution that runs PhotoShop, with whatever changes they deemed necessary, and then let everyone else standardize around them.

PhotoShop is a popular product, and people would flock to it, as long as they could run their other apps on it, as well.

Re:Photoshop?

[VdG]

I suspect that Adobe are more interested in it for Flash, now that they look set to buy Macromedia. In particular, for mobile computing. There was a piece in The Register about them buying Mobile Innovation, a mobile phone design company.
http://www.theregister.co.uk/2005/10/20/macromedia _mobile_innnovation/
Mobile Innovation seem to be a Symbian operation, primarily, but also do Linux work and there's quite a lot of opportunity for Linux in high-end mobile devices.

Re:Photoshop?

[LocoMan]

IMHO standars make more sense when it comes to low to middle end apps (including photoshop) than with higher end apps.

The general idea (from a quick reading of TFA) is that developers have a good idea of what will they find on a standard install of linux, so that there are less problems tracking down dependencies and the like, so that it's easier to create/port a program that will install and run right away for almost any distro (or so I've heard, I admit not being a linux user myself). This works best for programs that are supposed to work alongside with other programs, like adobe's own photoshop/aftefx/premiere combo... though lots of people might prefer photoshop/avid and the like, which could create problems if (just to give an example, no idea if these programs even have linux ports) photoshop was tested and optimized for redhat, while the others one for another distro.

It is much less of a concern when it comes down to high end programs like Maya or Houdini, where you'll very easily pay over 5 or 10 grands on a single program, or much more on more specialized software like medical stuff and the like. Basically when you go on that level that the software costs so much it's much more likely that the computer they run on will be designed around the program (instead of the program around the computer), and a set of standards are much less of a concern since you would just pick the distribution the software designer recomends (and quite a few will just not give you support unless you do that).

Or at least that's how I see it from this side of the monitor.. :)

Re:Photoshop?

[Bun]

Actually there was a high end Acrobat server they had on Linux years ago. It did lots of cool stuff IIRC but started out @ around $5,000.00 per seat. They did not have a demo available for download then and I dunno if it still exists.

It looks like it still does.

Re:Photoshop?

[shibashaba]

I've been think that Adobe would start porting their software to linux ever since the latest Reader came out. Completely ported to GTK and works beautifully. Why else would they bother doing that if they weren't thinking of porting other software to linux? I think sparkle and microsoft's pdf replacement have something to do with it. Also, the simple fact that people like Disney are willing to go through the effort of getting PS to run under wine shows that there is a demand to Adobe. If Adobe doesn't fill this demand it opens up a market for another company to make a linux compatibe PS replacement that also happens to run on Windows and OSX.

Re:Photoshop?

[LordoftheWoods]

Heck, I'm sure many would be willing to build a distro for them. Just set up an organization over which Adobe has veto power to build a distro at low- to no-cost. Adobe would still have to port it themselves, but they could let the volunteers on the project worry about deployment.

Re:Photoshop?

[mebollocks]

Like charge you ~800 bucks for a licence?

Any chance

[Anonymous Coward]

they can all decide to put similar files in similar places?

Not /etc/X11/

I LVOE IT!

Re:Any chance

[slavemowgli]

What's wrong with /etc/X11? That's exactly doing what you're talking about — putting similar files in similar places. Configuration files go to /etc/; X11 configuration files in particular go to /etc/X11.

So, what's wrong with that?

Re:Any chance

[stupidfoo]

This comment intrigues me. On one hand it (sort of) brings up the point about how annoying it is that each distribution seems to want to throw random files in seemingly random locations, instead of their being a standard spot for them.

On the other hand... the rest of it seems to be just random garbage, but it's gotten +3 Interesting mod.

Re:Any chance

[Jonathan.Sidego]

I totally argee with you!
I honestly consider the non-maintream-ness of Linux to be partially attributable to the messy filesystem.

I know it's inherited from old UNIX, but hey:
'Program Files' is way better than '/usr/local'!

:D This standard is gonna ROCK!

Re:Any chance

[pembo13]

You are aware that Linux filesystems are case sensitive don't you? And that space requires a '\' so "Program Files" is actually 16 keystrokes just for that one folder name, as compared to '/usr/local' which is 10 keystrokes, yet is a full path.

Re:Any chance

[sa666_666]

And that's why initiatives like this are doomed to fail. One person has a suggestion for the 'proper' place to put things, and another says that it belongs somewhere else. Repeat the argument ad-naseum.

What some people fail to understand is that the 'proper' place is the one that (a) someone just makes a decision on and is done with it, and (b) everyone else can depend on.

Who cares if it should have been /etc/X11 or /var/lib. Can someone just make a damn decision already? (yes, I develop software, and this unwillingness to just MAKE A DECISION is a pet peeve of mine).

Re:Any chance

[MBGMorden]

Well, it does make it a biatch. To uninstall programs. You have to search /usr/bin for the executable, then /etc for the config file, then /etc/init.d for the startup script. Get all the symlinks out of the runlevels. Delete anything it might have put under /usr/share. It goes on an on.

Now, some distros have nice uninstall routines, but that only works so long as you stick to their package management system. Most make files also have an install target built in, but that requires keeping around (and keeping track of) a seperate copy of that file.

IMHO, we would do much better to have every individual program keep ALL of it's files in a seperate directory under /opt.

Then have make a new type of symlink. All the symlinks are placed in the standard Unix locations and go back to the app directory under /opt, but the symlink is automatically removed from the system if the file it's linking to is removed. That would allow us to keep everything seperated for easy management and removal, but would still all the traditional usage of the file structure.

Re:Any chance

[kwalker]

Or just use the package manager that comes with your Linux distribution and knows where all of that stuff is already. It's easier than having umpteen hundred thousand symlinks thrown around the system.

Honestly, I don't understand how it's that difficult.

Re:Any chance

[MBGMorden]

The package manager:

a. Doesn't always have the latest version available.

b. Doesn't always work correctly. (am I just supposed to decide not to use a program if the package manager refuses to install it?)

c. Doesn't have every program known to man. Again, I'm not going to say "Gee golly darn. I'd love to use Avidemux since it seems so nifty, but there's no package. Guess I'll just patiently wait."

Using the package manager is not always a viable option. I use portage (Gentoo) whenever I can, but on some programs it's severely out of date (even when using the masked ebuilds). On other programs it simply doesn't have an ebuild available.

Also, we get into the situation where the user has to learn a new install/uninstall process for EVERY SINGLE DISTRO. People aren't going to bother with that, and companies certainly won't. If they can't crank out Setup.exe a la Windows, then most of them will simply ignore Linux as a platform (part of the problem is that Linux isn't really a platform, but if we want software support weren't going to have to make it into a standard one).

Re:Any chance

[Xamataca]

danm *nix! what's a folder called "etcetera" for??!!

Re:Any chance

[slavemowgli]

Use your distro's package manager to uninstall the program. :)

Re:Any chance

[thej1nx]

... or if the various application developers can finally make copy-paste work uniformally within X-Windows ?

Hmm...

[jez9999]

Also covered on FoxNews.

Has the payche(ck|que) from Rupert Murdoch arrived yet?

Re:Hmm...

[Kiaser Zohsay]

Has the payche(ck|que) from Rupert Murdoch arrived yet?

I was currious, so I looked. FoxNews (or FauxNews if you like) picked it up from eWeek.com by our old friend Steven J. Vaughan-Nichols. So rather than /. linking to Fox for cash, its Fox reposting insightful even-handed journalism to generate hits. I think the later is more noteworthy.

Hmm

[MrShaggy]

I agree, I think that standards such as directory structures and all that. It might not be as important. But that is a start. It takes too damn long someimes to figure out where X is on my system. It should be here, but its over there.

I also think that this would be good for having a strong divx like layer. I love linux, but there seems to be too many fads, and flavors-of-the-months for things like that. Games and all that would love something that is common to all sytems.

As long as the layer isnt imbedded into the kernel. L)
MMMMMMMMMM Standards

Re:Hmm

[meringuoid]

I also think that this would be good for having a strong divx like layer. I love linux, but there seems to be too many fads, and flavors-of-the-months for things like that. Games and all that would love something that is common to all sytems.

If by 'divx' you meant 'directx', then there's SDL. That, with the addition of OpenGL, could well become a Linux equivalent.

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!

Re:Hmm

[Sweetshark]

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

Re:Hmm

[Da_Weasel]

Filesystem Hierarchy Standard (FHS)
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 /media and /srv additions you see in distros now days.

Re:Hmm

[Lochin Rabbar]

Whats non-standard about that?

/usr/share/bin & /usr/local/share/bin

Re:Hmm

[MrShaggy]

instead of /bin /usr/bin why not just /bin/usr /bin/local etc etyc then you wouldnt get into as many repeating directories. If I don't know any better, let me know.

Re:Hmm

[i_should_be_working]

And even if distros did use different file structure I still don't understand why it's supposed to be hard for commerical companies to package software for every distro. Every commercial app I've ever installed came with everything it needed and put it in one folder. No dependency problems, no worries about where to put it's libraries. And they work with any distro.

For programmers that want to use existing libraries I can see how a lack of standards in file structure between distros might cause trouble for packaging but this isn't a problem for the commerical companies. They have their own libraries and toolkits anyway. How many of us had trouble installing Doom3?

Re:Hmm

[grimarr]

Historically, the distiction between /bin and /usr/bin (and similarly for /lib and /sbin) was that /bin and /lib contained just enough of the system to get to the point where the /usr disk could be mounted, bringing in the rest of it. When disk drives were small, that was important. And, although I've never seen it, some sites used an NFS mount for /usr, so that many machines shared one set of programs.

When you bring the system up in single-user mode, you won't have anything in the /usr tree, unless it happens to be on the same partition as /, so that's why the most essential programs
are in /bin or /sbin.

There may be other reasons as well, but that's my understanding.

Re:Hmm

[Daniel Baumgarten]

/usr is often a separate partition from /, so that wouldn't 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.

Re:Hmm

[xtracto]

I completely agree.

I am currently developing a game which plan to release as commrecial. I am working with SDL+OpenGL, and some other libraries. I am working under Windows/DevC++.

To deploy the program in windows I only have to create a folder and put 4 or 5 specific files in that folder:

mygame.exe
sdllibrary.dll
otherlibrary.dll
openGl.dll
mygamefiles/

Now, if I want to deploy it on linux I need to tell the user "you must have SDL library version X.yz of SDL library and xx.yy of other library". I am looking for a way to statically compile all the code that I use into my .bin executable so I dont have to depend on anything. I am sure this can be done, as IIRC on C you can link statically the functions you use (like puts, printf, etc). I would like to do the same, I dont care ending with a huge .bin (or .exe) file.

Re:Hmm

[Etyenne]

There is no such thing as /usr/share/bin.

Re:Hmm

[Lochin Rabbar]

Nor should there be a /usr/local/share/bin, that was my point. They don't exist, and that the original complaint amount the multitude of directories for executables was talking through a hole in his head.

Re:Hmm

[meringuoid]

How many of us had trouble installing Doom3?

I haven't tried Doom 3, but I tell you what, I gave Quake 3 a go when that came out. You wouldn't believe the hassle that was. I'd go into detail, but it was far too long and convoluted to post unless I was in fullscale flame mode...

Anyone else ever have a bugger of a time installing Q3 on Linux, or was I the only one?

Re:Hmm

[tchuladdiass]

In addition, a more modern reason for /bin and /usr/bin is when you're dealing with embedded systems. Most of them have a minimal root, then mount a compressed image over /usr.

Re:Hmm

[Knuckles]

You agree, but you don't get it :) I think that was exactly what the parent was talking about: you can do all this by statically linking on Linux, and then have your app selfcontained in a directory. Many commercial apps do this.

Re:Hmm

[rebelcan]

Exactly. If most people complaining actually took the time to do a google search, they'd find out that there IS a reason for all those directories.

If you're complaining about your self-compiled program installing stuff to /bin and /lib, then stop using --exex-dir and --lib-dir, etc.

I wonder if this kind of thing ( people mis-installing programs ) is more common with one distrobution than another? Like on a system like Gentoo or Slackware, where you're encouraged to do more of your own self-compiling, compared with more apt-get type distros.

Although you're right about the directory names not being immediatly being clear to new users. Trying to fix that now probably isn't a good idea though ( would it break dependancies for older systems? ).

Re:Hmm

[ckaminski]

What stops you from distributing a package containing these libs and doing the "same exact thing" that you do on Windows?

If it's LGPL, or similar, it's no big deal to redistribute libraries. I don't understand? You want to do one thing on one platform, then go out of your way to do something completely different on another platform when you don't even have to...

Re:Hmm

[Skjellifetti]

But there are a multitude of dirs for executables. I'd drop /usr/local/share/bin from the list, but sendmail is traditionally in /usr/lib. I also have a multitude of subdirs in /usr/lib with executables on my Solaris box (e.g. /usr/lib/lp/bin and /usr/lib/lp/postscript). Postfix puts its executables in some oddball place (/usr/libexec/postfix) instead of the sensible place (/usr/sbin or /usr/local/sbin). /usr/ucb is another traditional place to put BSD variants of standard unix commands on ATT based unixes and I've seen Linux distros that have copied that tradition.

Re:Hmm

[Matt Perry]

If usr is for user

usr stands for Unix Source Repository or Unix System Resources. People just pronounce it as the word "user."

Re:Hmm

[manno]

You make a good point, but this isn't what they are trying to address, they are trying to address the fact that Windows comes in one flavor with one set of libraries... meaning that compared to Linux it's the
MS Windows is the Dedicated-Console to Linux's PC-Box.

We all know the story already, but one more time can't hurt right?... With a Dedicated-Console the developer knows every piece of hardware on that console, With a PC-Box the developer has no clue what the end customer is going to have in their PC, and therefor has to either make compromises to get it to work on the widest array of PC's / or go for just the higher-end and alienate customers. Each option Dedicated-Console, or PC-Box has its advantages but as a developer I could tell you which one I'd prefer to write for.

A developer can program for Windows and have a guaranteed set of MS sanctioned, and maintained libraries to use on any Windows box bought off the self, or program for "Linux", and hope that the distro/user has put the libraries that you use on that box already. Or force your users to hunt them down themselves.

This may change in the In the upcoming 12 versions of Vista era, but so far MS has given developers one platform to program for when they program for "Windows". When they programing for "Linux", they have to assume that nothing is there, or they risk there program working incorrectly/not-at-all, as anyone who's installed a program that required dependencies, that are no longer easily found, or poorly documented can attest to. Windows/OSX aren't like that, they have 1 OS with tops 2-3 very similar flavors, to program for not 1 OS with 100+ different variations, and lord knows what screwball eccentricities.

In response to MS's use of Direct X some one suggested that SDL and OpenGL would be a good replacement for it(Direct X). But how would I as a developer know that a consumer purchasing my product had those libraries installed? That is the problem that these guys are trying to solve.

They are trying to make DISTRIBUTING a program for "Linux" across Linux flavors as easy as it is to distribute programs for "Windows". Linux needs this if it's going to go mainstream. I hope it takes off.

-manno

Re:Hmm

[vdboor]

/usr initially stood for 'user', separating the system disk from the user disk. Eventually it's role changed, /home was introduced and /usr got the acronym "Unix System Resources".

Re:Hmm

[Lochin Rabbar]

$ whereis postfix

postfix: /usr/sbin/postfix /etc/postfix /usr/lib/postfix /usr/share/man/man1/postfix.1.gz

It looks like the maintainers of my distro have fixed one of the examples you mention, which is one of the things I pay them for. That is to ensure that the applications they provide with the distribution conform to the FHS. The original poster seemed to me to be complaining that the FHS is borked, and then misrepresented it. You seem to be complaining about applications and systems that fail to conform to the FHS. Two different things. FWIW I agree with your complaint, FHS may be opaque to those that don't take the time to understand it, but it seems to me to be about as good a compromise as is possible.

Re:Hmm

[typical]

Why do you care where a binary is? It's in your path, right? How many Windows users care where their applications are installed (or know?)

Re:Hmm

[max_paine]

You might want to check out GoboLinux, an ongoing effort to build a distribution who tries to move away from the legacy filesystem structure. Here is an interesting read about the rationale behind the project, which explains why this is necessary and also perfectly possible.

Re:Hmm

[drsmithy]

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.

I see this said often, and it's really just silly. Editing obscure files in /etc is the accepted and recommended way of configuring unix systems and services, whereas directly editing the Registry in Windows is neither recommended nor expected.

Re:Hmm

[Tinidril]

I see this said often, and it's really just silly. Editing obscure files in /etc is the accepted and recommended way of configuring unix systems and services, whereas directly editing the Registry in Windows is neither recommended nor expected.

Not true. All windows configuration is done through the registry, just not always through regedit. Most Linux distros have graphical tools for configuring the system as well. What method is or is not recomended is moot. Windows doesn't recomend that you edit the registry directly because it is confusing and easy to screw up. The majority of windows users are not computer geeks, while the majority of linux users are. It's only natural that linux users would prefer going straight to /etc. That doesn't mean its the only way.

Also, as a windows user there have been many times that I have had to go straight to the registry to change things. For instance, its the only way I know of to lower your MTU when traversing a non-localy terminated VPN. I also go into the registry frequently to backup application configurations that I want to keep after a rebuild. Its much easier to grab app.conf out of /etc than it is to pull that data from the windows registry.

I think it is quite fair to draw a parallel between the registry and /etc, and in comparison linux wins hands down. Windows does generaly have better gui configuration tools than most linux distros, but that is becoming less and less true every day. In fact, I believe that some distros already have better gui configuration tools than windows; although that is often a matter of taste and perspective.

The best part about standards...

[Alt_Cognito]

Is that there are so many to choose from....

Re:The best part about standards...

[Anonymous Coward]

--Grace Hopper

She also said that, "it's easier to ask for forgiveness than it is to ask for permission." So would everyone stop making bloody announcements and just get the standards DONE WITH!

(For those who are interested, the context was a Chips Ahoy! magazine interview in which she threw a question back at the interviewer about when the magazine was going to get their subscription-handling computer system fixed. The interviewer replied that they were working on it. She replied that they should "just do it" and then quoted the line above. The original article can be found here.)

Re:The best part about standards...

[Tribbin]

Wow! Did you just make that up?

Or did you read it in my post yesterday?

http://slashdot.org/comments.pl?sid=165780&cid=138 29992

But not Sun...

[cryptoguy]

They prefer Java as the write-once, run anywhere solution.

This sounds good

[Stevyn]

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.

Re:This sounds good

[bheer]

It looks like companies, specifically Adobe, are realizing that people want to switch from windows to linux

No. In Adobe's actual paying customers use Windows and Macs, in that order (unlike the /. horde who complain they would use Photoshop _if_ their favorite distro was supported, and less than 1% of them would pay for it even then) and are generally productive with their OS of choice because Windows 2000 and above, believe it or not, make for excellent desktop OSes.

Adobe's newfound love of Linux has nothing to do with what their customers want today -- they have realized that Microsoft is testing the waters of competing with Adobe on its own turf by offering design tools for Windows (sparkle, xaml and particularly xaml/anywhere, metro). Although the products are nowhere as polished as Adobe's and the audience is slightly different, Adobe has partnered with MS long enough to see the writing on the wall. It knows that it needs to hedge its bets by adopting and evangelizing alternate platforms (assuming the MS of the future is just as aggressive as today's about /not/ developing for Linux).

Re:This sounds good

[Peter La Casse]

Adobe reader 7 for linux is great and works just as good as the windows counterpart

...unless you're not on the single architecture that it supports.

good intentions, but really a trojan horse

[CDPatten]

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.

Re:good intentions, but really a trojan horse

[MrShaggy]

I can see what you are saying, however, I think that it will force trhe companies to compete on a level playiong field. Kind of like the old beta max, DVD standard thing. Once everyone agrees, and the public accepts it, then it will be time to move on. Then everyone else will be able to enjoy it, and isnt that the whole idea behind this ?

Re:good intentions, but really a trojan horse

[C0vardeAn0nim0]

that's why things like debian and slackaware exists.

"distros for the rest of us" i call them, with apologies to frank constanza...

Re:good intentions, but really a trojan horse

[i_should_be_working]

"that's why things like debian and slackaware exists."

As long as they resist things like the so-called Debian Common Core which, like this Adobe-Intel-etc thing here, might just be another conglomerate of businesses that want to tell GNU/Linux how to be disguising themselves as the white horse of standards and uniformity.

Re:good intentions, but really a trojan horse

[pekoe]

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.

Re:good intentions, but really a trojan horse

[Mant]

Its open source, if you don't like the way Linux goes fork it.

Right now I think Linux could use some standards, not that every distro will follow it, but if you know any program that says it follows the standard runs (easily) on any distro that follows it.

Do any lone developers really alter the direction of Linux these days? And how would standards actually stop them? If we are talking about things like stanard libraries or interfaces, I don't think the market or business models are going to have much impact.

Re:good intentions, but really a trojan horse

[just_another_sean]

I don't think so. This gives the big companies a chance to push Linux out into the mainsteam. If the "single developer at home" wants to create ILD [ Incompatible Linux Distro] then there is nothing stopping her/him. That's the beauty of the GPL. But for the "single developer at home" that wants to create and sell the next Killer App these standards should only make it easier. Having big companies like this define standards does not change the fact that the software is and will continue to be free (libre).

Re:good intentions, but really a trojan horse

[Arker]

Eh? Moving target? Haven't you heard of 'make?'

The fact is, there are actually a large number of distinct (but very similar) Operating Systems that use the Linux kernel, and a lot of people get confused about this and talk about 'Linux' as if it were an Operating System alone. They're all source-compatible, which means it's trivial to run the same Free Software across the board, but it's slightly less than friendly to closed binary-only distribution.

A lot of people don't have a problem with that. Those that do, are welcome to work on 'solutions' like this, but they shouldn't be surprised when large portions of the community don't see the point. Particularly when they start off by proclaiming their desires 'linux standards' (thereby imply that the major community-supported OSs like Debian and its derivatives and Slackware are somehow 'non-standard') and deliberately adopting the design decisions of johnny-come-lately commercial distributors as the basis for their so-called standards. These moves seem almost calculated to alienate large portions of the community.

Frankly, the best (and in some sense only) real way to prevent lock-in is source-availability, and the only real standard is make. I'm not saying that the LSB is evil or that no good can come of these efforts - quite the opposite. The effort is a sensible one for those involved, although I think they've made some major tactical errors, and I really do wish them the best and think their efforts could result in real benefits for their customers, particularly if they do some reëvaluation and refocusing. But this effort isn't the end-all and be-all of the platform - quite the opposite, it's a niche concern, and those behind it would be well advised to recognise that fact and adjust their attitude if they'd like to see community support.

Re:good intentions, but really a trojan horse

[aconkling]

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.

Similar to what Mant said, your 'single developer' is free to reject any standards and stick to something else. But in the spirit of OSS, the more eyes, the better, so it doesn't seem (all) bad to have some companies' eyes looking at Linux too. If anything, it's just a different perspective, one that could just as easily be rejected by the community as accepted. It becomes a question of merit. Sounds good to me.

I, for one, welcome our potential standard overlords. But only if they agree with my standard.... ;)

Re:good intentions, but really a trojan horse

[pekoe]

Goodness me...

Yes, I've heard of make. Here's my problem: if I have to start editing a makefile to point to the right libraries (assuming my distro has the libraries) to get a compilation going, and depending on which distro I use the bits I need aren't all in the same place. Make isn't a standard unless there is a standard way of writing a makefile - and if there is, it isn't transparent to me, based on my experience. I have a lot of trouble learning how to do a complex and esoteric thing when I have to do something different today than it was yesterday. I think you'll find that most people, even the smart ones, are like that.

Hey, I celebrate diversity. But if you want to teach people to think for themselves, do it in small steps, mmmmkay? I'm a corporate chemist, not a programmer, and this stuff isn't second nature to me. I respect your superior knowledge; please respect my lack of it and how much my time is worth to me. Peace.

Re:good intentions, but really a trojan horse

[Eric Damron]

"This is really a wolf in sheep's clothing."

You're joking. Right?

As a developer I can tell you that some of the biggest problems with trying to develop for Linux is the LACK of standards. I never know what libraries I can count on being there. I can't be sure where they are located. Although it's getting better I still can't be sure that a new version of a library is backward compatible.

All of these things add up and make Linux development painful. If your goal is for Linux to be adopted by lots of third party software companies then you must provide a reliable platform for the building of products. That means standards.

Truly open standards will never be bad. Only the perversion of standards as a certain monopoly corporation does in its "embrace and extend" tactic is a bad thing.

Re:good intentions, but really a trojan horse

[killjoe]

I disagree. By competing with itself linux will get stronger. It will also weed out the less capable and less inventive programmers like yourself. What will remain will be the programmers that can deal with complex systems and produce better code.

Survival of the fittest.

Re:good intentions, but really a trojan horse

[IntlHarvester]

Those that do, are welcome to work on 'solutions' like this, but they shouldn't be surprised when large portions of the community don't see the point.

No, I think the commercial companies understand where "the community" is coming from. Maintaining binary compatibility requires discipline, testing, standards, and above all time and/or money. It's not that source compatibility is such a great solution, it's just that binary compatibility is hard issue, both politically and in cost.

The shoestring developers in the Linux world threw binary compatibility overboard mainly for efficiency and ease of development. Source compatibility was the cheap work around for a cost they could not afford to bear.

Only that cost didn't really go away -- it just got pushed onto the end users and porters. All of those thousands of Debian packagers bear the cost of binary incompatibility. The sysadmins who reinstall Fedora every 12 months bear the cost of binary incompatibility. The guy who pays RedHat $700/year/server for compatiblity bears the cost. The end user who can't find the package he wants bears the cost. And many of these "members of the community" are asking someone to do something about it.

Ulitimatly it's about expanding the market. The community can continue to shut costs onto the userbase

Re:good intentions, but really a trojan horse

[lengau]

These standards that they're setting up are good. They're not trying to force you to write something a certain way - you can go ahead and write it to depend on libthisisntincludedinanydistroexceptmine or whatever. What they're doing is writing a set of standards that you can choose to follow if you want for your distro or programs. The plus of this is that if the standard becomes widely accepted, companies will write more closed source apps for Linux (Photoshop, Winamp, etc.) because all users will have (apart from whatever a particular distro has set up) a specific way to access everything (like [almost] everyone has the GNU tools). Basically think of it as an expansion of the GNU tools to include any system function.

The benefit of this? well for those of us who support our own systems, probably nothing. But for companies that need to support Linux, it's huge. instead of having 500 different ways of doing something, you can support most users with just a generic system for all of this.

For me at home, it makes little difference. But at school I need to use Photoshop and InDesign for Journalism. If Adobe had made a Linux version, that wouldn't be a problem. But because there's no Linux version of InDesign and it doesn't work under WINE, I have a problem. Adobe's not going to make their programs for Linux until they have some standard for all of their stuff, but I need them under Linux.

I think they really need some sort of easy-to-use program that wraps around normal Linux installs for what they're doing. For example, I'm working (I'm not in a hurry; don't expect me to even release anything for a couple of years) on an application that builds support for just about any distro into a program. Give it a tarball (gzipped, bzipped, anything) with a specific directory structure, and it'll build a .deb, a .rpm, a .tgz (and/or tbz etc.) etc. The second part is a yum/apt-get/portage/etc. server that the user just needs to add to get the updates for that program (and the program itself). Finally, the third part is a user-end program that wraps around (insert package management system here) with this system. Say, for example, that I want to release a program with this system (assuming the user already has this last program). All I do is call my program with this and upload to the server. Then I tell the user to open this program and add http://my.website.com/url/to/packages to their list. The program adds /apt, or /yum, or /portage or whatever they need to the URL and adds correct formatting for that package management.

I think that's really what they're aiming for - one way for users of any distro to do anything necessary for support of their apps. Everything else can still be customized.

Re:good intentions, but really a trojan horse

[pekoe]

maybe I just don't get the internet, but i never understood the need to be rude to complete strangers - i'll assume you had a rough week and are just lashing out. anyways, i never claimed to be a programmer, i just took up learning linux for a hobby.

competition is good, but competition with other OS also forces people to make a better product, and gain market visibility. if linux remains inhomogenous for desktop users, how can it compete with windows? where is the incentive to market commercial software (games, for goodness' sake!)? there's nothing stopping you having a niche linux for specialist users as well.

i can understand if you think that the only people who should be able to learn linux are venerated programmers who have gone through a thirty year initiation in obscure computer ritual... no, check that, i don't understand that at all. in what way do you benefit by alienating people like myself - the non-programming but enthusiastic "power users" who know enough to advocate linux to their friends and family, and set up a cheap internet box for an impoverished friend with the spare pc sitting in the attic.

on a final note - linux doesn't need to compete with itself to capture best practice and improve. and i don't buy your survival of the fittest malarkey - if that were the way the world worked day to day, all of us geeks would have starved or been beaten over the head for our shoes by the strong, dumb kids before we got a chance to learn the l33t sk1llz that pay our salaries and make us useful to society today.

apologies for typing one-handed, someone knocked me off my bike on my way home. see, i had a bad day too.

Re:good intentions, but really a trojan horse

[Arker]

Here's my problem: if I have to start editing a makefile to point to the right libraries (assuming my distro has the libraries) to get a compilation going, and depending on which distro I use the bits I need aren't all in the same place. Make isn't a standard unless there is a standard way of writing a makefile - and if there is, it isn't transparent to me, based on my experience.

You shouldn't need to edit the makefile to point to the libraries manually. The configure script should be able to do that automatically. And autoconf writes the configure script automatically.

It is a tool that one has to spend a little time learning to understand and use, but it solves the problems you're talking about very neatly and elegantly, and is a truly enormous timesaver in the long run.

Re:good intentions, but really a trojan horse

[killjoe]

"i can understand if you think that the only people who should be able to learn linux are venerated programmers who have gone through a thirty year initiation in obscure computer ritual... no, check that, i don't understand that at all. in what way do you benefit by alienating people like myself - the non-programming but enthusiastic "power users" who know enough to advocate linux to their friends and family, and set up a cheap internet box for an impoverished friend with the spare pc sitting in the attic."

I think that by eliminating the casual programmer and the non programmer we gain higher quality code and a better reputation for reliability. It's as simple as that. People will judge the OS based on the apps they use, if 90% of the apps they use are crap written by half assed programmers then they will blame the OS for it. Just like they blame the lack of drivers on the linux kernel developers now.

"on a final note - linux doesn't need to compete with itself to capture best practice and improve. "

I call bullshit on that. So far linux has gotten better by competing with itself. That's what open source is all about. The competition between KDE and GNOME (as well as the lighter weight windowing toolkits) has lead to a plethora of innovations and continues to do so. If we just settle on one all that will happen is that linux will mimic windows for eternity and nobody wants that.

Anyway it's all a moot point. You have no way to punish people for working on a windowing system you disaprove of, you have no way to punish people for using a windowing system you disaprove of.

Why continue to bleat on about this issue when you have no idea how you would ever enforce such a rule?

Re:good intentions, but really a trojan horse

[pekoe]

Your point about KDE vs Gnome is well made... sort of. KDE and Gnome have gotten stronger as a result of competition between each other - but I can't name one feature that's useful to me or anyone I know that's provided in them that isn't in WinXP or OS X. In the cold eyes of commercial software, the fact that KDE has competed with Gnome is not relevent. If I were managing a project that allowed two different teams to work on two competing interfaces and consume double the resources, I would expect to be sacked unless there were very good reasons for retaining both projects. Shareholders notice such things.

"Why continue to bleat on about this issue when you have no idea how you would ever enforce such a rule?"

Err... standards. Any group that wants to be labled as LSB-compliant gets accredited as such. Google for iso-accreditation, and you'll see why companies think it's a big deal. As for "enforcing the rule" - you seem to think that this move heralds the appearance of FacistStateLinux where all development is sanctioned by a single body. No need to be paranoid. The commercial names backing the new standard are probably doing so because it is strategically useful to all of them to back a "standard" linux, because then they can market "standard linux"-compliant stuff with a greater chance of market penetration (and if I were Adobe I woulnd't market a linux-native Photoshop until I were sure of a sound base for the system that wouldn't detract from the image of my product). Commercial linux corps who want in have to prove themselves via LSB standards. Those who don't (niche, hobbyist etc) can give the LSB the finger if they want to.

Finally, I'm "bleating on" about it because it looks like you've completely misunderstood where I'm coming from.

It can't come soon enough

[manno]

I'm probably going to catch H. E. double hockey sticks for this, but it's about frigging time!

A. lack of standardized libraries across the Linux board is a big problem, I hope they release at least 3 three standards though, Server, Desktop/Workstation/Laptop, and Embedded.

-manno

P.S. Did you know OO.o2.0's spell check has the correct spelling of "frigging"?

Re:It can't come soon enough

[niiler]

I personally, am not sure about standardization of the install process. Currently there are three major package types: rpm, deb, and tgz. Each has its own package management, each of which has its strengths and weaknesses. RPM requires a large bloated database for functionality. It also seems to have the bulk of Linux users behind it. DEB is a close second as it is the package type behind many of the live CDs (Morphix, Knoppix) as well as Ubuntu. Apt seems to be pretty cool, but I have too limited experience with it to comment. TGZ is the classical slackware based and oldest package format. Installs are lightning fast and don't require a large database. With dependency info being built into each package now, tools like slapt-get do just about everything I understand debian package management can do.

In addition to the package types, it is nice to be able to put libraries anywhere on the system so that those of us who use multiple versions can get away with it. Standardizing on library locations could mean that this flexibility goes away. It seems that with good ./configure scripts, libraries are discovered without the need for such standard locations.

Finally, from the point of view of security, it is nice to know that virus and malware writers can't depend on my system having standard setup A. So many of their attempts to subvert my system (assuming they get past my firewalls, find a flaw in permissions, etc...) will go for naught.

Standards do have a place at the level of the kernel, or within a given window manager. But part of the draw of linux is its flexibility. Standardization beyond a certain point is not productive to those of us who need the ability to customize.

Re:It can't come soon enough

[mrchaotica]

...or within a given window manager. But part of the draw of linux is its flexibility.

No, standards have a place at every level of the software hierarchy, and especially across window managers. This, in fact, is required in order to achieve flexibility. You've gotta have good standards for things like drag-and-drop, copy-and-paste, configuration files, multimedia frameworks, etc. or else each "desktop environment" (how I hate that phrase!) becomes an ivory tower, cut off from every other one. Because of the stupidity of both the GNOME and KDE people in reinventing the wheel only for their particular set of software, instead of working together to create a single set of standards that all programs could use, I'm forced to only use GNOME apps, or only use KDE apps. They're effectively proprietary, because they make everything else incompatible (or at least a second-class citizen).

That's what's limiting!

Now, the way it should be is for GNOME and KDE to get together, pick the best non-conflicting parts from each, and throw away the rest. The user would still have a choice of whatever HIG or theme or window manager they wanted -- in fact, more choice than they have now -- but everything would work together.

Re:It can't come soon enough

[niiler]

I hear you about desktops. I agree that it can be frustrating. As the author of an unofficial installer for Vector Linux, I can tell you that it is a pain trying to place an icon on the IceWM, Fluxbox, KDE, and XFCE desktops when a new program is installed. Each particular WM uses a different standard. In fact, some WMs don't natively even support icons and require an addon such as ROX to support icons. That said, many features supported by some WMs are simply not even supported or even wanted by other WMs. This would require every WM author to learn some of the API of every other WM. I don't think that's reasonably going to happen for all kinds of reasons.

About the only thing I can think of is to go to an XML format for:

• Placement of icons
• Name of program
• Location of program
• Icon image location
• Actions (when supported)

Then, everyone is using the same .destop file format and if there is a feature your WM doesn't support, it can ignore the XML. BUT, this is a long way from happening considering the vast numbers of WMs available.

A Window By Any Other Name

[yancey]

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. :-)

Re:A Window By Any Other Name

[cerelib]

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.

Re:A Window By Any Other Name

[LordKazan]

yes writing applications ontop of KDE and Gnome requires using different system libraries that have incompatable APIs

IIRC

I always use wxWidgets.

You also want the presentation of your controls to be as similiar as possible. Take these two images for example - they're both the same app that i'm working on - one is on windows/wxWin and linux/wxGTK

POF Constructor Suite 2.x Alpha build 20050902 Win32
POF Constructor Suite 2.x Alpha build 20050919 Linux

You'll notice the data editor panel in the lower left hand corner has marked alignment issues under linux/wxGTK (it also has them under linux/wxX11).

Re:A Window By Any Other Name

[Otter]

You know, a window is a window is a window. Is the code needed to create a window not abstracted from the window manager?

KDE and GNOME aren't just window managers. The code needed to make a full-featured (or even not full-featured) KDE or GNOME application relies on the presence of KDE or GNOME libraries and resources.

Re:A Window By Any Other Name

['nother poster]

I run the KDE desktop on the KDE window manager. I run KDE and Gnome apps. They all work fine. The Gnome apps don't look exactly like the KDE desktop, but I haven't played with any of the themeing capabilities, but they might fix that minor issue. Where is the problem? If you're commenting that Gnome doesn't look like KDE, have the distros install both. You can then select the desktop you prefer from the GUI login screen. Once again, no problem, even if someone else like your mom is using your system and she's used to the other desktop. As small as some of the desktops/window managers are you wouldn't even notice if you threw fluxbox and a few more of the smaller ones on.

Re:A Window By Any Other Name

[mrchaotica]

The code needed to make a full-featured (or even not full-featured) KDE or GNOME application relies on the presence of KDE or GNOME libraries and resources.

...which is why GNOME and KDE are harmful! GNOME and KDE represent a huge duplication of effort, which should have instead been put into libraries that are designed to work for any unix-like system. We did it for libc, we did it for SDL, we did it for XLib, we did it for ALSA... why can't we do it for widget sets?!

See, the problem is that the very idea of making a "GNOME application" or a "KDE application" is WRONG! People should worry about making an X11 application instead.

Re:A Window By Any Other Name

[Karaman]

Come on, GTK2 apps run even on a twm and they are beautiful enough even for the enterprise! and the app will learn as smooth in KDE, GNOME, XFC and all other window managers. It is just a GUI for linux sake, why coding for specific desktops (using kdelibs, gnome-ui, etc) when you can just code with a toolkit like GTK2 and QT and install a few GUI-only libs on the user machine.

Re:A Window By Any Other Name

[Otter]

GNOME and KDE represent a huge duplication of effort, which should have instead been put into libraries that are designed to work for any unix-like system.

Huh?!?!? That's exactly what they are! For historical and political reasons, they're not considered "standard" Unix libraries (although the GNOME guys pushed a while ago for some of their libs to be considered standard), but that has noting to do with any technical difference.

By the way, who is this "we" you did all that stuff with...?

Re:A Window By Any Other Name

[mrchaotica]

Huh?!?!? That's exactly what they are!

No, it's not, because they only work with themselves. If they were truly compatible, you'd be able to mix-and-match them with each other, and with other toolkits (e.g. Motif).

For historical and political reasons, they're not considered "standard" Unix libraries

Exactly! That's what I'm complaining about!!! Linux is being held back because it's "hard to write for", because it doesn't have a standard desktop toolkit! And the worst part is indeed that it's due to stupid "historical and political reasons!"

(The "we" would be the Free Software community, collectively.)

Re:A Window By Any Other Name

[MaskedSlacker]

I like how it refers to GNOME and KDE as different versions of Linux. Idiot article. GNOME and KDE are not a source of the problem. GNOME applications work perfectly under KDE and vice versa. The author was just making crap up.

Re:A Window By Any Other Name

[AaronLawrence]

"You also want the presentation of your controls to be as similar as possible."

Maybe you do, but I and most users don't: they want the controls to look like other applications and the operating system.

Re:A Window By Any Other Name

[rebelcan]

But there is an incompatiblity issue between the two of them.

For example, I use mostly GNOME apps ( while using the Fluxbox wm ). Any time I use a KDE app ( usually k3b ), the open file dialog is completly unusable. Why? For some strange reason, I can't resize the open file dialog, so there's no little window ( the part where all the files show up ). Is this because I only have the minimum amount of kde libs needed to run k3b? If that's the case, why isn't something as simple as changing the size of the open file dialog part of the minimum kde library needed to run k3b?

I think that is the issue that a lot of people are talking about ( whether they are GNOME or KDE people ). If you use mostly GNOME, some KDE apps have unusable parts, and the opposite is probably true. If you mainly use one wm, sometimes programs based on a different wm become unusable.

[Yes, I know that there is a gnome version of k3b ( I think it's called gnomebaker ), but sometimes the kde version is just more visible.]

Re:A Window By Any Other Name

[MikeBabcock]

X11 applications suck. That's why people want to make Gnome or KDE applications; so they don't suck.

You want to write your own widget set? No? Then use someone else's. Feel free to Write a Gtk+ application or a Qt application that doesn't require Gnome or KDE, but you'll be somewhat limited.

KDE apps run just fine on my Gnome desktop.

Re:A Window By Any Other Name

[srock2588]

Isn't the point of standardizing linux distro's to make sure the apps you write would work perfectly fine no matter what window manager you use so long as the window manager also follows the standards? Its not about GNOME or KDE, its about both of them following the same standard so an app is not a GNOME or a KDE, the app just works on both.

Re:A Window By Any Other Name

[baquiano]

...which is why GNOME and KDE are harmful! GNOME and KDE represent a huge duplication of effort, which should have instead been put into libraries that are designed to work for any unix-like system. We did it for libc, we did it for SDL, we did it for XLib, we did it for ALSA... why can't we do it for widget sets?!

It's already done.

The widget libraries (GTK+ and Qt) are standardized and available for multiple platforms. You can run GTK apps in GNOME, KDE, Windows, MacOS X, etc.. Same for Qt apps.

You are confusing GNOME/KDE with GTK+/Qt. The former are much more than just widgets, they are Desktop Environments. There's a lot plumbing underneath (think KParts, Bonobo, etc.) Turning all this plumbing into neutral components (Desktop-wise) would be a hugely complex task.

IHMO, both KDE and GNOME are necessary because they represent different underlying philosophies. KDE is struggling to become a fully featured Desktop ("More is better"). GNOME is aiming to become the "It just works" Desktop. If you intertwin them, you get an ugly inconsistent unusable beast.

Re:A Window By Any Other Name

[good-n-nappy]

Yes, the KDE versus GNOME thing is mostly irrelevant. But your statement that broad acceptance is dependent on having fewer options is probably also true. What often happens in situations like this is that the winner takes all. That ultimately leads to fewer good choices. Sure there will always be choices on the fringe but you can pretty much guarantee that it'll take more effort to live there.

I think this whole discussion is pretty much irrelevant anyway. The real problem with Linux is not applications. The problem is device drivers. I think a huge chunk of the windows market would be happy to use open office, gimp, etc... if they know that when they buy that new wireless card, camera, printer, frikin usb mouse, etc. it would just work. The way this will get resolved is when one of the big boys really decides to compete on the x86 desktop OS market. By big boys, I mean one of IBM, Google, or Apple (yes I know about OS/2). When one of these players starts making deals with device manufacturers you will see a snowball effect in adoption. Granted, it may end up being a BSD based OS. That just underscores my point that the openness of the OS is somewhat of an illusion anyway since one of these companies will end up owning *the* distribution that everyone will standardize on.

Re:A Window By Any Other Name

[mrchaotica]

Turning all this plumbing into neutral components (Desktop-wise) would be a hugely complex task.

The fact that it's complex doesn't make it any less necessary! Unless you want to start saying "I use the GNOME OS" or "I use the KDE OS" -- if you want it to remain "the Linux OS" -- all the plumbing has to be desktop-neutral, or else it's useless for people trying to make "Linux applications." That's why Adobe et al. don't want to port their applications to Linux -- it's because currently, there is no such thing!

Re:A Window By Any Other Name

[Otter]

Exactly! That's what I'm complaining about!!! Linux is being held back because it's "hard to write for", because it doesn't have a standard desktop toolkit!

I'm sorry, but you simply don't understand this.

X11 isn't a Unix standard because it's more intrinsically "standard" than the KDE and GNOME libraries are. It's standard because it's accepted as such. There's nothing technical keeping KDE or GNOME from being any less standard than X11; each simply has been unable to displace the other the way X displaced competing windowing systems. One can certainly argue that this is a wasteful duplication of effort (and many people do), but your technical assertions are simply wrong.

Re:A Window By Any Other Name

[VENONA]

"Adobe et al. don't want to port their applications to Linux -- it's because currently, there is no such thing!"

Astonishing. I could have sworn I'm running half a dozen Linux boxen even as we speak.

Also, you do realize that you're asking for a *lot* of bloat, right?

Personally, I don't care about Adobe ever appearing on Linux. Remember the Skylarov case? They're as evil has any corporation needs to be.

I'm not a graphic artist. I haven't been a Photoshop user since around 3.5. But, I'm not pretending The GIMP is as good. If I were a graphic artist, I'd probably be looking at the new graphics software from Apple, and maybe resigning myself to running it on OS X if it's as capable a product as PS.

All the while in the fond hope that The GIMP would keep improving. I'll run Free software as long as there's any possible way I can do the job with it.

Re:A Window By Any Other Name

[killjoe]

"See, the problem is that the very idea of making a "GNOME application" or a "KDE application" is WRONG!"

That's a stupid and in the end useless statement to make. So unless you have a way to actually punish people for working on a desktop you disaprove of nothing can be done about it.

Having said that every major distribution, every single one, comes with gnome as default. There is a default desktop and it's gnome. KDE is there for people that like it and every major distro includes it for those that prefer KDE. That's the way things are, that's the way things should be.

Re:A Window By Any Other Name

[LordKazan]

that's exactly what i said

Re:A Window By Any Other Name

[IntlHarvester]

(Allow me to reinterpret the argument)

The issue was that both Gnome and KDE became branding and marketing machines very early on, with goal of garnering end-user loyality to their particular programming toolkit over the other. Thus a thin bright line was always drawn between a "Gnome application" and a "KDE applicaiton". In other words neither project had the goal of "making the Unix desktop environment the best". Their goal was "making sure our Unix desktop environment is the one people use".

And that focus has lead to a lot of technically shoddy decisions, including a vast and enormous number of desktop toolkit features that should not be tied (technically or marketing-wise) to a particular widget set or programming language/style.

Linux standards - history repeating itself?

[Anonymous Coward]

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.

Re:Linux standards - history repeating itself?

[kebes]

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

I feel like you're saying (and correct me if I'm wrong) that one of the strengths of Linux is that it has variety (hence it evolves, matches very specific needs, etc.). I agree that this is a good thing. Having different distros target different needs, different types of users, different types of usage environments... this is a good thing. A single standard may not be able to anticipate all the strange ways people want to use their OS... and sooner or later some distro would have to break the standard to do what they want.

Does that make the standard pointless? I would argue that it does not. Simply put, if a particular distro needs to break the standard to do what they want, then that's fair enough. They will meet a particular need and pay the price of reduced compatibility, interoperability, and ease-of-use. It probably won't be a big deal since the users of that niche distro will know what they are getting themselves into.

The place where the standard helps is all those things that don't have to be different from distro to distro. When someone is creating a new distro, they may not particularly care whether the cdrom gets mounted to /mnt/cdrom or /media/cdrom ... it makes no difference to them but they have to pick something. Here's where the standard comes into play. When the choice doesn't impact the quality of the distro, then why not use the "standard" way of doing things. That way, it will be easiest to integrate applications not originally written for your distro. In the limit, if you followed the standard closely enough, then all kinds of software would run, without modification, on your particular distro. This is a good thing.

So again, my point is that it is good to have standards so that people have something to follow when they need to make (arbitrary) choices. Of course no one is forced to follow the standard. And of course, this by and large is happening in the linux community. The filesystem is remarkably standardized when you think about it. Still, there's nothing wrong with formalizing a new standard, and then seeing if people follow it. I wish them all the luck, since this will make my life (as a linux user) easier. Even though you may think of Mandriva and Kubuntu as different operating systems, I like the fact that I was able to move from one to the other without difficulty.

Re:Linux standards - history repeating itself?

[Spy der Mann]

History is not repeating itself. The previous attempts weren't backed up with LOT$ OF $$$$. And I for one welcome our new corporate Linux overlords :-) (really, someone had to organize the Linux "tribes", don't you think?)

Good news, but might have some drawbacks

[Ruvim]

It is generally good news! This kind of cooperation might finally create some serious competition for M$Windows. On the other hand, I can see how these efforts can be hindered, just as new blue ray DVD has been. Also, I wonder if all the players will try to stick their freebie-leading-to-purchase "features" into this new desktop environment.

The Next Question Is:

[geomon]

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.

Re:The Next Question Is:

[bach37]

I think the many distros are the reason these companies want standards. They want to make sure their software will install and run on Gentoo, SuSE, Redhat, Fedora, Mandriva, etc etc. with no errors of libraries not being found, or missing directories. This is a good thing. If they want to have these companies' end goal software running on their distro, they will have to follow these standards.

Re:The Next Question Is:

[geomon]

I think the many distros are the reason these companies want standards. They want to make sure their software will install and run on Gentoo, SuSE, Redhat, Fedora, Mandriva, etc etc. with no errors of libraries not being found, or missing directories. This is a good thing.

No argument here. What developer in their right mind would trade creating software for one file hierarchy and library standard for the current situation?

If they want to have these companies' end goal software running on their distro, they will have to follow these standards.

But one of the nice things about Linux is the energy that individual developers bring to their work. It may be that new developers will still create what they want because it scratches their itch, but will make a tool set that will allow a user to install software intended for standards-compliant distros.

Re:The Next Question Is:

[Lussarn]

It doesn't matter if distros follow them. If you can't run say Adobe photoshop and Microsoft word on a distro because it ain't compliant it will probably lose market share and die out. The important thing is that developers don't have to target 10 distros, how many developers have experience in 10 distros and time to do that.

I don't see this as a big problem anymore. Take vmware as an example, closed source. Needs kernel module. Messes with init scripts. Still, I haven't tested a distro vmware doesn't run on. Gentoo as an example have vmware in portage and it don't use vmwares default installation. If vmware wasn't in portage it would probably be alot harder to install (Gentoo have it's own type of sysv init).

Now, vmware is a "high profile" program and gets lot of distro attention. But if vmware, Adobe and smaller developers can write to the same spec naturally distros will support that spec because otherwise they can't run important programs and will lose out on marketshare.

Re:The Next Question Is:

[tabdelgawad]

How many follow is not important. How many *mainstream business* ones follow is. If you get Red Hat, SuSE, (and maybe Debian/Ubuntu,) you've already won the battle. That's enough busniess linux market share to justify building apps commercially.

Re:The Next Question Is:

[advocate_one]

They want to make sure their software will install and run on Gentoo, SuSE, Redhat, Fedora, Mandriva, etc etc. with no errors of libraries not being found, or missing directories.

then they should fsking static link in ALL dependencies then... don't rely on the library being there... make sure you've compiled your code so it has everything it needs.

Re:The Next Question Is:

[srock2588]

There are advantages and disadvantages for a distro to follow the standard. If you are Suse and want to involved in the general purpose desktop market, then your distro better say "Linux Standard X Compliant" right on the box. If a distro is for some special purpose it may intentionally avoid the standards to set itself apart in some niche market. Getting the standards started is an addition to the linux community and makes good software development sense. Having one point of compliance makes it a lot easier for Joe Shmoe programmer or Huge Development Shop Corp. to make an App that anyone can use. This in no way intefers with the unique advantages of other disto's that choose not to follow the standard.

Re:The Next Question Is:

[killjoe]

The problem is that it's not in the interest of companies to follow these standards. There was the LSD but nobody really followed that. RPM is supposedly a standard but the RPMs differ between Suse and Redhat.

Finally there is already several package systems including zeroinstall and autopackage that address this problem, why start another one. For that matter why everybody doesn't adapt dpkg and apt I will never know.

Re:The Next Question Is:

[just_another_sean]

Well they don't all have to do they? Sure if a company wants to make a commercially viable Linux distro they probably should and will follow the standard. But if I decide to download Dettu[Xx] Linux (which was billed as 'the world's nastiest distribution' by it's developer) I pretty much know it won't follow the standard and I'm probably not going to want to put Photo Shop on it.

My point is the only distros that need to worry about the standard are those that care about the desktop market. Those of us who want/need the smallest, most secure Linux we can get for our servers already know a) where to get it and b) what to do with it.

If Debian decides not to follow the standard, for example, it doesn't matter to me, I'll still use it. But I may decide to put something that does follow the standard on my daughter's PC, especially if it results in more "end user" apps, because she uses the desktop. Regardless of the standards and who follows them or not there will continue to be plenty of Linux for everyone's special needs/desires.

Re:The Next Question Is:

[pthisis]

then they should fsking static link in ALL dependencies then... don't rely on the library being there... make sure you've compiled your code so it has everything it needs.

Then you have to include all your object files with your binaries (or otherwise fulfill LGPL requirements), as well as anything else needed to re-link. That is, assuming that you use any LGPL'd libraries (like glibc).

Re:It just means acrobat reader wont go away

[exi1ed0ne]

FWIW, I'm running Acrobat7 on Linux.

Apt...rpm...KDE...Gnome...choices choices

[manarth]

independent software vendors may choose not to target the Linux desktop

From TFA:

Some big names in the computer industry are pledging to make the development of desktop applications for the Linux operating system much easier than it has been.

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.

Re:Apt...rpm...KDE...Gnome...choices choices

[jswalter9]

I can't think of a distro that doesn't install the GTK+ libraries in the default $PATH, so if you want maximum penetration, there you go. Perhaps a win32 to gnuGTK auto-conversion tool? It could use the wine or cygwin codebase as a jumping off point maybe.

As far as install types, wouldn't it be nice to have a tool that automatically generates a variety of packages from your source? That would take some of the headache out of generating all those packages...

Re:Apt...rpm...KDE...Gnome...choices choices

[Svenne]

the only common thread is X-Windows (and not always that...what's about Sun's JDS Java Desktop System?)

JDS is X11 and GNOME with all the buttons relabeled to SUN- or Java-something. Not only that, but in Solaris x86, the X11 server is X.org 6.8.

Re:Apt...rpm...KDE...Gnome...choices choices

[Stevyn]

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.

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 /usr/portage/distfiles and have an ebuild work from there (as in sun-jdk, crossover office, etc.).

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.

Re:Apt...rpm...KDE...Gnome...choices choices

[zootm]

This does indeed suggest the death knell is sounding for variety on the linux desktop.

On one hand, yes, on the other hand that death knell could mean a lot more variety in terms of actual applications for the desktop.

Re:Apt...rpm...KDE...Gnome...choices choices

[pete-classic]

And adobe can't possibly make a different package for each distro, even the popular ones.

Why not?

Do you mean binary package (.deb, .rpm, etc.) or shiny shrink-wrapped box? It seems like they could put half a dozen different binary packages on one DVD and ship that as the "Linux" version.

-Peter

Re:Apt...rpm...KDE...Gnome...choices choices

[nomego]

Well. at least Gentoo has a solution for this today. When you install Cedega or sun-jdk for example, the ebuild fails if you don't provide the files you bought/downloaded. Why wouldn't this work for Adobe Photoshop as well?

Re:Apt...rpm...KDE...Gnome...choices choices

[WhiteWolf666]

We already have _several_ package management schemes that work across distributions AND desktop environments.

Autopackage is extremely user friendly, for example.
Apt works most everywhere (deb, rpm, tgz distributions)
SMART takes that integration work to another level (http://labix.org/smart)
klik:// is super-duper friendly for end users, and even with the K its being taken to gnome.

We don't need new technology. We need the existing technology to be made more wide ranging.

SMART builds on RPM/DEB/APT/TGZ systems, abstracting package management at a high-level. You can still use the 'older' tools, however. Think server.

klik:// is far easier installs for the end-user, and the klik:// architecture is mostly distribution agnostic.

Autopackage is very intelligent about putting whatever is needed whereever its needed, and fairly distribution agnostic.

The job of the LSB should be to push these standards, and make documentation avaliable so that these tools can work everywhere. Also, to make it _far_ easier to build packages that autoconfigure themselves for any distribution, and correctly setup dependencies for the appropriate package manager.

The best thing about building newer package management tools on older framework is that you don't have to change anything; you can keep doing what you are doing, or you can move on to the 'smarter' tools. If you build a flexible enough API, it doesn't have to be targetted at _any_ framework. You build tools into the desktop environment to support whatever package management scheme you could possibly desire, or you just rely upon integration with older standards to remain sane. In fact, proper standardization on flexible package management could actually encourage MORE variety in Linux desktop environments. If there's a standard way to handle installed apps and dependancies you don't have to do as much work in your desktop environment.

Flexibility thrives in an environment of sophisticated, easy to use tools. Look at all the work distribution creators have had to do to get their gnome and KDE to 'integrate'. If both can suddenly hook into a distribution agnostic app management system, you can provide more choice in environment at a far lower integration cost.

Regarding desktop/server distinction; that's simple. RPM/APT whatever isn't going away. The newer 'layers' are RPM/APT aware. Server/Desktop common software is managed at this level, using RPM/APT. Other utilities build on top of these; they transparently manipulate RPM/APT, using pretty GUI one-click install tricks, this, that, and the other. The only 'separation' is increasing layers of complexity.

Really, the only thing that will go away is unmanaged source-installs, because they really don't make any sense. It's very difficult to manage source-installs in a package managed world; there are a few utilies that will 'wrap' sourceinstalls into an RPM or a DEB, but you still have to do dependencies and the like by hand. ./configure, make, make install time has passed.

Re:Apt...rpm...KDE...Gnome...choices choices

[WhiteWolf666]

They don't need to do this.

All they need to do is create an Autopackage, or, better yet, and Autopackage and a klik:// image.

Autopackage kicks ass.
http://autopackage.org/

Re:Apt...rpm...KDE...Gnome...choices choices

[MaskedSlacker]

No its a problem with an easy solution. You people seem to think that packages are the only way to install software. Do you know what the real easiest way is for a vendor to setup a universal installer? A perl script. Have the distros set new environment variables, that are standardised, that point to all the relevant directories, and the presence of such and such necessary libraries. The perl script checks these, and installs as appropriate. Done. No revamping distro design. No loss of variety or choice in Linux. Just a slight amount of effort and collaboration between developers and distro managers on what environment variables need to be created, so the install script can find what it needs.

Re:Apt...rpm...KDE...Gnome...choices choices

[Coryoth]

No its a problem with an easy solution. You people seem to think that packages are the only way to install software. Do you know what the real easiest way is for a vendor to setup a universal installer? A perl script.

The problem with this is the maintenance/patch/upgrade/uninstall process. Part of the beauty of package management is that is provides a central registry of everything that is installed, making it a lot easier to maintain your system. At worst I would ask for something like autopackage which at least provides a single point for all third party software installed. Hopefully package manager integration will arrive in autopackage soon so that autopackages can register with the package manager and we can be back to a single system to track what has been installed on the system.

Jedidiah.

Re:Apt...rpm...KDE...Gnome...choices choices

[Stevyn]

Yeah, that's exactly what I said they "could" do, but that's going to be a pain in the ass for many users. My point is many companies will be afraid from customer complaints and increased support costs until a very simple (pop in cd, click, click, click, installed) solution exists. There is nothing technically wrong with the method gentoo uses for distfiles it is not allowed to distribute, but practically it would be difficult for people. of course now gentoo isn't the best example since people who use it are generally more knowledgeable with how things like this operates (I didn't say smarter, I said more knowledgeable) so they might pick up on it faster.

It's all a matter of make it very simple so you don't have to spend time and money supporting all the "I put the cd in, nothing happened!" calls from frustrated users who just paid lots of money for that cd.

Re:Apt...rpm...KDE...Gnome...choices choices

[nomego]

Yeah, I understand. I think we're both trying to achieve the same thing from different standpoints. I was thinking more along the lines of, assuming there would be a GUI for the package manager (which most package managers have): Package Manager -> Install Application -> Dialog: Insert CD -> (detect CD-insertion through HAL) -> Fetch required files from CD -> ... Optionally, if users want to do it the Windows-way, maybe the autorun.ini should contain Linux-related sections which could instruct the desktop environment to spawn the proper package manager. These are just ideas, but the bottom line is that I don't think a distribution-wide standard is neither feasible nor necessary. Intelligent package managers shouldn't (necessary) need a properly archived package if the distributor doesn't provide it. Instead, make a standard for distributing distribution-neutral applications (or material) and let the package managers add support for it.

Re:Apt...rpm...KDE...Gnome...choices choices

[wolf31o2]

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.

Why not? You have to support exactly 1 scenario to cover most of the "popular" ones. Two, if you're feeling generous. RPM and DEB. That's it. It is not hard, at all, to create a RPM that works properly on Red Hat/SuSE/Mandriva.

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 /usr/portage/distfiles and have an ebuild work from there (as in sun-jdk, crossover office, etc.).

You must mean like the multi-thousand dollar Maya that can be installed with the following commands on Gentoo:

mount /dev/cdroms/cdrom0
emerge maya
umount /dev/cdroms/cdrom0

How about Unreal Tournament 2004? (DVD just to make it simpler)

mount /dev/cdroms/cdrom0
emerge ut2004
umount /dev/cdroms/cdrom0

Now, Maya is only distributed as an RPM on CD, and UT2004 is distributed as a Loki_Setup distribution wrapped with MakeSelf along with data on the DVD. The games that are ported to Linux don't seem to have a problem being supported, why would other pieces of commercial software be any different? Is it really that hard to have a "setup.sh" on the CD? I've never understood the complexity problem that people seem to think is there. Is running "setup.sh" and clicking "Next" a few times really that much harder than running "setup.exe" and clicking "Next" a few times? Why is it that Veritas/Oracle/Epic/Id and others can get this and Adobe cannot?

And it also suggest "Frig gin"

[Mateo_LeFou]

what's that? I mean, what botanicals do you suppose are in it?

Re:And it also suggest "Frig gin"

[broggyr]

what's that? I mean, what botanicals do you suppose are in it?

Old refrigerator parts?

Different LSB levels

[MikeDawg]

I think that there should be multiple levels of the LSB standards. I think there should be an initial LSB filesystem standard, and then above that, there should be an LSB layout standard, and then an LSB application location standard, an LSB standard for package management (rpms, ick!), and further on there should be the LSB desktop environment for X layout.

I don't think the LSB should be, or have one standards base to rule them all. They should start several layers, so a distro could claim that they meet LSB Standards 1 (we'll call this the filesystem standard), and they also meet LSB Standards 2 (which is the application layout standard), but then the distro could claim that they don't met LSB standards 3 and 4 (which are, X, and their environment layouts) so a user can decide what he/she is getting in their distro. I think its stupid for the LSB to come out with the one end all standard for all forms of Linux.

Re:Different LSB levels

[MikeDawg]

Let me tell you my problem with RPMs. Remember, this is coming from a Slackware nut, so take with a grain of salt, if you wish. The time it takes me to build an RPM, with several missing dependencies (aka, download all the missing dependencies and install). As opposed to choosing my custom compile options (may not need the additional modules, or addons, that require additional packages). That is my primary issue with RPMs. I'm sure you can dig into the spec file and make changes in regards to which modules or addons (or options, or whatever you want to call them) to the packages you're building, but you may as well be doing a ./configure from source.

Re:Different LSB levels

[WhiteWolf666]

RPM isn't _that_ bad, however, its not all that great, either.

No conditional dependencies, for one. Difficulty in building multiplatform RPMs, for two.

There are alternative software distribution systems that do this better. Like autopackage, or dare I say klik://

The best of both worlds is an alternative package system that customizes for your system, and wraps the necessary-bits-to-be-installed in an RPM at the last minute. That way, you can install using, say, Autopackage, or plain source, and remove the RPM when you don't need it anymore.

I think its Kdesourceinstall does that, I can't remember the proper name of the package right now.

klik://, however, will make all these issues go away if it catches on. klik:// style packaging is the future of software distribution.

Color Calibration?

[ColdWetDog]

Does anyone know how Dizzney solved the color calibration problem with PS/Wine?

Come on

[bhirsch]

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.

Re:adobe reader 7 is crap

[Tim C]

Furthermore it does not follow ANY guidelines regarding buttons, neither kdes nor gnomes.

That's one of the major valid complaints left about Linux - there are too many damn widget sets. No third party developer is ever going to be able to make their product fit in perfectly with every users' desktop.

Don't use /usr/local

[amightywind]

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!

I have not seen /usr/share/bin, /usr/local/share/bin. These are grotesque. /usr/local makes an inconvenient and ugly garbage dump IMHO, just because of the length of the name. I much prefer /opt/. You can get long paths this way, but tentative and potentially disruptive packages stay segregated. My Gentoo machine doesn't have any of this confusion. You might complain that /usr/bin is overused. But the rc infrastructure is the best I've seen. Lightyears better than RedHat. I think because Gentoo drops all pretense of trying to support graphical system administration they have done a great job making text base configuration as good as it can be.

Re:adobe reader 7 is crap

[cerberusss]

Linux - there are too many damn widget sets

Well, I don't find the situation any better under Windows. We have the standard widget set, the Office widget set, and lots of applications use one that looks somewhat like the standards, but isn't quite.

Reality is not a Trojan horse

[ScentCone]

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.

And the more that single developers insist on trotting out oddball standards for everything that comes to mind, the less they'll be able to complain about business users not adopting Linux.

If Money driven corporations start calling shots

They're called "users with money to spend." You're confusing the vendors with the people the vendors work for (users). No happy users, no vendor profit. No profit, no vendor at all. No big vendors, no one for large business users to trust with their IT services/support... except maybe Microsoft.

standards that work best with their business model

And without customers wanting (and paying for) what they do, they wouldn't have any business at all, and you wouldn't have Adobe or IBM, or anyone else backing the better things that some "single developers" do come up with. But when a standard makes sense, and is adopted by both business users and the companies that serve them, that usually triggers both a large wave of additional development around that standard, and wider use of the resulting platform/apps by businesses. You can't get broad use at the office (and thus an urge for people to switch on the machine they use at home, too) without standards backed by the people that serve those businesses.

Didn't I just read...

[CarlJagt]

...the other day, a story about big corporate backers years ago proposing an internet naming- controlling- scheme? And this was regarded as a Bad Thing TM? And so it was Chased Away TM?

Yes, yes, everybody has an agenda. Only some of those everybodies have very big bank accounts and a very narrow mission in life. Should we get out the sticks?

Re:It's happening

[bhirsch]

And that is what needs to happen before there can be an expectation of companies sinking millions into desktop Linux.

wm menuing

[ChristTrekker]

If everybody could adopt a single file format to generate menus from, I'd be thrilled. I hate setting up my desktop, all over again, just because I am trying out a new window manager. It's hard to sell potential desktop Linux adopters on "the flexibility of Linux is a strength" when something as trivial as this is so cumbersome. Flexibility/choice can be a strength, but it can also be a PITB. The Free Desktop folks have a suggested standard for this...who is using it?

Re:bye bye kde

[maxwell demon]

Even if the standard demanded GNOME (I don't know), this wouldn't mean that there may not be KDE installed as well. It would just mean that GNOME has to be installed to be standard conforming.
It would probably mean that commercial apps would generally be GNOME apps. But since GNOME applications should run just fine under KDE, that should not be too much of a problem.
Of course TrollTech would surely prefer KDE as standard :-)

Different GUIs

[Conspiracy_Of_Doves]

A lot of people have mentioned the problems of which GUI these companies would write applications for. What if someone were to create wrapper around both KDE and Gnome GUI libraries that applications could use, and would detect which GUI was currently being used. That way, applications that these companies make could work no matter which GUI a user prefers.

Keep in mind that I don't use linux and am only somewhat familiar with appliction programming (I'm a web developer).

Re:Different GUIs

[Raseri]

A lot of people have mentioned the problems of which GUI these companies would write applications for. What if someone were to create wrapper around both KDE and Gnome GUI libraries that applications could use, and would detect which GUI was currently being used. That way, applications that these companies make could work no matter which GUI a user prefers. Keep in mind that I don't use linux and am only somewhat familiar with appliction programming (I'm a web developer).

Okay, keeping it in mind...:)

You don't need to be running GNOME, for example, to run GTK-based applications (GTK is the API that GNOME is built with); you only need to have the GTK libs installed on your system. So, realistically, Adobe (for example) could make PS a native GNOME application and include the GTK libs on the installation disc to make life a bit easier for those that use KDE and don't want to fsck around with looking for libraries that didn't get installed with the OS (thinking average person here, rather than average Slashdotter). Hope this helps.

Re:Different GUIs

[killjoe]

"A lot of people have mentioned the problems of which GUI these companies would write applications for. What if someone were to create wrapper around both KDE and Gnome GUI libraries that applications could use, and would detect which GUI was currently being used. That way, applications that these companies make could work no matter which GUI a user prefers."

You mean like swing, swt, wxwindows, fox, qt, fltk and a dozen other toolkits?

Re:adobe reader 7 is crap

[bheer]

Yes, since skinning became all the rage consistency has taken a back seat. However you overstate the case for Windows: most Windows apps look different because they WANT to look different (think Winamp's/Quicktime's/WMP's skinned controls). That said, the Office/Windows/IE widget sets (yes IE has its own widget set for web pages) are largely consistent and have very cosmetic differences -- most users can easily live with those.

The problem in Linux is that an app written for one desktop looks like crap on another. Take Ubuntu (I'm still on Hoary Hedgehog so I'm not sure if Badger fixes these): My Gnome desktop looks great until I start Konquerer (and I _need_ Konq because ^#*&ing Nautilus crashes hard on my SSL-ed WebDAV share). If I start up with KDE then Gaim and Firefox looks even crappier (horried fonts, tiny text). This is completely ridiculous and a great example of how the distro war costs Linux on the desktop.

Re:standards can help

[Maljin Jolt]

If you value yourself as a linux geek, perhaps you should try gentoo instead of certain monolitic distro.

Browsers vs. writing to the (GTK/KDE) API

[rhyre417]

The problem is really that people shouldn't have the mindset of writing raw GUI calls anymore.
Once you've build your web broswer or UIMS, you are then just sending message back and forth between your presentation layer and application. This should almost be a no-brainer, given the rich XML examples out there. Can anyone point to some examples?
http://en.wikipedia.org/wiki/UIMS (User Interface Mgmt system)

Details, please?

[jbn-o]

Please explain what "politics" you're referring to and how they are not in play right now. Some of the biggest businesses in the world are already heavily involved with Linux kernel development. Last I remember, people who don't like the strongly copylefted GNU GPL dismissed it in part on the grounds it was a "political" license (yet they also fail to explain precisely what that means and how that is a bad thing). Also, explain how the license of the Linux kernel (GNU GPL v2 plus linking permission, if I recall correctly) would be somehow obviated by increased involvement by business along the lines the GPL grants.

Free software isn't anti-business, it never was. The free software movement encourages businesses to participate in the freedoms we're all granted so long as they do so as equals, not entities with superior rights. I don't see how organizing to set standards for these issues endangers our software freedom.

Trading away software freedom is unwise.

[jbn-o]

Giving up your software freedom for some features is unwise. The free software community would not be where it is if the people who wrote and distribute free software behaved as you're advocating now. Proprietors would love to tell us how we can do the jobs they will allow us to do with computers. I understand why you would be attracted to features you miss—you've never been taught to value software freedom for its own sake hence you see nothing wrong with trading it away—but it is better to improve the GIMP to meet your needs.

Re:Trading away software freedom is unwise.

[superpulpsicle]

On this list, redhat is the only company with linux as the #1 revenue stream and #1 priority daily. They can make all the decisions they want on GNOME/KDE. But their decisions mean squat when the next kid in the basement come up with something better.

Adobe Systems
IBM
Intel
Hewlett-Packard
Novell
RealNetworks
Red Hat

It's about time !!

[bibi-pov]

Finally some guys with weight say it aloud. It's a pity it's just happening now. What's more disturbing is that once again FOSS people could not do it by themselves but it had to be a group of corporations. So revealing, so sad.

Re:will they choose between kde and gnome ?

[MooUK]

I personally think that it should be designed in a way that makes the GUI and so forth as customisable as people want IF THEY WANT TO CUSTOMISE IT. It should also be designed to be nice and usable for the not-so-fiddly user.

Yes, maybe there should be a standard default GUI for all, which is nice and friendly, but people who want to can instead plug a gui with a different style in and still have everything work perfectly happily, without weirdness. Maybe dialog boxes should be described content-wise in a universal way, and then the GUI system can take that and makes a dialog out of it.

It's not that the FOSS guys couldn't do it...

[Spy der Mann]

It was that the Linux zealots hindered them.

Standards are like highways. A reasonable person would say: "Thank goodness they made a highway in the middle of this jungle".
A Linux zealot would say: "Highways hinder our freedom! If we don't follow their way, we can go WHENEVER we want! (grabs tree-rope) AAAaaaa-AaaaAa-Aahhh!!!!"

Get the idea? Linux zealots often confuse "order" with "restrictions", and "chaos" with "freedom".

Re:It's not that the FOSS guys couldn't do it...

[bibi-pov]

I know, I totally agree with you. And as much as I love free software, this is the kind of childish opinion which I dislike about some people involved in FOSS.

Re:It's not that the FOSS guys couldn't do it...

[RazzleDazzle]

One problem with not having people strongly committed to their beliefs is we end up with complacancy and a mediocre result. Just "getting it done" is not something that should be settled for. If there were not people that thought the way the major corporations are going to do it is not the best way or even in the right directions then there is no devil's advocate or people willing question or investiage certain decisions or motives and you end up with something like Fox News and millions of people thinking that Fox News is good enough.

So call them zealots or call them nutcases, I think they are needed. I don't call people like that nut cases, I call them opnionated. If they have worked to be in a position of power or influence then good for them and good for us I think.

Now, I am not saying what these opinionated people think is the best way either but we don't have any other feasible means to counter balance against big corporate investors who are mostly looking out for their big corporate sponsors. Besides... IBM, Adobe, etc did not create a lot of the software, they have only added to what exists; they are joining the party, not hosting it.

Just my opinion.

Re:adobe reader 7 is crap

[GeorgeNorton]

Install package gtk2-engines-gtk-qt (its in the Ubuntu repositories) and it'll make all your GTK apps (including Firefox) look like QT apps under KDE. I haven't seen an equivalent package to make QT look like GTK.

Re:will they choose between kde and gnome ?

[JoeQuaker]

When I used to use Mandrake Linux a lot back in 99', I could never pick between Gnome or KDE myself! There were certain things I liked about both, so I would just have both installed and pick one or the other in the startup menu.

Didn't we discuss this already...

[cranky_slacker]

about a month ago (http://slashdot.org/article.pl?sid=05/09/21/13392 11&tid=185)?

I thought so. I said it then and I'll say it now: This is pointless until all of the major distros are on board. If you create standards and those standards get adopted by only some distros, then what you end up with is further fragmentation and your "standards" aren't.

Re:Static libs security issue

[xtracto]

wait for me to "patch" 'em :-)

Seriously, I know this is the classic argument the OSS comunity have but, if I wanted to have a "top notch secure" game I would make it OSS and the like, but what I like is something normal people can use.

The borgs cough and stir

[FishandChips]

Something like this is pretty well inevitable. It's not hard to see why. Bear in mind that big software outfits don't want their stuff to just run on Linux, they want it to run well and with a guaranteed "user experience". Both are deal-breakers for the Adobes of this world. It's also important to remember that top-class and easy to use software development tools are very important to the success of a platform. Microsoft were very clever in getting this aspect down pat for Windows.

And, hey, no one has to certify to this LSB or anything else in that line. If you don't want to, you'll very probably find that a swathe of apps won't run on your distro (in a few years' time) and many of your users will go elsewhere, but hey that is fine too. It's called consequences, and growing up to take responsibility for them.

I guess it's possible to try to influence change to the platform as the big money moves in, or to marginalize yourself by ranting at the world. But for good or ill, change of the kind envisioned in this article is clearly going to happen.

Re:The borgs cough and stir

[typical]

Bear in mind that big software outfits don't want their stuff to just run on Linux, they want it to run well and with a guaranteed "user experience".

And they sure as hell don't want to have to release their *source* in order for their software to run on different distros. :-)

KDE vs. GNOME is not Betamax vs. VHS

[srobert]

Most of us here know that the choice of desktop systems, KDE, Gnome, other, isn't relevant to what programs we can run. KMail runs fine with GNOME. Gnucash runs in KDE, etc. But users who are considering Linux, and even some developers, don't seem to know this. They seem to equate the choice with choosing a BetaMax or a VHS (I was alive in the 1980's). Each machine couldn't play the other's tapes. Hence, when the general newsmedia reports on the choice of desktops, potential users conclude that the Linux desktop isn't as mature as Microsoft Windows, because it hasn't converged on a consistent way of doing things. Linux advocates should be certain that potential users know that having a choice of desktops doesn't prevent one from running any applications.
  If you're trying to persuade a 40 something then tell them that choosing a desktop system is like buying a video recorder that plays both VHS and Beta and doesn't cost any more.

What about Apple?

[llbbl]

I thought you could already run Photoshop natively on a *nix system, its called OS X.

Standard for Kernel modules ABI

[guacamole]

We need a standard so that third-party kernel modules do not need to be recompiled with every minor kernel update. Only on Linux deals with this issue in such archain way. The third party drivers I install on Solaris or Windows boxes do not need to be reinstalled for YEARS despite numerous kernel updates until you do a major OS upgrade.

Where is OS/X for x86 ?

[shis-ka-bob]

When OS/X runs on a standard x86 this is a solution for the masses. Until then, you have to buy a new box to do this. That adds a great deal to the cost, even if Macs are not overpriced as in past years. I can take an old box and test any BSD, Linux distro or a version of Windows. I can't do that with OS/X, so I have to 'take the plunge' or else I'll never use a Mac. The 'transition barrier' for OS/X is very high. Even if the final state is very high, a high activation energy can be rate limiting. In this case, marketing follows chemistry :-)

LSB hasn't been the fix in the past

[VENONA]

See Ulrich Drepper:
http://www.livejournal.com/users/udrepper/8511.htm l

Historically, the LSB hasn't been very useful. Maybe it will in the next version. But not if the problems with the tests aren't sorted.

I was subscribed to the FHS mailing list, back in '98 or '99. I forget which version we were arguing about at the time, and can't check as the list archives don't go back that far. Part of the push to get that version out was that vendors just wanted *something*, optimal or not.

IMHO, it was that sort of thing that led to problems like multiple desktop environment binaries all being located in /usr/bin, etc. The workstation I'm writing this on has 2843 files in there, not counting X11. This is one reason why many systems are so slow to process this directory through a GUI combobox or file manager.

It's also the reason we didn't have /media much sooner, etc.

I'm not berating the list members. A lot of good came out of it, and there were many issues, such as allowing for how existing Unices used /opt, etc. But it could have been a lot better without vendor pressure.

IMHO, OpenGroup and LSB are as much about PR as anything else.

Whether to support Gnome or KDE?

[Skapare]

So here I am, trying to decide whether to support Gnome or KDE with this big project I am now planning. I think perhaps the simplest solution will be to pick an existing big project and see which they support. How about Firefox?

What its all about

[KayosIII]

The aim of this standard is for vendor's to be able to release a single binary and have it run on any LSB for Desktop compliant system.

the important parts are

• Reference releases of important graphical libraries. definately Qt and GTK not sure what others... Other libaries are going to have to be statically linked. So choosing the balance here is important
• A standard place for launching app, meaning a standardised menu system. So people can launch app
• Standardisation of part of the desktop that deal with interface with a running program. File dialogs,Printing,Etc
• Stock Iconsets are not out of the question

The standard is to be based on work of freedesktop.org, It will almost certain it will not include specifying which desktop environment is used - It will just specify the behaviour of the desktop when it comes to running a binary application

Re:adobe reader 7 is crap

[typical]

However you overstate the case for Windows: most Windows apps look different because they WANT to look different

I seriously doubt that an end user cares what was in the head of a developer. Whether or not WinAmp, Mozilla, Office XP, Lotus Notes, and so forth "want" to look different doesn't make a damn bit of difference. I don't see any users having trouble using the things.

Do over

[IntlHarvester]

...Ultimately it's about expanding the market. The community can continue to shut costs onto the userbase, but the users who are willing to accept that are all there. But improving the ease and economics of Linux ownership through binary compability will allow it into areas where it is currently has not been viable.

Re:Do over

[Arker]

No, I don't think you understand at all. Binary compatibility requirements would "shu[n]t costs onto the userbase." You have it exactly backwards.

Re:Do over

[IntlHarvester]

"IS NOT!!" wasn't a very compelling argument on the gradeschool playground either. Face it, the community has not really thought through the the cost-of-ownership implications of the status quo, and footstomping won't change that.

Re:Do over

[Arker]

No, it wasn't. Recognising that, you might want to improve your argument a bit.

Re:Do over

[IntlHarvester]

Nope, because what I'm describing exists on a factual basis, independently of your ability to understand it.

Re:It's happening

[westlake]

Just read Ubuntu forums and see. Many ordinary (not nerdy) Windows users are switching to Ubuntu.

How many Windows users have even heard of Ubuntu or post to any online forum?

FHS outdated

[Michael Wardle]

The reasoning for having a /bin and a /usr/bin is that you can have a very small root partition.

I don't see the need for that on a modern desktop system. Most of the guidelines in the Filesystem Hierarchy Standard come from a historical idea that you can share the same programs on every UNIX system on a site by mounting an NFS share on /usr, but this is an extra unnecessary complication for home users. Who even has separate / and /usr partitions today?

The /usr/share/bin directory is for binaries that may be shared among multiple systems.

I think the parent tricked you! The official description is:

The /usr/share hierarchy is for all read-only architecture independent data files.
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSH AREARCHITECTUREINDEPENDENTDATA

This precludes /usr/share from containing executable binaries, since they are different for each architecture. It was basically designed to separate the platform-specific and platform-independent files that were one both kept in /usr/lib. On my Ubuntu Linux system, /usr/share/bin doesn't even exist.

Re:FHS outdated

[Michael Wardle]

As I said, /usr/share can't contain binaries, so naturally there is no /usr/share/bin. The sentence stating Ubuntu doesn't have /usr/share/bin was just to highlight this point.

Re:FHS outdated

[Tinidril]

I don't see the need for that on a modern desktop system. Most of the guidelines in the Filesystem Hierarchy Standard come from a historical idea that you can share the same programs on every UNIX system on a site by mounting an NFS share on /usr, but this is an extra unnecessary complication for home users. Who even has separate / and /usr partitions today?

I think your usage of the word "most" is a little over-reaching. There are many reasons for having a smaller root partition with only critical tools installed.

Your point about it being an "unnecessary complication" for home users is also interesting. Firt, I would point out that there are more than "home users" that use Linux. Second, I would like to know exactly what complication you are talking about. If both directories are in the path, why would a user care which directory a given program is in?

One of Linux's advantages is that it is not aimed at any single segment of users, or usage scenarios. Thats not to say it can't meet the needs of specific user groups, but those needs are met in ways that don't excluse the needs of other user groups.

When doing server builds, I always have a small root partition for disaster recovery purposes. If I need to do a restore of /usr it is much simpler if it has its own partition, and if I can know that the binaries I am using to restore it wont be overwritten during the restore.

I think the parent tricked you! The official description is:

• The /usr/share hierarchy is for all read-only architecture independent data files.

Not at all. I was just making a general definition of /usr/share, not a legalistic one. I actually did point out later in the post that it is often used for man pages because they are architectualy independent. I have in fact seen executables shared from that directory in cluster environments with homogenious hardware. (Although it was not on Linux.)

Re:FHS outdated

[Michael Wardle]

I might have overstated a little. It's been a long time since I've had to recover my system with only the root partition mounted. On the few occasions I've needed to, a Knoppix live CD was a very good way to do it. I also use AIX at work, where /bin = /usr/bin, and it works pretty well.

/usr/share is a little like /usr/local, some sites use it differently than the FHS suggests.

As a user who would prefer to use the desktop, but nonetheless finds himself accessing the file system frequently, I think for most users the distinction between /bin and /usr/bin is unnecessary. I think eventually we'll end up with something like /Programs as GoboLinux does (also more similar to Windows and Mac). I also find unionfs interesting.

My main problems with the current hierarchy can be summed up:

• some programs exist in /sbin even tho unprivileged users might need to use them (for instance, /sbin/ifconfig, since netstat doesn't show each interface's IP address)
• programs installed in /usr/local/bin or even ~/bin are never first class citizen (for instance, when running from cron, which resets the path to /bin:/usr/bin or whatever the system default is)

/usr/bin versus /bin is down the list, but it's definitely not as friendly as it could be.

didn't stop Adobe Distiller, Reader on Linux

[Ignominious]

They already provide software for Linux - Distiller and Reader for example. Surely those 2 applications cover stuff like desktop integration, printing, filesystems etc. They've already gone to the trouble to implement these; why would Photoshop be any different? There are no OS barriers, it's just sensible to pool the design efforts together - freedesktop.org has been pretty successful already.
I guess they can and will provide Photoshop when they're certain there's strong demand for it - though professional users of Photoshop doubtless will run the OS with the widest portfolio of well-marketed applications.