Three Major Linux Distributions Certified LSB Compliant

KevinDumpsCore writes "RedHat, Mandrake, and SuSE are now certified LSB compliant!" Here's the announcement on the Free Standards Group's site. The Linux Standards Base (check out these related Slashdot posts) has been working for years to perhaps tame the what-lives-where cross-distro craziness. (Of course, distro makers are under no obligation to comply with the LSB's choices.)

Comments

What about Debian?

[shadwwulf]

What's Debian's status in this matter?

Re:What about Debian?

[ArtDent]

LSB requires compliant distributions to provide, not use, rpm, and Debian does.

Re:What about Debian?

[Anonymous Coward]

Even gentoo provides rpm, but like debian its users know better than to use it.

Re:What about Debian?

[Sc00ter]

uhh, apt-get is NOT a package manager.. .deb is. apt-get is just a front end and will work with .rpm files as well.

Re:What about Debian?

[sporty]

LSB seems to require redhat packages. They can't use triggers and some other things, but it is required they used rpm.

Re:What about Debian?

[Trevelyan]

The are some problems, for some reason LSB specifies a standard package, ie RPM
I do not know why, I see no reason for it, but obvious this is a problem for Debian, which has its own (imo superior) package (debs).

This article from Debian planet, is about a sudo package you can install, which depends on all the LSB stuff (thus gets them installed, with some caveats)
As to RPM, Debian wont move from debs, but I believe they make a wrapper so that dpkg can understand them, see /usr/share/doc/lsb/README.Debian.gz

I will not install lsb, cause it wants lpr (BSD print deamon) and I already use CUPS (a SysV print deamon), as well as other stuff.

Re:What about Debian?

[Macrobat]

What's Debian's status in this matter?

I believe they're aiming to be GNU/LSB certified.

Re:What about Debian?

[printman]

LSB requires the lpr command, not the lpr software. CUPS, LPRng, Berkeley lpr, and GNU lpr all satisfy the LSB requirement IIRC.

Re:What about Debian?

[bedessen]

a sudo [sic] package you can install, which depends on all the LSB stuff (thus gets them installed, with some caveats)

For all of you out there wondering what the hell the 'sudo' command has to do with the LSB, I believe the poster meant a pseudo-package.

Re:What about Debian?

[noahm]

The are some problems, for some reason LSB specifies a standard package, ie RPM I do not know why, I see no reason for it, but obvious this is a problem for Debian, which has its own (imo superior) package (debs).

Grr, I'm so tired of people not getting this. The LSB usage of RPM is simply not a problem for Debian. We have no problems handling .rpm packages. See the rpm and alien packages (particularly alien) to see how we do it. The RPM thing is a non-issue regarding Debian's LSB compliance.

To see how seriously Debian takes LSB compliance, go have a look at the archives of the various LSB related Debian mailing lists

noah

Re:What about Debian?

[Tomun]

Thank you.

That had me confused too.

Re:What about Debian?

[mackstann]

"Uhh", .deb is a filename, .deb's are debian packages. Files. Archives. Call them what you will. dpkg is what manages them, and is (I believe) what you were referring to as the backend to apt.

Re:What about Debian?

[Anonymous Coward]

Why was this moderated as troll? It's a fact. Debian runs a 2.2.x kernel, 3.3.x XFree, and has the installer from hell. No thank you, I'd rather roll my own distro than run that obscolecent crap.

And anyone that thinks it's more secure than an rpm distro, try to configure tripwire and you'll change your tune real fast.

Ok, GREAT now merge Gnome and KDE

[Anonymous Coward]

Ok, GREAT now merge Gnome and KDE. I hate it when I cannot easily copy from application to another.

Competition is great, but only to a certain level.

The LSB ought to have that merger as a long time goal. Get the Gnome/KDE guys together more, and eventually... I know they have had discussions, but, where are the actual results.

Let, Gnome 3.0 and KDE 4.0 be the same!!!

Re:Ok, GREAT now merge Gnome and KDE

[Sheetrock]

Actually, the best parts of each should be integrated with X. Right now, a lot of the bloat the common user experiences on the Linux GUI is because of the seven layers of translation the average API call goes through -- every window draw, every mouse click, every sound has a huge timing penalty incurred by the three or four extra layers over and above what you would find under Windows or even in Mac OS X. Building in icon support, sound support, font support, higher-level networking, drawing primitives, and OpenGL could make X anywhere from 12% to 37% faster on the average platform (depending on the features involved), bringing us that much closer to the Windows refresh rate.

Window managers should really be little more than themes; otherwise, we're just reinventing the wheel every time another person has to redevelop an algorithm that's already present in five other places.

Re:Ok, GREAT now merge Gnome and KDE

[Anonymous Coward]

Ok, so X is the bad gay again. Maybe, some Longhornesque initiative is in place. There are several 3D GUIs coming along a t a v e r y s l o w p a c e. Perhaps the efforts should be concentrated on that.

as I get it, Microsoft is now calculating on the immense evolution 3D cards and therefore will have Longhorn ready next year. Where are the visions among GPLists?

Ok, before you start flame me, a 3D GUI does not necessarily consist of rotating cubes... It can be quite trivial as ordninary 2D vector graphics with the ability to extende into 3D should you like that. One does not _have_ to overdo it.

Re:Ok, GREAT now merge Gnome and KDE

[AJWM]

could make X anywhere from 12% to 37% faster on the average platform

So, did you just pull those numbers out of your asterisk, or can you actually point to some analysis to back that up?

Even assuming that were true, on most machines (ie, anything better than a 386 with 4 MB memory), the difference won't be noticeable because even a 200% improvement in event response is lost in the noise of human reaction/perception times.

Re:Ok, GREAT now merge Gnome and KDE

[JanneM]

And who will get to decide what components to use? What WM functionality to implement? What toolkit to base it on?

Me? Great! I say we go All XFCe, All the Way! We won't even implement the letters K or G in our brand new environment! Oh, and the WM functionality will be tiled, not overlapping, and will be sloppy focus only, and with themes implemented in an inbedded Haskell interpreter.

Not good? Haskell is a drag? You maybe wanted to work in Qt? You maybe wanted a different feature set? Well, golly, let's put all your wishes in as well, and those of everybody else. Once we put in the superset of all current (and future) desktop-type projects, I'm sure X will be a lot faster and smaller!

And once it's all in, I'm sure everyone with a hankering to try some new ideas regarding desktops or window management will be just thrilled at the prospect of having to demand their users to install a custom version of X to use it.

Serously, I really don't get this "One OS, One Desktop, One Community" kind of reasoning. That we can use different stuff for environments (or even just different tastes) is a _strength_ of the platform, not a weakness.

If you are _really_ desperate for more speed, why not start a project to make a desktop bypassing X altogether? If the speed difference is really that important, people will flock to it. And BTW, I'm really impressed with the precise percentages you have, especially since you've not even decided _what_ components should be integrated... /Janne

Re:Ok, GREAT now merge Gnome and KDE

[Anonymous Coward]

This is what I get running the command: openssl speed
with KDE 2.2 (mdk 8.2) and a Pentium 2, 300 MHz

sign verify sign/s verify/s
rsa 512 bits 0.0052s 0.0005s 191.6 1937.9
rsa 1024 bits 0.0283s 0.0014s 35.4 699.4
rsa 2048 bits 0.1621s 0.0049s 6.2 205.3
rsa 4096 bits 1.1567s 0.0165s 0.9 60.8
sign verify sign/s verify/s
dsa 512 bits 0.0049s 0.0059s 203.3 169.8
dsa 1024 bits 0.0139s 0.0166s 72.1 60.3
dsa 2048 bits 0.0503s 0.0554s 19.9 18.0

Here is the same machine but with console only (i.e. no startx):

sign verify sign/s verify/s
rsa 512 bits 0.0044s 0.0004s 228.9 2563.0
rsa 1024 bits 0.0226s 0.0012s 44.2 867.6
rsa 2048 bits 0.1357s 0.0039s 7.4 257.0
rsa 4096 bits 0.2083s 0.0137s 1.1 72,9
sign verify sign/s verify/s
dsa 512 bits 0.0040s 0.0047s 252.3 211.1
dsa 1024 bits 0.0114s 0.0139s 87.5 71.7
dsa 2048 bits 0.0379s 0.0466s 26.4 21.5

Can you tell the difference?

Re:Ok, GREAT now merge Gnome and KDE

[SN74S181]

on most machines (ie, anything better than a 386 with 4 MB memory), the difference won't be noticeable because even a 200% improvement in event response is lost in the noise of human reaction/perception times.

So, did you just pull those numbers out of your asterisk, or can you actually point to some analysis to back that up?

Re:Ok, GREAT now merge Gnome and KDE

[leviramsey]

I agree with you, but, there should be some efforts made towards compatibility between the various environments. This brings up an idea I;ve been kicking around for a few months: meta-theme packaging. These would be tarballs of themes for different environments. The client system would provide scripts to install themes for different environments/toolkits. So now one theme could be installed for Sawfish/Metacity, GTK, Qt/KDE, WindowMaker, or Enlightenment.

Re:Ok, GREAT now merge Gnome and KDE

[Anonymous Coward]

Gnome + KDE = GnoKDE? Hrm. Sounds a bit like 'Naked'.

Re:Ok, GREAT now merge Gnome and KDE

[Anonymous Coward]

that's what freedesktop.org is for

oh, and gnome2 and kde3 happily copy and paste to and from one another

but, i'll probably get modded down as a troll anyway...

Re:Ok, GREAT now merge Gnome and KDE

[JanneM]

Look up Metatheme - it's supposed to do that eventually.

And there _is_ work on improving compatibility; with KDE3, the clipboard now works the same in just about every desktop, there is a common menu description format, Gnome is moving towards using arts as the soundserver, they use the same XML lib, and so on. There's even a site for coordinating desktop-interoperability in Linux (though I don't have the link handy).

The most difficult problem is of course theming. It would be all but impossible to make a common theme format; you'd probably end up with a 'compatibility engine' that can take themes written for it - and that nobody will use, as the native themes will be cooler and faster anyway. Something like Metatheme will probably have a better chance, and even then, it greatly depends on multiple people working together to create a unified theme. /Janne

Re:Ok, GREAT now merge Gnome and KDE

[Anonymous Coward]

Heya, leviramsey. What happened to monolinux? I just got back and is Eric gone or something?

-Shatai

Re:Ok, GREAT now merge Gnome and KDE

[Anonymous Coward]

This is an absolutely awesome idea, but do you honestly think anybody is going to do this? *sigh*. Probably not. Also, to whatever poster replied calling this FUD; please, shut the hell up. Do you even know what FUD is? Sheetrock is simply making suggestions that would improve X, not take away from it; and you call him a FUD spreader? Fuck off and die, brother.

Re:Ok, GREAT now merge Gnome and KDE

[leviramsey]

Monolinux sort of withered and died while Eric was in Spain. He got caught up with trolling K5. At this point, I don't know what monolinux's future is.

Re:Ok, GREAT now merge Gnome and KDE

[Anonymous Coward]

1. To copy, highlight text, center click at destination. In console and X, for ages.
2. Competition between less than two desktop environments isn't competition. By definition.
3. Where are the results? Have you actually used them. Both have made enourmous advances.
4. No, let's not. If you want one User Experience, one OS, one Desktop, Redmond already fills that niche.

Re:Ok, GREAT now merge Gnome and KDE

[jbolden]

I run KDE and Gnome apps fine in WindowMaker over a network. What do you mean by compatibility?

Re:Ok, GREAT now merge Gnome and KDE

[mgv]

If you are _really_ desperate for more speed, why not start a project to make a desktop bypassing X altogether

This is actually a very good idea. We will need X for some time to come, but it supports alot of junk that isn't needed; and it fails to support many things also (sound, most input devices).

If we want a common standard there should be one windowing API, which probably bypasses X altogether. This is hardly a trivial task, but in the long run makes alot of sense. If you are writing an app today, it really needs only two interfaces to the user: Command line and GUI. It shouldn't need to care about X.

Now for my personal impression - this isn't meant to start a flame war, but probably will be taken that way. The KDE environment (at the moment) appears the best local environment. By this I mean the GUI, themes, and smaller apps (konqueror for file browsing). Unfortunately (or fortunately, depending on your view) many of the best apps are GNOME (Evolution, Galeon for the web). For the newbie it can take a while to go find these apps if they use the KDE desktop.

Serously, I really don't get this "One OS, One Desktop, One Community" kind of reasoning. That we can use different stuff for environments (or even just different tastes) is a _strength_ of the platform, not a weakness.

I don't believe that is true when it applies to fundamental, underlying services. We have one kernel, and it works. The prospect of a kernel fork came up recently in the 2.4 series, and it wasn't a nice prospect. The current fork in GUI's that overlie X windows is much less critical, but still not good. And the two projects went their own ways at about concept time, when everyone agreed that linux needed a better GUI for end user apps.

Linux's strength is in a rock-steady kernel, a secure file and operating system all open to scrutiny, and a mass of interested developers. This produces a diversity of quality applications, and Linux needs that too. But GNOME and KDE? Two GUI's - no, in the long run we will want one good gui with the good features of both.

My 2c worth,

Michael

Re:Ok, GREAT now merge Gnome and KDE

[zorander]

Uhm....and this proves?

If I run tar xzvf on a big archive I end up with a bigger difference from that...all you've managed to figure out is that when more processes are running, each gets less juice.

This has been known for years.

Brian

Re:Ok, GREAT now merge Gnome and KDE

[AJWM]

Heh, wondered if that would get a comment.

The answer is "yes".

Re:Ok, GREAT now merge Gnome and KDE

[nathanh]

Actually, the best parts of each should be integrated with X. Right now, a lot of the bloat the common user experiences on the Linux GUI is because of the seven layers of translation the average API call goes through -- every window draw, every mouse click, every sound has a huge timing penalty incurred by the three or four extra layers over and above what you would find under Windows or even in Mac OS X. Building in icon support, sound support, font support, higher-level networking, drawing primitives, and OpenGL could make X anywhere from 12% to 37% faster on the average platform (depending on the features involved), bringing us that much closer to the Windows refresh rate.

12% to 37% faster? 7 layers of translation? Timing penalties for SOUND? How the hell did this techno-babble get moderated up as insightful? It's a load of codswallop. I don't think there's a single fact up there.

Re:Ok, GREAT now merge Gnome and KDE

[Hassan79]

There's even a site for coordinating desktop-interoperability in Linux (though I don't have the link handy).

It's freedesktop.org

Re:Ok, GREAT now merge Gnome and KDE

[Anonymous Coward]

"Well, let them drink juice."

M. Antionette

I think this is Better than 'United Linux'

[BroadbandBradley]

a nice open standard like LSB, imagine the improvement in install docs, cross distro rpms...this is a good thing.

Re:I think this is Better than 'United Linux'

[Anonymous Coward]

Talking about docs: Is there a good introductory text which explains why everything goes where it goes? Why is /etc called etc, why are there so many different *lib* directories? Stuff like that...

Re:I think this is Better than 'United Linux'

[Anonymous Coward]

great...now every distro will have equally crappy implementations of rpms. after using ports how could you go back?

Re:I think this is Better than 'United Linux'

[EggplantMan]

More exciting is conformance to a single ABI standard in combination with installation script support. This is a godsend for package maintainers; in the future they will only have to compile and package once, and your app is supported on multiple distros.

Re:I think this is Better than 'United Linux'

[Anonymous Coward]

Talking about docs: Is there a good introductory text which explains why everything goes where it goes? Why is /etc called etc, why are there so many different *lib* directories? Stuff like that...

It comes from traditional Unix, most of it. Ask the FHS people.

Re:I think this is Better than 'United Linux'

[Arethan]

More exciting is conformance to a single ABI standard in combination with installation script support. This is a godsend for package maintainers; in the future they will only have to compile and package once, and your app is supported on multiple distros.

Isn't that what United Linux was all about? LSB compliance, plus a standard filesystem layout, plus a standard set of libraries, plus standardized international language support.

Forgive me, but I feel that United Linux was on the right track. The only problem with it was that Ransom Love's name was on the list of founders. Well, that and the obvious fact that it is pretty much still vaporware at this point.

Still, it seems sad that a good idea gets the shit treatment simply because people have a bad attitude about one of its supporters.

The story didn't mention which versions

[Bob Loblaw]

Did they just finish evaluating the latest stable distros from each company or are they looking at the betas that just developed into FSB compliance?

Re:The story didn't mention which versions

[phatvibez]

(http://www.opengroup.org/lsb/cert/cert_prodlist.t pl?CALLER=display_product.tpl)

-Mandrake Linux ProSuite 8.2 + first update CD
-Red Hat Linux 7.3 with glibc 2.2.5-39+kernel 2.4.18-10 or later
-SuSE Linux 8.0 Professional + aaa_base and Kernel Update

RPM is obsolete =/

[N1KO]

If they plan to use rpm then i guess i'll make sure my distribution isn't LSB compliant.

If they wanted to choose the most popular packaging system they should've gone with installshield and force distros to have binary compatibility with windows apps.

Re:RPM is obsolete =/

[BagOBones]

I would rather use RPM than installshield and I'm a windows user!!!.. I can't count the number of times I have had strange pauses, lockups, errors, misc files left all over my system from using installshield or MSI. I would much rather use some other less bloated standard.. Under windows I tend to use Inno Setup for my windows projects.

Re:RPM is obsolete =/

[N1KO]

My point was that its stupid to choose the more popular installer if there are much better choices (if you've ever used apt or portage you wouldn't even think about going back to an rpm based distro).

I think its cool that someone wants to make a standard for distros but they should choose the best stuff from each one, not "the standard should resemble redhat".

Re:RPM is obsolete =/

[Sc00ter]

apt has nothing to do with the package type. apt will work with .debs or .rpms just as well.

Re:RPM is obsolete =/

[leviramsey]

Never used urpmi, have you?

The number one problem that RPM-based distros have is Red Hat's pathetic handling of RPM.

Re:RPM is obsolete =/

[Anonymous Coward]

You realize you can use apt with rpm don't you? Conectiva Linux does it.

Re:RPM is obsolete =/

[budgenator]

My understanding is that rpm has to be available, which is different from being used. Just like lpr has to be available, sometimes being available is a matter of providing a symlink or an alias to a superior but backward compatable program. LSB is a program that will make life easier for all of us.

Nooooooo, evil RPMs!

[FzZzT]

Doh, the LSB software installation "standard" is RPMs. Oh, the humanity!

Re:Nooooooo, evil RPMs!

[leviramsey]

RPM's not bad. In some ways it's even better than deb.

The problem that RPM has (from a pr perspective) is that deb was the first to get a good automated installer (apt-get). However, Mandrake (not sure about SuSE.. up2date sucks ass) has urpmi, which brings the power of apt to rpm.

There has also been a project to port apt-get to use rpms instead of debs.

How difficult would it be for debian to switch to rpm, especially once apt is ported to rpm?

Re:Nooooooo, evil RPMs!

[Anonymous Coward]

I've only used up2date with Red Hat Network, but it seems to work just fine in this limited capacity.

Urpmi was an improvement over tortuous, raw rpm. But, since Connectiva helped port apt to rpm, installation seems so much better and easier. There are now apt-rpm repositories available for Mandrake, Red Hat, SuSE, Connectiva, and even Solaris. There no longer seem to be any compelling reasons to use urpmi. Why not standardize all distributions on apt -- regardless of whether you're using rpm or deb packages?

On a cultural note: I'm sure Debian users have lots of good reasons for choosing it as their favorite distro, but please spare the rpm bashing until you've tried apt-rpm.

Re:Nooooooo, evil RPMs!

[damiam]

Apt has been completely ported several times over. Debian, however, will never switch. The rpm format doesn't include some of dependency information used by Debian, among other shortcomings. Debian does include rpm, alien, and various other tools to install rpms on a Debian system, but they'll never switch the main distro to rpm.

Re:Nooooooo, evil RPMs!

[Khalid]

I have been using apt for rpm (apt4rpm.sf.net) for ages, works insanly well !! resolve de dependency hell !

Re:Nooooooo, evil RPMs!

[Wandering Idiot]

To be honest, I've never used apt-get, but I *do* know that urpmi seems to work just fine. Because of it, I've never experienced the "dependency hell" that most people seem to go through. (And from looking at the dependency list every time I install something big, I'm damned happy about that).

Basically, *some* standard system of this type would be handy, and since rpms seem to be the most popular method of distribution, using them seems like a good choice. Now wrap that up in a nice graphical frontend (like Mandrake's, which for some reason seems to have broken after I installed KDE3!?), and you've got a system as easy to use as those evil Windows installers :)

Re:Nooooooo, evil RPMs!

[glitch!]

RPM's not bad. In some ways it's even better than deb.

I would be a lot happier with RPM if it had a simple way to simply unpack the files to some place I choose. Maybe there is a way, but it wasn't obvious when I wanted to do that.

Sometimes, I don't care about the dependencies, or I want to inspect the files before installing them. Or perhaps the people who packaged the rpm did not know (or care) that my file layout is completely different than what they expect. This can easily happen when I run Linux binaries on a non-Linux OS (FreeBSD for example). Or maybe I don't have (or want to set up) the RPM database, or I cannot access it because I am not root.

Maybe there is a way. If someone knows of a "JUST UNPACK THE FILES" option for RPM, I would be very interested to hear it.

Re:Nooooooo, evil RPMs!

[leviramsey]

Well you could use the --relocate OLDPATH=NEWPATH option to move stuff around. As for the others, I'm not sure.

Re:Nooooooo, evil RPMs!

[LinuxGeek8]

Sometimes you can unpack the files in an rpm, put them wherever you want, and it works.
Sometimes it depends on compile-time options to have the app find its files. Most games have fixed runtime paths to their datafiles for example. Larger projects like kde and gnome also expect to live in certain places.

When I want to unpack a rpm, i use mc (midnight commander) and it's virtual filesystem for rpm. Just click on an rpm, and you''ll browse into it. It will use rpm2cpio, which you can also use yourself to make the rpm into a cpio.

Re:Nooooooo, evil RPMs!

[Anonymous Coward]

Maybe there is a way. If someone knows of a "JUST UNPACK THE FILES" option for RPM, I would be very interested to hear it.

rpm2cpio <rpm file> | cpio -i

RPM...

[matman]

It's too bad that the LSB people havn't yet taken on packaging issues. They've effectively chickened out by just recommending RPM. The best features of RPM, DEB and the BSD ports system should be reflected in a new packaging format for people to work towards using. Not only should this format be recommended by the LSB, but the LSB should define policies for the use of the format - package name and version formats, dependencies and package alias names, source package handling, non-official packages, etc. This really is necessary to get distribution of commercial software on Linux; testing for and supporting distribution differences is just too expensive for most companies. This is not to say that everyone supporting RPM won't help, but rather that policies are needed to really make it work, and that we may as well get a more optimal package management system happening :)

Re:RPM...

[jmorris42]

RPM is just fine for a packaging standard. It does EVERYTHING a packaging system needs to do and none of the bogus crap that consumer friendly monsters like InstallShield do. Deb may very well have a equal featureset but nobody in the commercial world uses it because it is only used on Debian, a non-commercial distro. Since the big need for the LSB is for commercial software packagers.... see the problem? As for the BSD Ports system, it has ZERO to offer in this situation despite being a wonderful system. The BSD ports setup pretty much requires source distribution and the target audience for LSB isn't interested in that.

The apt groupies can't get it into their pointed heads that apt can work just fine with rpms. Apt and .deb are entirely seperate issues. Yes rpm needs something like apt to come into popular usage. (ya know, maybe apt would be just the ticket! Now if all of the apt groupies would promote it's use with rpm instead of constantly saying ya gotta go to Debian to get the wonders of apt. Ya, I'm talking about you Taco.)

Not that I would ever be insane enough to put apt in a cron job like the typical Debian user, but it does do wonders to solve rpm dependency hell situations.

Re:RPM...

[geogeek6_7]

If they won't do this, I would like to see RedHat improve their system to not gradually degrade into a pile of confused and intensely interdependent RPMs. ~geogeek

Re:RPM...

[leviramsey]

Maybe there should be a meta-program called "autopkgmanager" (or something else) that would serve as a unified front-end for apt-get, urpmi, up2date, emerge, etc.

For example, on a mandrake box:

autopkgmanager -i kde

would call:

urpmi kde

while on debian, the same command would call:

apt-get install kde

On gentoo:

emerge kde

And so forth...

Re:RPM...

[Anonymous Coward]

Thank you for making this point! Debian is a fine distribution, but to any outsider it's bound to look like a bunch of kooks and cultists -- especially when people don't get their facts straight. At the risk of trolling, a lot of this tripe comes from people who haven't so much as touched a Red Hat distribution in years. Weak. There are certainly differentiating factors which may make Debian a better choice than other distributions, but -- in many cases -- apt isn't one of them, thanks to apt-rpm.

Red Hat, SuSE, Yellow Dog, Solaris, and Mandrake users can give it a spin by heading to:

http://apt4rpm.sourceforge.net/

Re:RPM...

[inkfox]

Not that I would ever be insane enough to put apt in a cron job like the typical Debian user

A typical Debian user would not do this. Good god, that's a recipe for disaster!

"Typical" Debian users are more concerned with stability than they are in "upgrading" constantly.

Re:RPM...

[Scudsucker]

The apt groupies can't get it into their pointed heads that apt can work just fine with rpms.

What RPM goupies can't get into their pointed heads is that you can slap on an apt-like system onto RPM but that wont fix RPM's interdependancy problems. Its silly to think that just by slapping on another layer of package management that it will be "just as good" as a system that has been designed from the ground up not to have those problems, like Debians.

It's like if Microsoft and Apple just hacked multitasking and protected memory on top of the old MacOS and Win9x and claimed it was "just as good" as a unix kernel. Sheesh.

Re:RPM...

[miracle69]

Apt-get has been ported to RPMs.

Mandrake's urpmi does the same thing as apt-get for RPMS.

You can use RPMs as your packages and use either apt-get or urpmi.

My personal experiences are these:
1) apt-get on a debian box is the reason to use debian.
2) apt-get on Debian is a rock-solid way to add/subtract packages.
3) urpmi with RPMs works ok most of the time. When it doesn't work, it's usually beause it dependencies that urpmi can't find in other rpms. In this respect, Debian still beats the RPM-based distros.

Re:RPM...

[blaine]

Exactly who the hell puts apt in a cron job?

I mean, I have a short script that I wrote that checks to see if there are any updates, and emails me the results. I have it run every night on my domain box, and thus, every morning, I find out if there are needed upgrades. At that point, I can go check out why the upgrades are needed, and perform the udpate manually.

However, I would never have apt upgrade my system without me being there, and I highly doubt anyone else with any brains would. So please, stop spouting bullshit about how the "typical Debian user" does something that retarded, because I've never met a single person who has done that, and I've known a lot of people running Debian.

Re:RPM...

[xanadu-xtroot.com]

[root@aragorn /]# urpmi kde

The following packages contain kde: kdevelop kde-i18n-ro kde-i18n-ru kde-i18n-cs kdeaddons kdev_htdig kdegraphics kde-i18n-ko kde-i18n-da kde-i18n-de kde-i18n-sk kde-i18n-sl kde-i18n-he ksetiwatch kdeadmin kde-i18n-sr kdesdk kde-i18n-zh_CN.GB2312 kdetoys-devel kdebase kdenetwork-devel kde-i18n-sv kdeutils kdepim kdemultimedia-devel kde-i18n-pt_BR kde-i18n-hu kde-i18n-af kdelibs kdenetwork kdetoys kde-i18n-ta kdebindings kde-i18n-pl kde-i18n-lt kde-i18n-lv kde-i18n-en_GB kdebase-nsplugins kde-i18n-th

etc. It won't install anything. urpmi is a half brain-dead, half-backed version of apt. Portage is a God send, as is apt. But urpmi needs some SERIOUS work. MDK USED to support apt, but stopped support of it back in Janruary or so.

Re:RPM...

[Anonymous Coward]

Interdependency problems? On what is this based? Have you used apt-rpm and had such an experience? If so, please share the details. Otherwise, your post appears to be more troll than substance.

I've been using apt-rpm for two months, now, and have not had one interdependency problem. The original post was basically right. According to Debian's site, apt is a "package manager interface" -- not a package manager. There's no reason it can't work with either packaging system as well as the otehr. In fact, I can only find one problem with the original post:

It should have read *thick* pointed heads...

Re:RPM...

[Anonymous Coward]

As one who has used both urpmi and apt-rpm, I can say that apt-rpm is the superior of the two. If you use a well-maintained repository, you should have no problem whatsoever. Furthermore, if I'm not mistaken, urpmi is only available on Mandrake. Apt (either deb or rpm) is now available for Debian, SuSE, Red Hat, Solaris, Connectiva, and Yellow Dog -- as well as Mandrake. One more point that apt has over urpmi: It's nice to have consistant syntax and commands across distributions. Try it.

Re:RPM...

[Anonymous Coward]

It does EVERYTHING a packaging system needs to do and none of the bogus crap that consumer friendly monsters like InstallShield do

Thank you, you've just proved my point. Why can't we have a consumer friendly system? Why must all the systems be uggly little CLIs, non-intuitive GUI's, or outright painful installers. Let people choose where it gets installed, what gets installed(via checkboxs, please, 10 downloads for a complete program doesn't work), and they'll be happy. Before that happens, you've created one more roadblock to users adopting Linux.

Re:RPM...

[rossz]

bogus crap that consumer friendly monsters like InstallShield do

This is the kind of attitude that is keeping Linux out of the mainstream. Consumer friendly crap like InstallShield are exactly what is needed.

Typical installation on installation on Linux...

Download rpm and try to install. Now go look for the dependency rpm needed. Download that and try to install. Oops, that has a dependency, too. Can't find an rpm, get the source in a tar.gz. Unpack it and run ./configure, make, make install. Oops, need the source for a missing library. Go find that....

Typical install using InstallShield...

Run InstallShield, choose directory, choose components (though the defaults are usually correct for the average user). Wait for install to finish. Sometimes reboot (yuck, that's stupid).

Now which method is a typical computer user going to prefer?

Re:RPM...

[Nailer]

As the poster above states:

• There are many front ends such as up2date, urpmi and apt for RPM that do dependency handling. Until a week ago, my Red Hat 7.3 machine has KDE 3.02 and GNOME 2 plus a bunch of other stuff from Freshrpms all fetched from apt.
  
  
• There are things that RPM does better than Dpkg, including more detailed package verification, ghost files, and simpler source rebuilds. There are also things that Dpkg does better than RPM, including suggested/recommended dependencies. Policy issues aren't technical ones and there are many RPM based distributions with policy.
  

I think the real chickening out has beeen the acceptance the alien is an OK solution for RPM support.. Alien does not implement the RPM packaging system. It implements CPIO archives, stripping all the `management' facilities of the package. How many Debian users would install large chunks of their system using alien? They wouldn't, because its a hack and not much better than installing tarballs all over your system. Accepting Alien, seems to have been a compromise, and not a good one. If Debian doesn't want to use RPM in its current state, they should make RPM better, not try and get the LSB to let them avoid it.

Re:RPM...

[Khalid]

Can you please point to real RPM shortcomings ? I have been using apt for RPM for months now, and have been satisfied with beyond any hope

Re:RPM...

[Khalid]

Something beyond my understanding is why anybody and his dog want his own pet upgrading thingy !

I mean Redhat felt obliged to come with it's brain dead up2date, same thing for Mandrake. I mean there is this thing called apt, wich has been tested for years, and which has been ported to work for RPM. I use it every day, and it works insanly well.

Yeah I know, I know ! the official Linux motto, the party line is that "Choice is good". But I sure would prefer one good standard over 10 half backed brain dead programs.

Re:RPM...

[cant_get_a_good_nick]

The BSD ports setup pretty much requires source distribution and the target audience for LSB isn't interested in that.

BSD also has binary packages, which mesh with the ports system. They're .tgz packages with the normal pre and postinstall scripts available in the package. I always thought of the BSD system as pretty slick, a source model and a binary package model that mesh well. Anything I installed from ports I remove with the package tools. I can check for new versions of all externally installed software (packages and ports) with the same command. They blend well enough for me that I kind of see them as one system.

Re:RPM...

[Anonymous Coward]

Is that why they keep getting 0wn3d?

Security requires constant and immediate upgrading.
Fixing security problems in a timely manner from source code patches is a maintenance nightmare, and the bane of most open-source platforms.

Sitting around, waiting to get popped while Mandrake gets around to spitting out an RPM that's compatible with their distro has got to be the most nervewracking experience ever.

Re:RPM...

[woodja]

To continue this off topic discussion. For me it all depends on the environment the Debian machine is in. For my home desktop machine, I run unstable and upgrade quite often to get the latest and greatest. For any servers I manage, I keep updates at a minimum for stability.

Re:RPM...

[Anonymous Coward]

You didn't listen to him, did you? RPM is just as good at dealing with dependency issues as .debs. I.E very poorly since the packaging format has fuck all to do with it - it is the dependency resolution tools and the people who built tha package that make the difference. The problem isn't the format, fucknut - when are you morons going to learn.

.debs are just as susceptible to dependency problems as RPMS if the people making them are assclowns with no understanding of the issues, like you in fact. If i get all my RPMS from redhat, amazingly enough I don't get dependency problems. If I grab them of Joe Fucknut's webpage, it's quite likely that he packaged them poorly and I'll have problems.

Re:RPM...

[inkfox]

Is that why they keep getting 0wn3d?

Security requires constant and immediate upgrading.

Updates come with the risk of new security problems. Debian's security updates have fixes backported to old versions to minimize risk. Reconsidering, that's probably what the original poster expected people were auto-installing from cron jobs. Still, it's much better to do this manually if at all possible. Debian is exceptionally good about making security problems known as quickly as possible, even prior to the fix being available so that users can disable services or take other precautions as is appropriate to circumstance.

Merely leaving a job in place which snarfs the newest code from security is debatably a sane thing to do, but it's certainly not even half enough. It's important that any Debian user monitor debian-security at the very least.

Re:RPM...

[Scudsucker]

My main point should have been this: when you're designing a standard, why not go with the best format with the longest track record? Why not go with apt-get which has been around for what, 4+ years now, instead of one thats cropped up in the last year and isn't as proven?

The only problems I've had with Debian was when I was running unstable. Under Redhat I ran into dependancy hell when only trying to install....sorry you need libz which needs libx.2, but libx.2 confilcts with packages a, b and c which need libx.1, and so on......

Re:RPM...

[Bob Uhl]

You forgot to mention the typical install using apt:

apt-get &lt;package&gt;

That's it. And when it comes to directory to choose, there should not be a choice in a package system. If it's that important to break things sufficiently that they are not in the standard dirs, then the user should download the package. This is Unix, where we can graft in disk space where we need it, not Windows, where it must be dealt with on a volume level.

Re:RPM...

[Anonymous Coward]

Talk about not listening....apt-get and debs are designed to go hand in hand to avoid dependancy problems. RPM's are not and apt-rpm is an "aw shucks I hope this works" hack, fucktard.

Re:RPM...

[fatboy]

3) urpmi with RPMs works ok most of the time. When it doesn't work, it's usually beause it dependencies that urpmi can't find in other rpms. In this respect, Debian still beats the RPM-based distros.

I have never had a dependency problem with RedHat Errata RPMS on RedHat installs.

I have had problems with Joe Schmoe's RPMS though.

I take it that Debian has no dependency constraints in debs. (I don't know. I have never used anything but Slack and RedHat) If that is the case, how do you know what libs go with Joe Schmoe's debs?

This is not a troll, I really want to know.

Re:RPM...

[Anonymous Coward]

But these were with raw RPMs, right? Did you try apt-rpm?

Re:RPM...

[jhoffoss]

Lotsa mentions of apt and RPM, but not many seem to know of Gentoo's emerge system yet. It's similar to apt (from what I know of apt), and it allows for both binary and source distributions. I assume apt does as well, and I know you can make an RPM recompile to install, but it's just another suggestion.

As an aside, does anyone know if Gentoo is even remotely LSB-compliant?

Re:RPM...

[jhoffoss]

What...

You mean putting apt in cron is a bad thing?
(TWAJS)

Re:RPM...

[Webmonger]

There's nothing wrong with running apt from a cron job. You do the downloads in a cron job, and you upgrade manually if and when it makes sense.

Re:RPM...

[Mornelithe]

Here is a discussion of LSB compliance and Gentoo on the Gentoo forums. In short, Gentoo won't be LSB certified, but it will "likely maintain the 'spirit' of LSB standards."

I think the RPM requirement and probably the requirement to maintain two separate init-script implementations would be undesirable for most Gentoo users.

Re:RPM...

[rossz]

I agree. apt-get is a great program. I wish it was made part of the United Linux standard.

Re:RPM...

[jmorris42]

up2date makes perfect sense when viewed in light of RedHat's business model. Whether allowing important standards to be defined to support a single company's business model is a good thing is a question for another day.

After instantly removing up2date and all it's associated cruft after an install/upgrade for a couple of years I finally left it on my new laptop and signed up for RHN just to give it a chance. It does work slicker than owl snot. Never a worry about finding a mirror, no dependencies, etc. Not sure if the time savings justifies the fee, guess I'll know next year when resub time comes if I actually give up the CC # again. ;)

In the end, apt-get is a fine thing for the Debian folks because they are few in number. I just don't think there is enough free bandwidth to host package repositories for the rpm using hordes. I especially have those sorts of thoughts when a Debian user starts talking about installing or doing a major upgrade directly from the mirrors. Can you imagine the meltdown that would happen if, when RH8 drops if every RH user tried to upgrade directly off of the mirrors? The slashdot effect would be as nothing compared!

Re:RPM...

[Anonymous Coward]

Is that why they keep getting 0wn3d?

Check the numbers. 1 in 1.37e2 Red Hat/Apache web servers gets defaced. 1 in 8.23e3 Debian/Apache servers get defaced. 1 in 2.19e2 NT4/IIS servers get defaced.

Re:RPM...

[jmorris42]

If InstallShield is the answer it was a dumb question. It doesn't really solve DLL Hell, can't run non interactive and generally sucks. And it is a PITA to build packages with.

I'm not defending the status quo, I think having something like apt become standard issue for rpm based distros would be a good thing.

My idea of a GOOD installer would be a simple Tcl/Tk (or for the Python Bigots out there, Python/Tk would be just as nice, save your napalm) script that threw up a welcome splash, checked for an existing install, etc but basically did an apt command to do the actual install would be just hoopy. Vendors should include the RPMs they depend on, from several popular distros, if there is a chance of a problem, just to avoid the user having to swap in a handful of distro CDs looking for packages. But there is NO need for a graphical package manager like Install Shield and DON'T allow the user to pick where to install to! And if you aren't packing the CD full of bundleware/spyware you usually don't even need to allow a choice of what to install. (But there are legit exceptions to that statement.)

For 95% of cases install should be a matter of "Do you want to install Foo?" Ok, wait a minute..... done. Enjoy Foo!

Re:RPM...

[jmorris42]

And again, apt != .deb. Apt works just as well with rpm and rpm dates back to RedHat 3x (RH2 for very liberal interpretations of what RPM is) so don't start an age war.

Re:RPM...

[MobyTurbo]

As for the BSD Ports system, it has ZERO to offer in this situation despite being a wonderful system. The BSD ports setup pretty much requires source distribution and the target audience for LSB isn't interested in that.

FreeBSD doesn't have to compile source to download and install a package with it's dependencies. Use pkg_add -r, and you'll get binaries along with their dependencies in binary. I prefer most of the time to use the ports system, however, because I've got a fast CPU so compiling usually is fast enough for me.

Re:RPM...

[maxwell demon]

The best features of RPM, DEB and the BSD ports system should be reflected in a new packaging format for people to work towards using.

Well, a first start toward this could be if someone wold make a complete list of those best features. Or does such a list already exist?

Even if making the list doesn't ultimately lead to that universal packaging system, it would be interesting to know what the strengths and weaknesses of each packaging system are.

Re:RPM...

[Anonymous Coward]

So, apt works as good with rpm as with debs, point made. Then interdependancies between deb's are better than interdependancies between rpm's. Better that way?

Either way you put it, interdependancies on debian are better than on redhat, there's no way around that.

Re:RPM...

[Anonymous Coward]

You don't use Joe Schmoe's deb's because Debian's package collection is so big that you shouldn't have to reach outside of it (you mix debian unstable stuff with the stable distro, if you need to). The rare occasion that this happens, you can get into the same problems as with rpm's. However, because deb's are only built to one distro, debian, it usually doesn't lead to problems (you all have the same base dependancies to begin with). Also, debian tries very hard to keep the different versions backwards compatible, so you can use a package made for an older version on a newer version.

In practice, I've almost never had problems installing something, and I've never screwed up my package database or distro, after one and a half years of debian use.

But then, I'm not someone chasing the bleeding edge. If you like the blood, then debian is not really for you. You can get quite up to date by running unstable, but it probably won't satisfy you like redhat+external rpm's, gentoo or just plain bare slackware will. If, however, you actually want to use your linux system instead of toying with it, then debian IS for you. The last time I installed debian on this system was the first time I installed debian, one and a half years ago. I've been upgrading it through apt ever since. This is probably why the debian install and early setup sucks. It isn't really worth it to make it better, since you're not likely to be using it a lot. (But a redesigned one is promised for the next release, in however many years that is.)

After this system I put debian on 3 other systems, all without a problem (beyond figuring out what the hardware in the damn laptop was during the install).

The system maintenance itself is relatively straightforward. Settings are preserved as much as possible for you (debian comes with a built-in system administration system called debconf, where all packages' configuration routines plug into), and debian provides a good command-line toolset to make everything as easy as possible. Redhat has caught up to this pretty much over the last years, but they still have an inferior package collection.

Don't think that I didn't have any problems with debian. What debian lacks is well mapped-out documentation. It's all "out there" somewhere. But just try and find something when you need it. In addition, I often found myself cursing debian because it had it's own little way of doing things. Programs behave differently in debian. Configuration files are in different places, the contents aren't the same as what comes with the version that's on the ftp server of the developer, and all kinds of small differences. Debian maintainers tweak their packages much more than redhat maintainers (this is also a good thing, because it makes the system much more stable and predictable). The system is also laden with various peculiar debian-only things, like "menu" which is a system for apps to provide identical menu's in all window managers and desktop environments. A good idea, and it works great, even in practice. Ofcourse, when you want to add your own menu entries, that's when it gets complicated, because you add menu entries by adding a file in the ~/.menu directory, with the right contents ofcourse.

All those things together make debian a less than enjoyable experience at times. But having learned enough of it to manage, I can say that I wouldn't trade it with any other distro, even if you payed me for it.

Re:RPM...

[Anonymous Coward]

Relax, the original poster didn't know about synaptic, which is a really nice gui front-end for apt.

Just click on what you want in the package listing. Click install, and click proceed. Nothing to it.

Re:RPM...

[Weird Dave]

If Debian doesn't want to use RPM in its current state, they should make RPM better, not try and get the LSB to let them avoid it.

The "R" in RPM stands for "RedHat". They should probably standardize on a completely new format name derived from existing formats. They could also use the chance to finally decide upon the best package content.

Re:RPM...

[Nailer]

Actually,. the R in RPM stands for RPM (RPM Package Manager). And yes, just because someone invented it doesn't mean that other people (ie, most Linux Linux distributins) can't use it and improve it - all the major (usage) distributions do.

Re:RPM...

[Weird Dave]

Sorry, you're wrong. RPM stands for Red Hat Package Manager. You're having a hard time separating what they say now from what they said when they created it. It is extremely easy to change anything into a recursive acronym. If I started a software project and called it "Nailer Porn Manager", I could later change it to mean "NPM Porn Manager" so that all of the nerdiest Unix people can get off on the acronym.

You're so obviously wrong to correct me that it isn't funny. At least think about what you type before you post it in a public forum.

As for the RPM, it was a hack from the very beginning, just like so many other things. Where would Linux be today if Linus Torvalds had not been willing to accept drastic changes when it is for the better? All I am saying is that writing off thinking about something from the start is foolish because there might be a better way. Instead, you just want to improve on what is there. That's important, too, but why not even let others consider a redesign? Seems like an ignorant way to go about life, and pointless to argue about, too.

Re:RPM...

[Nailer]

It is extremely easy to change anything into a recursive acronym.

Yes. It still, currently, stands for RPM package manager, whic haccurately reflects the fact that it is a project shared by many organizations and the standard method of installing software on Linux.

At least think about what you type before you post it in a public forum.

You haven't said why RPM is a hack, provided no supporting arguments, while childishly insulting me. Grow up.

Re:RPM...

[Weird Dave]

You grow up. I know what I'm talking about, and you don't. That's all. See this page for at least one example of how the original RPM format was a hack... inflexibility.

As for the insults, you started the insults by correcting me. We both know that correcting somebody like you did is a form of insult. While your insults didn't hold water, I think my insults stand on their own feet.

You tell me to grow up because I made a claim and provided no proof, and look at all the proof you gave in your post! Wow!

Now, before you jump out of your chair, screaming murder, realize that I never said that RPM is currently a hack (I haven't had time to look at any recent changes), I said that it was a hack from the beginning. Now that I've proven my point by backing up my claim, I guess you're going to say, "Gee, mister, you sure are right!", right? I didn't think so.

Lastly, the fact that RPM is used by "many organizations" does not mean it is flawless. My entire point is that it was created quickly by Red Hat, and that we might be better off if we designed a new format that has all of the RPM's good stuff, and none of its bad stuff.

Re:RPM...

[Wdomburg]

>My main point should have been this: when you're
>designing a standard, why not go with the best
>format with the longest track record? Why not go
>with apt-get which has been around for what, 4+
>years now, instead of one thats cropped up in the
>last year and isn't as proven?

The LSB specification doesn't specify package management front ends like apt-get; it specifies a package format.

RPM has been around for about seven years, and, whether you like it or not, is used by virtually all of the major Linux distributions (Red Hat, Mandrake, Caldera, SuSE, Turbo).

Add that the majority of what people think is wrong with RPM is based on ignorance or confusion with what a package format is and what a package manager is, and there's no really compelling reason to standardize on what is a fringe package format.

>The only problems I've had with Debian was when I
>was running unstable. Under Redhat I ran into
>dependancy hell when only trying to
>install....sorry you need libz which needs
>libx.2, but libx.2 confilcts with packages a, b
>and c which need libx.1, and so on..

I tend to dislike when people say the other person is lying in an argument, but I'm tempted to here. Maybe if you told me what version of Red Hat wasn't able to resolve dependencies on install, I could go check and maybe believe you.

I don't doubt there are cases where circular dependencies exist, but I honestly have never run into one in the Red Hat provided packages, and haven't run into one for a couple years even with third party packages.

Matt

Re:RPM...

[giminy]

Check the numbers. 1 in 1.37e2 Red Hat/Apache web servers gets defaced. 1 in 8.23e3 Debian/Apache servers get defaced. 1 in 2.19e2 NT4/IIS servers get defaced.

Care to give us a source on that? I'm a debian user myself but I'm always wary of numbers with no backing...

Re:RPM...

[Anonymous Coward]

You are an idiot - both RPM and .debs were "designed" to avoid dependency issues - but neither are a solution by themselves. You need human procedures (which Debian has with it's maintainers, and RedHat has too), plus a dependency resolution tool - which could be apt or redcarpet.

I'll say it once again for the dimwits at the back of the class: RPM is NOT, repeat NOT, less able to deal with dependency issues. Do you understand... fucking clueless Debian zealot.

Eh? What ya talking about?

[jmorris42]

I don't see seven layers of API. That's just FUD you are spouting from either the Windows or Berlin camp.

A typical GNOME app makes calls into the GNOME libraries, which are linked at the hip to GTK. GTK directly talks the lowest wirelevel X protocol which gets stuff on the framebuffer.

A KDE app talks to the KDE libraries which are built on Qt. Qt talks Xlib (QT experts feel free to call me an idiot and correct me) which, like GTK, talks directly to the X server.

And if you want to argue that X imposes too much overhead, that is why we have things like the shared memory extension and Xrender.

But NO, window managers must remain ordinary applications, otherwise X turns into something brain damaged like Windows or a Mac.

certifications...

[jukal]

a system, may it be whatever, needs certifications only when it becomes bloated and looses focus. Soon, we will have these certifications in 42 main classes, and 42 subclasses of each, each with different meaning.

I believe that the user's free choice is the best standard-making-body it does not matter if you got a certificate or not if your distribution is crap.

Re:certifications...

[Fat Casper]

I believe that the user's free choice is the best standard-making-body it does not matter if you got a certificate or not if your distribution is crap.

That's great for users. We can and do use whatever the hell we want. If it wasn't intended for that use, someone will come up with the right hack.

Certification isn't about users. At least, not about current users. Except maybe non-coders like me. It's about companies. IT geeks can now tell their PHBs that it's certified, which will carry a lot of weight. It's an unfortunate situation, but it is the proper response. Linux will seem less of a freestyle, knocked together geek alternative thing, and that's what needs to happen to expand the business market. The desktop market isn't where Linux's growth is going to be for quite some time.

Re:certifications...

[cant_get_a_good_nick]

Certification has little to do with being bloated. It has to do with compatibility. Compatibility sometimes aids to bloatedness because you have to support both new and old. Look how big XP is vs NT 2000, a good deal of bloat is to get the Win95 kernel stuff working. Even with all that bloat, there is stuff that doesn't work. Microsoft isn't certified, and it can break things as it pleases, sometimes intentionally.

Linux certification has less to do with forward and reverse compatibility than across distros. Testing's a bitch. Last professional project I did on Linux, we had to support 3 different startup models: Slack 3 and inittab, SVR4, and RedHat SVR4 where they moved the rc?.d directories. (granted this was a long time ago and all may have changed since). Because it's a pain to test for 3 different distros, most folks only do 1, and they might as well do the biggest, and that's RedHat. Slack was dropped, and Mandrake was a one time deal. The group that contracted us said screw these other distros, we'll just support RedHat.

The reason for certification is to get more software. If I can target one installation file, one file system layout, then I'm more likely to make software for that. The easier it is for me to support you, the more likely I am to do so.

Yes the user is free to do whatever they want. You could make it where your startup directory isn't /etc/rc{1,2,3,4,5,6}.d but called /MyReallyCoolStartupDir/runlevel/{un,deux, trois...}. I doubt if most software would work though. If you want to make your mark on your install, go ahead. There's plenty of stuff you can do. There's just some stuff you should leave where others can find it.

Re:certifications...

[cant_get_a_good_nick]

To be tacky and reply to my own post...

The other fun thing was RedHat kernel by default had ip masquerading on. The software had a listen port, 61000 IIRC. IP masqueradig kept all ports 50000 to 65000 I think. So we had two choices...
Make folks recompile their kernel to support this software.
Change the port and have folks be incompatible with others.
Change the port and have UI to change which port to coneect to.

We felt nobody would (or should) recompile to get user level softwrae wotking, so we picked "use different port, but show a hidden UI pref if you wanted to talk to other machines", figuring most folks would want to check their own box only, and if they wanted to check other machines, they'd have to work.

Mind you this was only in RedHat. If there was a standard it would be easier. But no, now we had to have a UI for this, have soem confusing things about "ports" and "IP masquerading". It made it difficult to support Linux. There were major differences between Slack and RedHat because of this. This all led to them dropping Slack, then (after they dropped us) dropping UNIX support altogether. The Windows world is much easier to support. There's fewer variations. This is one of the reasons why you can get whatever software you want for windows.

Re:certifications...

[Codifex Maximus]

> a system, may it be whatever, needs
> certifications only when it becomes bloated and
> looses focus.
Linux' distributions are getting bigger all the time and have many vendor specific tools - as such it has lost some of the tight focus it had in the early days when there were few distributions.

Certification is neccessary to satisfy the requirements of some software producers and users. A software producer needs to know what clib to compile to, what package system to deliver, what is neccessary to read the help files of the app etc... The LSB addresses such issues and more.

RPM may not be perfect in some folks' eyes but it is used by many distributions.

The LSB provides minimum functionality standards! There is nothing to stop others from building on them. Who knows, maybe deb will get even more popular and the standard will then adopt it instead of rpm?

Heck, I like jar files with Installshield for Java in them. I also like tar.gz/Z/bz2 files and shell scripts with embedded install files in em. I personally don't care as long as they work.

> I believe that the user's free choice is the
> best standard-making-body it does not matter if
> you got a certificate or not if your
> distribution is crap.
What is wrong with having your cake and eating it too? Why not have these minimum standards to satisfy the commercial software producers AND still keep the ability to innovate with new technologies?

Example:
In the USA, most electrical sockets have the same format. Two vertical slots sometimes with a ground and maybe a different size for one of the slots. You can go out and buy a commercial appliance and almost always be able to plug it in. The voltage present on the socket is approx 110-120VAC which is also good.

Now, imagine that you couldn't depend on the voltage or the configuration of the socket? Life would be needlessly more difficult. Get it?

Remember, you are free to fsck with your power socket as much as you want but you will have to live with your modifications. Don't expect everyone else to feel the same way you do.

Anyway, peace.

Re:certifications...

[Eric Damron]

"I believe that the user's free choice is the best standard-making-body it does not matter if you got a certificate or not if your distribution is crap."

Well, as a programmer, I would prefer to write code for a distribution that contains standard lib versions etc. I don't see 42 main classes of standards with 42 subclasses of each coming down the pike.

I can see products coming out for Linux that have "This software runs on LSB Compliant platforms" labels on the packaging.

Re:certifications...

[Rashan]

I believe that the user's free choice is the best standard-making-body it does not matter if you got a certificate or not if your distribution is crap.

It doesn't matter to current users, probably... but future users? As someone who is currently thinking of switching to a flavour of linux, and has no idea which one to switch to, any kind of guide towards a decent distro is a "good thing." Especially since if you ask 3 Linux users which distro you should use, you get 4 different answers and at least one dirty look for not knowing already. ;)

Re:certifications...

[jukal]

Hey, I am too much a coward not to admit at this point, that the previous comment by me was crafted just as provocation to get good reasons why we need this certificate. Now, we got plenty of them :) Thanks! :)))

Versions?

[anakog]

The article forgot to mention which versions of these distributions got certified.

I am curious in particular about Red Hat's distro. I am sure that 8.0 will be LSB compliant but does anyone know about 7.3?

Re:Versions?

[Anonymous Coward]

This link tells you some LSB test suite information.

Re:Versions?

[Anonymous Coward]

Conduct your own LSB test on your distro

Re:Eh? What ya talking about?

[Anonymous Coward]

So most of the following is just packing peanuts to prevent the binaries from breaking during shipping?

$ ldd `which xterm`
libXft.so.1 => /usr/X11R6/lib/libXft.so.1 (0x40026000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4004f000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x4009a000)
libXaw.so.7 => /usr/X11R6/lib/libXaw.so.7 (0x4009f000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x400f1000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40105000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4014f000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40158000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x4016e000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4017c000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40189000)
libncurses.so.5 => /lib/libncurses.so.5 (0x40263000)
libc.so.6 => /lib/libc.so.6 (0x402a1000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

LSB vs FHS

[peterpi]

Forgive my ignorance, but how does the LSB relate to the Filesystem Hierachy Standard. Is it a replacement?

Re:LSB vs FHS

[deblau]

LSB is an attempt to standardize many aspects of a Linux distribution, such as binary (executable) file format, dynamic libraries, packages, and system initialization. They also standardize file system format, and the LSB 1.2 is FHS 2.2 compliant.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Eh? What are YOU talking about?

[__david__]

Quoth the heathen:
> But NO, window managers must remain ordinary
> applications, otherwise X turns into something
> brain damaged like Windows or a Mac.

Brain damaged? Who's spouting FUD now? Mac's have Window Managers too:

[localhost:~] david% ps axwww | grep Core
73 ?? Ss 3:15.50 /System/Library/CoreServices/WindowServer
228 ?? Ss 0:00.29 /System/Library/CoreServices/coreservicesd
272 ?? Ss 0:00.10 /System/Library/CoreServices/SecurityServer
286 ?? Ss 0:00.71 /System/Library/CoreServices/loginwindow.app/login window console
289 ?? Ss 0:03.53 /System/Library/CoreServices/pbs
303 ?? S 0:05.07 /System/Library/CoreServices/Finder.app/Contents/M acOS/Finder -psn_0_262145
304 ?? S 0:01.21 /System/Library/CoreServices/Dock.app/Contents/Mac OS/Dock -psn_0_393217
306 ?? S 0:08.16 /System/Library/CoreServices/SystemUIServer.app/Co ntents/MacOS/SystemUIServer -psn_0_655361

Mac OS X is less brain damaged than you think.

-David

Re:/. Slow?

[Czernobog]

It's the middle of August for RMS's sake.
Contributors and readers are probably away on holidays.
Only people who are either too busy for their own good or have come back (or worse, have not grasped the concept of rest) are here....

It's close

[hendridm]

Debian 3.0 did pretty well compared to SuSE.

Link shamelessly stolen from this post.

MDK?

[xanadu-xtroot.com]

I'm all for a standard here, but MDK? How is MDK compliant with something like this:

~/.kde/share/applnk-mdk-simplified/.hidden

for a menu item location. Are they all using the MDK extension now? Unlikley. Is MDK changing that? Unlikley since the 8.2 release was tagged as "Standards Compliant" somehow.

Don't get me wrong I like MDK, I'm on a 8.2 (heavily upgraded) box typing this, but "Standards Compliant"? No way.

Re:MDK?

[tg_schlacht]

IANALE - I am not a Linux expert. (But I ain-t Joe Six-Pack either.)

From my reading of the LSB it seems to address base level system issues:

- Having at least the minimum standard set of base, utility, and graphic libraries.

- Having at least the minimum standard set of system commands.

- Having standard init script actions, comments.

I don't see anything in the LSB regarding the location of window manager configuration files. Maybe they will add something regarding that to the standard in the future.

For now the focus of the LSB seems to be standardizing distros so that applications will install to standard locations, can expect standard libraries to exist, and can expect that system configuration information will be the same across distros.

Re:debian??

[Anonymous Coward]

> debian is most widely used
Debian is very far from being "most widely used".
> howcome a nonprofit 'standards' body can ignore a standard like the deb packaging standard?

which features make deb better than rpm ?
please be as specific as possible.
> apt is so good that it is getting ported everywhere...
your so much loved apt can be used with both rpms and debs

Apt get RPM (has nothing to do with this post)

[gnugnugnu]

Not that I would ever be insane enough to put apt in a cron job like the typical Debian user

A typical Debian user would not do this. Good god, that's a recipe for disaster!

Not that i believe there is actually such a thing as a typical debian user but one might do this not for the sake of upgrading but rather for apt-get security updates.

obviously for any large scale installation you would want not want to do automated installation except on a test machine and only later update the rest of your network.

Not good idea

[pardasaniman]

If GNOME has a bug that causes your computer not to function. At least you can use KDE. KDE has a weird glitch on my graphics card that GNOME does not have. If the two were the same and if they both had the glitch, I'd be using windoze right now.

Re:Eh? What ya talking about?

[elflord]

So most of the following is just packing peanuts to prevent the binaries from breaking during shipping?

These libraries are not "layered" on top of each other. The different libraries provide different functionality. For example, ncurses handles terminal IO. libXaw provides widgets, ICE provides authentication services. You are confusing "modularity" with "bloat"

I dont know if it means anything

[q-soe]

But it is interesting to note that the three standards all have soimething in common ...

1. Built on Red Hat
2. Commercially sold and focused distros (sure you can download them all but Suse is some 7gb of packages with no ISO and to purchase personal in AU costs $175...) they are the 3 distros which appear most focused on packaged box products
3. ALl 3 like to see themselves as leaders in the open source movement

This comes to mind after the self annoucement on Mandrakes site that they were on of the standard distibutions of linux.... and they are part of the standards groups as well...

Come on - the fact is that the three distros are built on one base - Red Hat. They use the same packages in most case and in my mind are pretty much the same thing.

If LSB wants to be a serious thing instead of a back slapping software tick then they need a diverse Standard - the best GNU Linux at the moment for development and use from all i have tried is Debian yet its not a standard... What about Slackware ?...

In short doing a bit of investigating of the members of the LSB groups and the supposed standard bearers may make some things clear... i did - and the terms of the standards make it clear that rather than the 3 mentioned distibutions being the best the fact that they were the 3 who submitted and that they all use the one base and RPM seems to indicate simply that Red Hat is an industry standard..something we all knew anyway.

Re:I dont know if it means anything

[jbolden]

Slack is all about do it yourself, individual system admins setting up things the way you want. They are sort of like an anti-LSB. Debian is anti commercial binary only distribution -- make works great for any distro if you are willing to ship source. Given the LSB's goals I don't know that these guys really need to be a part of it. Given the LSB's name OTOH they need to include more distros.

IMHO the problem is the name not the goals.

Re:I dont know if it means anything

[legis]

>But it is interesting to note that the three standards all have soimething in common ...

> 1. Built on Red Hat

Hum... SuSE is not based on Redhat.

Re:I dont know if it means anything

[q-soe]

Hum... SuSE is not based on Redhat.

yet it uses standard RED HAT rpms.....

HMMM the plot thickens. or does it... The fact is that large parts of it owe a lot to Red Hat linux no matter how far it has diverged..

Im not even going to get into the uselessness of the personal edition with all its missing apps, the lack of DVD support, the concoluted installation, the no iso policy etc etc. Basically Suse are not whati would think we want to be the standard for linux vendors, sure they produce a great product.. at a price. But when its approaching 80% the cost of a Windows XP license (here in AU) for personal and thats missing many apps mandrake and debian have for nothing then i have to wonder.

If it uses RPM it uses some Red Hat code... sorry but thats the facts maam

Re:I dont know if it means anything

[Anonymous Coward]

SuSE is not built on RedHat.
The only thing SuSE had ever had in common with RedHat was the use of RPM as the package format.

Re:I dont know if it means anything

[LinuxGeek8]

If Suse uses rpm it doesn't mean right away that they are based on RedHat. If they changed nothing, but only switched from rpm to deb, would that mean they are suddenly Debian based?
They started as a Slackware clone, and added rpm along the road. You can still see a lot of Slackware in the startup system. In fact, they are a mix between SysV and BSD, they use an /etc/rc.config script, and they use init scripts. Very confusing to me, but that wasn't the point. The point is, they are based on Slackware, and moved a bit towards RedHat (rpm and SysV).

Re:I dont know if it means anything

[legis]

First of I do not understand your attitude. I was just pointing out to you that SuSE is not based on Redhat and not whether their policy is good or not. If you must know SuSE Linux is based on Jurix (an older German distro).

> yet it uses standard RED HAT rpms.....

So what, RPM is open source. At the time of their switching from tar.gz (before Debian) everyone was standardizing on RPM.

> Im not even going to get into the uselessness of the personal edition with all its missing apps,

I also think that the personal edition is a waste of time

> the lack of DVD support,

LOL, I can play DVD's just fine. SuSE is also packaged on one DVD as an alternative to the multiple CD's. How can someone install it if SuSE doesn't support DVD?

> the no iso policy etc etc.

So, do an ftp install. No one is stopping you.

> sure they produce a great product.. at a price.

I just checked on cheapbyte, SuSE Professinal is US$78.00, Redhat Professinal is US $196.00, and Mandrake Prosuite (closest to SuSE Pro) is US$141.00 . Also remember the term Free software means freedom to look at and modify the source and not cost.

> I refuse to argue with Anonymous Cowards - if you want a discussion get an account....

Excuse me, since when did I post as an AC?

Charles

Re:I dont know if it means anything

[q-soe]

Fair enough guys - if im wrong on the redhat base then i am wrong and i will admit it.

I still modify nothing about my comments on SuSe and their ISO etc and personal edition but if i am in error then i am . Thanks for pointing that out with courtesy..

BTW Charles - the AC is my sig and not directed at you

Re:I dont know if it means anything

[joestar]

> But it is interesting to note that the three standards all have
> soimething in common ...
>
> 1. Built on Red Hat

Sorry but Mandrake isn't built on Red Hat.

Re:I dont know if it means anything

[legis]

> BTW Charles - the AC is my sig and not directed at you

Thanks for the clarification, I over reacted. :-)

Charles

Re:I dont know if it means anything

[legis]

> Sorry but Mandrake isn't built on Red Hat. Don't know about now, but when Mandrake first started it is nothing but Redhat with KDE. Charles

Re:I dont know if it means anything

[joestar]

> Mandrake first started it is nothing but Redhat with KDE.

Firstly, the first Mandrake were more than that : they include many hacks to ease install and use and to get access to devices more transparent.

Then, Mandrake completely stopped to base on Red Hat since version 6.0 in 1999, three years ago. Just have a look at packages lists and kernel/glibc/gcc... they are never the same. Even Mandrake & Red Hat kernels are _very_ different (more features in Mandrake kernel, and Mandrake ships with different kernels: Mandrake Linux kernel, entreprise kernel (which comes with SMP & crypto stuff for instance) and "vanilla" Linux kernel, without any hacks/add-ons).

Re:I dont know if it means anything

[legis]

Thanks for the info. It is good to know.

Charles

Re:I dont know if it means anything

[FooBarWidget]

> yet it uses standard RED HAT rpms.....

Wrong. It uses the Red Hat PACKAGE MANAGER; in short: R P M. It doesn't use the packages from RedHat, it uses the *package manager*!

The package manager is only an application with a database. Just because SuSE uses that application & database doesn't automatically mean that the entire system is based on RedHat.

library compliance?

[small_dick]

so, how does this relate to base development libraries? it's a major PITA to d/l a cool project to see how the source works, only to have ./configure bomb out 7/8ths of the way through.

Use of packaging to distribute software internally

[aegilops]

Interesting thread RE comparisons between RPM, apt, ports etc which I have some familiarity with but not enough to argue with the beards. However what I would like to see is some work on how an admin can centralise package distribution to internal users.

From personal experience, most of these package managers are focused on the end user making the decision to instigate an upgrade, however that is achieved. The execution of the upgrade is also within the hands of the end-user. However consider the scenario where you have a number of open source desktops and you have responsibility for ensuring that your users (a) have access to the applications they need (which will vary from user to user), (b) incorporate upgrades on a mandatory basis based upon criteria that you specify (e.g. security patches, other app patches you decide are required), (c) these applications are available to users wherever they log in, (d) they integrate well with whatever window manager you choose to use.

Now, I know this is easy to say and represents a lot of work, especially the WM integration (exactly how many WMs are there out there?) but consider from a corporate perspective - it's not going to look to good when you start advocating the current methodologies for obtaining packaged software for desktops when compared with MS Group Policy package distribution, Novell ZENworks, IBM Tivoli ...

If you're going to review the current approaches to package distribution, and hopefully build an open standard at some point to fit in with LSB, then at least keep the door open for a centralised software distribution mechanisms.

Aegilops

exactly

[martin-boundary]

I agree with you completely. The real advantage of Debian is that the package maintainers have to abide by such a high standard. When you install an official Debian package, you have a really high expectation that it just works well with your existing system.

Commercial linux systems have lower package management standards compared to Debian, maybe because they want to be more cutting edge (ie Mandrake), and maybe because they have fewer official package maintainers or different corporate priorities.

It's the people, not the package management software that makes the big difference.

support

[Anonymous Coward]

this will be helpful for technical support...

Wrong. Simple counterexample.

[BlowCat]

Suppose that some commercial development tool requires gcc-3.0.1 or above. They make an RPM. What should they require? "gcc >= 3.0.1"? Wrong. A user of RedHat 7.2 can have gcc-2.96 and gcc3-3.0.4. Maybe "gcc3 >= 3.0.1". Nope. RedHat 8.0 will have gcc-3.1 (maybe even gcc-3.2) and no gcc3 package.

Handling of incompatible versions of the same software is done ad hoc, without any strictly established and well designed rules. Either the old or the new version gets a number appended to the package name (glib10, kde2, gcc3).

BAH! Who cares about RPM?

[rutledjw]

Look, after using Slack, I find RPM obnoxious and much more difficult to track down. The Slack package installer is much better. But one can get around these differences tanks to the -f tag.

What gets my goat is the location and use of config files. It's very clear on Slack what files handle what and the configs can be handled on the file level. On RedHat or Mandrake, this is inconsistent. Example. If you DON'T boot into X on Mandrake, tell me how to switch the default Window Manager. In slack it's a matter of changing a symbolic link. There are other examples.

I don't want to start a distro holy war (and there is always one brewing just under the surface), but these differences are not good. A better commercial example is Mandrake vs SuSE. Both have pretty widespread use in the commercial arena, I've used both on commercial projects, but again, the config loacation and use is not consistent.

I don't know if ALL of these things have been solved by the LSB, but if not, then there is a failing which needs to be resolved...

/rant

need beer

What about POSIX?

[Chexsum]

LSB isnt helping much when there are files all over the place, programs being renamed each revision and tools being hacked up to only work with GUI.

LSB is a start and it is crazy that GNU/Debian will not be included in this list when it has been following its own policies and standards for a long time. LSB is for RPM Distros. RPM means RedHat Packaging Manager.

GNU/Debian/Linux is the best choice in Distributions for people who like contributing to a Portable Operating System *gee look at those words and think what anagram is made up from the words - thats right POSIX*. =)

warning: troll

[Anonymous Coward]

If suggesting "icon support", "font support", or "higher-level networking" should be brought into X wasn't a tipoff that this was a troll, the line "12% to 37% faster" clinches it.

MacOS window manager

[jmorris42]

Yes it is a seperate process on OSX, but don't expect replacements anytime soon if Apple has any say in it.

On the whole, OSX does kinda toss old views of the Mac into the trash. I have been playing around with some iMacs running OSX recently and it's almost but not quite familiar territory. Neither fish nor foul if you take my meaning. But gimme three buttons on a TiBook and I'm there when my Thinkpad's warranty runs out.

Guh... RPM sucks

[mark-t]

Unless it becomes possible to manually update your rpm database so that when you later use rpm it will realize you have some package that you may have grabbed as a tarball and compiled from source rather than used the rpm for. You can't just get away with using --force in this case because you may _WANT_ it to check dependancies, just that for certain packages already on your system, you may have a better idea of what's actually on your computer than rpm does. I know I did when I lost my RPM database, with no way to rebuild it.

(rant concluded)

Re:Guh... RPM sucks

[Anonymous Coward]

If everyone included a .spec with their software, life would be much better.

How exactly do you propose that the database is rebuilt from the existing system? Without the database, you don't know which files belong to what package. So it's impossible to recreate.

Why not backup your database?

Re:Guh... RPM sucks

[mark-t]

It's funny that every single person I tell this to asks exactly the same question.

The answer is obvious... You don't attempt to automate the rebuilding, but a system administrator could tell rpm that package xyz, for example, was already installed on the system, even if it hadn't been installed with rpm, or the rpm database got corrupted and needed to be rebuilt. This would be done manually, one package at a time.

It's actually not as big a pain in the ass as it might sound because most rpm packages don't have that many dependancies. A typical scenario might go like this:

• User tries to install rpm
• rpm says that it needs package xyz
• User recalls that he *did* install package xyz himself, but not via rpm's.
• User doesn't want to specify --force because that would override other, unknown dependancies
• User quickly patches rpm database using a utility (one currently not available, but in an ideal world, would be)
• User tries to reinstall package again
• software installs normally because that was the only unsatisfied dependancy

See?

Re:Guh... RPM sucks

[JM_the_Great]

RPM spits out a list of packages that you need - if you see you have all of them, then great, do a --force. If not, install the ones you don't have and then use --force.

Re:Guh... RPM sucks

[LinuxGeek8]

You do have a point, it would be nice to have a utility to add a package to your rpm database. There are a few projects working on that, but it's not a major movement. You could check out checkinstall for example.
I myself mostly build my own rpms, if there aren't any available. But for most people, building from source is hard enough, or even too hard. Building an rpm and specfile from source is a bit harder, you have to understand what .configure, make and make install do.

On the other hand, if you choose to install software by hand, from tar.gz, you bypass the rpm system, and become package manager yourself. So it's up to you to remember what's installed, and to know when you can use --nodeps (not --force).
It's a bit easier then the way you tell it. First you can do an rpm -Uvh, which will tell you if there are missing dependencies. If you know you have those dependencies fullfilled, you can try again with rpm -Uvh --nodeps, and it will install, and there won't be any unknown dependencies, like you say.

And yes, rpm sucks, so does deb and tgz and source. All in a different way, but none is perfect.
Imo it's just the best there is currently for binary based distributions.

Btw, I haven't had a corrupted rpm database in a long time. And if it happened, a backup would fix it within a few minutes.

Re:Guh... RPM sucks

[Anonymous Coward]

rpm --justdb

may be helpful to you..

Re:Guh... RPM sucks

[FooBarWidget]

Have you read all the other comments? deb != apt && rpm != no auto dependency downloading!

It's dll's not installshield that's the key.

[sg_oneill]

Microsoft , to it's credit, seemed to make a concious effort to make sure it's API's remined consistently backwards over time. DLL's from microsoft, (notable exceptions.. Fucking wang/kodak imaging library, grrrr) can be updated without too high likelyhood of slaying previous versions of software.

Unfortunately the haphazzard linux update cycle has tended to mean that one needs the correct libraries for each expected invokation (eg ver 6.7 AND 6.8 rather than just 6.8).
Think KDE here.
That's where the magic of debians apt stuff kicks in. The program really does not much except maintain a well pruned dependancy tree and make sure that libs are there (and autogets them if necesarrily), the magic is that Debian lords with an iron fist over packagers and make sure that package descriptions list EXACTLY what is needed. I have no doubt that apt & RPM are a groovy enough combo, but one still depends on a central body to enforce strict rules to enforce compliance.

With out that, dependancy-fucking your box hasn't gone away, it's just become automatic.

urpmi is not enough

[fireboy1919]

urpmi will only deal with stuff in its database ONLINE, you can't add a new package to its database which isn't available online (very easily). In addition, eventually, the package list online changes (when Mandrake goes to the next version), and all of your old rpm installs don't work as libraries with anything new you install, and there's nothing you can do about it but a MAJOR upgrade. Also, currently, it doesn't really do versioning well, that is, you cannot have multiple versions of the same software unless you specify that its something completely different, and that the files go in a different spot on the system, just as rpm doesn't. Also, its not easy to create rpm files; it often takes some work.

urpmi does only one thing better: it keeps a record of a website which lists packages. The problem is not the lack of a wrapper, its the lack of features built into the whole RPM model.

Not all distros have a package management system with all of those features, and I'm not sure all of the ones that do. I only know that Mandrake, my old distro, did not have them, and that Gentoo, my new distro, does.

LSB is for commercial software packagers

[Anonymous Coward]

"Since the big need for the LSB is for commercial software packagers.... see the problem?"

YES, i do see a problem.

NON-commercial software packages make up 99% of all linux software.

IAgreeWithThisPostKinda

[Anonymous Coward]

I think XFree needs to die, but since KDE is a serious memory hog, you'll be defeating the purpose. What's needed is a local only GUI with a light but extremely flexible window manager like TWM. Hell, I'll run TWM before I install KDE again.

I love this stuff.

[ubernostrum]

I've been running Red Hat for two years now. Where's the "dependency hell" everybody talks about? I've gone from 7.0 to 7.3, doing each upgrade in turn, installed all sorts of stuff in between upgrades, never had any problems. So I have some issues with what you call a "typical" install on Linux...

Re:Eh? What are YOU talking about?

[FooBarWidget]

Then you've just given a reason why window managers in X should stay.

Haskell?

[axxackall]

Haskell is a drag?

What's wrong with Haskell and is it related here?

I assume we talk about the same language

Re:Haskell?

[JanneM]

Nothing wrong with Haskell to my knowledge; I just picked it as an example of a perhaps unlikely scripting language. My point was rather that whatever you pick, it's not going to be popular for a lot of people.

/Janne

Re:Haskell?

[axxackall]

My point was rather that whatever you pick, it's not going to be popular for a lot of people.

You are right. Most of software development is performed using very primitive tools. Professional software developers prefer either VB or Java, mistaking professional programming tools (which Java and VB are not) with programming tools professionally marketted (by MS and Sun).

Unfortunately, Linux faces the same problem. For example RBAC is well known for awhile, but for Linux it's still in experimental dreams. Python was proved as the best scripting and OS-automation language, but sysadmins still keep creating write-only Perl kludges. Long time ago CVS was proved as too primitive for serios and complex development projects, but alternative versioning systems still are not popular. RPM is known as the most primitive package management tool, but Gentoo's Portage was even not considered for LSB.

Too bad, the world doesn't love the best. The world loves tools, which everyone can understand quickly. Everyone, including uneducated ones.

Gentoo Portage?

[axxackall]

There is a lot of comparing of RPM versus DEB. But is that it? How about Gentoo Portage system? It seems even more advanced than Debian packaging system. You can get more info here and here.

Our company seriously considers Gentoo as it helps to build a Linux distro (or two) customized for specific corporate needs. Our research shows that with RPM or DEB we'd spend more resources on creating and supporting own distros.

It doesn't mean anything

[sapped]

If LSB wants to be a serious thing instead of a back slapping software tick then they need a diverse Standard - the best GNU Linux at the moment for development and use from all i have tried is Debian yet its not a standard... What about Slackware ?...

I beg your pardon!? A diverse standard!? Are you smoking the really good stuff!?

A standard is supposed to be something that remains...well gosh STANDARD! - not something which changes every couple of months!

Check out CNET.

[ubernostrum]

They have an article about this which mentions that the three certified versions are Red Hat 7.3, SuSE 8.0 Professional, and Mandrake ProSuite 8.2.