Windows Registry - Flawed Design
grom
----------------------
The Registry is a hierarchical database within later versions of Windows
(95/98/NT4/NT5) where all the system settings are stored. It has replaced
all of the .ini files that were present in Windows 3.x. The data from
system.ini,win.ini, control.ini, are all contained within it now, along
with hundreds of other system settings. Additionally, all Windows specific
programs are now to store their initialization data within the Registry
instead of in .ini files in your Windows folder.
http://geodsoft.com/opinion/server_comp/reliability/registry.htm
------------------------------------------------------------------
When Microsoft replaced .INI text configuration files with the registry, it
made one of the worst technical decisions ever. Moving parts of the
registry to Windows 2000's Active Directory does not significantly change
anything. The mechanics of access may have changed, but the logical issues
are pretty much the same.
I won't try to guess how Microsoft justified the adoption of a registry. I
can only see one superficial appeal to it. A number of programs share
configuration data and by having a central repository, they only need to go
to one place to get the data. The fallacy is that registry data is accessed
by key name. There is little fundamental difference between accessing a
dozen different keys in a deeply nested registry tree than there is a dozen
text files in different directories with different filenames. If you don't
already know the key, i.e., have it stored somewhere, there is no more
direct way to it than a text file whose location you don't know.
Theoretically many binary lookups should be more efficient than many file
opens. In practice few applications will need to open more than two files:
one containing common system data and one application specific data.
Numerous binary tree lookups, in a large deeply nested structure, become
quite resource intensive. This is confirmed by the fact that Windows
systems slow with age as software is added; UNIX systems do not slow with
age due to software installs. Further, if the directory structure is
logical, you can often find the text configuration file you need, without
knowing before hand what its named or where it's located. Without an exact
key fragment or data, this is not possible in the registry.
A major difference between the registry and text configuration files, is
that the registry is a proprietary binary format with only two widely
available.general purpose utilities, for it and a number of custom GUI
front ends, each of which accesses specific limited sections of the
registry. There are more utilities and tools to manipulate text files than
any other storage format on earth. There isn't anything that can't be done,
either manually or automatically, with scripting in the way of locating,
comparing or changing text files using general purpose text editing and
manipulation utilities. Text files can have user friendly, graphical front
ends more easily than proprietary binary files. Text file formats normally
allow as much internal documentation as the developers care to provide.
The .INI format used in pre Windows 95 versions, had named areas or stanzas
with an open ended number of key value pairs following. Add intelligent file
names to a logical directory structure and there isn't any data that can't
be stored and in a logical relationship to the programs that use the data.
Even binary data can be stored in a hex representation. If the
configuration data is program specific, it can go with the program. If it's
system wide, it can be stored in a standard system directory, in which key
filenames and stanzas within files would be reserved.
With files, programs read what they need and not much more, if the files are
well planned. The SOFTWARE part of the registry on my workstation is over
8MB and I know of a SAM over 19MB. The registry grows over the life of
system and systems get slower as a result, because on Windows systems,
virtually all programs need to access the registry. Few if any uninstall
programs, cleanup everything that was installed. When an application lacks
an uninstall program or either the install or uninstall program has a bug,
there is a increased chance some or all the registry entries will get left
behind.
Limited Registry Tools
-----------------------
Microsoft provides tools to maintain only parts of the registry. IIS 3 was a
good example where there were many more registry entries than there were
options in the Internet Manager. It also provides two limited editors as the
only general purpose access to the registry and says it's can't be
responsible if these tools are used, even though they are often the only
way to maintain parts of the registry. There are some additional tools in
the Resource kit but their value is limited. If a registry key contains
spaces, and many do, the limitations of the command line interface may
provide no way to pass the necessary arguments to the utility. Correctly
passing the arguments may require the equivalent of nested or escaped
quotes which the NT command prompt can't do.
The registry has no equivalent of create, modify or access times so it's not
possible to locate recently changed registry entries or to relate
modification times to the onset of a problem.
Keys in the registry have security permissions that are very similar to
directory permissions. Anyone who has seriously tightened file and directory
security, on almost any kind of server, knows that this almost invariably
breaks some user's access to some applications. With files, it's generally
pretty straightforward to figure out who needs update access, who needs read
access and who needs no access. With the registry, since all access is
programmatic, behind the scenes, and not documented, it's almost impossible
to know who needs access to what let alone what level of access. I've never
needed a guide to tell me how to tighten file security, but any independent
attempt to tighten registry security without clear guidelines as to what
should and should not be changed is very likely to lead to serious trouble.
Permission changes can be at the current level or apply to sub keys. The
registry is quite deep in some areas and often huge in its entirety.
Changing individual entries, except to limit access to known specific keys
for specific security related results won't do much and changing sub keys
will make changes several levels down that you can only hope need to be the
same as the parent key's permissions.
Registry Security and Installs
--------------------------------
The worst problem with the registry is that is a single structure, to which
administrators normally have full access. Most software installs need to be
run as an administrator. Thus any bug in a software install program can
result in corruption in almost any part of the registry. Unlike file and
directory related programs, where administrators generally have a pretty
good idea what will and will not be affected, there is no way to know what
registry keys any install program will access deliberately or
unintentionally change. I'm convinced that this is the primary source of
bizarre install related results.
By definition, one of the specific functions of an install program, is to
update the registry. Programmers develop install programs like any others,
make mistakes, and get poor specifications. There are important differences
though. The registry is probably the most system specific component on any
Windows system, as every system variation is reflected in it, somewhere,
thus making it one of the hardest parts to properly test. All changes are
normally made with the full authority of the system.
Any misunderstanding the programmer has regarding the use of system calls
related to registry updates, could result in unpredictable consequences.
Whatever the programmer believes his program needs to or update will get
updated except when the programmer makes a mistake. Because installs execute
with administrator level access, then whatever the install program is built
to do, whether it is intentional or accidental, will be done. When you
install software, you are normally asked what directory to put it in,
usually what program group to put it in and sometimes whether or not to
create a desktop icon. You're never asked about registry updates. When you
install software you implicitly trust the install programmer as well as the
company that employs him or her and hopefully tests the installs well. When
you install Windows software, someone else is making critical system
choices for you, without your knowledge or consent.
When software is installed on UNIX and configuration files specific to that
software are created or updated, as opposed to a centrally shared,
system-wide registry, the programmer pretty much has to have malicious
intent to damage anything but the software being installed. Also, most UNIX
installs are done with scripts that the administrator can read if they
wish, as opposed to binary executables, which for all practical purposes,
cannot be read. Further, UNIX install programs that find missing shared
libraries or other perquisite parts, inform the administrator or the
missing components, but allow the administrator to locate and install the
prerequisites. Windows programs that require shared functions not
automatically provided with the OS, automatically provide them,
in whatever version the install vendor thinks is appropriate, creating DLL
hell. With the registry, any programming mistakes can cause serious
unintended damage. The surprise is not that some installs go bad, but that
the large majority actually work.
--------------------------------END-------------------------------------------
Other Registry Problems
-----------------------
Over time the Registry can get congested and confused with unused, corrupt
or unnecessary links or "keys". The result is a cluttered Registry that
will slow down your system and even cause it to crash.
Applications may introduce modifications into the registry without any
protection or verification whatsoever, which may cause other applications or
even the OS to crash. This seriously compromises the reliability of the
entire system.
It is usually easier to fix a corrupt registry by reinstalling.
If the registry is improperly edited, it can cause severe problems, which
could lead to loss of data.
Registry Bugs
-------------
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q296733
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ddtools/hh/ddtools/bccodes_0t5z.asp
http://msdn.microsoft.com/library/default.asp?url=/library/
en-us/ddtools/hh/ddtools/bccodes_0t5z.asp (short version of link above)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q184398
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q176906
grom
Net Resident
<gro...@optusnet.com.au> wrote:
> What Is The Registry?
<snip>
Personally I always assumed that the registry was just a way to obfuscate
the system further which seems to me to be near and dear to MS's heart (or lack
thereof...).
*shrug*
Walter Haberl
addition to the keys in the registry anyway, so almost nothing is gained
from this concept, as usual ...
Spicerun
provide a mechanism in which proprietary programs could lock themselves
on one only computer,prevent execution on other computers, and not worry that
anyone is going to break the copy-protection on the program (ie - If you
try to break open our program, you'll break the entire system). It's
like a central place to store all of your license keys that can't be
edited.
In <3c2f17c7$0$26026$afc3...@news.optusnet.com.au>, grom wrote:
> What Is The Registry?
> ----------------------
> The Registry is a hierarchical database within later versions of Windows
> (95/98/NT4/NT5) where all the system settings are stored. It has
> replaced all of the .ini files that were present in Windows 3.x. The
> data from system.ini,win.ini, control.ini, are all contained within it
> now, along with hundreds of other system settings. Additionally, all
> Windows specific programs are now to store their initialization data
> within the Registry instead of in .ini files in your Windows folder.
...
Tsu Dho Nimh
>The SOFTWARE part of the registry on my workstation is over
>8MB and I know of a SAM over 19MB. The registry grows over the life of
>system and systems get slower as a result, because on Windows systems,
>virtually all programs need to access the registry.
It is possible to clean this crap out ... but Windows does not
have a built-in "purge" tool.
And INI files were WAY easier to use.
Tsu Dho Nimh
It is my job to completely create professional technology
in order that we may seamlessly supply competitive data.
Tsu Dho Nimh
>And all this time, I thought the true purpose of the registry was to
>provide a mechanism in which proprietary programs could lock themselves
>on one only computer,prevent execution on other computers, and not worry that
>anyone is going to break the copy-protection on the program (ie - If you
>try to break open our program, you'll break the entire system). It's
>like a central place to store all of your license keys that can't be
>edited.
You can look at all the entries and edit the registry.
Charlie Ebert
What frankly griped me about the Registry is 3rd party soft
NIC vendors who catered to the WIN crowd would install
settings into the registry as well as software and not
UN-install it when the time came. The Registry would
be completely crapped out to the point your new WIN
card wouldn't work at all.
Windows is a slum-house of intellectual property.
--
Charlie
GreyCloud
> grom <gro...@optusnet.com.au> wrote:
>
>
>>The SOFTWARE part of the registry on my workstation is over
>>8MB and I know of a SAM over 19MB. The registry grows over the life of
>>system and systems get slower as a result, because on Windows systems,
>>virtually all programs need to access the registry.
>
> It is possible to clean this crap out ... but Windows does not
> have a built-in "purge" tool.
I thought that the scanreg /opt was a way of purging the useless clutter
out of the registry.
Erik Funkenbusch
better", not any inherantly flawed design of the registry.
"grom" <gro...@optusnet.com.au> wrote in message news:3c2f17c7$0$26026
> The fallacy is that registry data is accessed
> by key name. There is little fundamental difference between accessing a
> dozen different keys in a deeply nested registry tree than there is a dozen
> text files in different directories with different filenames.
And here we have the rub. There is little fundamental difference between the
two mechanisms. You have just admitted this, therefore any "serious flaw" in
the registry must exist in configuration files too, or it would be a
fundamental difference, would it not?
> If you don't
> already know the key, i.e., have it stored somewhere, there is no more
> direct way to it than a text file whose location you don't know.
No difference between the two in this manner either.
> Theoretically many binary lookups should be more efficient than many file
> opens. In practice few applications will need to open more than two files:
> one containing common system data and one application specific data.
And one containing user specific data.
> Numerous binary tree lookups, in a large deeply nested structure, become
> quite resource intensive.
This is complete bullshit, they are no more resource intensive than parsing
large text files with many configuration items.
> This is confirmed by the fact that Windows
> systems slow with age as software is added; UNIX systems do not slow with
> age due to software installs. Further, if the directory structure is
> logical, you can often find the text configuration file you need, without
> knowing before hand what its named or where it's located. Without an exact
> key fragment or data, this is not possible in the registry.
Can you be any more contradictory, you just said a few paragraphs ago that it
wasn't any easier to find text files you don't know. Further, the registry
structure can be just as equally logically laid out.
> A major difference between the registry and text configuration files, is
> that the registry is a proprietary binary format with only two widely
> available.general purpose utilities, for it and a number of custom GUI
> front ends, each of which accesses specific limited sections of the
> registry.
Doesn't sound any different between text files in /etc or ~ and the various
GUI front-ends being developed fro Linux (YaST2, DrakConfig (or whatever it's
called..), the various Gnome and KDE config tools, etc...
> There are more utilities and tools to manipulate text files than
> any other storage format on earth.
While true, this is actually a negative for text files. First, you need to
learn lots of different utilities with differen syntax, then you need to write
code for every app you use to parse and process those files, since text files
often have very different formats.
> There isn't anything that can't be done,
> either manually or automatically, with scripting in the way of locating,
> comparing or changing text files using general purpose text editing and
> manipulation utilities. Text files can have user friendly, graphical front
> ends more easily than proprietary binary files. Text file formats normally
> allow as much internal documentation as the developers care to provide.
Bullshit, there is no reason that text files can have GUI front ends easier
than with registry front-ends. In fact, it's easier to do the registry
front-end because registry access always uses the same API's no matter what
the configuration, while text files have broad and varying formats that need
to be understood by the front-end.
> The .INI format used in pre Windows 95 versions, had named areas or stanzas
> with an open ended number of key value pairs following. Add intelligent file
> names to a logical directory structure and there isn't any data that can't
> be stored and in a logical relationship to the programs that use the data.
There is no fundamental difference between the data associations used in the
registry or .ini files. They each use a "section" (key) name and key/value
pairs.
> Even binary data can be stored in a hex representation.
Which must first be converted from binary to text, and text to binary when
reading it.
> If the
> configuration data is program specific, it can go with the program. If it's
> system wide, it can be stored in a standard system directory, in which key
> filenames and stanzas within files would be reserved.
The problem then becomes, where is it stored? The #1 problem with .ini files
was that the program often got confused about where they were located, and if
two programs used the same named file, they corrupted each other. While, the
name problem is possible in the registry as well, it's unlikely because apps
are supposed to store their config files in sub-sections of their company name
or some other unique name related to their product and then under app name
giving two unique keys which is unlikely to ever be the same (in fact, i've
never heard of any app using this convention which ever had a problem).
> With files, programs read what they need and not much more, if the files are
> well planned.
Of course the planning of the files has no control over how the use has edited
them.
> The SOFTWARE part of the registry on my workstation is over
> 8MB and I know of a SAM over 19MB.
Huh? How exactly would you know how large the software part of the registry
is, and SAM databases are not in the registry.
> The registry grows over the life of
> system and systems get slower as a result, because on Windows systems,
> virtually all programs need to access the registry. Few if any uninstall
> programs, cleanup everything that was installed. When an application lacks
> an uninstall program or either the install or uninstall program has a bug,
> there is a increased chance some or all the registry entries will get left
> behind.
This is a myth. When win9x systems start slowing down, it's not because of
the registry. It's because of things like disk fragmentation, and quite often
large temp file or cache directories (with the internet explorer integrated
shells, the cache directories are searched for almost any operation, which
makes things appear to slow down significantly. Try clearing out your caches
and temp directories regularly and notice the speed improvements).
> Limited Registry Tools
> -----------------------
> Microsoft provides tools to maintain only parts of the registry.
What is meant is that MS provides limited GUI front-ends. The same is true of
Unix based config files.
> IIS 3 was a
> good example where there were many more registry entries than there were
> options in the Internet Manager.
And how many options are available in GUI front-ends for apache?
> It also provides two limited editors as the
> only general purpose access to the registry and says it's can't be
> responsible if these tools are used, even though they are often the only
> way to maintain parts of the registry.
"limited" editors? They allow you to edit everything, how is that limited?
> There are some additional tools in
> the Resource kit but their value is limited. If a registry key contains
> spaces, and many do, the limitations of the command line interface may
> provide no way to pass the necessary arguments to the utility. Correctly
> passing the arguments may require the equivalent of nested or escaped
> quotes which the NT command prompt can't do.
This is simply From the command line there are many options, including
exporting a sub-key to text and editing it with any command line editor then
reimporting it.
> The registry has no equivalent of create, modify or access times so it's not
> possible to locate recently changed registry entries or to relate
> modification times to the onset of a problem.
This is about the only legitimate claim i've read so far. Yes, this is true.
> Keys in the registry have security permissions that are very similar to
> directory permissions. Anyone who has seriously tightened file and directory
> security, on almost any kind of server, knows that this almost invariably
> breaks some user's access to some applications. With files, it's generally
> pretty straightforward to figure out who needs update access, who needs read
> access and who needs no access. With the registry, since all access is
> programmatic, behind the scenes, and not documented, it's almost impossible
> to know who needs access to what let alone what level of access. I've never
> needed a guide to tell me how to tighten file security, but any independent
> attempt to tighten registry security without clear guidelines as to what
> should and should not be changed is very likely to lead to serious trouble.
> Permission changes can be at the current level or apply to sub keys. The
> registry is quite deep in some areas and often huge in its entirety.
> Changing individual entries, except to limit access to known specific keys
> for specific security related results won't do much and changing sub keys
> will make changes several levels down that you can only hope need to be the
> same as the parent key's permissions.
I'm just not even sure who this makes sense. I simply don't understand how
someone can claim that you can know what permissions to apply to files, but
not know what permissions to apply to registry keys. As already admitted,
they are functionally the same thing.
> Registry Security and Installs
> --------------------------------
> The worst problem with the registry is that is a single structure, to which
> administrators normally have full access.
And administrators of unix systems don't have full access to /etc?
> Most software installs need to be run as an administrator.
As do most unix installs, since you need write access to /etc to put your
config files into it. Yes, it's usually possible to install something into
your own home directory, but then the same is usually true of apps in Windows
as well. As with unix, whole classes of apps need administrator access to
function on either system.
> Thus any bug in a software install program can
> result in corruption in almost any part of the registry. Unlike file and
> directory related programs, where administrators generally have a pretty
> good idea what will and will not be affected, there is no way to know what
> registry keys any install program will access deliberately or
> unintentionally change. I'm convinced that this is the primary source of
> bizarre install related results.
If you don't know what sections of the registry will be effected, what makes
you think you'll know what will be effected the other way? Again, it's
already been admitted that they're functionally the same.
> By definition, one of the specific functions of an install program, is to
> update the registry. Programmers develop install programs like any others,
> make mistakes, and get poor specifications. There are important differences
> though. The registry is probably the most system specific component on any
> Windows system, as every system variation is reflected in it, somewhere,
> thus making it one of the hardest parts to properly test. All changes are
> normally made with the full authority of the system.
Not even remotely true. For instance, all user specific settings are stored
in the users registry hive (and contrary to what is stated here, the registry
is *NOT* one big database, it's actually stored in several sub-files, some of
which are loaded specifically for each and every user). Of course a user has
direct access to their own hive, and applications running run in the users
security context.
> Any misunderstanding the programmer has regarding the use of system calls
> related to registry updates, could result in unpredictable consequences.
And what about misunderstandings in the way to use text processing tools?
> Whatever the programmer believes his program needs to or update will get
> updated except when the programmer makes a mistake.
Same is true of text files.
> Because installs execute with administrator level access,
As they almost always do in Unix/Linx.
> then whatever the install program is built
> to do, whether it is intentional or accidental, will be done.
Ditto.
> When you
> install software, you are normally asked what directory to put it in,
> usually what program group to put it in and sometimes whether or not to
> create a desktop icon. You're never asked about registry updates. When you
> install software you implicitly trust the install programmer as well as the
> company that employs him or her and hopefully tests the installs well. When
> you install Windows software, someone else is making critical system
> choices for you, without your knowledge or consent.
This has absolutely nothing to do with the registry, it has to do with how
installation code is written. I've seen plenty of script based installs on
Windows for instance.
> When software is installed on UNIX and configuration files specific to that
> software are created or updated, as opposed to a centrally shared,
> system-wide registry, the programmer pretty much has to have malicious
> intent to damage anything but the software being installed. Also, most UNIX
> installs are done with scripts that the administrator can read if they
> wish, as opposed to binary executables, which for all practical purposes,
> cannot be read.
Again, nothing to do with the registry. This is simply a philisophical
difference in the way install programs are written. You could do precisely
the same for Unix/Linux, or you could create scripts on Windows.
> Further, UNIX install programs that find missing shared
> libraries or other perquisite parts, inform the administrator or the
> missing components, but allow the administrator to locate and install the
> prerequisites. Windows programs that require shared functions not
> automatically provided with the OS, automatically provide them,
> in whatever version the install vendor thinks is appropriate, creating DLL
> hell. With the registry, any programming mistakes can cause serious
> unintended damage. The surprise is not that some installs go bad, but that
> the large majority actually work.
This is no longer the case, since Windows provides side-by side DLL installs
and windows file protection. And again, it has nothing to do with the
registry.
> --------------------------------END-----------------------------------------
--
>
> Other Registry Problems
> -----------------------
> Over time the Registry can get congested and confused with unused, corrupt
> or unnecessary links or "keys". The result is a cluttered Registry that
> will slow down your system and even cause it to crash.
Again, it's a myth. I espcially like the "even cause it to crash". If it's
unused, it's not going to cause it to crash, now is it? That's pure FUD. And
i've yet to see a Linux system that didn't have unused config files in /etc,
unless the admin was very good at cleaning things up.
> Applications may introduce modifications into the registry without any
> protection or verification whatsoever, which may cause other applications or
> even the OS to crash. This seriously compromises the reliability of the
> entire system.
I love how in one hand you claim that registry security can cause problems
because you can secure it in such a way as to prevent apps to not have access
to what they need, then in the other hand claim there is no way to protect it
from unauthorized access.
You need a consistent argument.
> It is usually easier to fix a corrupt registry by reinstalling.
One could say the same thing about a complicated config file.
> If the registry is improperly edited, it can cause severe problems, which
> could lead to loss of data.
Duh, that's why it's called "editing". The same is true of config files.
> Registry Bugs
> -------------
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q296733
Wow, didn't know about this one. But it was in one service pack, and is
fixed.
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ddtools/hh/dd
tools/bccodes_0t5z.asp
This is not a bug. This is a "bug check". I can understand your confusion,
but it's basically a warning message when something is corrupted, not a bug
itself.
> http://msdn.microsoft.com/library/default.asp?url=/library/
> en-us/ddtools/hh/ddtools/bccodes_0t5z.asp (short version of link above)
This is the exact same link (not even a different link to the same thing).
Again, it's not even a bug. You're padding your list
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q184398
This is not a bug in the registry or the OS, it's a bug in the Microsoft
Transaction Server. Not relevant. And by "corrupt the registry" they mean
corrupt the keys relevant to this program, not corrupting the registry itself.
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q176906
This is a bug, but a very rare one. So, 5 links.. 2 real bugs. you're
stretching.
Charlie Ebert
Erik Funkenbusch wrote:
<registry rant deletia>
Erik,
Swallow two full boxes of chocolate Ex-lax and call us next
year if you have any more registry ideas.
--
Charlie
Ian Smith
>
> And here we have the rub. There is little fundamental difference between the
> two mechanisms. You have just admitted this, therefore any "serious flaw" in
> the registry must exist in configuration files too, or it would be a
> fundamental difference, would it not?
>
No. And the reason is just that "little fundamental difference". Bit
of a "serious flaw" in your logik, erik. Are you tired, or just getting
lazy?
--
----------------------------------------------------------------------------
Ian Smith
----------------------------------------------------------------------------
Michael Vester
> Grom, the vast majority of this article boils down to "I like text files
> better", not any inherantly flawed design of the registry.
>
> "grom" <gro...@optusnet.com.au> wrote in message news:3c2f17c7$0$26026
> > The fallacy is that registry data is accessed
> > by key name. There is little fundamental difference between accessing a
> > dozen different keys in a deeply nested registry tree than there is a
> > dozen text files in different directories with different filenames.
>
> And here we have the rub. There is little fundamental difference between
> the
> two mechanisms. You have just admitted this, therefore any "serious flaw"
> in the registry must exist in configuration files too, or it would be a
> fundamental difference, would it not?
>
That does not make any sense.
> > If you don't
> > already know the key, i.e., have it stored somewhere, there is no more
> > direct way to it than a text file whose location you don't know.
>
> No difference between the two in this manner either.
>
Except text files can be very well documented. I like to add all sorts of
info to my configuration files. Makes them self-documenting.
> > Theoretically many binary lookups should be more efficient than many
> > file opens. In practice few applications will need to open more than two
> > files: one containing common system data and one application specific
> > data.
>
> And one containing user specific data.
>
> > Numerous binary tree lookups, in a large deeply nested structure, become
> > quite resource intensive.
>
> This is complete bullshit, they are no more resource intensive than
> parsing large text files with many configuration items.
>
Opening a few tiny 1 - a few K text files verses opening 3 gigantic binary
files. The Unix way is much more efficient.
> > This is confirmed by the fact that Windows
> > systems slow with age as software is added; UNIX systems do not slow
> > with age due to software installs. Further, if the directory structure
> > is logical, you can often find the text configuration file you need,
> > without knowing before hand what its named or where it's located.
> > Without an exact key fragment or data, this is not possible in the
> > registry.
>
> Can you be any more contradictory, you just said a few paragraphs ago that
> it
> wasn't any easier to find text files you don't know. Further, the
> registry structure can be just as equally logically laid out.
>
Most /etc configuration names are the same as the program they support.
> > A major difference between the registry and text configuration files, is
> > that the registry is a proprietary binary format with only two widely
> > available.general purpose utilities, for it and a number of custom GUI
> > front ends, each of which accesses specific limited sections of the
> > registry.
>
> Doesn't sound any different between text files in /etc or ~ and the
> various GUI front-ends being developed fro Linux (YaST2, DrakConfig (or
> whatever it's called..), the various Gnome and KDE config tools, etc...
>
> > There are more utilities and tools to manipulate text files than
> > any other storage format on earth.
>
> While true, this is actually a negative for text files. First, you need
> to learn lots of different utilities with differen syntax, then you need
> to write code for every app you use to parse and process those files,
> since text files often have very different formats.
>
There is only one format for a configuration file that I can see. A line
of text with a <LF>. Comments are #. Any text editor can edit them.
> > There isn't anything that can't be done,
> > either manually or automatically, with scripting in the way of locating,
> > comparing or changing text files using general purpose text editing and
> > manipulation utilities. Text files can have user friendly, graphical
> > front ends more easily than proprietary binary files. Text file formats
> > normally allow as much internal documentation as the developers care to
> > provide.
>
> Bullshit, there is no reason that text files can have GUI front ends
> easier
> than with registry front-ends. In fact, it's easier to do the registry
> front-end because registry access always uses the same API's no matter
> what the configuration, while text files have broad and varying formats
> that need to be understood by the front-end.
>
With any amount of experience, one quickly discards the gui front end and
edits the text file directly.
All my configuration files are in /etc. Managing names can be done just
like you state with registry pairs.
> > With files, programs read what they need and not much more, if the files
> > are well planned.
>
> Of course the planning of the files has no control over how the use has
> edited them.
>
Why would anyone change their name or location?
> > The SOFTWARE part of the registry on my workstation is over
> > 8MB and I know of a SAM over 19MB.
>
> Huh? How exactly would you know how large the software part of the
> registry is, and SAM databases are not in the registry.
>
On my Windows machine, the registry occupies over 5 megabytes. On my main
Linux workstation, /etc occupies just over 3 megabytes. My Linux has many
more installed applications. And /etc has all the scripts for launching
programs. Of course, as you point out later, much of /etc is not even used.
> > The registry grows over the life of
> > system and systems get slower as a result, because on Windows systems,
> > virtually all programs need to access the registry. Few if any uninstall
> > programs, cleanup everything that was installed. When an application
> > lacks an uninstall program or either the install or uninstall program
> > has a bug, there is a increased chance some or all the registry entries
> > will get left behind.
>
> This is a myth. When win9x systems start slowing down, it's not because
> of
> the registry. It's because of things like disk fragmentation, and quite
> often large temp file or cache directories (with the internet explorer
> integrated shells, the cache directories are searched for almost any
> operation, which
> makes things appear to slow down significantly. Try clearing out your
> caches and temp directories regularly and notice the speed improvements).
>
The reigistry is always growing. A small application still has to open a
gigantic file just to access a few bytes of information.
> > Limited Registry Tools
> > -----------------------
> > Microsoft provides tools to maintain only parts of the registry.
>
> What is meant is that MS provides limited GUI front-ends. The same is
> true of Unix based config files.
>
> > IIS 3 was a
> > good example where there were many more registry entries than there were
> > options in the Internet Manager.
>
> And how many options are available in GUI front-ends for apache?
>
Hardly a great demand for a gui front end for Apache. It would only get iin
the way.
>
> > It also provides two limited editors as the
> > only general purpose access to the registry and says it's can't be
> > responsible if these tools are used, even though they are often the only
> > way to maintain parts of the registry.
>
> "limited" editors? They allow you to edit everything, how is that
> limited?
>
And one mistake, you render your Windows machine unbootable.
> > There are some additional tools in
> > the Resource kit but their value is limited. If a registry key contains
> > spaces, and many do, the limitations of the command line interface may
> > provide no way to pass the necessary arguments to the utility. Correctly
> > passing the arguments may require the equivalent of nested or escaped
> > quotes which the NT command prompt can't do.
>
> This is simply From the command line there are many options, including
> exporting a sub-key to text and editing it with any command line editor
> then reimporting it.
>
I thought the great reason to use the registry was to use a pretty gui. You
still have to edit it with a text editor?
> > The registry has no equivalent of create, modify or access times so it's
> > not possible to locate recently changed registry entries or to relate
> > modification times to the onset of a problem.
>
> This is about the only legitimate claim i've read so far. Yes, this is
> true.
>
Amazing!!! Erik agreed. I thought the registry was perfect.
Remembering it took Microsoft over twenty years to come up with this. It
was never an issue with Linux.
> >
--------------------------------END-----------------------------------------
> --
> >
> > Other Registry Problems
> > -----------------------
> > Over time the Registry can get congested and confused with unused,
> > corrupt or unnecessary links or "keys". The result is a cluttered
> > Registry that will slow down your system and even cause it to crash.
>
> Again, it's a myth. I espcially like the "even cause it to crash". If
> it's
> unused, it's not going to cause it to crash, now is it? That's pure FUD.
> And i've yet to see a Linux system that didn't have unused config files in
> /etc, unless the admin was very good at cleaning things up.
>
More like rendering your computer unbootable. With many text based
configuration files, a screwup in one will not affect others.
> > Applications may introduce modifications into the registry without any
> > protection or verification whatsoever, which may cause other
> > applications or even the OS to crash. This seriously compromises the
> > reliability of the entire system.
>
> I love how in one hand you claim that registry security can cause problems
> because you can secure it in such a way as to prevent apps to not have
> access to what they need, then in the other hand claim there is no way to
> protect it from unauthorized access.
>
> You need a consistent argument.
>
> > It is usually easier to fix a corrupt registry by reinstalling.
>
> One could say the same thing about a complicated config file.
>
I make a backup of a configuration file before I edit it. Any problems and
I can easily return to a functioning config.
> > If the registry is improperly edited, it can cause severe problems,
> > which could lead to loss of data.
>
> Duh, that's why it's called "editing". The same is true of config files.
>
Yet one mistake in "editing" the register will render your computer
unbootable. From personal experience of course. I have yet to render a
Linux box unbootable from mistakes in editing configuration files. I am
sure that if I mucked up fstab, I would not have access to my partitions on
the next very infrequent reboot.
> > Registry Bugs
<snip>
>
I always thought that the registry was a bad idea. I like having all the
configuration files in /etc. Simple and very easy to maintain, even for a
slightly more advanced newbie like me.
With my Windows machine, if any problems crop up in the registry, I simply
zero out the drive and reload from a CDRed ghosted image. Much simpler than
having to deal with the registry. I guess I am too stupid to master
registry editing. The Linux/Unix way is much easier.
--
1:55pm up 46 days, 2:46, 1 user, load average: 1.29, 1.14, 1.05
Spammer diluetent (additions welcome)
ms...@microsoft.com ab...@hotmail.com MrB...@btamail.net.cn
flat...@att.net tsetf...@hotmail.com sfazv...@hotmail.com
hot...@prontomail.com webm...@korcin.com hot...@protolmail.com
Erik Funkenbusch
news:a0o3nt$m887q$1...@ID-121900.news.dfncis.de...
> Erik Funkenbusch wrote:
>
> > Grom, the vast majority of this article boils down to "I like text files
> > better", not any inherantly flawed design of the registry.
> >
> > "grom" <gro...@optusnet.com.au> wrote in message news:3c2f17c7$0$26026
> > > The fallacy is that registry data is accessed
> > > by key name. There is little fundamental difference between accessing a
> > > dozen different keys in a deeply nested registry tree than there is a
> > > dozen text files in different directories with different filenames.
> >
> > And here we have the rub. There is little fundamental difference between
> > the
> > two mechanisms. You have just admitted this, therefore any "serious flaw"
> > in the registry must exist in configuration files too, or it would be a
> > fundamental difference, would it not?
>
> That does not make any sense.
If there is "little fundamental difference", how can they be fundamentally
differnt?
> > > If you don't
> > > already know the key, i.e., have it stored somewhere, there is no more
> > > direct way to it than a text file whose location you don't know.
> >
> > No difference between the two in this manner either.
>
> Except text files can be very well documented. I like to add all sorts of
> info to my configuration files. Makes them self-documenting.
There is nothing stopping you from adding comments in the registry as well,
just insert a few keys and put text comments in.
> > > Theoretically many binary lookups should be more efficient than many
> > > file opens. In practice few applications will need to open more than two
> > > files: one containing common system data and one application specific
> > > data.
> >
> > And one containing user specific data.
> >
> > > Numerous binary tree lookups, in a large deeply nested structure, become
> > > quite resource intensive.
> >
> > This is complete bullshit, they are no more resource intensive than
> > parsing large text files with many configuration items.
> >
> Opening a few tiny 1 - a few K text files verses opening 3 gigantic binary
> files. The Unix way is much more efficient.
The files are open by the OS all the time, therefore no extra resources are
consumed for individual programs opening them.
> > > This is confirmed by the fact that Windows
> > > systems slow with age as software is added; UNIX systems do not slow
> > > with age due to software installs. Further, if the directory structure
> > > is logical, you can often find the text configuration file you need,
> > > without knowing before hand what its named or where it's located.
> > > Without an exact key fragment or data, this is not possible in the
> > > registry.
> >
> > Can you be any more contradictory, you just said a few paragraphs ago that
> > it
> > wasn't any easier to find text files you don't know. Further, the
> > registry structure can be just as equally logically laid out.
> >
> Most /etc configuration names are the same as the program they support.
What happens if you have two programs with the same name?
> > While true, this is actually a negative for text files. First, you need
> > to learn lots of different utilities with differen syntax, then you need
> > to write code for every app you use to parse and process those files,
> > since text files often have very different formats.
> >
> There is only one format for a configuration file that I can see. A line
> of text with a <LF>. Comments are #. Any text editor can edit them.
There are lots of formats. Do comments start with #'s or ;'s? Hell,
gs.fontmap uses %'s for comments.
does the format have a name = option format, or is it just a line item? Is it
field oriented (like, say, hosts) or are there commands issued per line?
etc...
> > > There isn't anything that can't be done,
> > > either manually or automatically, with scripting in the way of locating,
> > > comparing or changing text files using general purpose text editing and
> > > manipulation utilities. Text files can have user friendly, graphical
> > > front ends more easily than proprietary binary files. Text file formats
> > > normally allow as much internal documentation as the developers care to
> > > provide.
> >
> > Bullshit, there is no reason that text files can have GUI front ends
> > easier
> > than with registry front-ends. In fact, it's easier to do the registry
> > front-end because registry access always uses the same API's no matter
> > what the configuration, while text files have broad and varying formats
> > that need to be understood by the front-end.
>
> With any amount of experience, one quickly discards the gui front end and
> edits the text file directly.
That's not the point, the criticism was talking about how poor the GUI front
ends in windows are.
> > The problem then becomes, where is it stored? The #1 problem with .ini
> > files was that the program often got confused about where they were
> > located, and if
> > two programs used the same named file, they corrupted each other. While,
> > the name problem is possible in the registry as well, it's unlikely
> > because apps are supposed to store their config files in sub-sections of
> > their company name or some other unique name related to their product and
> > then under app name giving two unique keys which is unlikely to ever be
> > the same (in fact, i've never heard of any app using this convention which
> > ever had a problem).
>
> All my configuration files are in /etc. Managing names can be done just
> like you state with registry pairs.
That depends on the distro. On my debian system the config files for grub are
in /boot/grub.
> > > With files, programs read what they need and not much more, if the files
> > > are well planned.
> >
> > Of course the planning of the files has no control over how the use has
> > edited them.
>
> Why would anyone change their name or location?
The point was that if the text files are laid out correctly, you didn't have
to read more than was necessary. There's nothing about name or location in
this.
> > > The SOFTWARE part of the registry on my workstation is over
> > > 8MB and I know of a SAM over 19MB.
> >
> > Huh? How exactly would you know how large the software part of the
> > registry is, and SAM databases are not in the registry.
>
> On my Windows machine, the registry occupies over 5 megabytes. On my main
> Linux workstation, /etc occupies just over 3 megabytes. My Linux has many
> more installed applications. And /etc has all the scripts for launching
> programs. Of course, as you point out later, much of /etc is not even used.
What does that have to do with what I was saying?
> > > The registry grows over the life of
> > > system and systems get slower as a result, because on Windows systems,
> > > virtually all programs need to access the registry. Few if any uninstall
> > > programs, cleanup everything that was installed. When an application
> > > lacks an uninstall program or either the install or uninstall program
> > > has a bug, there is a increased chance some or all the registry entries
> > > will get left behind.
> >
> > This is a myth. When win9x systems start slowing down, it's not because
> > of
> > the registry. It's because of things like disk fragmentation, and quite
> > often large temp file or cache directories (with the internet explorer
> > integrated shells, the cache directories are searched for almost any
> > operation, which
> > makes things appear to slow down significantly. Try clearing out your
> > caches and temp directories regularly and notice the speed improvements).
> >
> The reigistry is always growing. A small application still has to open a
> gigantic file just to access a few bytes of information.
No, the file is already open. And typically this is a one-time event.
> > > Limited Registry Tools
> > > -----------------------
> > > Microsoft provides tools to maintain only parts of the registry.
> >
> > What is meant is that MS provides limited GUI front-ends. The same is
> > true of Unix based config files.
> >
> > > IIS 3 was a
> > > good example where there were many more registry entries than there were
> > > options in the Internet Manager.
> >
> > And how many options are available in GUI front-ends for apache?
> >
> Hardly a great demand for a gui front end for Apache. It would only get iin
> the way.
That doesn't change the fact that the argument is hypocritical.
> > > It also provides two limited editors as the
> > > only general purpose access to the registry and says it's can't be
> > > responsible if these tools are used, even though they are often the only
> > > way to maintain parts of the registry.
> >
> > "limited" editors? They allow you to edit everything, how is that
> > limited?
> >
> And one mistake, you render your Windows machine unbootable.
Make one mistake in your /etc folder, and you can do the same.
> > > There are some additional tools in
> > > the Resource kit but their value is limited. If a registry key contains
> > > spaces, and many do, the limitations of the command line interface may
> > > provide no way to pass the necessary arguments to the utility. Correctly
> > > passing the arguments may require the equivalent of nested or escaped
> > > quotes which the NT command prompt can't do.
> >
> > This is simply From the command line there are many options, including
> > exporting a sub-key to text and editing it with any command line editor
> > then reimporting it.
>
> I thought the great reason to use the registry was to use a pretty gui. You
> still have to edit it with a text editor?
No. The reason to use the registry is to have a central place for
configuration. The context here is command line editing.
> > > The registry has no equivalent of create, modify or access times so it's
> > > not possible to locate recently changed registry entries or to relate
> > > modification times to the onset of a problem.
> >
> > This is about the only legitimate claim i've read so far. Yes, this is
> > true.
> >
> Amazing!!! Erik agreed. I thought the registry was perfect.
I didn't say that, I said it wasn't "fundamentally flawed".
> > This is no longer the case, since Windows provides side-by side DLL
> > installs
> > and windows file protection. And again, it has nothing to do with the
> > registry.
> >
> Remembering it took Microsoft over twenty years to come up with this. It
> was never an issue with Linux.
Not true. Dependancy issues have been around on Linux for years.
> --------------------------------END-----------------------------------------
> > --
> > >
> > > Other Registry Problems
> > > -----------------------
> > > Over time the Registry can get congested and confused with unused,
> > > corrupt or unnecessary links or "keys". The result is a cluttered
> > > Registry that will slow down your system and even cause it to crash.
> >
> > Again, it's a myth. I espcially like the "even cause it to crash". If
> > it's
> > unused, it's not going to cause it to crash, now is it? That's pure FUD.
> > And i've yet to see a Linux system that didn't have unused config files in
> > /etc, unless the admin was very good at cleaning things up.
>
> More like rendering your computer unbootable. With many text based
> configuration files, a screwup in one will not affect others.
Really, so if you screwup rc, or inittab or any of a number of other critical
files, your system will still boot just perfectly in all cases? Just like
with /etc, there are critical places and non-critical places.
> > > It is usually easier to fix a corrupt registry by reinstalling.
> >
> > One could say the same thing about a complicated config file.
> >
> I make a backup of a configuration file before I edit it. Any problems and
> I can easily return to a functioning config.
So backup your registry. Big deal.
> > > If the registry is improperly edited, it can cause severe problems,
> > > which could lead to loss of data.
> >
> > Duh, that's why it's called "editing". The same is true of config files.
> >
> Yet one mistake in "editing" the register will render your computer
> unbootable. From personal experience of course. I have yet to render a
> Linux box unbootable from mistakes in editing configuration files. I am
> sure that if I mucked up fstab, I would not have access to my partitions on
> the next very infrequent reboot.
So you admit you were wrong them when you claimed editing files in etc
wouldn't make your system unbootable.
> > > Registry Bugs
> <snip>
> >
> I always thought that the registry was a bad idea. I like having all the
> configuration files in /etc. Simple and very easy to maintain, even for a
> slightly more advanced newbie like me.
>
> With my Windows machine, if any problems crop up in the registry, I simply
> zero out the drive and reload from a CDRed ghosted image. Much simpler than
> having to deal with the registry. I guess I am too stupid to master
> registry editing. The Linux/Unix way is much easier.
It's all a frame of mind.
TuxTrax
<nomail...@nothanks.org> wrote:
You have to ask yourself what kind of moron designs any system around one
part, the failure of which, brings down the whole system.
What kind of an idiot would design an operating system so that its very
life depends on *one* *file* . I don't take bill to be an idiot, so I
must assume there is a darker reason for this design decision.
cheers,
Mathew
--
TuxTrax (n.) An invincible, all terrain, Linux driven armored assault
vehicle that can take as much fire as it gives ;-)
Yes, I am a Penguin cult high priest. Fin readings upon request.
Amateur Radio Operator KD6MSI
www.tuxtrax.com
Nigel Feltham
>> > > If you don't
>> > > already know the key, i.e., have it stored somewhere, there is no
>> > > more direct way to it than a text file whose location you don't know.
>> >
>> > No difference between the two in this manner either.
>>
>> Except text files can be very well documented. I like to add all sorts of
>> info to my configuration files. Makes them self-documenting.
>
> There is nothing stopping you from adding comments in the registry as
> well, just insert a few keys and put text comments in.
Adding extra comments in the registry for all programs makes it grow,
causing the PC to slow down and pushing the size closer to where the PC
won't boot.
>> Opening a few tiny 1 - a few K text files verses opening 3 gigantic
>> binary files. The Unix way is much more efficient.
>
> The files are open by the OS all the time, therefore no extra resources
> are consumed for individual programs opening them.
So instead of opening a 1k file to read the settings when I start an
application I have 3 files totalling over 10mb permanently in memory and
you still claim this doesn't make the PC run slower.
>> Most /etc configuration names are the same as the program they support.
>
> What happens if you have two programs with the same name?
What happens if 2 windows programs use the same registry key.
The worst that can happen on linux is that they will share the
configuration file and this won't cause any problems unless they both look
for the same config line in the file - they should ignore any lines they
don't recognise.
>> > > The registry grows over the life of
>> > > system and systems get slower as a result, because on Windows
>> > > systems, virtually all programs need to access the registry. Few if
>> > > any uninstall programs, cleanup everything that was installed. When
>> > > an application lacks an uninstall program or either the install or
>> > > uninstall program has a bug, there is a increased chance some or all
>> > > the registry entries will get left behind.
>> >
>> > This is a myth. When win9x systems start slowing down, it's not
>> > because of
>> > the registry. It's because of things like disk fragmentation, and
Bullshit - when you install a program the registry grows, when you
uninstall the redundant areas of the file aren't compressed so files
containing the registry ends up the same size as if you had never done the
uninstalls.
I have also proved by experience (on a win98 machine) that a large registry
file can cause bluescreens which wouldn't happen if the registry was
reduced to the size needed to contain all entries remaining - it was only
large due to being used on a machine used to test software builds so
contained data for every install & uninstall.
This was proved by exporting the whole registry to a file then shutting the
machine down to DOS mode and using regedit in commandline mode to build a
new registry from the text file - the resulting registry files were less
than half the size and the machine became a lot more stable (well as good
as you can get under win98 anyway - only crashing daily rather than the
several times per hour it crashed before the registry rebuild).
>> > > Other Registry Problems
>> > > -----------------------
>> > > Over time the Registry can get congested and confused with unused,
>> > > corrupt or unnecessary links or "keys". The result is a cluttered
>> > > Registry that will slow down your system and even cause it to crash.
>> >
>> > Again, it's a myth. I espcially like the "even cause it to crash". If
>> > it's
>> > unused, it's not going to cause it to crash, now is it? That's pure
>> > FUD. And i've yet to see a Linux system that didn't have unused config
>> > files in /etc, unless the admin was very good at cleaning things up.
No Myth - see above for details of how rebuilding a new registry containing
exactly the same data as the old one can stop the PC crashing.
> Really, so if you screwup rc, or inittab or any of a number of other
> critical
> files, your system will still boot just perfectly in all cases? Just like
Screwing up the files may stop it booting but with text files you can boot
from a recovery disk and correct the problem - with windows how do you
correct your error without a re-install as regedit won't edit the registry
if it won't boot.
> So backup your registry. Big deal.
So I can back up my config file to a floppy before editing, what do I do
with a 10mb registry.
> It's all a frame of mind.
It's all a major MS cock-up.
Nigel Feltham
>> the
>> two mechanisms. You have just admitted this, therefore any "serious
>> flaw" in the registry must exist in configuration files too, or it would
>> be a fundamental difference, would it not?
>>
>
>
> No. And the reason is just that "little fundamental difference". Bit
> of a "serious flaw" in your logik, erik. Are you tired, or just getting
> lazy?
>
Exactly - if something corrupts a binary file like the registry it can wipe
out every key stored after the corrupt bytes. Even a single wrong byte at
the wrong point can lose most of your settings. It would take severe damage
to corrupt every file in /etc.
grom
> Grom, the vast majority of this article boils down to "I like text files
> better", not any inherantly flawed design of the registry.
>
> "grom" <gro...@optusnet.com.au> wrote in message news:3c2f17c7$0$26026
>> The fallacy is that registry data is accessed
>> by key name. There is little fundamental difference between accessing a
>> dozen different keys in a deeply nested registry tree than there is a
>> dozen text files in different directories with different filenames.
>
> And here we have the rub. There is little fundamental difference between
> the two mechanisms. You have just admitted this, therefore any "serious
> flaw" in the registry must exist in configuration files too, or it would
> be a fundamental difference, would it not?
No, because the registry has furhter disadvantages (such as the entire
system relies on two files for the registry) without any benefits.
>
>> If you don't
>> already know the key, i.e., have it stored somewhere, there is no more
>> direct way to it than a text file whose location you don't know.
>
> No difference between the two in this manner either.
See above.
>> Theoretically many binary lookups should be more efficient than many file
>> opens. In practice few applications will need to open more than two
>> files: one containing common system data and one application specific
>> data.
>
> And one containing user specific data.
>
>> Numerous binary tree lookups, in a large deeply nested structure, become
>> quite resource intensive.
>
> This is complete bullshit, they are no more resource intensive than
> parsing large text files with many configuration items.
Actually, I'll agree with you on that.
>> This is confirmed by the fact that Windows
>> systems slow with age as software is added; UNIX systems do not slow with
>> age due to software installs. Further, if the directory structure is
>> logical, you can often find the text configuration file you need, without
>> knowing before hand what its named or where it's located. Without an
>> exact key fragment or data, this is not possible in the registry.
>
> Can you be any more contradictory, you just said a few paragraphs ago that
> it wasn't any easier to find text files you don't know. Further, the
> registry structure can be just as equally logically laid out.
You can do pattern matching, unlike the registry where you need to know the
key.
>> A major difference between the registry and text configuration files, is
>> that the registry is a proprietary binary format with only two widely
>> available.general purpose utilities, for it and a number of custom GUI
>> front ends, each of which accesses specific limited sections of the
>> registry.
>
> Doesn't sound any different between text files in /etc or ~ and the
> various GUI front-ends being developed fro Linux (YaST2, DrakConfig (or
> whatever it's called..), the various Gnome and KDE config tools, etc...
What? Because it's the config files are text, anybody can write there own
front end. You can even use your favourite editor.
>> There are more utilities and tools to manipulate text files than
>> any other storage format on earth.
>
> While true, this is actually a negative for text files. First, you need
> to learn lots of different utilities with differen syntax, then you need
> to write code for every app you use to parse and process those files,
> since text files often have very different formats.
No you don't. You can chose only one. The text files in UNIX have a very
similar format. Sorry erik, wrong again.
>> There isn't anything that can't be done,
>> either manually or automatically, with scripting in the way of locating,
>> comparing or changing text files using general purpose text editing and
>> manipulation utilities. Text files can have user friendly, graphical
>> front ends more easily than proprietary binary files. Text file formats
>> normally allow as much internal documentation as the developers care to
>> provide.
>
> Bullshit, there is no reason that text files can have GUI front ends
> easier than with registry front-ends. In fact, it's easier to do the
> registry front-end because registry access always uses the same API's no
> matter what the configuration, while text files have broad and varying
> formats that need to be understood by the front-end.
Besides the fact the registry is a proprietary binary format.
>
>> The .INI format used in pre Windows 95 versions, had named areas or
>> stanzas with an open ended number of key value pairs following. Add
>> intelligent file names to a logical directory structure and there isn't
>> any data that can't be stored and in a logical relationship to the
>> programs that use the data.
>
> There is no fundamental difference between the data associations used in
> the registry or .ini files. They each use a "section" (key) name and
> key/value pairs.
No. But there is a difference. The .INI doesn't have everything in a
central location.
>> Even binary data can be stored in a hex representation.
>
> Which must first be converted from binary to text, and text to binary when
> reading it.
>> If the
>> configuration data is program specific, it can go with the program. If
>> it's system wide, it can be stored in a standard system directory, in
>> which key filenames and stanzas within files would be reserved.
>
> The problem then becomes, where is it stored? The #1 problem with .ini
> files was that the program often got confused about where they were
> located, and if
> two programs used the same named file, they corrupted each other. While,
> the name problem is possible in the registry as well, it's unlikely
> because apps are supposed to store their config files in sub-sections of
> their company name or some other unique name related to their product and
> then under app name giving two unique keys which is unlikely to ever be
> the same (in fact, i've never heard of any app using this convention which
> ever had a problem).
What about system wide settings?
>> With files, programs read what they need and not much more, if the files
>> are well planned.
>
> Of course the planning of the files has no control over how the use has
> edited them.
What are you saying?
>
>> The SOFTWARE part of the registry on my workstation is over
>> 8MB and I know of a SAM over 19MB.
>
> Huh? How exactly would you know how large the software part of the
> registry is, and SAM databases are not in the registry.
>
>> The registry grows over the life of
>> system and systems get slower as a result, because on Windows systems,
>> virtually all programs need to access the registry. Few if any uninstall
>> programs, cleanup everything that was installed. When an application
>> lacks an uninstall program or either the install or uninstall program has
>> a bug, there is a increased chance some or all the registry entries will
>> get left behind.
>
> This is a myth. When win9x systems start slowing down, it's not because
> of the registry. It's because of things like disk fragmentation, and
> quite often large temp file or cache directories (with the internet
> explorer integrated shells, the cache directories are searched for almost
> any operation, which makes things appear to slow down significantly. Try
> clearing out your caches and temp directories regularly and notice the
> speed improvements).
ROTFLMAO. Yeah right!
>> Limited Registry Tools
>> -----------------------
>> Microsoft provides tools to maintain only parts of the registry.
>
> What is meant is that MS provides limited GUI front-ends. The same is
> true of Unix based config files.
You can uses any editor to edit Unix config files.
>> IIS 3 was a
>> good example where there were many more registry entries than there were
>> options in the Internet Manager.
>
> And how many options are available in GUI front-ends for apache?
It is difficult (if not impossible) to edit the registry directly and
change the config for an application. Whereas the text config files for
apache are commented and very easy to understand.
>> It also provides two limited editors as the
>> only general purpose access to the registry and says it's can't be
>> responsible if these tools are used, even though they are often the only
>> way to maintain parts of the registry.
>
> "limited" editors? They allow you to edit everything, how is that
> limited?
Search function is crap.
>> There are some additional tools in
>> the Resource kit but their value is limited. If a registry key contains
>> spaces, and many do, the limitations of the command line interface may
>> provide no way to pass the necessary arguments to the utility. Correctly
>> passing the arguments may require the equivalent of nested or escaped
>> quotes which the NT command prompt can't do.
>
> This is simply From the command line there are many options, including
> exporting a sub-key to text and editing it with any command line editor
> then reimporting it.
>
>> The registry has no equivalent of create, modify or access times so it's
>> not possible to locate recently changed registry entries or to relate
>> modification times to the onset of a problem.
>
> This is about the only legitimate claim i've read so far. Yes, this is
> true.
So its the only claim that you wish to agree with.
>> Keys in the registry have security permissions that are very similar to
>> directory permissions. Anyone who has seriously tightened file and
>> directory security, on almost any kind of server, knows that this almost
>> invariably breaks some user's access to some applications. With files,
>> it's generally pretty straightforward to figure out who needs update
>> access, who needs read access and who needs no access. With the registry,
>> since all access is programmatic, behind the scenes, and not documented,
>> it's almost impossible to know who needs access to what let alone what
>> level of access. I've never needed a guide to tell me how to tighten file
>> security, but any independent attempt to tighten registry security
>> without clear guidelines as to what should and should not be changed is
>> very likely to lead to serious trouble. Permission changes can be at the
>> current level or apply to sub keys. The registry is quite deep in some
>> areas and often huge in its entirety. Changing individual entries, except
>> to limit access to known specific keys for specific security related
>> results won't do much and changing sub keys will make changes several
>> levels down that you can only hope need to be the same as the parent
>> key's permissions.
>
> I'm just not even sure who this makes sense. I simply don't understand
> how someone can claim that you can know what permissions to apply to
> files, but not know what permissions to apply to registry keys. As
> already admitted, they are functionally the same thing.
Erik you are so blinded.
>> Registry Security and Installs
>> --------------------------------
>> The worst problem with the registry is that is a single structure, to
>> which administrators normally have full access.
>
> And administrators of unix systems don't have full access to /etc?
The point comes with the next sentence.
>> Most software installs need to be run as an administrator.
That is why it is a problem in windows.
> As do most unix installs, since you need write access to /etc to put your
> config files into it. Yes, it's usually possible to install something
> into your own home directory, but then the same is usually true of apps in
> Windows as well. As with unix, whole classes of apps need administrator
> access to function on either system.
A user can install to there own directory. You fool erik.
>
>> Thus any bug in a software install program can
>> result in corruption in almost any part of the registry. Unlike file and
>> directory related programs, where administrators generally have a pretty
>> good idea what will and will not be affected, there is no way to know
>> what registry keys any install program will access deliberately or
>> unintentionally change. I'm convinced that this is the primary source of
>> bizarre install related results.
>
> If you don't know what sections of the registry will be effected, what
> makes you think you'll know what will be effected the other way? Again,
> it's already been admitted that they're functionally the same.
See earlier statements.
>> By definition, one of the specific functions of an install program, is to
>> update the registry. Programmers develop install programs like any
>> others, make mistakes, and get poor specifications. There are important
>> differences though. The registry is probably the most system specific
>> component on any Windows system, as every system variation is reflected
>> in it, somewhere, thus making it one of the hardest parts to properly
>> test. All changes are normally made with the full authority of the
>> system.
>
> Not even remotely true. For instance, all user specific settings are
> stored in the users registry hive (and contrary to what is stated here,
> the registry is *NOT* one big database, it's actually stored in several
> sub-files, some of
> which are loaded specifically for each and every user). Of course a user
> has direct access to their own hive, and applications running run in the
> users security context.
It doesn't work all that well. Again there are many programs (many
microsoft ones included) that can only be installed as administrator.
>> Any misunderstanding the programmer has regarding the use of system calls
>> related to registry updates, could result in unpredictable consequences.
>
> And what about misunderstandings in the way to use text processing tools?
It is much easier to recover in a UNIX system. Fucking the registry, causes
a person to reinstall in almost all cases.
>> Whatever the programmer believes his program needs to or update will get
>> updated except when the programmer makes a mistake.
>
> Same is true of text files.
>
>> Because installs execute with administrator level access,
>
> As they almost always do in Unix/Linx.
Ummm. One can install to there home directory.
>> then whatever the install program is built
>> to do, whether it is intentional or accidental, will be done.
>
> Ditto.
Linux uses package managers which is much better then having an install exe
for each program.
>> When you
>> install software, you are normally asked what directory to put it in,
>> usually what program group to put it in and sometimes whether or not to
>> create a desktop icon. You're never asked about registry updates. When
>> you install software you implicitly trust the install programmer as well
>> as the company that employs him or her and hopefully tests the installs
>> well. When you install Windows software, someone else is making critical
>> system choices for you, without your knowledge or consent.
>
> This has absolutely nothing to do with the registry, it has to do with how
> installation code is written. I've seen plenty of script based installs
> on Windows for instance.
Yes, if they install program isn't any good, and can leave you with a
corrupt registry. Which leaves you with a corrupt system.
>> When software is installed on UNIX and configuration files specific to
>> that software are created or updated, as opposed to a centrally shared,
>> system-wide registry, the programmer pretty much has to have malicious
>> intent to damage anything but the software being installed. Also, most
>> UNIX installs are done with scripts that the administrator can read if
>> they wish, as opposed to binary executables, which for all practical
>> purposes, cannot be read.
>
> Again, nothing to do with the registry. This is simply a philisophical
> difference in the way install programs are written. You could do
> precisely the same for Unix/Linux, or you could create scripts on Windows.
See above.
>> Further, UNIX install programs that find missing shared
>> libraries or other perquisite parts, inform the administrator or the
>> missing components, but allow the administrator to locate and install the
>> prerequisites. Windows programs that require shared functions not
>> automatically provided with the OS, automatically provide them,
>> in whatever version the install vendor thinks is appropriate, creating
>> DLL hell. With the registry, any programming mistakes can cause serious
>> unintended damage. The surprise is not that some installs go bad, but
>> that the large majority actually work.
>
> This is no longer the case, since Windows provides side-by side DLL
> installs and windows file protection. And again, it has nothing to do
> with the registry.
No, but it is a futher problem (and it still applies, although it has
improved slighty)
>
>>
--------------------------------END-----------------------------------------
> --
>>
>> Other Registry Problems
>> -----------------------
>> Over time the Registry can get congested and confused with unused,
>> corrupt or unnecessary links or "keys". The result is a cluttered
>> Registry that will slow down your system and even cause it to crash.
>
> Again, it's a myth. I espcially like the "even cause it to crash". If
> it's
> unused, it's not going to cause it to crash, now is it? That's pure FUD.
> And i've yet to see a Linux system that didn't have unused config files in
> /etc, unless the admin was very good at cleaning things up.
No its not a myth.
>> Applications may introduce modifications into the registry without any
>> protection or verification whatsoever, which may cause other applications
>> or even the OS to crash. This seriously compromises the reliability of
>> the entire system.
>
> I love how in one hand you claim that registry security can cause problems
> because you can secure it in such a way as to prevent apps to not have
> access to what they need, then in the other hand claim there is no way to
> protect it from unauthorized access.
>
> You need a consistent argument.
>
>> It is usually easier to fix a corrupt registry by reinstalling.
>
> One could say the same thing about a complicated config file.
No you don't need to reinstall. Just replace that config file.
>> If the registry is improperly edited, it can cause severe problems, which
>> could lead to loss of data.
>
> Duh, that's why it's called "editing". The same is true of config files.
Yes, but editing seperate config files can not cause as much problems.
>> Registry Bugs
>> -------------
>> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q296733
>
> Wow, didn't know about this one. But it was in one service pack, and is
> fixed.
>
>>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ddtools/hh/dd
> tools/bccodes_0t5z.asp
>
> This is not a bug. This is a "bug check". I can understand your
> confusion, but it's basically a warning message when something is
> corrupted, not a bug itself.
>
>> http://msdn.microsoft.com/library/default.asp?url=/library/
>> en-us/ddtools/hh/ddtools/bccodes_0t5z.asp (short version of link above)
>
> This is the exact same link (not even a different link to the same thing).
> Again, it's not even a bug. You're padding your list
I did say it was the same link. I'm not trying to pad the list. Some people
can not click on links that go past 80 cols.
grom
> "Michael Vester" <mve...@v-wave.com> wrote in message
> news:a0o3nt$m887q$1...@ID-121900.news.dfncis.de...
>> Erik Funkenbusch wrote:
>>
>> > Grom, the vast majority of this article boils down to "I like text
>> > files better", not any inherantly flawed design of the registry.
>> >
>> > "grom" <gro...@optusnet.com.au> wrote in message news:3c2f17c7$0$26026
>> > > The fallacy is that registry data is accessed
>> > > by key name. There is little fundamental difference between accessing
>> > > a dozen different keys in a deeply nested registry tree than there is
>> > > a dozen text files in different directories with different filenames.
>> >
>> > And here we have the rub. There is little fundamental difference
>> > between the
>> > two mechanisms. You have just admitted this, therefore any "serious
>> > flaw" in the registry must exist in configuration files too, or it
>> > would be a fundamental difference, would it not?
>>
>> That does not make any sense.
>
> If there is "little fundamental difference", how can they be fundamentally
> differnt?
Because the registry stores everything in a couple of files.
>> > > If you don't
>> > > already know the key, i.e., have it stored somewhere, there is no
>> > > more direct way to it than a text file whose location you don't know.
>> >
>> > No difference between the two in this manner either.
>>
>> Except text files can be very well documented. I like to add all sorts of
>> info to my configuration files. Makes them self-documenting.
>
> There is nothing stopping you from adding comments in the registry as
> well, just insert a few keys and put text comments in.
And how many applications do this? You will bloat the registry even more.
>> > > Theoretically many binary lookups should be more efficient than many
>> > > file opens. In practice few applications will need to open more than
>> > > two files: one containing common system data and one application
>> > > specific data.
>> >
>> > And one containing user specific data.
>> >
>> > > Numerous binary tree lookups, in a large deeply nested structure,
>> > > become quite resource intensive.
>> >
>> > This is complete bullshit, they are no more resource intensive than
>> > parsing large text files with many configuration items.
>> >
>> Opening a few tiny 1 - a few K text files verses opening 3 gigantic
>> binary files. The Unix way is much more efficient.
>
> The files are open by the OS all the time, therefore no extra resources
> are consumed for individual programs opening them.
So if your not using all the registry, the entire bloated registry is still
in memory.
>> > > This is confirmed by the fact that Windows
>> > > systems slow with age as software is added; UNIX systems do not slow
>> > > with age due to software installs. Further, if the directory
>> > > structure is logical, you can often find the text configuration file
>> > > you need, without knowing before hand what its named or where it's
>> > > located. Without an exact key fragment or data, this is not possible
>> > > in the registry.
>> >
>> > Can you be any more contradictory, you just said a few paragraphs ago
>> > that it
>> > wasn't any easier to find text files you don't know. Further, the
>> > registry structure can be just as equally logically laid out.
>> >
>> Most /etc configuration names are the same as the program they support.
>
> What happens if you have two programs with the same name?
Erik, tell us why the registry is better then text config files. It appears
that you think they are equal (just a different implementation) however,
the registry has a few main problems. It is central (divided into three
files) and therefore a corrupt registry can make the system unstable or
unbootable. You say this is a myth. But it is not, I and six other people
that I know, that fix computers for a living know that the registry can
cause system problems.
>> > While true, this is actually a negative for text files. First, you
>> > need to learn lots of different utilities with differen syntax, then
>> > you need to write code for every app you use to parse and process those
>> > files, since text files often have very different formats.
>> >
>> There is only one format for a configuration file that I can see. A line
>> of text with a <LF>. Comments are #. Any text editor can edit them.
>
> There are lots of formats. Do comments start with #'s or ;'s? Hell,
> gs.fontmap uses %'s for comments.
If you wish, you can change this since it is OSS. You can't with commerical
programs.
> does the format have a name = option format, or is it just a line item?
> Is it field oriented (like, say, hosts) or are there commands issued per
> line? etc...
Config files are usually self-documented.
>> > > There isn't anything that can't be done,
>> > > either manually or automatically, with scripting in the way of
>> > > locating, comparing or changing text files using general purpose text
>> > > editing and manipulation utilities. Text files can have user
>> > > friendly, graphical front ends more easily than proprietary binary
>> > > files. Text file formats normally allow as much internal
>> > > documentation as the developers care to provide.
>> >
>> > Bullshit, there is no reason that text files can have GUI front ends
>> > easier
>> > than with registry front-ends. In fact, it's easier to do the registry
>> > front-end because registry access always uses the same API's no matter
>> > what the configuration, while text files have broad and varying formats
>> > that need to be understood by the front-end.
>>
>> With any amount of experience, one quickly discards the gui front end and
>> edits the text file directly.
>
> That's not the point, the criticism was talking about how poor the GUI
> front ends in windows are.
Typically of erik. You bring up a valid point and he says "That's not the
point"
>> > The problem then becomes, where is it stored? The #1 problem with .ini
>> > files was that the program often got confused about where they were
>> > located, and if
>> > two programs used the same named file, they corrupted each other.
>> > While, the name problem is possible in the registry as well, it's
>> > unlikely because apps are supposed to store their config files in
>> > sub-sections of their company name or some other unique name related to
>> > their product and then under app name giving two unique keys which is
>> > unlikely to ever be the same (in fact, i've never heard of any app
>> > using this convention which ever had a problem).
>>
>> All my configuration files are in /etc. Managing names can be done just
>> like you state with registry pairs.
>
> That depends on the distro. On my debian system the config files for grub
> are in /boot/grub.
Again, this can be changed.
>> > > With files, programs read what they need and not much more, if the
>> > > files are well planned.
>> >
>> > Of course the planning of the files has no control over how the use has
>> > edited them.
>>
>> Why would anyone change their name or location?
>
> The point was that if the text files are laid out correctly, you didn't
> have
> to read more than was necessary. There's nothing about name or location
> in this.
>
>> > > The SOFTWARE part of the registry on my workstation is over
>> > > 8MB and I know of a SAM over 19MB.
>> >
>> > Huh? How exactly would you know how large the software part of the
>> > registry is, and SAM databases are not in the registry.
>>
>> On my Windows machine, the registry occupies over 5 megabytes. On my main
>> Linux workstation, /etc occupies just over 3 megabytes. My Linux has many
>> more installed applications. And /etc has all the scripts for launching
>> programs. Of course, as you point out later, much of /etc is not even
>> used.
>
> What does that have to do with what I was saying?
The registry is bloated, and continues to get bloated because of its
design. Can't you see erik, that this is a design flaw.
>> > > The registry grows over the life of
>> > > system and systems get slower as a result, because on Windows
>> > > systems, virtually all programs need to access the registry. Few if
>> > > any uninstall programs, cleanup everything that was installed. When
>> > > an application lacks an uninstall program or either the install or
>> > > uninstall program has a bug, there is a increased chance some or all
>> > > the registry entries will get left behind.
>> >
>> > This is a myth. When win9x systems start slowing down, it's not
>> > because of
>> > the registry. It's because of things like disk fragmentation, and
>> > quite often large temp file or cache directories (with the internet
>> > explorer integrated shells, the cache directories are searched for
>> > almost any operation, which
>> > makes things appear to slow down significantly. Try clearing out your
>> > caches and temp directories regularly and notice the speed
>> > improvements).
>> >
>> The reigistry is always growing. A small application still has to open a
>> gigantic file just to access a few bytes of information.
>
> No, the file is already open. And typically this is a one-time event.
See earlier comment.
>> > > Limited Registry Tools
>> > > -----------------------
>> > > Microsoft provides tools to maintain only parts of the registry.
>> >
>> > What is meant is that MS provides limited GUI front-ends. The same is
>> > true of Unix based config files.
>> >
>> > > IIS 3 was a
>> > > good example where there were many more registry entries than there
>> > > were options in the Internet Manager.
>> >
>> > And how many options are available in GUI front-ends for apache?
>> >
>> Hardly a great demand for a gui front end for Apache. It would only get
>> iin the way.
>
> That doesn't change the fact that the argument is hypocritical.
No it isn't. The difference being that the registry is a binary format.
>> > > It also provides two limited editors as the
>> > > only general purpose access to the registry and says it's can't be
>> > > responsible if these tools are used, even though they are often the
>> > > only way to maintain parts of the registry.
>> >
>> > "limited" editors? They allow you to edit everything, how is that
>> > limited?
>> >
>> And one mistake, you render your Windows machine unbootable.
>
> Make one mistake in your /etc folder, and you can do the same.
True. But there are more possiblities with the registry. Editing file sin
/etc does not affect other files in /etc. Whereas in the registry it can.
>> > > There are some additional tools in
>> > > the Resource kit but their value is limited. If a registry key
>> > > contains spaces, and many do, the limitations of the command line
>> > > interface may provide no way to pass the necessary arguments to the
>> > > utility. Correctly passing the arguments may require the equivalent
>> > > of nested or escaped quotes which the NT command prompt can't do.
>> >
>> > This is simply From the command line there are many options, including
>> > exporting a sub-key to text and editing it with any command line editor
>> > then reimporting it.
>>
>> I thought the great reason to use the registry was to use a pretty gui.
>> You still have to edit it with a text editor?
>
> No. The reason to use the registry is to have a central place for
> configuration. The context here is command line editing.
Which is a design flaw. Unrelated settings can affect each other.
>> > > The registry has no equivalent of create, modify or access times so
>> > > it's not possible to locate recently changed registry entries or to
>> > > relate modification times to the onset of a problem.
>> >
>> > This is about the only legitimate claim i've read so far. Yes, this is
>> > true.
>> >
>> Amazing!!! Erik agreed. I thought the registry was perfect.
>
> I didn't say that, I said it wasn't "fundamentally flawed".
Erik, I'm don't think everything in windows is wrong. But the registry is a
design mistake. It is from the windows 3.1 days. Although you say there is
"little fundamental difference" the differences between having config files
in /etc and the registry are major differences. The only benefit I can see
from the registry, is that you can make it more difficult (although not
impossible) to pirate software.
Erik you have just point out a problem with the registry. Critical and
non-critical belong together in the registry. Whereas, in /etc each is
seperate.
>> > > It is usually easier to fix a corrupt registry by reinstalling.
>> >
>> > One could say the same thing about a complicated config file.
>> >
>> I make a backup of a configuration file before I edit it. Any problems
>> and I can easily return to a functioning config.
>
> So backup your registry. Big deal.
The problem is though, the registry can become corrupt without you editing
it.
>> > > If the registry is improperly edited, it can cause severe problems,
>> > > which could lead to loss of data.
>> >
>> > Duh, that's why it's called "editing". The same is true of config
>> > files.
>> >
>> Yet one mistake in "editing" the register will render your computer
>> unbootable. From personal experience of course. I have yet to render a
>> Linux box unbootable from mistakes in editing configuration files. I am
>> sure that if I mucked up fstab, I would not have access to my partitions
>> on the next very infrequent reboot.
>
> So you admit you were wrong them when you claimed editing files in etc
> wouldn't make your system unbootable.
However, this can be fixed by using a rescue disk. With windows how do you
edit the registry if you can not boot windows. (and with NT - that includes
w2k and XP - you can't use dos if you have NTFS partitions).
>> > > Registry Bugs
>> <snip>
>> >
>> I always thought that the registry was a bad idea. I like having all the
>> configuration files in /etc. Simple and very easy to maintain, even for a
>> slightly more advanced newbie like me.
>>
>> With my Windows machine, if any problems crop up in the registry, I
>> simply zero out the drive and reload from a CDRed ghosted image. Much
>> simpler than
>> having to deal with the registry. I guess I am too stupid to master
>> registry editing. The Linux/Unix way is much easier.
>
> It's all a frame of mind.
Erik, I don't think there is any point in trying to make you see. You think
windows has no design flaws. I don't really care that you feel this way,
but what I care about is you making other people believe this crap. Over
time, the registry can slow the machine down. Period. It is not a myth. You
realise the registry needs to be defragged and cleanup.
What do you do for a living? What qualifications do you have?
grom
> "Michael Vester" <mve...@v-wave.com> wrote in message
> news:a0o3nt$m887q$1...@ID-121900.news.dfncis.de...
>> Erik Funkenbusch wrote:
>>
>> > Grom, the vast majority of this article boils down to "I like text
>> > files better", not any inherantly flawed design of the registry.
>> >
>> > "grom" <gro...@optusnet.com.au> wrote in message news:3c2f17c7$0$26026
>> > > The fallacy is that registry data is accessed
>> > > by key name. There is little fundamental difference between accessing
>> > > a dozen different keys in a deeply nested registry tree than there is
>> > > a dozen text files in different directories with different filenames.
>> >
>> > And here we have the rub. There is little fundamental difference
>> > between the
>> > two mechanisms. You have just admitted this, therefore any "serious
>> > flaw" in the registry must exist in configuration files too, or it
>> > would be a fundamental difference, would it not?
>>
>> That does not make any sense.
>
> If there is "little fundamental difference", how can they be fundamentally
> differnt?
Because the registry stores everything in a couple of files.
>> > > If you don't
>> > > already know the key, i.e., have it stored somewhere, there is no
>> > > more direct way to it than a text file whose location you don't know.
>> >
>> > No difference between the two in this manner either.
>>
>> Except text files can be very well documented. I like to add all sorts of
>> info to my configuration files. Makes them self-documenting.
>
> There is nothing stopping you from adding comments in the registry as
> well, just insert a few keys and put text comments in.
And how many applications do this? You will bloat the registry even more.
>> > > Theoretically many binary lookups should be more efficient than many
>> > > file opens. In practice few applications will need to open more than
>> > > two files: one containing common system data and one application
>> > > specific data.
>> >
>> > And one containing user specific data.
>> >
>> > > Numerous binary tree lookups, in a large deeply nested structure,
>> > > become quite resource intensive.
>> >
>> > This is complete bullshit, they are no more resource intensive than
>> > parsing large text files with many configuration items.
>> >
>> Opening a few tiny 1 - a few K text files verses opening 3 gigantic
>> binary files. The Unix way is much more efficient.
>
> The files are open by the OS all the time, therefore no extra resources
> are consumed for individual programs opening them.
So if your not using all the registry, the entire bloated registry is still
in memory.
>> > > This is confirmed by the fact that Windows
>> > > systems slow with age as software is added; UNIX systems do not slow
>> > > with age due to software installs. Further, if the directory
>> > > structure is logical, you can often find the text configuration file
>> > > you need, without knowing before hand what its named or where it's
>> > > located. Without an exact key fragment or data, this is not possible
>> > > in the registry.
>> >
>> > Can you be any more contradictory, you just said a few paragraphs ago
>> > that it
>> > wasn't any easier to find text files you don't know. Further, the
>> > registry structure can be just as equally logically laid out.
>> >
>> Most /etc configuration names are the same as the program they support.
>
> What happens if you have two programs with the same name?
Erik, tell us why the registry is better then text config files. It appears
that you think they are equal (just a different implementation) however,
the registry has a few main problems. It is central (divided into three
files) and therefore a corrupt registry can make the system unstable or
unbootable. You say this is a myth. But it is not, I and six other people
that I know, that fix computers for a living know that the registry can
cause system problems.
>> > While true, this is actually a negative for text files. First, you
>> > need to learn lots of different utilities with differen syntax, then
>> > you need to write code for every app you use to parse and process those
>> > files, since text files often have very different formats.
>> >
>> There is only one format for a configuration file that I can see. A line
>> of text with a <LF>. Comments are #. Any text editor can edit them.
>
> There are lots of formats. Do comments start with #'s or ;'s? Hell,
> gs.fontmap uses %'s for comments.
If you wish, you can change this since it is OSS. You can't with commerical
programs.
> does the format have a name = option format, or is it just a line item?
> Is it field oriented (like, say, hosts) or are there commands issued per
> line? etc...
Config files are usually self-documented.
>> > > There isn't anything that can't be done,
>> > > either manually or automatically, with scripting in the way of
>> > > locating, comparing or changing text files using general purpose text
>> > > editing and manipulation utilities. Text files can have user
>> > > friendly, graphical front ends more easily than proprietary binary
>> > > files. Text file formats normally allow as much internal
>> > > documentation as the developers care to provide.
>> >
>> > Bullshit, there is no reason that text files can have GUI front ends
>> > easier
>> > than with registry front-ends. In fact, it's easier to do the registry
>> > front-end because registry access always uses the same API's no matter
>> > what the configuration, while text files have broad and varying formats
>> > that need to be understood by the front-end.
>>
>> With any amount of experience, one quickly discards the gui front end and
>> edits the text file directly.
>
> That's not the point, the criticism was talking about how poor the GUI
> front ends in windows are.
Typically of erik. You bring up a valid point and he says "That's not the
point"
>> > The problem then becomes, where is it stored? The #1 problem with .ini
>> > files was that the program often got confused about where they were
>> > located, and if
>> > two programs used the same named file, they corrupted each other.
>> > While, the name problem is possible in the registry as well, it's
>> > unlikely because apps are supposed to store their config files in
>> > sub-sections of their company name or some other unique name related to
>> > their product and then under app name giving two unique keys which is
>> > unlikely to ever be the same (in fact, i've never heard of any app
>> > using this convention which ever had a problem).
>>
>> All my configuration files are in /etc. Managing names can be done just
>> like you state with registry pairs.
>
> That depends on the distro. On my debian system the config files for grub
> are in /boot/grub.
Again, this can be changed.
>> > > With files, programs read what they need and not much more, if the
>> > > files are well planned.
>> >
>> > Of course the planning of the files has no control over how the use has
>> > edited them.
>>
>> Why would anyone change their name or location?
>
> The point was that if the text files are laid out correctly, you didn't
> have
> to read more than was necessary. There's nothing about name or location
> in this.
>
>> > > The SOFTWARE part of the registry on my workstation is over
>> > > 8MB and I know of a SAM over 19MB.
>> >
>> > Huh? How exactly would you know how large the software part of the
>> > registry is, and SAM databases are not in the registry.
>>
>> On my Windows machine, the registry occupies over 5 megabytes. On my main
>> Linux workstation, /etc occupies just over 3 megabytes. My Linux has many
>> more installed applications. And /etc has all the scripts for launching
>> programs. Of course, as you point out later, much of /etc is not even
>> used.
>
> What does that have to do with what I was saying?
The registry is bloated, and continues to get bloated because of its
design. Can't you see erik, that this is a design flaw.
>> > > The registry grows over the life of
>> > > system and systems get slower as a result, because on Windows
>> > > systems, virtually all programs need to access the registry. Few if
>> > > any uninstall programs, cleanup everything that was installed. When
>> > > an application lacks an uninstall program or either the install or
>> > > uninstall program has a bug, there is a increased chance some or all
>> > > the registry entries will get left behind.
>> >
>> > This is a myth. When win9x systems start slowing down, it's not
>> > because of
>> > the registry. It's because of things like disk fragmentation, and
>> > quite often large temp file or cache directories (with the internet
>> > explorer integrated shells, the cache directories are searched for
>> > almost any operation, which
>> > makes things appear to slow down significantly. Try clearing out your
>> > caches and temp directories regularly and notice the speed
>> > improvements).
>> >
>> The reigistry is always growing. A small application still has to open a
>> gigantic file just to access a few bytes of information.
>
> No, the file is already open. And typically this is a one-time event.
See earlier comment.
>> > > Limited Registry Tools
>> > > -----------------------
>> > > Microsoft provides tools to maintain only parts of the registry.
>> >
>> > What is meant is that MS provides limited GUI front-ends. The same is
>> > true of Unix based config files.
>> >
>> > > IIS 3 was a
>> > > good example where there were many more registry entries than there
>> > > were options in the Internet Manager.
>> >
>> > And how many options are available in GUI front-ends for apache?
>> >
>> Hardly a great demand for a gui front end for Apache. It would only get
>> iin the way.
>
> That doesn't change the fact that the argument is hypocritical.
No it isn't. The difference being that the registry is a binary format.
>> > > It also provides two limited editors as the
>> > > only general purpose access to the registry and says it's can't be
>> > > responsible if these tools are used, even though they are often the
>> > > only way to maintain parts of the registry.
>> >
>> > "limited" editors? They allow you to edit everything, how is that
>> > limited?
>> >
>> And one mistake, you render your Windows machine unbootable.
>
> Make one mistake in your /etc folder, and you can do the same.
True. But there are more possiblities with the registry. Editing file sin
/etc does not affect other files in /etc. Whereas in the registry it can.
>> > > There are some additional tools in
>> > > the Resource kit but their value is limited. If a registry key
>> > > contains spaces, and many do, the limitations of the command line
>> > > interface may provide no way to pass the necessary arguments to the
>> > > utility. Correctly passing the arguments may require the equivalent
>> > > of nested or escaped quotes which the NT command prompt can't do.
>> >
>> > This is simply From the command line there are many options, including
>> > exporting a sub-key to text and editing it with any command line editor
>> > then reimporting it.
>>
>> I thought the great reason to use the registry was to use a pretty gui.
>> You still have to edit it with a text editor?
>
> No. The reason to use the registry is to have a central place for
> configuration. The context here is command line editing.
Which is a design flaw. Unrelated settings can affect each other.
>> > > The registry has no equivalent of create, modify or access times so
>> > > it's not possible to locate recently changed registry entries or to
>> > > relate modification times to the onset of a problem.
>> >
>> > This is about the only legitimate claim i've read so far. Yes, this is
>> > true.
>> >
>> Amazing!!! Erik agreed. I thought the registry was perfect.
>
> I didn't say that, I said it wasn't "fundamentally flawed".
Erik, I'm don't think everything in windows is wrong. But the registry is a
design mistake. It is from the windows 3.1 days. Although you say there is
"little fundamental difference" the differences between having config files
in /etc and the registry are major differences. The only benefit I can see
from the registry, is that you can make it more difficult (although not
impossible) to pirate software.
>> > This is no longer the case, since Windows provides side-by side DLL
Erik you have just point out a problem with the registry. Critical and
non-critical belong together in the registry. Whereas, in /etc each is
seperate.
>> > > It is usually easier to fix a corrupt registry by reinstalling.
>> >
>> > One could say the same thing about a complicated config file.
>> >
>> I make a backup of a configuration file before I edit it. Any problems
>> and I can easily return to a functioning config.
>
> So backup your registry. Big deal.
The problem is though, the registry can become corrupt without you editing
it.
>> > > If the registry is improperly edited, it can cause severe problems,
>> > > which could lead to loss of data.
>> >
>> > Duh, that's why it's called "editing". The same is true of config
>> > files.
>> >
>> Yet one mistake in "editing" the register will render your computer
>> unbootable. From personal experience of course. I have yet to render a
>> Linux box unbootable from mistakes in editing configuration files. I am
>> sure that if I mucked up fstab, I would not have access to my partitions
>> on the next very infrequent reboot.
>
> So you admit you were wrong them when you claimed editing files in etc
> wouldn't make your system unbootable.
However, this can be fixed by using a rescue disk. With windows how do you
edit the registry if you can not boot windows. (and with NT - that includes
w2k and XP - you can't use dos if you have NTFS partitions).
>> > > Registry Bugs
>> <snip>
>> >
>> I always thought that the registry was a bad idea. I like having all the
>> configuration files in /etc. Simple and very easy to maintain, even for a
>> slightly more advanced newbie like me.
>>
>> With my Windows machine, if any problems crop up in the registry, I
>> simply zero out the drive and reload from a CDRed ghosted image. Much
>> simpler than
>> having to deal with the registry. I guess I am too stupid to master
>> registry editing. The Linux/Unix way is much easier.
>
> It's all a frame of mind.
Erik, I don't think there is any point in trying to make you see. You think
Tim Smith
>Exactly - if something corrupts a binary file like the registry it can wipe
>out every key stored after the corrupt bytes. Even a single wrong byte at
>the wrong point can lose most of your settings. It would take severe damage
>to corrupt every file in /etc.
So that's why databases store everything in a zillion files, rather
than in one or two big files? Oh, wait...they don't. Ooops.
--Tim Smith
Ian Pegel
<SNIP>
> This is a myth. When win9x systems start slowing down, it's not because
> of the registry. It's because of things like disk fragmentation, and
> quite often large temp file or cache directories (with the internet
> explorer integrated shells, the cache directories are searched for
> almost any operation, which makes things appear to slow down
...........................................^^^^^
> significantly. Try clearing out your caches and temp directories
> regularly and notice the speed improvements).
>
Pedant point:
"Mrs Wilkins, your W9x computer has not slowed down, it
just appears to be running slower. Mere illusion, you stupid
woman! Anyway, if you weren't so much of a slut and would keep your caches
cleaner, everything would be just hunkydory. It's *all* your fault!"
--
Ian
"He knows his onions"
Pete Goodwin
news:PmKX7.4731$aH2.2...@ruti.visi.com:
> Grom, the vast majority of this article boils down to "I like text
> files better", not any inherantly flawed design of the registry.
There is one big flaw with the system part of the registry. If it dies, the
whole system is dead. If a Linux system configuration text file dies, its
possible that less is affected.
[snip]
>> The registry grows over the life of
>> system and systems get slower as a result, because on Windows systems,
>> virtually all programs need to access the registry. Few if any
>> uninstall programs, cleanup everything that was installed. When an
>> application lacks an uninstall program or either the install or
>> uninstall program has a bug, there is a increased chance some or all
>> the registry entries will get left behind.
>
> This is a myth. When win9x systems start slowing down, it's not
> because of the registry. It's because of things like disk
> fragmentation, and quite often large temp file or cache directories
> (with the internet explorer integrated shells, the cache directories
> are searched for almost any operation, which makes things appear to
> slow down significantly. Try clearing out your caches and temp
> directories regularly and notice the speed improvements).
A myth? If the registry grows over time, and it most certainly does, surely
that will slow down access gradually?
I've tried clearing out caches, temp directories etc. and defragmentation
and guess what - it's still pretty slow. The only way I've found to
increase speed is to wipe the system and start again.
[snip]
>> Most software installs need to be run as an administrator.
>
> As do most unix installs, since you need write access to /etc to put
> your config files into it. Yes, it's usually possible to install
> something into your own home directory, but then the same is usually
> true of apps in Windows as well. As with unix, whole classes of apps
> need administrator access to function on either system.
On Windows the predominant system is Windows 9x based. There's no need to
consider security there, so most applications don't. There are certain
Microsoft games that refuse to run unless they're run from an Administrator
account. That's just a fault of the application, one which is too common,
and hopefully will change.
>> Thus any bug in a software install program can
>> result in corruption in almost any part of the registry. Unlike file
>> and directory related programs, where administrators generally have a
>> pretty good idea what will and will not be affected, there is no way
>> to know what registry keys any install program will access
>> deliberately or unintentionally change. I'm convinced that this is the
>> primary source of bizarre install related results.
>
> If you don't know what sections of the registry will be effected, what
> makes you think you'll know what will be effected the other way?
> Again, it's already been admitted that they're functionally the same.
On any OS I would like to installation of software in _one_ directory. That
way it lives in that directory and all I need do is transfer that directory
if necessary. Windows can lead to configuration scattered throughout the
registry - how can that be easily transferred to another system? Linux may
have similar problems (/etc?).
[snip]
>> Because installs execute with administrator level access,
>
> As they almost always do in Unix/Linx.
Actually, not true. I installed Kylix 2.0 into my home directory. I did not
need to be root to install or to run it.
>> Other Registry Problems
>> -----------------------
>> Over time the Registry can get congested and confused with unused,
>> corrupt or unnecessary links or "keys". The result is a cluttered
>> Registry that will slow down your system and even cause it to crash.
>
> Again, it's a myth. I espcially like the "even cause it to crash". If
> it's unused, it's not going to cause it to crash, now is it? That's
> pure FUD. And i've yet to see a Linux system that didn't have unused
> config files in /etc, unless the admin was very good at cleaning things
> up.
What is the myth? That the registry isn't cluttered up with crap? Sorry,
but that ain't no myth!
>> Applications may introduce modifications into the registry without any
>> protection or verification whatsoever, which may cause other
>> applications or even the OS to crash. This seriously compromises the
>> reliability of the entire system.
>
> I love how in one hand you claim that registry security can cause
> problems because you can secure it in such a way as to prevent apps to
> not have access to what they need, then in the other hand claim there
> is no way to protect it from unauthorized access.
And what is the default on Windows 2000 and XP? Is it secure? No it isn't!
The default is to be Administrator!
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-
>>us/ddtools/hh/dd
>>tools/bccodes_0t5z.asp
>
>This is not a bug. This is a "bug check". I can understand your
>confusion,
>but it's basically a warning message when something is corrupted, not a
>bug
>itself.
What happens when the system hits a bugcheck? It depends... by default it
reboots! Woops! That's a crash!
--
Pete Goodwin
----
Running on Windows ME.
Craig Kelley
[snippage]
> The .INI format used in pre Windows 95 versions, had named areas or stanzas
> with an open ended number of key value pairs following. Add intelligent file
> names to a logical directory structure and there isn't any data that can't
> be stored and in a logical relationship to the programs that use the data.
> Even binary data can be stored in a hex representation. If the
> configuration data is program specific, it can go with the program. If it's
> system wide, it can be stored in a standard system directory, in which key
> filenames and stanzas within files would be reserved.
You forgot the biggest flaws in the registry: There are no comments
and there is no order to keys. In a real configuration file, people
group similar items together and explain what is going on with
comments. In the registry there is no such luck, everything is hashed
by Windows into a random order and there is no explanation for
anything.
[snip most excellent post]
In a nutshell: The registry is slower, more cumbersome, more
error-prone and more confusing than text files.
--
It is financially more expensive to go to prison than to attend Harvard.
Craig Kelley -- kell...@isu.edu
http://www.isu.edu/~kellcrai finger i...@inconnu.isu.edu for PGP block
Craig Kelley
> "Michael Vester" <mve...@v-wave.com> wrote in message
>
> > Except text files can be very well documented. I like to add all sorts of
> > info to my configuration files. Makes them self-documenting.
>
> There is nothing stopping you from adding comments in the registry as well,
> just insert a few keys and put text comments in.
Laughable.
1) Please name one (1) software product that ships with comments in the
registry.
2) Since all keys are hashed, and representation is left up to the
client, how can you keep your "comments" in order?
3) How do you group similar configuration items next to eachother
without making use of a zillion keys (which enter their own form
of confusion into the equation)?
[snip -- I'm going to snip a bunch of this long thread, so this
warning will apply to the entire text below; use your news client's
history if you're curious]
> > Most /etc configuration names are the same as the program they support.
>
> What happens if you have two programs with the same name?
Hmm, like HKEY_SYSTEM\Software\Blah\Blah\Blah? They would both suffer
from that "problem" (ahem, "strawman") if it actually existed.
> > There is only one format for a configuration file that I can see. A line
> > of text with a <LF>. Comments are #. Any text editor can edit them.
>
> There are lots of formats. Do comments start with #'s or ;'s? Hell,
> gs.fontmap uses %'s for comments.
That's better than NO COMMENTS at all, I do believe.
> does the format have a name = option format, or is it just a line item? Is it
> field oriented (like, say, hosts) or are there commands issued per line?
> etc...
Erik, Erik, Erik... Being able to understand any configuration file
requires that you know what is being done underneath. The Windows
registry lets you know that something is a DWORD, but what good does
that do you unless you know the format of the value? What if you need
to add a value to a key -- should it be a REG_MULTISZ or a REG_BINARY?
Being able to make sense of a grammar requires knowledge; files can
include an option and have it commented out by default -- no such luck
with the registry.
The deliniation of text files isn't completely uniform, but it is
mostly standardized with libraries today. The lame ducks in this
department are older software products -- the same ones that would
probably be using their own configuration files under Windows...
> > All my configuration files are in /etc. Managing names can be done just
> > like you state with registry pairs.
>
> That depends on the distro. On my debian system the config files for grub are
> in /boot/grub.
Hmm, the same function under Windows NT is in C:\BOOT.INI, which isn't
even in the registry.
Wonderful example, great attempt to show how uniform the registry is.
> > Why would anyone change their name or location?
>
> The point was that if the text files are laid out correctly, you
> didn't have to read more than was necessary. There's nothing about
> name or location in this.
Hmm, kind of like the (many times, MULTIPLE) locations that things are
found in the registry? Don't throw rocks, etc.
> The reason to use the registry is to have a central place for
> configuration.
What advantage does that offer for *humans*? You know, the ones that
actually have to use and maintain the computer?
> > I make a backup of a configuration file before I edit it. Any problems and
> > I can easily return to a functioning config.
>
> So backup your registry. Big deal.
It's much easier to move an emacse save~ file back when something goes
wrong than it is to remember to backup the registry before touching
it. Again, it comes down to which system was designed for humans and
which system was designed around buzz-word compliance and not much
else.
> It's all a frame of mind.
Yes, the registry makes you think like the computer. Text files let
you use human language and human language editors to express
yourself. One is proprietary, one is open.
Erik Funkenbusch
Where did I say it was the users fault? I simply said it wasn't the
registry causing the problem.
Erik Funkenbusch
> In article <3c2f3...@nntp2.nac.net>, "Net Resident"
> <nomail...@nothanks.org> wrote:
>
> > In article <3c2f17c7$0$26026$afc3...@news.optusnet.com.au>, "grom"
> > <gro...@optusnet.com.au> wrote:
> >
> >> What Is The Registry?
> >
> > <snip>
> >
> > Personally I always assumed that the registry was just a way to
> > obfuscate the system further which seems to me to be near and dear to
> > MS's heart (or lack thereof...).
> >
> > *shrug*
>
> You have to ask yourself what kind of moron designs any system around one
> part, the failure of which, brings down the whole system.
Yeah, you have to wonder. Like maybe a kernel? How about a disk
drive? What about an init process? There are literally dozens of
things on any given system which are critical components that will
bring the whole system down if that one thing fails.
> What kind of an idiot would design an operating system so that its very
> life depends on *one* *file* . I don't take bill to be an idiot, so I
> must assume there is a darker reason for this design decision.
Good question. Good thing the regisry isn't one file.
Russ Lyttle
Don't think the count goes up to a zillion, but several hundred files
aren't uncommon. In fact, most of my data base files never all reside on
the same machine and shadow copies are kept hot synched somewhere.
Peter Köhlmann
> "TuxTrax" <ARC...@zerojunktuxtrax.com> wrote in message
> news:<20011230.162058...@fortress.tuxnet>...
>> In article <3c2f3...@nntp2.nac.net>, "Net Resident"
>> <nomail...@nothanks.org> wrote:
>>
>> > In article <3c2f17c7$0$26026$afc3...@news.optusnet.com.au>, "grom"
>> > <gro...@optusnet.com.au> wrote:
>> >
>> >> What Is The Registry?
>> >
>> > <snip>
>> >
>> > Personally I always assumed that the registry was just a way to
>> > obfuscate the system further which seems to me to be near and dear to
>> > MS's heart (or lack thereof...).
>> >
>> > *shrug*
>>
>> You have to ask yourself what kind of moron designs any system around one
>> part, the failure of which, brings down the whole system.
>
> Yeah, you have to wonder. Like maybe a kernel? How about a disk
> drive? What about an init process? There are literally dozens of
> things on any given system which are critical components that will
> bring the whole system down if that one thing fails.
>
So MS decided it did not matter if they added one to that count, right?
>> What kind of an idiot would design an operating system so that its very
>> life depends on *one* *file* . I don't take bill to be an idiot, so I
>> must assume there is a darker reason for this design decision.
>
> Good question. Good thing the regisry isn't one file.
Fine. So it is two files. Big deal. And still hasn't changed anything.
It is still crap
Peter
--
A NT based server can be run by an idiot and usually is.
Russ Lyttle
in some cases, if not zillions. In fact most of the databases are
distributed over multiple machines with hot synched shadow copies, just
in case.
Erik Funkenbusch
> Erik Funkenbusch wrote:
>
> > "Michael Vester" <mve...@v-wave.com> wrote in message
> > news:a0o3nt$m887q$1...@ID-121900.news.dfncis.de...
> >> Erik Funkenbusch wrote:
> >>
> >> > Grom, the vast majority of this article boils down to "I like text
> >> > files better", not any inherantly flawed design of the registry.
> >> >
> >> > "grom" <gro...@optusnet.com.au> wrote in message news:3c2f17c7$0$26026
> >> > > The fallacy is that registry data is accessed
> >> > > by key name. There is little fundamental difference between accessing
> >> > > a dozen different keys in a deeply nested registry tree than there is
> >> > > a dozen text files in different directories with different filenames.
> >> >
> >> > And here we have the rub. There is little fundamental difference
> >> > between the
> >> > two mechanisms. You have just admitted this, therefore any "serious
> >> > flaw" in the registry must exist in configuration files too, or it
> >> > would be a fundamental difference, would it not?
> >>
> >> That does not make any sense.
> >
> > If there is "little fundamental difference", how can they be fundamentally
> > differnt?
>
> Because the registry stores everything in a couple of files.
You do realize that your hard disk is the equivelant of a single
database file, right? Perspective counts for a lot. If your hard
disk becomes corrupted, you can lose your entire disk just as easily.
You have not provided any valid reason as to why "a couple of files"
is any worse than 1000 files. However, 1000 files have the obvious
disadvantages of conflicting file formats, decreased efficiency (the
files have to be read, then parsed, then converted to binary formats
where applicable. The regitry has all that information in a useable
form).
> >> > > If you don't
> >> > > already know the key, i.e., have it stored somewhere, there is no
> >> > > more direct way to it than a text file whose location you don't know.
> >> >
> >> > No difference between the two in this manner either.
> >>
> >> Except text files can be very well documented. I like to add all sorts of
> >> info to my configuration files. Makes them self-documenting.
> >
> > There is nothing stopping you from adding comments in the registry as
> > well, just insert a few keys and put text comments in.
>
> And how many applications do this? You will bloat the registry even more.
A "bloated registry" has not proven to be a problem with one
exception, the system hive.
> > The files are open by the OS all the time, therefore no extra resources
> > are consumed for individual programs opening them.
>
> So if your not using all the registry, the entire bloated registry is still
> in memory.
Maybe, maybe not. The registry is opened as a memory mapped file.
This allows the OS to discard any part that hasn't been recently used
and reload it on demand via the paged back storage mechanism. This is
quite efficient.
> >> > Can you be any more contradictory, you just said a few paragraphs ago
> >> > that it
> >> > wasn't any easier to find text files you don't know. Further, the
> >> > registry structure can be just as equally logically laid out.
> >> >
> >> Most /etc configuration names are the same as the program they support.
> >
> > What happens if you have two programs with the same name?
>
> Erik, tell us why the registry is better then text config files. It appears
> that you think they are equal (just a different implementation) however,
> the registry has a few main problems. It is central (divided into three
> files) and therefore a corrupt registry can make the system unstable or
> unbootable. You say this is a myth. But it is not, I and six other people
> that I know, that fix computers for a living know that the registry can
> cause system problems.
The number of files is an implementation detail, not a design one. It
could be implemented as each major key being a unique file, or it
could be all one file. We're talking about *DESIGN* flaws, not
implementation (not that I'm saying it *IS* a flaw at all, but even if
you could come up with a valid reason for being a flaw, this it
wouldn't have anything to do with the registry's design).
Next, you are thinking of this as a binary file in the way that
dumping objects from memory to disk is a binary file. That's not
true. It's implemented as a linked list structure and is very
resistant to corrupting the entire registry if one portion is
corrupted. A simple repair (much like an fsck) will almost always fix
it, though like fsck, it's not foolproof.
Having said that, the only time i've ever seen a registry corruption
is when there is a disk error, in which case you could lose
*anything*.
> >> > While true, this is actually a negative for text files. First, you
> >> > need to learn lots of different utilities with differen syntax, then
> >> > you need to write code for every app you use to parse and process those
> >> > files, since text files often have very different formats.
> >> >
> >> There is only one format for a configuration file that I can see. A line
> >> of text with a <LF>. Comments are #. Any text editor can edit them.
> >
> > There are lots of formats. Do comments start with #'s or ;'s? Hell,
> > gs.fontmap uses %'s for comments.
>
> If you wish, you can change this since it is OSS. You can't with commerical
> programs.
Oh, right... conveniently forgetting that OSS software is available
for Windows.
> > does the format have a name = option format, or is it just a line item?
> > Is it field oriented (like, say, hosts) or are there commands issued per
> > line? etc...
>
> Config files are usually self-documented.
I find more often than not that they aren't. A quick perusal of /etc
finds dozens of files without any kind of comments at all.
> >> > > There isn't anything that can't be done,
> >> > > either manually or automatically, with scripting in the way of
> >> > > locating, comparing or changing text files using general purpose text
> >> > > editing and manipulation utilities. Text files can have user
> >> > > friendly, graphical front ends more easily than proprietary binary
> >> > > files. Text file formats normally allow as much internal
> >> > > documentation as the developers care to provide.
> >> >
> >> > Bullshit, there is no reason that text files can have GUI front ends
> >> > easier
> >> > than with registry front-ends. In fact, it's easier to do the registry
> >> > front-end because registry access always uses the same API's no matter
> >> > what the configuration, while text files have broad and varying formats
> >> > that need to be understood by the front-end.
> >>
> >> With any amount of experience, one quickly discards the gui front end and
> >> edits the text file directly.
> >
> > That's not the point, the criticism was talking about how poor the GUI
> > front ends in windows are.
>
> Typically of erik. You bring up a valid point and he says "That's not the
> point"
It may be a valid point for another argument. For this argument, it's
irrelevant and merely changing the subject.
> >> > The problem then becomes, where is it stored? The #1 problem with .ini
> >> > files was that the program often got confused about where they were
> >> > located, and if
> >> > two programs used the same named file, they corrupted each other.
> >> > While, the name problem is possible in the registry as well, it's
> >> > unlikely because apps are supposed to store their config files in
> >> > sub-sections of their company name or some other unique name related to
> >> > their product and then under app name giving two unique keys which is
> >> > unlikely to ever be the same (in fact, i've never heard of any app
> >> > using this convention which ever had a problem).
> >>
> >> All my configuration files are in /etc. Managing names can be done just
> >> like you state with registry pairs.
> >
> > That depends on the distro. On my debian system the config files for grub
> > are in /boot/grub.
>
> Again, this can be changed.
That doesn't change the fact that you argued that all configuration
files are in /etc.
> >> On my Windows machine, the registry occupies over 5 megabytes. On my main
> >> Linux workstation, /etc occupies just over 3 megabytes. My Linux has many
> >> more installed applications. And /etc has all the scripts for launching
> >> programs. Of course, as you point out later, much of /etc is not even
> >> used.
> >
> > What does that have to do with what I was saying?
>
> The registry is bloated, and continues to get bloated because of its
> design. Can't you see erik, that this is a design flaw.
No more so than an /etc directory that never gets cleaned out.
> >> The reigistry is always growing. A small application still has to open a
> >> gigantic file just to access a few bytes of information.
> >
> > No, the file is already open. And typically this is a one-time event.
>
> See earlier comment.
And is just as wrong. The registry can be cleaned out as well as /etc
can.
> >> > > Limited Registry Tools
> >> > > -----------------------
> >> > > Microsoft provides tools to maintain only parts of the registry.
> >> >
> >> > What is meant is that MS provides limited GUI front-ends. The same is
> >> > true of Unix based config files.
> >> >
> >> > > IIS 3 was a
> >> > > good example where there were many more registry entries than there
> >> > > were options in the Internet Manager.
> >> >
> >> > And how many options are available in GUI front-ends for apache?
> >> >
> >> Hardly a great demand for a gui front end for Apache. It would only get
> >> iin the way.
> >
> > That doesn't change the fact that the argument is hypocritical.
>
> No it isn't. The difference being that the registry is a binary format.
So what? If you want to argue front-ends, then be consistent. If
not, then be consistent in that as well.
> >> > > It also provides two limited editors as the
> >> > > only general purpose access to the registry and says it's can't be
> >> > > responsible if these tools are used, even though they are often the
> >> > > only way to maintain parts of the registry.
> >> >
> >> > "limited" editors? They allow you to edit everything, how is that
> >> > limited?
> >> >
> >> And one mistake, you render your Windows machine unbootable.
> >
> > Make one mistake in your /etc folder, and you can do the same.
>
> True. But there are more possiblities with the registry. Editing file sin
> /etc does not affect other files in /etc. Whereas in the registry it can.
Nor does editing a key in one part of the registry effect another
part. You seem to be under the mistkaken impression that editing one
part of the registry can change other parts of the registry. The
warnings about editing the registry are that you can change a value
which will cause your system to no longer boot, much like haphazardly
editing files in /etc.
> >> > > There are some additional tools in
> >> > > the Resource kit but their value is limited. If a registry key
> >> > > contains spaces, and many do, the limitations of the command line
> >> > > interface may provide no way to pass the necessary arguments to the
> >> > > utility. Correctly passing the arguments may require the equivalent
> >> > > of nested or escaped quotes which the NT command prompt can't do.
> >> >
> >> > This is simply From the command line there are many options, including
> >> > exporting a sub-key to text and editing it with any command line editor
> >> > then reimporting it.
> >>
> >> I thought the great reason to use the registry was to use a pretty gui.
> >> You still have to edit it with a text editor?
> >
> > No. The reason to use the registry is to have a central place for
> > configuration. The context here is command line editing.
>
> Which is a design flaw. Unrelated settings can affect each other.
That's not true.
> >> > > The registry has no equivalent of create, modify or access times so
> >> > > it's not possible to locate recently changed registry entries or to
> >> > > relate modification times to the onset of a problem.
> >> >
> >> > This is about the only legitimate claim i've read so far. Yes, this is
> >> > true.
> >> >
> >> Amazing!!! Erik agreed. I thought the registry was perfect.
> >
> > I didn't say that, I said it wasn't "fundamentally flawed".
>
> Erik, I'm don't think everything in windows is wrong. But the registry is a
> design mistake. It is from the windows 3.1 days. Although you say there is
> "little fundamental difference" the differences between having config files
> in /etc and the registry are major differences. The only benefit I can see
> from the registry, is that you can make it more difficult (although not
> impossible) to pirate software.
Your argument boils down to "I don't like it" and rumors and myths.
You have presented no technical arguments which aren't equally as
valid for the way things are done in Linux, and you have presented
many arguments which are completely irrelevant to the design of the
registry.
It's fine that you don't like it, but to call it a flawed design
without even a valid argument is just stupid.
If you say that registry bloat slows down windows, document it.
Provide evidence that this is the case. Take a 'bloated registry' and
time various things. Doing *NOTHING* else, clean it up, optimize it,
then re-time it. If you can document this, then I might consider that
you have an argument (but I know this will not happen).
If you say that a single flipped bit in the registry will hopelessly
lose all data, go ahead and edit the registry and corrupt a single bit
with a disk editor, then verify that registry repair doesn't fix it.
> >> More like rendering your computer unbootable. With many text based
> >> configuration files, a screwup in one will not affect others.
> >
> > Really, so if you screwup rc, or inittab or any of a number of other
> > critical
> > files, your system will still boot just perfectly in all cases? Just like
> > with /etc, there are critical places and non-critical places.
>
> Erik you have just point out a problem with the registry. Critical and
> non-critical belong together in the registry. Whereas, in /etc each is
> seperate.
You are still confused into thinking the registry is a single file
that one wrong bit can hopelessly ruin. that's simply not the case.
> >> > > It is usually easier to fix a corrupt registry by reinstalling.
> >> >
> >> > One could say the same thing about a complicated config file.
> >> >
> >> I make a backup of a configuration file before I edit it. Any problems
> >> and I can easily return to a functioning config.
> >
> > So backup your registry. Big deal.
>
> The problem is though, the registry can become corrupt without you editing
> it.
Only if *SOMETHING* edits it or your disk is bad. Applications can
edit config files /etc and corrupt them as well.
> >> > > If the registry is improperly edited, it can cause severe problems,
> >> > > which could lead to loss of data.
> >> >
> >> > Duh, that's why it's called "editing". The same is true of config
> >> > files.
> >> >
> >> Yet one mistake in "editing" the register will render your computer
> >> unbootable. From personal experience of course. I have yet to render a
> >> Linux box unbootable from mistakes in editing configuration files. I am
> >> sure that if I mucked up fstab, I would not have access to my partitions
> >> on the next very infrequent reboot.
> >
> > So you admit you were wrong them when you claimed editing files in etc
> > wouldn't make your system unbootable.
>
> However, this can be fixed by using a rescue disk. With windows how do you
> edit the registry if you can not boot windows. (and with NT - that includes
> w2k and XP - you can't use dos if you have NTFS partitions).
You boot to a recovery console using your CD. Or, you boot with DOS
and use something like NtfsDOS. Your argument is based on things you
*THINK* are true, but aren't.
> > It's all a frame of mind.
>
> Erik, I don't think there is any point in trying to make you see. You think
> windows has no design flaws. I don't really care that you feel this way,
> but what I care about is you making other people believe this crap. Over
> time, the registry can slow the machine down. Period. It is not a myth. You
> realise the registry needs to be defragged and cleanup.
>
> What do you do for a living? What qualifications do you have?
If you could come up with a valid argument other than your personal
preference and mythology about corruption, I would more than admit
flaws. You have yet to do so. Your arguments about "a few files" are
flawed because of the design of those files (which is not all that
different from the ext2fs in and of itself). Your argument about
editing something in one place and effecting something else is
entirely fictional. To date, the only valid concern is that you have
no last modified date on registry keys. I'm willing to concede that
this is an advantage of individual files, but not that it's an
inherant flaw of the design of the registry.
I'm a software developer, and have been for over 10 years. I
understand the difference between "flaw" "preference". You apparently
do not.
Bob Hauck
<reply_i...@mouse-potato.com> wrote:
> Nigel Feltham <nigel....@btinternet.com> wrote:
>>Exactly - if something corrupts a binary file like the registry it can wipe
>>out every key stored after the corrupt bytes.
> So that's why databases store everything in a zillion files, rather
> than in one or two big files? Oh, wait...they don't. Ooops.
Ah, but they do:
music:/var/lib/mysql/GiantDisc# dir
album.MYD musictype.MYD playlist.MYD source.MYD
album.MYI musictype.MYI playlist.MYI source.MYI
album.frm musictype.frm playlist.frm source.frm
genre.MYD player.MYD playlistitem.MYD tracklistitem.MYD
genre.MYI player.MYI playlistitem.MYI tracklistitem.MYI
genre.frm player.frm playlistitem.frm tracklistitem.frm
language.MYD playerstate.MYD playlog.MYD tracks.MYD
language.MYI playerstate.MYI playlog.MYI tracks.MYI
language.frm playerstate.frm playlog.frm tracks.frm
Postgres does a similar thing, with the various tables and indexes
living in their own files (although with less human-readable names than
MySQL uses) and each database being in a separate directory. Not sure
about Oracle or DB2, not having used them, but it looks to me as if at
least some databases use multiple files. Although, I rather suspect it
is for performance rather than safety.
--
-| Bob Hauck
-| To Whom You Are Speaking
-| http://www.haucks.org/
Ian Pegel
No, you said that:
the cache directories
are searched for almost any operation, which makes things appear to
slow down
The operative phrase here being "appear to slowdown", as in "runs at the
same speed". I told you it was a pedant point - sorry!
Erik Funkenbusch
> "Erik Funkenbusch" <er...@visi.com> wrote in
> news:PmKX7.4731$aH2.2...@ruti.visi.com:
>
> > Grom, the vast majority of this article boils down to "I like text
> > files better", not any inherantly flawed design of the registry.
>
> There is one big flaw with the system part of the registry. If it dies, the
> whole system is dead. If a Linux system configuration text file dies, its
> possible that less is affected.
This is an overly broad generalization. I can just as easily say
"There is one big flaw with the /etc directory. If it dies, the whole
system is dead". For all intents and purposes, the registry *IS* just
a directory. The ext2fs stores files in a manner that isn't all that
different from the way that registry entries are stored in the
registry. For all intents and purposes, it's a file system within a
filesystem.
Now, you might say "So why not use files, and why go to all this
trouble", and that would probably be a valid question, but it does not
support a claim that the registry is itself flawed. If the regisry is
flawed, then all file systems are flawed in the same way.
> [snip]
>
> >> The registry grows over the life of
> >> system and systems get slower as a result, because on Windows systems,
> >> virtually all programs need to access the registry. Few if any
> >> uninstall programs, cleanup everything that was installed. When an
> >> application lacks an uninstall program or either the install or
> >> uninstall program has a bug, there is a increased chance some or all
> >> the registry entries will get left behind.
> >
> > This is a myth. When win9x systems start slowing down, it's not
> > because of the registry. It's because of things like disk
> > fragmentation, and quite often large temp file or cache directories
> > (with the internet explorer integrated shells, the cache directories
> > are searched for almost any operation, which makes things appear to
> > slow down significantly. Try clearing out your caches and temp
> > directories regularly and notice the speed improvements).
>
> A myth? If the registry grows over time, and it most certainly does, surely
> that will slow down access gradually?
I don't see how one follows the other. Windows (especially in NT with
sparse file access) uses memory mapped files for access and does not
have to read from beginning to end to access the data in the file. If
the file is 1k or 100MB, and you only need to read 1k, that's what it
will be. Since the registry is stored as hashed linked lists, it's
easy to travers the trees to access whatever you want.
> I've tried clearing out caches, temp directories etc. and defragmentation
> and guess what - it's still pretty slow. The only way I've found to
> increase speed is to wipe the system and start again.
The problem with you theory is that it doesn't isolate the registry as
the cause of your problem. When you wipe the disk, you are doing a
lot more than just getting rid of the registry to recreate it with a
new install. Try an experiment. Take a freshly installed copy of the
OS and save a copy of the registry. When you find the system has
slowed down, do *NOTHING* but reinstall your original registry and
then see if anything has changed. Yes, any items added for existing
apps won't work, but you will at least be able to measure the
performance of the default installed items.
> >> Thus any bug in a software install program can
> >> result in corruption in almost any part of the registry. Unlike file
> >> and directory related programs, where administrators generally have a
> >> pretty good idea what will and will not be affected, there is no way
> >> to know what registry keys any install program will access
> >> deliberately or unintentionally change. I'm convinced that this is the
> >> primary source of bizarre install related results.
> >
> > If you don't know what sections of the registry will be effected, what
> > makes you think you'll know what will be effected the other way?
> > Again, it's already been admitted that they're functionally the same.
>
> On any OS I would like to installation of software in _one_ directory. That
> way it lives in that directory and all I need do is transfer that directory
> if necessary. Windows can lead to configuration scattered throughout the
> registry - how can that be easily transferred to another system? Linux may
> have similar problems (/etc?).
That would be nice, in theory. But from a maintenance standpoint, it
becomes more difficult. For instance, if you change your directory
structure, you now have to search through all the app directories
looking for configuration data.
Originally, the idea behind the registry was to have a single place
where configuration data could be saved for things like backups and
maintenance. This is still valid, and if a proper policy were in
place to control how the registry is used, it would be a lot easier to
manage.
> [snip]
>
> >> Because installs execute with administrator level access,
> >
> > As they almost always do in Unix/Linx.
>
> Actually, not true. I installed Kylix 2.0 into my home directory. I did not
> need to be root to install or to run it.
How exactly did you run the debugger without root access?
> >> Other Registry Problems
> >> -----------------------
> >> Over time the Registry can get congested and confused with unused,
> >> corrupt or unnecessary links or "keys". The result is a cluttered
> >> Registry that will slow down your system and even cause it to crash.
> >
> > Again, it's a myth. I espcially like the "even cause it to crash". If
> > it's unused, it's not going to cause it to crash, now is it? That's
> > pure FUD. And i've yet to see a Linux system that didn't have unused
> > config files in /etc, unless the admin was very good at cleaning things
> > up.
>
> What is the myth? That the registry isn't cluttered up with crap? Sorry,
> but that ain't no myth!
No, just like an unmanaged /etc, the registry can (and usually does)
get cluttered with stuff if you're not agressive about maintaining it.
I say it's a myth that it slows down your system to any great degree.
> >> Applications may introduce modifications into the registry without any
> >> protection or verification whatsoever, which may cause other
> >> applications or even the OS to crash. This seriously compromises the
> >> reliability of the entire system.
> >
> > I love how in one hand you claim that registry security can cause
> > problems because you can secure it in such a way as to prevent apps to
> > not have access to what they need, then in the other hand claim there
> > is no way to protect it from unauthorized access.
>
> And what is the default on Windows 2000 and XP? Is it secure? No it isn't!
> The default is to be Administrator!
Why change the argument? My point was criticizing a hypocritical
argument that says on one hand it can be made so secure as to be
unuseable and on the other hand to claim that it can't be secured.
> >>http://msdn.microsoft.com/library/default.asp?url=/library/en-
> >>us/ddtools/hh/dd
> >>tools/bccodes_0t5z.asp
> >
> >This is not a bug. This is a "bug check". I can understand your
> >confusion,
> >but it's basically a warning message when something is corrupted, not a
> >bug
> >itself.
>
> What happens when the system hits a bugcheck? It depends... by default it
> reboots! Woops! That's a crash!
And? How does that make a bug check a bug as was claimed?
Erik Funkenbusch
> Erik Funkenbusch wrote:
>
> > Grom, the vast majority of this article boils down to "I like text files
> > better", not any inherantly flawed design of the registry.
> >
> > "grom" <gro...@optusnet.com.au> wrote in message news:3c2f17c7$0$26026
> >> The fallacy is that registry data is accessed
> >> by key name. There is little fundamental difference between accessing a
> >> dozen different keys in a deeply nested registry tree than there is a
> >> dozen text files in different directories with different filenames.
> >
> > And here we have the rub. There is little fundamental difference between
> > the two mechanisms. You have just admitted this, therefore any "serious
> > flaw" in the registry must exist in configuration files too, or it would
> > be a fundamental difference, would it not?
>
> No, because the registry has furhter disadvantages (such as the entire
> system relies on two files for the registry) without any benefits.
This is an implementation detail. In Win9x, yeah.. 2 files. In NT,
there are several (5 or 6). This is an implementation detail, not a
design detail.
> >> This is confirmed by the fact that Windows
> >> systems slow with age as software is added; UNIX systems do not slow with
> >> age due to software installs. Further, if the directory structure is
> >> logical, you can often find the text configuration file you need, without
> >> knowing before hand what its named or where it's located. Without an
> >> exact key fragment or data, this is not possible in the registry.
> >
> > Can you be any more contradictory, you just said a few paragraphs ago that
> > it wasn't any easier to find text files you don't know. Further, the
> > registry structure can be just as equally logically laid out.
>
> You can do pattern matching, unlike the registry where you need to know the
> key.
Regedit has a search function. It's basic, true.. but I don't really
know that many people that truely use regular expression in any but
basic form. If you're so worried, you can write your own regular
expression search utility for it.
> >> A major difference between the registry and text configuration files, is
> >> that the registry is a proprietary binary format with only two widely
> >> available.general purpose utilities, for it and a number of custom GUI
> >> front ends, each of which accesses specific limited sections of the
> >> registry.
> >
> > Doesn't sound any different between text files in /etc or ~ and the
> > various GUI front-ends being developed fro Linux (YaST2, DrakConfig (or
> > whatever it's called..), the various Gnome and KDE config tools, etc...
>
> What? Because it's the config files are text, anybody can write there own
> front end. You can even use your favourite editor.
Yeah? Anyone can write their own front-end to the registry as well.
The registry is accessed through very well known API's.
> >> There are more utilities and tools to manipulate text files than
> >> any other storage format on earth.
> >
> > While true, this is actually a negative for text files. First, you need
> > to learn lots of different utilities with differen syntax, then you need
> > to write code for every app you use to parse and process those files,
> > since text files often have very different formats.
>
> No you don't. You can chose only one. The text files in UNIX have a very
> similar format. Sorry erik, wrong again.
Bullshit. I can pull any 10 files at random, and almost all will have
different formats. Look at XF86Config versus Hosts versus httpd.conf
versus sendmail's configs versus smb. They all have very different
formats.
> >> There isn't anything that can't be done,
> >> either manually or automatically, with scripting in the way of locating,
> >> comparing or changing text files using general purpose text editing and
> >> manipulation utilities. Text files can have user friendly, graphical
> >> front ends more easily than proprietary binary files. Text file formats
> >> normally allow as much internal documentation as the developers care to
> >> provide.
> >
> > Bullshit, there is no reason that text files can have GUI front ends
> > easier than with registry front-ends. In fact, it's easier to do the
> > registry front-end because registry access always uses the same API's no
> > matter what the configuration, while text files have broad and varying
> > formats that need to be understood by the front-end.
>
> Besides the fact the registry is a proprietary binary format.
Which is accessed with well-known API functions. You don't have to
know the format of the file to access the data within it, unlike with
unix config files.
> >> The .INI format used in pre Windows 95 versions, had named areas or
> >> stanzas with an open ended number of key value pairs following. Add
> >> intelligent file names to a logical directory structure and there isn't
> >> any data that can't be stored and in a logical relationship to the
> >> programs that use the data.
> >
> > There is no fundamental difference between the data associations used in
> > the registry or .ini files. They each use a "section" (key) name and
> > key/value pairs.
>
> No. But there is a difference. The .INI doesn't have everything in a
> central location.
If they're all in the same directory, how is that any different?
> >> If the
> >> configuration data is program specific, it can go with the program. If
> >> it's system wide, it can be stored in a standard system directory, in
> >> which key filenames and stanzas within files would be reserved.
> >
> > The problem then becomes, where is it stored? The #1 problem with .ini
> > files was that the program often got confused about where they were
> > located, and if
> > two programs used the same named file, they corrupted each other. While,
> > the name problem is possible in the registry as well, it's unlikely
> > because apps are supposed to store their config files in sub-sections of
> > their company name or some other unique name related to their product and
> > then under app name giving two unique keys which is unlikely to ever be
> > the same (in fact, i've never heard of any app using this convention which
> > ever had a problem).
>
> What about system wide settings?
What about them? System wide settings are in the HKEY_LOCAL_MACHINE
hive, individual user settings are in HKEY_CURRENT_USER.
> >> With files, programs read what they need and not much more, if the files
> >> are well planned.
> >
> > Of course the planning of the files has no control over how the use has
> > edited them.
>
> What are you saying?
What were you saying? You claimed that if the files were "planned"
right, you didn't need to read much. My point was that the end user
can completely change the files making any "planning" moot.
> >> The registry grows over the life of
> >> system and systems get slower as a result, because on Windows systems,
> >> virtually all programs need to access the registry. Few if any uninstall
> >> programs, cleanup everything that was installed. When an application
> >> lacks an uninstall program or either the install or uninstall program has
> >> a bug, there is a increased chance some or all the registry entries will
> >> get left behind.
> >
> > This is a myth. When win9x systems start slowing down, it's not because
> > of the registry. It's because of things like disk fragmentation, and
> > quite often large temp file or cache directories (with the internet
> > explorer integrated shells, the cache directories are searched for almost
> > any operation, which makes things appear to slow down significantly. Try
> > clearing out your caches and temp directories regularly and notice the
> > speed improvements).
>
> ROTFLMAO. Yeah right!
Well rebutted technical argument.
> >> Limited Registry Tools
> >> -----------------------
> >> Microsoft provides tools to maintain only parts of the registry.
> >
> > What is meant is that MS provides limited GUI front-ends. The same is
> > true of Unix based config files.
>
> You can uses any editor to edit Unix config files.
You can also use any editor to edit the registry, simply export the
relevant sections (or the whole thing if you like), edit it in your
favorite editor, then reimport.
> >> IIS 3 was a
> >> good example where there were many more registry entries than there were
> >> options in the Internet Manager.
> >
> > And how many options are available in GUI front-ends for apache?
>
> It is difficult (if not impossible) to edit the registry directly and
> change the config for an application. Whereas the text config files for
> apache are commented and very easy to understand.
What do you mean by "directly"? If you mean outside of the OS
provided API's, then you're right. But that's a good thing, since it
keeps the data in a consistent format.
If you mean "outside of a GUI front-end" then you're completely wrong.
While the text files for apache are *somewhat* commented, there are
dozens of config files without even a single comment within them.
> >> It also provides two limited editors as the
> >> only general purpose access to the registry and says it's can't be
> >> responsible if these tools are used, even though they are often the only
> >> way to maintain parts of the registry.
> >
> > "limited" editors? They allow you to edit everything, how is that
> > limited?
>
> Search function is crap.
But workable. And if you're so annoyed, just write your own search
utility.
> >> The registry has no equivalent of create, modify or access times so it's
> >> not possible to locate recently changed registry entries or to relate
> >> modification times to the onset of a problem.
> >
> > This is about the only legitimate claim i've read so far. Yes, this is
> > true.
>
> So its the only claim that you wish to agree with.
It is the only claim that I *DO* agree with.
> >> Keys in the registry have security permissions that are very similar to
> >> directory permissions. Anyone who has seriously tightened file and
> >> directory security, on almost any kind of server, knows that this almost
> >> invariably breaks some user's access to some applications. With files,
> >> it's generally pretty straightforward to figure out who needs update
> >> access, who needs read access and who needs no access. With the registry,
> >> since all access is programmatic, behind the scenes, and not documented,
> >> it's almost impossible to know who needs access to what let alone what
> >> level of access. I've never needed a guide to tell me how to tighten file
> >> security, but any independent attempt to tighten registry security
> >> without clear guidelines as to what should and should not be changed is
> >> very likely to lead to serious trouble. Permission changes can be at the
> >> current level or apply to sub keys. The registry is quite deep in some
> >> areas and often huge in its entirety. Changing individual entries, except
> >> to limit access to known specific keys for specific security related
> >> results won't do much and changing sub keys will make changes several
> >> levels down that you can only hope need to be the same as the parent
> >> key's permissions.
> >
> > I'm just not even sure who this makes sense. I simply don't understand
> > how someone can claim that you can know what permissions to apply to
> > files, but not know what permissions to apply to registry keys. As
> > already admitted, they are functionally the same thing.
>
> Erik you are so blinded.
Another well reasoned, technical argument.
How can you claim you know what permissions apply to files, but don't
know what permissions apply to the registry?
> >> Registry Security and Installs
> >> --------------------------------
> >> The worst problem with the registry is that is a single structure, to
> >> which administrators normally have full access.
> >
> > And administrators of unix systems don't have full access to /etc?
>
> The point comes with the next sentence.
Does it? It doesn't appear to.
> >> Most software installs need to be run as an administrator.
>
> That is why it is a problem in windows.
This is not the case with "most" software. It's the case with *SOME*
software.
> > As do most unix installs, since you need write access to /etc to put your
> > config files into it. Yes, it's usually possible to install something
> > into your own home directory, but then the same is usually true of apps in
> > Windows as well. As with unix, whole classes of apps need administrator
> > access to function on either system.
>
> A user can install to there own directory. You fool erik.
Perhaps, but how do you run apache without administrator access? You
can't open port 80 without admin access. How do you run sendmail or
an ftp daemon? Further, installing those programs to your own
directory only is problematic and requires a great deal of tweaking.
> >> Thus any bug in a software install program can
> >> result in corruption in almost any part of the registry. Unlike file and
> >> directory related programs, where administrators generally have a pretty
> >> good idea what will and will not be affected, there is no way to know
> >> what registry keys any install program will access deliberately or
> >> unintentionally change. I'm convinced that this is the primary source of
> >> bizarre install related results.
> >
> > If you don't know what sections of the registry will be effected, what
> > makes you think you'll know what will be effected the other way? Again,
> > it's already been admitted that they're functionally the same.
>
> See earlier statements.
Which haven't answered the question.
> >> By definition, one of the specific functions of an install program, is to
> >> update the registry. Programmers develop install programs like any
> >> others, make mistakes, and get poor specifications. There are important
> >> differences though. The registry is probably the most system specific
> >> component on any Windows system, as every system variation is reflected
> >> in it, somewhere, thus making it one of the hardest parts to properly
> >> test. All changes are normally made with the full authority of the
> >> system.
> >
> > Not even remotely true. For instance, all user specific settings are
> > stored in the users registry hive (and contrary to what is stated here,
> > the registry is *NOT* one big database, it's actually stored in several
> > sub-files, some of
> > which are loaded specifically for each and every user). Of course a user
> > has direct access to their own hive, and applications running run in the
> > users security context.
>
> It doesn't work all that well. Again there are many programs (many
> microsoft ones included) that can only be installed as administrator.
System utilities generally need administrator access. But no,
actually, you don't need administrator access to install, you only
need install accesss. That's one of the things about the new windows
installer created for Windows 2000 (and installable on 9x) which most
programs use these days. This prevents users from installing things
if you don't want them to. How do you prevent someone from installing
something in Unix?
> >> Any misunderstanding the programmer has regarding the use of system calls
> >> related to registry updates, could result in unpredictable consequences.
> >
> > And what about misunderstandings in the way to use text processing tools?
>
> It is much easier to recover in a UNIX system. Fucking the registry, causes
> a person to reinstall in almost all cases.
Now this is just complete and utter horseshit. First, you can recover
just as easily. Backup tools for the registry are available and come
with the OS. If you choose not to back it up, that's as bad as not
backing up your etc files. Second, I can go in and change 100 random
entries and probably never make the system unbootable. 1000 random
entries and it *MIGHT* make the system unbootable.
You seem to think that the registry is some kind of card house that if
you change one thing it effects everything else. That's simply not
the case.
> >> Whatever the programmer believes his program needs to or update will get
> >> updated except when the programmer makes a mistake.
> >
> > Same is true of text files.
> >
> >> Because installs execute with administrator level access,
> >
> > As they almost always do in Unix/Linx.
>
> Ummm. One can install to there home directory.
One *CAN*, but rpm's are almost always setup to install config files
to /etc.
> >> then whatever the install program is built
> >> to do, whether it is intentional or accidental, will be done.
> >
> > Ditto.
>
> Linux uses package managers which is much better then having an install exe
> for each program.
And they can't decide exactly which package manager to use. Each
distro can, and usually is different.
> >> When you
> >> install software, you are normally asked what directory to put it in,
> >> usually what program group to put it in and sometimes whether or not to
> >> create a desktop icon. You're never asked about registry updates. When
> >> you install software you implicitly trust the install programmer as well
> >> as the company that employs him or her and hopefully tests the installs
> >> well. When you install Windows software, someone else is making critical
> >> system choices for you, without your knowledge or consent.
> >
> > This has absolutely nothing to do with the registry, it has to do with how
> > installation code is written. I've seen plenty of script based installs
> > on Windows for instance.
>
> Yes, if they install program isn't any good, and can leave you with a
> corrupt registry. Which leaves you with a corrupt system.
You are confusing two concepts. A corrupted registry, and corrupted
data IN that registry. If the registry itself is corrupted, then that
is like your disk being corrupted. If the data is corrupted, that's
like random stuff in your given configuration file.
Most of the time, if you were to randomly corrupt the data, it's not
going to do anything but make whatever program is using that data to
not work or work incorrectly. You have to specifically go into the
system hives and start randomly changing stuff to effect how the
system boots.
> >> When software is installed on UNIX and configuration files specific to
> >> that software are created or updated, as opposed to a centrally shared,
> >> system-wide registry, the programmer pretty much has to have malicious
> >> intent to damage anything but the software being installed. Also, most
> >> UNIX installs are done with scripts that the administrator can read if
> >> they wish, as opposed to binary executables, which for all practical
> >> purposes, cannot be read.
> >
> > Again, nothing to do with the registry. This is simply a philisophical
> > difference in the way install programs are written. You could do
> > precisely the same for Unix/Linux, or you could create scripts on Windows.
>
> See above.
And still not addressed. It has nothing to do with the registry or
how it's designed. Can't you admit that?
> >> Further, UNIX install programs that find missing shared
> >> libraries or other perquisite parts, inform the administrator or the
> >> missing components, but allow the administrator to locate and install the
> >> prerequisites. Windows programs that require shared functions not
> >> automatically provided with the OS, automatically provide them,
> >> in whatever version the install vendor thinks is appropriate, creating
> >> DLL hell. With the registry, any programming mistakes can cause serious
> >> unintended damage. The surprise is not that some installs go bad, but
> >> that the large majority actually work.
> >
> > This is no longer the case, since Windows provides side-by side DLL
> > installs and windows file protection. And again, it has nothing to do
> > with the registry.
>
> No, but it is a futher problem (and it still applies, although it has
> improved slighty)
And still has nothing to do with the registry.
> --------------------------------END-----------------------------------------
> --
> >>
> >> Other Registry Problems
> >> -----------------------
> >> Over time the Registry can get congested and confused with unused,
> >> corrupt or unnecessary links or "keys". The result is a cluttered
> >> Registry that will slow down your system and even cause it to crash.
> >
> > Again, it's a myth. I espcially like the "even cause it to crash". If
> > it's
> > unused, it's not going to cause it to crash, now is it? That's pure FUD.
> > And i've yet to see a Linux system that didn't have unused config files in
> > /etc, unless the admin was very good at cleaning things up.
>
> No its not a myth.
It is a myth. Prove it, as I've asked. I'll believe you if you tell
me you've timed replacing the registry alone and can prove that the
registry itself is the cause of this slowdown.
> >> It is usually easier to fix a corrupt registry by reinstalling.
> >
> > One could say the same thing about a complicated config file.
>
> No you don't need to reinstall. Just replace that config file.
Gee, and here I though replacing the config file was reinstalling it.
> >> If the registry is improperly edited, it can cause severe problems, which
> >> could lead to loss of data.
> >
> > Duh, that's why it's called "editing". The same is true of config files.
>
> Yes, but editing seperate config files can not cause as much problems.
Of course it can. If someone without any idea of what they're doing
goes into /etc and starts changing stuff at random, it's just as
possible.
GreyCloud
> Grom, the vast majority of this article boils down to "I like text files
> better", not any inherantly flawed design of the registry.
>
> "grom" <gro...@optusnet.com.au> wrote in message news:3c2f17c7$0$26026
>> The fallacy is that registry data is accessed
>> by key name. There is little fundamental difference between accessing a
>> dozen different keys in a deeply nested registry tree than there is a
>> dozen text files in different directories with different filenames.
>
> And here we have the rub. There is little fundamental difference between
> the
> two mechanisms. You have just admitted this, therefore any "serious flaw"
> in the registry must exist in configuration files too, or it would be a
> fundamental difference, would it not?
>
>> If you don't
>> already know the key, i.e., have it stored somewhere, there is no more
>> direct way to it than a text file whose location you don't know.
>
> No difference between the two in this manner either.
>
>> Theoretically many binary lookups should be more efficient than many file
>> opens. In practice few applications will need to open more than two
>> files: one containing common system data and one application specific
>> data.
>
> And one containing user specific data.
>
>> Numerous binary tree lookups, in a large deeply nested structure, become
>> quite resource intensive.
>
> This is complete bullshit, they are no more resource intensive than
> parsing large text files with many configuration items.
>
Yeah, that's right Ewic, make a fool out of yourself. A lot of vendor
software adds their crap to the registry, and if you add enough software to
the registry, then you end up waiting longer for the vendor program to
startup and find its special keys and variables inside this bloated
registry.
>> This is confirmed by the fact that Windows
>> systems slow with age as software is added; UNIX systems do not slow with
>> age due to software installs. Further, if the directory structure is
>> logical, you can often find the text configuration file you need, without
>> knowing before hand what its named or where it's located. Without an
>> exact key fragment or data, this is not possible in the registry.
>
> Can you be any more contradictory, you just said a few paragraphs ago that
> it
> wasn't any easier to find text files you don't know. Further, the
> registry structure can be just as equally logically laid out.
>
But it really isn't logically laid out. Ever look for a feature to change
its attribute in the register?? It ain't easy.
But the real issue here is that you claim to prefer FreeBSD. And in fact
you spend more of your energy supporting and defending M$ than you do if
someone made a false statement about FreeBSD. Now why is that??
GreyCloud
But that is why databases are structured they way they are. M$ is just
plain lazy about their so-called registry. Corrupt a big file and it takes
a while to rebuild... corrupt a small file and it doesn't take long to
rebuild. In this case M$ carries all their eggs in one basket.
GreyCloud
>>
>> Because the registry stores everything in a couple of files.
>
> You do realize that your hard disk is the equivelant of a single
> database file, right? Perspective counts for a lot. If your hard
> disk becomes corrupted, you can lose your entire disk just as easily.
>
Hahah... yes ewic perspective does count for a lot here. Tell Oracle about
how they can stuff everything into one big database file because it won't
matter if the hard drive fails. Uh-huh...
> You have not provided any valid reason as to why "a couple of files"
> is any worse than 1000 files.
Speed youngster, speed!
> However, 1000 files have the obvious
> disadvantages of conflicting file formats, decreased efficiency (the
> files have to be read, then parsed, then converted to binary formats
> where applicable. The regitry has all that information in a useable
> form).
>
BWAHAHAHAHAH!!! AGAIN tell that to any database administrator! This one is
funny!
>
> A "bloated registry" has not proven to be a problem with one
> exception, the system hive.
>
Another piece of baloney. Try that on a slower PII.
You'll see the difference immediately.
>> So if your not using all the registry, the entire bloated registry is
>> still in memory.
>
Another inefficiency, in the case of cheap PCs whose memories aren't ECC
types... the registry can really get corrupted in a hurry this way when you
do a system shutdown after running a few hours.
> Maybe, maybe not. The registry is opened as a memory mapped file.
> This allows the OS to discard any part that hasn't been recently used
> and reload it on demand via the paged back storage mechanism. This is
> quite efficient.
>
Then why does a system that has a lot of programs on it tend to load those
programs more slowly than one with a few??
Charlie Ebert
It's Erik's way of admitting FreeBSD makes up more of Windows than
he will admit to.
--
Charlie
GreyCloud
To some extent yes and to some extent no. The older computers with 48M of
ram were a little sensitive to the registry. If you load up too many
programs on the hard drive that used the install/remove program wizard the
registry just got bigger. Booting got more time consuming, and even the
start menus' response time slowed down to the point of being a real
annoyance. The program would take its time loading, and also accessing the
large registry to get its stored values. Once the program was actually
running then it would run normally. Except when a new window would come
up, again it would have to access the registry for the size and orientation
and color of the window if that were changed from the default user
settings. Most of the time it was just default settings. However, you can
clean up the registry once a week by rebooting into Dos and typing in
scanreg /fix and scanreg /opt to clean out the empty entries. Then you'd
just type in win /wx to get going again.
Its not the users' fault in any of this , but then do you expect the user
to know how to maintain the registry in good health??
GreyCloud
I pretty much reboot down into DOS and type in scanreg /fix and scanreg
/opt to clean up the registry along with a good defrag. It seems to speed
it up some but it will never be like it was when it was new, because you
didn't load it up with a lot of programs in the beginning.
GreyCloud
>> There is one big flaw with the system part of the registry. If it dies,
>> the whole system is dead. If a Linux system configuration text file dies,
>> its possible that less is affected.
>
> This is an overly broad generalization. I can just as easily say
> "There is one big flaw with the /etc directory. If it dies, the whole
> system is dead". For all intents and purposes, the registry *IS* just
> a directory.
Oh yeah, sure it is.
And just how likely is the /etc directory going to get screwed up eh Ewic??
Why do people have to re-install windows at least twice a year??
Why do the techs always have to rebuild the registry often??
But the big question is this: Why are you defending M$ so vehemently??
Eh??
Russ Lyttle
Basic.
Kelsey Bjarnason
> grom <gro...@optusnet.com.au> wrote:
>
>
>>The SOFTWARE part of the registry on my workstation is over 8MB and I
>>know of a SAM over 19MB. The registry grows over the life of system and
>>systems get slower as a result, because on Windows systems, virtually
>>all programs need to access the registry.
>
> It is possible to clean this crap out ... but Windows does not have a
> built-in "purge" tool.
So what's the Linux purge tool that cleans out all the leftover
configuration files strewn about, while not deleting either configuration
files for applications still installed, or any other files?
Jim Richardson
Erik Funkenbusch <er...@visi.com> wrote:
> "TuxTrax" <ARC...@zerojunktuxtrax.com> wrote in message news:<20011230.162058...@fortress.tuxnet>...
>> In article <3c2f3...@nntp2.nac.net>, "Net Resident"
>> <nomail...@nothanks.org> wrote:
>>
>> > In article <3c2f17c7$0$26026$afc3...@news.optusnet.com.au>, "grom"
>> > <gro...@optusnet.com.au> wrote:
>> >
>> >> What Is The Registry?
>> >
>> > <snip>
>> >
>> > Personally I always assumed that the registry was just a way to
>> > obfuscate the system further which seems to me to be near and dear to
>> > MS's heart (or lack thereof...).
>> >
>> > *shrug*
>>
>> You have to ask yourself what kind of moron designs any system around one
>> part, the failure of which, brings down the whole system.
>
> Yeah, you have to wonder. Like maybe a kernel? How about a disk
> drive? What about an init process? There are literally dozens of
> things on any given system which are critical components that will
> bring the whole system down if that one thing fails.
>
Exactly! So why go to all the effort to design in another one like the
registry?
--
Jim Richardson
Anarchist, pagan and proud of it
www.eskimo.com/~warlock
Linux, because life's too short for a buggy OS.
Jim Richardson
Erik Funkenbusch <er...@visi.com> wrote:
> Grom, the vast majority of this article boils down to "I like text files
> better", not any inherantly flawed design of the registry.
>
>> The fallacy is that registry data is accessed
>> by key name. There is little fundamental difference between accessing a
>> dozen different keys in a deeply nested registry tree than there is a dozen
>> text files in different directories with different filenames.
>
> And here we have the rub. There is little fundamental difference between the
> two mechanisms. You have just admitted this, therefore any "serious flaw" in
> the registry must exist in configuration files too, or it would be a
> fundamental difference, would it not?
>
little != none
Peter Köhlmann
> On Sun, 30 Dec 2001 13:59:55 -0600,
> Erik Funkenbusch <er...@visi.com> wrote:
>> Grom, the vast majority of this article boils down to "I like text files
>> better", not any inherantly flawed design of the registry.
>>
>> "grom" <gro...@optusnet.com.au> wrote in message news:3c2f17c7$0$26026
>>> The fallacy is that registry data is accessed
>>> by key name. There is little fundamental difference between accessing a
>>> dozen different keys in a deeply nested registry tree than there is a
>>> dozen text files in different directories with different filenames.
>>
>> And here we have the rub. There is little fundamental difference between
>> the
>> two mechanisms. You have just admitted this, therefore any "serious
>> flaw" in the registry must exist in configuration files too, or it would
>> be a fundamental difference, would it not?
>>
>
> little != none
>
Well, one of those "little" differences is that the config files are not
held in memory, waiting to be corrupted there and then written back in
that state.
Peter
--
Another name for a Windows tutorial is crash course
Mart van de Wege
> Pete Goodwin <pgoo...@REMOVE.TO.REPLY.blueyonder.co.uk> wrote in
> message news:<Xns91888A40F13C...@193.38.113.46>...
>> "Erik Funkenbusch" <er...@visi.com> wrote in
>> news:PmKX7.4731$aH2.2...@ruti.visi.com:
>>
>> > Grom, the vast majority of this article boils down to "I like text
>> > files better", not any inherantly flawed design of the registry.
>>
>> There is one big flaw with the system part of the registry. If it dies,
>> the whole system is dead. If a Linux system configuration text file
>> dies, its possible that less is affected.
>
> This is an overly broad generalization. I can just as easily say "There
> is one big flaw with the /etc directory. If it dies, the whole system
> is dead". For all intents and purposes, the registry *IS* just a
> directory. The ext2fs stores files in a manner that isn't all that
> different from the way that registry entries are stored in the registry.
> For all intents and purposes, it's a file system within a filesystem.
>
> Now, you might say "So why not use files, and why go to all this
> trouble", and that would probably be a valid question, but it does not
> support a claim that the registry is itself flawed. If the regisry is
> flawed, then all file systems are flawed in the same way.
>
I see a glaring problem with your argument here though: In the case of
the /etc directory there is only one single point of failure to wipe it
out, and that is filesystem corruption. In case of the registry there are
two points of failure, filesystem corruption and registry corruption. So
that makes the registry twice as vulnerable to corruption.
(Never mind that ext2 is such a robust filesystem that irrepairable
corruption of an entire filesystem is pretty rare.)
Thank you for playing and a Happy New Year.
Mart
--
A dirty mind is a joy forever
Its sleaziness will never cease
Mart van de Wege
dpkg --purge <packagename> will do it on Debian. Don't know if rpm has a
similar option.
Tim Smith
>> This is complete bullshit, they are no more resource intensive than
>> parsing large text files with many configuration items.
>>
>
>Yeah, that's right Ewic, make a fool out of yourself. A lot of vendor
>software adds their crap to the registry, and if you add enough software to
>the registry, then you end up waiting longer for the vendor program to
>startup and find its special keys and variables inside this bloated
>registry.
As opposed to keeping each program's configuration in its own file, so
that when you add enough software, then you end up waiting longer and
longer for programs to start up because the filesystem has slowed down
because you've got a zillion things in /etc?
The registry is stored as a tree, and exhibits size vs. speed behavior
similar to a filesystem (which is no surprise, since it basically *is*
a filesystem, that just happens to be implemented inside other files,
rather than directly on disk).
--Tim Smith
TuxTrax
"Kelsey Bjarnason" <kel...@xxspamxx.telus.net> wrote:
Shall we not compare apples and oranges here (this is not specifically
aimed at you Kelsey, but the conversation in general).
The registry is not simply a configuration file. It is a binary data base
that windows uses to store every kind of data, critical, and not so
critical. It mixes third party entries with critical system entries, in a
most haphazard fashion. Windows is fairly ordered (usually) in it's
accesses, but any one can (and does) use the registry for everything from
variable storage to temporary hkey entries. That's *anyone* with a capital
*A* , and it includes visual basic programmers to professional third party
software producers. What makes the situation even worse is the lack of a
good install/deinstall tool, something microsoft has yet to get right. All
kinds of dead wood gets left in the registry after the typical deinstall,
and it's really cool because since it's not plain text, plain english
files with helpful comments, like you have in Linux, it's *really* hard to
keep this oh-so-important data base clean.
And now we come to the cleaning part of your comment. Yes, Linux does have
a cleaning tool for dynamic files: actually several. Scripting languages
like perl and python, or just some judicious CRON jobs will do the trick.
This aside from the fact that there aren't that many dynamically changing
files that need cleaning to begin with, and the fact that *none* of them
are going to bring down the (already booted) system single handedly like a
corrupted registry *will*. Notice I said *will* not *can*. Anyone who has
used windows any length of time knows the truth of this, and the pain of a
corrupted registry/crapped out OS. It's easy enough to say "make a
registry backup" except for the fact that the registry is constantly
changing as windows modifies it on the fly.
cheers,
Mathew
--
TuxTrax (n.) An invincible, all terrain, Linux driven armored assault
vehicle that can take as much fire as it gives ;-)
Yes, I am a Penguin cult high priest. Fin readings upon request.
Amateur Radio Operator KD6MSI
www.tuxtrax.com
Tim Smith
>Then why does a system that has a lot of programs on it tend to load those
>programs more slowly than one with a few??
It has nothing to do with the registry. This statement is based on
hundreds of hours going over detailed traces of Windows application
launches during the development of a Windows application launch
accelerator (http://www.webcelerator.com/products/superfassst/).
--Tim Smith
ps: in case anyone notices my name on some of the software patents
related to this...sorry! I think just as much as most other Linux
advocates that the patent office is screwed up when it comes to
handling software patents, but since we are competing with big
companies like Symantec and McAffee and Microsoft and Intel in the
system enhancement market, and *they* get patents, we have to get
patents too.
Tim Smith
>So what's the Linux purge tool that cleans out all the leftover
>configuration files strewn about, while not deleting either configuration
>files for applications still installed, or any other files?
rpm.
--Tim Smith
Peter Köhlmann
> GreyCloud <mi...@cumulus.com> wrote:
>>> This is complete bullshit, they are no more resource intensive than
>>> parsing large text files with many configuration items.
>>>
>>
>>Yeah, that's right Ewic, make a fool out of yourself. A lot of vendor
>>software adds their crap to the registry, and if you add enough software
>>to the registry, then you end up waiting longer for the vendor program to
>>startup and find its special keys and variables inside this bloated
>>registry.
>
> As opposed to keeping each program's configuration in its own file, so
> that when you add enough software, then you end up waiting longer and
> longer for programs to start up because the filesystem has slowed down
> because you've got a zillion things in /etc?
>
You certainly do not know what you are talking about. A filesystem can be
very well organized as a BTree (HPFS of OS/2 for example is) so search to
any file will execute the same no matter how many files there are.
That MS completely botched that and choose the worst filesystem imaginable
(at least for all windows version before NT) is a totally different matter
> The registry is stored as a tree, and exhibits size vs. speed behavior
> similar to a filesystem (which is no surprise, since it basically *is*
> a filesystem, that just happens to be implemented inside other files,
> rather than directly on disk).
>
Yep, and if something happens to this "special filesystem" your system is
toast. As I have encountered several times. Reinstall blues...
Peter
--
Windows, for those too scared to use their brain
Peter Köhlmann
> GreyCloud <mi...@cumulus.com> wrote:
>>Then why does a system that has a lot of programs on it tend to load those
>>programs more slowly than one with a few??
>
> It has nothing to do with the registry. This statement is based on
> hundreds of hours going over detailed traces of Windows application
> launches during the development of a Windows application launch
> accelerator (http://www.webcelerator.com/products/superfassst/).
>
So care to tell us with *what* it has to do? With the primitive filesystem
MS choose to use perhaps?
>
> ps: in case anyone notices my name on some of the software patents
> related to this...sorry! I think just as much as most other Linux
> advocates that the patent office is screwed up when it comes to
> handling software patents, but since we are competing with big
> companies like Symantec and McAffee and Microsoft and Intel in the
> system enhancement market, and *they* get patents, we have to get
> patents too.
Fine for you. I am not impressed. Got patents on my own. Means
absolutely nothing to me. Just drop it, you wont get any points
in "believability" for that.
Peter
--
A NT based server can be run by an idiot and usually is.
Chris Ahlstrom
> Well, one of those "little" differences is that the config files are not
> held in memory, waiting to be corrupted there and then written back in
> that state.
Sure they are. Linux keeps lots of stuff in memory as long as possible.
The difference is that the apps mostly read the file, and don't write to
it, and, should they write and save a corrupt file, it affects only
that app.
Chris
--
Living large and loving Linux!
Bob Hauck
Well, it is somewhat less needed than on Windows, simply because most
programs document the location of their config files in the man page.
This makes it pretty easy to remove them. But both major packaging
tools have commands for this:
apt-get --purge remove appname
rpm -e appname
These don't get per-user config files though, you'll have to get those
some other way. And I take no responsibility for broken packages that
forget where they installed the files.
Kenneth Downs
/* snip */
>
> And now we come to the cleaning part of your comment. Yes, Linux does
> have a cleaning tool for dynamic files: actually several. Scripting
> languages like perl and python, or just some judicious CRON jobs will do
> the trick. This aside from the fact that there aren't that many
> dynamically changing files that need cleaning to begin with, and the
> fact that *none* of them are going to bring down the (already booted)
> system single handedly like a corrupted registry *will*. Notice I said
> *will* not *can*. Anyone who has used windows any length of time knows
> the truth of this, and the pain of a corrupted registry/crapped out OS.
Up until Win95 I had never met a problem I could not solve -- never found
a disaster I could not rescue. One good thing about the simplicity of
those old DOS/Novell or WFW/Novell setups was they could not hurt
themselves that badly. You could take practically any "dead" system and
restore it to perfect health. It was the age of being a hero because you
could take care of people.
Then one day a client of mine, whose equipment and network I had not
installed and did not actually service, asked me to help out. Seemed the
help desk person's computer had this message at bootup "Windows Protection
Error, please reboot." It was cruel because when you rebooted it said it
again.
I agreed to look at it but after 15 minutes or so told them it was
open-ended, and I could not do it as a courtesy, but would forget about
the 15 minutes if they didn't want to commit to that. They insisted that
I could handle it, and agreed to pay for a support call to MS. I said
fine.
MS told me to correct the system by overwriting System.dat with a backup
stored in C:\ and then reinstalling all of the hardware. I was
astonished. Never had any vendor told me to do any such thing. Start over
from scratch? Lose previous work? I've never felt right about MS since.
--Ken
Peter Köhlmann
Thats essentially what I have written.
Stephen Howe
> NIC vendors who catered to the WIN crowd would install
> settings into the registry as well as software and not
> UN-install it when the time came. The Registry would
> be completely crapped out to the point your new WIN
> card wouldn't work at all.
Which touches on another topic. All of this is because when Microsoft
launched Win95 they did not provide it with a decent installer/deinstaller
which they should have forced all 3rd party vendors to use (after all Mac's
have always had installers).
The result is 3rd party vendors did installation their own way until
Wise/InstallShield met a niche. That is why "DLL hell" exists.
Now if MS did it right the first time, you would be able to uninstall the
NIC vendors left-over crud using the standard deinstaller.
Stephen Howe
Erik Funkenbusch
news:slrna318h...@finch.haucks.org...
The actual data is typically stored in one or two files. The other files are
indexes to that data, which is not the same thing at all.
Try this (assuming MYD is your data file)
mv language.myd language.mydb
echo "x" > language.myd
cat language.mydb >> language.mydb
How nice are your multiple files now?
The registry isn't stored in a single file either. On Windows 9x systems,
there's at least system.dat and user.dat . On NT systems, you have several
hives in different files plus different user.dat's for each user.
Erik Funkenbusch
news:2%8Y7.14275$726.5...@news1.sttln1.wa.home.com...
> Erik Funkenbusch wrote:
>
> >>
> >> Because the registry stores everything in a couple of files.
> >
> > You do realize that your hard disk is the equivelant of a single
> > database file, right? Perspective counts for a lot. If your hard
> > disk becomes corrupted, you can lose your entire disk just as easily.
> >
>
> Hahah... yes ewic perspective does count for a lot here. Tell Oracle about
> how they can stuff everything into one big database file because it won't
> matter if the hard drive fails. Uh-huh...
What are you getting at?
> > You have not provided any valid reason as to why "a couple of files"
> > is any worse than 1000 files.
>
> Speed youngster, speed!
There's only one disk head. And a pre-parsed table in memory is a lot faster
than opening and parsing individual files.
> >> So if your not using all the registry, the entire bloated registry is
> >> still in memory.
>
> Another inefficiency, in the case of cheap PCs whose memories aren't ECC
> types... the registry can really get corrupted in a hurry this way when you
> do a system shutdown after running a few hours.
If your memory is failing like this, you have a lot worse problems to deal
with. *ANY* part of your system can become unstable and corrupted. What
happens if your file system cache becomes corrupted and writes a corrupted
dirty page back out?
> > Maybe, maybe not. The registry is opened as a memory mapped file.
> > This allows the OS to discard any part that hasn't been recently used
> > and reload it on demand via the paged back storage mechanism. This is
> > quite efficient.
>
> Then why does a system that has a lot of programs on it tend to load those
> programs more slowly than one with a few??
Why don't you profile your system and tell me exactly why, not guess and pull
it out of your ass?
Erik Funkenbusch
Because they're morons and don't know what they're doing? How easy is it to
screw up your /etc directly? I've seen it happen with just unplugging the cpu
while the system is up.
> But the big question is this: Why are you defending M$ so vehemently??
> Eh??
That's not "the big questions". The big question is, why do you feel the need
to exagerate every claim against MS? If you truly had any integrity, you
would wish to make sure your statements were as accurate as possible, not just
exagerated claims to support your own pesonal preference.
Erik Funkenbusch
news:m1advzp...@inconnu.isu.edu...
> "Erik Funkenbusch" <er...@visi.com> writes:
>
> > "Michael Vester" <mve...@v-wave.com> wrote in message
> >
> > > Except text files can be very well documented. I like to add all sorts
of
> > > info to my configuration files. Makes them self-documenting.
> >
> > There is nothing stopping you from adding comments in the registry as
well,
> > just insert a few keys and put text comments in.
>
> Laughable.
>
> 1) Please name one (1) software product that ships with comments in the
> registry.
That doesn't change the fact that you can.
> 2) Since all keys are hashed, and representation is left up to the
> client, how can you keep your "comments" in order?
Keys are displayed in alphabetical order.
Key: DoSomething = blah
Comment: DoSomething# = Tells the computer to do something.
>
> 3) How do you group similar configuration items next to eachother
> without making use of a zillion keys (which enter their own form
> of confusion into the equation)?
>
> [snip -- I'm going to snip a bunch of this long thread, so this
> warning will apply to the entire text below; use your news client's
> history if you're curious]
>
> > > Most /etc configuration names are the same as the program they support.
> >
> > What happens if you have two programs with the same name?
>
> Hmm, like HKEY_SYSTEM\Software\Blah\Blah\Blah? They would both suffer
> from that "problem" (ahem, "strawman") if it actually existed.
>
> > > There is only one format for a configuration file that I can see. A
line
> > > of text with a <LF>. Comments are #. Any text editor can edit them.
> >
> > There are lots of formats. Do comments start with #'s or ;'s? Hell,
> > gs.fontmap uses %'s for comments.
>
> That's better than NO COMMENTS at all, I do believe.
>
> > does the format have a name = option format, or is it just a line item?
Is it
> > field oriented (like, say, hosts) or are there commands issued per line?
> > etc...
>
> Erik, Erik, Erik... Being able to understand any configuration file
> requires that you know what is being done underneath. The Windows
> registry lets you know that something is a DWORD, but what good does
> that do you unless you know the format of the value? What if you need
> to add a value to a key -- should it be a REG_MULTISZ or a REG_BINARY?
> Being able to make sense of a grammar requires knowledge; files can
> include an option and have it commented out by default -- no such luck
> with the registry.
>
> The deliniation of text files isn't completely uniform, but it is
> mostly standardized with libraries today. The lame ducks in this
> department are older software products -- the same ones that would
> probably be using their own configuration files under Windows...
>
> > > All my configuration files are in /etc. Managing names can be done just
> > > like you state with registry pairs.
> >
> > That depends on the distro. On my debian system the config files for grub
are
> > in /boot/grub.
>
> Hmm, the same function under Windows NT is in C:\BOOT.INI, which isn't
> even in the registry.
>
> Wonderful example, great attempt to show how uniform the registry is.
>
> > > Why would anyone change their name or location?
> >
> > The point was that if the text files are laid out correctly, you
> > didn't have to read more than was necessary. There's nothing about
> > name or location in this.
>
> Hmm, kind of like the (many times, MULTIPLE) locations that things are
> found in the registry? Don't throw rocks, etc.
>
> > The reason to use the registry is to have a central place for
> > configuration.
>
> What advantage does that offer for *humans*? You know, the ones that
> actually have to use and maintain the computer?
>
> > > I make a backup of a configuration file before I edit it. Any problems
and
> > > I can easily return to a functioning config.
> >
> > So backup your registry. Big deal.
>
> It's much easier to move an emacse save~ file back when something goes
> wrong than it is to remember to backup the registry before touching
> it. Again, it comes down to which system was designed for humans and
> which system was designed around buzz-word compliance and not much
> else.
>
> > It's all a frame of mind.
>
> Yes, the registry makes you think like the computer. Text files let
> you use human language and human language editors to express
> yourself. One is proprietary, one is open.
>
> --
> It is financially more expensive to go to prison than to attend Harvard.
> Craig Kelley -- kell...@isu.edu
> http://www.isu.edu/~kellcrai finger i...@inconnu.isu.edu for PGP block
Jim Richardson
On my wife's machine, there is a system.dat that weighs in at 3MB, please
note that the windows side (it is a dual boot, that spends 90+% of it's
time in Linux) Has only win98, 4 games (Diablo II, UT, Baldurs Gate and
Max Payne, Photoshop 5.5 and flash 4. That's it. No mailservr, no
outlook, no newsreader, nothing else. On the linux side, with apache,
exim (mail server) leafnode (newserver) 1001 useful utilities and
programs that install default .rc files in /etc, and the whole directory
is 6.9MB. When exim starts up, it just reads the exim stuff, doesn't
care about any of the other, when I play falcon's Eye, (remotely
displayed on my laptop) all it cares about is it's config file. Consider
also that the bulk of the config files in /etc are comments, which are
ignored by the various parsers. Whereas there are little or no comments
in the windows registry.
If vim hoses it's config, it doesn't matter squat to the rest of the
system. That is not the same under windows. I know what I prefer.
On a nearly related note, anyone know why when I click on the desktop in
windowmaker, the menu pops up instantly, whereas when I do the same
thing in windows, it takes a second? Or why it takes a second or so for
the start button in windows to be clicked and present me with the menu?
This is on the same system, dual booting. Linux feels a lot snappier.
TuxTrax
<reply_i...@mouse-potato.com> wrote:
> --Tim Smith
>
> ps: in case anyone notices my name on some of the software patents
> related to this...sorry! I think just as much as most other Linux
> advocates that the patent office is screwed up when it comes to handling
> software patents, but since we are competing with big companies like
> Symantec and McAffee and Microsoft and Intel in the system enhancement
> market, and *they* get patents, we have to get patents too.
<grin> no need to apologise, Tim. When you are playing in their sandbox,
you have to have shovels and pails that are at least as big as theirs.
Kelsey Bjarnason
> In article <pan.2002.01.01.00...@xxspamxx.telus.net>,
> "Kelsey Bjarnason" <kel...@xxspamxx.telus.net> wrote:
>
>> On Sun, 30 Dec 2001 09:46:50 -0800, Tsu Dho Nimh wrote:
>>
>>> grom <gro...@optusnet.com.au> wrote:
>>>
>>>
>>>>The SOFTWARE part of the registry on my workstation is over 8MB and I
>>>>know of a SAM over 19MB. The registry grows over the life of system
>>>>and systems get slower as a result, because on Windows systems,
>>>>virtually all programs need to access the registry.
>>>
>>> It is possible to clean this crap out ... but Windows does not have a
>>> built-in "purge" tool.
>>
>> So what's the Linux purge tool that cleans out all the leftover
>> configuration files strewn about, while not deleting either
>> configuration files for applications still installed, or any other
>> files?
>
> Shall we not compare apples and oranges here (this is not specifically
> aimed at you Kelsey, but the conversation in general).
>
> The registry is not simply a configuration file. It is a binary data
> base that windows uses to store every kind of data, critical, and not so
> critical. It mixes third party entries with critical system entries, in
> a most haphazard fashion.
You mean like stuffing virtually everything other than per-user settings
into /etc?
And yes, it is a binary database - of configuration information. While
it's true it may lack a "purge" tool, the same seems to be true of Linux;
at least, I haven't seen such a critter on my Mandrake box yet.
> Windows is fairly ordered (usually) in it's
> accesses, but any one can (and does) use the registry for everything
> from variable storage to temporary hkey entries. That's *anyone* with a
> capital *A* , and it includes visual basic programmers to professional
> third party software producers.
Right, but then again, they're _supposed_ to be using it; that's what
it's for. However, note that not everyone has permissions to modify all
areas of it; a non-privileged program can update per-user areas, say, but
not the system areas. At least under NT and 2K - let's remember that
"Windows" does include these.
> What makes the situation even worse is
> the lack of a good install/deinstall tool, something microsoft has yet
> to get right. All kinds of dead wood gets left in the registry after the
> typical deinstall, and it's really cool because since it's not plain
> text, plain english files with helpful comments, like you have in Linux,
> it's *really* hard to keep this oh-so-important data base clean.
Well, yeah, but again, when I noted that removing some application left
behind a mess of dross under Linux, the response was that this was
configuration information, so it _should_ be left behind.
Pick one: either apps _should_ leave config settings behind when
uninstalled, so the point above is irrelevant, or they _shouldn't_ do
this, in which case virtually all Linux apps are broken in this regard,
at least by the default methods of uninstalling (rather than "purging").
> And now we come to the cleaning part of your comment. Yes, Linux does
> have a cleaning tool for dynamic files: actually several. Scripting
> languages like perl and python, or just some judicious CRON jobs will do
> the trick.
Fine; please point out where such a tool is installed, by default, on
every Linux box, and the command-line I need to launch it. Would that be
/usr/local/bin/confclean perhaps? Nope, no such animal. Oh, wait - you
mean I can _write_ a program to clean up this way? Well, so what? I can
do that in Windows, too. The bitch wasn't that you couldn't program a
cleanup tool, but that Windows didn't _have_ a cleanup tool; by this
argument, it follows that Linux must, perforce, have such a tool, no
programming required; where is it?
> This aside from the fact that there aren't that many
> dynamically changing files that need cleaning to begin with, and the
> fact that *none* of them are going to bring down the (already booted)
> system single handedly like a corrupted registry *will*.
No? Fine; corrupt your boot loader information. Corrupt your vmlinuz
image. Whoops. Yes, corrupting some files under Windows will muck
things up - so what? Linux just happens to have _different_ files with
the same property. Big deal.
> Notice I said
> *will* not *can*. Anyone who has used windows any length of time knows
> the truth of this, and the pain of a corrupted registry/crapped out OS.
Not really. Can't recall this happening on any of my boxes. Oh, I've
hit the occasional corruption, sure, requiring a reboot after the
automatic cleaning phase, but I can't recall having the system corrupted
so badly it can't boot at all.
Well, not quite true, I do recall _a_ box where this had happened - but
then again, the corruption was hardly limited to the registry, so
singling it out is a bit disingenuous.
Kelsey Bjarnason
Really? Okay, let's see.
rpm -Uvh gkrellm[x].rmp
rpm -Uvh gkrellm-themes[x].rmp
rpm -Uvh gkrellm-plugins[x].rmp
[run the program a while]
rpm -e gkrellm-plugins
rpm -e gkrellm-themes
rpm -e gkrellm
Hmm; ~/.gkrellm still exists. Now, let's see about that purge option,
shall we?
rpm -e --allfiles gkrellm
Nope. --allfiless can only be specified during installation.
rpm -e --allmatches gkrellm
Nope: gkrellm not installed.
Sorry, I missed it in the man pages; once a program is uninstalled, how
does RPM manage to clean up after the program - i.e. delete all the
leftover configuration files? Remember, we're talking about stuff left
behind _after_ uninstalling, and how to purge that.
GreyCloud
> GreyCloud <mi...@cumulus.com> wrote:
>>Then why does a system that has a lot of programs on it tend to load those
>>programs more slowly than one with a few??
>
> It has nothing to do with the registry. This statement is based on
> hundreds of hours going over detailed traces of Windows application
> launches during the development of a Windows application launch
> accelerator (http://www.webcelerator.com/products/superfassst/).
>
Then why when a computer has a lot of applications on it that it tends to
load a lot more slower than one with a few applications on it. You do know
that a lot of developers use the registry for their programs use don' you??
Then there are developers that like to append their custom code to the end
of MFC42.dll file thinking that is a safe place to put their code like ICQ
use to do.
And BTW, I did a re-install of the neighbors win98 and just the o/s and it
booted up nice and fast. Then I loaded up all of his applications and then
to test it out, rebooted the computer.... lo and behold the computer booted
up pretty slowly... so as you were saying??
Kelsey Bjarnason
Right, that's what I use - and it does _not_ remove those configration
files; it leaves crud all about the place - just like apps do in the
Windows registry.
I'm not saying the registry is good, but that if we're going to say "X is
bad because of A,B and C" we need to be sure we're not shooting ourselves
in the feet - say by suggesting that Windows lacks a "purge" tool to
clean out the leftover dross after applications are uninstalled, while
failing to note that Linux seems to lack the same thing.
Yes, I'm sure _some_ Linuxes [distros] have tools for doing this, but it
doesn't appear to be universal by any means.
GreyCloud
> GreyCloud <mi...@cumulus.com> wrote:
>>> This is complete bullshit, they are no more resource intensive than
>>> parsing large text files with many configuration items.
>>>
>>
>>Yeah, that's right Ewic, make a fool out of yourself. A lot of vendor
>>software adds their crap to the registry, and if you add enough software
>>to the registry, then you end up waiting longer for the vendor program to
>>startup and find its special keys and variables inside this bloated
>>registry.
>
> As opposed to keeping each program's configuration in its own file, so
> that when you add enough software, then you end up waiting longer and
> longer for programs to start up because the filesystem has slowed down
> because you've got a zillion things in /etc?
>
You seem to have a delusion here about what /etc is all about I see.
It is always more time consuming to access a very large data base than a
nice small data base.
> The registry is stored as a tree, and exhibits size vs. speed behavior
> similar to a filesystem (which is no surprise, since it basically *is*
> a filesystem, that just happens to be implemented inside other files,
> rather than directly on disk).
>
Which is still a very bad design.
Craig Kelley
> "Craig Kelley" <i...@inconnu.isu.edu> wrote in message
> news:m1advzp...@inconnu.isu.edu...
> > "Erik Funkenbusch" <er...@visi.com> writes:
> >
> > > "Michael Vester" <mve...@v-wave.com> wrote in message
> > >
> > > > Except text files can be very well documented. I like to add all sorts
> of
> > > > info to my configuration files. Makes them self-documenting.
> > >
> > > There is nothing stopping you from adding comments in the registry as
> well,
> > > just insert a few keys and put text comments in.
> >
> > Laughable.
> >
> > 1) Please name one (1) software product that ships with comments in the
> > registry.
>
> That doesn't change the fact that you can.
It presents the fact that it is never done, and as such your idea is
utterly useless.
> > 2) Since all keys are hashed, and representation is left up to the
> > client, how can you keep your "comments" in order?
>
> Keys are displayed in alphabetical order.
>
> Key: DoSomething = blah
> Comment: DoSomething# = Tells the computer to do something.
Keys are displayed in whatever order the registry client wants them to
be displayed in, remember? That is one of the supposed advantages of
the registry; client-agnosticity.
[snip un-answered attacks on the registry]
Jim Richardson
Erik Funkenbusch <er...@visi.com> wrote:
> "Craig Kelley" <i...@inconnu.isu.edu> wrote in message
> news:m1advzp...@inconnu.isu.edu...
>> "Erik Funkenbusch" <er...@visi.com> writes:
>>
>> > "Michael Vester" <mve...@v-wave.com> wrote in message
>> >
>> > > Except text files can be very well documented. I like to add all sorts
> of
>> > > info to my configuration files. Makes them self-documenting.
>> >
>> > There is nothing stopping you from adding comments in the registry
>> > as well, just insert a few keys and put text comments in.
>>
>> Laughable.
>>
>> 1) Please name one (1) software product that ships with comments in the
>> registry.
>
> That doesn't change the fact that you can.
>
please explain how, so my mum can do it...
>> 2) Since all keys are hashed, and representation is left up to the
>> client, how can you keep your "comments" in order?
>
> Keys are displayed in alphabetical order.
good lord, you mean they aren't grouped by function ?
Is there any way to use CVS/RCS for the registry? (or something similar
since it is not text)
Jim Richardson
Erik Funkenbusch <er...@visi.com> wrote:
> "GreyCloud" <mi...@cumulus.com> wrote in message
> news:9_9Y7.14278$726.5...@news1.sttln1.wa.home.com...
>> Erik Funkenbusch wrote:
>>
>> >> There is one big flaw with the system part of the registry. If it dies,
>> >> the whole system is dead. If a Linux system configuration text file dies,
>> >> its possible that less is affected.
>> >
>> > This is an overly broad generalization. I can just as easily say
>> > "There is one big flaw with the /etc directory. If it dies, the whole
>> > system is dead". For all intents and purposes, the registry *IS* just
>> > a directory.
>>
>> Oh yeah, sure it is.
>> And just how likely is the /etc directory going to get screwed up eh Ewic??
>> Why do people have to re-install windows at least twice a year??
>> Why do the techs always have to rebuild the registry often??
>
> Because they're morons and don't know what they're doing? How easy is it to
> screw up your /etc directly? I've seen it happen with just unplugging the cpu
> while the system is up.
>
unplugging the CPU with power on? why not mention morons who take
sledgehammers to harddrives too... jeesh!
I am sure that the windows registry would be entirely unfazed if someone
pulled the CPU out...
>> But the big question is this: Why are you defending M$ so vehemently??
>> Eh??
>
> That's not "the big questions". The big question is, why do you feel the need
> to exagerate every claim against MS? If you truly had any integrity, you
> would wish to make sure your statements were as accurate as possible, not just
> exagerated claims to support your own pesonal preference.
>
What do you feel about someone who lumps the security flaws of all linux
distros together, including multible mail servers, web servers,
newservers, ftp servers &etc. Would you class that as pretty dishonest?
How about if someone wanted to include all the gpl stuff that can
compile under cygwin as "available" for windows, and not count any bugs
they bring along into the windows total, yet wants to include those same
program's bugs in the linux total?
Kelsey Bjarnason
> Erik Fudkenbrush wrote:
>
>>> > > If you don't
>>> > > already know the key, i.e., have it stored somewhere, there is no
>>> > > more direct way to it than a text file whose location you don't
>>> > > know.
>>> >
>>> > No difference between the two in this manner either.
>>>
>>> Except text files can be very well documented. I like to add all sorts
>>> of info to my configuration files. Makes them self-documenting.
>>
>> There is nothing stopping you from adding comments in the registry as
>> well, just insert a few keys and put text comments in.
>
> Adding extra comments in the registry for all programs makes it grow,
> causing the PC to slow down and pushing the size closer to where the PC
> won't boot.
Just FMI, what size, precisely, would this be? I've had registries, on
heavily loaded machines, well over 30Mb, sometimes considerably over. No
problems booting.
>>> Opening a few tiny 1 - a few K text files verses opening 3 gigantic
>>> binary files. The Unix way is much more efficient.
>>
>> The files are open by the OS all the time, therefore no extra resources
>> are consumed for individual programs opening them.
>
> So instead of opening a 1k file to read the settings when I start an
> application I have 3 files totalling over 10mb permanently in memory and
> you still claim this doesn't make the PC run slower.
They're not in memory; they're files, on the disk. You _open_ them, you
don't _load them into memory_.
>>> Most /etc configuration names are the same as the program they
>>> support.
>>
>> What happens if you have two programs with the same name?
>
> What happens if 2 windows programs use the same registry key.
Unlikely. Most software (virtually all, IME) uses the standard format
Vendor/Application; therefore even if two companies produced some program
"System Tester" for example, the two would reside in distinct registry
trees.
There is still some room for clashes; notably in the Application Paths
section of the registry; if both apps were called "systest.exe", there
would only be one entry in the App Paths area, not two. This could be a
problem, but rarely is in actuality.
> The worst that can happen on linux is that they will share the
> configuration file and this won't cause any problems unless they both
> look for the same config line in the file - they should ignore any lines
> they don't recognise.
'Course, if you uninstall one of them and tell it to take its configs
with it, presumably you've just killed the other app's config. Not
great.
>>> > This is a myth. When win9x systems start slowing down, it's not
>>> > because of
>>> > the registry. It's because of things like disk fragmentation, and
>
> Bullshit - when you install a program the registry grows, when you
> uninstall the redundant areas of the file aren't compressed so files
> containing the registry ends up the same size as if you had never done
> the uninstalls.
So?
If I add 1,000,000 records to a database and then "delete" 900,000 of
them, I shouldn't expect any particular slowdown - despite the fact that
the data is actually still there (since I didn't actually _remove_ it, I
just set a 'deleted' flag on the 'deleted' records.)
The only cases where I'd expect this to be an actual problem are two:
first, when Windows initially boots, if it performs a linear read of all
keys to build an index (rather than maintaining a static index into the
database), and second, when an application performs such a read.
The first may or may not be the way Windows does things; I don't know.
The second is just plain silly, unless you're writing some sort of
utility to do exacty this sort of thing - such as a regdump tool - in
which case you're going to expect it to run a lot slower than a typical
application which simply loads a specific key or set of keys.
> This was proved by exporting the whole registry to a file then shutting
> the machine down to DOS mode and using regedit in commandline mode to
> build a new registry from the text file - the resulting registry files
> were less than half the size and the machine became a lot more stable
> (well as good as you can get under win98 anyway - only crashing daily
> rather than the several times per hour it crashed before the registry
> rebuild).
Which, sadly, doesn't really prove much of anything. Now try repeating
this, consistently, over a variety of sizes, configurations, etc, to at
least avoid reliance on strictly anecdotal evidence.
>> Really, so if you screwup rc, or inittab or any of a number of other
>> critical
>> files, your system will still boot just perfectly in all cases? Just
>> like
>
> Screwing up the files may stop it booting but with text files you can
> boot from a recovery disk and correct the problem - with windows how do
> you correct your error without a re-install as regedit won't edit the
> registry if it won't boot.
Probably true... however, except in the rarest of cases, a reinstall
recreates the _system_ areas of the registry, while leaving your
application data alone; thus a reinstall involves only reinstalling the
OS, not the applications. While annoying, it's not exactly fatal.
>> So backup your registry. Big deal.
>
> So I can back up my config file to a floppy before editing, what do I do
> with a 10mb registry.
Make a copy of it to another location on the hard drive?
Terry Porter
<pan.2002.01.01.15...@xxspamxx.telus.net> dashed off:
>> The registry is not simply a configuration file. It is a binary data
>> base that windows uses to store every kind of data, critical, and not so
>> critical. It mixes third party entries with critical system entries, in
>> a most haphazard fashion.
>
>You mean like stuffing virtually everything other than per-user settings
>into /etc?
*stuffing* ?
Thats a little emotive Kelsey, as my /etc contains only 4 megabytes
of files and there is still 974 megabytes available.
You're Wintrolling again.
>
>And yes, it is a binary database - of configuration information. While
>it's true it may lack a "purge" tool, the same seems to be true of Linux;
>at least, I haven't seen such a critter on my Mandrake box yet.
Why should Linux need a purge tool for /etc ?
>
>> Windows is fairly ordered (usually) in it's
>> accesses, but any one can (and does) use the registry for everything
>> from variable storage to temporary hkey entries. That's *anyone* with a
>> capital *A* , and it includes visual basic programmers to professional
>> third party software producers.
>
>Right, but then again, they're _supposed_ to be using it; that's what
>it's for. However, note that not everyone has permissions to modify all
>areas of it; a non-privileged program can update per-user areas, say, but
>not the system areas. At least under NT and 2K - let's remember that
>"Windows" does include these.
NT,2K, and XP combined do not add up to a fraction of the numbers that
W9x totals, and on that "Windows" OS, *everyone* has permission to
do whatever they like. The user is the equivalent of root.
>> What makes the situation even worse is
>> the lack of a good install/deinstall tool, something microsoft has yet
>> to get right. All kinds of dead wood gets left in the registry after the
>> typical deinstall, and it's really cool because since it's not plain
>> text, plain english files with helpful comments, like you have in Linux,
>> it's *really* hard to keep this oh-so-important data base clean.
>
>Well, yeah, but again, when I noted that removing some application left
>behind a mess of dross under Linux, the response was that this was
>configuration information, so it _should_ be left behind.
Still apologising for Microsoft Kelsey ?
It seems that my initial opinion of you was quite accurate.
Can you give an example of this "dross" please ?
>Pick one: either apps _should_ leave config settings behind when
>uninstalled, so the point above is irrelevant, or they _shouldn't_ do
>this, in which case virtually all Linux apps are broken in this regard,
>at least by the default methods of uninstalling (rather than "purging").
Nonsense, with Debian, all app files are removed and if any are left
behind, apt-get tells you where they are, so you an manually remove them.
>> This aside from the fact that there aren't that many
>> dynamically changing files that need cleaning to begin with, and the
>> fact that *none* of them are going to bring down the (already booted)
>> system single handedly like a corrupted registry *will*.
>
>No? Fine; corrupt your boot loader information.
How ?
> Corrupt your vmlinuz
>image.
How ?
> Whoops. Yes, corrupting some files under Windows will muck
>things up - so what?
Then use your boot floppy, np.
> Linux just happens to have _different_ files with
>the same property. Big deal.
Linux has nothing in common with Windows, your examples dont
change this.
>
>> Notice I said
>> *will* not *can*. Anyone who has used windows any length of time knows
>> the truth of this, and the pain of a corrupted registry/crapped out OS.
>
>Not really.
Yes ... really.
> Can't recall this happening on any of my boxes.
I can.
> Oh, I've
>hit the occasional corruption, sure, requiring a reboot after the
>automatic cleaning phase, but I can't recall having the system corrupted
>so badly it can't boot at all.
Me neither, the registry problem just killed an application. That taught
me the perrils of Windows "housekeeping".
>
>Well, not quite true, I do recall _a_ box where this had happened - but
>then again, the corruption was hardly limited to the registry, so
>singling it out is a bit disingenuous.
The Windows registry is a liability, and everyone on Cola knows it,
with the exception of Windows advocates.
--
_
.' `. Free Micro Burner
|a_a| http://w3w.arafuraconnect.com.au/~tp/burn.html
Debian \ V /
2.2.20 /( )\ Linux Registration Number: 103931
|\`> < /\ http://counter.li.org
\_|=='|_/
* OSS is long-term credible ... FUD tactics can not be used to combat it.
Tim Smith
>> As opposed to keeping each program's configuration in its own file, so
>> that when you add enough software, then you end up waiting longer and
>> longer for programs to start up because the filesystem has slowed down
>> because you've got a zillion things in /etc?
>>
>
>You certainly do not know what you are talking about. A filesystem can be
>very well organized as a BTree (HPFS of OS/2 for example is) so search to
>any file will execute the same no matter how many files there are.
Do you have /etc mounted on an HPFS filesystem?
>That MS completely botched that and choose the worst filesystem imaginable
>(at least for all windows version before NT) is a totally different matter
>
>> The registry is stored as a tree, and exhibits size vs. speed behavior
>> similar to a filesystem (which is no surprise, since it basically *is*
>> a filesystem, that just happens to be implemented inside other files,
>> rather than directly on disk).
>>
>Yep, and if something happens to this "special filesystem" your system is
>toast. As I have encountered several times. Reinstall blues...
You missed the point so completely I'm not sure how to answer.
--Tim Smith
Tim Smith
>You seem to have a delusion here about what /etc is all about I see.
>It is always more time consuming to access a very large data base than a
>nice small data base.
Really? The database for my web cache is constant access time whether
it has 100 pages in it or 1000000 pages in it. Amazing what an
afternoon spent with Knuth will do...
>> The registry is stored as a tree, and exhibits size vs. speed behavior
>> similar to a filesystem (which is no surprise, since it basically *is*
>> a filesystem, that just happens to be implemented inside other files,
>> rather than directly on disk).
>>
>
>Which is still a very bad design.
You've still given no arguments to back this claim.
--Tim Smith
Tim Smith
>> It has nothing to do with the registry. This statement is based on
>> hundreds of hours going over detailed traces of Windows application
>> launches during the development of a Windows application launch
>> accelerator (http://www.webcelerator.com/products/superfassst/).
>>
>
>So care to tell us with *what* it has to do? With the primitive filesystem
>MS choose to use perhaps?
If you want to see what it has to do with, use strace on a Netscape
launch on Linux. Netscape is slow on Linux for pretty much the same
reason Windows programs are slow on Windows, it turns out.
For some reasons I can't explain, I found this quite funny. :-)
>> ps: in case anyone notices my name on some of the software patents
>> related to this...sorry! I think just as much as most other Linux
>> advocates that the patent office is screwed up when it comes to
>> handling software patents, but since we are competing with big
>> companies like Symantec and McAffee and Microsoft and Intel in the
>> system enhancement market, and *they* get patents, we have to get
>> patents too.
>
>Fine for you. I am not impressed. Got patents on my own. Means
>absolutely nothing to me. Just drop it, you wont get any points
>in "believability" for that.
It wasn't meant to impress you. It was meant to head off flaming if
anyone went to the referenced web page, saw that my employer mentions
patents, and saw that some of them have my name on them, since
software patents are generally frowned upon in the free software
community.
--Tim Smith
Tim Smith
>Really? Okay, let's see.
Sorry...I thought we were just talking about the config files in /etc,
which I *think* it removes on uninstall (could be wrong). I missed
that we were also talking about the per-user files in ~.
--Tim Smith
Erik Funkenbusch
news:3dbt0a...@127.0.0.1...
> On my wife's machine, there is a system.dat that weighs in at 3MB, please
> note that the windows side (it is a dual boot, that spends 90+% of it's
> time in Linux) Has only win98, 4 games (Diablo II, UT, Baldurs Gate and
> Max Payne, Photoshop 5.5 and flash 4. That's it. No mailservr, no
> outlook, no newsreader, nothing else. On the linux side, with apache,
> exim (mail server) leafnode (newserver) 1001 useful utilities and
> programs that install default .rc files in /etc, and the whole directory
> is 6.9MB. When exim starts up, it just reads the exim stuff, doesn't
> care about any of the other, when I play falcon's Eye, (remotely
> displayed on my laptop) all it cares about is it's config file. Consider
> also that the bulk of the config files in /etc are comments, which are
> ignored by the various parsers. Whereas there are little or no comments
> in the windows registry.
Comments aren't ignored by parsers. They still have to be read and determined
to be comments.
Further, while your wifes registry may be 3MB, each program doesn't read 3MB,
it only reads what it needs to.
> If vim hoses it's config, it doesn't matter squat to the rest of the
> system. That is not the same under windows. I know what I prefer.
So you're claiming that if Diablo II's registry keys get messed up, your other
programs won't work? That's simply not true.
> On a nearly related note, anyone know why when I click on the desktop in
> windowmaker, the menu pops up instantly, whereas when I do the same
> thing in windows, it takes a second? Or why it takes a second or so for
> the start button in windows to be clicked and present me with the menu?
> This is on the same system, dual booting. Linux feels a lot snappier.
Because Windowmaker doesn't have an extensible menu system like windows. With
windows, it searches a number of configuration entires *EVERY TIME* you right
click the menu. If it were in text files, it would still take the same amount
of time. You might think that this is a poor design, and maybe so.. but it
prevents means the GUI doesn't have to be restarted everytime you make a
change to it, unlike Windowmaker.
Erik Funkenbusch
Ok, I wasn't clear there. When I said "unplug the cpu" i meant the power
cord, not ripping the CPU out of it's socket.
> >> But the big question is this: Why are you defending M$ so vehemently??
> >> Eh??
> >
> > That's not "the big questions". The big question is, why do you feel the
need
> > to exagerate every claim against MS? If you truly had any integrity, you
> > would wish to make sure your statements were as accurate as possible, not
just
> > exagerated claims to support your own pesonal preference.
>
> What do you feel about someone who lumps the security flaws of all linux
> distros together, including multible mail servers, web servers,
> newservers, ftp servers &etc. Would you class that as pretty dishonest?
They're security flaws that effect linux. Period.
> How about if someone wanted to include all the gpl stuff that can
> compile under cygwin as "available" for windows, and not count any bugs
> they bring along into the windows total, yet wants to include those same
> program's bugs in the linux total?
If those applications were actually commonly used under windows, perhaps. But
they're not.
Erik Funkenbusch
> "Erik Funkenbusch" <er...@visi.com> writes:
>
> > "Craig Kelley" <i...@inconnu.isu.edu> wrote in message
> > news:m1advzp...@inconnu.isu.edu...
> > > "Erik Funkenbusch" <er...@visi.com> writes:
> > >
> > > > "Michael Vester" <mve...@v-wave.com> wrote in message
> > > >
> > > > > Except text files can be very well documented. I like to add all
sorts
> > of
> > > > > info to my configuration files. Makes them self-documenting.
> > > >
> > > > There is nothing stopping you from adding comments in the registry as
> > well,
> > > > just insert a few keys and put text comments in.
> > >
> > > Laughable.
> > >
> > > 1) Please name one (1) software product that ships with comments in
the
> > > registry.
> >
> > That doesn't change the fact that you can.
>
> It presents the fact that it is never done, and as such your idea is
> utterly useless.
Look, i was responding to the claim that you CANNOT comment the registry.
Whether or not it's done is irrelevant to what you can do if you want to.
> > > 2) Since all keys are hashed, and representation is left up to the
> > > client, how can you keep your "comments" in order?
> >
> > Keys are displayed in alphabetical order.
> >
> > Key: DoSomething = blah
> > Comment: DoSomething# = Tells the computer to do something.
>
> Keys are displayed in whatever order the registry client wants them to
> be displayed in, remember? That is one of the supposed advantages of
> the registry; client-agnosticity.
Valid point. However, it's highly unlikely that you're going to see two
similarly named keys in radically different orders.
Erik Funkenbusch
> On Tue, 1 Jan 2002 16:10:27 -0600,
> Erik Funkenbusch <er...@visi.com> wrote:
> > "Craig Kelley" <i...@inconnu.isu.edu> wrote in message
> > news:m1advzp...@inconnu.isu.edu...
> >> "Erik Funkenbusch" <er...@visi.com> writes:
> >>
> >> > "Michael Vester" <mve...@v-wave.com> wrote in message
> >> >
> >> > > Except text files can be very well documented. I like to add all
sorts
> > of
> >> > > info to my configuration files. Makes them self-documenting.
> >> >
> >> > There is nothing stopping you from adding comments in the registry
> >> > as well, just insert a few keys and put text comments in.
> >>
> >> Laughable.
> >>
> >> 1) Please name one (1) software product that ships with comments in the
> >> registry.
> >
> > That doesn't change the fact that you can.
>
> please explain how, so my mum can do it...
Does your mum edit her rc files?
> >> 2) Since all keys are hashed, and representation is left up to the
> >> client, how can you keep your "comments" in order?
> >
> > Keys are displayed in alphabetical order.
>
> good lord, you mean they aren't grouped by function ?
They can be, that's what sub-keys are for.
> Is there any way to use CVS/RCS for the registry? (or something similar
> since it is not text)
You can export it to text.
Erik Funkenbusch
> Tim Smith wrote:
>
> > GreyCloud <mi...@cumulus.com> wrote:
> >>Then why does a system that has a lot of programs on it tend to load those
> >>programs more slowly than one with a few??
> >
> > It has nothing to do with the registry. This statement is based on
> > hundreds of hours going over detailed traces of Windows application
> > launches during the development of a Windows application launch
> > accelerator (http://www.webcelerator.com/products/superfassst/).
>
> Then why when a computer has a lot of applications on it that it tends to
> load a lot more slower than one with a few applications on it. You do know
> that a lot of developers use the registry for their programs use don' you??
Since you don't know, why don't you do some profiling yourself?
There are lots of reasons this happens under 9x, and none of them have
anything to do with the registry. Want a few?
1) The number of files in the system paths increase, which increase the
amount of time needed to locate dll's and shared libraries when loading.
2) The number of files in the temporary and cache directories increase,
increasing the amount of time spent looking for cached files.
3) As you add more files, the filesystem becomes more fragmented, taking more
and more time the more fragemented it gets.
These things are cumulative, and add upon each other.
> Then there are developers that like to append their custom code to the end
> of MFC42.dll file thinking that is a safe place to put their code like ICQ
> use to do.
What are you talking about? You can't just "append" code onto the end of a
DLL.
> And BTW, I did a re-install of the neighbors win98 and just the o/s and it
> booted up nice and fast. Then I loaded up all of his applications and then
> to test it out, rebooted the computer.... lo and behold the computer booted
> up pretty slowly... so as you were saying??
Oh yeah, that proves it's the registry, since that's the ONLY thing you
changed, right? NOT.
Erik Funkenbusch
news:pan.2002.01.01.15...@xxspamxx.telus.net...
> On Sun, 30 Dec 2001 16:34:52 -0800, Nigel Feltham wrote:
>
> > Erik Fudkenbrush wrote:
> >
> >>> > > If you don't
> >>> > > already know the key, i.e., have it stored somewhere, there is no
> >>> > > more direct way to it than a text file whose location you don't
> >>> > > know.
> >>> >
> >>> > No difference between the two in this manner either.
> >>>
> >>> Except text files can be very well documented. I like to add all sorts
> >>> of info to my configuration files. Makes them self-documenting.
> >>
> >> There is nothing stopping you from adding comments in the registry as
> >> well, just insert a few keys and put text comments in.
> >
> > Adding extra comments in the registry for all programs makes it grow,
> > causing the PC to slow down and pushing the size closer to where the PC
> > won't boot.
>
> Just FMI, what size, precisely, would this be? I've had registries, on
> heavily loaded machines, well over 30Mb, sometimes considerably over. No
> problems booting.
Oh, he's just reiterating something he doesn't understand but heard once.
On Win2k, if the system hive becomes larger than 16MB, it will cause the
system to not boot. Since the system hive is it's own file and only supposed
to contain device configuration data, this is highly unlikely. There are no
such limits on the registry itself, just the system hive.
> >>> Opening a few tiny 1 - a few K text files verses opening 3 gigantic
> >>> binary files. The Unix way is much more efficient.
> >>
> >> The files are open by the OS all the time, therefore no extra resources
> >> are consumed for individual programs opening them.
> >
> > So instead of opening a 1k file to read the settings when I start an
> > application I have 3 files totalling over 10mb permanently in memory and
> > you still claim this doesn't make the PC run slower.
>
> They're not in memory; they're files, on the disk. You _open_ them, you
> don't _load them into memory_.
Actually, they're memory mapped files, so they're always open, but never
"loaded into memory". They're only accessed when they're paged in.
Chris Ahlstrom
> Chris Ahlstrom wrote:
>
>> After takin' a swig o' grog, Peter Köhlmann belched out this bit o'
>> wisdom:
>>
>>> Well, one of those "little" differences is that the config files are not
>>> held in memory, waiting to be corrupted there and then written back in
>>> that state.
>>
>> Sure they are. Linux keeps lots of stuff in memory as long as possible.
>> The difference is that the apps mostly read the file, and don't write to
>> it, and, should they write and save a corrupt file, it affects only
>> that app.
>>
>
> Thats essentially what I have written.
>
> Peter
We are in accord then. Happy 2002!
Chris
--
Living large and loving Linux!
Chris Ahlstrom
>> apt-get --purge remove appname
>
> Right, that's what I use - and it does _not_ remove those configration
> files; it leaves crud all about the place - just like apps do in the
> Windows registry.
That's not been my experience with dselect's purge.
Charlie Ebert
From Dselect
+ Will select and install software.
- minus That just removes software but not configuration files.
_ underscore That removes software AND configuration files.
And that is the way it has always worked.
--
Charlie
grom
<snip>
>>Pick one: either apps _should_ leave config settings behind when
>>uninstalled, so the point above is irrelevant, or they _shouldn't_ do
>>this, in which case virtually all Linux apps are broken in this regard,
>>at least by the default methods of uninstalling (rather than "purging").
>
> Nonsense, with Debian, all app files are removed and if any are left
> behind, apt-get tells you where they are, so you an manually remove them.
On mandrake, by default config files are renamed to conf.rpmsave.
<snip>
grom
<snip>
> Sorry, I missed it in the man pages; once a program is uninstalled, how
> does RPM manage to clean up after the program - i.e. delete all the
> leftover configuration files? Remember, we're talking about stuff left
> behind _after_ uninstalling, and how to purge that.
Rpm needs such an option (if not already there). However, the registry
leaving things behind slows the performance (slower access) and can make
the system more unstable. So you can not compare linux and windows. With
linux, nothing is affected (besides disk space) when files are left behind.
Can't you see windows registry is a flawed design. For crying out loud. I
know you like windows, but you must know this is flawed and could be
improved.
Adam Warner
>>> It has nothing to do with the registry. This statement is based on
>>> hundreds of hours going over detailed traces of Windows application
>>> launches during the development of a Windows application launch
>>> accelerator (http://www.webcelerator.com/products/superfassst/).
>>>
>>So care to tell us with *what* it has to do? With the primitive
>>filesystem MS choose to use perhaps?
>
> If you want to see what it has to do with, use strace on a Netscape
> launch on Linux. Netscape is slow on Linux for pretty much the same
> reason Windows programs are slow on Windows, it turns out.
>
> For some reasons I can't explain, I found this quite funny. :-)
So please enlighten me instead of being so cryptic. I just did an strace
on netscape and locked up my machine! (i.e. at least my keyboard and
mouse. No remote way to log in).
So what's the reason Tim?
Regards,
Adam
grom
<snip>
> I'm not saying the registry is good, but that if we're going to say "X is
> bad because of A,B and C" we need to be sure we're not shooting ourselves
> in the feet - say by suggesting that Windows lacks a "purge" tool to
> clean out the leftover dross after applications are uninstalled, while
> failing to note that Linux seems to lack the same thing.
>
> Yes, I'm sure _some_ Linuxes [distros] have tools for doing this, but it
> doesn't appear to be universal by any means.
Again the difference, is that leaving files behind in linux doesn't affect
anything but diskspace. In windows it slows performance and can make the
machine less stable.
Jim Richardson
> On Tue, 01 Jan 2002 03:59:52 -0800, TuxTrax wrote:
>
>> Shall we not compare apples and oranges here (this is not specifically
>> aimed at you Kelsey, but the conversation in general).
>>
>> The registry is not simply a configuration file. It is a binary data
>> base that windows uses to store every kind of data, critical, and not so
>> critical. It mixes third party entries with critical system entries, in
>> a most haphazard fashion.
>
> You mean like stuffing virtually everything other than per-user settings
> into /etc?
>
it's a good place for it. If I blow up the /etc/news/leafnode/ dir,
nothing happens to /etc/apache/.
> And yes, it is a binary database - of configuration information. While
> it's true it may lack a "purge" tool, the same seems to be true of Linux;
> at least, I haven't seen such a critter on my Mandrake box yet.
>
Haven't used rpm in a while, but:
1) What does rpm -e package *not* remove?
2) Having files in /etc/deadpackage doesn't slow down access to
/etc/activepackage. With the registry, it parses everything at least
once, dead packages clog up the registry and slow that down.
>> Windows is fairly ordered (usually) in it's
>> accesses, but any one can (and does) use the registry for everything
>> from variable storage to temporary hkey entries. That's *anyone* with a
>> capital *A* , and it includes visual basic programmers to professional
>> third party software producers.
>
> Right, but then again, they're _supposed_ to be using it; that's what
> it's for. However, note that not everyone has permissions to modify all
> areas of it; a non-privileged program can update per-user areas, say, but
> not the system areas. At least under NT and 2K - let's remember that
> "Windows" does include these.
It also includes Win9X which are the vast majority of windows installs
out there, and XP on which most people will run as admin thanks to some
rather screwy policies.
>
>
>> What makes the situation even worse is
>> the lack of a good install/deinstall tool, something microsoft has yet
>> to get right. All kinds of dead wood gets left in the registry after the
>> typical deinstall, and it's really cool because since it's not plain
>> text, plain english files with helpful comments, like you have in Linux,
>> it's *really* hard to keep this oh-so-important data base clean.
>
> Well, yeah, but again, when I noted that removing some application left
> behind a mess of dross under Linux, the response was that this was
> configuration information, so it _should_ be left behind.
Depends on where it was. If it was $USER info, yes it should be left
behind. Because you have no way of knowing if that user is accessing
that program on another machine via network. If it's stuff in /etc, then
dpkg will remove it, and AFAICR so did rpm -e.
>
> Pick one: either apps _should_ leave config settings behind when
> uninstalled, so the point above is irrelevant, or they _shouldn't_ do
> this, in which case virtually all Linux apps are broken in this regard,
> at least by the default methods of uninstalling (rather than "purging").
When you install appfoo under linux, it rarely puts anything in
/home/user, the user does that either manually, or when they run appfoo
and get some first time wizard thing.
Having a distinction between uninstall and purge is useful.
>
>> And now we come to the cleaning part of your comment. Yes, Linux does
>> have a cleaning tool for dynamic files: actually several. Scripting
>> languages like perl and python, or just some judicious CRON jobs will do
>> the trick.
>
> Fine; please point out where such a tool is installed, by default, on
> every Linux box, and the command-line I need to launch it. Would that be
> /usr/local/bin/confclean perhaps? Nope, no such animal. Oh, wait - you
> mean I can _write_ a program to clean up this way? Well, so what? I can
> do that in Windows, too. The bitch wasn't that you couldn't program a
> cleanup tool, but that Windows didn't _have_ a cleanup tool; by this
> argument, it follows that Linux must, perforce, have such a tool, no
> programming required; where is it?
what exactly does rpm -e fail to do?
>
>> This aside from the fact that there aren't that many
>> dynamically changing files that need cleaning to begin with, and the
>> fact that *none* of them are going to bring down the (already booted)
>> system single handedly like a corrupted registry *will*.
>
> No? Fine; corrupt your boot loader information. Corrupt your vmlinuz
> image. Whoops. Yes, corrupting some files under Windows will muck
> things up - so what? Linux just happens to have _different_ files with
> the same property. Big deal.
No, windows has the same analogs to bootloader, and kernel image, it
*also* has the registry. It's an additional single point failure.
>
>> Notice I said
>> *will* not *can*. Anyone who has used windows any length of time knows
>> the truth of this, and the pain of a corrupted registry/crapped out OS.
>
> Not really. Can't recall this happening on any of my boxes. Oh, I've
> hit the occasional corruption, sure, requiring a reboot after the
> automatic cleaning phase, but I can't recall having the system corrupted
> so badly it can't boot at all.
I have, and I rarely use windows.
>
> Well, not quite true, I do recall _a_ box where this had happened - but
> then again, the corruption was hardly limited to the registry, so
> singling it out is a bit disingenuous.
Since we have no knowledge of the event you mention, I don't think
anyone on cola *was* singleing it out.
Jim Richardson
Kelsey Bjarnason <kel...@xxspamxx.telus.net> wrote:
> On Tue, 01 Jan 2002 04:10:46 -0800, Tim Smith wrote:
>
>> Kelsey Bjarnason <kel...@xxspamxx.telus.net> wrote:
>>>So what's the Linux purge tool that cleans out all the leftover
>>>configuration files strewn about, while not deleting either
>>>configuration files for applications still installed, or any other
>>>files?
>>
>>
>> --Tim Smith
>>
>
> Really? Okay, let's see.
>
> rpm -Uvh gkrellm-themes[x].rmp
> rpm -Uvh gkrellm-plugins[x].rmp
>
> [run the program a while]
>
> rpm -e gkrellm-plugins
> rpm -e gkrellm-themes
> rpm -e gkrellm
>
> Hmm; ~/.gkrellm still exists. Now, let's see about that purge option,
> shall we?
>
> rpm -e --allfiles gkrellm
> Nope. --allfiless can only be specified during installation.
>
> rpm -e --allmatches gkrellm
> Nope: gkrellm not installed.
>
> Sorry, I missed it in the man pages; once a program is uninstalled, how
> does RPM manage to clean up after the program - i.e. delete all the
> leftover configuration files? Remember, we're talking about stuff left
> behind _after_ uninstalling, and how to purge that.
The only stuff left behind is in /home/user. I don't want the sysadmin
coming along and removing (for example) my .vimrc, since I use that
whilst accessing multiple machines over the net. Even if vim didn't
exist on my local machine, I need my .vimrc.
Jim Richardson
Kelsey Bjarnason <kel...@xxspamxx.telus.net> wrote:
> On Tue, 01 Jan 2002 08:09:31 -0800, Bob Hauck wrote:
>
>> On Tue, 01 Jan 2002 08:47:34 GMT, Kelsey Bjarnason
>> <kel...@xxspamxx.telus.net> wrote:
>>
>>> On Sun, 30 Dec 2001 09:46:50 -0800, Tsu Dho Nimh wrote:
>>
>>>> It is possible to clean this crap out ... but Windows does not have a
>>>> built-in "purge" tool.
>>>
>>> So what's the Linux purge tool that cleans out all the leftover
>>> configuration files strewn about, while not deleting either
>>> configuration files for applications still installed, or any other
>>> files?
>>
>> programs document the location of their config files in the man page.
>> This makes it pretty easy to remove them. But both major packaging
>> tools have commands for this:
>>
>> apt-get --purge remove appname
>> rpm -e appname
>>
>> These don't get per-user config files though, you'll have to get those
>> some other way. And I take no responsibility for broken packages that
>> forget where they installed the files.
>
> Right, that's what I use - and it does _not_ remove those configration
> files; it leaves crud all about the place - just like apps do in the
> Windows registry.
>
>
As I have said elsewhere, but you haven't seen yet cause it's too soon
for propagation, I don't *want* the sysadmin removing files in my
/home/user directory. I use them when ssh to other machines.
> I'm not saying the registry is good, but that if we're going to say "X is
> bad because of A,B and C" we need to be sure we're not shooting ourselves
> in the feet - say by suggesting that Windows lacks a "purge" tool to
> clean out the leftover dross after applications are uninstalled, while
> failing to note that Linux seems to lack the same thing.
The difference is the crap left in the registry slows the machine down,
the crap left in /home/user doesn't. The crap left in the registry
doesn't have an affect on remote systems, the crap in /home/user does.
>
> Yes, I'm sure _some_ Linuxes [distros] have tools for doing this, but it
> doesn't appear to be universal by any means.
Nothing in linux can be said to be universal beyond the kernel itself,
and not even all parts of that.
grom
> grom <gro...@optusnet.com.au> wrote in message
> news:<3c2fd13b$0$28865$afc3...@news.optusnet.com.au>...
>> Erik Funkenbusch wrote:
>>
>> > "Michael Vester" <mve...@v-wave.com> wrote in message
>> > news:a0o3nt$m887q$1...@ID-121900.news.dfncis.de...
>> >> Erik Funkenbusch wrote:
>> >>
>> >> > Grom, the vast majority of this article boils down to "I like text
>> >> > files better", not any inherantly flawed design of the registry.
>> >> >
>> >> > "grom" <gro...@optusnet.com.au> wrote in message
>> >> > news:3c2f17c7$0$26026
>> >> > > The fallacy is that registry data is accessed
>> >> > > by key name. There is little fundamental difference between
>> >> > > accessing a dozen different keys in a deeply nested registry tree
>> >> > > than there is a dozen text files in different directories with
>> >> > > different filenames.
>> >> >
>> >> > And here we have the rub. There is little fundamental difference
>> >> > between the
>> >> > two mechanisms. You have just admitted this, therefore any "serious
>> >> > flaw" in the registry must exist in configuration files too, or it
>> >> > would be a fundamental difference, would it not?
>> >>
>> >> That does not make any sense.
>> >
>> > If there is "little fundamental difference", how can they be
>> > fundamentally differnt?
>>
>> Because the registry stores everything in a couple of files.
>
> You do realize that your hard disk is the equivelant of a single
> database file, right? Perspective counts for a lot. If your hard
> disk becomes corrupted, you can lose your entire disk just as easily.
Yes. But windows is adds another to the count.
> You have not provided any valid reason as to why "a couple of files"
> is any worse than 1000 files. However, 1000 files have the obvious
> disadvantages of conflicting file formats, decreased efficiency (the
> files have to be read, then parsed, then converted to binary formats
> where applicable. The regitry has all that information in a useable
> form).
True about conflicting file formats. But the way people use the registry is
conflicting. Decreased efficiency? An application only reads what it needs.
Okay, in theory the binary format should work better. However, there are a
few flaws with the windows registry. When entries are deleted, a space is
left. Okay, you can defrag the registry. But in linux you don't have to
defrag the /etc directory. I'm not saying the linux is any better, it has
its flaws as well. I know I've been comparing the two, but the argument is
that the windows registry is flawed. Erik, you say this is not a design
flaw. Well I consider it two be. Depends on point of view of guess. The
seperate between design and implementation is black and white. You can we
not argue on this point. Lets just say the windows registry in its current
state is flawed.
>
>> >> > > If you don't
>> >> > > already know the key, i.e., have it stored somewhere, there is no
>> >> > > more direct way to it than a text file whose location you don't
>> >> > > know.
>> >> >
>> >> > No difference between the two in this manner either.
>> >>
>> >> Except text files can be very well documented. I like to add all sorts
>> >> of info to my configuration files. Makes them self-documenting.
>> >
>> > There is nothing stopping you from adding comments in the registry as
>> > well, just insert a few keys and put text comments in.
>>
>> And how many applications do this? You will bloat the registry even more.
>
> A "bloated registry" has not proven to be a problem with one
> exception, the system hive.
I know I have given a report on this. However, I and six other people I
know fix computers all the time for a living. There are solutions to
prevent this being a problem - Norton's WinDoctor. However, there is no
such tool included with windows. Microsoft do have RegClean but I (and
others) have found this to not be good enough.
>> > The files are open by the OS all the time, therefore no extra resources
>> > are consumed for individual programs opening them.
>>
>> So if your not using all the registry, the entire bloated registry is
>> still in memory.
>
> Maybe, maybe not. The registry is opened as a memory mapped file.
> This allows the OS to discard any part that hasn't been recently used
> and reload it on demand via the paged back storage mechanism. This is
> quite efficient.
Okay, but with seperate files you can be using less memory.
>> >> > Can you be any more contradictory, you just said a few paragraphs
>> >> > ago that it
>> >> > wasn't any easier to find text files you don't know. Further, the
>> >> > registry structure can be just as equally logically laid out.
>> >> >
>> >> Most /etc configuration names are the same as the program they
>> >> support.
>> >
>> > What happens if you have two programs with the same name?
>>
>> Erik, tell us why the registry is better then text config files. It
>> appears that you think they are equal (just a different implementation)
>> however, the registry has a few main problems. It is central (divided
>> into three files) and therefore a corrupt registry can make the system
>> unstable or unbootable. You say this is a myth. But it is not, I and six
>> other people that I know, that fix computers for a living know that the
>> registry can cause system problems.
>
> The number of files is an implementation detail, not a design one. It
> could be implemented as each major key being a unique file, or it
> could be all one file. We're talking about *DESIGN* flaws, not
> implementation (not that I'm saying it *IS* a flaw at all, but even if
> you could come up with a valid reason for being a flaw, this it
> wouldn't have anything to do with the registry's design).
>
> Next, you are thinking of this as a binary file in the way that
> dumping objects from memory to disk is a binary file. That's not
> true. It's implemented as a linked list structure and is very
> resistant to corrupting the entire registry if one portion is
> corrupted. A simple repair (much like an fsck) will almost always fix
> it, though like fsck, it's not foolproof.
Erik, please. You underestimate my knowledge of programming. I am in my
last year of a Computer Science degree. I currently have a Grade Point
Average of 6 (7 being the highest). Please, do not try and undervalue my
opinion because you have 10 years of experience.
> Having said that, the only time i've ever seen a registry corruption
> is when there is a disk error, in which case you could lose
> *anything*.
See earlier comments.
>> >> > While true, this is actually a negative for text files. First, you
>> >> > need to learn lots of different utilities with differen syntax, then
>> >> > you need to write code for every app you use to parse and process
>> >> > those files, since text files often have very different formats.
>> >> >
>> >> There is only one format for a configuration file that I can see. A
>> >> line of text with a <LF>. Comments are #. Any text editor can edit
>> >> them.
>> >
>> > There are lots of formats. Do comments start with #'s or ;'s? Hell,
>> > gs.fontmap uses %'s for comments.
>>
>> If you wish, you can change this since it is OSS. You can't with
>> commerical programs.
>
> Oh, right... conveniently forgetting that OSS software is available
> for Windows.
Know I wasn't. You have pointed out a problem with the linux way of things.
I'm never said linux was perfect. I'm just trying to show you that the
windows way isn't the best. I would very much like to see Windows improve.
I want to see a competitive market for OSes.
>> > does the format have a name = option format, or is it just a line item?
>> > Is it field oriented (like, say, hosts) or are there commands issued
>> > per line? etc...
>>
>> Config files are usually self-documented.
>
> I find more often than not that they aren't. A quick perusal of /etc
> finds dozens of files without any kind of comments at all.
Okay, linux has faults. But I point out a flaw in windows and you dismiss
it.
>> >> > > There isn't anything that can't be done,
>> >> > > either manually or automatically, with scripting in the way of
>> >> > > locating, comparing or changing text files using general purpose
>> >> > > text editing and manipulation utilities. Text files can have user
>> >> > > friendly, graphical front ends more easily than proprietary binary
>> >> > > files. Text file formats normally allow as much internal
>> >> > > documentation as the developers care to provide.
>> >> >
>> >> > Bullshit, there is no reason that text files can have GUI front ends
>> >> > easier
>> >> > than with registry front-ends. In fact, it's easier to do the
>> >> > registry front-end because registry access always uses the same
>> >> > API's no matter what the configuration, while text files have broad
>> >> > and varying formats that need to be understood by the front-end.
>> >>
>> >> With any amount of experience, one quickly discards the gui front end
>> >> and edits the text file directly.
>> >
>> > That's not the point, the criticism was talking about how poor the GUI
>> > front ends in windows are.
>>
>> Typically of erik. You bring up a valid point and he says "That's not the
>> point"
>
> It may be a valid point for another argument. For this argument, it's
> irrelevant and merely changing the subject.
Yes it is relevant. Instead of trying to debate the issue, you ignore it
and then say I haven't provided a valid arguement.
>> >> > The problem then becomes, where is it stored? The #1 problem with
>> >> > .ini files was that the program often got confused about where they
>> >> > were located, and if
>> >> > two programs used the same named file, they corrupted each other.
>> >> > While, the name problem is possible in the registry as well, it's
>> >> > unlikely because apps are supposed to store their config files in
>> >> > sub-sections of their company name or some other unique name related
>> >> > to their product and then under app name giving two unique keys
>> >> > which is unlikely to ever be the same (in fact, i've never heard of
>> >> > any app using this convention which ever had a problem).
>> >>
>> >> All my configuration files are in /etc. Managing names can be done
>> >> just like you state with registry pairs.
>> >
>> > That depends on the distro. On my debian system the config files for
>> > grub are in /boot/grub.
>>
>> Again, this can be changed.
>
> That doesn't change the fact that you argued that all configuration
> files are in /etc.
>
>> >> On my Windows machine, the registry occupies over 5 megabytes. On my
>> >> main Linux workstation, /etc occupies just over 3 megabytes. My Linux
>> >> has many
>> >> more installed applications. And /etc has all the scripts for
>> >> launching programs. Of course, as you point out later, much of /etc is
>> >> not even used.
>> >
>> > What does that have to do with what I was saying?
>>
>> The registry is bloated, and continues to get bloated because of its
>> design. Can't you see erik, that this is a design flaw.
>
> No more so than an /etc directory that never gets cleaned out.
There is a different here. The /etc directory doesn't need to be cleaned
out. The registry however does. So stop bringing this up.
>> >> The reigistry is always growing. A small application still has to open
>> >> a gigantic file just to access a few bytes of information.
>> >
>> > No, the file is already open. And typically this is a one-time event.
>>
>> See earlier comment.
>
> And is just as wrong. The registry can be cleaned out as well as /etc
> can.
>
>> >> > > Limited Registry Tools
>> >> > > -----------------------
>> >> > > Microsoft provides tools to maintain only parts of the registry.
>> >> >
>> >> > What is meant is that MS provides limited GUI front-ends. The same
>> >> > is true of Unix based config files.
>> >> >
>> >> > > IIS 3 was a
>> >> > > good example where there were many more registry entries than
>> >> > > there were options in the Internet Manager.
>> >> >
>> >> > And how many options are available in GUI front-ends for apache?
>> >> >
>> >> Hardly a great demand for a gui front end for Apache. It would only
>> >> get iin the way.
>> >
>> > That doesn't change the fact that the argument is hypocritical.
>>
>> No it isn't. The difference being that the registry is a binary format.
>
> So what? If you want to argue front-ends, then be consistent. If
> not, then be consistent in that as well.
What? Don't understand you on that.
>> >> > > It also provides two limited editors as the
>> >> > > only general purpose access to the registry and says it's can't be
>> >> > > responsible if these tools are used, even though they are often
>> >> > > the only way to maintain parts of the registry.
>> >> >
>> >> > "limited" editors? They allow you to edit everything, how is that
>> >> > limited?
>> >> >
>> >> And one mistake, you render your Windows machine unbootable.
>> >
>> > Make one mistake in your /etc folder, and you can do the same.
>>
>> True. But there are more possiblities with the registry. Editing file sin
>> /etc does not affect other files in /etc. Whereas in the registry it can.
>
> Nor does editing a key in one part of the registry effect another
> part. You seem to be under the mistkaken impression that editing one
> part of the registry can change other parts of the registry. The
> warnings about editing the registry are that you can change a value
> which will cause your system to no longer boot, much like haphazardly
> editing files in /etc.
I didn't say changing one part changes another. Please re-read what I have
said.
>> >> > > There are some additional tools in
>> >> > > the Resource kit but their value is limited. If a registry key
>> >> > > contains spaces, and many do, the limitations of the command line
>> >> > > interface may provide no way to pass the necessary arguments to
>> >> > > the utility. Correctly passing the arguments may require the
>> >> > > equivalent of nested or escaped quotes which the NT command prompt
>> >> > > can't do.
>> >> >
>> >> > This is simply From the command line there are many options,
>> >> > including exporting a sub-key to text and editing it with any
>> >> > command line editor then reimporting it.
>> >>
>> >> I thought the great reason to use the registry was to use a pretty
>> >> gui. You still have to edit it with a text editor?
>> >
>> > No. The reason to use the registry is to have a central place for
>> > configuration. The context here is command line editing.
>>
>> Which is a design flaw. Unrelated settings can affect each other.
>
> That's not true.
I have already point out that it is. But you chose to believe this is a
myth.
>> >> > > The registry has no equivalent of create, modify or access times
>> >> > > so it's not possible to locate recently changed registry entries
>> >> > > or to relate modification times to the onset of a problem.
>> >> >
>> >> > This is about the only legitimate claim i've read so far. Yes, this
>> >> > is true.
>> >> >
>> >> Amazing!!! Erik agreed. I thought the registry was perfect.
>> >
>> > I didn't say that, I said it wasn't "fundamentally flawed".
>>
>> Erik, I'm don't think everything in windows is wrong. But the registry is
>> a design mistake. It is from the windows 3.1 days. Although you say there
>> is "little fundamental difference" the differences between having config
>> files in /etc and the registry are major differences. The only benefit I
>> can see from the registry, is that you can make it more difficult
>> (although not impossible) to pirate software.
>
> Your argument boils down to "I don't like it" and rumors and myths.
> You have presented no technical arguments which aren't equally as
> valid for the way things are done in Linux, and you have presented
> many arguments which are completely irrelevant to the design of the
> registry.
Erik, I have. You are starting to piss me off.
> It's fine that you don't like it, but to call it a flawed design
> without even a valid argument is just stupid.
You just say "that's not the point" or "completely irrelevant". Not my
fault.
> If you say that registry bloat slows down windows, document it.
> Provide evidence that this is the case. Take a 'bloated registry' and
> time various things. Doing *NOTHING* else, clean it up, optimize it,
> then re-time it. If you can document this, then I might consider that
> you have an argument (but I know this will not happen).
It will not happen, because I know it is true and it is obvious you are
just a troll. Please go else where. Why don't you document it, and prove us
wrong. You are the one trolling, and this is COLA - so you should prove
that windows is as good as you say it is.
> If you say that a single flipped bit in the registry will hopelessly
> lose all data, go ahead and edit the registry and corrupt a single bit
> with a disk editor, then verify that registry repair doesn't fix it.
What registry repair?
>> >> More like rendering your computer unbootable. With many text based
>> >> configuration files, a screwup in one will not affect others.
>> >
>> > Really, so if you screwup rc, or inittab or any of a number of other
>> > critical
>> > files, your system will still boot just perfectly in all cases? Just
>> > like with /etc, there are critical places and non-critical places.
>>
>> Erik you have just point out a problem with the registry. Critical and
>> non-critical belong together in the registry. Whereas, in /etc each is
>> seperate.
>
> You are still confused into thinking the registry is a single file
> that one wrong bit can hopelessly ruin. that's simply not the case.
Know I don't. I work on windows machines. I understand this. Is there any
point in trying to reason with you.
>> >> > > It is usually easier to fix a corrupt registry by reinstalling.
>> >> >
>> >> > One could say the same thing about a complicated config file.
>> >> >
>> >> I make a backup of a configuration file before I edit it. Any problems
>> >> and I can easily return to a functioning config.
>> >
>> > So backup your registry. Big deal.
>>
>> The problem is though, the registry can become corrupt without you
>> editing it.
>
> Only if *SOMETHING* edits it or your disk is bad. Applications can
> edit config files /etc and corrupt them as well.
>
>> >> > > If the registry is improperly edited, it can cause severe
>> >> > > problems, which could lead to loss of data.
>> >> >
>> >> > Duh, that's why it's called "editing". The same is true of config
>> >> > files.
>> >> >
>> >> Yet one mistake in "editing" the register will render your computer
>> >> unbootable. From personal experience of course. I have yet to render
>> >> a
>> >> Linux box unbootable from mistakes in editing configuration files. I
>> >> am sure that if I mucked up fstab, I would not have access to my
>> >> partitions on the next very infrequent reboot.
>> >
>> > So you admit you were wrong them when you claimed editing files in etc
>> > wouldn't make your system unbootable.
>>
>> However, this can be fixed by using a rescue disk. With windows how do
>> you edit the registry if you can not boot windows. (and with NT - that
>> includes w2k and XP - you can't use dos if you have NTFS partitions).
>
> You boot to a recovery console using your CD. Or, you boot with DOS
> and use something like NtfsDOS. Your argument is based on things you
> *THINK* are true, but aren't.
Getting up the recovery console isn't that easy for the average windows
user (if at all possible).
>> > It's all a frame of mind.
>>
>> Erik, I don't think there is any point in trying to make you see. You
>> think windows has no design flaws. I don't really care that you feel this
>> way, but what I care about is you making other people believe this crap.
>> Over time, the registry can slow the machine down. Period. It is not a
>> myth. You realise the registry needs to be defragged and cleanup.
>>
>> What do you do for a living? What qualifications do you have?
>
<snip out crap>
Charlie Ebert
<SNIP>
The Windows Registry is an open sewer where
third party manufacturers making Win products
come to take their POOP!
And when these hardware miracles of modern
science die, the Windows Registry is their
favorite burial ground.
And thus the religion of eternal Win failure
is started. And this is why we were given
RegEdit, so that we might scrape thru the
remains of the dead so that we might animate
life into our new Win products.
But as our Quicky Mart USA sales clerks
would say, "sir, you will probably have
to just wipe the drive off and re-install
Windows to get this new jackie-bob win
device to work. I've seen this before
and that is my recommendation"
Ah, enough said for 3rd party drivers.
--
Charlie
grom
> grom <gro...@optusnet.com.au> wrote in message
> news:<3c2fc942$0$28920$afc3...@news.optusnet.com.au>...
>> Erik Funkenbusch wrote:
>>
>> > Grom, the vast majority of this article boils down to "I like text
>> > files better", not any inherantly flawed design of the registry.
>> >
>> > "grom" <gro...@optusnet.com.au> wrote in message news:3c2f17c7$0$26026
>> >> The fallacy is that registry data is accessed
>> >> by key name. There is little fundamental difference between accessing
>> >> a dozen different keys in a deeply nested registry tree than there is
>> >> a dozen text files in different directories with different filenames.
>> >
>> > And here we have the rub. There is little fundamental difference
>> > between
>> > the two mechanisms. You have just admitted this, therefore any
>> > "serious flaw" in the registry must exist in configuration files too,
>> > or it would be a fundamental difference, would it not?
>>
>> No, because the registry has furhter disadvantages (such as the entire
>> system relies on two files for the registry) without any benefits.
>
> This is an implementation detail. In Win9x, yeah.. 2 files. In NT,
> there are several (5 or 6). This is an implementation detail, not a
> design detail.
Erik, that doesn't change its disadvantages.
>> >> This is confirmed by the fact that Windows
>> >> systems slow with age as software is added; UNIX systems do not slow
>> >> with age due to software installs. Further, if the directory structure
>> >> is logical, you can often find the text configuration file you need,
>> >> without knowing before hand what its named or where it's located.
>> >> Without an exact key fragment or data, this is not possible in the
>> >> registry.
>> >
>> > Can you be any more contradictory, you just said a few paragraphs ago
>> > that
>> > it wasn't any easier to find text files you don't know. Further, the
>> > registry structure can be just as equally logically laid out.
>>
>> You can do pattern matching, unlike the registry where you need to know
>> the key.
>
> Regedit has a search function. It's basic, true.. but I don't really
> know that many people that truely use regular expression in any but
> basic form. If you're so worried, you can write your own regular
> expression search utility for it.
Oh, you are comparing people that can use computers (linux users) to a
windows user. ROTFLMAO.
>> >> A major difference between the registry and text configuration files,
>> >> is that the registry is a proprietary binary format with only two
>> >> widely available.general purpose utilities, for it and a number of
>> >> custom GUI front ends, each of which accesses specific limited
>> >> sections of the registry.
>> >
>> > Doesn't sound any different between text files in /etc or ~ and the
>> > various GUI front-ends being developed fro Linux (YaST2, DrakConfig (or
>> > whatever it's called..), the various Gnome and KDE config tools, etc...
>>
>> What? Because it's the config files are text, anybody can write there own
>> front end. You can even use your favourite editor.
>
> Yeah? Anyone can write their own front-end to the registry as well.
> The registry is accessed through very well known API's.
You can't use your favourite editor on the registry without exporting it to
text and them re-importing it.
>> >> There are more utilities and tools to manipulate text files than
>> >> any other storage format on earth.
>> >
>> > While true, this is actually a negative for text files. First, you
>> > need to learn lots of different utilities with differen syntax, then
>> > you need to write code for every app you use to parse and process those
>> > files, since text files often have very different formats.
>>
>> No you don't. You can chose only one. The text files in UNIX have a very
>> similar format. Sorry erik, wrong again.
>
> Bullshit. I can pull any 10 files at random, and almost all will have
> different formats. Look at XF86Config versus Hosts versus httpd.conf
> versus sendmail's configs versus smb. They all have very different
> formats.
Again, some aplies to the registry. Your point is?
>> >> There isn't anything that can't be done,
>> >> either manually or automatically, with scripting in the way of
>> >> locating, comparing or changing text files using general purpose text
>> >> editing and manipulation utilities. Text files can have user friendly,
>> >> graphical front ends more easily than proprietary binary files. Text
>> >> file formats normally allow as much internal documentation as the
>> >> developers care to provide.
>> >
>> > Bullshit, there is no reason that text files can have GUI front ends
>> > easier than with registry front-ends. In fact, it's easier to do the
>> > registry front-end because registry access always uses the same API's
>> > no matter what the configuration, while text files have broad and
>> > varying formats that need to be understood by the front-end.
>>
>> Besides the fact the registry is a proprietary binary format.
>
> Which is accessed with well-known API functions. You don't have to
> know the format of the file to access the data within it, unlike with
> unix config files.
Yeah right.
>> >> The .INI format used in pre Windows 95 versions, had named areas or
>> >> stanzas with an open ended number of key value pairs following. Add
>> >> intelligent file names to a logical directory structure and there
>> >> isn't any data that can't be stored and in a logical relationship to
>> >> the programs that use the data.
>> >
>> > There is no fundamental difference between the data associations used
>> > in
>> > the registry or .ini files. They each use a "section" (key) name and
>> > key/value pairs.
>>
>> No. But there is a difference. The .INI doesn't have everything in a
>> central location.
>
> If they're all in the same directory, how is that any different?
Having everything in a directory is completely different to having it all
in the same file (or 5 - doesn't change the fact the registry acts as one
file).
>> >> If the
>> >> configuration data is program specific, it can go with the program. If
>> >> it's system wide, it can be stored in a standard system directory, in
>> >> which key filenames and stanzas within files would be reserved.
>> >
>> > The problem then becomes, where is it stored? The #1 problem with .ini
>> > files was that the program often got confused about where they were
>> > located, and if
>> > two programs used the same named file, they corrupted each other.
>> > While, the name problem is possible in the registry as well, it's
>> > unlikely because apps are supposed to store their config files in
>> > sub-sections of their company name or some other unique name related to
>> > their product and then under app name giving two unique keys which is
>> > unlikely to ever be the same (in fact, i've never heard of any app
>> > using this convention which ever had a problem).
>>
>> What about system wide settings?
>
> What about them? System wide settings are in the HKEY_LOCAL_MACHINE
> hive, individual user settings are in HKEY_CURRENT_USER.
You are truely an idiot. If an application adds a system wide setting
another application can overwrite that setting and then you have problems.
>> >> With files, programs read what they need and not much more, if the
>> >> files are well planned.
>> >
>> > Of course the planning of the files has no control over how the use has
>> > edited them.
>>
>> What are you saying?
>
> What were you saying? You claimed that if the files were "planned"
> right, you didn't need to read much. My point was that the end user
> can completely change the files making any "planning" moot.
Yes, same for the registry. The superuser can also render the system
corrupt.
>> >> The registry grows over the life of
>> >> system and systems get slower as a result, because on Windows systems,
>> >> virtually all programs need to access the registry. Few if any
>> >> uninstall programs, cleanup everything that was installed. When an
>> >> application lacks an uninstall program or either the install or
>> >> uninstall program has a bug, there is a increased chance some or all
>> >> the registry entries will get left behind.
>> >
>> > This is a myth. When win9x systems start slowing down, it's not
>> > because
>> > of the registry. It's because of things like disk fragmentation, and
>> > quite often large temp file or cache directories (with the internet
>> > explorer integrated shells, the cache directories are searched for
>> > almost
>> > any operation, which makes things appear to slow down significantly.
>> > Try clearing out your caches and temp directories regularly and notice
>> > the speed improvements).
>>
>> ROTFLMAO. Yeah right!
>
> Well rebutted technical argument.
Erik, although you are a software developer you have no idea. The registry
needs to be defragged.
>> >> Limited Registry Tools
>> >> -----------------------
>> >> Microsoft provides tools to maintain only parts of the registry.
>> >
>> > What is meant is that MS provides limited GUI front-ends. The same is
>> > true of Unix based config files.
>>
>> You can uses any editor to edit Unix config files.
>
> You can also use any editor to edit the registry, simply export the
> relevant sections (or the whole thing if you like), edit it in your
> favorite editor, then reimport.
Yes ladies and gentlemen. Instead of being able to edit the config files
directly you can export it to text, and still not be able to edit it. What
a great feature!
>> >> IIS 3 was a
>> >> good example where there were many more registry entries than there
>> >> were options in the Internet Manager.
>> >
>> > And how many options are available in GUI front-ends for apache?
>>
>> It is difficult (if not impossible) to edit the registry directly and
>> change the config for an application. Whereas the text config files for
>> apache are commented and very easy to understand.
>
> What do you mean by "directly"? If you mean outside of the OS
> provided API's, then you're right. But that's a good thing, since it
> keeps the data in a consistent format.
No it doesn't.
> If you mean "outside of a GUI front-end" then you're completely wrong.
> While the text files for apache are *somewhat* commented, there are
> dozens of config files without even a single comment within them.
Erik, Erik. I pity you.
>> >> It also provides two limited editors as the
>> >> only general purpose access to the registry and says it's can't be
>> >> responsible if these tools are used, even though they are often the
>> >> only way to maintain parts of the registry.
>> >
>> > "limited" editors? They allow you to edit everything, how is that
>> > limited?
>>
>> Search function is crap.
>
> But workable. And if you're so annoyed, just write your own search
> utility.
That's good. Not. It is not workable. It is not usefull. The search
function in regedit is pointless.
>> >> The registry has no equivalent of create, modify or access times so
>> >> it's not possible to locate recently changed registry entries or to
>> >> relate modification times to the onset of a problem.
>> >
>> > This is about the only legitimate claim i've read so far. Yes, this is
>> > true.
>>
>> So its the only claim that you wish to agree with.
>
> It is the only claim that I *DO* agree with.
>
>> >> Keys in the registry have security permissions that are very similar
>> >> to directory permissions. Anyone who has seriously tightened file and
>> >> directory security, on almost any kind of server, knows that this
>> >> almost invariably breaks some user's access to some applications. With
>> >> files, it's generally pretty straightforward to figure out who needs
>> >> update access, who needs read access and who needs no access. With the
>> >> registry, since all access is programmatic, behind the scenes, and not
>> >> documented, it's almost impossible to know who needs access to what
>> >> let alone what level of access. I've never needed a guide to tell me
>> >> how to tighten file security, but any independent attempt to tighten
>> >> registry security without clear guidelines as to what should and
>> >> should not be changed is very likely to lead to serious trouble.
>> >> Permission changes can be at the current level or apply to sub keys.
>> >> The registry is quite deep in some areas and often huge in its
>> >> entirety. Changing individual entries, except to limit access to known
>> >> specific keys for specific security related results won't do much and
>> >> changing sub keys will make changes several levels down that you can
>> >> only hope need to be the same as the parent key's permissions.
>> >
>> > I'm just not even sure who this makes sense. I simply don't understand
>> > how someone can claim that you can know what permissions to apply to
>> > files, but not know what permissions to apply to registry keys. As
>> > already admitted, they are functionally the same thing.
>>
>> Erik you are so blinded.
>
> Another well reasoned, technical argument.
>
> How can you claim you know what permissions apply to files, but don't
> know what permissions apply to the registry?
Erik, and you have such well reasoned, technical arguments. You are a
troll. I have made a more well reasoned, technical argument then any of the
wintrolls - including you.
>> >> Registry Security and Installs
>> >> --------------------------------
>> >> The worst problem with the registry is that is a single structure, to
>> >> which administrators normally have full access.
>> >
>> > And administrators of unix systems don't have full access to /etc?
>>
>> The point comes with the next sentence.
>
> Does it? It doesn't appear to.
That is because you are a troll. Blinded by a monopoly.
>> >> Most software installs need to be run as an administrator.
>>
>> That is why it is a problem in windows.
>
> This is not the case with "most" software. It's the case with *SOME*
> software.
>> > As do most unix installs, since you need write access to /etc to put
>> > your
>> > config files into it. Yes, it's usually possible to install something
>> > into your own home directory, but then the same is usually true of apps
>> > in
>> > Windows as well. As with unix, whole classes of apps need
>> > administrator access to function on either system.
>>
>> A user can install to there own directory. You fool erik.
>
> Perhaps, but how do you run apache without administrator access? You
> can't open port 80 without admin access. How do you run sendmail or
> an ftp daemon? Further, installing those programs to your own
> directory only is problematic and requires a great deal of tweaking.
Apache runs as its own user. What are you talking about?
>> >> Thus any bug in a software install program can
>> >> result in corruption in almost any part of the registry. Unlike file
>> >> and directory related programs, where administrators generally have a
>> >> pretty good idea what will and will not be affected, there is no way
>> >> to know what registry keys any install program will access
>> >> deliberately or unintentionally change. I'm convinced that this is the
>> >> primary source of bizarre install related results.
>> >
>> > If you don't know what sections of the registry will be effected, what
>> > makes you think you'll know what will be effected the other way?
>> > Again, it's already been admitted that they're functionally the same.
>>
>> See earlier statements.
>
> Which haven't answered the question.
Yeah they have. You are just trolling.
>> >> By definition, one of the specific functions of an install program, is
>> >> to update the registry. Programmers develop install programs like any
>> >> others, make mistakes, and get poor specifications. There are
>> >> important differences though. The registry is probably the most system
>> >> specific component on any Windows system, as every system variation is
>> >> reflected in it, somewhere, thus making it one of the hardest parts to
>> >> properly test. All changes are normally made with the full authority
>> >> of the system.
>> >
>> > Not even remotely true. For instance, all user specific settings are
>> > stored in the users registry hive (and contrary to what is stated here,
>> > the registry is *NOT* one big database, it's actually stored in several
>> > sub-files, some of
>> > which are loaded specifically for each and every user). Of course a
>> > user has direct access to their own hive, and applications running run
>> > in the users security context.
>>
>> It doesn't work all that well. Again there are many programs (many
>> microsoft ones included) that can only be installed as administrator.
>
> System utilities generally need administrator access. But no,
> actually, you don't need administrator access to install, you only
> need install accesss. That's one of the things about the new windows
> installer created for Windows 2000 (and installable on 9x) which most
> programs use these days. This prevents users from installing things
> if you don't want them to. How do you prevent someone from installing
> something in Unix?
Why do you want to prevent this in Unix? You don't because it doesn't have
a crap registry.
>> >> Any misunderstanding the programmer has regarding the use of system
>> >> calls related to registry updates, could result in unpredictable
>> >> consequences.
>> >
>> > And what about misunderstandings in the way to use text processing
>> > tools?
>>
>> It is much easier to recover in a UNIX system. Fucking the registry,
>> causes a person to reinstall in almost all cases.
>
> Now this is just complete and utter horseshit. First, you can recover
> just as easily. Backup tools for the registry are available and come
> with the OS. If you choose not to back it up, that's as bad as not
> backing up your etc files. Second, I can go in and change 100 random
> entries and probably never make the system unbootable. 1000 random
> entries and it *MIGHT* make the system unbootable.
You can recover easier because you only have to work with the portion you
change. The problem with you saying to backup the registry is that the
registry can changed by running applications.
> You seem to think that the registry is some kind of card house that if
> you change one thing it effects everything else. That's simply not
> the case.
>> >> Whatever the programmer believes his program needs to or update will
>> >> get updated except when the programmer makes a mistake.
>> >
>> > Same is true of text files.
>> >
>> >> Because installs execute with administrator level access,
>> >
>> > As they almost always do in Unix/Linx.
>>
>> Ummm. One can install to there home directory.
>
> One *CAN*, but rpm's are almost always setup to install config files
> to /etc.
You can redirect them. It is very simple to install to one's home directory.
>> >> then whatever the install program is built
>> >> to do, whether it is intentional or accidental, will be done.
>> >
>> > Ditto.
>>
>> Linux uses package managers which is much better then having an install
>> exe for each program.
>
> And they can't decide exactly which package manager to use. Each
> distro can, and usually is different.
>> >> When you
>> >> install software, you are normally asked what directory to put it in,
>> >> usually what program group to put it in and sometimes whether or not
>> >> to create a desktop icon. You're never asked about registry updates.
>> >> When you install software you implicitly trust the install programmer
>> >> as well as the company that employs him or her and hopefully tests the
>> >> installs well. When you install Windows software, someone else is
>> >> making critical system choices for you, without your knowledge or
>> >> consent.
>> >
>> > This has absolutely nothing to do with the registry, it has to do with
>> > how
>> > installation code is written. I've seen plenty of script based
>> > installs on Windows for instance.
>>
>> Yes, if they install program isn't any good, and can leave you with a
>> corrupt registry. Which leaves you with a corrupt system.
>
> You are confusing two concepts. A corrupted registry, and corrupted
> data IN that registry. If the registry itself is corrupted, then that
> is like your disk being corrupted. If the data is corrupted, that's
> like random stuff in your given configuration file.
No. Erik I'm have already point this out.
> Most of the time, if you were to randomly corrupt the data, it's not
> going to do anything but make whatever program is using that data to
> not work or work incorrectly. You have to specifically go into the
> system hives and start randomly changing stuff to effect how the
> system boots.
Again you are wrong.
>> >> When software is installed on UNIX and configuration files specific to
>> >> that software are created or updated, as opposed to a centrally
>> >> shared, system-wide registry, the programmer pretty much has to have
>> >> malicious intent to damage anything but the software being installed.
>> >> Also, most UNIX installs are done with scripts that the administrator
>> >> can read if they wish, as opposed to binary executables, which for all
>> >> practical purposes, cannot be read.
>> >
>> > Again, nothing to do with the registry. This is simply a philisophical
>> > difference in the way install programs are written. You could do
>> > precisely the same for Unix/Linux, or you could create scripts on
>> > Windows.
>>
>> See above.
>
> And still not addressed. It has nothing to do with the registry or
> how it's designed. Can't you admit that?
Yes it has all to do with it. You are just trolling.
>> >> Further, UNIX install programs that find missing shared
>> >> libraries or other perquisite parts, inform the administrator or the
>> >> missing components, but allow the administrator to locate and install
>> >> the prerequisites. Windows programs that require shared functions not
>> >> automatically provided with the OS, automatically provide them,
>> >> in whatever version the install vendor thinks is appropriate, creating
>> >> DLL hell. With the registry, any programming mistakes can cause
>> >> serious unintended damage. The surprise is not that some installs go
>> >> bad, but that the large majority actually work.
>> >
>> > This is no longer the case, since Windows provides side-by side DLL
>> > installs and windows file protection. And again, it has nothing to do
>> > with the registry.
>>
>> No, but it is a futher problem (and it still applies, although it has
>> improved slighty)
>
> And still has nothing to do with the registry.
That is true. But this is COLA and it is another problem with windows.
<snip> Why go on? Erik is a troll, and instead of debating says "that's not
the point" "not relevant" "has nothing to do with it"
Yes ladies and gentlemen, that is what erik fud is.
grom
> GreyCloud <mi...@cumulus.com> wrote:
>>> This is complete bullshit, they are no more resource intensive than
>>> parsing large text files with many configuration items.
>>>
>>
>>Yeah, that's right Ewic, make a fool out of yourself. A lot of vendor
>>software adds their crap to the registry, and if you add enough software
>>to the registry, then you end up waiting longer for the vendor program to
>>startup and find its special keys and variables inside this bloated
>>registry.
>
> As opposed to keeping each program's configuration in its own file, so
> that when you add enough software, then you end up waiting longer and
> longer for programs to start up because the filesystem has slowed down
> because you've got a zillion things in /etc?
>
> The registry is stored as a tree, and exhibits size vs. speed behavior
> similar to a filesystem (which is no surprise, since it basically *is*
> a filesystem, that just happens to be implemented inside other files,
> rather than directly on disk).
>
> --Tim Smith
One problem. The registry also has the filesystem problems. So your point.