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. Tools built on top of RPM are not really helping much. > 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. > 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 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. 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. > 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. 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? > 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. And that's exactly why commercial companies are able to create and successfully deploy applications on it. 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. If (as I suspect) you were talking about stripping the system during fixed embedded system development, i don't think anyone really cares how this is done. Why would you have RPM repository in such system anyway? > 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. > 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'? > 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 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. -- // Janne --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
