Forgot your password?
typodupeerror
Linux Software

Linux Standard Base .9 Released 92

Posted by Hemos
from the getting-something-done dept.
Scott McNeil e-mailed me regarding Linux Standard Base releasing .9 - check out the full release of information below.

The Linux Standard Base is in the final stages of the LSB written specification for Linux. The workgroup has published the LSB v0.9 written specification, and is undergoing a 30 day Request For Comments from the public until Wednesday June 6th, 2001. Afterwards, this draft will be submitted to the Free Standards Group for adoption.

http://www.linuxbase.org/spec/lsbreview.html

The LSB is built on pieces of existing standards that are widely used by the industry and supported by the development community. These include:

  • ELF & TIS 1.2
  • FHS 2.1
  • ISO C90 & C99
  • LFS 1.5
  • POSIX.1
  • POSIX.2
  • SUS (CURSES, XBD, XCU, XNS, XSH, XSH95)
  • X base interface standards

Work is primarily being done by the development community and the major Linux distributions including Caldera/SCO, Debian, Mandrake, Red Hat, SuSE, and Trubolinux. Further contributions have come from IBM, Intel, Linuxcare, Metro Link, VA and others.

The goal of the LSB is to develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant Linux system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.

http://www.linuxbase.org/

The LSB is but one of several open source standards efforts run by the Free Standards Group, a nonprofit organization founded by community developers to accelerate the use and acceptance of open source technologies through the application, development and promotion of standards.

http://www.freestandards.org/

This discussion has been archived. No new comments can be posted.

Linux Standard Base .9 Released

Comments Filter:
  • by Anonymous Coward
    Dumbass, can you read? It says "not officially" and "de facto". Get a dictionary.
  • by Anonymous Coward
    If XML is going to be standardized, then why not have everyone switch to "standardized XML" configuration scripts? Why not make it EASY to parse, read, and LDAP/RDBMS config files? Why not have config file versioning control? By making Linux Standards Base config files all be XML, there could be a BIG win in the administration of Linux boxes. Lots of good tools could be made (GUI, CLI, RDBMS, LDAP, etc.) to take that into account. Right now, though, everyone has their own way of writing config files, so it is difficult to get everything into a database.... I have heard of people putting all of their configs in LDAP, but it would be *SO* much nicer to keep plain text files that could be manipulated by tools, etc.
  • by Anonymous Coward
    LSB standardizes on System V style init scripts. Slackware uses BSD style init scripts. The Slackware developers talked about moving to System V style, but the idea was unpopular with the user base, who considered it one of the major points of differentiation between Slackware and the other distributions.
  • by Anonymous Coward on Tuesday May 08, 2001 @06:23AM (#238075)
    In that the "Linux standard base" specifies nothing about the Linux kernel, but how userland files, system utilities, and configuration data should be layed out and installed on a file system, shouldn't this really be called a "GNU Standard Base", or at the very least, "GNU/Linux Standard Base", as this specification has far reaching implications on many of the GNU packages that make up "GNU/Linux".

    This specification actually says very little about the kernel itself other than where the boot image may reside and where the modules directory may be found, and in fact specifies nothing that need even be relevant to a Linux based GNU system at all. Substitute Hurd as the kernel, or even something else, and most of this document could still apply equally well.

  • Offtopic, karma to burn, flame-war starter:

    A discussion went on on the trip home between me and a couple of other guys from my work about RPM vs. DEB. Basically it was put forth as such:

    "Why doesn't RedHat just dump RPM and go to DEB?"

    And why not? I'm not a developer of packages, so I don't know the differences between building a deb vs rpm, but what are the technical issues surrounding converting a redhat distro to RPM.

    Yes, a lot of paths would have to change, and some other additions and subtractions would have to be made. Do debs support signing as RPMs do (or so I've heard)? No clue.

    So from a technological, NOT a religious, view, why not?

    Regarding the LSB move toward RPM (or at least indication), I think that's a very bad thing. Either put a lot of evidence and ask a lot of people which is better for linux, not for who is contributing the most $, or choose none at all.

    Yes, I'm a debian user and have been for about 5 years now. I've played with redhat and mandrake) on occasion, and my experiences have been not good, not to do with the install (awsome) or the system (not what I'm used to but nothing wrong with it) but with RPM.

    IE: I need to install rpm of package foo. Get package foo, try to install. unmet dependancies, get dependancies, install them, get more unmet dependancies. bitch on irc. Someone suggested using rpmfind. get rpmfind rpm, install, get unmet dependancies.... continue until hands were thrown up in the air and I gave up.

    Now that's my experience, and as a debian user I don't know all the cool places to get the rpms I need, just as a redhat user when thrown in front of a debian box probably wouldn't know how to set up a sources.list from scratch or where to get xyz information. But I digress :)

    Basically I think that deb, while still not 100% (signing, ssl support, plus whatever features it still needs to make it feature for feature the same as RPM), is still better than RPM as far as functionality. My vote is to either

    a) make a judement based on technology
    b) make no judement at all (which they've done)
    c) don't lean one way or the other (which they've done)
  • Well, --nodeps works fine if it's the RPM being a PITA, but if the dependancies are actually needed...

    Besides, this is the Wrong Way(tm) to do it. I remember talking to the Helix Code guys at the last LWE I went to and how they shuddered every time someone "fixed" their install problems by just doing --no-deps.

    Besides, wouldn't it make more sense to make a better distrobution mechanism so that the automatic response for people who have RPM problems is something other than --no-deps? I've used --force-depandancies exactly 0 times since I started using debian, and --force-overwrite approxitely 10 (for unstable packages that I was playing with).

    This is why I'm bitching about RPM :)
  • IE: I need to install rpm of package foo. Get package foo, try to install. unmet dependancies, get dependancies, install them, get more unmet dependancies. bitch on irc. Someone suggested using rpmfind. get rpmfind rpm, install, get unmet dependancies.... continue until hands were thrown up in the air and I gave up.

    rpm foo.rpm -Uvh --nodeps :)

  • Doesn't Conectiva have rpm-based apt?
  • The whole idea behind the LSB is to provide for a predictable minumum functionality.

    While it may be nice to have a whole bunch of bells and whistles like Java specifications and thouroghly debated package managers, it's more important to get a least common denominator first working draft on the table now.

    Let's have some orderly anarchy here ok? :)
  • I think Linux should migrate to using Donald Knuth's METAFONT for all its font needs. ;-)

    -Paul Komarek
  • by Kostya (1146) on Tuesday May 08, 2001 @06:34AM (#238082) Homepage Journal
    I see that C90 and C99 are used in the LSB (or drawn from). What about ISO C++?

    (please note at this time, if you are going to post a "C rocks! We don't need no stinkin' C--!" please don't. I could care less what you think about the C/C++ holy wars raged by various loonies)

    C++ is heavily used in the industry, and especially in Windows shops. If Linux industries want to steal that developer-share from Windows, they need to hammer out what C++ libs and standards compliance will be considered a part of "standards compliance" linux.

    Is the absence of C++ standards due to gcc not having a ISO C++ compliant release? I know that 3.0 is in the works and that Red Hat ships a snapshot of GCC in an attempt to get better libstdc++. Is this lack of a viable free option the reason for no C++ standardization?

  • Debian definately is the only one with FREE automatic upgrading.

    Now see that's a feature I'd be willing to pay for. Debian has a great service contract option with the automatic updates.

  • "The intent is to in the future replace this format with a new format currently being developed." Anyone know what the new format is. All they really need to do is specify what the /var/lib/packages unified format is. Then rpm and apt-get could be modified to use the new unified format. And you can use either tool, and possibly even the old .rpm and .deb files.
  • AND, you can still roll your own. They haven't made a nice lil /etc/roll_your_own_compiler_defaults yet, which would be cool cause then you could just dump in -O6 and other goodies.

    -l
  • The *BSD family's /usr/ports/ is a great idea and works great in practice. The source is brought in, dependancies as needed, and compiled for your box (See http://www.freebsd.org/ports/ for more info on that)

    Few questions (I really don't know the answers):

    • Does the ports system allow for removal of a package and all it's files?
    • Can you query a package to find out if files have been modified?
    • How are the dependencies defined?
  • Excellent idea!

    Somebody asked about designing it. Well here goes:

    Fonts are stored in /usr/share/fonts and /usr/local/share/fonts. FreeType, GhostScript, X, and all other programs that load fonts are modified to look for all their files there.

    The files are all of the form .. is a USER FRIENDLY name that can easily be typed and rememberd. The extension is used to distinguish various incompatable font formats, or different transformatons of image-based font formats. Systems that don't understand an extension ignore those files as though they are not there.

    Fonts may also be stored in subdirectories, but in this case the "name" has slashes in it, so the services can just consider them normal file names.

    Font files are found by a service taking the user-friendly name (X servers will have to extract a few fields from the ugly X name to get this) and tacking on each extension the service understands and checking if the file is there. There is no need to use readdir to get a specific named font. Services can assumme that once they see a font, that file will not be changed or disappear, although they may want to check the date stamp every now or then.

    Services that need to search for fonts will have to recursively readdir the entire directory tree. They should be written so they don't do this on startup but instead delay it at least until the first font is requested. They should record the datestamp of the root directories and rerun the search if it has changed. Services are allowed to create their own cache files but they should create them in some other directory, as they may have read-only access to the font directories.

    Multiple names for the same font (like "Ariel" or "helvetica" for "Helvetica") are done with symbolic links.

    Yes it is quite likely that the first implementations will ignore each other's fonts. I expect they will gradually start to read each other, and that obsolete formats will disappear, and eventually there will be one file for each font.

  • Whoops. Yep, better use that preview button.

    Okay, the files should be of the form [name].[extension]. [name] is a user friendly name, ie something that a person of average intelligence may type, like "Helvetica". An example of a non-user-friendly name, which is not allowed under my design, is "adobe-helvetica-bold-normal-p".

    [extension] is the user-unfriendly part and each font using service looks for a set of extensions it understands. Examples are "pfa", "ttf", and maybe "xfont.25.25" for an x bitmapped font that is designed for a pixel size of 25 vertically and 25 horizontally.

  • Just chop off nine fingers and one fingernail.
    --G
  • I think that the whole packaging issue is quite a problem.

    I would also like to point out that one of the earlier threads on the "de facto" status of RPM in the standard was marked as a "(-1 Troll)". If people aren't open to this kinda of discussion, progress won't be made, and we might as well go back to bowining to the great satan of software.

    I personally think REDHAT has a large investment in the automatic updating through their "redhat netowrk" and apt-get very much threatens that cash source. I think that is one of the reasons that the .deb format is played down.
  • And what major distrobution supports this?

    Debian definately is the only one with FREE automatic upgrading.
  • same question as above.

    What major distrobution supports this?
  • I'll give you the spec files, but that is an advantage for the author, how about for a user. Why should an end user care about this?

    Yes apt-get has been made to work with rpm, but what distro has decided to set this up for their users to use it. Certainly not Redhat, they are trying to make money on the service (not that they shouldn't make money, I just quesiton if this is a good way).

    I agree with your long run conclusion, and I agree that it will be hard. The most annoying thing about RPMS for me, is that it is ESPECIALLY hard to find RPM files to fill dependancies when you take the RPM from a third party source. (NOTE: RH network is not a solve for this... as it costs cash. Using an IS person to look things up is also a solution for this, but I didn't use it either as it also costs cash.)

    Debian also may create some dependancy problems, but at least it tells me, so I don't spend forever looking for the file to make everything work.

    I'm not against paying for things, but quesiton wheather this is a good way of going about things

    It seems alot of companies are setting themselves up to use this method (ximian, nautilus, redhat, microsoft.) I am not against subscription service, but subscription updates, are questinoable as a method for making money, in my opinion.

    I look forward to seeing what other services are started as subscription (but I only see this coming from ximian and nautilus, and I'm sure they will have differant systems, and not be on friendly terms.)

    It would seem to me these companies would do better to offer subscription support and then use a common, open source, subscription service for added features (remote backup, remote CPU power).

    The reason I see the open source business model (and the free software model) working is that 80% of most software projects spend 80% of their time in the support/update phase of a project.

    IBM/Aurther Anderson/E&R/Deloit and Touch(or whatever it is) all know this. Micro$oft knows this, but wants to charge you incredible amounts of money for it.

    I re-iterate, I do like redhat and some things they do. This rant makes me sound harder on them than I am.
  • yes...
    de facto - In reality or fact; actually.

    This debate wouldn't exist if it were in fact the standard.
  • He's not a dumbass,
    De Facto means "in fact".

    While De Facto can mean unofficially, it meaning has a connotation that would imply that it is more factually corret. (for example a De Facto governemt might not correspond with the legal government, but is IN FACT where the power lies) Why do programmers always overlook the connotatino of words?

    I imagine there are lots of non-RPM users who would like to dispute this "fact".
  • If this is actualy true, that RPM's are "in fact" the standard, why is this debate occuring?

    Based on my experience, as I said above, RPM's USED to be alot more prevalent than they used to.
    Maybe once upon a time they were the defacto standard, but alot of projects seem to be providing .debs now too.

    Windows was once upon a time the "De Facto" operating system for PC's, I think you would agree that they are loosing this status, can't claim this completely any more. I believe RPM's fit in this category.

    As for naming things after the distrobution, where did the name Redhat Package Manager come from?

    Since it has been about a day, I've had some time to think about it. I guess I'll send in my comment asking that they, at least point out that if you make sure your RPM's works with alien it will help the .deb distro's, and it would cool some people's ire (including mine), if they would change the wording from "DeFacto", to "most prevalent".

    Now I just have to go fill out the form.

    BTW to whoever it was that was trying to dismiss these comments by pointing out that we hadn't been part of the whole debate and what not... Why did they ask for public comments if they didn't want this type of conversation to take place?

    Focus on the solution, not the problem!
    (but I'll still be surprized if a new packaging system comes out that really helps everybody)
  • Debian, Libranet, Progeny, as well as two other distros that don't exist any more., use Debs and APT get, That's great, but OT. APT get isn't easier to use than RPMs, its easier to use than up2date, merely because there's no mirrors or vast quantities of unsupported packages. Which can be fixed pretty easily.

    ok.. I'll accept some of thse facts

    Mandrake and Connective also use APT, and Mandrake likely has more users than all the other distros mentioned here combined.
    But does it work with RPM v3? (the one used in the document)

    Every Red Hat machine can update packages with automatic dependencies.
    As pointed out below, can you suggest or recommend? How? And do I have to pay to get this to happen with Redhat? (honest questions)

    There is nothing specifically tying APT to Deb. However, there are far more than 4500 RPMs that are actively maintained, and far more users of RPM based distributions.
    Agreed, if somebody had another distrobution that could do all the package-updating that debian can, I would listen. (As for the 4500, I can make alot of crappy Packages to inflate my package count number too)

    All this is beside the point, my point is that the phrase "de Facto" should be "most prevalent", and it would do them some good to mention "alien" and .deb, to give a full picture in the standard. Afterall, as they point out, there is no standard. Why not give a full picture of the situation instead of being one sided?

    How would you feel if somebody said "Windows is the De Facto OS on the PC" and didn't mention anything about Linux/BSD? Especially in a document that was supposed to set a standard for the PC?
  • Why did they ask for public comments if they didn't want conversation like this to happen? Even if it is from people who haven't looked at the problem for as long?

    "Stop shoooting your mouth off" is the call of a person who either dosen't want to debate, or dosen't have the knowledge to do so. You seem knowledgable, so I'm going to assume (and hope) that you simply are tired of the debate. If this is true.. that's fine.. don't participate.
  • Wow.. thats interesting.. Personally, I had heard of Debian before I'd heard of RedHat (yes I was using back then.. yes I started with slackware).

    As I've pointed out elsewhere, what I would propose is replacing "de Facto" with "prevalent" (as that would not have the "corrective" connotation). It would take care of this kinda "who's older and bigger" war.

    Mention a few of the other packaging formats (including deb) and point out that making sure your rpm works with alien can indeed make you even MORE compatable with more distros. (after all, interoperability is what this is all about, isn't it?)

    Does the redhat network feel threatened by things like apt-get? (honest question.. I said that I thought that above, but I'd be curious to know what an actual person from the company would say.)
  • They should point this out in the document.
    Understanding why a standard is the standard is almost as important as the standard itself.
    (if I say standard one more time... DOH.. too late :) )

  • Is a standard always set by the majority?
    Is Windows the standard PC Operating System?
  • I'll have to check that out.

    The thing I'd point out is that after seeing some of the intent it is clear that some of my questions are inflamitory (this can be said without even looking at the FAQ yet), having looked at the standard I found no statemnet of intent in the introduction, and found words that had heavy negative connotation in the document wrt packaging.

    If I'm representative of folk that are not part of the project, but interested in the issues, it would behove you to at least provide a statment of intent. This would show us dimwits, who haven't been paying attention, that one part of the community is not trying to pull something over on the other side.

    With the recent tactics of MicroSoft, trying to drive a line down the middle between the Free Software types and the Open Source types, it is probably very important to get the politics right, as well as the standard itself.
  • So with rpm 3 or 4 I can get the full functionality of apt-get (recommends, suggests.. and all?) Also, somewhere somebody should explain that these RPMS can work with alien.

    Up2date free for one machine.. as apposed to apt-get free for 0 to infinity machines... that's a tough choice.

    As for the 4500, I was refering to the fact that you said there were more than 4500 RPM's. Half of them don't install easily is my experience (thus my comment about being able to make crappy packages to inflate my count too).

    Ease of use should be just as heavily weighted as a determinig factor, as this is what keeps or looses beginnning end-users.
  • by Yohahn (8680) on Tuesday May 08, 2001 @06:25AM (#238104) Homepage
    I agree, while they point out there is no standard, they do not back up their reasoning for using RPM as the supposedly "de facto" standard.

    As RPM is the reason I originally left redhat to go to debian, I would suggest that they should either support their claim, or they shuold remove the suggestion.

    In practicality, RPM used to be alot more dominant, I find that alot more projects are supporting .debs than used to.

    I think Redhat is trying to promote its "redhat network" as sees Debian's apt-get as a significant problem.

    I normally do not like to talk about distribution being against distribution, but in this case it has already been done and I am just pointing it out.

    I use Redhat in some cases and appreciate all that they do. I just see this as obvious manipulation.
  • by Logger (9214) on Tuesday May 08, 2001 @06:14AM (#238105) Homepage
    1. a standard location for fonts
    2. a standard lib that renders the fonts that
    a. X Windows uses
    b. ghostscript uses
    c. anything else uses (StarOffice, Tex ?)
    3. anti-alias support (yes, X4.0.2 has this, but you have to explicitly use it)
    4. You don't have to do anything other than copy a font file to the aformentioned standard location to get it recognized by everything!
    5. Maybe, an extensible font library, supporting some sort of plugin architecture for adding new font formats.
  • I've hated RPM since day one.

    Getting a tarball and making it yourself is the best way to do it on Linux

    The *BSD family's /usr/ports/ is a great idea and works great in practice. The source is brought in, dependancies as needed, and compiled for your box (See http://www.freebsd.org/ports/ for more info on that)

  • by Azog (20907) on Tuesday May 08, 2001 @08:05AM (#238107) Homepage
    You are correct - the reason that the kernel is not specified is that applications do not (normally) depend on the kernel. Perhaps a better name for the Linux Standard Base would be the "Gnu + X11 + Filesystem Layout Standard Base" but lets be realistic, it's going to be Linux kernels in there for a while. On the other hand, a specification like this should make it easier for alternate kernels to be accepted - if the Hurd can be used to make an LSB-compliant system, that should accelerate it's acceptance.

    The point of the LSB is so that big companies can write applications and installers that will run and install on any LSB-compliant system. This is a good thing, otherwise we will continue to get applications that are "supported on Red Hat Linux 6.2" only.

    The key parts to the specification seem to be the Gnu C Library (although a different C library could probably be made to work) and X11. I am happy to see that an OpenGL library is part of the spec! This should make it much easier for 3D games to work on any Linux system without all the messing around that you have to go through now.

    Hopefully in the next version they will specify:

    1. Fonts - how to use them, where to keep them.
    2. X Extensions - X Render, for example
    3. Audio

    And maybe in future versions they can nail down the locations of configuration files. Beware of the inevitable holy war over init scripts... Probably the best thing about this spec is that it will make management happier about Linux, and make it harder for Microsoft to FUD about Linux fragementing.


    Torrey Hoffman (Azog)
  • Come on, d00d! We don't need no C--! Code in C only!!11!

    Sorry, couldn't resist...

    What do I do, when it seems I relate to Judas more than You?

  • Uhm, for printing pourpouses, TT is not better than Adobe Type 1, and also there is the not-so-little inconvenience of TT font makers being expecially creative when it comes to give the right name to glyphs (instead of following the Adobe convention). Peple having to live with iso-8859-1/2/15 instead of plain US-ASCII perhaps can understand it better.

    BTW, Ghostscript already comes with an high quality replacement for standard Postscript fonts (the URW fonts), which can be readily used with XFree since they are common Adobe Type 1 (this is explained in better detail somewhere in the Font-deuglification-howto).

    If I understood it correctly, a major TrueType feature that Adobe Type 1 fonts don't have is the presence of hints for rendering glyphs at small sizes (or low resolutions), but I doubt they can be used in a free TT font renderer, since there should be patents on them. But using the bitmapped versions for exact size matches and the vectorial versions in the other cases gives you the same result... and XFree allows you do to this automatically (again, follow the instructions within the URW fonts).

    Putting every font file in a known place is going to leave unsolved a part of the problem, because this wont't work if you use a centralized X font server (and install noncommon fonts only on the machine running it). Here I'd really prefer an extension to the X Font Server protocol.

    About fonts.alias: it isn't really needed at all, but it's there if you need it. fonts.dir OTOH is something we could easily get rid of, since all font files commonly used today already contain the needed information, but then, it's only a matter of running mkfontdir each time the X font server is started...

  • What gets me is that the two formats being discussed are named after a particular distribution (DEBian and Redhat).

    Indeed choosing one over the other would give substantial credibility of a distribution as being "the standard" distro.

  • I agree, while they point out there is no standard, they do not back up their reasoning for using RPM as the supposedly "de facto" standard.

    From dictionary.com -

    de facto adj : existing in fact whether with lawful authority or not

    There's no "supposedly" about it - RPM is the de facto standard.

    And yes - .debs rock my world and yours. And if they hadn't named the fool things after the distribution, more Linux distros would probably have picked them up by now.

  • The idea is, Debian should just drop .deb packaging and catch up with the ease, power and user base of RPM.

    thats just it. i've used both and i would agree that rpm has a larger user base but i would dissagree with the power and ease assertations. apt-get is much more powerful and easy to use in my opinon. for this reason i think it should be given more consideration. if you do things based on sheer numbers then everyone should use microsoft since they have a larger market share.

    use LaTeX? want an online reference manager that
  • i'm not shooting my mouth off. i didnt slander rpm's or redhat. i simply stated my preferences and concerns.

    so what is the new packaging system? i wish they would have provided a link or some other information.

    use LaTeX? want an online reference manager that
  • by gimpboy (34912) <john...m...harrold@@@gmail...com> on Tuesday May 08, 2001 @06:13AM (#238114) Homepage
    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 [linuxbase.org]

    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
  • by devphil (51341) on Tuesday May 08, 2001 @12:43PM (#238115) Homepage


    ...because those maintainers in a position of authority (mostly the Steering Committee) have been too busy getting 3.0 ready for release. Herb Sutter had contacted the GCC list but apparently got no reply.

    As you can see, as far as compliance goes, Gnu C++ is pretty good for a compiler, but is lacking in the library department. I find it interesting, and I'm sure the GNU C++ team is looking at the numbers, considering how important the library is to the standard (it really does make C++ more powerful).

    The last releases, 2.95.x, as well as RH's snapshot-based spinoff of 2.96, all shipped with the old, nonstandard, noncompliant v2 C++ library, which has been mostly unmaintained for years.

    Everybody's been working on the rewritten-from-scratch v3 C++ library, which has ISO compliance as its primary goal and criteria. If you get one of the nightly 3.0 build snapshot RPMS [codesourcery.com], you'll find that the new C++ library is the default.

    When will 3.0 be released? Sooner, if you help [gnu.org].

  • De Facto: 4 (RedHat, Suse, Caldera, Turbolinux) out of 6 (+Debian, +Slackware) major Linux distributions use RPM.

    It simply states that more Linux boxen have RPM than DEB.
  • You obviously don't have a clue about Debian packages or RPM packages. Debian packages are *much* more complex than RPMs. I've designed both. As a developer, RPMs are easier to make, but as a user, I would go to Slackware or a roll-my-own distro before I would ever go back to an RPM-based distribution.

    The Debian zealots are right. RPM does suck compared to dpkg. (Both have deficiencies, however).
    ------
    I'm an assembly guru ... What's a stack?

  • How can you get a RPM to "Recommends:" or "Suggests:" other packages? I can't seem to find it in the manuals.
    ------
    I'm an assembly guru ... What's a stack?
  • Your statement was that dpkg "is about as good as RPM". This is false, as dpkg is significantly more advanced. I'll flame people who post "facts" without researching them first, if you don't mind.
    ------
    I'm an assembly guru ... What's a stack?
  • The Progeny team is participating in the Open Packages effort. We may end up seeing ports in Linux as well.
  • The files are all of the form .. is a USER FRIENDLY name that can easily be typed and rememberd.

    Indeed, easy to type - no typing at all required! :)

    Use the Preview Button! Check those URLs! Don't forget the http://! etc.
  • How about standardizing on TrueType fonts. Plain and simple.

    some basic free TT fonts would have to be found for distribution with Linux systems, of course. it would be enough (for me) to ship with a Times clone, a Helvetica clone, a Courier clone and a symbol/icon font.

    Support for Adobe Type1 scalable fonts should be optionally included, but most of the bitmap, BitStream and other crappy fonts just plain suck.

    Theres no reason you couldn't also have support for these fonts, but a single font folder which doesn't require creating fonts.alias and fonts.dir files would be good.

    Does anyone think Linux's font handling is in any way better than that of Windows or the Mac?

  • Theres nothing to stop you changing the way fonts are handled i.e. with a central server, but a reasonable default for a desktop workstation/small server should be adopted, i think.

    Whether TrueType is 'better' than Type1 is not the central issue, as i see it.

    I just want to see a simple default font handling system that gives good output on screen and print.

    If i want to tweak my font handling to use Type1 fonts to give perfect printed output, then thats fine, but it is extremely painful to fire up some program like Konqueror and see absolutely hideous looking fonts.

    Why do they look hideous? I don't know.. Mozilla's fonts look fine, all my other programs are OK.. Reading the X deuglification FAQ is no help, since it doesn't cover xfs-based setups etc. DrakFont (i use Mandrake) seems good, but its an application, not a standard.

    Windows and MacOS make this stuff so simple, yet font handling in X seems incredibly involved and tricky.

    Simple, reasonable defaults would be a big step for usability on the desktop.

  • by joq (63625) on Tuesday May 08, 2001 @06:18AM (#238124) Homepage Journal
    That this project doesn't go astray or become another one of the 10,546,673,132,895,345,923,566 neat sounding projects to bring the hopes of Linux users only to falter somewhere down the line due to ego's, vendor differences in opinion, lack of insight, etc.

    Well not to be a troll or say something out of place to the Linux users out there, but I think at this point Corel can come off that page (you think) lets start things on the right foot with an up-to-date site.


  • Debians packaging system is .deb. Its about as good as RPM. Some people say Debian packages ae easier to create, others think RPM has much better package verification options.

    APT...
    * Is designed to cross platform and packaging system independepndent
    * Is both, as of about half a year now.
    * Currently popular on Debian and Progeny,also avaliable on Mandrake 8 (this distribution likely has a larger installed base than Debian) and Connectiva.

    Compare Deb to RPM, and the difference isn;t that much. There ARE more RPMs about - yes, more than the 4500 deb packages. In case Debian users didn't realize this, their distribution only includes free software. Sometimes commercial software (shock-horror!) is the best tool for the job, and in most cases, Deb's don't exist.

    LSB will go RPM. Its inevitable. And every single RPM based distro will have APT or APT like capabilities within a year.
  • The source is brought in, dependancies as needed,
    and compiled for your box (See http://www.freebsd.org/ports/ for more info on that)


    SRPMs can do the build part for you, and better still, standardize it. All you'd need is a large repository of unsupported RPMs, and a version of up2date to do it. If enough people wanted it, I'm sure its possible.

  • IE: I need to install rpm of package foo. Get package foo, try to install. unmet dependancies, get dependancies, install them, get more unmet dependancies. bitch on irc.

    Agreed 100%. But this isn't an RPM complaint and has very little to do with RPM versus Deb packaging formats. They're to do with add on tools and where software is hosted.

    Automatic dependencies are already sorted out via up2date. What you need is a large repository of unsupported packages designed to work with your distribution.

    I'd like to start something myself in this area. Anyone want to lend me a hand?

  • You still don't respond - APT isn't Debian specific and was designed to be independent of packaging systems.

    Debian, Libranet, Progeny, as well as two other distros that don't exist any more., use Debs and APT get, That's great, but OT. APT get isn't easier to use than RPMs, its easier to use than up2date, merely because there's no mirrors or vast quantities of unsupported packages. Which can be fixed pretty easily.

    Mandrake and Connective also use APT, and Mandrake likely has more users than all the other distros mentioned here combined.

    Every Red Hat machine can update packages with automatic dependencies.

    There is nothing specifically tying APT to Deb. However, there are far more than 4500 RPMs that are actively maintained, and far more users of RPM based distributions.
  • userland files, system utilities, and configuration data

    Known by most peeple as the Linux operating system, OS being defined by most people as `the program that loads when I start my computer'.

    shouldn't this really be called a "GNU Standard Base", or at the very least, "GNU/Linux Standard Base

    No, IMO it should not, as there are many others contributors to this OS who put in effort other than the GNU project, and Richard Stallman has no right claiming to be the `maintainer' of the OS as if such a maintainer actually existed. Firstly that assumes the only software ones uses is the shell and GNU utilties. This is extremely uncommon, and ignores folk who who choose a different layer of abstraction (say, KDE, which is not produced by the FSF).

  • You obviously don't have a clue about Debian packages or RPM packages

    You're obviously a weak pathetic fool who responds to something you find innacurate by flaming the person that posted it. That's okay, I do too... you stupid little itch.

    I make RPMs of everything I install and fix broken SRPMS when I encounter them, thank you very much. I do indeed know little about building Debs other than that a few knowledgable people have said building Debs was easier.

    But did I say anything definitibe myself? No, I was discussing what others say. How in any logical way can you know this to be innacurate? Have you been following me and know for sure that I have not encountered anyone else that has these opinions.

    Thanks you also for providing supporting arguments for your final statement too.
  • But does it work with RPM v3? (the one used in the document)

    Yes. RPM 3.05 can install all RPM 4.x packages - the main advantage of RPM 4 is transaction support in the RPM database (somethign which .deb. doesn't have).

    As pointed out below, can you suggest or recommend?

    Using up2date, a CLU / GUI app that comes with Red Hat since 6.2 (but is updated quite frequently itself)

    And do I have to pay to get this to happen with Redhat?

    For one machine, its free. For multiples, you should theoretically subscribe (ie pay, but you can simply create a new profile on the Red Hat Network. Or point the second machine at the firsts list of archives and freshen them.

    As for the 4500, I can make alot of crappy Packages to inflate my package count number too)

    Um, that's actually the number of maintained Debian packages :I was referring to :-). But yes, quality counts no matter what system is used.

    Windows is the De Facto OS on the PC" and didn't mention anything about Linux/BSD

    Yes, popularity isn't the reason to adopt something, but when two packaging systems offer a very similar rnage of capabilities with no clear advantage, its a definite consideration.
  • I see no reference whatsoever to Linuxone! [linuxone.net] I always thought LinuxOne(TM) was working to become the highest rated supplier of Linux solutions based on packaging, support, and product capabilities in the global market

    Ok, I'm being silly. I need more coffee

  • by mr (88570)
    Yes, well heaven forbid that we be INCLUSIVE...its better to be a linux-only-zealot and if they ain't running some version of the Linux kernel, it is garbage.

    Embracing Solaris/BSD/the Linux layer on Windows would give a 100% effective coverage.

    But, the LSB crowd doesn't see things that way.
  • I remember reading somewhere some time ago that Slackware boycotts this standard, but does anyone know why? I couldn't find anything about it in the FAQs on www.slackware.com.

    -Karl
  • They all use it already - (except Debian (deb) w/recent derivatives (only Progeny is currently active, AFAIR - Corel has stopped, Stormix is broke) and Slackware (no real package system)).

    Among the current users are Red Hat Linux, Mandrake, SuSE, Turbo, Caldera, Immunix, Trustix, Connectiva and all of the derivatives of Red Hat Linux.

  • All of the above has been around for some time, and the userbase of Red Hat Linux, Mandrake and SuSE is much bigger than Debian.
  • I started using Red Hat Linux in '95, and it wasn't the first release of RHL - Debian wasn't out with 1.0 (actually 1.1) at the time, and was insignificant: The big distro at the time was Slackware. The other major distros have also been around for some time - some spinoffs are a bit newer (like Connectiva and Mandrake).
  • Speaking of the other old ones: Caldera was Red Hat Linux with proprietary add-ons at that time - they had Looking Glass, a weird desktop thing. The oldtimers around here always wonder how Caldera, with so much money and many people at the time managed to become what they are (a company with revenue of about $1 million, spending $10 million to get there).

    As for the packaging format: One of the main reasons for the LSB is to give a vendor/packager the possibility of creating one package and then have it run on "Linux". Specifying multiple package formats doesn't help to reach that goal... Note that being able to use it everywhere is important, so only a subset of RPM functionality can be used (so alien can convert to other package formats (well, .deb - .tgz isn't really sufficient) without loosing functionality required by the package). An example of excluded functionality is triggers.

  • Not quite. RPM has a couple of advantages over debs, as well. Take a look at package building, for example. At least IMO, writing an RPM spec file is much quicker than writing all the files for a debian package. (Actually, the package manager was one of the main reasons why I based my own distribution on Red Hat Linux rather than Debian, which was long before I joined Red Hat.)

    Yes, apt-get is nice (and has been ported to work with rpm).

    In the long run, I think the best solution is to create a new package manager with the advantages of both systems (hard to do, though, since they follow very different philosophies on some things). It should have a unified package format, but also handle both "old" RPMs and "old" .debs.
  • pkg_delete removes package and all files, which has been listed in pkg_plist file (%files section in RPM spec). From what I've understood, this means all files except configuration files, because they are not listed in pkg_plist (at least thats what porters handbook used to recommend). So in Debian terminology, you can remove, but you can't purge package.

    pkg_info has option (-g), which will show files, which checksum doesn't match with recorded checksum.

    What comes to dependencies, there are more than one kind of dependencies. There are dependencies that are required for building the package, there are dependencies that are required to run the programs that package provides, etc.. All dependencies are described by telling required file and port, which has that file, i.e. you could list /usr/local/bin/mutt as required file and mail/mutt as port, which has to be installed, if /usr/local/bin/mutt doesn't exist. When you are building port with make install, make file will automatically install all ports, which your port requires.


  • 4-1. ELF Special Sections

    So sure there is a standard to put "special" elvens into, but what about the not so special elven?

    All your [Linux Standard] bases are belong to us*

    *us is defined as:
    Including but not limited to Caldera/SCO, Debian, Mandrake, Red Hat, SuSE, and Trubolinux. IBM, Intel, Linuxcare, Metro Link, VA and others.


  • Debian, Libranet, Stormix, Progeny, Corel, and other distros support the deb package system and apt-get. Anyone who has actually used a Debian based distro on a regular basis will tell you that apt-get is far more powerful and easier to use than RPMs. It is easier to install software on a Debian distro than it is to install software on Windows 2000! In fact, installing software is so easy with apt-get, that you might think for a second that you were using a Mac.
  • Ideal slogan: All your Linux are Belong to Us!
  • The above is a little too convuluted ;-) Will this make development on Linux systems earlier, or is this just an effort to collectively index common linux libraries?
  • Programmers who wish to produce binary applications that will run on any LSB-conforming implementation should follow this procedure:

    Link your binary application with the LSB's filter libraries found in /usr/lsb/lib to determine at compile time if your application is using only LSB defined APIs.

    Link your binary application with the LSB /lib/ld-lsb.so.1 dynamic linker/loader.

    Verify your binary application with the LSB's /usr/bin/lsbappchk tool to determine at runtime if your application is using only LSB defined APIs.

    If people start writing their programs to comply to this binary compatibility will be something I would consider doing, instead of compiling from source. They guy down my hall who installed linux and asks me questions every time he trys to install software (since they all install differently) could leave me the heck alone. It would be good no matter how you look at it.

  • who really cares how it's packaged? If the filesystem layout gets standardised, then I would assume that the files will end up in the same place regardless of the package format used.

    Once the filesystem is standard, the package manager ceases to be a method of forcing incompatibility and little more than a database-backed archiver. I don't recall anyone whinging too hard about gzip, zip, bzip2, arj, rar, etc..
  • If this is actualy true, that RPM's are "in fact" the standard, why is this debate occuring?

    There are more RPM users than DEB users, but the Debian people are notoriously vocal, therefore giving the appearance of a multitude.

    ------
    C'mon, flame me!

  • Is a standard always set by the majority?
    Is Windows the standard PC Operating System?
    Sorry, it pains me to say it, but yes it is.

    That's why every peripheral on the planet is shipped with Windows drivers, and why we have to beg, cajole, or reverse engineer to get Linux drivers.

    Its well known that Beta is a technologically superior format to VHS, but the weight of the majority states that you are going to use VHS. Sorry Sony, game over for the Betamax.

    Same thing here, we would be better off improving RPM and making it a more agreeable standard.

    This is not the same as the people who foolishly argue about consolidating KDE and GNOME or dropping one alltoghether.

    This is about making a unified package system for all distributions, so that Joe User can download a package, fireup his favorite InstallShield-like tool from KDE, Gnome, WM, [insert your WM here] to quickly install it, without worrying if it will be installed in a wrong location, or if it will bitch about a dependency that you _do_ have installed.

    Of course, if we are going to standarize on something, lets change the name of it so that it becomes distro-agnostic.
    I suggest .lsp (linux standard package)

    ------
    C'mon, flame me!

  • I hadn't heard of this, it is a good idea. The only question is how well they promote the idea. Cause no good idea ever gets very far without some good promotion. So if you are interested in this getting paid attention to, please promote it.

    Does it ever seem like the world will collapse from the weight of standards to you? It does to me.
  • Bloody good thing too.....<P>
    Fragmentation if one thing that stands in the way of people accepting Linux as a desktop alternative - although there are sadly plenty of people who when they think of Linux think RedHat, as it's they're the vendor they've heard of.
    <P>
    If we can guarantee that our programs will run on any "compliant" system, that's surely a good thing. I'm troubled by the compliance tag, though. I'll have to read up and find out what <I>exactly</I> that means. Overall, this can't be bad.<P>
    Tom.
  • C++ is heavily used in the industry, and especially in Windows shops. If Linux industries want to steal that developer-share from Windows, they need to hammer out what C++ libs and standards compliance will be considered a part of "standards compliance" linux.

    Is the absence of C++ standards due to gcc not having a ISO C++ compliant release? I know that 3.0 is in the works and that Red Hat ships a snapshot of GCC in an attempt to get better libstdc++. Is this lack of a viable free option the reason for no C++ standardization?

    I'm grabbing my copy of C/C++ User's Journal, April 2001, which had a Compiler Conformance check (see it online [cuj.com]). They have always avoided rating compilers, but now that there is a standard, they decided there was now a somewhat objective means to judging a compiler - conformance to standards. They go on for about 5 pages, explaining the tests and giving justifications for testing. The folks who create the test suites get to comment, the folks who wrote the compiler get to comment, and it looks like everyone involved will work toward meeting the standard in the next release.

    Gnu gcc 2.95.2 was tested, as well as Borland BCC 5.5, Microsoft's Visual C++ 6.0, Intel's C/C++ 4.5, as well as 6 others. While just about everyone else commented on the results, there was no spokeperson for gcc.

    You'll have to go to the web-site for full results, but here's a few. Three test suites were used, from Dinkumware, Perennial, and Plum Hall. The compiler was tested as well as the library, and results were given as percentage compliance.

    Borland
    Dinkumware: library - 75%
    Perennial: compiler - 63%, library - 67%
    Plum Hall: compiler - 89%, library - 74%

    Gnu C++
    Dinkumware: not tested
    Perennial: compiler - 98%, library - 41%
    Plum Hall: compiler - 94%, library - 21%

    IBM C++
    Dinkumware: library - 99%
    Perennial: compiler - 99%, library - 97%
    Plum Hall: compiler - 95%, library - 85%

    Intel
    Dinkumware: not tested
    Perennial: compiler - 96%, library - 72%
    Plum Hall: compiler - 90%

    Microsoft
    Dinkumware: library - 84%
    Perennial: compiler - 77%, library - 64%
    Plum Hall: compiler - 83%, library - 74%

    You can look up the other number if you so desire.

    As you can see, as far as compliance goes, Gnu C++ is pretty good for a compiler, but is lacking in the library department. I find it interesting, and I'm sure the GNU C++ team is looking at the numbers, considering how important the library is to the standard (it really does make C++ more powerful).

  • Why not have the standard include specifications for multiple packages? When the system is installed, the user could select the default installer to use. Just make sure that the specification is easily extensible so that newer package formats can be added so that older systems won't be forced to upgrade.
  • by phaze3000 (204500) on Tuesday May 08, 2001 @06:12AM (#238153) Homepage
    Like it says above, it's an effort to standardise Linux distributions' layout, with an aim to ease the use of applications across distributions. It has a standard set of directories which should be used for things like config files and documentation.

    --
  • the "open source" model will fail

    I get really fed-up with all those people who keep screaming about how the Open Source model will fail. Look around you, its thriving not failing!

  • GNU/Hurd has a terrrible filesystem "standard". They are trying to eliminate /usr. I wish that the GNU/Hurd team reconciders - then "Linux Standard Base" could indeed become "GNU Standards Base"
  • by BlowCat (216402) on Tuesday May 08, 2001 @06:25AM (#238156)
    How about a standardized font system?
    One should
    design and implement it first. If it works well and many applications support it then it may be a good candidate for a standard.
  • Like, great if we get a standards base, but how is it going to be USED? Will RedHat, Suse, Debian, etc. offer us a bare-bones LSB install, without all the extras? Will people working on important projects offer a special implementation for people with LSB setups? Will it finally be feasible to have an InstallShield-like program for Linux? Will it be easy or a nightmare to go from an LSB install to one of several kinds of rigs (ie: a server box, an internet browsing box, a gamer's box, a development box, etc.)?

    Also, how often do they forsee this base being updated? When new killer hardware comes out, how will this affect the LSB? Will the LSB be so concrete that a new killer ap coming along will shake it to the core and require a complete rebuilding? Or will the LSB be so abstract that it won't be really any use to anybody?

  • While binary compatability is great, one only has to look at shrink-wrapped Windows software to see that Linux is not ready for the average user (AKA "moron"). Take almost any application or piece of hardware and you will see Windows screenshots showing the installation and/or operation. When Linux has no predictable UI and innumerable potential configurations, it is impossible to produce instructions that all users can follow. We can look down on the average user all you want, but that's where the money is.
  • Work is primarily being done by the development community and the major Linux distributions including Caldera/SCO, Debian, Mandrake, Red Hat,SuSE, and Trubolinux. Further contributions have come from IBM, Intel,Linuxcare, Metro Link, VA and others.

    Hmm, well it seems as though a few companies have done some development, however who do you think will be the first to adopt it into their base distrobution? What also comes to mind is package support. Right now it is said that it hasn't selected a package format but eludes to RPM. Does this mean that when others adopt the standard they will have/like to switch to RPM?


    The only statement that cannot be questioned, is that every statement can be questioned.
  • Looking at the standard, it struck me that for the most part, all the things that define what a distribution is (packaging format, some of the hierarchy issues, init scripts, etc) are being standardised.

    My question is, is it not so much that we're making it so all software can run on many distributions, as making all distributions essentially the same?

    And if so, is this really a good thing?
    --

  • All Your Linux Standard Base Are Belong To Us
  • It uses RPMS and ends with .0, what more do we need to know? I don't trust it, it'll probably load a vga message into lilo and screw the crap out of the mda video card in my server.

    err... or is that redhat I am thinking of..
    kenny
  • But I'm so used to counting in Base 10! I mean, I've got counting in binary and hexadecimal down pretty well, but .9? How the hell do you count in base .9?

Hackers of the world, unite!

Working...