Big Names Back Possible Linux Standards 239
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.
Photoshop? (Score:4, Insightful)
(and yes, I've used the Gimp, and no, it doesn't do what Photoshop can do)
Re:Photoshop? (Score:3, Insightful)
Somehow, I just don't think so...
Re:Photoshop? (Score:2)
Linux is getting there, if there i
Re:Photoshop? (Score:5, Insightful)
Re:Photoshop? (Score:2, Interesting)
Either way, I don't see why anyone should give a fuck about a "standardized" Linux that has anything
Re:Photoshop? (Score:3, Insightful)
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
Re:Photoshop? (Score:4, Insightful)
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? (Score:5, Insightful)
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.
Color Calibration? (Score:2)
Re:Photoshop? (Score:3, Interesting)
Re:Photoshop? (Score:2)
Re:Photoshop? (Score:3, Interesting)
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/macromedi a _mobile_innnovation/ [theregister.co.uk]
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.
Trading away software freedom is unwise. (Score:3, Insightful)
Re:Trading away software freedom is unwise. (Score:2)
Adobe Systems
IBM
Intel
Hewlett-Packard
Novell
RealNetworks
Red Hat
Re:It just means acrobat reader wont go away (Score:3, Informative)
Any chance (Score:4, Interesting)
Not
I LVOE IT!
Re:Any chance (Score:3, Informative)
So, what's wrong with that?
Re:Any chance (Score:2, Insightful)
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
Re:Any chance (Score:2)
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 ke
Re:Any chance (Score:2)
Honestly, I don't understand how it's that difficult.
Re:Any chance (Score:3, Insightful)
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 pr
Re:Any chance (Score:2)
Re:Any chance (Score:2)
On the other hand... the rest of it seems to be just random garbage, but it's gotten +3 Interesting mod.
The best part about standards... (Score:2, Funny)
Re:The best part about standards... (Score:2)
Or did you read it in my post yesterday?
http://slashdot.org/comments.pl?sid=165780&cid=13
This sounds good (Score:4, Interesting)
Re:This sounds good (Score:2)
...unless you're not on the single architecture that it supports.
Re:adobe reader 7 is crap (Score:2)
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.
Re:adobe reader 7 is crap (Score:2)
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.
good intentions, but really a trojan horse (Score:4, Interesting)
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 (Score:2)
"distros for the rest of us" i call them, with apologies to frank constanza...
Re:good intentions, but really a trojan horse (Score:2)
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 (Score:4, Insightful)
Re:good intentions, but really a trojan horse (Score:2)
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
Re:good intentions, but really a trojan horse (Score:2, Insightful)
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
Reality is not a Trojan horse (Score:3, Insightful)
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
Re:good intentions, but really a trojan horse (Score:2)
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 i
Details, please? (Score:2)
It can't come soon enough (Score:2, Interesting)
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"?
And it also suggest "Frig gin" (Score:2, Funny)
Re:It can't come soon enough (Score:3, Interesting)
Re:It can't come soon enough (Score:2)
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 o
Re:It can't come soon enough (Score:2)
A Window By Any Other Name (Score:3, Interesting)
Re:A Window By Any Other Name (Score:4, Insightful)
Re:A Window By Any Other Name (Score:4, Informative)
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 [ferrium.org]
POF Constructor Suite 2.x Alpha build 20050919 Linux [ferrium.org]
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 (Score:2)
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 (Score:3, Interesting)
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 (Score:3, Insightful)
...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 id
Re:A Window By Any Other Name (Score:2)
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 (Score:2)
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).
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 st
Re:A Window By Any Other Name (Score:2)
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 displace
Re:A Window By Any Other Name (Score:2)
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 (Score:3, Interesting)
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
Re:A Window By Any Other Name (Score:2)
I think this whole discussion is pretty much irrelevant anyway. The real problem with Linux is not application
Linux standards - history repeating itself? (Score:3, Insightful)
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? (Score:3, Interesting)
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.
Re:Linux standards - history repeating itself? (Score:2)
The Next Question Is: (Score:5, Insightful)
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: (Score:3)
Re:The Next Question Is: (Score:2)
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
Re:The Next Question Is: (Score:2)
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: (Score:2)
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 o
Re:The Next Question Is: (Score:2)
Apt...rpm...KDE...Gnome...choices choices (Score:3, Interesting)
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 [sun.com]?)
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 (Score:3, Informative)
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 (Score:4, Insightful)
I'm using gentoo and ubuntu right now. I love them because thousands of software titles are available either with the click of the mouse or a few keystrokes in a console. But this works because people get those free packages and configure them for each distro either because their distro paid them or out of the goodness of their heart. But it'd be illegal for someone to make a photoshop ebuild that distributed all the files. And it's a pain to copy the photoshop files into
So yeah, this is a problem without an easy solution. Probably the best thing would be to make a common installer such as autopackage and leave it up to the distro to support it and work with it. Whether the distro wants to use autopackage exclusively isn't required.
Re:Apt...rpm...KDE...Gnome...choices choices (Score:2)
All they need to do is create an Autopackage, or, better yet, and Autopackage and a klik:// image.
Autopackage kicks ass.
http://autopackage.org/ [autopackage.org]
Re:Apt...rpm...KDE...Gnome...choices choices (Score:2)
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
Re:Apt...rpm...KDE...Gnome...choices choices (Score:2)
Re:Apt...rpm...KDE...Gnome...choices choices (Score:2)
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 (Score:2)
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 [labix.org])
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 system
Different LSB levels (Score:2)
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 m
Re:Different LSB levels (Score:2)
Re:Different LSB levels (Score:2)
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 R
Come on (Score:4, Insightful)
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:It's happening (Score:2)
Different GUIs (Score:2)
Keep in mind that I don't use linux and am only somewhat familiar with appliction programming (I'm a web developer).
KDE vs. GNOME is not Betamax vs. VHS (Score:3, Insightful)
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.
Standard for Kernel modules ABI (Score:2)
Re:Hmm (Score:3, Insightful)
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/bi
Re:Hmm (Score:4, Insightful)
Whats non-standard about that?
http://www.pathname.com/fhs/pub/fhs-2.3.html [pathname.com]
Re:Hmm (Score:2)
Whats non-standard about that?
Re:Hmm (Score:2)
Re:Hmm (Score:2)
Re:Hmm (Score:2)
Re:Hmm (Score:2)
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
Re:Hmm (Score:3, Insightful)
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
Re:Hmm (Score:2)
Re:Hmm (Score:2)
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:Static libs security issue (Score:2)
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.
Re:Hmm (Score:2)
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 (Score:5, Informative)
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.
Re:Hmm (Score:2)
Don't use /usr/local (Score:2)
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
Re:Hmm (Score:4, Informative)
http://www.pathname.com/fhs/ [pathname.com]
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
Re:Hmm... (Score:2)
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
Re:bye bye kde (Score:2)
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
Re:standards can help (Score:2)
It's not that the FOSS guys couldn't do it... (Score:2)
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".