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 ;)
>obvious geek-fun of rolling their own distro
Aren't they just a Redhat distro with some a few mods? If Mandrake is more than that, please explain.
under Linus, indivisible.
--
E_NOSIG
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.
That's "UNDER GNU/LINUS", dammmittt!!!
GRR!!
--RMS
"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/
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 wouldn't say that commercial developers are incompetent, more like 'commercial software houses as a whole are incompetent and lazy.'
It would be easier to code to something like UnitedLinux than support 5 or 6 different distributions. They'd rather just pick one (most just pick Redhat) and be done with it. They're just not willing to invest developer costs.
Love would have everyone believe that Linux is fragmenting Unix-style. But that just doesn't happen with open source. I mean, look at Ximian, they're a relatively small software house, they support boatloads of distributions.
yeah great they did an installer and learnt how to compile src rpm's to what they like but I have yet to see them actually upgrade anything before redhat has put its fix's in
e.g. lets see them actually use gcc3.1 before redhat
regards
john jones
Yes he does. A proper UNIX program will install files in /usr/bin, /usr/doc, /usr/share, /etc, and various other places, as opposed to a Windows program that installs everything in C:\Program Files\$progname, with the occasional library in C:\windows\system
It's hard to be religious when certain people are never incinerated by bolts of lightning.
LINK CORRECTION ... [debian.org] ... should be ... [slackware.com]
heh!
But of course, that should actually read:
I'll just stick to the best distributions and watch the fun from afar
[grin]
Seriously, though, it is this choice that allows you to use and enjoy slackware, and me to use and enjoy Source Mage and Gentoo, others to use and enjoy Debian, Red Hat, Mandrake, and so on, that makes the GNU/Linux community, and the Free Software community in general, so dynamic and so productive.
It is this choice the efforts like UL are trying to undermine, by promoting the myth that commercial and proprietary software vendors should (or need to) package their wares up for one or two reference distributions, rather than packaging them up in a distribution-agnostic manner as Blender, VMWare, Id, and Loki have done. This myth may serve the interests of the distribution promoters in question (in this case, UL), but it is a disservice to the GNU/Linux community as a whole by creating unneeded incompatabilities with other distributions and excercizing some degree of coercion for people to adopt the reference distribution instead. What is more, as other binary releases have proven, it is absolutly unnecessary.
It behooves us all, slackware, Debian, Gentoo, Mandrake, and Source Mage enthusiasts alike, to stand up and make sure the word gets out to commercial vendors that they can, and should, package their software in a distribution-agnostic manner so that they can target their entire marketplace, and not just a portion thereof, by packaging their software in standard tarballs, documenting precisely which versions of which dynamically linked libraries their software requires, and providing a statically linked binary-of-last-resort in parallel that will run regardless (this is important as distros mature and the old version of the software remains desirable anyway, so it not only allows any distro access to the software, it also provides insurance that the software will run on most any GNU/Linux distro 5 years hence, or even longer, long after the state of the art has moved a great deal further along).
The Future of Human Evolution: Autonomy
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
I would say this is more flamebait, but anyway....
.dll file, just like linux doesn't require anything to be in a .so file. The difference is not one of architecture, both are equally well suited for dynamic linking. The difference is in the way licensing tends to work, convenience, and update ability. Companies in the windows world frequently license the use of a third party component, but they never exchange a line of source code, but instead only get API documentation and necessary .dlls. The agreement often also stipulates that redistribution is *only* permitted in the form of a dll. Also, when it comes to updates, it is easier to update individual dlls bandwidth wise than a whole application. You see linux binaries that are dynamically linked to let users try their luck with .sos too, in most cases.
I would say commercial software companies understand dynamic linking fine, they are not idiots (at least my company isn't). There is nothing about the windows architecture that forces *anything* to be in a
- Commercial companies can understand the filesystem fine, but that doesn't mean they like it. The typical installation strategy of putting binaries, libraries, headers, and documentation in standard, shared places can make it easier on CLI users, but makes support and integratin testing/implementation a nightmare. Companies want maximum control over the install process and want to keep things in a separate directory not because they don't "get it", but because they can only test a finite number of combinations, and the more the user deviates from those tested configurations, the more potential conflicts/bugs could be exposed by exotic configurations. If their product just happens to use the same filename as another product, and the user in trying to install erases the other applications file, will get upset with the second company. Same goes with relocation and such. Many commercial Unix apps never require access outside of ~, but some do, but same goes for a few open source projects.
- That whole last paragraph smelled of pure FUD. Quite frankly I don't see much the point of UnitedLinux, but I don't think they are doing this, if for no other reason then they *know* they lack the market presence to pull it off. As mentioned in the story, Linux distributions are not the same as the Unix vendor differences, and UnitedLinux seeks to solve a largely non-existant problem.
XML is like violence. If it doesn't solve the problem, use more.
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.
I have never had binary incompatibility problems with any commercial Linux software, on any distribution. And, unlike most freeloaders who read this site, I buy a significant amount of commercial Linux software.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
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!
Is this a good thing? I think it's a stupid relic of the days when $PATH and $LD_LIBRARY_PATH were the best way people could come up with of taking individual software applications and importing them into a common environment. These days, a database mapping command and .so names to binaries and libraries that live in their own application directories would be a far cleaner solution. It could even be automatically managed by RPM or DPKG, with something like 'menu' on Debian.
A deep unwavering belief is a sure sign you're missing something...
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?
Yes, but Woody shows no sign of being released in my lifetime...
Look, everyone knows Mandrake doesn't want to join United Linux, and why? Because they want to make money, and not share it with anyone else. It would be nice to see Red Hat follow a strict Linux standard, and Mandrake to do so as well (since they tend to follow Red Hat) but that probably won't happen because they are constantly trying to include things that will make people buy their distro and sign up for their services rather than just the same old standard stuff. That's the reason, and everyone knows it, Mandrake is just blowing smoke.
~ now you know
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.
Yeah, because we all know what a second-tier outfit SuSE is.
If you don't believe it, check out the UnitedLinux FAQ, which states:
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 ;)
The final frontier of Linux computing is the Windoze desktop. RH, Mandrake, and a few of the geekier distros have pretty much conquered the hardcore Linux community, but there has been minimal penetration of the desktop market.
What remains is the competition over whose Linux will be pre-installed on the next batch of lowball Walmart machines. Simplified installs, upgrades and desktop support will appeal to the "Linux for dummies" crowd, especially those who don't know or care about the GPL issues.
No matter who UL says their target market is, the only customers that would be interested in a "pay per seat" implementation of Linux are those who are trying to abandon a "pay per seat" implementation of something else. The UL product should have some appeal for PC manufacturers who want a cheaper Microsoft than Microsoft. I think UL will evolve into the "Linux Ultra Lite/Total Fluff" distro.
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
I'd like to see a package management system somewhat like CPAN (more info). I like being able to use a ReadLine enabled interface and automatic dependancy checking. I like being able to break the install into parts: I gan get the module, tweak it as I see fit, then install it. It just seems like a better system then fink, apt-get, etc.
t'nera semordnilap
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.
.so or .dll to fix a problem in a library used in a number of applications, without having to rebuild every single one.
.dll does not work properly with an existing app? That's happened over and over in the Windows world. Suddenly CD burning stops and it turns out that something replaced one ASPI-related .dll with an older or newer version that is incompatible.
.dll files flies in the face of software regression testing. If the software that I deliver to you can be changed because you installed software from Adobe, Microsoft, or AOL (that replaced a shared .dll), what good was my testing?
.dll concept is like disk compression software -- an answer to a problem (expensive, limited disk storage) that no longer exists.
My last 80GB, 7,200rpm hard drive cost me $75 after rebates. Thus the redundency and waste arguments are just not relevent to most people. I'd much rather buy a larger hard disk than give up system stability.
Not to mention the distribution of bug fixes. Linux or Windows, it's much nicer if I can download/build a new
And what happens when the "new and improved"
The entire concept of
Welcome to the world of modern software.
You act like "modern software" is somehow better than older software. In fact, the number of bugs that exist in the typical business application dwarfs its equivalent from a decade ago.
But all of that aside, the shared
Do you trust the providers of the DLL to only to provide updates that are strictly compatible with the version you installed on the user's machine?
Do you trust the other software vendors to do the right thing when writing their installers?
You balance off your feelings of unease with the performance cost of providing a copy of the DLL in your application directory or statically linking such functions as you need.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Very, very good points, especially about regression testing. Most software companies have enough trouble verifying that their own code works correctly; it gets worse when third-party dll developers can make changes at their whim...
/proc)
Binary software vendors have been doing a better job of not breaking DLL interfaces. It comes out of necessity - you can't just ask each of your customers to recompile a whole bunch of things every time you make a change (like some open-source library developers have been known to do =).
Consider the *immense* lengths that Microsoft has gone to in order to avoid breaking user32.dll and msvcrt.dll after umpteen different changes. (e.g. according to Joel Spolsky/Joelonsoftware.com, MS kept a bug in malloc/free just so that SimCity would continue to run on Windows 95).
I do see a certain advantage to DLLs however - cache footprint. It is better to have one shared copy of a "hot" function like malloc() than many statically-linked copies... But this is a really small concern.
Keep in mind that even if all executables are 100% statically linked, they still depend on a stable kernel syscall interface. The Linux kernel developers have been pretty good about binary API stability over the years, but there have been occasional breakages. (e.g. changing the layout of files in
Someone please mark this date.
Inter-Linux FUD takes over any rational discussion of things.
Nope...that would make it Red Hat :P.
(In case some of you don't know/remember, RH started out as a derivative of Slackware).
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.
The definition of SPAM predates any legislation on the subject by years. The fact that our corrupt government has drafted legislation (or, in some cases, allowed mass marketers to draft legislation) that changes the definition for the convinience of the SPAMMERs themselves in fact does nothing to legitimize the incorrect definition you are defending. It does serve, however, to delegitize the government that is redefining the term
From whatis: The most authoritative definitions are probably the following ones, offered by the Net Abuse FAQ (for USENET) and the email abuse FAQ (for email) The only people who are defining SPAM in the self-serving, restricted manner as you are are the SPAMMERs themselves and the legislators they have bought (and, indeed, not even all of them).
The Future of Human Evolution: Autonomy
Being a FreeBSD user, and thus to some extent part of the problem ;-), I'm only peripherally aware of what's going on here, but an attempt to unify the operating environment of the various Unices can only help. Unifying Linux would be a great start. The inability to do this in the late 80's, combined with a refusal to make a user interface the mere mortals could use, handed the PC market to Microsoft in the first place. Unix was going gangbusters back then and was on the verge of standardizing, but everyone had to do their own thing, and Billy jumped in. And it's taken another 10-15 years for Apple to put a pretty face on Unix. The Open Source version still has a long ways to go yet to match it.
Dude. The entire concept of Open Source Software flies in the face of regression testing.
If a firm develops an open-source app and regression tests it, I can trust it. If I change it, then all bets are off. But the goal of United Linux is to make the Linux platform appealing to application developers, including commercial, closed source applications. When you play swap-the-dll on them, you make support more difficult and expensive.
Oh yeah, that's right, you trust that the kernel developers won't break documented features that they expose - the same is true with library developers: a library developer can be trusted to not break functionality between minor versions. A good one anyway.
You may trust them, but I've seen enough problems to know that I want as much control of my app as possible. If I test it with whatever.dll version 6.3.1.4, then I want 6.3.1.4 on the system, not some version that someone thought would work better.
Yeah. Office 2000 and Photoshop 6.0 crash on me all the time. Buggy as hell. You're right.
Well, if you aren't aware of the bugs and if they don't result in a complete crash, then they don't exist, right? Try going to the Microsoft Knowledge Base for, say, Word 2000 and searching for the phrase "Microsoft has confirmed this to be a problem". The search maxes out at 150 results. God (and Bill) only knows how many bugs really exist.
Sounds good to me. All moderators that make bad mods, please respond to explain yourself. That'll make everyone happy.
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
The real argument for static linking is simple. If you use static linking your program is more likely to run after system updates. There are other answers, but they are a bit less reliable.
I think we've pushed this "anyone can grow up to be president" thing too far.
Why do you think we need a new definition of spam?
> Any e-mail I don't want = spam
Wrong, although it is undertsandable why many new users believe so. Most unwanted email they get is spam, so when more experienced users call that spam, they believe it cover all unwanted email.
> I guess Mandrake is sending their newsletter to *@*.* now, right?
Not as far as I know.
> Spam is unsolicited bulk e-mail
Yes. Of course, spam is more than that. We used the term for mass-posted messages to Usenet before junk email became a problem on email. And before the term reached Usenet, it was used for the practice of flooding online text games with messages, preventing other players their turn.
> with a specific commercial pitch or advertisement including a price.
No such requirement have ever been part of the definition of spam. While most email spam have a commercial twist, there are a low that doesn't (Jesus loves you, learn about the supresseed ethnics, help this worthy cause).
The "includes a price" clause is plain stupid, the majority of spam doesn't include spam, it just refers to a web site.
> Introductory e-mails (especially sent to a
> specific address), newsletters and business
> correspondence is not spam.
Depend on whether it is bulk and unsolicited. It need to be both to be spam.
SuSE Yast is not closed source, but it isn't "Open Source" either. It's a propriatery licence which gives you somewhat more freedom than usual propriatery licences, but leaves SuSE in control.
This is a fact. Now you may argue that "this isn't a problem" for you, and someone else may argue that "this is a problem" for him...
In fact, LSB has been seen as a "Good Thing" for ages at MandrakeSoft, but we didn't want to kill the idea by advertising LSB-compliance too early (ages-old buggy libs, "media" directory fiasco, no test suite, etc..).
For Mandrake 8.x, the goal was to make the distro "mostly LSB compliant", and that's what it is. First distro which is really supposed to be fully LSB-compliant is 9.0.
Well.. Guess some people can't imagine the idea of 200.000 people opting in for a newsletter. So, "it must be spam" .-)
;-)
And I thought geeks have good power of imagination...
Oh piss off you abusive wanker. Theres no point in abusing someone just because you don't agree. Maybe when you graduate from high school you'll learn that. Remember kidstuff that that sort of language in the real world will likely get your nose punched in.
Fuck off.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.