Slashdot Mirror

Will the Linux Standard Base specification make Linux more vulnerable to viri? Currently, one of the "strengths" of Linux is it's non-homogenous nature. Every distro. has it's own way of doing things (Slackware vs. Red Hat :), hence a virus has a lot of ground to cover. However, if everybody follows the LSB do we become much easier to infect?

Jeff

Others have addressed the various issues about what is a "real" Bourne shell and bash extensions and all that. Anyway, the Linux Standard Base has a section on shells. In a nutshell, bash 2.x was the most POSIX-compliant of the shells that the LSB tested (and no, I don't know exactly what versions or which shells or the like), with pdksh getting an honorable mention. And there were two ways in which bash was not POSIX-compliant and concerning which the LSB therefore diverges from POSIX (whether $0 is the full pathname or just the basename, and what happens if you try to use "." to run a script without the read bit set). I don't know whether a future version of POSIX is planning to change the specification, or whether this is likely to remain a divergence for the foreseeable future or what. In any event, these two issues shouldn't be hard to deal with in writing scripts.

Symbol Versioning

(This dummy line is added to get around a slashcode violation of postercomment compression filter - what the fuck is that?)

Last time I looked, SuSE violated the FHS by using /sbin/init.d and having the distribution install software into /opt

And, of course, I forgot to post the link to LSB.
http://www.linuxbase.org

---

LDP = Linux Documentation Project

LSB = Linux Standard Base

and for perl:

perl -MCPAN -e install :
suck source accross the net, resolve dependencies, buils, installs...

ok, that's only for perl, but that's great, when it works ;-)

anyway i don't really see in what port system, apt get, rpm or whatever have to do with .NET. I thought .NET was dealing more with services (passport stuff, and some C# bullshit progs around -maybe other languages too-), than with apps, that are most of the time simply useable on any UNIX-like system (./configure,make,make install works on most recent progs out here, on ever GNU/Linux distro, most *BSD, and probably MacOS X too, and thus usually binaries packages exist as well) so what's the point of this article ? As far as apps are concerned, i don't see why we would use *BSD ports, that seems very odd to me, and instead i think it would be far better if things were cleared up for everyone about where to install all the stuff from a prog (/usr ? /usr/share ? /usr/local ? /var ???) i've seen in the past years that much funny things about that. see for apache, in the past default content directories were under /home/httpd, now it is in /var/www (using RedHat), and it's probably different on another distro. That makes no sense to me. it's silly. I think LSB 1.0 is far better news than that port thing we don't care.... (well, FHS seems to be still working on, but it's about ending with a stable version, despite i don't find clear enough the difference between /usr and /opt)

but maybe i'm only completely missing the point about that non-event...

Package management is a wonderful thing, but it does have some drawbacks.

Package management is used to ensure that the rights libraries needed for your app (server) to work. If you think that the package you are using is bloated, does not provide the functionality that you need or even does not exist in your distribution. You should create the package yourself.

Unfortunally very fewer distributions can satisfy every kind of user, so if you knows how to create a package for your distro, you can fill the gap.

Just to note RPM has been made the official LSB packaging tool,

Package management is a wonderful thing, but it does have some drawbacks.

Package management is used to ensure that the rights libraries needed for your app (server) to work. If you think that the package you are using is bloated, does not provide the functionality that you need or even does not exist in your distribution. You should create the package yourself.

Unfortunally very fewer distributions can satisfy every kind of user, so if you knows how to create a package for your distro, you can fill the gap.

Just to note RPM has been made the official LSB packaging tool,

Yes, it's right that the blurb doesn't mentions anything about RedHat. It doesn't mentions Progeny, Storm, Stampede, SLS or many of the other existing distributions.

If you look at linuxbase.org there is a lot of contributors including Caldera, Redhat, Suse, Mandrake, Metro Link, VA Linux and even the Open Group is mentioned.

I don't know how you can look at dpkg and apt and not be impressed. Maybe people are afraid it will effect their business model's because debian is doing for free what other folks are charging for. Is either perfect? No. But that should only serve to raise the bar for each package management system. Then again splitting hairs dosen't do anyone any good, I just hope we can pick the best choice becase it _is_ the best choice.

Yes, you should be able to use your software in any linux distribution. But how long will it actually take from the distribution makers to accept and comply with this standard?

Not very long at all, hopefully. If you look at the home page for the Linux Base project, you'll see that their list of contributors includes all the big players in Linux, including hardware vendors like IBM and Compaq. Besides, it sure looks like a good excuse for a major revision number.

I don't think so.... Ok, it's a minor mistake, but they call it a 1.0 release.

OK, I know why. But really, as someone pointed out the other day, the Open Group will certify NT as a "UNIX" OS if it meets their criteria, so why isn't the real goal to get *BSD certified as an official "UNIX" (and, similarly, to get Linux certified as well)? If my suspicions are correct and the certification does not mean apps are portable, then we need better UNIX certification, not abandonment of the only available certification.

I also wonder how many people are scrambling to run *BSD binaries on their Linux boxes... Again, not to flame or troll, but I wonder about market share and how it affects software developers. Anyone know off-hand how many apps cleanly compile for both *BSD and Linux? (and yes, I know the story is about compatible binaries, not compatible source).

Hell, how many binaries run on all Linux distros (hopefully the Linux Standard Base will help)? So are we talking getting Red Hat binaries to run on BSD, or are we talking about Debian binaries, or does it matter?

Finally, it seems to me that it would be better to put the effort into making compiling the source so easy (transparent) that we don't care about binaries anymore. One real advantage of UNIX isn't that I can copy a binary file from my HPUX box and run it on my Solaris box, but rather that I can compile the same source on both boxes. This allows you to run UNIX on virtually any hardware and still find applications that will work -- you just have to compile them! Users new to UNIX have to learn all sorts of things that are different from the VAX/OS2/DOS/Windows/Amiga/Mac world they came from; why shouldn't compiling code be another thing all UNIX users learn?

well i've played with rpm and apt-get. from the page
Currently the LSB does not officially specify a package format; however, the recommended package format is RPM (Version 3) with some restrictions listed below. RPM is the defacto standard on Linux and supported either directly, or indirectly by the widest number of distributions. The intent is to in the future replace this format with a new format currently being developed

i really think more consideration should be given to the debian system of package management. it appears both redhat and debian are contributors, but i would imagine redhat contributes a bit more. i really think this is going to hurt things.

use LaTeX? want an online reference manager that

I'd like to see a trend start for GPL'd software to become "mission critical" -- in other words, for there to be certification standards, and have libraries then pass that certification, and then have programs which are built using only certified libraries, etc.

I suppose this could be one aspect of the Linux Standard Base, on further thought. Here's a URL: linuxbase.org.
--

Well, they do: SuSE Linux 7.1 will use the init scheme defined in the LSB spec.

Of course, none of this will be able to happen without a set of standards. Support the LSB!

A while ago, I would have replied to this with the standard "It's open source yadda yadda yadda choice is good". However, after seeing Redhat's latest hijinxs with gcc, I'm starting to worry if this sort of thing will become a trend. So first it's gcc that's incompatible. Then what? Xfree86? glibc?

More work needs to be done to adhere to standards and distros not doing their own thing just for the hell of it. I'd really hate for Microsoft's 'mutant' ads to ring true.

As Treasurer of the Bucknell University ACM (Association for Computing Machinery), myself and the other officers help to persuade industry, faculty, and students computer experts or evangelists to (of OOP, OSS, Linux, etc) come to Bucknell to give a presentation. In the past year or so, we've had guests like Dan Quinlan of Transmeta, speaking on the Linux Standards Base, Ralph Droms (inventor of DHCP), a faculty member at Bucknell, John 'Maddog' Hall (Linux International executive director) on the Flexibility of the Linux OS, and many others. Currently, Eric S. Raymond has added us to his mailing list and will probably come Spring semester to talk about his ideals and beliefs when it comes to software.

What are our methods of obtaining guests? First, it helps to have some connections with someone related to the person you'd like a have speak at your school. Second, being at a top-notch college like Bucknell University tends to give some incentive, perhaps, for people to visit. Finally, persistance does pay off occassionally; if there's someone you really want, make sure you remind them via email or vmail every so often that you'd be absolutely delighted to have them grace you with their presence ;-D

Good luck!

It might just be me being slow, but when I was at a Australian Unix Users Group conference in July they had people from Red Hat, Suse, Caldera and TurboLinux who all raved about this thing called the Linux Standards Base which is meant to stop vendor dominance and allow things like a standard package management system despite distribution...

RPMs, and other packaging formats, should have install scripts, especially if they're not part of a particular distro. Most source tarballs have reasonably good configure scripts, why don't RPMs? I'm not a programmer, either, but I'd think that RPM is capable of doing everything that the author wants it to do, if it's used right.

Draft Text of the LSB
The document cited in this article is -not- the LSB, and the reason all those things are already in most distributions is because they analyzed the distributions to see what they had in common! The LDPS is saying 'if you distribute a binary, compile it with this, because that's what people have' and 'if you maintain a distribution, make sure you have at -least- this, because that's the basics'.
--Parity

That's because most linux distibutions ignore the Filesystem Hierarchy Standard. I believe that this is part of the Linux Standard Base which has most of the major distributions as members so IMHO they should be using /opt.

Yellow tigers crouched in jungles in her dark eyes.

Surely a source-compatible specification would be a lot better than a binary one. That way, along with the work being done by the Linux Standard Base project, applications would be compatible with all Linux distributions and not just the x86 ones.

Users of non-x86 distributions (of which I am one with LinuxPPC) are left out a great deal of the time by the big companies when they release Linux binaries.

Although a "common binary format" exists in the form of Java bytecode, I cannot see world+dog porting all of their apps to Java. Personally, I'm now writing all of my new apps in Java so that they run on all the platforms that I have without a lot of tweaking for each of them.

RPM is also the system specified in the current LSB draft

The problem with compatibility is not package formats, but libraries, file locations etc - binary compatibility is much better than what it used to be, thanks to glibc, but is still in need of improvement.

these announcements really underscore the need for a standard linux base or something similar.

but from what i can tell, the lsb only determines what libraries and such should be installed. perhaps a better solution would be to create a meta-package format, which could be cleanly converted into .deb, .rpm, .tgz, .slp (or whatever format) with some supplied tools. then a software vendor would only have to create a single package, and either convert it, or offer the meta-package which the end-user could convert.

in any case, until there is a standardized linux base/package system, this sort of thing is going to continue. it's no different than software houses developing for msft; they are the market leader in terms of number of users. similarly, redhat has a higher percentage of users than any other linux distro. it's all about getting the biggest market possible for their software.

=--- - - .

big business can innovate and often does a damn better job than what comes out of somebody's garage

Yes, Bill Gates put it best:

"The royalty paid to us, the manual, the tape and the overhead make it a break-even operation. One thing you do do is prevent good software from being written. Who can afford to do professional work for nothing? What hobbyist can put 3-man years into programming, finding all bugs, documenting his product and distribute for free? The fact is, no one besides us has invested a lot of money in hobby software. We have written 6800 BASIC, and are writing 8080 APL and 6800 APL, but there is very little incentive to make this software available to hobbyists. Most directly, the thing you do is theft."

After all, who would spend THREE WHOLE MAN YEARS developing software. Free software could never put that much work into programming, bug finding, or documenting, and distributing for free hobbyist (free) software.

The current "plan-of-record" is to specify RPM as the file format. It is supported either directly, or indirectly by the widest number of distributions, and so far, no one has pointed out any deficiencies.

Linux Standard Base Specification 0.2pre - chapter 13

And personally I find the sysV init scripts a braindead idea, who needs to stop a server? Who needs a restart? What does it add that I can't do with 'killall -HUP .....'?

Jeroen

Up until this point, the LSB and Li18nux were operating as unincorporated organizations, which is bad for a number of reasons: legal liability, the inability to accept and distribute funding for development and other expenses, no entity to hold copyrights for the group, anti-trust issues (you need to be careful when you have competitors meeting in the same room), and more. We needed to incorporate (as a non-profit, of course).

As far as the Li18nux and the LSB are concerned, they will more or less continue as before, although we'll be able to put more resources on each project so things will speed up. We'll be working closer together and referring to each other's specification, but the LSB and Li18nux specifications will probably be separate standards for some time.

Why incorporate together? It makes sense and it's less overhead. We didn't need separate legal entities for these open-source standardization efforts.

Some LSB specifics:

Will the LSB be multi-architecture? Yes, although x86 is the main target, we are trying to draft the specification to apply for multiple architectures. Recompile the sample implementation and test suite and everything should work fine for other architectures. (The reality is that most third party software is released for Linux on x86.)

Another thing: the whole "LSB stifles development" argument is very misleading. You can ship development libraries along with stable LSB versions if you want both environments. (It will be up to the distribution and system administrators.) Kernel developers like Alan Cox, Ted Ts'o, and H. Peter Anvin have been participating in the LSB for a long time - I don't think that would happen if we were going to stifle forward progress.

Will having more members slow us down? Quite the opposite, actually. The main thing slowing us down is the amount of work to be done, not slow decision-making or the lack of consensus.

Finally, recall that the word "base" is part of the Linux Standard Base name. Distributions will still have the same amount of room to add value, innovate, and distinguish themselves. We like the fact that there are different Linux distributions, each with something unique to offer. We just disagree about requiring commercial and non-commercial providers of software to port and test their software for five or ten different Linux distributions.

Second, I don't see it particularly important to internationalize this layout. What kind of ugly precedent would this set? If I wrote a program for a German-language compiler, would my code have to read:

wenn (foo != foobar) {
schreib ("foo und foobar sein anders.\n");
}

As it is, UN*X is pretty far removed from English, anyway. Don't mess with /etc...

--

What you are proposing is basically the Linux Standards Base project. It was formed to do pretty much what you just said, and that was almost 2 years ago. Hate to say it, but they haven't come terribly far just yet.

People will be people, and they will have divergent opinions. But this seems to be the best hope for something like that. And it has at the very least, token participation from all the major players (Red Hat, SuSE, Caldera, Corel, Debian, etc, etc.)

--
It's a fine line between trolling and karma-whoring... and I think I just crossed it.
- Sean

I think it's about time that the linux distribustitions more or less shoud be standaristed. See link: LinuxBase . I think the cause of the problem is the differance between the linux distributions. If this contiues than we might indeed get a fork. What people are already fearing of.

cmon you LSB guys - WTF are you guys doing ?

Waiting for you to help.
--

There is a move to try to bring some control to this.   It is called the Linux Standard Base, the goal to create a set of standards for compatibility between distributions as well as encourage more app porting to Linux in general. &nbsp The project is being supported by most of the major distros and I recall them having a big get together not too long ago.

Their motto - "Standardizing the Penguin". &nbsp Pretty cool and timely.

• Java

  There seems to have been something of a "trainwreck" with respect to Java. There are lots of "nearly done" Java environments out there, including Kaffe, GCJ, Jikes, "Blackdown," and likely others.

  Unfortunately, none are truly useful without some combination of classes (ala GNU Classpath) and some combination of AWT/Swing. And that has been rather less rapidly forthcoming in the "reasonably free form" that is necessary in order for it to be ubiquitous enough for people to really use it to deploy applications, or to use it as a layer on which to build further infrastructure like EJB.

  Is anybody near to deploying a complete "libre" Java for Linux?

• System Config Tools

  There's Linuxconf. There's COAS. There's cfengine. And Ganymede (tho it needs Java; see above...) and bunches of other system config tools one one degree of incompleteness or another.

  Big, expensive things like UniCentre are also getting ported, although they're not likely of great interest on the home front.

  Is there any intent to try to have some useful protocols to allow intercommunications of some of these systems, or to perhaps pick an existing one rather than recreating the wheel?

• Testing/Standards

  There has been some lipservice about Linux Standard Base (LSB), but it is not evident that anyone has either deployed substantially changed systems as a result of attempting to conform to some common guidelines, nor to actually provide ways of conforming systems to standards.

  There are lots of tools out there to run systems through automated test suites; that is apparently one of the major tasks of one ACLs for Linux project. In other contexts, we find ANSI Common LISP Conformance Tests. The folks at Cygnus run EGCS through testing, and provide EGCS Test Suite Results. Greg is being used to validate that GnuStep conforms to its documentation.

  ... And every "dot zero" release of Red Hat Linux fills many with fear as it tends to at least appear undertested.

  And then there's the Extreme Programming approach (particularly associated with Smalltalk) where one of the core requirements is of Continuous Integration Tests that are integrated in with the development process.

  But it is, often enough, not clear that people are depending in much more than merely the notion that Because it's Open Source, naturally bags of people will want to spend their weekends testing my code.

  We badly need to have some regression tests so that some testing takes place as distributions are constructed. Debian does some of this with dpkg-related tools; it is highly unfortunate that similar tools have not cropped up around RPM.

  Question: What are you doing to help contribute to the public body of test suite code?

The name is Linux Standard Base. You can find more about them at http://www.linuxbase.org/. They have mailing lists for you to contribute. I suppose it is `taking so long' because the number of persons asking why it is taking so long is far bigger than the number of persons actively working on it.

Alejo.

I am just trying to point out that popularity some times flies in the face of logic. If we have to go with Linux, then, the LSB will be more important than ever... And, along those lines, it would mean that the LSB would be more important than standards getting in the way of development of Linux itself, because without standards, someone like Red Hat could end up being the only Linux that VAR/ISV's want anything to do with.

Hmm. Maybe it's just another reason to keep anyone who cares following the LSB, which is starting to make some "visable" progress now (compatibility testing tools...). Frankly, maybe it wouldn't be a bad thing if there get to be tons of Linux distributions, as long as thier compatiable on a basic level. It sure doesn't hurt to have lots of diffrent telephone long distance carriers, but if they weren't compatable, you could only call people that use your carrier.

Wait, Linux better be BETTER than the phone companies, that's the point of the LSB. I don't wanna see "you can't get that service unless you use brand X." If the base is the same, who cares who you get it from, I'd be happy with "Jonny Smith's Linux" that I picked up in the "impulse buy rack" at the grocery store, because I would probably end up changing what I didn't like anyway.

Personally, I have started using FreeBSD as of late, I got sick of trying to find the "right" package out of 100 diffrent packages for the same application, or tracking libraries to insure the new verson of X will run, but not break the old version of Y. I have less and less time to do that stuff anymore (approching graduation), maybe some day when I have more time, I'll go back towards Linux installs.

Ummm... If you bothered to check the LSB web site you'd see that there are 'Members' which include Caldera, SuSE, Metro Link, etc. and that there are 'Additional Participants' which are Debian and Red Hat. Now why isn't the the biggest Linux distro on the planet a 'Member' instead of an 'Additional Participant'? Vested interests? Maybe. Check your facts please. Clevo (Stampede blows the doors off Red Hat anyway - and yes I run both)

Looking at the LSB web site and I see no news of Red Hat falling off the supporters list. I don't see it there.

So, what is CNN's source? Off to the CNN artical and I read Red Hat's PRO LSB statements and quotes. I don't see it there.... Oh wait "And other Red Hat officials in recent weeks have referred to standards groups as "overhead." " Ahhh... This is the bad news? Wait a minute.

Let's see, most Buisnesses call things they have to spend money on "overhead." Not a bad thing, it's simply something needed to function. So, in a sence, it's even like saying Red Hat sees that it NEEDS the LSB to keep it's product (LINUX) alive. Without it, Red Hat would die out because of the lack of community support, and it's users would flock to any of the other dozen Linux choices (and vendors would soon follow).

So, where is the leaked internal Red Hat memo, where is the source? Where is this comming from? I don't see it. Take ONE WORD, "overhead", out of context, and do a complete "why Red Hat Sucks" spin on one out of context word from a Red Hat statement?

Bad CNN, Bad Bad Bad..... No table scraps for you tonight, go back to the dog house...

In repeated press releases and articles, RedHat has made their LSB position clear. They like the idea, they will support the process (Note that they are LSB members ), but they won't commit to complying with the standard until they actually can read a final standard.

While I would be happier if they committed to complying, I understand their reluctance, and I don't see the big deal. Once the LSB is actually out, we can lambast them if they don't comply. Until then, I think it's safe to assume that they will do the sane thing, and follow standards.

LSB Home Page

My feeling is that it is very important. I run FreeBSD, Debian, and RedHat; I'd very much like for RedHat and Debian to be more compatible, as I imagine many people would like Slackware to be, etc. There's no reason for gratuitous incompatibility -- RedHat is a bunch of nice people, but sometimes their decisions for where to put things and what to include make little sense.

A common starting point would be very good for Linux, and would really stuff it to the "fragmentation FUDrakers" once and for all.

I think Linux fragmentation isn't safe yet (not that that will stop people). Once the LSB gets finished and accepted, then fragmentation will be fine, since it won't cause as many problems for new developers.