Slashdot Mirror
Big Names Back Possible Linux Standards
Sean Feryl writes "Adobe Systems, IBM, Intel, Hewlett-Packard, Novell, RealNetworks and Red Hat are all backing the new Linux standards effort led by the Free Standards Group to form standards for key components of Linux desktop software, including libraries, application runtime and install time. The goal is to encourage the development of more applications for the Linux platform. 'With this complex and costly development and support environment, independent software vendors may choose not to target the Linux desktop, leading to reduced choice for end users and an inability to compete with proprietary operating systems', the group said." Also covered on FoxNews.
Adobe? Does this mean Photoshop could be on the cards?
(and yes, I've used the Gimp, and no, it doesn't do what Photoshop can do)
Sigs are so 1990s. No way would I be seen dead with one.
they can all decide to put similar files in similar places?
/etc/X11/
Not
I LVOE IT!
Is that there are so many to choose from....
It looks like companies, specifically Adobe, are realizing that people want to switch from windows to linux, but a big problem is still the native applications that are available. This is the long time chicken and egg problem facing linux growth. Adobe reader 7 for linux is great and works just as good as the windows counterpart so hopefully we'll see photoshop and the other parts of CS2 ported to linux. And if microsoft doesn't want to port their applications to linux (for obvious reasons) then I think people can still find good alternatives to their programs and use programs like photoshop that they are familiar with.
The more big companies get involved in forcing standards, the less the single developer at home has to say about what happens with the OS.
One of the strengths that Linux has is that anyone can write good code and alter the direction. If Money driven corporations start calling shots, then politics come into play, and they start promoting/forcing standards that are advantageous to how they believe the market should be, or standards that work best with their business model.
This is really a wolf in sheep's clothing.
I'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"?
I find it interesting and somewhat disturbing that the only way to achieve broad acceptance of an operating system is to offer the product with as few options as possible. An gross exaggeration? Yes, but consider this. The article states, "Developing applications for Linux desktops is a complicated endeavor now because of significant differences between two prevailing versions, called GNOME (GNU Network Object Model Environment) and KDE (K Desktop Environment)." So what we're saying is that an OS cannot be accepted by the masses if it has a choice of desktop environments, because it's hard to develop for two desktop environments? You know, a window is a window is a window. Is the code needed to create a window not abstracted from the window manager? Is what you display within the window dependent on the window manager? I don't see why this is so hard. Someone explain it to me. I know you will. :-)
Ouch! The truth hurts!
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!
Real Daleks don't climb stairs - they level the building.
I find all this talk of "Linux standards" amusing. To me it appears like POSIX, etc, all over again and I expect it will have about just as much success and impact as POSIX and friends did in standardising Un*x.
The first problem here is most of the "new blood" involved weren't around to witness the mistakes of Un*x in the early 1990s and so Linux has been as different as it can be whilst still being POSIX compliant.
What everyone needs to understand is that standards will never deliver what people are claiming they will.
What we should do is just accept that RedHat, Ubuntu, SuSE, Caldera, Debian, etc, are all different operating systems that happen to share a common source code -base-.
In the end, I expect that the standard will be nice but "not enough" because there will be "differences" in key places to allow each vendor to provide more functionality, expand, etc.
Can't the others just copy for compatibility? Yes and they can do so today but they don't because of different ideals.
All that said, I would love it if the mechanism to install a new software package and have it enabled at bootup was the same on _all_ Linux platforms. Unfortunately, today, it isn't and given the gratuitous differnces in how this is done, I'm not confident that it ever will be the same everywhere.
How many of the distros will follow the standard? I know that it is commercially important for the major distros to follow the standard, but newer and more innovative distibutions may forgo them. If you spend much time running Red Hat or SuSE, you can get frustrated sitting down and attempting to edit scripts on Debian, or at least that had been a problem in the past. Gentoo seems to follow its own path, and I haven't spent more than a few hours working with Slackware in five years. These are just a few of the different approaches to linux file management (especially the rc scripting). Then there are the various package management systems, updaters, and user scripts. I haven't had time to play with Ubantu, but it would take me time to work through the directory tree to see how things are arranged as well.
Linux standards are a great idea, but I don't know how many of the dozens of distros will follow it.
"Rocky Rococo, at your cervix!"
FWIW, I'm running Acrobat7 on Linux.
Pessimists.net - as if life wasn't depressing enough.
From TFA:
I'm all for a good set of standards; installation already varies across apts, rpms, and make installs. The article raises the issue of a standard desktop installation method, question is, will we see yet another install method?
How will this impact server systems and installation methods (apt/rpm) for non-desktop systems? What about software that operates desktop framework components and what you'd typically consider 'server' stuff...will there be two installation methods, one for the desktop and another for the service?
Cross-desktop compatibility...
I'm sure everyone here knows of KDE and Gnome as the two most popular desktops - so will these standards just be targeted at these? Or just one of these? What about the (near infinite) variety of other windowing systems - the only common thread is X-Windows (and not always that...what's about Sun's JDS Java Desktop System?)
Packaging Photoshop for linux will always be difficult because of this variety - Adobe can only support so many variations. The only way this will work is if they standardise on a single desktop system, killing off the others.
TFA talks about 'the first specification for Linux desktop software' and 'It plans to give compliant applications a "Linux Standard Base Desktop" certification mark.'. This does indeed suggest the death knell is sounding for variety on the linux desktop.
It's the non-standard nature of the directory tree that gets on my nerves. /bin, /usr/bin, /usr/share/bin, /usr/local/bin, /usr/local/share/bin... Aargh!
Whats non-standard about that?
http://www.pathname.com/fhs/pub/fhs-2.3.html
Filesystem Hierarchy Standard (FHS)
/media and /srv additions you see in distros now days.
http://www.pathname.com/fhs/
This is a well known standard that has been around for quite some time. Most distros that I see have finally made the move to this structure. This was the primary driving force behind the
If you must!
what's that? I mean, what botanicals do you suppose are in it?
My turnips listen for the soft cry of your love
The reason apps are not ported from Windows and OS X to Linux is that it is a poor use of resources. Why port apps to an OS that such a small fraction of users use? LSB will not solve that problem.
Linux needs to gain popularity from the ground up, not the top down. Especially given the nature of F/OSS and community driven development, the Linux community should not be looking to big software companies for handouts. How much would Adobe have to sell Linux Photoshop for in order to make money off of it?
Yes, I know there are arguments that companies should be trying to steer their users toward Linux, but without an apparent bottom-line payoff, this will be the exception, not the rule.
The 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.
Don't disappoint your bird dog. Go to the range.
The reasoning for having a /bin and a /usr/bin is that you can have a very small root partition. Then when /usr gets mounted you pick up the rest of the binaries that you want for a fully functioning system. Moving /usr/local/bin and /usr/bin out of /usr and into /bin would defeat the whole purpose.
/usr partition gets corrupted you can still boot and have the tools you need to get they system functioning again. Kind of like a built-in rescue disk.
/usr/local/bin directory exists for binaries that are not managed by the distribution's packaging system. That prevents add-on software from breaking dependencies in the underlying OS. That is why most software that you download and compile yourself installs itself in /usr/local.
/usr/share/bin directory is for binaries that may be shared among multiple systems. For instance an in-house network may have an NFS shared volume with binaries that are used on all systems. Man pages are often included here because they tend not to change much from system to system.
/etc directory is much more complicated than it needs to be, and that things are hard to find. After I point out how much cleaner /etc is than the windows registry those complaints tend to go away as well.
The reason you want a minimal root partition is that a smaller partition with fewer files will have less oportunity for corruption. That way if your larger
The
The
IMHO people who complain about this structure are just looknig for something to whine about. All of these directories are automaticaly added to the path, so most users should never have to think about them at all.
I often hear from windows users that the
If there is a problem with the unix directory structure its that the names are far from clear. What exactly do etc and usr stand for? If usr is for user then isn't that where the home directories should be? var makes a certain amount of sense to developers, but I don't know that most people would understand that means "stuff that changes a lot". I don't suggest that the names change because that could be an even bigger mess, but I do think that experienced users need to keep all this in mind when helping new users to understand the system.
XML is the best data format; unless your data needs to be read or written by a human or a computer.
I completely agree.
.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.
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
Ubuntu is an African word meaning 'I can't configure Debian'
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.
Digital Citizen
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.
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.
Writhe your naked ass to the mindless groove.