Slashdot Mirror
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 ;)
It's redhatesque but it's unique. It happens to be a damn fine distribution also.
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
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?
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.
I think that Mandrake tends to be an early adopter of new features... more so than other more conservative distro's like Red Hat. Whether that's a good thing or not is a whole other discussion- I personally think it's great. Mandrake was (one-of) the first to use a graphical installer, journaling file systems, etc. I imagine being part of a coalition like 'UnitedLinux' would entail restrictions as to what they can and cannot do. I'm glad that Mandrake has decided to continue choosing their own path.
Blender And Linux Fan
Best distro eh? Thats just *begging* to begin a flame war!
Well, yes, considering the best distros can be found here and here.
Personally I like the idea of United Linux. There's no reason that all Linux venders can't use the same base for rpm compatibility, etc. It'll hapen one way or another. Do you want one company to control the standards, or a shared effort?
I think the idea of UL is horribly flawed (and rather arrogant on its part), and the underlying premise of your reasoning for supporting UL equally flawed.
It isn't necessary to have One True packaging scheme, or One True distro to which all must maintain binary compatability, in order to effectively release binaries.
It has already been demonstrated by the folks at Blender, VMWare, Id, Loki, and others that it is quite possible to release binaries that are distribution agnostic. These real world examples, all of which install and run just fine on my Source Mage and Gentoo boxes, as well as my Debian, Mandrake, and Suse boxes, exist despite naysayers saying it isn't possible, and claiming that UL, or UL+Red Hat, bring a much needed cohesion to GNU/Linux.
Nonsense. It is an effort to impose a proprietary embrace-and-extended standard on a community that is doing just fine with consensual standards where they make sense, and a wide open, free and fair marktetplace that encourages choice everywhere else.
Telling commercial vendors that they should package their wares up as RPMs aimed at one (or two) distributions, when it is quite possible, and vastly more desirable, to package them up in standard tar.bz2 or tar.gz format along with a README listing the required libraries+versions, as well as a statically linked "last resort" fallback binary in parallel with the dynamically linked binary and thereby make them compatible with almost every distribution out there, is a terrible disservice to both the Linux community at large, and the vendors themselves who are being misled and excluding a big chunk of their target market.
This nonsense only serves the interests of the purveyors of UL, at the expense of virtually everyone else, and at the cost of our freedom of choice as GNU/Linux users. There is IMHO absolutely nothing good about this whatsoever, regardless of what your favorite distro happens to be, and even though I am not a Mandrake fan per se, I applaud them for their courage in standing up to this nonsense.
The Future of Human Evolution: Autonomy
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.
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
I'd like to take issue with your statements: /opt directory. The config files are in /etc, maybe adding some lbiraries to /usr/lib, probably setting up some symbolic links in /usr/local/bin. For the most part Unix-style distributions keep everything in one directory, but so do most Windows apps.
1. Commercial software companies don't understand dynamic linking.
This statement might be correct in a few cases, but Linux does *not* provide a better development model than windows. The simple fact is that you can statically or dynamically link in *both* windows *and* linux. And ask anyone who's tried to update their libraries in Linux if it's easier than doing so in Windows.
2. Unix Filesystem
So, we've got files in, say the
As for a guarantee that a program "relocated" will or won't work on two systems, the same thing can be said for Linux/Unix.
3. Illegal cartel
I don't know where you're getting this, but you might as well claim that Steven King killed JFK. It's an unfouned conspiracy theory at best, slander at worst. And since when is OPEC or De Beers illegal? Or UL fo that matter?
Your main point is that prorpiatary software developers are incompetent. You use some... interesting justification. Just because there is so much more sofwtare for Windows doesn't mean that there is more bad siftware, but there us *plenty* of bad software (open source, free and closed) for Linux.
Moderation: Put your hand inside the puppet head!
It is a basic principle of dynamic libraries that versions and functionality changes between releases. Ever notice how many different versions of Microsoft's DLLs you have on your Windows box? That's no coincidence - Windows developers are forced to incorporate the version of the DLL that works with their application. Linux provides a far superior development model, allowing publishers to statically link the correct library into their binary. Mozilla does it; Oracle does it; why can't the rest of the vendors get a clue and do the same thing?
.so or .dll to fix a problem in a library used in a number of applications, without having to rebuild every single one.
Ugh. Is this a troll? Am I missing something? Staticically linked libraries are not a 'far superior' development model. Seriously. If you want to use your system efficiently, you really don't want every application completely self-contained. That's a lot of redundancy, and thereofre, al ot of waste. Not to mention the distribution of bug fixes. Linux or Windows, it's much nicer if I can download/build a new
If you want everything self-contained, then throw yourself back to some single-tasked OS from the 70's. If you want to take advantage of modern advances in application and systems design, you're just going to have to get "used to" the idea of some standard that applications can conform to. This could be the LSB or a guide from the OS vendor to which an application is tailored, but you have to have something. Otherwise, your wasting alot of (system/manpower) resources maintaining n-hundred copies of the same statically-linked library distributed throughout your system.
Welcome to the world of modern software. Have a nice day.
-Andrew
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?
-josh
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.
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.
Bryan R.
The price of freedom is eternal vigilance, or $12.50 as seen on eBay.....
Seriously, try it out. It's absolutely wonderful. By far the best way I've found to keep your system from accumulating too much cruft (well, it won't stop the accumulation, but it will make it trivially easy to get rid of later). I've only used Encap, but it's way way cool. When you compile a program, use "--prefix=/usr/local/encap/program-1.0" with the configure script, and then you'll have /usr/local/encap/program-1.0/bin, /usr/local/encap/program-1.0/share, etc . . . Then you run "epkg -i program" and it'll install all the symlinks correctly into /usr/local the way you'd expect. Then you can remove packages, upgrade, etc, etc, etc. Very fun.
Al Qaeda has ninjas!
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.
microsoftword.mp3 - it doesn't care that they're not words...
Because spam means unsolicited commercial e-mail, no matter how useful it is?
That being said, Mandrake doesn't seem to spam - I had to explicitly sign up for the newsletter...
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.
Who said Freedom was Fair?
yeah great
lets see them actually use gcc3.1 before redhat
Nice flamebait.
They are already using gcc 3.1 in Mandrake Cooker, their development distro.
They built everything with it short after the release of 8.2. They tried before, with Mandrake's rpm-rebuilder robot, but a lot of software didn't build with gcc 3.0 then.
With gcc 3.1 and 3.1.1 things look better.
They were the first with devfs in mdk 8.0 I believe, allthough that might have been a bit early.
They were the second distro to use apt-get (after Connectiva), but they switched to their own tool, urpmi, which is working rather good nowadays (apt-get for rpm isn't perfect yet too, you know).
So all in all, it seems to me you put out a rather cheap flamebait; you mostly lack the right information.
Well, don't worry about that. We can get you back before you leave. (Dr. Who)
Any e-mail I don't want = spam
I guess Mandrake is sending their newsletter to *@*.* now, right?
Spam is unsolicited bulk e-mail with a specific commercial pitch or advertisement including a price. Introductory e-mails (especially sent to a specific address), newsletters and business correspondence is not spam.
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.
Mandrake is right on when they say "MandrakeSoft would gain nothing by joining United Linux, and doing so would damage our reputation." Mandrake's claim to fame is their ease of use and GUI utilities, which have been praised and touted in this thread. They are not limited to the desktop, but they do it very well and that is their core competency. The are traditionally not the hardend server Linux you would think of (yes, of course Mandrake makes a fine server, I'm talking about their focus and perception). The UL crew have been very specific on what their target market is; not the desktop, the enterprise server, even to the exclusion of the desktop. Why then would Mandrake be interested in joining such a server focused group? As state, they wouldn't. Joining UL would force them to compete in an area where they are neither the leader or have a competitive advantage. Sure, you can believe all the sanctimonious hoorah they spout if you want, but bottom line is it's bad business for a desktop focused distro to join a server focused organization.
The biggest missconception about UL is that it is some Borg like entity that once you join you must fall in line with. This is just not the case. Each participating member can do whatever they like outside the UL organization. SuSE has stated quite clearly that they will continue to offer a desktop version. This version will (probably) not have the UnitedLinux tag on it, but then for a desktop, who cares? What UL offers is the ability to have your OS certified on enterprise hardware without being lucky enough to have the "defacto Linux standard" in your title (that's RedHat incase you missed it). With that in mind, there's no reason Mandrake could't join UL and realse a UL version, fully certified on all major hardware, with the added value of it's GUI tools, etc. Then Mandrake could continue to sell their deskop/server versions that would appeal to a broader, more price sensitive, customer base.
The second biggest missconception about UL is that it limits competition. This is just the opposite of the truth. To date there is only One distro that enjoys certification across all major hardware line, RedHat. Now, either RedHat has been unwilling or unable to convince it's hardware partners to certify agains all Linux distro's or, say, a Kernel/libs version of Linux. Sure, their are hundres of distro's out there, but only one certified for your enterprise needs, nice if your RedHat. With UnitedLinux there will not be two distros certified on all major hardwere, but five. And, because of the open (gasp) whey UnitedLinux was founded that could grow into as many distro's who care to achieve that level of certification. So, while UL does nothing to prevent a distro from producing whatever they like (thus not hurting competition), they provide the avenue through wich all distro's, not just RedHat, can achieve hardware certifications and compete in the enterprise market.
UnitedLinux is not a bad thing. It is focused on what it wants to do, but ultimately it does what RedHat never cared to, bring the rest of Linux along into the enterprise space. . . if they want to come.
Opus
Someone please mark this date.
Inter-Linux FUD takes over any rational discussion of things.
What do SuSE, Caldera, Conectiva, and TurboLinux have in common? Simple; those four distros are practically the only ones that continue to try to make a profit, and consistently fail. RedHat is profitable, and Mandrake is getting closer every day; Debian, Gentoo, and myriad others are noncommercial distros that have no profit incentive. But SuSE, Caldera, Conectiva, and TurboLinux all want to be the next RedHat, and outside of very small markets, they all failed.
SuSE is RedHat's biggest competitor in Europe, and has the greatest marketshare in Germany. Caldera was formerly RedHat's biggest competitor in the US (until Mandrake came along). Conectiva is RedHat's biggest competitor in Latin America. TurboLinux is RedHat's biggest competitor in Japan.
So, these four distros realized that in every market, there was generally three corporate competitors: RedHat, Mandrake, and one of them. They decided to merge, so that there would be a common distro with worldwide marketshare; but kept the companies separate, so that they could leverage their brand in each market - would Latin Americans suddenly buy a copy of SuSE? As it is, they might fully merge someday, if/when the UnitedLinux brand becomes stronger.
Mandrake knew that they were a strong competitor throughout a very large geographical area; as they said in this statement, their worldwide marketshare is larger than the four UnitedLinux companies combined. Mandrake would have nothing to gain if they had to pool their resources with four companies who are much weaker then they are, and declining all the time.
I wouldn't be surprised if UnitedLinux ends up in a full corporate merger, and later the whole thing goes bankrupt; after reading Mandrake's statement, I get the feeling that they wouldn't be either.
I have great respect for the Mandrake Linux, or any other Linux distribution, for that matter. Making a distribution of any software is hard, and an OS is more complex than most.
But Mandrake is missing the boat... and so is United Linux.
In Mandrake's FAQ entry, explaining why they have decided not to participate in United Linux, they state:
"Since all distributors use the same base
components, there are relatively few binary
incompatibility issues. And even when a
binary compatibility problem arises, it's
easy to recompile an application for a given
Linux distribution."
and they claim:
"It is extremely hard for us to understand
why some software publishers and hardware
manufacturers only support one Linux
distribution."
To me, the answer is obvious: a third party developer would have to not only internally certify their software for support purposes, but it would have to also maintain seperate SKUs (Stock Keeping Units) for each of the Linux versions on which it runs. For commercial applications, "recompile" is not as easy as the act itself. It's clear, these people have never produced a third party shrink-wrapped packaged software product intended to run on a UNIX system.
The intent of United Linux is to try and make it possible for a manufacturer to build shrink-wrapped product that they can know will run on any United Linux labelled platform.
But here, United Linux must fail, as the LSB has failed.
In the original UNIX Wars (of which I am a battle-scarred veteran), the problem was that each distribution of UNIX, even for the same processor family, was "standard plus extensions". Each vendor tried to provide "value add"... and, in doing that, they introduced incompatability between nominally standards compliant platforms.
So paying lip-service to a standard gets you nowhere. The LSB gets you nowhere, and POSIX gets you nowhere. You may be able to compile the same source code on each of these platforms, and, if you are lucky, and did not need to use any platform proprietary information to build your product, it may run without errors. But all you've achieved with this is source compatability.
The LSB doesn't give you binary compatability, and neither does United Linux. And it won't, even if they specify the ABI, even to the point of install tools and other minutia, like IBCS2 did (and neither BSD nor Linux has *full* IBCS2 compliance, until the IBCS2 installation and packaging tools also work -- it's not *just* the ABI, it's the environment).
Why will United Linux fail, since that's what I'm leading up to?
United Linux will fail because it's not possible to *turn off* the vendor "value add".
This seems counter-intuitive at first, but it's a fact. It's the same reason the LSB has failed to deliver on the same promise. And it's the same reason UNIX was never able to be defragmented, when everyone started using Intel processors and commodity PC hardware. Here is the reason:
Standard plus extensions is inherently non-standard.
Let me repeat that:
Standard plus extensions is inherently non-standard.
Until it's possible to turn off *everything* that isn't covered by a standard, it will be impossible for a third party developer to build something that they *know* will run on all platforms that conform to the standard.
Linux vendors: if you want to become the #1 developement platform for United Linux, then strip out everything that isn't covered by the definition of United Linux.
That -- and only that! -- will guarantee that any program that runs on your platform will run on any United Linux platform.
It will guarantee that there is no possibility of a third party developer accidently using a vendor specific extension (OK: "enhancement", but we know that it's really there for vendor lock-in).
It will also make you a commodity.
*This* is what the vendors in the UNIX Wars feared, and refused to let happen. And, in doing that, they lost all the third party development resources to Windows, which *was* a commodity, even if it was one only because of the Microsoft Monopoly.
Will this happen? Will the Linux Vendors wake up to the fact that they nust agree to *commoditize themselves*? Probably not. It's a lot easier for Caldera or Mandrake or Red Hat to compete among themselves, and try and beat each other down, than it is for them to try and take on Microsoft.
So Mandrake... you're avoiding doing the wrong thing by not participating in United Linux, given it's current vender differentiation model permitting vendor lock-in of third party developers.
*But*... you are doing it for the wrong reasons, and as long as you stick to your guns, you aren't going to be doing the right thing for the right reasons, either.
-- Terry