Linux-Development-Sys Digest #882, Volume #6 Fri, 25 Jun 99 07:14:16 EDT
Contents:
Re: Why we are still holding on to X Windows (Neal Tucker)
Re: Why not C++ ("Thomas Steffen")
Re: Configuration as Database (was Re: TAO: the ultimate OS) (Terry Murphy)
Re: TAO: the ultimate OS (Vladimir Z. Nuri)
Re: TAPOs: configurations (Alexander Viro)
Re: Why not C++ (Jan Panteltje)
Re: TAO: the ultimate OS (Stefaan A Eeckels)
Re: Configuration as Database (was Re: TAO: the ultimate OS) (Stefaan A Eeckels)
Re: Configuration as Database (was Re: TAO: the ultimate OS) (Stefaan A Eeckels)
Re: TAO: the ultimate OS (Stefaan A Eeckels)
Re: TAPOs: configurations (Paolo Torelli)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Neal Tucker)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 24 Jun 1999 23:35:34 -0700
Marcus Sundberg <[EMAIL PROTECTED]> wrote:
>
>There exists no software named "X Windows".
Oh yeah, it's "The X Windowing System." Just like there's no
software named "Win95" -- it's "Windows 95". Just like there's
no such thing as "Cheez-its" -- they're "Cheez-it snack crackers".
(i.e. who cares ... people call it what is convenient, and as
long as it's not hindering discussion, it's counterproductive
to bitch and moan about it)
My two cents regarding the sound stuff: the sound support should
absolutely not be part of a window manager, as someone suggested.
The window manager's job is to allow the user to move windows
around. If the window manager wants to make noises, fine (not on
my system, though), but it should call the sound system. Apps
should not have to call on the window manager to make noise.
That said, sound support should definitely be part of the window
system (i.e. X), in my opinion, because, as someone else pointed
out, it is part of the user interface. Sound should be tied to a
"console" in the sense of a set of input and output devices
assigned to a user, because when an app running on :0 (to use X
terminology) makes a noise, the user staring at :0 should hear
it. It should not be up to the application to figure out which
set of speakers is associated with which keyboard. After all,
you wouldn't expect the application to have to figure out which
keyboard is associated with which display -- it's up to the
user interface toolkit.
I am astounded that I even read any of this thread, let alone
contributed.
-Neal Tucker
--
___________________________________________________
"You've completely missed the point." - Dean Stark
------------------------------
From: "Thomas Steffen" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 25 Jun 1999 09:46:19 +0200
[EMAIL PROTECTED] (Bruce Hoult) writes:
> You might want to check out Dylan. It's much simpler and easier to learn
> than C++, and yet is more powerful than C++ -- for example Dylan supports
> dynamic dispatch on more than just one argument of a function, plus Dylan
> has things such as lexically scoped local functions, anonymous functions,
> and closures,
though i'm not sure it supports closures the way i would like g++ to
do... anyway, Dylan looks like a very potent language. however, until
a safe compiler base is available (which means gcc basically), i am
unlikely to switch. and C++ seems to be there to stay (as unfortunate
as it may be for better languages).
"Thomas Steffen" <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Terry Murphy)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Configuration as Database (was Re: TAO: the ultimate OS)
Date: 25 Jun 1999 06:18:56 GMT
In article <[EMAIL PROTECTED]>,
Christopher B. Browne <[EMAIL PROTECTED]> wrote:
>Sadly, that means that you gain very little over the text file.
>
>--> Fixed size blocks means wasted storage compared to text
Sure. But to be fair, the little text files that Unix creates is
not optimal space usage either (and what you write at the bottom
is much worse...unless you do have a plan ;-)
>--> No indexes means no benefit from "better than O(n) expected accesss time"
Correct, but performance would be much better over all since there is
no need to parse, you can just read() everything in.
The two advantages I see in the registry are:
(a) programmatically writable
(b) uniform tool/file format/routines for all programs
(c) inherent error checking (by way of types)
I'm not as concerned about performance (I would be if it dipped below
text files, of course, though)
>The *real* point is that when text is used, one can muster the force of any
>of UNIX's text manipulation tools, whereas a binary database leaves you
>limited to whatever tools have been specifically written to manipulate the
>binary database.
In theory this is true, but in practice which text tool are you going
to use for these sorts of configuration files? Since these are
basically read-only except by humans, really the only thing you are
going to do search, so grep and friends may help you, but remember, the
registry editor is going to have all of the search (and replace!)
functions as well. Also the fact that is in one database (file)
alleviates the need for some of the other tools (e.g. find)
>I don't see a mandate for everyone to reimplement all the programs they've
>written just to do that; that approach represents the sort of "fascism" that
>the UNIX community (and others) rather frown on.
I know it's frowned down upon and that's my whole problem with
it. ;-)
See, this is the type of thing that would have been solved by having
thought about this 30 years ago: Unix would have just had a standard
for it, and most people would have used, but since it came 30 years
after the fact, even if a lot of new programs decide to adopt it,
there will always be those written before the fact that won't have the
support.
>My classic alternative to /etc/fstab is to do the following:
>
># mkdir /etc/fstab
># echo 192.168.1.1 > /etc/fstab/dantzig.brownes.org
># echo 192.168.1.2 > /etc/fstab/wolfe.brownes.org
># echo 192.168.1.3 > /etc/fstab/knuth.brownes.org
># cd /etc/fstab
># ln dantzig.brownes.org dantzig
># ln wolfe.brownes.org wolfe
># ln knuth.brownes.org knuth
># ln -s dantzig cache
># ln -s wolfe coda
Of course this is /etc/hosts, not /etc/fstab, but that makes me
curious as to how would go about implementing /etc/fstab, which
differs from /etc/hosts in that each record has more than one field.
Would you make the record into a directory as well, and put each field
as a separate file, or would you keep it as it is, and put all of the
fields into one file (and if the latter, how do you tell them apart)?
(/etc/fstab is also tricky because the primary keys generally contain
slashes ;-)
I've seen you mention this before, and I do think it is beautiful. It
it the perfect fusion of a database into filesystem semantics,
especially with the links there. I would like to see how well it scales
to the other files though. How could /etc/resolv.conf work? Also, how
is this actually implemented (if it is), are each of the
records/fields actually individual files (taking up a whole block of
filesystem), or is there something more intelligent behind the whole
thing?
-- Terry
------------------------------
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 25 Jun 1999 07:44:02 GMT
Linus Torvalds ([EMAIL PROTECTED]) wrote:
: So back to the question of UNIX vs mainframes - no, it's not in the
: least interesting. And it has got nothing to do with size.
speaking of "in the least interesting".. wired has a really
critical article of Mr.Penguin(*) himself regarding the
lotus developers conference 99.. boy everyone's a critic !!
http://www.wired.com/news/news/culture/story/20399.html
linus, maybe if you become more provocative like ESR
and offend everyone. or maybe a costume would be interesting.
ever notice how the bar keeps getting raised?
(they should invite me instead, I guarantee I would bring
down the house.. hahaha I have my kerosene & matches right
here!!)
(*) for the humor impaired, Mr.Penguin is meant to be
a term of respectful endearment.
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAPOs: configurations
Date: 25 Jun 1999 05:07:00 -0400
In article <[EMAIL PROTECTED]>,
Paolo Torelli <[EMAIL PROTECTED]> wrote:
>> I assure you the OS of the future is not going to have text based
>> configuration files .. at least at the core. I think there is always
>Indeed. text files are by all means larger and harder to mantain.
So you never did any kind of sysadmin job, right?
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Jan Panteltje)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Fri, 25 Jun 99 09:41:41 GMT
>In article <wt4sjyngo9.fs C++ and Java are
>much better than C. Dylan is much better than C++ and Java.
>
Well if I distill 'better' from that, then (I have not tested Dylan, liked
some of Bops songs though), then it must be f*cking slow and bloated.
It is not true (to any extend) that C++ is much 'better' then C.
In fact any thing you can do in C++ can also be done in C.
Many times object oriented programming is not even needed, or even desirable.
And the use of classes is for sure just a programming decision, nothing
fundamental.
I speak both, C, and C++, and admit to mostly using C.
Because it is fast, small code size, portable.
Java is IMNSHO (In My Not So Humble Opinion) a PIG, maybe even an elephant.
Because it is so slow, did you try the java version of ICQ?
Compare it with micq, written in C.
That shows it all does it not?
Oh, the GUI? try xforms, it is written in C.
Not talking licenses here, just technical.
Of cause there is Qt, OK, it has it advantages too.
In fact every language has its advantages, but great is the programmer who
really masters the language (whatever language), he can write anything.
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 25 Jun 1999 07:18:07 GMT
In article <[EMAIL PROTECTED]>,
Frank Sweetser <[EMAIL PROTECTED]> writes:
>
> not true. work is being done even as we speak on a generic (read: non arch
> specific) LVM system for linux.
Will it support other OSes -- for those with dual-boot systems?
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Configuration as Database (was Re: TAO: the ultimate OS)
Date: 25 Jun 1999 08:42:17 GMT
In article <7kut50$q1j$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Murphy) writes:
>
> You can implement a registry system with no additional metadata than a
> text file, if you use fixed sized records, and don't have additional
> indexes, and yet still have all of the advantages of a registry
> system. There can be exactly no additional metadata than in a text
> file, and thus it is no more subject corruption. If you implement a
> full scaled database, yes, there is additional chance of corruption.
> But you do not need that to gain the advantages of a registry system.
You're talking about two different things here.
1. A file structure
2. An API
When you say "advantages of a registry", you really mean to say
"advantages of a single, unique API to access configuration
information", with the concommitant expectation that you can
manipulate all configuration data without reference to the
programs.
A coherent, unique API *can* be a huge advantage, provided that it
is sufficiently expressive to support programs that weren't even
dreamt of when the API was designed. Clearly, the
"GetPrivateProfileString" API is *not* expressive enough (ever tried
to have several identical keys with that API?).
Having the configuration data for all the programs in *one* location
is clearly a sub-optimal design. Using the "registry" for everyting
from the OS to the silliest utility is not only sub-optimal, it is
just plain silly. It strikes me as a marketing concept forced into
an OS design.
And mind you, even though Windows uses the registry, many Windows
apps don't. How you would make it impossible to write an application
that doesn't use the registry (ie enforcing a policy) for its
configuration information, I cannot imagine.
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Configuration as Database (was Re: TAO: the ultimate OS)
Date: 25 Jun 1999 09:36:44 GMT
In article <7kv70g$2ib$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Murphy) writes:
> In article <[EMAIL PROTECTED]>,
> Christopher B. Browne <[EMAIL PROTECTED]> wrote:
>
>>Sadly, that means that you gain very little over the text file.
>>
>>--> Fixed size blocks means wasted storage compared to text
>
> Sure. But to be fair, the little text files that Unix creates is
> not optimal space usage either (and what you write at the bottom
> is much worse...unless you do have a plan ;-)
>
>>--> No indexes means no benefit from "better than O(n) expected accesss time"
>
> Correct, but performance would be much better over all since there is
> no need to parse, you can just read() everything in.
The file lives in the cache. In any case, the time spent to read in
configuration information is hardly ever a factor. Now if you're
going to use the registry as a place to store volatile information,
and you want to to stay coherent...
> The two advantages I see in the registry are:
>
> (a) programmatically writable
> (b) uniform tool/file format/routines for all programs
> (c) inherent error checking (by way of types)
There are actuall three advantages here :-)
Advantage a) is not limited to a registry. A library offers the same
advantage, and I really wonder if anyone who writes more than one
program hasn't come up with a configuration library of one's own.
Not all configuration requirements can be met by a simple key/type/value
structure, though.
Advantage b) is in the eye of the beholder. What you feel to be
the advantage of a registry (a uniform set of tools to access the
information for all programs) is what I find in UNIX: I can use
vi, perl, tcl, etc to manage my configuration information, and
(for instance) create dynamic Samba configurations (Samba can
use "include" statements in its config file; such functionality
would require major hackery if at all possible with a registry).
Advantage c) is inherent in a well-designed configuration API.
> I'm not as concerned about performance (I would be if it dipped below
> text files, of course, though)
>
>>The *real* point is that when text is used, one can muster the force of any
>>of UNIX's text manipulation tools, whereas a binary database leaves you
>>limited to whatever tools have been specifically written to manipulate the
>>binary database.
>
> In theory this is true, but in practice which text tool are you going
> to use for these sorts of configuration files? Since these are
> basically read-only except by humans, really the only thing you are
> going to do search, so grep and friends may help you, but remember, the
> registry editor is going to have all of the search (and replace!)
> functions as well. Also the fact that is in one database (file)
> alleviates the need for some of the other tools (e.g. find)
You haven't worked as a sysadmin, have you? I use perl *all the time*
to insert, create, derive, modify all kinds of system information and
configuration data.
>>I don't see a mandate for everyone to reimplement all the programs they've
>>written just to do that; that approach represents the sort of "fascism" that
>>the UNIX community (and others) rather frown on.
>
> I know it's frowned down upon and that's my whole problem with
> it. ;-)
>
> See, this is the type of thing that would have been solved by having
> thought about this 30 years ago: Unix would have just had a standard
> for it, and most people would have used, but since it came 30 years
> after the fact, even if a lot of new programs decide to adopt it,
> there will always be those written before the fact that won't have the
> support.
But UNIX *has* a standard way to handle configuration information:
1. System configuration data in /etc
2. Application global configuration in the application
sub-directory
3. User application configuration data in ."app"rc
4. Use text files for configuration, whatever required for state
information
What UNIX doesn't have (and if it had it, could not mandate its use) is
an API. What is also doesn't have, is the terminal braindamage of mixing
OS configuration with application configuration. In addition, it *has*
a fairly sane way of looking at user-specific config info (which is sadly
lacking in NT).
In any case, you're making a mountain of a molehill. There are
as many, if not more, problems with the Windows registry than
with the UNIX configuration files (ever tried to move an application
from drive C: to drive D: without re-installing?).
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 25 Jun 1999 08:05:30 GMT
In article <7kv2pc$t7h$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Murphy) writes:
> In article <7kt0m9$pbb$[EMAIL PROTECTED]>,
> Stefaan A Eeckels <[EMAIL PROTECTED]> wrote:
>
>>The portability issue is not a fundamental feature. It stems from the fact
>>that the kernel was re-written in a high-level language.
>
> It seems that virtually every introduction to Unix will mention
> its portability in the first sentence. This is one of the main things
> which is used to distinguish it from OS/400, VMS, etc.
It does now. It did not in 1969, because 'C' wasn't available.
Thompson did UNIX to get a comfortable programming environment,
Ritchie did 'C' to get a comfortable language. The reason UNIX
is successful is that many a programmer has that "comfortable"
feeling when working with UNIX. I develop systems on both UNIX
and Windows (and did for a lot of other platforms); UNIX is by
far the best environment to work in.
> And I don't think it just stems from the high level language (which VMS
> is also largely written in), but also the fact that it is much more
> abstract and independent of the system (unlike VMS, which only runs on
> two platforms, both by one company, and is thought to be
> technologically impossible to port to any other existing platform).
When UNIX was recoded in 'C', they were very careful to separate
the stuff that was really low-level from the rest (in addition,
getting UNIX to run on the Interdata 8/32, about as different from
a PDP/11 as you can find, helped a lot to get the gratuitous
machine dependencies out). Because they weren't working for a
manufacturer, they could indeed justify (re-)designing for portability.
All this notwithstanding, I still cannot understand why you
feel that UNIX not being designed in 1969 for portability in any
way diminishes the value of its design. There are very few, if
any, systems that are so coherently designed that they survive
re-coding in a different language.
>>The pipe was indeed a concept that sprang from the original design.
>>Again, what's wrong with that? Are only products which didn't
>>expand their core functionality "designed"?
>
> But the problem with pipes is that chapter one on any treatise on
> the Unix Philosophy is going to be about pipes, e.g. small re-usable
> tools, filters, etc., etc. True this was possible before pipes with
> redirection, but it is clear that were it considered a core feature,
> more thought would have been into exploiting this feature.
More thought? Would you care to elaborate where you feel that pipes
are under-utilised? Maybe certain applications that were ported from
other systems could have been re-designed to fit better, but the
core tools *are* using pipes quite heavily. A prime example is [t,n]roff,
which strings filters together with gay abandon, and which was the
motivation offered to management to continue the development of UNIX.
You're making a sweeping statement that is not founded in fact.
In addition, you fail to offer any rationale for the assertion that
*if* pipes had been in UNIX1969, the current toolset would have been
significantly better (at least WRT to using pipes). It's about as
vacuous as saying that sockets would have been better *had* they been
in the original design (given the state of the art in networking
in 1969, they would have been *worse*).
>>It's not because DEC wrote a "book" on software engineering that they
>>follow it :-)
>
> This book I am talking about, what not published, it was a handbook
> "for internal use only", i.e. it would have been silly to produce it
> and not use it. For the project that I worked in there, we did the
> whole nine yards: requirements, architecture, unit testing, regression
> testing, field tests, etc. And this was for an internal product with
> perhaps 100 customers. I am sure the process for external tools is
> even more rigorous.
The first releases of UNIX were internal products with a small number
of users. I wasn't there, but I'm quite sure the UNIX people *did* get
the requirements from their patent department WRT text processing before
they set out to provide both the OS and the formatter. I'm quite sure
they *did* unit test both the OS, the formatter, and the macros for
conformity with the requirements (or the patent department wouldn't
have used the system), and did whatever tests were required to have
a satisfactory system.
What you fail to see is that once UNIX had become a multi-vendor
product is was (and is) wholly impossible to impose a strict
"by-the-book" approach to its evolution. You're forgetting that
VMS has essentially died, *because* the development process did not
allow the system to be adapted to the requirements of the users.
Apple's MacOS has the same problem, and if MS is not very careful
WinNT is bound to collapse under the pressure of the marketing
droids to introduce badly engineered features.
>>Seriusly, look at OpenVMS --a mad scramble to get POSIX into
>>VMS. Does that fit your requirements?
>
> FYI, Posix was merely a product on top of VMS, it wasn't really
> integrated into the system (e.g. it required a separate license). It
> has been discontinued, BTW. I am opposed to it on principle of course
> (I don't want my system polluted by Posix), but it seems that was about
> the only way to do it, and it's hard to get pointy haired managers to
> buy a systems which doesn't conform to the "P" word.
But it was done nonetheless. Separate license or not, VMS was modified
to support POSIX, and this was not foreseen in the original design,
which is what we're talking about.
>>Sure. The Windows design process. GlobalAlloc and LocalAlloc --hacks
>>to get around a 640k memory limitation without using a memory management
>>chip. The MSDOS-1 FCB stuff still present in Windows98. And Word of
>>course never acquired *any* new functionality since its original
>>release.
>
> Microsoft engineering was a bit patchy until recently. I don't know
> how you can argue with the technical quality of their applications, e.g.
> Outlook, IE, Power Point, Word, etc. All of those are massively complex
> projects, which clearly a lot of work went into.
Again, dear Terry, give me a break. MS engineering has been non-existing,
because they've largely bought products and adapted them (more or less
successfully). Their 'C' compiler started out as Lattice 'C'. I forget
whom they bought Powerpoint from. Excel is also an outside acquisition.
They scrambled like mad to get compression into MS-DOS when Stacker
turned out to be successful. They scrambled like mad to get TCP/IP into
windows when the Internet turned out to be a success. They scrambled like
mad to get a browser out when Netscape turned out to be a success; they
even fail to convince a lot of people that IE is a good thing. Outlook
looses messages that Eudora handles perfectly. Word has such a complex
document structure that it's easy to loose blocks of text, and that
documents larger than 100 pages are handled very badly. Word 2 was
so perfectly designed that it could not save documents that are larger
than the swap space of the OS. VBfA was obviously carefully vetted for
security. etc. etc.
But I agree with you that they are "massively complex projects", and that
"a lot of work went into them". This does not mean that they were
properly engineered, though.
>>The hallmarks of a good design are that it
>>a) finds uses the original designers never envisaged
>>b) accepts the inevitable modifications, additions and enhancements
>> that are applied to it without too many structural cracks.
>>Whether it had a requirements document, or still matches the original
>>or revised design spec are not relevant.
>
> So what software system would you consider to match these criteria?
UNIX would be an example of a design that (although not perfect),
has managed to maintain its relevance for a long time, is used for
purposes (like running X) that the original designers (and for that
matter, hardly anyone back in 1969) never thought of, and has
(fairly) gracefully accepted such advances as virtual memory,
huge disk drives, long file names, networking, micro-kernelisation,
fault-tolerance etc. Contrast that with MS-DOS, which is so
limited that hard disks required a major overhaul of the API,
programs larger that about 600K required the introduction of
kludgy memory extensions (remember expanded, extended etc memory?),
and limits the number of mountable devices to 26, even in NT?
>
>>Take care, and brace yourself for what you'll discover when you
>>leave varsity ;-)
>
> I'll try. I think a have had a bit of exposure to the bad side (my
> current employer), which is the reason I speak up in this discussion.
Don't believe that following procedures blindly yields quality. Too
many projects are ruined by excessive, clueless management.
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: Paolo Torelli <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAPOs: configurations
Date: Fri, 25 Jun 1999 10:43:38 +0200
Reply-To: [EMAIL PROTECTED]
"Vladimir Z. Nuri" wrote:
> if you combine a registry with a good fault-tolerant system, with
> versions of the registry & all other software.. that could be pretty
I have a (better?) idea. Since the problem seems to be the central registry,
then splitting the registry would make things nicer, correct? Well, if for
every program's configuration, the configuration is stored in a registry-style
stream of the program, then we'd have the following:
- Removing the program would not leave trash (as long as it doesn't interact
with system configuration/behaviour, but that's another point)
- moving the program around would not cause any harm
- failure of the stream for the configuration does not harm more than the
program itself
- no more thousands of config files spread all over
- easy and fast access to program's settings (by not searching through all the
huge registry but just in a couple of subkeys)
> ouch. there are insane amts of trouble spent by end users trying
> to keep crappily-designed/fragile OSes taped together.
:'(
> I assure you the OS of the future is not going to have text based
> configuration files .. at least at the core. I think there is always
Indeed. text files are by all means larger and harder to mantain.
> a need to export any "entity" into unambiguous ASCII files however.
Like regedit's export function, which exports text files which can be
re-imported, I guess...
> that would be one of the operations I would build into the OS.
Better, a function of the configuration libraries/program.
--
[=-----------------------Technolord-the-Hellraiser----------------------=]
]All tied up and dried up forever all fucked up and dead to the world[
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
