Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux Foundation Promises LSB4

ScuttleMonkey posted more than 6 years ago | from the making-it-easier-to-like-us dept.

Software 194

gbjbaanb writes "Ever thought it was difficult to write software for Linux? For multiple distros? InternetNews reports that the LSB is making a push for their next release (due out later this year) that should help make all that much easier. Although the LSB has not lived up to expectations, this time around Linux has a higher profile and ISVs are more interested. This is to help persuade them to develop applications that will run on any LSB-compliant Linux distribution. If it gets adopted, LSB 4 could bring a new wave of multidistribution Linux application development. 'It is critically important for Linux to have an easy way for software developers to write to distro "N," whether it's Red Hat, Ubuntu or Novell,' [said Jim Zemlin, executive director of the Linux Foundation.] 'The reason you need that is because we don't want what happened to Unix to happen to Linux in terms of fragmentation.' The LSB defines a core set of APIs and libraries, so ISVs can develop and port applications that will work on LSB-certified Linux distributions."

cancel ×

194 comments

Sorry! There are no comments related to the filter you selected.

first post (-1, Troll)

Anonymous Coward | more than 6 years ago | (#24437165)

got goat?

AC Foundation Promises FP 4U (-1, Troll)

Anonymous Coward | more than 6 years ago | (#24437205)

First
my bitches
enjoy

What is LSB, you ask? (4, Informative)

RandoX (828285) | more than 6 years ago | (#24437207)

The Linux Standard Base, or LSB, is a joint project by several Linux distributions under the organizational structure of the Linux Foundation to standardize the internal structure of Linux-based operating systems. The LSB is based on the POSIX specification, the Single UNIX Specification, and several other open standards, but extends them in certain areas.

http://en.wikipedia.org/wiki/Linux_Standard_Base [wikipedia.org]

Re:What is LSB, you ask? (0, Troll)

Smidge207 (1278042) | more than 6 years ago | (#24437415)

RandoX, my dear, my sweet, my love, you sound like a nice boy...but from your above comments I'd say you're about as sharp as a sack of wet mice.

/I bid you good day, sir.

=Smidge=

POSIX...? (1, Interesting)

Anonymous Coward | more than 6 years ago | (#24437471)

I was under the impression that Linux was based on the POSIX spec from the get go.

Re:POSIX...? (1)

Hairy Heron (1296923) | more than 6 years ago | (#24437587)

It certainly was.

Re:POSIX...? (5, Informative)

larry bagina (561269) | more than 6 years ago | (#24437681)

POSIX has multiple components -- kernel APIs, command line utilities, shell scripting, libraries, etc -- so there's more too it than just the linux kernel.

Re:What is LSB, you ask? (2, Insightful)

Anonymous Coward | more than 6 years ago | (#24438005)

Thank you. fscking acronyms... If you're gonna use them, at least define them once up front, kinda like a variable. If I see one more article using SMB or SMS without hinting at which of the numerous meanings they mean, I'll puke.

The difficulty depends on what tools you use (1, Interesting)

pembo13 (770295) | more than 6 years ago | (#24437267)

Web devs, python devs, etc likely don't find it that difficult.

Re:The difficulty depends on what tools you use (3, Informative)

Splab (574204) | more than 6 years ago | (#24437917)

Wrong.

Any given distro will have to make a choice of what modules each program should support, this means even as a PHP programmer you have no guarantee your software will work with default installation of PHP under a specific distro.

Really? (0)

Anonymous Coward | more than 6 years ago | (#24438033)

#!/bin/python Whoops! Doesn't work on distro Foo!

#!env python
Whoops! env isn't in PATH on distro Bar!

#!/bin/env python
Whoops! env is in /usr/bin/ on distro Baz!

So on and so forth. Which is why the LSB is important to people like Python developers.

Re:Really? (4, Interesting)

TheRaven64 (641858) | more than 6 years ago | (#24438345)

env should always be in /usr/bin. This will work on any POSIX.2-compliant system:

#!/usr/bin/env python

LSB isn't needed, Linux distros just need to implement 16-year-old standards. I think most do put env in the right place, although some also put it in /bin (which should only contain binaries needed to boot the system in single-user mode).

Re:Really? (1)

mrchaotica (681592) | more than 6 years ago | (#24439211)

[S]ome also put it in /bin (which should only contain binaries needed to boot the system in single-user mode).

Perhaps they do that because some boot scripts are written in Python (I'm pretty sure Gentoo is like this)?

Re:Really? (1)

TheRaven64 (641858) | more than 6 years ago | (#24439439)

Boot scripts don't need to be portable, so they can hard-code the path and don't need to use env to find it (and shouldn't, since environment variables won't have been set this early on in the boot process).

Re:Really? (1)

pembo13 (770295) | more than 6 years ago | (#24439407)

Well I wasn't arguing against LSB myself. Just not entirely agreeing with the summary.

Re:Really? (0)

Anonymous Coward | more than 6 years ago | (#24439533)

To be fair, it was a simple contrived example. As someone else has pointed out, LSB also covers things like which version(s) of Python are included and what external modules are available, which is equally important.

Re:The difficulty depends on what tools you use (0)

Anonymous Coward | more than 6 years ago | (#24438323)

"Web devs, python devs, etc likely don't find it that difficult."

If you believe that - try setting up Apache Roller on Ubuntu and configure it as a daemon.

All I can say is, whoever packaged tomcat55 for Debian must have a real hate on for Java web developers.

What did happen to UNIX? (1, Interesting)

chris_mahan (256577) | more than 6 years ago | (#24437311)

"The reason you need that is because we don't want what happened to Unix to happen to Linux in terms of fragmentation."

What makes you think what happened to UNIX was bad? It's called evolution. Things change. If UNIX was all that, it would still be at the top of the food chain. It ain't. It couldn't perform.

Now, "UNIX The Philosophy" is alive and well, having transcended its earthly manifestation to become a mindset. It loaded itself into wetware. Pretty goo feat if you ask me.

Ultimately, let the best software win. The rest can go to bit-afterlife.

Re:What did happen to UNIX? (3, Insightful)

dlgeek (1065796) | more than 6 years ago | (#24437403)

UNIX fractured into a large number of incompatible variants including BSD (fractured further into Open/Free/Net BSD), Solaris, IRIX, HP-UX, SCO Unix, etc., etc..

See this graph [wikipedia.org] for more information.

Re:What did happen to UNIX? (3, Informative)

Crispy Critters (226798) | more than 6 years ago | (#24438497)

One piece of this was that simple commands had different names and different options depending on the variety of UNIX. I am talking things like lp vs. lpr, options for ps, and so on. Also, some things were hidden in really weird places (X on Sun is/was under an "openwin" directory, I think). Writing cross-platform scripts is a pain when you first have to test for the OS and then redefine command names, options, and paths accordingly. In theory, under the LSB you always know where commands and libraries are.

Re:What did happen to UNIX? (2, Funny)

XnavxeMiyyep (782119) | more than 6 years ago | (#24439069)

If that's Unix_history-simple.svg (which it is), I'd hate to see Unix_history-complex.svg.

Re:What did happen to UNIX? (2, Informative)

Knuckles (8964) | more than 6 years ago | (#24439199)

If that's Unix_history-simple.svg (which it is), I'd hate to see Unix_history-complex.svg.

Here you go [levenez.com] . Well, not svg.

Mutation !== Evolution (3, Insightful)

Spy der Mann (805235) | more than 6 years ago | (#24437447)

"The reason you need that is because we don't want what happened to Unix to happen to Linux in terms of fragmentation."

What makes you think what happened to UNIX was bad? It's called evolution. Things change.

Let me remind you, my friend, that evolution means SUCCESSFUL ADAPTATION to an environment. What happens when a change (mutation) results in inadaptation? Extinction.

Evolution refers to a species. But in Linux what we have is not a single species, but a genus [wikipedia.org] (a set of different species): Redhat, Debian, etc. "DNA" recombination is impossible in these. The resulting software would be inoperable.

LSB4, hopefully, will be a further step in the evolution of Linux: The convergence to a single species that will be able to share one single configuration.

In other words, yes, change is necessary, but there needs to be a period of stabilization. Just as stable/unstable releases in software. And LSB is providing this stability. LSB is, in fact, evolving.

Re:Mutation !== Evolution (1)

Darkness404 (1287218) | more than 6 years ago | (#24437527)

Ummm... A lot of software works between distros. The main problem is when Debian uses an older version of GTK than Fedora uses, and the RPM/DEB inconsistencies, but alien usually takes care of that. Python works cross-platform as does Java and a whole lot of other languages.

It isn't that hard to write cross-distro programs, what is hard is making sure that the version in Ubuntu is the same version in Fedora, or that Ubuntu has your programs as well as Gentoo.

Re:Mutation != Evolution (2, Funny)

marco.antonio.costa (937534) | more than 6 years ago | (#24438181)

Sorry, but when expressing inequality != is the correct operator.

You're not really a programmer, security, please escort this gentleman to Digg, please. :-)

Re:Mutation != Evolution (1)

creepynut (933825) | more than 6 years ago | (#24438385)

Actually, PHP uses both != / !== and == / === as comparison operators.

== / != checks that the values are "equal" (same value, but not necessarily the same type; ie. 1 == "1" is true)
=== / !== checks that the values are "identical" (same value and data type; ie. 1 === "1" is false)

See http://php.net/operators.comparison [php.net]

Re:Mutation != Evolution (1)

marco.antonio.costa (937534) | more than 6 years ago | (#24438619)

PHP... pheefff... I was talking about manly, virile languages such as Assembly. :P

Don't ruin my wisecrack with facts! :)

Re:Mutation != Evolution (0)

Anonymous Coward | more than 6 years ago | (#24438695)

!= in assembly?
Since when?

Not the same. (1)

khasim (1285) | more than 6 years ago | (#24438417)

Let me remind you, my friend, that evolution means SUCCESSFUL ADAPTATION to an environment. What happens when a change (mutation) results in inadaptation? Extinction.

So far, so good.

Evolution refers to a species. But in Linux what we have is not a single species, but a genus (a set of different species): Redhat, Debian, etc. "DNA" recombination is impossible in these. The resulting software would be inoperable.

Huh? I run "bash" on all kinds of distributions. Not to mention Apache. And Samba. It's trivial to run the same code on different distributions.

LSB4, hopefully, will be a further step in the evolution of Linux: The convergence to a single species that will be able to share one single configuration.

Again, Apache, Samba, bash, etc.

We're already there.

The GPL rocks.

Re:Not the same. (1)

mehemiah (971799) | more than 6 years ago | (#24439451)

let me clarify, Interestingly enough, the BSD varients pritty much qualify as different genus, but linux distros are more like clades, they have compatible dna (kernel source and Binary compatibility ) but perhaps a few prezigotic bariers (where the biological species consept gets rough, dogs and wolves are the same species but do not mate in nature, i guess this is where package managers lie) where BSD variants have source compatibility sometimes but not binary compatibility because the source of their kernels are different, so one exploit might not effect the others (like a plague) but all of linux are subject to the same kernel bugs (like the compiler bug found by the gcc programmer) and related distros are subject to the same exploits (like the Debian ssh) but not all distros (like how we're down to one clade of banana in north america.)

Re:What did happen to UNIX? (5, Insightful)

Haeleth (414428) | more than 6 years ago | (#24437569)

Ultimately, let the best software win. The rest can go to bit-afterlife.

Yes, that's kind of the whole point of the LSB.

Customers choose OSes based on many criteria. One of them is how much of the software they need will run on each platform. Now, this is rarely actually determined by the quality of the platform -- it's mostly a question of which platforms were already popular enough to be targeted. In theory, LSB will make it easier for new Linux-based OSes to run existing software, and will make it easier for ISVs to write software for Linux-based OSes in general.

Those OSes can then compete on more interesting metrics like performance, stability, scalability, price, and quality of support. How is this not a good thing?

Re:What did happen to UNIX? (5, Insightful)

Darkness404 (1287218) | more than 6 years ago | (#24437701)

UNIX fragmentation wasn't caused by anything other than all the proprietary, incompatible licenses. Whenever Sun made an improvement to UNIX, HP couldn't simply adopt it like they can with the GPL. With the GPL, if I take an OSS program and fork it, and change it radically, the original creators of the software can always add my changes back into the main branch. And yes it would be bad, if you had to write a program, say an HTTP server, you had to test it on every Unix imaginable, today, just release the source, package an RPM and a DEB, and it will be ported to the rest soon enough.

Re:What did happen to UNIX? (1)

symbolset (646467) | more than 6 years ago | (#24438311)

Ransom Love happened to Unix.

Re:What did happen to UNIX? (3, Funny)

nawcom (941663) | more than 6 years ago | (#24438449)

What makes you think what happened to UNIX was bad? It's called evolution.

I COMPLETELY DISAGREE WITH YOU! Linux, SunOS, Solaris (Not an evolved SunOS!), BSD, etc were magically created out of... erm.. random bits generated from some pseudo-random generator in DigiGod's image. Proof? DigiBless.com [digibless.com]

</satire>

Jim Zemlin needs to read the GPL. (2, Insightful)

khasim (1285) | more than 6 years ago | (#24437321)

"The reason you need that is because we don't want what happened to Unix to happen to Linux in terms of fragmentation." says Jim Zemlin, executive director of the Linux Foundation.

He needs to read the GPL and understand how it differs from the various PROPRIETARY licenses that caused the *nix fragmentation.

Re:Jim Zemlin needs to read the GPL. (3, Insightful)

Grey_14 (570901) | more than 6 years ago | (#24437495)

maybe you mean something different, but I'm not sure how your statement relates to this issue. Afaik the LSB is about standardizing directory layouts and configuration files, and while sure under the GPL any linux distro CAN be made to follow those guidelines, almost none of them DO, so the difference between nonstandardized linux systems and nonstandardized UNIX systems is a philosophical one and not a practical one.

(Although on Linux it's a fair bit easier to remedy)

It relates to his statement. (3, Interesting)

khasim (1285) | more than 6 years ago | (#24437599)

maybe you mean something different, but I'm not sure how your statement relates to this issue.

It relates to his statement that I quoted.

"The reason you need that is because we don't want what happened to Unix to happen to Linux in terms of fragmentation." says Jim Zemlin, executive director of the Linux Foundation.

That shows how clueless he is regarding the history of *nix.

It was the various PROPRIETARY licenses that caused the fragmentation because an improvement made by HP had to be specifically licensed by Sun to be included in Solaris.

But with the GPL, the improvements made in one fork are available to ALL forks.

Therefore, the fragmentation will not happen because if a feature is worth it, it will be ported to the other forks. Without the need to coordinate licenses with HP or Sun or anyone else.

The GPL rocks.

Re:It relates to his statement. (0)

Anonymous Coward | more than 6 years ago | (#24437693)

Therefore, the fragmentation will not happen because if a feature is worth it, it will be ported to the other forks.

It will be available to the other forks, but not necessarily ported or adopted. Not everyone can agree on what is an improvement. Do you see Debian adopting .rpm any time soon? How about Redhat adopting .deb?

Result: fragmentation

Re:It relates to his statement. (1)

notamisfit (995619) | more than 6 years ago | (#24438205)

If people can't agree as to what is or isn't an improvement in a particular Linux distribution, how is picking several improvements at random and calling them a "standard" going to fix things? The LSB Junir Woodchuck Club has been going on for years about the importance of standardization, and nothing has really changed.

Re:It relates to his statement. (0)

Anonymous Coward | more than 6 years ago | (#24438237)

"How about Redhat adopting .deb?"

Sorry I think I just threw up in my mouth a little.

Re:It relates to his statement. (1)

renoX (11677) | more than 6 years ago | (#24439449)

>the fragmentation will not happen

will not?? It has already happened! If you have a software which is certified with distribution X, it may or may not run on distribution Y: you have no guarantee, the fragmentation is already here.

Features may be ported, but not necessarily in a compatible way: witness how easily the rpm tools have fragmented recently, ok there is now an effort to reunite them, but this example show that licensing compatibility is by now means sufficient to ensure binary compatibility, which is what LSB is about.

Looks like the GPL haters got some mod points. (-1, Offtopic)

khasim (1285) | more than 6 years ago | (#24437683)

So some people who don't understand the GPL mod'ed me down. Imaging my surprise.

Re:Looks like the GPL haters got some mod points. (3, Informative)

mrsteveman1 (1010381) | more than 6 years ago | (#24437789)

No we understand the GPL, but it has very little to do with the subject, namely that regardless of open vs closed, some distros remain incompatible with each other in small but significant ways.

If there is to be a stable platform to target with Linux, that crap has to stop. Simple being GPL software means very little toward that goal if distros continue to be arbitrarily different and the situation never really resolves itself.

Feel free to build the ULTIMATE distribution then. (1)

khasim (1285) | more than 6 years ago | (#24437915)

If there is to be a stable platform to target with Linux, that crap has to stop. Simple being GPL software means very little toward that goal if distros continue to be arbitrarily different and the situation never really resolves itself.

Sure. You just have to tell everyone what the BEST way is.

No we understand the GPL, but it has very little to do with the subject, namely that regardless of open vs closed, some distros remain incompatible with each other in small but significant ways.

Actually, it has EVERYTHING to do with it.

Each distribution can take whatever path it thinks is BEST and the results will speak for themselves.

If it succeeds, then others can copy the improvements made by it.

It's easy to look backwards and see what you believe to be a straight path of development. But if you look at each point in time, you'll see LOTS of different approaches.

It's impossible to look forward and choose the best path TODAY for development of features that will take 2 years to implement.

Until you can do that, telling distribution X that it is wrong for choosing a path different than distribution Y is beyond silly.

Distribution (4, Interesting)

99BottlesOfBeerInMyF (813746) | more than 6 years ago | (#24437351)

The quote in the summary reads:

'It is critically important for Linux to have an easy way for software developers to write to distro 'N,' whether it's Red Hat, Ubuntu or Novell,"

Personally (as a Linux on the desktop user), I'm a lot more concerned about easily acquiring installing software, than whether it has problems with my distro. For the most part I can get software to run, but it can be a huge pain in the butt. I wish LSB would focus on extending and standardizing package formats and creating advanced standards for package managers to simplify that part of my workflow. I never wonder, "will this run on Ubuntu," so much as "which package format is this in, or how hard is it going to be to compile and update."

Re:Distribution (5, Informative)

dlgeek (1065796) | more than 6 years ago | (#24437487)

You should wonder about will it run.

Debian and Ubuntu use exactly the same packaging format (.deb). Try taking a debian package from a few years back and installing it on your system. Chances are, it won't work due to library incompatibilities.

Now you could probably rebuild it for your system, but depending on what it is, it may or may not work.

When you say "how hard it is going to bed to compile and update"...that's exactly what LSB is working on. It'll be trivially easy to compile a program written against the LSB specs on any LSB compatible distro.

Re:Distribution (1)

Darkness404 (1287218) | more than 6 years ago | (#24437747)

Try taking a debian package from a few years back and installing it on your system. Chances are, it won't work due to library incompatibilities.

No it probably wouldn't, but open source seems to not take too many steps back so it would be easy to just do sudo apt-get install *insert name of the deb package* if it is proprietary though, you are out of luck, but that is one of the (many) problems with non-free software.

Re:Distribution (1)

dlgeek (1065796) | more than 6 years ago | (#24437859)

Doubtful... there are binary incompatibilities between each release of Debian that make it rather difficult to install packages. For example, the C++ ABI bump during sarge's release cycle means you won't be able to install *ANYTHING* written in C++ from pre-sarge on a post-sarge system. Various other library ABI changes will require you to search out old versions of library packages.

Source isn't so bad though.

Re:Distribution (1)

Darkness404 (1287218) | more than 6 years ago | (#24438965)

Yes, but the debian repos usually take care of the packages that can't be installed and replace them with more recent packages.

Re:Distribution (0)

Anonymous Coward | more than 6 years ago | (#24437907)

AutoPackage.org is the solution?

Re:Distribution (1)

dondelelcaro (81997) | more than 6 years ago | (#24438049)

Try taking a debian package from a few years back and installing it on your system. Chances are, it won't work due to library incompatibilities.

If it successfully installs, it should work just fine. The whole point of versioned sonames encoded into library package names is to allow this very thing. Any time an install completes successfully, but the program doesn't work is a bug that needs to be fixed.

Obviously, there are cases where it doesn't su

Re:Distribution (1)

notamisfit (995619) | more than 6 years ago | (#24438255)

The only real issue I've ever had as far as binary incompatibility goes is libc5/glibc issues.

Re:Distribution (1)

maxume (22995) | more than 6 years ago | (#24438283)

I get the feeling that they would be much more successful if they provided a binary runtime platform that commercial-ware could run against. They could even release new versions on a somewhat time based schedule.

Sure, it is ugly as hell to need to download 500 MB every time there are some updates, but it is a different kind of hassle than making sure compilation can happen, and it is a hassle that a lot of people are used to dealing with.

Re:Distribution (1)

myrdos2 (989497) | more than 6 years ago | (#24438415)

I haven't looked at LSB 4, but in LSB 3 you'd make a standard .RPM package and it would supposedly install on any LSB-compliant Linux distribution.

See here for more: http://www.linuxfoundation.org/en/Developers/LSB_Tutorial#Porting_your_code_to_the_LSB [linuxfoundation.org]

"LSB-conforming systems promise to be able to install an LSB-compliant RPM. However, you need not limit yourself to that format, with the caveat that the packaging technology you choose must work on an LSB-compliant system. For example, a shell script with a tarball is an acceptable format. Your own installer is acceptable, too, as long as the installer itself is LSB compliant."

Re:Distribution (0)

Anonymous Coward | more than 6 years ago | (#24439291)

Third party software shouldn't be packaged, it should install into a subdirectory of /opt in the same way that Windows software uses "\Program Files".

If you're compiling from source well then, yes - of course you're going to have trouble. Not as much as if you were trying to do the same thing in Windows or OS X though.

Re:Distribution (1)

buchanmilne (258619) | more than 6 years ago | (#24439437)

But, did you note the mention of "ISV" ?

When last did you install Netbackup, Symantec Critical Server Protect, Veritas, Sun JES (and all its pieces) on Ubuntu? You haven't? Yes, this means that you aren't the target customer for the people who need problems solved.

ABI (1, Insightful)

Anonymous Coward | more than 6 years ago | (#24437389)

Why cant we have binary compatibility too :(

Re:ABI (1, Redundant)

oyenstikker (536040) | more than 6 years ago | (#24437525)

Because Linux runs on many different hardware architectures.

Re:ABI (1)

mrsteveman1 (1010381) | more than 6 years ago | (#24437829)

Yea, even within one architecture there is no binary compatibility, which was the GPs point you either ignored or didn't get.

Re:ABI (1)

oyenstikker (536040) | more than 6 years ago | (#24438269)

There is at least some binary compatibility. I have downloaded and successfully executed generic binaries on several distributions.

Re:ABI (2, Interesting)

notamisfit (995619) | more than 6 years ago | (#24438299)

"Binary Compatibility" is one of those horrendously ugly catch-alls that, in the end, really doesn't explain anything. Strictly speaking, every distribution out there uses the same ELF executable format, so they're all "binary compatible". Of course, there's library compatibility (usually not a big factor), and package format/package manager incompatibility ("I tried to install a Ford Escort starter in my Chevy Malibu and the bolt holes don't match up!").

Re:ABI (1)

init100 (915886) | more than 6 years ago | (#24439015)

If there isn't any binary compatbility, how can I run my ten year old Linux games (released by the now-defunct LokiGames) on my modern Linux installation?

Difficult? (0)

Anonymous Coward | more than 6 years ago | (#24437521)

"Ever thought it was difficult to write software for Linux? For multiple distros?"

No. For Windows? Yes. At least Linux has an organized filesystem, with Windows, headers and libraries could be anywhere.

Re:Difficult? (1)

AceofSpades19 (1107875) | more than 6 years ago | (#24437669)

In every linux distro I have used, the basic filesystem is always the same, of course there might be some extra directories, like /srv in openSuSE, but the basic filesytem is always the same

Re:Difficult? (1)

Billhead (842510) | more than 6 years ago | (#24438171)

I think that was his point, that at least in linux it is consistent.

Didn't we try this once? (3, Insightful)

oyenstikker (536040) | more than 6 years ago | (#24437577)

LSB4 is all very well, but if RHEL does not follow (does anybody really think they will?) it will not amount to a hill of beans.

Re:Didn't we try this once? (1)

Darkness404 (1287218) | more than 6 years ago | (#24437609)

Exactly, Red Hat will be complaining that it doesn't use RPM, Ubuntu will grumble that they just made Apt and Deb simple enough for everyone to use, Gentoo will complain that it isn't fast enough...

Re:Didn't we try this once? (3, Informative)

larry bagina (561269) | more than 6 years ago | (#24437769)

It does use RPM.

Re:Didn't we try this once? (0, Troll)

ShieldW0lf (601553) | more than 6 years ago | (#24438823)

It does use RPM.

Ewhhh...

Re:Didn't we try this once? (0)

Anonymous Coward | more than 6 years ago | (#24438951)

Well, that makes it pretty useless then, doesn't it?

Re:Didn't we try this once? (1)

odiroot (1331479) | more than 6 years ago | (#24439201)

Please note that to yourself and stop telling bullshit. The reason why Gentoo exist is NOT speed. It's really getting boring. Freedom of choice is the factor that made Gentoo. Freedom of taking from applications only these things that you want or need. In Simple English: you use only these apps that you want/need.

Re:Didn't we try this once? (2, Funny)

Knuckles (8964) | more than 6 years ago | (#24439325)

Ubuntu will grumble that they just made Apt and Deb simple enough for everyone to use

Come again?

Isn't this what Shuttleworth was getting at? (2, Insightful)

HighOrbit (631451) | more than 6 years ago | (#24437643)

All the distrubtions use the same basic set of Gnu tools (like GCC, binutils, bash) and common programs like the perl binary. So why not have all the contemporaneous (i.e. released in the same time-frame) distros use the same tools? Shuttleworth was basically advocating an extended version of this (although he phrased it in terms of a coordinated release cycle [slashdot.org] ) to be policy across several distros and to include higher-level applications like GNOME, KDE, and OO (besides the low level stuff like binutils).

As I've said before [slashdot.org] , software vendors like Oracle would love this because it would simplify their support.

Now if only LSB would stop the cluttering of /usr/bin with non-system programs and put user install apps in /usr/local or /opt where they belong. ;)

Re:Isn't this what Shuttleworth was getting at? (3, Insightful)

X0563511 (793323) | more than 6 years ago | (#24437841)

Well, from what I've seen, /usr/local and /opt were reserved for the local sysadmin to manage, and the package management system generally stayed away from that. This meant that custom software and distro packages didn't have file conflicts.

Now, I like the way that works, a lot. But I don't have any objections against further partitioning of that scheme.

Re:Isn't this what Shuttleworth was getting at? (1)

TheRaven64 (641858) | more than 6 years ago | (#24438477)

Now if only LSB would stop the cluttering of /usr/bin with non-system programs and put user install apps in /usr/local or /opt where they belong

Won't happen until Linux distributions work out what is a system program and what isn't. In *BSD and most other UNIX derivatives it's obvious. In a Linux distribution everything is a third-party component including the kernel, so where do you draw the line?

A simple explanation for ISVs: (0, Flamebait)

Cal Paterson (881180) | more than 6 years ago | (#24437649)

If you want to write for distro foo, you release the source code and get to work collaborating with distro foo. Someone will package your program, and you'll be fine.

If you don't release source code, you can expect endless pain, and I hope that doesn't change.

Re:A simple explanation for ISVs: (5, Insightful)

droopycom (470921) | more than 6 years ago | (#24437777)

But you see, they dont want to write for distros foo, bar, etc... they want to write an app for linux.

They dont want to "collaborate" with dozens of distros, all of which will tell them that "in our distro, the proper way of how to do this" is different than the other ones...

 

Re:A simple explanation for ISVs: (0)

Anonymous Coward | more than 6 years ago | (#24437807)

If you want to write for distro foo, you release the source code and get to work collaborating with distro foo. Someone will package your program, and you'll be fine. If you don't release source code, you can expect endless pain, and I hope that doesn't change.

Releasing the source doesn't guarantee that anyone's going to compile it. Why should Redhat or SUSE expend time and resources maintaining a port of your little niche program? Unless or until it gets big and popular you can't rely on the distro makers to help you put it out there.

Re:A simple explanation for ISVs: (5, Insightful)

mrsteveman1 (1010381) | more than 6 years ago | (#24437857)

Classic zealot response. Pretend the entire world is moving to GPL-only software and neglect to address the concerns of anyone who disagrees.

Re:A simple explanation for ISVs: (0, Flamebait)

Eighty7 (1130057) | more than 6 years ago | (#24439037)

Neglecting proprietary software now makes you a zealot? Hey sign me up, because I actually prefer to contribute to software that I'm free to run/modify/distribute. Weird concept, I know.

And btw, GP didn't say GPL-only. There are many free-software licenses, as everyone including the FSF will tell you.

Unified Protocol and MIME Registry (4, Insightful)

Doc Ruby (173196) | more than 6 years ago | (#24437665)

Other than eliminating conflicting directory structures, the most important standard for Linux distros to completely unify would be a single API to data protocols and MIME types. Like the one FreeDesktop.org has managed to sync (in principle) between GNOME and KDE Desktops, but for all distros (including servers).

A registry of which app to hand off a URL to given its protocol part, to retrieve the data. A registry of which app to hand off the data to once it's retrieved. Different data handler lists for displaying, editing or executing (the usual Linux RWX modes) the content, depending on the use case triggering the registry access. The registries could include prioritized lists of different apps, depending on user selection or settable default preference. And of course any single app could be registered to either registry, in any mode it will function properly.

Then the OS is performing its main task of connecting processes to the hardware and to each other. In a very simple and clear architecture. That every single app can use, without having to anticipate how the other apps will agree with it.

If LSB4 can pull that off, using the existing attempts as a starting point, it won't just make a unified Linux target for developers across distros. It will make LSB4 itself more quickly and completely adopted, because its benefits will be so compelling.

It already happened (2, Insightful)

BELG (4429) | more than 6 years ago | (#24437761)

We don't want it to happen?

It already did.

Distribution compatibility and package management is a big problem for most, if not all developers, and has been for a very long time.

Re:It already happened (1)

Chester K (145560) | more than 6 years ago | (#24438137)

Distribution compatibility and package management is a big problem for most, if not all developers, and has been for a very long time.

And it will be, for quite some time to come. Linux doesn't have a stable ABI, so it's very hard to deploy [blogspot.com] to. I'm pretty sure even the LSB's goals don't reach far enough to solve this fundamental problem.

Re:It already happened (1)

TheRaven64 (641858) | more than 6 years ago | (#24438673)

Linux does have a stable ABI for userland programs. Linux is a kernel. It only interfaces with userland programs via system calls. These are backwards-compatible right back to Linux 0.1.

Linux distributions may or may not have a stable ABI. If you use C++, they tend to use the GCC ABI which changes periodically for C++. Libraries also might not have a stable ABI, but if you write an app that depends on one then you have to either see if it makes ABI guarantees and consider static linking if it doesn't. The X11 protocol has been stable forever, so that's not a limiting factor.

One example of where it works (1)

Krishnoid (984597) | more than 6 years ago | (#24438365)

Distribution compatibility and package management is a big problem for most, if not all developers, and has been for a very long time.

Debian [lwn.net] focused on and solved this problem with their FHS (the whole lwn discussion [lwn.net] on LSB4 is here), and take packaging and interoperability seriously (they also take distribution seriously, but other distros do that too). But IMHO, Debian represents the amount of rigor, effort, and time it takes to get these non-glamorous 'administrative' things right. In particular, a commitment to 'must pass defined installation/filesystem/interoperability test suite' over 'rpm -i seems to drop stuff in place ok' is historically sufficient to make installation reliable, and you could moot the point as to whether it's necessary now, and importantly, in the future.

If developers provided hints (in the form of a skeleton debian control or rpm spec file) describing even roughly

  • how their .tar.gz divides into logical installable parts
  • what dependencies they know it needs to build and run
  • generally what dirs in the .tar.gz contain libs, executables, docs, and config files

I think it would go a long way towards helping distribution authors. Even a text file (README.packagers.txt) with a couple paragraphs of prose describing this would give a big boost to packagers, and in turn, to the interoperability of the software with others as a good distro constituent. Debian recognized this, and IMHO the sooner developers visualize helping distribution creators by feeding this kind of information forward, the sooner distributions will converge on internal interoperability, leading to higher quality distributions, and subsequently to FLOSS maturing faster.

Simple solution (1)

Viol8 (599362) | more than 6 years ago | (#24439589)

Don't write your code to rely on v 2.3b of some obscure library that some other obscure programs may need a different version of and may not exist on some systems anyway. Stick with core libs like libc etc and you can't go wrong. Or even better just distribute a statically compiled binary.

/etc still gets too big! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#24437773)

I have been mentioning this for years: it doesn't make sense to have ALL configuration information in /etc. /etc needs to be mounted for booting, but only a fraction of the stuff there will be needed at boot time. Almost any package which installs to /usr, does not need to have configuration information present at boot time. My personal feeling, is that anything which installs to /usr, should have its configuration information in /etc/usr, and we should be able to symlink this to /usr/etc.

Re:/etc still gets too big! (4, Funny)

XanC (644172) | more than 6 years ago | (#24437925)

I have been mentioning this for years

Yes, I've seen you post here often!

Re:/etc still gets too big! (2, Interesting)

X0563511 (793323) | more than 6 years ago | (#24438009)

hrm, maybe we could have an /setc for boot-critical config? Similar to how we have /bin and /sbin. For people who like the old way of one massive /etc, you could just symlink one to the other and there would be no practical difference.

Re:/etc still gets too big! (1)

Gazzonyx (982402) | more than 6 years ago | (#24438867)

Except for the fact that it isn't at all in the FHS which already has enough problems with it being very open to interpretation (and sometimes extended... RHEL, what's /net, how does it differ from /srv). Symlink farms mean that you're doing something wrong.

I've already seen distros symlinking /srv/httpd to /var/www, because that's where apache has been for the last fifteen years! If you have a place for servers, then, what belongs in /opt and what belongs in /srv? If it's a network server, does it go in /opt, /srv or /net? If it's over NFS, does it go in /export/home, /data/home or /home? You cannot separate directory structures by use because much of the data we have has multiple uses.

Re:/etc still gets too big! (1)

init100 (915886) | more than 6 years ago | (#24439463)

RHEL, what's /net, how does it differ from /srv

/net is for mounting remote network filesystem shares, while /srv is the opposite, that is local content being shared with remote hosts through various protocols. So as an example, the NFS server could use a subdirectory of /srv for exporting local files, and a client could mount that remote share in a subdirectory of /net.

It's about freakin time (2, Insightful)

ph1nn (588305) | more than 6 years ago | (#24437879)

I've hated this whole fragmentation thing all along. It would be so much nicer to have a unified system like LSB4 claims to offer. This can't come soon enough.

Do we want LSB? (2, Insightful)

maestroX (1061960) | more than 6 years ago | (#24438231)

Formalizing the basis of a linux system seems awkward to me. It simply evolves, LSB is following.

I've never had any need for a standardized linux environment except when I had to run Civ3 using libc5. The kernel never really freezes AFAIK.

The beauty of linux, progress continues, just switch distros. If you need something comfy and reliable, use Debian.

Its not bad, but... (1)

zartacla (1320359) | more than 6 years ago | (#24438815)

...there are a lot of distributions, good (not necessarily too popular) ones, apart from ubloatuntu, red hat etc, which are in use and new ones are being developed all the time...how do they expect to keep up with all of these and vice-versa ? Who's complaining anyway ? Everybody's in awe of open source and Linux. Introducing standards , man it sounds evil.

Needs a code name (3, Funny)

harlows_monkeys (106428) | more than 6 years ago | (#24438875)

Every project needs a code name. For this, I propose "Bullwinkle", and their slogan can be "This time for sure!".

+1 as a developer (2, Insightful)

ge0ffrey (1337221) | more than 6 years ago | (#24438941)

As a developer I've considered this one of the (if not the) most important issue in linux. I am happy to hear it's finally getting the attention it needs. Many applications (especially games) will only be released for linux (and work out-of-the-box without tweaking), once there is a decent way to build 1 release for any (LSB compliant) linux distro. I myself build java applications (on Ubuntu) that work perfectly fine on linux, but because of this problem, I simply don't bother building a release package for linux. No matter how hard is, get it done. And make an extensive test kit to assure Red Hat, Ubuntu and Novell are compatible.

One of Linux' biggest annoyances.. (0)

Anonymous Coward | more than 6 years ago | (#24439115)

.. is that you just cant try out software quickly without a lot of hassle. For ex. there is a new software that can do $cool_thing, on windows I just download, install, try it, either uninstall or keep it. In Linux if its not packaged for your distro you cant do that quickly, even if its GPL'ed etc.. Most of times they'll give you source and let you compile it by yourself which takes way too long and for most end users is far from convenient. Heck its easier to quickly test new software in WINE rather than to wait till its packaged for your favorite distro.

Closing the door after the horses have escaped... (1)

argent (18001) | more than 6 years ago | (#24439239)

They don't want what happened to UNIX happen to Linux?

"But, Doctor Evil, that already happened."

The horses have escaped and had children.

Why don't they insted make a library to abstract (4, Interesting)

TheSunborn (68004) | more than 6 years ago | (#24439285)

Instead of trying to make all the distributions the same, why don't they make a library that abstract away the difference?

Example: If my program need to link to a ssl library(Such as openssl), version 2.3 or newer, I should call a function
findLibrary("ssl",2,3) which would return the path to the needed .so file, or null if the file is not installed. There could then be a
function to also ask the os to install the needed library if it were not there.
Each linux distribution should then implement the library in a way, so that the Redhat version, might forward the call to rpm, while the debian version of the library would query the dep database insted.

And instead of the infinite debate on /opt vs /usr/local the program could just call getPathForUserInstalledSoftware();
And getDefaultCompilerPath() instead of the current autoconfig hack.

Then a linux standard base, would just be a specification of the needed functions in LinuxStandardBaseLibrary.

And we would newer have to use the autoconfig hack. (The library might ofcause also be implemented on Solaris, and maybe even cygwin/windows)

It'll never happen. (1)

bjk002 (757977) | more than 6 years ago | (#24439381)

The problem with the *nix community has been and always will be the very thing that makes *nix so attractive: open, availability for forking, etc...

As a code monkey, I have been a fan of linux as long as I can remember. I can also say that in all that time, THIS issue, more than any other, has always kept *nix from gaining real traction in the biz world.

CIO: "So I can't REALLY switch between distros because of library differences"?
DEV: "Yeah thats right."
CIO: "Then what exactly is the difference between this and windows, other than lack of support?"
DEV: "Ummm.... well we can see the OS code and change it"
CIO: "We make widgets not OS's right?"
DEV: "Yeah..."
CIO: "So who cares?"
DEV: "Ummm...." ... and no, I'm not trolling.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>