Re: What Linux can learn from Windows...
From: Noi (noi_at_siam.com)
Date: 09/19/03
- Next message: Menno Duursma: "Re: Winchip CPU?"
- Previous message: Michael C.: "/etc/modules.conf is more recent than /lib/modules/uname -r/modules.dep"
- In reply to: Tommy Li: "What Linux can learn from Windows..."
- Next in thread: Chris Share: "Re: What Linux can learn from Windows..."
- Reply: Chris Share: "Re: What Linux can learn from Windows..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 19 Sep 2003 15:40:57 GMT
On Sun, 14 Sep 2003 23:44:50 +0000, Tommy Li without thinking wrote:
> Hello,
>
> Linux in general is a superior operating system to Windows, but I feel that
> there are some things that Windows does better. In particular, I'm talking about
> certain aspects of the directory structure.
>
> Linux's directory structure makes more sense than Windows' overall. There are no
> primitive notions of "drives" or what have you. However, there are two things
> that irk me.
>
> There is a lack of a unifed place to store program settings and information.
> Currently, settings are scattered about the system in text files, XML, or in
> other cryptic formats. This makes configuring a system somewhat of a pain. You
> must memorize the names and locations of files, and what they configure. On top
> of that, there are many different formats used for configuration, from XML, to
> the ALSA asoundrc format, to god knows what.
>
> Windows (back in 95, I think) used to have something like this, where
> information was stored in INI files. I would have to say that the Windows
> registry was great (mostly, since some of the applications still didn't follow
> the registry standards). All the configuration everywhere could be edited with
> one editor, and it was easy to find where your programs kept their settings
> (assuming they followed the standards).
>
Disagree. First of all Win3.x/9x also has multiple configuration (ini)
files, i.e., win.ini, sys.ini, program.ini, and vendors wrote ini files
for their programs. With WinMe/NT?, W2k and XP came consolidation to
the registry.
Unix was an OS created to run small, efficient and unrelated utility programs for
developers in a multiprocess, multiuser environment. Meaning Joe user
can install and run a program known only to him, while Jane user does the
same.
> Perhaps we could adopt something like this. People could write their own
> programs to edit the registry, and it would be much easier to edit
> configurations like now. Instead of "/etc/fstab", people would just use their
> favorite registry editor, and navigate to "Local System -> Mount Points" or
> whatever. Backwards compatibility could probably be maintained for the hardcore
> old-timers: programs should be able still configured from virtual files editable
> by text editors.
>
I would prefer a utility that registers the location for all configuration
files, provides a brief informative description for each of the
configuration files and allows you to click to edit provide you have
rw permissions. You could create a subdirectory in your home directory
and add symbolic links to each configuration file and then use Nautilus
for navigation.
> The other thing that bothers me is the fact that there isn't really a set place
> to install programs (as we discussed throughly in that last old topic). Windows
> partially solved that problem with the Program Files folder. In Linux, there are
> many different standards for this with may programs not follwing any of them. As
> a result, chaos ensues.
>
> I think we should do something about this with Linux. From a conceptual
> viewpoint, there are to approaches to organization of applications: grouping by
> application, or grouping by application component type. Windows does the first
> (generally), and keeps everything in it's own folder under "Program Files".
> Linux does the latter, and scatters the program files in "/usr/local/bin/",
> "/usr/local/lib/", "/usr/local/doc/", etc.
>
> Both approaches have their pros and cons. On the one hand, you can access
> everything related to a program from a single directory. On the other hand, all
> the documentation, libraries, and binaries will be in one place. I believe, with
> clever use of symbolic links, we can get the advantages of both.
>
> Makefiles should be able to be set with a flag to install to /opt and create
> symbolic links from, "/usr/doc/appname/" to "/opt/appname/doc/".
>
> Another option is to have Makefiles install in the normal linux convention,
> create a directory of "/opt/appname/", and make symbolic links within
> "/opt/appname/" to "/usr/local/bin/appname/", "/usr/local/doc/appname/", and
> other files related to the application. This way, all the application files
> could be accessed (and deleted) from one place.
>
Other than using arguments to supply alternative directories to .configure
or makefile, that's something I wouldn't mind either.
> Both of the above solutions seem pretty good. Perhaps there should be an option
> with all Makefiles, so the user can choose. Users could set a default in the
> $INSTALLMETHOD enviroment variable, or something.
>
> What do you think, guys?
- Next message: Menno Duursma: "Re: Winchip CPU?"
- Previous message: Michael C.: "/etc/modules.conf is more recent than /lib/modules/uname -r/modules.dep"
- In reply to: Tommy Li: "What Linux can learn from Windows..."
- Next in thread: Chris Share: "Re: What Linux can learn from Windows..."
- Reply: Chris Share: "Re: What Linux can learn from Windows..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
