Why Mandrake is Too Cool for UnitedLinux

An anonymous reader says "Mandrake's lastest community (spam) newsletter contains their explanation as to why they won't join in on UnitedLinux. Besides the obvious geek-fun of rolling their own distro, they claim that the underlying idea of UnitedLinux is based on a flawed comparison to the Unix world of the 80's. " I think the whole UnitedLinux thing is lame- the distros that want to be compatible already are. UL is just the 2nd tier distros trying to get attention and ink away from the "evil forces" in North Carolina. I'll just stick to the best distribution and watch the fun from afar ;)

Comments

Spam

[Anonymous Coward]

Why is it spam if it contained information useful enough to be posted on slashdot?

Good for Mandy

[Apostata]

I think this decision will not only please Mandrake's huge user-base (or at least those who give a sh*t), but also earn Mandy a little more respect from those who constantly refer to it as a Fisher-Price distro.

mandrake

[gralem]

Mandrake is simply the best distro out there. It doesn't get bogged down by "this package uses the wrong license" or "this is too cutting edge" or "this is too average user", either. They simply go out there and offer their users EVERYTHING in the linux world. I will always only install Mandrake.

And not becoming a part of United Linux is partly due to the above and partly due to their use of RPM. I think they're doing the right thing, and the United Linux people fill fall big time.

---gralem

Re:mandrake

[Matt2000]

"I will always only install Mandrake."

This is clearly retarded. Why do computer dudes always throw down insane ultimatums? It gives us a bad name and it's the reason people in companies don't trust us.

"DOS 6.3 is the last operating system this company will every use, PERIOD."
"Get out."
"Ok."

At least they're committed to LSB.

[Anonymous Coward]

I am not a fan of mandrake, but this is an extremely well-written document all the way through. I would like everyone to take note of the fact Mandrake seems to be committing in here to follow the LSB.. so that's good. One thing i wonder about though:

"In the same spirit, all software publishers should certify their products for a given version of the LSB (Linux Standard Base), not for a particular brand of Linux. Therefore, that software would work equally well with any Linux distribution that is in conformity with the LSB. "

Is this correct? The UnitedLinux people have been implying that they are somehow just the logical conclusion of the idea of the LSB, and in some way they will make things easier for developers-- i.e., less varied systems to test. Is this correct, or just misleading marketing? Are there any situations where it would be possible to certify a single binary for UnitedLinux, but not possible to certify a single binary for the LSB becuase the LSB is not extensive enough?

Mandrake is closest to getting to mainstream

[StandardCell]

As a (relatively new) Linux user, my first distro was Mandrake 8.1. What's nice about Mandrake is that there are GUI interfaces for everything. I mean, I've been working with Solaris and HP/UX for years and writing perl scripts and scheduling cron jobs, but never had to deal with "admin-type" issues like drivers and installing software and hardware. I don't mind going in and trying to figure out command-line switches for various tools and turning system services on and off. Mandrake is getting pretty close to the ideal, particularly with its HardDrake detection and its unbelievably good disk partitioning tool. That's not to say that it's perfect - I still think the whole package/RPM thing needs a lot of refinement, and there are bugs like losing sound on my A3D card for no reason (a known KDE problem). In fact, there's the rub - when it comes to ease of use, Windows still has Mandrake and the rest of the Linuxes beat hands-down. But like I've said before - with 10% of the development budget of Windows products, and buy-in from major software developers in multimedia, Linux could be a Windows killer. Just like UnitedLinux is supposed to do. Therein lies the problem - do you take the distro with the currently closest emulation of Windows' ease-of-use and push it to effective completion, or do you go and pool development efforts to make all the rest of the distros good? My hope is that cooler heads and better attitudes prevail, because many Linux distros and the fate of Linux on the desktop lies in the next move made by all Linux companies.

"best distro"?

[vogon jeltz]

"I'll just stick to the best distribution and watch the fun from afar ;)"
Well Taco, it might just happen that United Linux fits your needs perfectly then: http://www.debian.org/News/weekly/2002/25/

UnitedLinux is not the solution

[bigjocker]

We Linux users know there is a problem with the current linux distributions. It's not only an interoperability problem, but a core one. We have came to a point where we knew we were going to get to, but we haven't tought of a solution because we were making linux ready for the mainstream. Now is the time to solve this, UnitedLinux is a start, but, as many of you, I dont like the approach they took.

We all know all the problems with RPM based distros, compatibility between them breaks a lot, and, even if you should have only one RPM for any distro, when we go to download an application we get a RH6.X.rpm, RH7.rpm, MDK8.rpm, MKD8.1.rpm, etc ...

I'm a Mandrake user, and I love it, but I have seen apt-get working, and I'm really impressed. I think apt-get is the right direction for a real package management tool for all distros. This is the direction package managment under Linux should be taking, and not creating commercial standards without atacking the core of the problem nor creating apt-like solutions or apt-like-frontends for rpm based solutions.

Conclution: LSB + apt-get should be mandatory to be able to call anything a Linux distribution. I know a lot of us would kill for apt-get to be the default package manager in all distributions.

Re:UnitedLinux is not the solution

[bigjocker]

There's an RPM version of apt-get at freshrpms.net [freshrpms.net]. It's for Redhat but I don't see why it wouldn't work for Mandrake.

That's exactly what we shouldn't be doing. Is the RPM package/dependencies list available to the apt packages? is the apt packages list availabe to RPM? Do they use the same notations? Ah, I see, making a RPM version of apt-get solves the problem, because we need more front-ends that hide a poor designed system.

We need to stop for a second and rethink a lot of things, and among them is package distribution for linux. No matter which distribution we use or we make, this is a issue that is comming back to us right now, and if we don't do anything it will get a lot worse in the future.

Re:UnitedLinux is not the solution

[captaineo]

Yes, I'd say that RPM + automatic dependency downloader = APT. However, the important thing is that the developers of APT-based distributions traditionally pay a lot more attention to forward- and backward-compatibility than RPM-based distros.

As you pointed out, on Debian the major library version number is appended to the library name, e.g. libgnomeprint0. This is because the Debian people know that at some point in the future, the GNOME developers *will* break the libgnomeprint API. Then they will label the new package libgnomeprint1, and all your software continues to work. On Redhat it would still be named libgnomeprint, and you wouldn't be able to install the new version until all apps using the old version are fixed and recompiled...

Give APT to the Redhat folks, and before long you will end up in "APT hell," I guarantee it =).

glibc and gcc breakages are a separate issue. The developers of those packages need to be shot... I've read posts to the gcc mailing lists regarding libgcc that show most gcc developers haven't the faintest idea what "backwards compatibility" means.

Why you're all incorrect about UnitedLinux

[k8to]

UnitedLinux is clearly an attempt to raise the commercial value of compatible and LSB-compliant linux distributions.

The Mandrake solution of 'blindly do whatever RedHat does' does make things somewhat compatable, but there are a lot of drawbacks to this strategy, and it doesn't really help the commercial software vendors at all if Red Hat decides to change what they provide from version to version. (And they do.)

The Linux Standard Base is useful, it is relevant, it is important. This draws attention to and raises the bar of interest in this regard.

Now, please explain, all you slashbots, how this is a bad thing?

Re:Why Mandrake is right

[ceswiedler]

Dynamic linking is bad, and we should all go back to static linking? Well, why don't we get rid of this whole "networked computers" thing and go back to timeshared servers?

Dynamic linking has its problems, but the answer isn't "statically link everything". There should (and can) be a clear separation between changing the interface of a dynamic library and changing its underlying implementation. All of my applications which use zlib should benefit from upgrading the shared library to fix bugs.

Microsoft has tried to answer this with COM, where COM objects have interfaces which never change and instead create a new "version" of the interface if it needs to be updated. It's no panacea but it's the right idea.

The problem is that programming is hard. There's no quick solution that will fix all of these problems, and we don't need to go back to static linking either. Developers need the discipline to use the techniques which answer the problems effectively. And there is no way you can convince me that open source developers have more discipline in that area than proprietary developers.

Why Should Success == evil forces?

[BRock97]

Over the last few years of open source, why is it that when an open source company becomes successful financially (and by this, I mean is able to operate without going under), they become the source of evil-ness in the eyes of others? I understand that Taco put the "evil forces" in quotes to indicate a certain level of sarcasm, but to some in Open Source Land, they do see it this way.

What has RedHat done that is so bad? Sold out? Stifled innovation? As far as I am concerned, no, they have not. In fact, I am very happy with their products on the server level and use it on three production machines at my local university. The Airforce is even looking into using servers running RedHat. Not only does their stuff run well, but it gets good name recognition for Linux as a whole.

It isn't just RedHat, either. I am sure that if the Apache Foundation were to go private and start selling a commercial version of Apache httpd AND become commercially sound, they would be looked upon in the same way.

I am asking in all seriousness. I want to understand this mentallity.

Re:Why Should Success == evil forces?

[tempest303]

I must respectfully disagree with a few things here:

They have encouraged proprietary software vendors to release their wares in a manner that is compatible with Red Hat and not other distributions, by falsely implying that they, Red Hat, set the standards and everyone else follows.

This is true to an extent. Red Hat did essentially "go their own way" in some respects, setting up their own standards for some things. The most notorious of these breaks is, of course, the use of GCC 2.96 instead of 2.95. This caused a lot of controversy, and deservedly so, but it's what they felt they had to do for their distro. They had customers who required the enhancements of 2.96, and so they met those needs. They took a lot of crap for it, too, but they stuck to their guns (and the customers they were serving).

RH also took some liberties with file system layout, etc. They obviously felt it was important enough to make the change, so they did.

What I'm trying to illustrate here is that in both cases, RH did what they did not to lock out other vendors, or to hyjack the industry, but rather to apply what they felt was some needed sanity into certain aspects of Linux. However, the community has now "caught up" to Red Hat's changes, by releasing GCC 3.x, and the LSB 1.1 spec. RH's next distro (which will undoubtably be called 8.0) is going to be using GCC 3.x, and will be LSB compliant. So it seems to me that Red Hat has only been doing what they felt was necessary until the community made their decision on the direction of things, and then RH re-converged their distro with the community at large.

it is quite possible, and vastly preferable, to package software in a distribution-agnostic form installable by evertyone. Blender did it, Loki did it, Id and several other proprietary vendors do it now.

Yeah, but they did it by making nasty custom installer scripts, typically with no uninstaller! Eek! This might be nice for Slack or Gentoo people, but how about an RPM for the RH, Mdk, Suse, Caldera, and (via alien) Debian users? What's more, they probably also statically linked the stuff to hell and back. I'd prefer to see 2 releases - LSB and non-LSB. A nice RPM for LSB compliant distros, and non-LSB for people who don't give a stuff. ;-) The LSB people are rewarded with package management, and smaller executables, and a smaller memory footprint, but it doesn't keep out the people who aren't compliant.

While I'm on the subject, who isn't compliant now, or won't be by Fall? RH will be fully compliant with 8.0, MDK is/will be soon, all the United Linux distros are/will be (SuSE, Caldera, Connectiva, Turbo), and Debian is/will be as well. What about Gentoo, Slack, and the micro-distros? Anyone know if they plan to conform? FOr that matter, what about Lycoris and Lindows? ANyone have info either way on these?

Re:Why Mandrake is right

[abe ferlman]

when a user installs an application on UNIX, he does not expect that application to install random files in arbitrary directories all over the filesystem. There is no registry in UNIX and no guarantee that the application won't be relocated to another system.

I wish that this were true, but "make install" typically writes to a lib directory, a bin directory, and runs ld to update the library directory listings. Thank goodness it's not a binary-only registry like windows has (ld.so.conf is pretty simple to grok once you know why it's there), but it's not as simple as you make it out to be.

This, in fact, is the only reason I use rpms on my redhat boxen- it's a lot easier to uninstall a package than a tarball that has had "make install" run because the package management software keeps track of where all the files were installed for you.

Did you read the article?

[jaaron]

If you didn't read the Mandrake article yet, I would really, really recommend you do so. It's wonderfully written and an excellent explaination of what a distribution is and how software should be developed. For example:


It is extremely hard for us to understand why some software publishers and hardware manufacturers only support one Linux distribution.

Each hardware manufacturer should develop drivers directly with the appropriate Free Software project. Network card manufacturers should cooperate with the Linux kernel project, videocard manufacturers should collaborate with the XFree86 project, and so on. For example, when a network card module is included directly in the Linux kernel it becomes a de facto standard supported by all Linux distributions.

In the same spirit, all software publishers should certify their products for a given version of the LSB (Linux Standard Base), not for a particular brand of Linux. Therefore, that software would work equally well with any Linux distribution that is in conformity with the LSB.

This article has really increased by respect of Mandrake and shown that they really do understand the Open Source/Free Software methods.

Re:Why Mandrake is right

[Fastball]

Statically linking is not a waste when you consider the cheapness and size of today's storage solutions. Unless you install everything under the sun, this is not a problem. Additionally, you get a performance increase with statically linked libraries. Dynamic linking might have been *the* way of life when storage capacities were in the tens or hundreds of MB, but by no means is it the only viable solution these days.

That said, you are probably right about the expediency of bug fixes through libraries. Still, when you consider the rapid pace of development of some projects, I think this isn't as much of an issue as you might think it is.

Worse than DLL or .so hell is RPM hell. I am sure all of you who have been exposed to this technological travesty agree. When a distribution's installation hinges on the installation of the Perl RPM, for example, you are virtually guaranteeing that you will break something and potentially assfuck your system if you remove or don't install the Perl package in favor of compiling from a tarball.

Treat Base Distro's like XFree (or the kernel)

[Anonymous Coward]

I think we should treat the base Linux distro as a commodity and separate it from other components. We have a group working on XFree, one for the kernel, etc, so why not get a bunch of people together and release a base distro with the kernel, required libs, XFree, command line apps, etc. This base would hopefully be LSB compliant (FHS too!). This way, different companies would concentrate on installers, application choosers, and eye candy (KDE/Gnome/etc). Don't worry, there will still be lots to fight about ;)