Ubuntu's multisearch surprise

And then you'll need it to be able to upgrade itself, track dependencies, uninstall, etc.

In short, you need a PACKAGE system. So back to square 1.

LSB works for some things, but obviously it's limited in scope.

Different standards organizations work in different manners. For example Freedesktop.org has it's XDG stuff which is 'next gen' (when it was developed). This has added considerably in helping users experience consistent behavior and addressing many of the annoyances that come from having different desktop environments.

A big example is previous to things like "xdg-open" application developers that wanted to call a seperate browser for documentation or linking online had to hardcode it into their installation scripts or in their applications. The best they could do was to allow people to go into their application preferences and set a default browser. Most people just hardcoded 'mozilla' since that was the premiere browser at the time.

Obviously this is less then preferable. Either forcing everybody to use 'mozilla' or forcing everybody to configure a browser for each and every application that happened to need to call a browser.

LSB is a bit different though. They are a 'best practices' type orginization that goes and finds what is consistent and supportable across all distros and then formalizes it. The amount of stuff that LSB tries to impose on distros is relatively small and distros tend to respond very negatively when they do (like standardizing packages to be RPMs and forcing some new directory structure).

So they don't assume a position of making people work together. Their position is much more centered aorund documenting and making formal in what ways they already do that. So that when you have third party developers (ISVs) or you have people new to Linux then they have a place to go to learn what parts of "Linux OS" they can depend on.

So things that cause incompatibility and problems for developers who try to target multiple distros that LSB doesn't cover should be mostly because distros refuse to work together about those things. It's not LSB's position to try to force those sort of issues.

Traditionally the biggest problem is going to be because of GUI applications. The 'GNU' part in 'GNU/Linux' is very consistant normally, but the differences in how people setup KDE vs Gnome vs Whatever causes all sorts of headaches.

------------------

The latest thing that LSB is trying to deal with is the GUI applications through the Moblinv2 specifications developed by Intel.

This is only targeting smaller devices, but I am hoping that it will extend to desktops and workstations.

Moblin dictates that you need to have a Gnome-based environment and that you have all the dependencies that it says you should have for it. It includes specific libraries and specific versions of libraries. It also assumes that if you have newer then the specified libraries then those libraries should be backwards compatible with the versions that it dictates. It has bunches of PDFs outlining all of this, plus test cases and a certification process.

So far it seems that Novell, Ubuntu, and Fedora are releasing Moblin compliant versions of their operating distros, as well as smaller custom-commercial companies like Xandros.

--------------

the main problem with Moblinv2 is that it's more for smaller devices, but I am hoping that it'll be move 'up' and include desktops and workstations. It's heavily influencing the direction of Gnome 3.0 I believe.

The other big problem is that it's very Gnome centric and thus KDE fans and people who care about older and slower devices will have a tendency to dismiss it early on.

My thoughts on this goes like this:

Gnome stuff, while heavy in nature when running, does not really take up that much disk space. Thus the price you pay for Moblin compatibility is rather low. Even old computers should be handle the additional disk space required without blinking.

And what gets you is a solid and constant base for users to build off of.

----------------------------

I learned this when dealing with OpenLDAP.

People have, in the past, had huge issues learning LDAP with OpenLDAP. There is a wealth of documentation and examples on LDAP, but very little actually covers the initial setup and deployment of OpenLDAP. When you install OpenLDAP from Debian and Fedora it's built correctly, but it's a blank canvas...

So users will read the documentation and want to experiment with OpenLDAP, but the initial setup to get a actual working example is a very high barrier and they get confused and dismayed and usually give up.

So if they were given a nice default setup, even if it wasn't what they needed ultimately then it makes things MUCH easier to learn and deploy and would increase the value of the software by a large amount.

This is the advantage that companies get with Microsoft Small Business Server setup. Everything is designed to work together by default. Even if SBS is not a good match for the company initially then having a consistent and working basis (as well as documentation) is invaluable to build off of and modify so that it does end up being a good match.

------------------------

Linux desktops and desktop application development is not like that. There is no solid basis, no solid and constant foundation.

It's like walking on shifting sand... everything is moving around under your feet. People get the feeling that they are building a house on wet clay... no matter how well and how strong you build your house if the foundations are not done correctly and are not consistent then your screwed. The more you effort/time/money you spend on it the worse off you are.

If users and developers are presented with a solid, working Desktop, that has all the basic features and services done correctly and is working then that makes using and customizing the desktop much easier. Even if 'Moblin' or 'Gnome' is not what they want, having that solid working base to fall back to and build off of makes things much much easier.

What is the fun in getting Awesome WM configured and all EXCELLENT if you have to struggle around with Pulseaudio or Alsa and need to compile patches in Network-Manager (or uninstall it entirely) to get basic OS features working correctly?

With everything 'working by default', then developers only have to worry about the stuff they care about. They don't have to worry and care about things that they don't want care about and don't have in-depth knowledge about.

--------------------------

'Usable By Default' is along the same lines as 'Secure By Default'.

When a user installs a secure OS like OpenBSD or Debian's 'base install' it has almost no chance of providing what the user wants ultimately. They want a network router or a web server or email server or something like that.

However what it gets you is that you can deploy a HTTP server without having to worry about SNMP security and SMTP security and SMB security and NFS security, etc etc. etc. You only have to concentrate on the stuff you need to concentrate on and you still end up with a secure system.

---------------------------

Like if I am developing a video game using Blender.. Idon't want to care about sound APIs. I don't want to have to worry if PulseAudio or Alsa or OSS is being used. I don't want to worry about if the users have the ability to connect to wireless networks correctly for playing multiplayer or if they have a decent browser that is compatible with my documentation. I don't want to worry about if their distro has a good MESA implementation or if the user is using proprietary drivers or if the user does not know that they need drivers installed at all. I don't want to care if they have the ability to full-fill the python requirements or have goofed up python libraries all the time.

If I have to worry and deal with every little detail with the desktop and have to provide work-arounds and documentation and support for every little thing that can screw my game up... then I won't have any time to make the actual game!

I think you are paying far too little attention to systems integration. Anyone can package individual packages, but a bunch of independently packaged software does not a good distribution make.

By far the most impressive bit of Debian is the Technical policy manual, and how the packages create a more integrated whole by following the dictum of policy (which, BTW, is not a statid dead set of rules, but a vibrant, breathing, changing document). Very few upstream packaged software pays much attention to it, as can be seen by running lintian -vi on the packages produced.

manoj

That is more a consequence of problems in the *nix linking model, where all shared objects land in a global namespace. It is desirable for a few things like the C library, but for most shared objects it causes more problems than it solves. It would be so nice if build-time linking had the equivalent of dlopen's RTLD_LOCAL flag. I think this should even work without breaking LD_PRELOAD, as preloaded libraries would still be loaded as "RTLD_GLOBAL" libraries, so would still override the subsequent RTLD_LOCAL loaded ones.