| |||||||||||||
|
| |||||||||||||
Will LSB 4 Standardize Linux? (InternetNews)Will LSB 4 Standardize Linux? (InternetNews)Posted Jul 31, 2008 22:55 UTC (Thu) by JoeBuck (subscriber, #2330)Parent article: Will LSB 4 Standardize Linux? (InternetNews) The answer is "probably not". If LSB4 is a large enough subset of current distros, then it might help with portability, but it's not possible to test whether an app works on "LSB4". It still has to be tested on specific machines, running specific distributions. An ISV might test on Red Hat and Novell, and the app might happen to work on other distros, or maybe not. ISVs are not going to promise that they run on any LSB4-compliant system.
(Log in to post comments)
Will LSB 4 Standardize Linux? (InternetNews) Posted Jul 31, 2008 23:35 UTC (Thu) by elanthis (subscriber, #6227) [Link] That makes little sense. Distros can be certified LSB4 compliant, and they can offer meta-packages to pull in any libraries necessary for LSB4 compliance if they are not in the default install.
Will LSB 4 Standardize Linux? (InternetNews) Posted Aug 1, 2008 0:19 UTC (Fri) by derekp (guest, #53203) [Link] What the poster above was referring to is that if you develop your app on say RHEL, just because RHEL is LSB compliant doesn't mean that your app won't accidentally rely on non-LSB components also included in the base OS. So your app may not work on other LSB-compliant systems (because your app isn't a "pure" LSB app). The solution to this is to set up a directory structure that contains _only_ LSB components, then chroot into that directory and test your app. If there are no problems, then it should run on any other LSB-compliant OS.
Will LSB 4 Standardize Linux? (InternetNews) Posted Aug 1, 2008 0:31 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] Or there could be a specific bug that would prevent distro Foo from running your app even though your app validly uses LSB4 and Foo passed LSB4 certification, because testing is always incomplete.The best the ISV can do is to say is "try it, it might work, if it doesn't you'll have to use a supported distro".
Will LSB 4 Standardize Linux? (InternetNews) Posted Aug 1, 2008 6:42 UTC (Fri) by k8to (subscriber, #15413) [Link] I disagree, an ISV *could* do better. They can say "we support the LSB4 platform". And they can investigate all bugs which come to light running on the LSB4 platform, and determine whose side of the fence such problems are on and resolve them. Some bugs will be on the distro side, and then it will be up to the distro to support the platform. Really it would be ideal if you could actually get both parties interested in such bugs. You may be right that vendors will not go down this path, but there's no reason they can't do so. The issues you have to worry about are significantly curtailed if you target LSB. However the catch is that LSB is a pretty limited platform, or was. I haven't checked lately.
Better tooling and IDE support Posted Aug 1, 2008 16:07 UTC (Fri) by salimma (subscriber, #34460) [Link] This sounds like an integration problem: compared to, say, OS X development, where the Xcode IDE let you target any of the last three OS X releases, Linux IDEs are not configured to target any LSB versions. Ideally, you should be able to deploy to a chroot-ed environment as part of the build process too. There's still the library mess if your application depends on libraries that are not part of the LSB standard, though.. Makes me think that adopting the Acorn RISC / OpenStep / OS X concept of application and framework bundles would be a neat idea, as far as binary proprietary applications go: the application is just a bundle (a directory), within which there is a predefined place for bundling self-contained frameworks (libraries) that are in turn bundles themselves.
Application bundles? Puhlease. Posted Aug 1, 2008 17:46 UTC (Fri) by khim (subscriber, #9252) [Link] If you ever worked with these "magic" bundles you'll know they work just fine if we are talking about small self-contained applications (like Firefox or Skype) - exactly where trivial solution (.tar.lzma) already exist - but easily break apart if we are starting to talk about big integrated packages like MS Office/Acrobat (not reader). Then you have the whole non-standard scripts, arcane installation commands and so on. Sorry. This is non-solution for non-problem. 0install is slightly better - but not by much: basically it's huge distribution without any control with ability to run software from thousand of repositories. All existing systems are totally, utterly useless because they are addressing easiest 90% of the problem while leaving really problematic 10% untouched. Result: complex system which offers no significant additional value over simple tarball.
Application bundles? Puhlease. Posted Aug 2, 2008 20:18 UTC (Sat) by salimma (subscriber, #34460) [Link] The advantage of bundles is that it contains more metadata than a simple tarball. Compatibility problems might arise, but at least the application launcher could provide more meaningful feedback to the user. Or even integrate with the OS' version control system, especially now that Linux has PackageKit, to say "hey, the user wants to run this new bundle that needs libfoo-x.y, install whatever package is necessary to provide that". You'd need a package management system that automatically scans built packages for what libraries they provide; RPM does that, not sure whether DPKG does.
Application bundles? Puhlease. Posted Aug 2, 2008 20:51 UTC (Sat) by salimma (subscriber, #34460) [Link] I elaborated the point on my blog. To summarize, a bundle allows for better integration with the native package management system. It provides a more user-friendly experience too -- drag and drop your applications and libraries. I forgot to argue that in the blog entry.
And who can use this metadata? Posted Aug 3, 2008 13:20 UTC (Sun) by khim (subscriber, #9252) [Link] The advantage of bundles is that it contains more metadata than a simple tarball. So what? README.txt/INSTALL.txt written in English is quite good for human and it's impossible to use metadata till there are no organization which resolves conflicts, give canonical names for libraries, etc. It's easy to request "convert" binary - but then your application will fail due to difference between ImageMagick and GraphicMagick flags. It's easy to request QT 3.3.x but then your application can not start since ABI was changed when immodule-qt was used. And if you need to just start your own background service - you still need to supply bunch of scripts for different distributions. Libraries and binaries (which is currect focus of all these systems) are easy, almost trivial: HDD space is cheap so just bundle all libraries with your package. Easily doable with tarball. And the hard stuff (do you need to talk with esd? with arts? or use PulseAudio daemon?) is not solved by current generation of bundle systems. Note: I've not said that bundles can never ever work. Who knows? Perhaps sometime in the future... when all will ditch this obsolete Linux and switch to great new HURD... but not today. So far all tries failed miserably. They are either work for limited usecases (0install is example here) or threaten to kill the host system altogether (autopackage and friends).
Wrong goal Posted Aug 1, 2008 1:43 UTC (Fri) by ncm (subscriber, #165) [Link] This isn't meant to help users directly. As Joe notes, no software vendor will claim to run on any old LSB4-certified system. However, ISVs who code to LSB4 -- i.e., rely only on what's documented to be present in LSB4 -- will find porting to any LSB4 system will be easier than what they have to do now. Typically, now, they have to build release packages on some ancient version of Red Hat, and then rely on forward link compatibility to run on new Red Hats, and everywhere else too. With any luck this means they can rely on newer OS features than they previously had access to. E.g. does LSB have futex? If this works out, users will benefit by having a wider and possibly more modern choice of targets certified by the ISVs, because it will be cheaper for the ISVs to port and certify. ISVs benefit by being able to sell into shops that run distros they hadn't previously been able to afford to support. Anyway that's the theory.
Wrong goal Posted Aug 1, 2008 3:18 UTC (Fri) by jwb (guest, #15467) [Link] That could happen, but what's more likely is that vendor-distributed binary software packages for Linux will continue to be garbage regardless of the LSB. It's easy to laugh at random sourceforge projects, but you haven't really experienced the extremes of software failure if you've never tried to download and install Oracle or DB2 or even Eclipse for that matter.
|
|
||||||||||||