Re: What Linux can learn from Windows...
From: Tommy Li (realitymage_at_softhome.netSPAM)
Date: 09/15/03
- Next message: \: "Re: The time is right to evangelize Linux..."
- Previous message: David: "Re: fatx"
- In reply to: armin walland: "Re: What Linux can learn from Windows..."
- Next in thread: Davorin Vlahovic: "Re: What Linux can learn from Windows..."
- Reply: Davorin Vlahovic: "Re: What Linux can learn from Windows..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 15 Sep 2003 03:18:09 GMT
armin walland wrote:
> Tommy Li <realitymage@softhome.netSPAM> wrote:
>
>>>/etc
>>
>>Yes, but you have to remember the names and location of every file, and some of
>>them are a bit cryptic. How is someone who's not used Linux supposed to know
>>that "/etc/fstab" is mount points?
>
>
> granted.
> how is someone who's not used to windows supposed to know that you need
> regedit to disable autoplay for cds in w2k/xp?
>
In XP, you can disable autoplay w/o going into the registry. And I still stand
ground in the point that it's easy to fire up regedit and find/edit program
settings, while it's harder in Linux, where you have to figure out which text
file contains the configuration you need, figure out the syntax and edit it, and
remember that.
>
>>>>Currently, settings are scattered about the system in text files, XML, or in
>>>>other cryptic formats.
>>>
>>>plain text is a cryptic format?
>>>
>>
>>Like I said above, many config files are in XML, or some other markup language.
>
>
> well, xml is a very well documented language. take java for example; the
> preferences classes do a pretty good job maintaining xml files.
>
Yes, you're right XML /is/ brilliant, but to newbies, it would look absolutely
cryptic compared to using regedit.
>
>>Secondly, it's hard on GUI frontend configuration tools. It's very easy for a
>>GUI tool to screw up your meticulously made configuration file, which is less
>>true in a registry.
>
>
> well, i don't agree to that. it makes no difference if you write to a
> binary or to a text file, if you do it wrongly it will screw up the
> file.
>
You may be right on this. My argument was based on the experience of when
sounddrake absolutely choked on a hand-customized modules.conf file, and then
proceeded to mangle my configuration.
>
>>>>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).
>>>
>>>youre not serious are you?
>>>one false bit in the registry and the pc won't boot anymore. OTOT there
>>>is no registry editor for windoze without a gui. what if the gui doesn't
>>>work. i have not only seen this once so don't tell me it doesn't happen.
>>
>>First of all, this has never happened to me.
>
>
> lucky you :) you don't administer a lot of windows boxes, do you?
>
It's probably a combination of the two. Also, I'm not advocating Windows.
Linux's registry could be better designed...
>
>>Secondly, a false bit in a text
>>configuration file can equally screw up booting.
>
>
> well yes. if that happens, i boot from cd, fire up vi, fix the file and
> i'm done. what will i do with windoze?
>
Well, I'm not really talking about Windows. In fact, the Linux registry should
probably be a bzipped text file.
>
>>Like I said, people can write
>>their own registry editors, and I'm sure there will be console-mode registry
>>editors.
>
>
> i hope i can surprise you with the fact, that there are. written for
> linux boot disks for people with trashed windows registries.
>
>
>>>>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.
>>>
>>>
>>>you don't understand the idea behind the PATH variable and dynamic
>>>shared libraries.
>>>
>>
>>I understand those ideas, but they're irrelevent. Even with PATH, there are
>>still instances where you need to know exactly where a program is stored.
>
>
> man which
Ah, cool. Learn something new every day.
>
>
>>Plus,
>>PATH causes your computer to have to search every directory in the PATH until
>>your file is found.
>
>
> true and that is the great thing about it. you prove me correct assuming
> you do not exactly understand the idea behind PATH.
> if PATH is not used _I_ have to search _every_ directory in
> the filesystem to find a file which's exact location i don't know. do
> you think that is clever?
>
Well, I meant that because PATH had to search every directory, there would be
additional overhead - especially if you had many directories in your PATH.
>
>>Secondly, dynamic shared libraries can still be stored in a
>>common area.
>
>
> they are :)
> usually in /lib, /usr/lib/, /usr/local/lib
>
>
>>>>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.
>>>
>>>there is one distro that does that. i don't remember the name but i
>>>tried it and it was awful. 90 % of all files were symlinks.
>>>
>>
>>I don't see why 90% of the files would be symlinks if this was done properly.
>>Secondly, I don't see any problem with many symlinks.
>
>
> it produces unnecessary complexity. just think of installing and
> uninstalling programs. who would want to have masses of dangling
> symlinks on their system. things that create more work than comfort
> don't seem necessary to me.
Well, actually, the whole idea of this is because of the toughness of
installing/uninstalling applications. The idea is that when you want to delete
an application, you could just delete "/opt/appname/", and everything related to
the program would be gone.
On the different note, you're right, symlinks wouldn't be appropriate for the
job. A mix of hardlink and softlink would work.
This type of link would have to:
-be deleted when target is gone
-be renamed when target is renamed
-can link directories
-can link across filesystems
> <snip>
The registry idea is probably a bad one. Now that I think about it, I don't
really want a registry, but rather a system where all the applications follow
one standard (i.e. XML) in storing their configuration files in the "/etc/" folder.
The unified approach to application storage still sounds like a really good one,
even though it would require a new type of link. It would dramatically simplify
uninstalling a application. You could simply delete a folder instead of hunting
down the libs, docs, bins, configuration files, user config files, etc. At the
same time, you could still view all the libs, docs, bins, etc. at once.
-- Tommy C. Li | RealityMage | realitymage@softhome.net Registered Linux User # 327563 | http://www.impulsestorm.com/
- Next message: \: "Re: The time is right to evangelize Linux..."
- Previous message: David: "Re: fatx"
- In reply to: armin walland: "Re: What Linux can learn from Windows..."
- Next in thread: Davorin Vlahovic: "Re: What Linux can learn from Windows..."
- Reply: Davorin Vlahovic: "Re: What Linux can learn from Windows..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
