[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] Re: Shared installs and our EPP Packages
- From: John Arthorne <arthorne.eclipse@xxxxxxxxx>
- Date: Mon, 23 Aug 2010 12:03:56 -0400
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=Ho+rwBzXVRSwclTza+Nkd8clSeAsOLNN1KkRA3ci4E59/+xtHpLUJNl1gfOb2G3MaO tLc/RHvcOxKE80EJFIxx1GzmJU4MesUfn/jaGpXu5xWVqz2nasmNuYEZNKGv5djSbmbW 7ZkWl9wquiuw6TF5a1UEpAnbbdJTA1NqHNk5M=
I guess another way to look at this is that there are different reasons for a "shared" install:
1) You really want multiple users for an application
2) You want to prevent an ordinary user from messing with their install.
Having said that, I'm not sure we can automatically say that Windows is always case (2) and Linux is always case (1). There are certainly examples of Windows installs that really have multiple users that could reasonably want different sets of plugins installed (imagine a computer lab at a university or a shared computer at a library, etc). Conversely, there are a large number of Linux installs that are single user desktops, but access control is used to avoid accidentally breaking the system. So, in the end I don't see how we can have two different flavours of shared installs and automatically determine which one to use.
My interpretation of the intent of UAC is that it tries to behave more like Unix access control, but for backwards compatibility reasons it is dumbed down so we see differences in behaviour (only locking certain directories, and performing virtualization on write).
On Thu, Aug 19, 2010 at 3:26 AM, Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>
Am 12.08.2010 15:32, schrieb Ian Bull:
> 1. The definition of 'shared' installs. If each user could update theI started thinking more about this and I'm tending to say that Windows
> base then this is not really 'shared' anymore. Some users have SR1,
> some have SR2, etc...
is *not* a shared install in terms of the original definition on
Unix/Linux. I think there are different kinds of "shared" installs now.
A) not really shared
A user installs something into a protected area. During installation the
user gained higher privileges (either automatically or on purpose). But
generally the user is the owner of the system and is the exclusive user
of the install.
In essence only the installation location is write protected. A user may
not even be aware of this (UAC).
B) really shared
An administrator installs something into a shared location to be used by
Case B clearly is a shared install. However, case A is different. That's
the Windows 7 case (IMHO). I think it's wrong to treat it the same as
This clearly applies to B but not to A. In case A user == admin,
> 2. Consistency. If a users updates some bundles in the shared area, and
> then the admin updates the base, what should we use now?
however, the user might not even be aware of this.
I think p2 needs different strategies for case A and B and a smart
decision when selecting a strategy.