>>I think what may be "inherently broken" is the basic Unix model, where
>>you search for executables and other support files in a "path" of
>>directories. There is nothing inevitable about doing things this way,
>>it just happened to be what made sense to the people who first designed
>>Unix (or whoever they got the idea from), and since then it has been
>>passed down from generation to generation, even unto the present day.
>>There are many arbitrary choices that go into designing an operating
>>system, and many paths that could have been taken, but weren't.
>If you suggest a concrete alternative then people could critique
>its advantages and disadvantages.
I am less interested in defending particular alternatives than in
simply noting that they exist, and that the present setup was
determined as much by historical accident as anything. The Unix file
system really is very simple. I worked for a long time on a VM/CMS
system, and after moving to Unix I often missed having a record based
(rather than stream based) file system. You can certainly roll your
own record based (or even indexed) files, but because it happens that
they were not there at the beginning there will never be a universal
way of doing this. On the matter at hand, one thing that comes to mind
is the possibility of more types of special files and directories. One
example is the special package directory in the NeXT operating system,
which looked like a single file unless you deliberately opened it up.
Another thought: why aren't the *subdirectories* of a directory that is
part of a "path" also searched for resources? That might lead to a
whole different way of organizing things, which might (or might not) be
better than what we have (I can't pretend I've thought this through to
the point where I could answer this).
Quote:>>I'm sure that if someone were designing an operating system from scratch it
>>would be easy enough to set things up so that it was indeed natural and
>>efficient to put each application and all it's support files all
>>together in the same place. But for historical reasons that's just not
>>the way we do it, and it may in fact be impossible to get there from
>>here.
>I would put it this way: there is a lot of existing code and
>many widely adopted standards that depend on the existing
>conventions. However, there is very little in the existing
>scheme to stop anyone from writing all sorts of application
>management interfaces that isolate the naive user, and perhaps
>even the system administrator from micromanaging the details
>of the directory layouts. RPM seems to be a good attempt at
>a move in that sort of a direction, but much more comprehensive
>schemes are certainly possible.
>Notice that this general issue is not particular to Unix:
>uninstaller programs for MS-Windows are frequently found
>among lists of Top 10 best selling commercial software
>packages and there has been an enormous brouhaha lateley
>about the differences between the registry formats for
>Windows 95 and NT as well as the question of how application
>programs should use the registry (e.g. MS IE and Netscape
>fighting to install themselves as the default browser).
But notice that DOS/Windows drew a lot of its inspiration from Unix,
and thus tends to have the same sort of problems. I think Unix's
simplicity had a lot to do with its success, but in the end I think it
had TOO MUCH simplicity, which has lead to it's being patched up and
extended in dozens of incompatible ways. I wish I knew more about the
IBM's AS/400 system; I get the feeling that it is a *lot* more
sophisticated, in many ways, than any of the Unixes or Unix
derivatives, and I suspect it would be an excellent example of
different paths taken to different solutions. It would certainly be
interesting to see a point by point matchup by someone who know both
systems well.
--
John Brock
by