-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Janne Karhunen wrote: > On Sunday 30 October 2005 11:45, Pascal Bleser wrote: >>>> RPM is a powerful tool for system administrator, but as ironic as it >>>> is, end user is much happier with windows installer :/. >> Maybe. *Some* end-users prefer a windows installer. > > Let's be fair here - i would say 95% of them do. That's pretty > drastic figure. We definitely need to be asking why the case > is such.
because 95% = Windows user market share on the desktop .. ? Let's face it: most end users just don't know anything beyond Windows. Just because they want it to look like Windows, including its many defects, is not a reason for making Linux distributions like that. > Tools built on top of RPM are not really helping much. I think that's a serious misconception. The package management backend is a major asset of most Linux distributions, and it's a key feature to provide stability (dependencies being installed), quality and security (a well-defined, common package upgrade mechanism). What may be argued upon is that there are different package management backends (let's just keep RPM and dpkg, others being either highly experimental (conary), unfinished (conary) or unable to fulfill the role (slackware)) and, hence, you don't have a single package format to cover all Linux distributions. That's definately the kind of issue faced by commercial vendors. Admittedly, and I'm certainly amongst the first to critize that, distributions don't unify their packaging schemes. What I mean is that e.g. the project "libfoo" is packaged as "libfoo + libfoo-doc + libfoo-devel" on Fedora, as "libfoo1 + libfoo1-devel" on Mandriva, "libfoo + libfoo-dev" on Debian and "libfoo + libfoo-devel" (or just "libfoo") on SUSE. <rant> But I don't see any hope for unifying that. Linux distributions don't want to make that compatible, don't talk to each other. Never mind if they're "commercial" (Redhat, SUSE, Mandriva, Ubuntu, ...) or "community" (Debian, Slackware). The first probably don't want this because of their market shares, the latter because of ideologic/religious reasons. This is not intended to be Debian flaming, as I highly respect their excellent work, and Debian has a lot of excellent features. But let's face it, most Debian packagers/committers are quite convinced their way is the best and don't really give much about other distributions. Just see the state of LSB support in Debian - admittedly, it got better, but it took a couple of years and is still far from being complete - compare Debian init scripts with SUSE... actually... on Redhat/Fedora it's different, again.. because they don't give a **** about LSB either. While LSB is geared towards solving part of these issues, I don't see the overwhelming industry/community support for it. SUSE probably is the only really LSB compliant distribution. And Redhat doesn't care, they're the market leader in the enterprise sector. But maybe that's just me being wrong or too pessimistic about LSB ;) </rant> But let's get back to the thread... ;) I think we definately have to precisely define what we're talking about, as it seems we're mixing two IMHO different topics here: - - end-users coming from Windows and who want Linux to look and behave exactly like Windows - - commercial vendors who want to package their applications for various Linux distributions >> But it's not because they prefer to shoot themselves into the foot with an >> inferior software management concept that we should actually give them the >> gun. > Let's not move the target now. Nobody is really taking anything away. But you implied RPM being an issue, RPM frontends being crap. Where I disagree. YaST2's Software Management module does more than a decent job at installing packages and its dependencies properly. >> Everyone talking about end-users and desktop all the time. You seem to >> forget that Linux is also strong in the server room, where we have to keep >> on working on its adoption for mission-critical tasks. For things like >> those, having a very strict and powerful package management system is >> *crucial*. > > No-one is forgetting this either. I'm well aware that most of > the money Linux is making comes from the server room. What you're I didn't mention "money". I meant *users*. You seem to discard people using Linux in the server room and who want features that are in direct opposition with what you're asking for. > really saying there is circular reasoning; Linux will stay away > from the desktop as long as the software installation and 3rd > party development is as bad as it is. So this is contributing > significantly to the fact that 3rd party commercial SW vendors > are avoiding Linux. Oh, I never said that, I didn't even imply that. Linux won't stay away from the desktop. Actually, Linux is already very usable on the desktop. I, and many others, do that every single day. Actually, it's even far superior as a "desktop platform" than Windows. It always depends on the criteria. Yes, there are issues with hardware (or rather, drivers and availability of specs), but that's quite a different topic. On the other hand, using e.g. NLD or SUSE Linux as a platform for the desktop PCs in a corporate environment provides a much better platform than Windows. Centralized package management, remoting, cost cutting, modularity, customization and security being just a few of the advantages. For gaming, having any hardware device work properly and some other topics, Windows is better than Linux. It really depends on the focus. It's just plain wrong to say "desktop" and assume a single scenario with that, and imply that it's the only environment that counts. Let's just not confuse "Linux is ready for the desktop" (whatever that means anyway) and "Linux looks and behaves exactly like Windows". And don't tell me you're not asking for the latter, you're the one mentioning Windows "installers" ;) > Due to the dependency hassle it's almost impossible to support > anything else than some very specific distribution and it's > version. And I'm not saying what ever i proposed will solve this, > it doesn't. It would just be the first step. Ok, here you're mentioning commercial vendors who want to package their stuff for Linux. That's a different topic. Either that's what you meant from the beginning and I didn't get it, or we're both mixing up 2 different topics (see above). I agree, it currently definately is an issue for vendors who want to provide their proprietary software on Linux. >> What you describe as "dependency hell" is a *feature* that's miles ahead of >> what Windows provides as software management facilities. > > Depends on the point of view. Windows does not allow creating > broken installations - basic elements to be expected from modern > desktop are always in place. Example: 3rd party SW vendor can > safely expect the MSIE html rendering component to be there. He > can build on it. This is not the case with Linux. There is no > common base, and there definitely should be. I'm sorry, but that's not correct. As you're mentioning IE: Windows bundles a number of components. That's also one of its technical defects, because they're so tightly integrating into the "operating system" (yes, I put quotes there) that one cannot install Windows without a graphical user interface that uses at least 40 to 100MB of RAM, permanently, having a sh*tload of DLLs and applications running in memory, including IE. And, as we all know, that also implies a large number of security issues. Do we want that for Linux ? I don't think so. If a commercial vendor requires libgtk-x11-2.0.so.0, fine. What you're talking about is rather having consistent and backwards-compatible APIs and ABIs. > That said, let's take an example of RH Enterprise Linux. It's > minimal installation is roughly 550 megabytes. RH does not really > support systems stripped to be smaller than this as things will > start to break. So what good does it do for the user to have the > system split into 1000 small packages instead of just 10-20? A minimal installation for Debian can be much smaller than that. And when you have 120 packages instead of 10-20, you're able to make smaller installations than 550 MB for a base system. Now what does this have to do with RH's support for their enterprise distribution ? >> You're asking for having bigger base packages, but many more people are >> asking to have *smaller* packages, better split into subpackages, because >> a) embedded systems: only run the bare minimum because of hardware >> constraints > > Actually, once again smaller packages are actually hurting instead > of helping here, if it's a system that customer can install software > to. One of the most successful embedded systems currently available, > Nokia Series 60 platform, consists of just half a dozen packages. That's *one* distribution. You can have exactly the same situation if you say: I only look at SUSE Linux. > And that's exactly why commercial companies are able to create and > successfully deploy applications on it. No, it's because of APIs and ABIs. And most of them just require J2ME anyway. > Then again, if it's a system you can't install applications to, user > does not care a jack shit what kind of a mess it is internally. But that's exactly the point. We should never allow such considerations to spoil the whole system. ... >> b) security: only run the bare minimum because any unused >> application that's installed is an additional potential security risk > This is true, but i wasn't talking about applications. I was talking > about the base system - components you need to have in place anyway. ... which vary a lot depending on what you want to do with the system. That "base system" is not the same when you're using it for a desktop system than for a server than for an embedded one. The onyl real "base system" I can think of and that fits into every scenario is the kernel and some stuff from coreutils. But even there, what kernel modules and features are available highly depend on the environment. Linux is a modular system, and that's one if its major assets. >> Don't just discard those very important aspects that are a key element of >> the stability of most Linux systems, just because you think Linux should be >> like Windows. > Now that HAS ABSOLUTELY NOTHING TO DO with anything i proposed. How > do people always find this 'argument'? Because you mentioned Windows and "installers" as being the right way to do it. >> Pushing Linux onto the desktop and for everyone's use should never, ever >> compromise the stability, consistency and technical superiority of Linux >> compared to Windows (and even to some Unix derivates). > > And that is not done here either.. That's where we don't agree ;) >> .. >> That's a valid point. The only issue I see nowadays with not finding >> dependencies is when you install packages from a 3rd party repository that >> depends on another package that's in another 3rd party repository. >> e.g. you install some package from my (suser-guru) repository that requires >> another package from packman, and you don't have the packman repository in >> your installation sources >> That's really the only situation where we have to improve things. > > Uh-oh. Take some time to think this over, please. It's about 5 years I'm building packages for SUSE Linux and providing this service at no cost and part of my spare time to many SUSE Linux users. I think I do qualify as an "expert" on this topic. So, yes, what I wrote above, I did took some time to think about it. Still, I wonder how on earth you're managing software on your Linux system. The vast majority of users do *not* have the dependency and "unfriendlyness" issues you're describing when they're using YaST2. Yes, there still are a number of issues and room for improvements, but really, it works quite well as of now. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDZNFYr3NMWliFcXcRAuhSAKC5EUNsS+3rAdLxBRHdktGByvdbMwCdENLi Rxv+f4Bv4A8ModpNNwhIbhg= =XfrQ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
