On Fri, 21 Oct 2005 16:59:38 +1000, Mike MacCana wrote: > Why should Fedora and Red Hat encourage installing software in a > non-standard method? Because: a) Fedora RPMs are not a standard method. They're proprietary to Fedora and a particular Fedora release at that b) Non-technical end users like this particular non-standard method c) It's more secure to use RPM for operating system level code and something else for 3rd party application code. I'll talk about the last one more in a moment, as I suspect you don't care much for inter-distro compatibility or what non-technical end users want. > How is it easier to have an application that installs in a totally > different method from every other app on my system? Have you ever tried it? I don't think ease of use is a real problem with autopackage. Anyway, this set of /usr/local bugs affects installing software from source too, which is still VERY common amongst end users, mostly because software people want is often not available in any repositories. > This isn't a defence of RPM. It's a defence of good systems management. > One way to install software is better than two. You say this as if it's obvious. But to me it is not. Let's talk about security. Hopefully it hasn't passed you by that despite being basically miniature computers mobile phones have remained basically impervious to viruses and spyware. Yeah yeah, I'm sure somebody can pull up a scare story about a "virus" that requires you to manually confirm reception and installation of the software, and which can then be trivially deleted. But we've seen nothing like what we've seen in the Windows world, where software gets in undetected and then makes itself nearly impossible to remove. One reason is that there is strict separation between 3rd party application code and native OS code. Java MIDlets are an extreme example of that, which can't access or control each other and run in an interpreted sandbox. They also can't access operating system files (although phones do have operating systems and they do store their code and data in regular files). By keeping application/game software totally sandboxed, the platform has been (so far) kept secure. To upgrade the OS you need to reflash the firmware, it's not like installing a regular application at all. Right now we simply *cannot* do that on Linux because there is no distinction between a kernel or libc upgrade and installing a new chat client. When RPM is used for both, how can you possibly sandbox the installation of this software? How can you say, well, THIS rpm can modify the grub configuration but THIS rpm cannot? You could try playing games with digital signatures - RPMs signed by this authority can do anything, and RPMs that aren't signed cannot - but then you did exactly what we did with autopackage and produce a new format. They might have the same file extension but they actually aren't the same type of file at all. They have different capabilities and work in different ways. Anyway. One of the things we've been looking at lately is using the binary policy modules in Fedora Core 5 to sandbox autopackages down so they can't interfere with system configuration in unacceptable ways. We can do that because we control the API and because the format was advertised since day one as a way for developers to distribute their application-level software to end users and not as a distro building tool. You'll never find a kernel autopackage, so the format itself acts as the dividing line. Through this technique and others (like whitelisting) we hope to improve security far beyond what a "one size fits all" tool can offer. > Don't try and encourage people to use two different packaging systems simultaneously. Too late. The cat is already out of the bag, 250+ people install their first autopackage every day and it's growing all the time. Why don't you work with what end users want instead of what you believe to be theoretically pure? thanks -mike -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
