Linux Foundation Promises LSB4 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."
What is LSB, you ask? (Score:5, Informative)
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: (Score:2, Insightful)
Re:What is LSB, you ask? (Score:5, Interesting)
The Linux Standard Base is essentially a farce. The Wikipedia article linked to above gives a pretty good overview of why, but the primary reason is that developers don't want a set of tests that they can run against their application to see if it is portable. They want a binary distribution that they can actually install their software on and test against. Originally that's precisely what the LSB was supposed to be. It was going to be a small installable distribution based on Debian.
At the time Caldera thought that would be problematic, and so the current incarnation of the LSB was born. Not that anyone uses it, as it is a complete waste of time.
Re: (Score:3, Insightful)
"Not that anyone uses it, as it is a complete waste of time."
I don't know if it's a waste of time. I don't even know what the original motivations for the LSB were.
But I do know what is meant for now: is an intent from some distribution vendors to make easier to coaligate with privative source vendors. Not that I think this is a good or bad thing for them to do, but I do know that's not a goal I'm interested in, so I don't give a damn about LSB.
Making better/easier portable configure-like tools? Sure.
Mak
Re: (Score:3, Informative)
Uh that's exactly what the LSB is trying to put a stop to. Currently, software installation sucks [ianmurdock.com] because it doesn't have integration with the native package manager. One of the reasons for forming a cohesive, extensible packaging API is so that any package can communicate with t
Re:POSIX...? (Score:5, Informative)
The difficulty depends on what tools you use (Score:2, Interesting)
Re:The difficulty depends on what tools you use (Score:4, Informative)
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.
Re:Really? (Score:5, Interesting)
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: (Score:2)
Perhaps they do that because some boot scripts are written in Python (I'm pretty sure Gentoo is like this)?
Re: (Score:2)
Re: (Score:3, Informative)
Maybe it was Portage (Gentoo's Python-based package management system) then? I can imagine it being useful to be able to mess with packages (especially core ones like baselayout) in single-user mode.
Re: (Score:2)
Re:Really? (Score:5, Informative)
env should always be in /usr/bin. This will work on any POSIX.2-compliant system:
POSIX.2 doesn't even mention /usr. The location of env is not standardized.
Re: (Score:2)
BASH does.
$ cat > hello.sh ./hello.sh ./test.sh: bash: bad interpreter: No such file or directory
#!bash
echo "Hello, world!"
^D
$ chmod a+x hello.sh
$
bash:
Re:Really? (Score:5, Informative)
The first way is with a command like 'sh foo.sh'. sh will then read foo.sh and execute each command in it in order (if it's not a shell script, it will hopefully read the magic number and run it).
The second way is to just exec() it. The loader then reads the first few bytes of the file. This tells it what type of file it is. For ELF files, they will be ".ELF". For Mach-O binaries, they will be 0xFEEDFACE or 0xCAFEBABE, depending on the architecture. For scripts the first two bytes will be "#!".
If the loader encounters "#!" then it will read the rest of the line execute the specified command (and arguments) and pass the file to it as the last argument. You can see this in operation with the following script:
If you have a shell script that needs to run with the standard POSIX shell, then there's no problem. You just specify /bin/sh after the #! and it's fine. But what happens if you want to use some bash-specific features? On GNU platforms, bash is the default shell and /bin/sh is a hard link to bash, so it's in /bin. On other platforms it's a third-party thing and so will be in /usr/local/bin or /opt/something. This is where env comes in.
When you specify "#!/usr/local/env bash" you can safely hard-code the path of env, because POSIX defines where it is. Env then looks up where bash is and execs it with whatever command line arguments it was given. You can see this in action again like this:
If you just run 'env' from a command line to inspect the environment variables, you are most likely just calling a shell built-in command, which lists the things passed in to the third argument to main() and any set since the shell started. Env, however, can be used when you are not launching from a shell. If your program wants to run a shell script, you can just vfork() and exec() it, and the loader will find the correct interpreter. You could always inspect the environment yourself, but having every app do that whenever it needs to run a script is quite silly (especially since it means that the app also has to know the difference between a binary and a script and so on).
Some people still have a habit of hard-coding /bin/bash, and this is probably the kind of crap LSB will encourage ('bash is always in /bin on Linux, and I don't care about other platforms!') but the correct thing to do is use env.
Re: (Score:2)
"So on and so forth. Which is why the LSB is important to people like Python developers."
Please, go in depth with your "so forth" cases, since the ones you are producing have nothing to do with the LSB. They are a case for a FHS, and whooops! that already exists (http://www.pathname.com/fhs/)
Re: (Score:2)
Blame Sun.
The problem was that for years Sun refused to release Java under a Free License. This meant that packages in main could not rely on the existence of a JVM. Worse, at least if you wanted to use Sun's JVM, as gcj got better Debian started packaging Free Software Java packages so that they would run on gcj.
Sun's announcement to Free Java has helped move things in the right direction, but we are just barely starting to get a usable Free Software JVM. I stopped paying attention some time ago (as
Jim Zemlin needs to read the GPL. (Score:2, Insightful)
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. (Score:4, Insightful)
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. (Score:4, Interesting)
It relates to his statement that I quoted.
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: (Score:2)
>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, w
Do you have an example? (Score:2)
And an example of that would be ... ?
And what is this "guarantee" that you're talking about?
Re: (Score:3, Insightful)
No, VMWare works for me. (Score:2)
I don't know about you, but I have run VMWare server and workstation on Red Hat, SuSE and Ubuntu.
Yes, I have. I'm still running VMWare server on my Ubuntu box (Hardy Heron). It works. I have to run a script every time I upgrade the kernel, but that is all.
I have also run Apache, Samba, BIND and many others on different distributions. Without an
Re: (Score:2)
Apache, Samba and BIND are using autoconf and recompiled for every distro. Also, they have a package and are part of repositories. Not the case with many proprietary vendors...
I agree VMWare works on most major distribution (it recompiles the kernel module, which it shouldn't have to), although I'm sure it won't work on every YDL or shady distros out there.
Also, IIRC, they have specific distros for their technical support services. Guess why...
So VMWare does work on different distributions. (Score:2)
So? Fragmentation would be when they did NOT work.
Since they DO work, that is not fragmentation.
Yeah ... so it does work.
Again, fragmentation would be wh
Re: (Score:2)
Re:Looks like the GPL haters got some mod points. (Score:4, Informative)
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. (Score:2)
Sure. You just have to tell everyone what the BEST way is.
Actually, it has EVERYT
Re: (Score:2)
"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."
Yea, they've had some time to work this stuff out and it hasn't happened. You assume that the best solution will win, and in Linux that isn't the only deciding factor. People choose distros based on things ranging from "i hate novell" all the way to "it had blue wallpaper".
How about all these distros agree on something beforehand? This commun
If it is the colour of wallpaper, who cares? (Score:2)
So? If it works, it works.
Because that requires something known as "prescience". They have to know BEFORE THEY DO IT which options are best.
Again, when you know the future so well that you c
Distribution (Score:5, Interesting)
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 (Score:5, Informative)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Autopackage is essentially a distribution on top of the distribution. The autopackage guys basically built an autopackage base that they have ported to some of the more popular distributions. They then try and take care of the same packaging issues that Debian, Fedora, and the rest of the distributions take care of already. They have their own incompatible list of packages, with their own incompatible dependencies, their own naming scheme, and their own packaging format.
The only difference between auto
Re: (Score:2)
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 wit
Re: (Score:2)
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.
Re: (Score:2)
Yes, this means that you aren't the target customer for the people who need problems solved.
The point I was making is that it is hard for developers to easily get their software into a single format that all their customers can easily use. The fact that in my examples I'm not the target for LSB does not matter. I'm the customer of their target, and when it is a pain for me to get and install software because the developer had to choose to target either Debian or RedHat or waste time trying to target both with different procedures, well that is the exact problem they're supposedly working on solvin
Re: (Score:2)
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".
I kind of prefer my third party software to be packaged so I can manage the install, uninstall, and update process from the same location as all the rest of my software. I strongly prefer it to be a self contained, executable package so I can run it from removable media without having to install it locally as well and so that all the files it uses are self contained for security and management reasons.
If you're compiling from source well then, yes - of course you're going to have trouble.
Why? Instead of typing the same commands on the CLI every time, why can't my package manager handle that st
Re: (Score:2)
That only works for applications for which you have the source.
Not all commercial software is open source, and limiting yourself to only open-source (er, "ships as source") software is quite limiting in a business enviornment.
Didn't we try this once? (Score:4, Insightful)
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: (Score:2)
Re: (Score:3, Informative)
Re: (Score:3, Funny)
Ubuntu will grumble that they just made Apt and Deb simple enough for everyone to use
Come again?
Re: (Score:2)
It won't work because they'll (again) try to solve problems that don't need solving and (again) ignore the one thing that would actually make a difference.
They'll probably throw yet another abstraction layer on top of init, one more for the package manager(s), and maybe a big tarball of symbolic links to top off the complexity party.
But you won't hear anyone saying "Hey! What if we all agreed to use the same tool chain for a bit?"
Isn't this what Shuttleworth was getting at? (Score:3, Insightful)
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
Re:Isn't this what Shuttleworth was getting at? (Score:4, Insightful)
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: (Score:2)
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?
Re: (Score:2)
They're already made that distinction; they all have a core set of packages which are vital to a working system, e.g. what you get when you debootstrap a Debian/Ubuntu install, which is enough for a usable shell, basic networking, and installing other apps.
Unified Protocol and MIME Registry (Score:5, Insightful)
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.
Re: (Score:2)
Ok, I plenty layers of abstraction there, but I don't see a problem that needs solving. Are you trying to make it so that if I click on a png it gets opened up with the application that I set in one of my registry configuration wizards?
Re: (Score:2)
Yes. And that if you click on any URL, or in any other way tell an app you want a network/internet/filesystem object with a URL, that the app will get the data, by relying on whatever standard processing you have assigned (or the OS assigns by default).
Yes, this should all seem familiar from Firefox or your other browser - it was basically introduced with Netscape. But it should be an OS feature. So that any app can access it in a truly standard fashion. That's why it was started in FreeDesktop.org. But eve
It already happened (Score:3, Insightful)
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: (Score:2)
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: (Score:2)
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.
One example of where it works (Score:2)
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 h
Simple solution (Score:2)
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.
Do we want LSB? (Score:2, Insightful)
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.
Needs a code name (Score:4, Funny)
+1 as a developer (Score:2, Insightful)
Closing the door after the horses have escaped... (Score:2)
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 (Score:5, Interesting)
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 .so file, or null if the file is not installed. There could then be a
findLibrary("ssl",2,3) which would return the path to the needed
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)
Re: (Score:2)
The trouble is, LSB would essentially turn into ICANN in that regard. How do you determine what qualifies a library for inclusion in LSB except by charging like we do for domain names? Of course, there could also be a vetting process, but one person decides that the vetting process is not working for them, and suddenly you have an alternate version of libSSL floating around that's required for a specific program, and before long the entire thing falls flat.
We need things to be as much as possible the same.
Re: (Score:3, Insightful)
See this graph [wikipedia.org] for more information.
Re:What did happen to UNIX? (Score:4, Informative)
Re: (Score:2, Funny)
Re: (Score:3, Informative)
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 (Score:4, Insightful)
"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: (Score:2)
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 (Score:2, Funny)
Sorry, but when expressing inequality != is the correct operator.
You're not really a programmer, security, please escort this gentleman to Digg, please. :-)
Re: (Score:2)
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]
Not the same. (Score:2)
So far, so good.
Huh? I run "bash" on all kinds of distributions. Not to mention Apache. And Samba. It's trivial to
Re: (Score:2)
Re: (Score:2)
"But in Linux what we have is not a single species, but a genus"
Good analogy; let's expand on it.
The "problem" with the LSB is that is an intent much alike with this one: I'm a thootbrush maker and I'd want to sell my products to all the cats over there, since there are a lot. But, hey, it's not that I want to make different models to cover the variability of the Felix genus (or the Felidae family, for that matter), covering from little kitties to mature lions, so I'll make a marketing campaing to force al
Re:What did happen to UNIX? (Score:5, Insightful)
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? (Score:5, Insightful)
Re: (Score:2)
Re: (Score:3, Funny)
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>
Re: (Score:2, Redundant)
Because Linux runs on many different hardware architectures.
Re: (Score:2)
Yea, even within one architecture there is no binary compatibility, which was the GPs point you either ignored or didn't get.
Re: (Score:2)
There is at least some binary compatibility. I have downloaded and successfully executed generic binaries on several distributions.
Re: (Score:2)
The real fun only starts when you try to build one.
Re: (Score:3, Interesting)
Re: (Score:2)
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?
Re: (Score:2)
Do they rely on any modern dynamic system libraries? If they do, chances are they don't work.
Static stuff works sure, those interfaces for running stuff are stable, libraries aren't between distros.
Re:A simple explanation for ISVs: (Score:5, Insightful)
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: (Score:5, Insightful)
Classic zealot response. Pretend the entire world is moving to GPL-only software and neglect to address the concerns of anyone who disagrees.
MOD PARENT UP (Score:3, Interesting)
Exactly!
The world does not revolve about GPL software. It works about *working software*. I don't care if I use GPL to get my work done, $50 software or if I use a $20,000 a seat software. Whatever makes sense is what is used.
If Linux community expects ANY sort of commercial software released for Linux distributions, they need to get the LSB implementation done and ready. LSB is like an SDK towards building apps for ISVs. If you don't have it, you end up with app not for Linux, but for Debian 3.0, RHEL 2.0,
Re: (Score:2)
Yea, it does in this case. Its the old 'if you're in the repos, you're fine' argument, and it falls flat on its face in a number of situations, some even involving open source software, but especially closed commercial software.
Making life intentionally difficult for commercial closed software vendors isn't going to help the cause of open source, nor will it help Linux as a platform. If anything it will cause large companies to avoid it because political crap takes precedence over everything else.
FOSS soft
Re: (Score:2)
This has been pointed out dozens of times, but people in the various distributions still do not get it. If you're packaging software up on a widespread basis so users can install it you are not going to do it for each and every distribution and you are certainly not going to wait years for it to appear in a package repository. Those are the sa
Re:/etc still gets too big! (Score:5, Funny)
I have been mentioning this for years
Yes, I've seen you post here often!
Re: (Score:3, Interesting)
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: (Score:2)
I've already seen distros symlinking
Re: (Score:2)
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.
Gotcha (Score:2)
Re:It'll never happen. (Score:5, Insightful)
COO: so, we've developed a new widget, brilliant. When can we ship it.
DEV: today, its all tested. I've run it myself on my Debian box.
COO: sure, it'll run on Customer B's Redhat environment won't it?
DEV: Ummmm.. well, not straight off.
COO: ok, so what do we need to do to make it work?
DEV: well, alter a couple of paths, recompile, change the dependancy for package Z and build a rpm
COO: and how long will that take?
DEV: a week, maybe 2 with testing.
COO: so, that's 2 weeks development costs on top of what we've already spent. We wouldn't have this kind of problems with Windows!
and I'm not trolling either - standards are good, making extra work for yourself for no good reason is bad. Its not as if a common directory layout, ABI or programming libraries need to affect open source linux in any way. The Kernel is a standard, and no-one complains they don't have a choice of kernels to develop against.
Re: (Score:2)
That depends on if you view it from a user or from a developer point of view. From a developer point of view, who distributes source, Linux is quite nice and Windows is pretty terrible. On the other side from a users point of view Linux is a pretty ugly nightmare for all software that isn't part of your distro and even for some that is part of your distro when it is to old or buggy, Windows on the other side is just a click on setup.exe.