Dave Miner wrote: > Christof Pintaske wrote: >> Dave Miner wrote: >>> [...] >>> For example, I think it's necessary to provide a registry of the >>> "software domains" on the system, so that the system administrator >>> will have the knowledge of where package installation has been done >>> available to leverage, and so that tools can be provided to take >>> advantage of that knowledge. >> >> Basically the software that a user installs in his home directory is >> not part of a specific system. It's part of the network. So it's on >> vain to register it on a specific machine. It must be accessible >> wherever the user is roaming with his home directory. So the home >> directory itself might be a proper place or an LDAP directory ... >> >> If the home directory is on an nfs share the system admin might not be >> able to access it. The user might use the machine never again, and >> prefers to use a different one to deinstall his software (or move it >> to the trash can on a Windows box). > > Sorry, that sounds like we're just trying to say ETOOHARD, and I don't > buy it. For these cases, we can construct all sorts of cross-system > solutions, perhaps using a directory service, as you sort of seem to > allude to. Solving that would seem to be even more valuable, because > then you can help improve TCO of a larger "system".
we may not be too distant. The thing I wanted to point out is that you cannot solve this on single machine (in a network). You either ignore it or solve it on the network. >>> Further, this proposal raises many more questions about the ability >>> of the package and patch tools to present a coherent view of a system, >> >> In this context they can't, and I don't think they should try. Only >> software that's "owned" by a specific system should be part of this >> view. Software that is "owned" by a user should not. >> > > Again, I disagree; did we suddenly decide that the network isn't the > computer anymore? And how would I, as an administrator, find the > software that has been installed? Write a big "find"? Why is it > necessary to force that cost onto the customer, where it's definitely > higher in aggregate as each customer has to come up with their own? What do you do with the information as a system administrator ? If you find out that user U has installed package P, how could you possibly rely on this information ? If you restrict (lock) the user in what he can do with P (like for example, remove it) then this is probably not what the user expect (he might have to free some diskspace to obey to the quota ...) >>> because that's not what they do anymore. We grappled with this in >>> the zones space, and really didn't come to a resolution, punting due >>> to lack of resources and time pressures. "Consolidation" is a great >>> story, but if the consolidated system ends up requiring the same (or >>> worse, new) expensive third-party tools to manage the software as a >>> network of systems, then it's far less compelling. We know we need >>> to do a bunch of work to make the user's software maintenance >>> experience on Solaris modern and competitive, and I'm disturbed by >>> the thought that this proposal will actually increase the scope of >>> that problem without making any steps in the direction of addressing it. >>> >>> I'm interested in some elaboration of the DOS concern. I can imagine >>> some concerns, but I'd like to understand what you're specifically >>> trying to prevent. >> >> The system must not depend in any way on software that it does not own. >> > > That doesn't answer my question in any way that is meaningful. What is > the threat that we're attempting to design against? that the system has a dependency on a package in the users home directory, or that user A's software depends on user B's. >> Validation cannot be done (fully) at installation time. It has to be >> done at runtime, if at all. >> A user will be happy to install a software on, say, Solaris 10, and >> then later try to run it on Solaris 9 (or FreeBSD, or whatever) > > You'd seriously assert that there is no value in attempting to point out > to a less-sophisticated user that perhaps he's trying to do something > that won't work and doesn't make sense? This is not an either/or > proposition. right, that's what I meant by "fully". You have to do it again and again. Maybe my wording was not well chosen. The install-time check is the 0th iteration of the runtime check, although what becomes an error at run-time might be only a warning at install-time. bye Christof
