On Feb 12, 2006, at 23:13, Kevin van Haaren wrote:
>> I'm really the only one that uses the Martok (my desktop), so on
>> there I'd really prefer to install things, including bits like kexts
>> and Unix programs, in my user folder. That way, when I switch over to
>> my 'clean' user account to do some testing, I know that it really is
>> clean.
>
> I've seen it in Windows, it's called DLL Hell and it's a bad idea.
DLL Hell on Windows came about because MS went for a long time
without including a system in Windows to prevent it. When they did
eventually get around to it, it was weak and, worse, largely ignored
by developers. If you design in a good system, and if developers play
along (whether by force or by choice), there's no law of systems
architecture that says you must live in dependency hell.
OS 9's multiple users feature more-or-less failed for two reasons: it
was poorly implemented (largely because Apple was held back by legacy
technicalities), and developers constantly violated the rules. By
your reasoning, should we have given up on the idea of a multiple-
user Mac OS back then? Just because one implementation fails
miserably for whatever reason doesn't mean that an idea is
fundamentally flawed. (Incidentally, the situation is the same with
multithreading between OS 9 and OS X; I don't think any Quad G5 or
Core Duo owners, however, would argue that Apple should have given up
on multithreading back in the OS 9 days when it was of rather limited
use.)
> BTW in digging around on this I found out that Apple only actually
> supports
> one location for Kernel Extensions.
Ah yes, you are correct. I remember reading that in Apple's dev docs
years ago, but had long since forgotten about it. Like many other
developers, I felt (and now feel again) this limitation was a huge
mistake on Apple's part, one that was founded on shortsightedness. Be
that as it may, the decision was made, so we have to deal with it
until Apple decides otherwise.
>> And when I back up my user folder, I can be secure in knowing
>> that *everything* that is custom is included.
>
> I don't quite understand this. The only way for this to be true is
> if you
> either also installed all applications in your user folder too, or
> backed-up /Applications too -- which defeats the purpose of backing
> up only
> user folders.
Why do you think Apple supports an ~/Applications folder? It's not
necessary for all users to have access to all apps. On my mother-in-
law's machine, I have some diagnostics-type applications installed in
my account that could cause a ton of damage if my MIL started playing
with them, but by having them in my user account, she won't even know
they're installed. This also serves to ensure that they'll still be
installed (and not have been deleted with a shoulder shrug as to what
they were) when something goes wrong and I need to fix it.
Ideally, in multi-user settings, apps that general users install
would go into their user folder, and Apple apps would be the only
ones in /Applications. A good place for shared apps installed by the
admin for use by all users is /Users/Shared/Applications (or an
equivalent, like a network volume), with an OS-provided way to
somehow display the merged contents of all apropos app directories
for the benefit of users.
Complete domain enforcement has all sorts of benefits; just a few are:
* Backup user folders and, as applicable, the shared apps folder(s)--
i.e., all the non-Apple parts--and you're good for a basic backup. A
recovery would involve reinstalling the OS and restoring the backed-
up user data. You can still choose to back up the system, but by
having a clear separation between system data and user data, users
are in control.
* Users need not be concerned with nor deal with *anything* that
other users have on the machine. This already applies to documents,
but it makes sense for applications, too. If user A uses Nisus Writer
and user B uses MS Word, why should B need to have Nisus Writer
polluting their applications list (and vice versa)? The user is in
control of what apps they have to deal with.
* Problems like Photoshop being used by the Finder to open JPEG
documents when the current user likes to use GraphicConverter are
completely prevented. The user controls what program is used for
what, with minimal configuration hassles.
Do you see the theme here? It's all about keeping the user in the
driver's seat, where they should be. I remind you that computers are
supposed to work for us and make life easier for us, not the other
way around.
You posted a link to a message where an Apple engineer complains
about all the extra work necessary to support what really is a
relatively small change in supporting kexts in the user domain. My
response: Yeah, there's some work involved. However, all of the
required updates are fairly minor, and frankly, the whole job is
probably a thousandth of the effort required to implement, test, and
document a new UI-theme-of-the-year with each new OS release, and
what benefits does that bring the user? (Oh, wait, Apple doesn't
document such changes, but rather just tosses them out into the wild
without explanation of any sort. This makes things even better for
users and developers alike, while also cutting down on the project
effort. Brilliant idea - why didn't I ever think of it?)
Strict domain enforcement also has benefits on single-user machines,
some of which I described in my previous message.
The problem we have today is that the current system is somewhat
flawed. Apple dropped the ball big-time by limiting kexts to the
System domain, and to a lesser extent by not providing a domain-
unified presentation of installed apps. Developers turned Apple's
errors into a disaster by installing stuff willy-nilly. The system is
not fatally flawed, but it does need some work and some polish. To
me, that means you put in some time working and polishing, not
disregard the whole thing because it's less than optimal, which is
what you seem to be suggesting. Apple seems thus far to be choosing a
third option, which is to simply let the system sit in the sun
unchanged, so that the flaws become increasingly baked in and
difficult to remove in the future. (Remember why Copland and Gershwin
never materialized?)
> Kernel extensions are part of an application (or according to Apple
> they're
> part of the System). If you don't think /System or /Applications is
> worth
> backing up, then why are KEXTs worth it?
You're putting words in my mouth. First of all, *everything* is worth
backing up, but *how* it's backed up--as part of a daily routine, a
monthly routine, or just by keeping the install discs around--is a
decision to be made by the user based on his or her needs (user
control!). Secondly, I'm not saying any data type is more important
than any other, just that OS-level separation of data that are by
their nature orthogonally opposed makes sense. If user-installed
kexts and apps are in the users' folders, they're easily targeted for
backup, whether on their own or as part of a larger backup (user
control!). This is in stark contrast to the current situation where
some user-domain items are stored in the system domain's directory
hierarchy; such mingling means that to target one group or the other,
you must know exactly what is in each group, a difficult if not
impossible requirement to meet. The mere existence of a decent domain
system in OS X proves that Apple agrees with me. They just need to
clean up the implementation details and somehow get developers on
board (so that we can put an end to situations such as a contextual
menu being quietly installed for all users).
Incidentally, let's not forget command line installations that assume
the traditional Unix directory structure. That's yet another giant
can of worms!
> Also I think we're totally forgetting the point of kernel
> extensions --
> these are serious modifications of the low-level kernel of the OS.
> Applications that need to do this should be few and far between.
If this is true, and for the most part, it is, then why should a kext
that my wife installs be able to bring down my account when it
misbehaves? The nature of kexts is all the more reason to keep them
isolated to only those users who need them. OS X can generally load
kexts dynamically, so there's no reason that they always need to be
installed for all users. Admins can still choose to make things like
device drivers available to all users, but once again, it's a user
(admin) choice, not an Apple engineer's choice.
>> That way, when I switch over to
>> my 'clean' user account to do some testing, I know that it really is
>> clean.
>
> You would learn as much booting from a clean SYSTEM (i.e. boot DVD,
> firewire drive, etc...) plus have the benefit of being able to backup
> existing files or doing troubleshooting, without worrying that a
> corrupt
> system is causing the problem -- not just a corrupt user.
That's the whole point. Any point of cross-over between domains is a
potential point of failure in the theory of clean testing. Currently,
there are a ton of cross-over points, most of them unpredictable, so
the value of a clean account has been greatly diminished. There's
just too much spill-over between domains. If the domains were
enforced, the overlap would be both minimal and known, and thus
easily factored out. Why should I have to go through the hassle to
start up off another volume when the OS's purported features should
obviate the need to restart at all?
Regards,
Bob
--
Robert E. Williams, Jr.
E-mail: <bob
trivectus.com> Phone: (602) 357-3296 x111
Web site: <
http://www.trivectus.com/>
![[F]](/Images/i7/site.gif){kind=small}
TidBITS 
TidBITS 