On Sunday 30 October 2005 15:57, Pascal Bleser wrote: > > 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.
Who exactly is doing it? I certainly did not suggest anything 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). I agree 100%. It's just that it is not well defined as it is now. > 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 Please stop saying that. That is *NOT* what i suggested. > >> 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. Yet, most times I fall back to using plain RPM as either repositories are incomplete, broken dependency wise or just too busy to talk to me. And that's just one of the reasons RPM itself needs to 'just work'. > > 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. I gave this some more thinking, In theory, we wouldn't need to break the 'eons-of-packages with circular dependencies in the base system for nothing' concept by using another old concept: meta RPM, 'selection' of smaller RPMs. By making 3rd party RPMs to depend on these selection RPMs we would get rid of some of the dependency jungle. I'm bit confused that no-one really raised the one valid concern about this: how to handle security updates and such. Deltas of course are a one possible solution, but RH for one is highly against them as they claim they 'just don't work'. > > 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. So have I as my sole desktop, for the past 6 years. However, that does not mean it couldn't be made better. > I agree, it currently definately is an issue for vendors who want to > provide their proprietary software on Linux. Okay, now we're getting somewhere :) > >> 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" This goes off topic, but why is it bad thing to expect the system to have a HTML renderer in the year 2006 (earliest)? > (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. The fact is, it's almost as impossible to do this with Linux as well or you end up breaking many, many things. Applications are the first to suffer. Setting up embedded stuff like ultra-lite firewall should be a thing to worry for the firewall builder, not every frigging end user. In the end, stripping Linux to bare bones has very little real use. > 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. Okay, now you go off topic. Of course we could argue for ever whether integration is a good thing or not. I think it is, and it is one of the key design concepts of KDE for one. That's why I like it. > 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's a one thing. But having the working ABI will not get the RPM to install. > > 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. How many people do you think have the real need for this? Few hundred geeks globally? Is that a valid reason to make things complicated for everyone else? > Now what does this have to do with RH's support for their enterprise > distribution ? Think about it. > >> 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. No you can't. There are at least 20 different main flavors of SUSE Linux alone. Plus gazillion possibilities to install each and every one of them. > > 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. As I said, ABI is the other thing. But making that truly stable for Linux is too much to ask right now. Just having the applications to install would be OK for now. > > 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. Look at the RPM dependency graph. Have a good look at it. Now think about all the variations system can be installed in. Grasping the concept, do you think as a packager you can guarantee that 3rd party software 'Zardoz' (that you have never seen) will work in every one of these combinations IF it works on ONE of them? I don't think so. Or do we leave this job for the 3rd party SW vendor? I think he'd rather not touch it. He does NOT know the system nearly as well as the packager does. Having said that, i don't think i need to emphasize what happens to end user here. > >> 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. There is no one size fits all 100% type of solution. You need to cut some corner cases. -- // Janne --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
