Adobe, IBM, Intel, Hewlett-Packard, Novell, RealNetworks and Red Hat are all backing the new Linux standards effort led by the Free Standards Group. The nonprofit organisation plans to marshal their resources to form standards for key components of Linux desktop software, including libraries, application runtime and install time. The group said Monday that it will encourage software developers to use its guidelines when building programs for Linux as part of its Linux Standard Base project.
Post a Comment
Member since:
---
Member since:
---
Member since:2005-10-02
Member since:2005-07-28
Member since:---
Member since:2005-07-06
If you look closer at the companies that are leading this they are Gnome-centric.
Well Novell isn't Gnome-centric because if you look at openSUSE and their selling products they've actively gone the other way.
I'd hardly call those companies Gnome-centric either. They've employed a bunch of people getting lots of free lunches in the open source community who happen to push Gnome and GTK, but it's not as if their companies use it. The companies listed on there are some of the biggest Windows developers around - hypocrites!
Lets hope they don't shut out KDE at the same time they are drawing up their standards.
I doubt it. People have been saying that non-stop for about six years, but when all is said and done, people want technology and a desktop that works. What's the point of drawing up standards for a desktop absolutely no one will use when put up against what they have now - Windows, perhaps Mac? After all, that's what happened to Unix and stuff like CDE in the 80s and 90s.
Member since:
---
Member since:2005-10-02
Member since:---
Member since:---
"What we need is standard that specifies the correct term. :-)"
Which would promptly be ignored by Linus as being bullshit, and then there-after be packaged in RPM, DEB and assorted other formats that will unpack themselves to different directories based on the Distributer's whim.
Red Hat's will require GNOME as a dependancy (as it uses aspell for some of it's sub-packages), and Debian won't include it in anything other than Sid for the forseeable future.
Member since:
2005-07-06
This is definitely a good move. I look forward to the fruits of the work.
About Linux destroying the language....I think it was Curly Howard who complained about mangling the "Queens English" with the messing up of tense in the sentences. Remember Justin Wilson, the Cajun Chef? "Now, what I'm going to DID is....."
Of course, a minor spelling error has nothing to do with the English language, as that can happen in any language and the point of the person was clear as can be. But all that said, it's amazing to me how many articles get published on the web with bad spelling and improper usage of language!
Member since:2005-07-28
Member since:
---
Member since:---
Member since:2005-07-07
I wonder what sort of overlap this will have with freedesktop.org
I don't think there is any overlap.
LSB specifies libraries, APIs and ABIs and freedesktop.org hosts specifications and is a collaboration forum for working on new specifications.
Very likely LSB will base some of their work on the that of the developers contributing to freedesktop.org
Member since:
2005-07-06
Standards for the sake of standards is what killed desktop Unix systems and open source software off in the late 80s and 90s allowing Microsoft to move off unchallenged.
Basically, and this happens a lot with the LSB now, many people get involved in technology wanking (and conferences in Hawaii) over who's software, and even particular implementations, will be counted as a standard. Once something is ratified as a standard (and it isn't even the best implementation most of the time) it then stagnates totally and all calls to replace it with a better option are totally ignored.
What is even worse than a lack of standards is crap and stagnant software that stays around simply because many people can call it a standard. That might not matter to these people, but it matters to end users. I see all the usual suspects have not learned that lesson.
Member since:
---
Member since:
2005-07-06
Member since:
---
Member since:2005-07-06
Member since:
2005-07-09
What is needed is Untied Linux. We don't need no stinking innovation crushing standards declaring, "oh system V is the only right way to do it", stupid crap suffocated UNIX in the formative years and this will do it again. There is a broad spectrum of requirements out there and we need the broad spectrum of linux distributions to meet them. STAND UP, give this trash the raspberry and just say no to conformity.
Member since:
---
IMHO those big vendors RedHat Novell HP are pushing Gtk as the standard desktop for Linux.
I don't understand why these companies push a toolkit/desktop that is technically inferior to what Microsoft and Apple have to offer. If they don't want to use Qt because it is not lgpl, why don't they a) buy Trolltech and release Qt as lgpl b) help the gnustep people to finish their toolkit or c) create something that is technically as advanced as Qt and release it as lgpl. While it maybe possible for them to make some money with gtk/Gnome based stuff in the short run, Linux will never be a viable desktop in the long run if it is technically inferior to Windows or MacOSX.
Member since:2005-07-06
Member since:2005-07-28
Member since:2005-07-09
Member since:
---
Linux is based on or around many, many standards. Examples might well be TCP/IP, The linux kernal and Posix.
However, I have to say that in general, the home brew nature of every man and his dog, and everyone involved is at the stage where hopefully people can come together.
It does'nt need RFC style standards. It just needs some simple stuff. I'll add that I think Linux's strength and the homebrew nature mean that this might mean that you never reach where you need to reach to get this.
During my Linux LPI 1 exam, I studied over several areas, RedHat Vs Debian. From the critical side, Permissions were different, start up scripts, and settings were held in different locations, logfiles were called names that logically held no resemblence to what they would be logging, software installation was all over the place, with each distro operating on its own idea of what and where things should go, software directories were the same. In the harshed terms, you might have a unified Kernal, but the system sitting on top suffers the homebrewed nature of being all over the place. And that was before the 2.6 driver changes.
Now, for the uninitiated home user who fires up linux, I am sure they can live with this, they probably don't delve to deeply in the system. And for the Unix specialist, I would guess that they too can cope with this 'evolving' mix of end product.
There *must* be a way that this could be addressed. The LSB to be honest does'nt seem to actually tackle the underlying issues. Perhaps there are just so many people and distro's involved that they deem it as unwanted should they go there.
The older Linux actually gets, the more cludgy and backward looking it seems to grow at the same rate.
Perhaps its time to take the kernal, and just start with a clean state from there.
Member since:
---
Let's have a nice, sane packaging format first that allows people to install what they want, when they want.
Currently, to get the latest software, people need to build from source or use 'unstable' repositories and pull in dependencies or find some RPM for Mandriva that might work on SUSE and and and...
Let's get using Autopackage (www.autopackage.org) and make new programs double-click easy install.
(If you don't see it as a problem, try getting the new Gnumeric release when it comes out, without using some 'unstable' package repository. Not easy, eh?)
Member since:2005-07-06
(If you don't see it as a problem, try getting the new Gnumeric release when it comes out, without using some 'unstable' package repository. Not easy, eh?)
Why not wait until the distribution has added it to their repository and have the new stuff tested a little bit, before you yourself clumsilly destroy your setup with the latest and greatest?
Installing Autopackage software is like Russian Roulette. No way on earth that an Autopackage binary blob can play nicely with each and every intricacy of all the GNU/Linux based OSes out there. I trust on the software management by the distribution.
Plus, I really, really, really hate the idea of having to trawl the net and download each and every piece of software I want to use and then afterward have to click each and every piece after I've downloaded them and then having to answer the same stupid questions over and over again. Click -> next -> next -> next times 1,000,000.
Repository-based and (graphic) package-manager accessible software is superior to any installshield solution.
Member since:---
You've just supported my argument even more. Why should users have to "wait for it to appear in the distro"? In many cases, a new major release of a software package fixes bugs and problems in earlier releases. And now you're saying, users shouldn't have easy access to those bugfixed releases?
That they should have to wait for it to get into their "repositories"? Or download the source (and all the dependencies) and build by hand? Or poke around for unstable repositories that bring in their own problems?
All to fix a bug? It's insane.
And if you hate the idea of 'trawling' the net for software, ask your distro to collect together Autopackages of software into one place, so you don't have to go hunting. That also leads to a MASSIVE reduction in duplicated effort.
Right now, when a security issue is discovered in FooApp, hundreds of developers for hundreds of distros scramble to patch, rebuild and distribute the exact same fix over the myriad of distros. If there was an Autopackage for FooApp, distro vendors could simply grab that and push it out to end-users.
If you look around forums on the Net, one of the most common problems Linux newcomers grumble about is software installation. They see FooApp, go to the site, and just want to download and run a program. But instead they have to go through the massive somersaults mentioned above, or wait five months for it to appear in their next distro release.
Do you think that's acceptable? Do you not think we, as a community, should be doing something to get Linux out of its 5~% market share, and going upwards?
Software installation under Linux is fiendishly messy, and projects like Autopackage could solve it -- with you STILL having your repositories if you wanted them.
Member since:---
I prefer the Mac approach, first developed on NeXT computers --> everything there is about an application is bundled within its own subdirectory; drag it/copy it to wherever on your system, double-click and it runs. Erase it, it's gone. Have many releases of the same app runnable on your computer? Sure!
For folks interested in writing apps for a wide-spread linux audience, including potential commercial developers, this would be the pipe dream.
Problem? All the desktop/services stuff. The icons, associations with files, launch/start menu, etc. MS led the way in requiring packages to stick things in system directories to make such magic work. Thus, they require install scripts that know where to put these things. It also requires (ugh!) uninstall scripts to remove this junk when you want to ditch or upgrade a package. An we all know how often we need to upgrade apps in linux!
Ditch all this. That's an accomplishment I'd like to see from a Linux Standards Board.
Let package managers handle the underpinning distro toolkit foundation stuff. Software like Open Office, Abiword, Audacity or Unreal Tournament should not have to be squeezed into /usr/bin, /usr/etc, /usr/lib, /opt/kde, etc. That's as bad as MS requiring DLL's to be stuffed into the Windoze directory. Remember DLL hell?
It was handling DLL hell which encouraged the creation of Installers in the first place - a kludge to handle a kludgey OS that required tens and hundreds of files to be put just so or else the program wouldn't run.
Heck with that. All these problems came from a time when memory and storage were scarce and there was 16-bit windoze to remain compatible with. Linux need not follow in such footsteps. I hope the LSB establishes a standard where Apps may be drag-n-drop install, like the Mac. Simple and clean for the expert, easy to comprehend for the newbie.
It will take work for something like this to come to pass, but what's the LSB there for, anyway?
Member since:2005-07-14
This has been discussed times and times already.
Apps have library dependencies. Having more copies of the same library installed would (probably) break dynamic linking in one or the other way. Either you would end up using a library from a different apps' directory or you would end up with two copies of the same library in memory. Though disk space and even network connectivy (at least some places) are cheap, RAM still is not. I'd rather use my RAM for a file cache than for duplicate copies of the same code.
There's nothing nice about drag and drop installation. Might be easy to explain - "just" download and drag'n'drop. Fits well into a desktop metaphore. However, I prefer typing "aptitude install app1 app2 ... app10" then doing ten drag'n'drops.
I also _welcome_ and _appreciate_ that the distro (Debian in my case) people test the new versions of applications and make sure they don't break too much of the existing stuff.
Member since:2005-07-07
I'd rather use my RAM for a file cache than for duplicate copies of the same code
Good point, but I think an even worse problem is maintainability.
Every app has to provide its own update mechanism and in the case of a security problem in one of the libs, you will need to get them multiple times and if one of the apps doesn't have an update you can't use the secured version of another.
Member since:2005-07-14
Every app has to provide its own update mechanism and in the case of a security problem in one of the libs, you will need to get them multiple times and if one of the apps doesn't have an update you can't use the secured version of another.
Yes. But I wrote about this point on OSNews so many times I did not want to go into it again.
Member since:2005-09-01
That's true, but what I'd like to see is an effort to define clean separation between foundation/base packages (libs, critical data) and leaf, application packages.
The first ones could be severely coupled and intermingled, could be developed intensively, break compat between eachother but as long as they would present an selfconsistent, extendable and stable api/abi to the second group user could sleep well. (see the analogy with kernel internal/external api)
The other group would be self consistent application packages that are only allowed to depend on an stable api of the first group but are not dependencies for any other apps (lets call it leaf packages).
Optionally distros could provide optional, special purpose extentions for the base and including more libs
That setup would enable to synergise both sw distribution ideas and combine their strengths:
+ foundation packages distribution would be repository-dependency graph based and thus would receive all the update goodness. As their number would be finite the approach wouldn't hit the scalability problems that whole encompassing repository based approach is ridden with
+ leaf packages could employ easy install=copy mechanism. As they would share popular foundation libs, the amount of bloat could be kept manageable
+ leaf apps would check for presence of nonfoundation libs and use them instead of their own copies reducing bloat even further
+ distros could still provide their repository of selected leaf apps to present userfriendly application selection mechanism (aka click'n'run) , but have to be be replaceable by upstream leaf packages
I believe that LSB is driven by this very vision but by taking conserve (yet only currently feasible) approach by including only handful of foundation components under its umbrella it limits its usefullness.
Of course there are technical obstacles to overcome:
+ borderline cases - e.g. should apache be considered foundation or a leaf package? - i think we could look at windows when deciding that
+ what about plugin enabled apps?
+ what about not stable, still necessary foundation components (e.g. power management, hotplug, virtually every new technology)
nevertheless i thing it's overall worthwhile.
rgds,
DS.
Member since:---
drag and drop and installation are different things. You can have a wrapper around apt so you can have a window called "repository" and another one called "installed packages" and when you drag from "repository" to "installed packages", it automaticly download and install the package and all its dependencies. i think this can be done with kioslaves or gnome_vfs.
Now if you complain that when you drop a package on "installed packages" it ask you to install N more packages (dependencies) and you feel bad about that, the "repository" window can be tweaked to show you only end-user applications and no library and utility packages, and when you drop a packages it only shows to you the final size of all packages together, the system can schedule periodic cleanings of unused packages so you don't have to think. With this you get the sensation that packages are simple files, even if you wish to pick the package and copy to a pendrive, the system can copy all needed packages (all dependecies) as a big one to the pendrive and when you get to another system and drag it to the "installed packages", the system only install the packages that are not already present.
with this system you can keep installing and uninstalling things and the system can keep tracking dependencies and updating packages and libraries without redundacy.
the only things neede are:
a new package type: package of packages
a kioslave or gnome_vfs to control the package manager
tag some packages to be shown as "end user applications"
Member since:2005-07-14
Do you think that's acceptable? Do you not think we, as a community, should be doing something to get Linux out of its 5~% market share, and going upwards?
I did not choose Linux for its market share. I chose it, because I like how it works, how it is created, etc.
You believe that technically-worse solutions are worth it for a project like Linux just to increase a market share? Keep in mind, that there is not one entity called "Linux", just a number of coders and distributions and companies, each with a different motivation and goals. I, personally, prefer technical correctness to appealing to Joe Sixpacks.
Member since:---
So hundreds of developers all scrambling to patch the same flaw for their distros is "technical correctness"?
So software that needs libfoo.so.0.2.1 but won't work on libfoo.so.0.2.2 and requires a certain GCC and glibc symbols is "technical correctness"?
Methinks you just enjoy saying things like "technical correctness" when you have no idea about the problem. It just gives you the warm and fuzzies :-)
Member since:2005-07-14
No. Having a unified way to install all software in your OS is technical correctness. Having a unified way to apply patches is technical correctness. Checking that a patch does not break the existing system / distribution is technical correctness. Utilizing existing dependency-resolving schemes and libraries-sharing (both in RAM and on disk) technologies is technical correctness. Getting your software from a central, trusted, verifiable source is (sort-of) technical correctness.
I agree that whatever worked with libfoo.so.0.2.1 should work with libfoo.so.0.2.2 as well. However, someone has to check / test it. Requiring GCC or glibc symbols is OK, if they are public. Requiring unsupported / deprecated symbols is not OK, but that is a coding issue, not packaging / distribution issue.
Methinks I should start ignoring anonymous comments.
Member since:---
Methinks you should spend some time with Linux newcomers, and help out on Linux newbie forums, and you'll start to see what a nightmare the packaging situation is. I've seen far, far too many potential convertees go back to Windows because it's way too fiddly and convoluted to get a new program.
If the labyrinthine tangle of per-distro repositories, duplicated effort, compiling or waiting months for a new distro release is all 'correct', how come so many other OSes have a much cleaner system?
Is the Mac, BeOS, RISC OS, Windows etc. way of installing software 'technically incorrect' then? Because to the vast majority of users, it's orders of magnitude faster and simpler.
I love Linux, but I've come to accept that there are inherent problems trying to developing a modern desktop OS by a vast number of disparate groups, working independently. It has bad side-effects as well as good. And yes, if you're involved with Linux purely for technical reasons, then these problems won't be a concern.
But if like me, you want to share Free Software and get the masses away from proprietary systems, we need to offer something better. In some ways we do, but in some ways we don't. You can choose to ignore these problems and the thousands of newbies struggling with them (I know, I run a Linux website forum), but don't complain when, in 2010, Linux still has ~5% of the market share.
Member since:2005-07-07
've seen far, far too many potential convertees go back to Windows because it's way too fiddly and convoluted to get a new program
It might be a matter of what you are used to or how you expect things to work.
I for example find it a lot easier to just type a query, click an install button and be done, but of course others might find it easier to search with google, locate a download page, potentially register for download, download and install.
Is the Mac, BeOS, RISC OS, Windows etc. way of installing software 'technically incorrect' then?
Besides Linux I have only experience with Windows and while it is a different approach for installing programs, it works quite well.
The main problem I have with their way is what happens after installation.
The program register themselves with the central software list but do not register any update hooks.
If you start a software update, they only thing it can update is the operating system and maybe other Microsoft software.
I really don't get it why other software vendors do not register their applications with systems update service.
Instead they have their own update thingie that checks for updates during runtime.
So if you already know that you have an application with a potential security problem you either have to start it despite the threat or remove it and install an newer version.
How can anyone count this as simple?
Member since:2005-07-02
In many cases, a new major release of a software package fixes bugs and problems in earlier releases. And now you're saying, users shouldn't have easy access to those bugfixed releases?
In many cases, a new release is buggy and unstable. Waiting for the distro to include it in the repository is the reasonable thing to do for 95% of users. The 5% of users who must compulsively use the latest and greatest version can always install it from tarballs. It's not hard, and with utilities such as checkinstall it's pretty safe as well.
The idea that you must absolutely install the latest version of an app comes from the Windows world. Things don't exactly work the same way with open source...
If you look around forums on the Net, one of the most common problems Linux newcomers grumble about is software installation.
Not really. The most common thing Linux newcomers grumble about is lack of native drivers for their hardware, or the fact that they are proprietary drivers that require special procedures to install. In other words, they indirectly complain about the fact that such drivers are not available as packages, since that means that they could be installed automatically during system installation. Autopackage (while a good idea) would not solve this.
Programs like Autopackage and other similar installers are useful for commercial software, because that provides cross-platform packages for ISVs. For most system and open-source software, however, the repository system works just fine. I use it every day and I don't feel slighted by it at all. I really do think you're exaggerating the problem here.
Member since:---
"Waiting for the distro to include it in the repository is the reasonable thing to do for 95% of users"
What, even waiting up to six months? Or a year? Most distros only include security-fixed packages in their archives, so unless you risk your whole system by switching to an 'unstable' repository you have to wait for a whole new distro release several months down the line -- upgrading everything else too, which you may not want to do. Or go through the trials of compiling from source.
Do you realise what you're saying here? There are many, many operating systems that have orderly and clean packaging solutions, so that users can get new programs as and when they want. But all this waiting and distro-upgrading is somehow a 'feature' for Linux, when it's seen as vastly backward to other OSes?
Please, go use a Mac for six months. Or RISC OS. Or BeOS. Or even Windows. Then come back and see that this distro-specific-repository-waiting-or-source charade is comically bad.
Member since:2005-07-02
What, even waiting up to six months? Or a year?
You obviously haven't heard of backports. This means I can get up-to-date packages without switching to an unstable distro.
Please educate yourself a little bit more before trolling.
Oh, and I use Windows every single day. I have done so for 15 years. So please STFU.
Member since:2005-08-19
Installing Autopackage software is like Russian Roulette. No way on earth that an Autopackage binary blob can play nicely with each and every intricacy of all the GNU/Linux based OSes out there.
It would work if distributors collaborated with the Autopackage developers. What would not work is having the Autopackage developers trying to guess at the intricacies of many distributions.
I trust on the software management by the distribution.
That promotes duplicated effort and stifles creativity. It's harder to create a new distribution when you have to set up your own repository. Even if you counter this point by saying that a new distribution could be based off an existing one, that existing one is still duplicating effort; therefore, the derived distributions' package selections are constrained. Distributors ought to be specifying distribution-specific details, not repeating the entire packaging process.
Plus, I really, really, really hate the idea of having to trawl the net and download each and every piece of software I want to use and then afterward have to click each and every piece after I've downloaded them and then having to answer the same stupid questions over and over again. Click -> next -> next -> next times 1,000,000.
Repository-based and (graphic) package-manager accessible software is superior to any installshield solution.
I agree wholeheartedly. Remember that this is a separate issue from Autopackage; there is no reason why we couldn't have one distribution-neutral Autopackage repository. This would also make it easier for new software to be published, particularly so if the developer is new to Linux.
Member since:2005-07-07
It would work if distributors collaborated with the Autopackage developers.
What kind of collaboration would you like to see?
Auopackage didn't make themselves a lot of friends when they decided to treat all distributions as "broken" and to deliberately risk breaking the system.
Bad first impressions take a long time to overcome
Member since:2005-08-19
What kind of collaboration would you like to see?
Cherry flavored, please.
Seriously, collaboration on Autopackage would involve the two kinds of developers coming together to create a feature set that is flexible enough to allow software to be packaged once for all distributions. I thought this meaning was rather obvious given the rest of my post.
Perhaps you just wanted a hook into the conversation? ;-)
Auopackage didn't make themselves a lot of friends when they decided to treat all distributions as "broken" and to deliberately risk breaking the system.
From the viewpoint of someone who develops solutions for problems with existing systems, those existing systems are going to appear broken, so people who come up with new ideas tend to irritate those using the old ones. If what you say is correct, then people just need to get their egos out of the way so that they can start improving distribution methods.
I have no idea what you mean by "to deliberately risk breaking the system."
Member since:2005-07-07
Cherry flavored, please.
Hehe 
I thought this meaning was rather obvious given the rest of my post.
Yes, what I meant is which kind of work/contribution would be considered collaboration.
Since autopackage is designed to worked on different distributions, I have no idea how a distribution developer could help.
Did you mean installing the autopackage package by default?
From the viewpoint of someone who develops solutions for problems with existing systems, those existing systems are going to appear broken
I was referring to the /usr/local problem. Seems some weird distribution didn't have it in their PATH setup.
Not sure which one, but obviously all that do were treated likewise.
I have no idea what you mean by "to deliberately risk breaking the system.
Installing into the directories controlled by the package manager (/usr) without notifying it about changes.
/usr/local or /opt are there for a reason.
There are all sorts of excuses for that, but it is still a bad default.
Distribution developers spend their time to ensure stability for their users and of course anyone who just walks over them isn't going to be liked a lot.
Even if autopackage changes this in a later version, which I think is going to happen, their bad initial choice will still be in the heads of a lot of people.
Member since:
---
Member since:
2005-07-12
As much as I see a need for better standards in linux distributions, something I feel unnecessary is the push for a single package format (that is, RPM).
Why cannot applications be distributed as a binary tarball, which can be extracted to a directory and run. "Installing" simply consists of copying the directory to /usr/local, and uninstalling would simply involve deleting it.
RPM's, DEB's and other dependancy package managers are great for managing the software which is supported and provided by the distribution, but I don't see the point of having third party applications provided in these formats.
Member since:
---
If we followed the same reasoning with our automobiles, we would all be driving generic no-name 4 door ford taurus's. If I couldn't tell the difference between a ford and a toyota, I would lose satisfaction in car ownership. I love my PTCruiser but my neighbor likes his minivan just as much. And Billy, down the street, despises his Accord. Who's right?
Linspire, Xandros are already creating their own 'standard desktop's. I don't particularly like them, but they do provide a 'standard' for their customers. They are providing the structure and security some clients need. More power to them.
If Linspire had 40% of market share, we wouldn't be discussing desktop standards, we would be full of suggestions for a disparate approach.
Frustration with package management is real, but let Redhat take care of Redhat and let Xandros take care of Xandros. We are free to contribute to both and others, but gosh we need variety. The differences foster innovation, but standards foster complacency. The day that Slackware and Fedora look eactly the same, is the day I will find something else.
Member since:2005-06-29
If we followed the same reasoning with our automobiles, we would all be driving generic no-name 4 door ford taurus's.
Which in a sense, we do. All cars have the exact same layout, they work the exact same way, they have the gas pedal in the same place, the gear stick (automatic is for women, semi-automatic for playboys) in the same place, the doorknobs, the whole nine yards (except for TVR which insists on placing everything exactly there where you don't expect them, have fun trying to open the door on a TVR 
).
Your comparison is more akin to having a different theme on your desktop than to having different toolkits and package managers.
Member since:---
I agree with Thom. And I'll also add, yes, competition is good. But can we have competition between OSes please? There'd be nothing wrong with having Linux, Syllable, Haiku etc. all battling it out to make the best desktop OS, cross-polinating ideas and bringing new innovations.
But 600 Linux distros, with an incalculable number of frustrating little quirks and differences, making it hard to move software or configuration skills from one machine to another, doesn't help anyone.
Member since:2005-07-06
Which in a sense, we do. All cars have the exact same layout, they work the exact same way, they have the gas pedal in the same place, the gear stick (automatic is for women, semi-automatic for playboys) in the same place, the doorknobs, the whole nine yards (except for TVR which insists on placing everything exactly there where you don't expect them
You're talking about physical objects there. In the software world standards are effectively setting the laws of physics, in many ways, skewed to the advantage of a handful of people and companies.
Software is a whole different kettle of fish.
Member since:
2005-07-06
Member since:2005-07-28
I didn't find anything on the wiki but I foubd this:
http://www.linuxbase.org/futures/candidates/Qt/
Where it shows that the status of Qt is Blocked.
Member since:2005-07-09
Where are you looking?
This page:
http://www.linuxbase.org/futures/candidates/Qt/
indicates that Qt is blocked.
Member since:2005-07-06
http://www.linuxbase.org/LSBWiki/DesktopWG
"LibQt libraries: LSB WG and FSG are considering the licensing criteria update proposal. Pending that ratification and trolltech schedule alignment, libQt will be standardized as a part of LSB desktop first release."
Member since:2005-07-28
Member since:2005-07-06
The Desktop working group has already accepted the reasoning, and a new licence criteria was already drafted:
http://www.linuxbase.org/LSBWiki/LicenseCriteria
There is currently a lot of work around Qt, and it would be very unfair not to include it after that.
Member since:---
[i][4] "Almost no strings attached." On occasion, licenses with reasonable restrictions may be considered, e.g., a number of ABIs in the LSB have conforming component implementations licensed under the LGPL. The LGPL has requirements of which you must be aware if you intend to ship a proprietary work. In particular, you cannot ship your work with an End-User License Agreement (EULA) that forbids reverse engineering. The LSB intends to make development easier, but you must still invest effort to ensure you understand the licenses of the components you select.[i]
Will this mean I will be able to use Qt w/o the annoying GPL issue to my customers?
So the "End Work" will be GPL free?
I
Member since:2005-07-06
Dear Anonymous (IP: 201.145.141.---):
You are so confused I don't even know how to start. This point has nothing to do with GPL.
It points out that even a LGPL licensed library needs to be carefuly evaluated by the legal department before used. It is not a "no strings attached" license: you have to allow reverse egineering. Some companies may prefer to pay a developer licence to Trolltech and keep the reverse engineering restriction, than allow it, especially it they are writing a simple linux front end.
Member since:2005-07-28
Member since:2005-07-07
Member since:2005-07-06
Member since:2005-07-28
Member since:
---
Software installation under Linux is fiendishly messy, and projects like Autopackage could solve it -- with you STILL having your repositories if you wanted them.
That's nice, but who's going to create the Autopackage files? As a developer, it's not my problem. I'm only concerned with getting the source tarball out. What you want to do with it beyond that is your problem.
You want the distro to make the Autopackage file? Why would they do that when they already have a system set up that works? Besides, you wouldn't get it any faster than the already established means that distro has developed.
Autopackage solves nothing. It just makes devs do more work that takes time away from the real work they want to get done. If you want bleeding edge, use Gentoo.
Member since:
---
Well it's a nice idea but if the views here are representative it has about as much chance as a snowball in the Sahara. To paraphrase a Red Hat spokesman, "They'll be crying 'Choice' all the way to the bargain bin at Comp USA."
Another angle to consider is that eventually one of the larger distros will take matters into their own hands, announce the standards they will follow and in effect fork Linux (fully so, if they decided to tackle the kernel as well). Some folks might put up their hands in horror, but if the distro managed to get just a couple of big ticket items on board - open office, Adobe ports perhaps, apache or whatever - they would have every chance of doing well. Apple have already done something not that dissimilar, after all, and no one complains because Mac OS doesn't major on KDE or apt-get.
In many ways this might be better than the present morass, which is slowly getting worse as Linux gets more complex. The prospect of an "OS Lite" from Sun/Google could be quite tempting as a way of avoiding the f/oss standards swamp. Different standards is basically just a euphemism for "incompatible".
Member since:
---
They could solve a good deal of the current situation by moving to a single desktop. Supporting Gnome and KDE might offer choice, but the downside is huge.
But not as huge as the upside of being able to choose a kit that works best for what you want to do.
Making one desktop the "standard" is a bad idea. Creating common standards by which the different desktops / toolkits can interact with each other is what needs to be done. (Actually it's been something that has been happening for quite some time now. Perhaps you've heard of freedesktop.org?)
Member since:
2005-07-06
Member since:
2005-07-06
LSB should not pick favorites. It is a standard to make the deployment of Linux apps easy. And there is plenty of Qt/KDE linux apps, commercial and free. Nobody is forced to use Qt: GTK will be there too.
Therefore, the inclusion of Qt is logical. And competition is good: the desktop battle will be fought on the merits and qualities of the desktops, not by trying to exclude the opponent, making both desktops better in the process.
Member since:
---
Member since:
2005-06-29
http://www.linuxbase.org/futures/ideas/issues/libqt/
It all comes down to "no strings attached" and there are strings attached with Qt.
Trolltech should have been bought out a long time ago.
Hey Segedunum, so now that some major players are backing this does it count? Hehe, or I guess your new line is "Unix has tried this before".
It was inevitable that the Qt license was going to come back to haunt some people.
Member since:2005-07-06
Hey Segedunum, so now that some major players are backing this does it count?
ROTFL.
Yer, these people are all major players. In fact, most of them are the people that lost the last time around.
It was inevitable that the Qt license was going to come back to haunt some people.
Ahhh. I go away for a nice pint, come back, peruse the internet for a bit and lo and behold - over a hundred comments about making pieces of shit like GTK and Gnome standards.
If it's crap unreliable software, people ain't using it. Users and businesses do not pick software based on favourable licenses, no matter how much the technology and license wankers like Lumbergh jerk. General rule of thumb there explained many times before, but we have quite a few goldfish round here. I'm amazed you found your way back onto the internet.
RE[2]: Why Qt won't be included
Member since:---
So much bitterness Sege.
Errr, no. I've never been here for most of this useless ranting with people wanking over perceived big player support again.
Not surprised though. I love how your story has changed from "it doesn't matter" to "Unix tried this before". Nice one.
Errr, no.
But you might be right that it doesn't matter. It's not like the Linux desktop is going anywhere anyway.
Why bother then?
I love how you throw a tantrum anytime the Qt license topic comes up. It's amusing.
So what were the last seventy odd comments about then?
Member since:
---
Business companies all over the planet have decided to standardize on Linux. The open source crowd wrote the licenses, they will now have to deal with the consequences.
Almost every major piece of software I run on Linux is the result of corporate business involvement. It is the only reason Linux is a viable desktop system today. After years of 0.1alpha software littering the Linux world, big business has come in and is turning Linux as a Project into Linux as a Product.
Corporations are taking over Linux and finally whipping it into shape and there is nothing the open source crowd can do about it now. They wrote the licences, the code is out there. The amount of money to be saved for companies to standardize on a free and open system is so great that nothing the open source crowd will try to do to stop it will have any effect.
What some bearded GNU freak still running Slackware has to say about the matter will be of no consequence.
Member since:2005-06-29
Nobody can co-opt anything on linux because it's open source. But I'll grant you that corporations like RedHat, Novell, Suse, and even Trolltech have pumped resources into the desktop that wouldn't have been there. On the flip side, corporate involvement could hinder development too. If it ever came to be that some RedHat marketing guy started playing puppet master on the RedHat gtk+/Gnome guys then that could be problematic.
But this whole thing is not about choice or freedom because you can't take that away with open source. It's all about standards and making the desktop more palatable for ISVs to target.
Frankly, I think it's too little too late. I'll run KDE as my desktop and a bunch of gtk apps with it, but I don't think either desktop is really that important compared to Mozilla and its derivatives.
Member since:
2005-07-06
First of, Lumbergh had you bothered to read some of the other replies you would have known that libQt will be standardized as a part of LSB desktop first release. So you have to find another approach for your FUD.
And the link you provided as proof was rather telling, it gives me a 404 Not Found. Nice way to tell us all that you are wrong.
Besides you are rather confused with the "no strings attached" argument of yours, as it's the LGPL that has strings attached. Qt on the other hand has a no strings attached license.
Member since:2005-06-29
Member since:2005-07-06
Show some evidence.
Here is some evidence: Qt has been discussed for inclusion in the last 3 months in the LSB desktop meetings / conference calls. Here is the agenda for the next one:
http://mail.freestandards.org/pipermail/lsb-desktop/2005-October/00...
Member since:2005-06-29
Here is some evidence: Qt has been discussed for inclusion in the last 3 months in the LSB desktop meetings / conference calls. Here is the agenda for the next one:
http://mail.freestandards.org/pipermail/lsb-desktop/2005-October/00...
I wouldn't call a conference call evidence. I'll wait to see an official announcement. The only way I can see Qt being included if FSF makes an exception by breaking their own criteria.
Member since:2005-07-06
I wouldn't call a conference call evidence. I'll wait to see an official announcement. The only way I can see Qt being included if FSF makes an exception by breaking their own criteria.
They won't break the criteria: they will modify it.
See:
http://www.linuxbase.org/LSBWiki/LicenseCriteria
If you will only believe in the process after it is completed, than there is no argument I can give you. The process is not finished yet.
RE[6]: Why Qt won't be included
Member since:---
"And here is how Qt relates to the criteria
http://www.linuxbase.org/futures/candidates/Qt/index.html#license"
And thats bullshit. Qt is licensed under terms of GPL AND QPL.
Member since:2005-06-29
Besides you are rather confused with the "no strings attached" argument of yours, as it's the LGPL that has strings attached. Qt on the other hand has a no strings attached license.
There's some trolling FUD. You better tell the FSG about your "theory" on how LGPL has strings attached, but the Qt license doesn't.
Member since:2005-07-06
Member since:2005-06-29
Member since:2005-07-06
And exactly what license can't you use with independent modules linked to gtk+?
If you link to a LGPL library, you can't restrict modifications to the binary file, or reverse engineering for that matter. Most proprietary licenses do restrict that, and therefore cannot be used with LGPL. See sections 5 and 6 of the LGPL.
http://www.fsf.org/licensing/licenses/lgpl.html
Please note that I am *not* saying that the LGPL restricts proprietary licenses in general. It does not. But the developer has to choose between these restrictions and using GTK. Googling for EULA, I found out that restricting modification of binaries and reverse engineering is pretty standard:
* http://www.macromedia.com/software/eula/tools/
* http://www.guildwars.com/legal/user-agreement.html
* http://www.worldofwarcraft.com/legal/eula.html
* http://www.nero.com/en/EULA.html
* http://www.adobe.com/products/acrobat/acrreula.html
* http://www.microsoft.com/windowsxp/pro/eula.mspx
Member since:2005-06-29
You can diassemble any binary. A EULA license isn't going to stop that. All that matters is the source, but you know that already.
So until the FSF changes their criteria by making an exception for Qt, a wiki page (that's a joke) and a random email about a conference call is meaningless.
Member since:2005-07-06
Besides you are rather confused with the "no strings attached" argument of yours, as it's the LGPL that has strings attached. Qt on the other hand has a no strings attached license.
Actually, you're the one who is rather confused. The LGPL attaches no "strings" to the user of an LGPL-library (yes I've read sections 5 and 6 of the license in question). Qt on the other hand has license strings attached to the usage of GPL-Qt and monetary strings for the other method of licensing.
Member since:
2005-07-06
Hey - why should we complain about such a group working to promote Linux for application development if....
1) Adbobe would grant pantent-free* access to color management system (pantone etc.) for FOSS systems to enable seemless color management in Linux/X. And Macromedia opening up their code for first class FOSS implementations....
2) Intel would provide patent-free* access to all current acpi/apci/wireless subsystems implemented by various manufactures using Intels chipsets. And providing patent-free* open source drivers for *all* intel products in use in FOSS systems-including high quality mmx/sse/sse2 code optimization algorithms to gcc.
3) RealNetworks donating patent-free* media codecs and allowing them to be seamlessly integrated into various FOSS media projects(gstreamer, xine, mplayer etc.) Along with the transport protocols in use on their servers.
4) IBM donating their implementation of the Java virtual machine bootstrapping the harmony project.
5) And HP releasing patent-free* open source drivers for *all* of their products for use in FOSS systems so that we as consumers of HP products can fully utilize the hardware we purchase...
If they really want to help Linux become more palatable for the consumer application market their is soooo much they could do 
* perhaps in the form of a large scale patent donation-ie. granting FOSS projects exemption from patent claims....
Member since:
2005-07-06
You can diassemble any binary. A EULA license isn't going to stop that. All that matters is the source, but you know that already.
It's not about what a EULA can stop or not. It's about what they can write in the EULA, whitout getting sued or getting cease and desist letters. If they try to pull the non reverse engineering clause in app using LGPL they it's very likely they will have legal problems.
So until the FSF changes their criteria by making an exception for Qt, a wiki page (that's a joke) and a random email about a conference call is meaningless.
I guess that was a typo, as FSF has nothing to do with this. It's the FSG. But the thing is, they are actively working on including Qt. They are clarifying their own criteria and removing the wrong interpretations of both it and the Qt licenses they have had. It's rather a matter of clearer heads realizing that any desktop standardization without Qt, would become irrelevant.
Member since:2005-06-29
