Linux Standard Base .9 Released 92
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/
Re:package formats. (Score:1)
why not XML? LSB is not looking ahead (Score:1)
Re:Why does Slackware boycott the LSB? (Score:2)
Misnamed (Score:4)
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.
Re:package formats. (Score:2)
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)
Re:Solving RPM dependency problems (Score:2)
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
Solving RPM dependency problems (Score:1)
rpm foo.rpm -Uvh --nodeps :)
Re:dpkg != apt (Score:1)
Linux Standard Base A Good Thing (tm) (Score:2)
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?
Re:How about a standardized font system? (Score:2)
-Paul Komarek
C90, C99--what about ISO C++? (Score:4)
(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?
Re:dpkg != apt (Score:1)
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.
new format currently being developed (Score:1)
Re:package formats. (Score:1)
-l
Re:package formats. (Score:1)
Few questions (I really don't know the answers):
Re:How about a standardized font system? (Score:2)
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.
Re:How about a standardized font system? (Score:2)
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.
Re:Base .9? (Score:1)
--G
Re:Go for it! (Score:1)
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
Re:dpkg != apt (Score:1)
Debian definately is the only one with FREE automatic upgrading.
Re:apt-get != dpkg (Score:1)
What major distrobution supports this?
Re:package formats. (Score:1)
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.
Re:de facto (Score:1)
de facto - In reality or fact; actually.
This debate wouldn't exist if it were in fact the standard.
Re:package formats. (Score:1)
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".
Re:package formats. (Score:1)
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
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
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)
Re:dpkg != apt (Score:1)
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
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?
Re:Stop shooting your mouth off (Score:1)
"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.
Re:De Facto? (Score:1)
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.)
Re:De Facto? (Score:1)
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
Re:package formats. (Score:1)
Is Windows the standard PC Operating System?
Re:package formats. (Score:1)
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.
Re:dpkg != apt (Score:1)
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.
Re:package formats. (Score:3)
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
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.
How about a standardized font system? (Score:5)
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.
Re:package formats. (Score:2)
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)
Re:Misnamed (Score:3)
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)
Re:C90, C99--what about ISO C++? (Score:2)
Sorry, couldn't resist...
What do I do, when it seems I relate to Judas more than You?
Re:How about a standardized font system? (Score:1)
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...
Re:dpkg != apt (Score:1)
Indeed choosing one over the other would give substantial credibility of a distribution as being "the standard" distro.
Re:package formats. (Score:2)
From dictionary.com -
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.
Re:package formats. (Score:1)
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
Re:Stop shooting your mouth off (Score:1)
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
package formats. (Score:5)
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
There was no spokesperson for gcc... (Score:3)
...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.
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].
Re:package formats. (Score:2)
It simply states that more Linux boxen have RPM than DEB.
Re:APT has nothing to do with packaging formats. (Score:2)
The Debian zealots are right. RPM does suck compared to dpkg. (Both have deficiencies, however). ... What's a stack?
------
I'm an assembly guru
Re:apt-get != dpkg (Score:2)
------
I'm an assembly guru
Re:APT has nothing to do with packaging formats. (Score:2)
------
I'm an assembly guru
Re:package formats. (Score:1)
Re:How about a standardized font system? (Score:1)
Indeed, easy to type - no typing at all required!
Use the Preview Button! Check those URLs! Don't forget the http://! etc.
Re:How about a standardized font system? (Score:2)
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?
Re:How about a standardized font system? (Score:2)
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.
Lets just hope (Score:3)
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.
APT has nothing to do with packaging formats. (Score:2)
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.
Re:package formats. (Score:2)
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.
You're not talking about RPM. (Score:2)
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?
Re:dpkg != apt (Score:2)
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.
Not misnamed. (Score:2)
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).
Re:APT has nothing to do with packaging formats. (Score:2)
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.
Re:dpkg != apt (Score:2)
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
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
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.
Wait a secpnd here (Score:1)
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
Re:Pathetic (Score:1)
Embracing Solaris/BSD/the Linux layer on Windows would give a 100% effective coverage.
But, the LSB crowd doesn't see things that way.
Why does Slackware boycott the LSB? (Score:2)
-Karl
Re:Who is stepping up to the plate first? (Score:2)
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.
Re:De Facto? (Score:2)
Re:De Facto? (Score:2)
Re:De Facto? (Score:2)
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.
Re:package formats. (Score:2)
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"
Re:package formats. (Score:1)
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.
My elf is so special (Score:2)
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.
Re:dpkg != apt (Score:2)
I can't resist (Score:1)
Re:What is this? (Score:1)
To give you some idea of what LSB is about (Score:2)
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.
Re:package formats. (Score:1)
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..
Re:package formats. (Score:1)
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!
Re:package formats. (Score:1)
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. .lsp (linux standard package)
I suggest
------
C'mon, flame me!
Good Idea (Score:2)
Does it ever seem like the world will collapse from the weight of standards to you? It does to me.
Go for it! (Score:2)
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.
What about ISO C++ - (C/C++ User's Journal Tests) (Score:3)
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).
Multiple support? (Score:1)
Re:What is this? (Score:3)
--
Re:The problem: (Score:1)
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!
Re:Misnamed (Score:2)
Re:How about a standardized font system? (Score:3)
Okay, so what does this REALLY mean? (Score:1)
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?
Re: (Score:2)
Who is stepping up to the plate first? (Score:1)
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.
Re:Go for it! (Score:1)
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?
--
obligatory aybabtu (Score:1)
0.9.0 (Score:1)
err... or is that redhat I am thinking of..
kenny
Base .9? (Score:2)