Re: What Linux can learn from Windows...

From: Tommy Li (realitymage_at_softhome.netSPAM)
Date: 09/15/03 

Date: Mon, 15 Sep 2003 00:53:01 GMT

armin walland wrote:
> Tommy Li <realitymage@softhome.netSPAM> wrote:
>
>>There is a lack of a unifed place to store program settings and information.
>
>
> /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?

>
>
>>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.
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.

>
>>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. Secondly, a false bit in a text
configuration file can equally screw up booting. Like I said, people can write
their own registry editors, and I'm sure there will be console-mode registry
editors.

>
>>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. Plus,
PATH causes your computer to have to search every directory in the PATH until
your file is found. Secondly, dynamic shared libraries can still be stored in a
common area.

>
>
>>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.

>
>
>>What do you think, guys?
>
>
> well all in all i think you want to use suse or mdk, they try what you
> want in some kind of way. IMO this is a crappy approach, i prefer the
> way that debian and gentoo go and i believe it is very intelligent and
> easy to maintain.
>

Mdk doesn't do this. I'm going to install Gentoo on monday, so I'll get back to
you on that. 

-- 
Tommy C. Li   |   RealityMage   |      realitymage@softhome.net
Registered Linux User # 327563  |  http://www.impulsestorm.com/

Relevant Pages

  • Re: What Linux can learn from Windows...
    ... ]>>There is a lack of a unifed place to store program settings and information. ... If you think a single registry is not cryptic, ... ]GUI tool to screw up your meticulously made configuration file, ... Registries are dirt easy to screw up. ...
    (alt.os.linux)
  • Re: Winforms, Shown Event and SetEnvironmentVariable
    ... the environment variables wind up in the registry anyway. ... Assuming .NET took that advice, it makes me wonder if there's some sort of interaction with the broadcast of that message, but I don't know what it would be. ... That would explain why the console application works fine, as it may skip the window message broadcasting, or at least not having a window itself would not wind up being a recursive bottleneck in the broadcast. ... You do not need to subscribe to the ProgressChanged event, and even if you do, the subscriber does not need to be a GUI component. ...
    (microsoft.public.dotnet.languages.csharp)
  • Newbie to security -- Im stuck.
    ... Service application and a GUI to interface to it. ... I have the Login and Password for the database in the ... Registry and I wish to encrypt it. ... Dim rsa As New RSACryptoServiceProvider ...
    (microsoft.public.dotnet.security)
  • Re: Disable changing history settings
    ... Setting those settings is only ment to protect the GUI. ... But if you apply this policy and someone alters it in the registry the ...
    (microsoft.public.windows.group_policy)
  • Re: using Microsoft.Office.Interop.Word not working!
    ... An error occurred during the processing of a configuration file ... To enable assembly bind failure logging, set the registry value ... office PIAs may not have been installed properly. ...
    (microsoft.public.dotnet.languages.csharp)