Linux-Development-Sys Digest #216, Volume #6 Tue, 5 Jan 99 00:14:11 EST
Contents:
Re: WDM Emulator, anyone? (Inaki Castillo)
Re: Registry - Already easily doable, in part. (Frank Sweetser)
Re: Registry for Linux - Bad idea ([EMAIL PROTECTED])
HOW-TO submit? ([EMAIL PROTECTED])
Re: Registry for Linux - Bad idea (Frank Sweetser)
Oops in 2.2.0-pre4 (David Ronis)
Re: things I'd pay to have developed for Linux... (nobody)
Re: What does "set_fs( )" and "get_fs( )" ? ("D. Stimits")
Re: Registry for Linux - Bad idea (Craig Kelley)
----------------------------------------------------------------------------
From: Inaki Castillo <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: WDM Emulator, anyone?
Date: Mon, 04 Jan 1999 22:27:31 +0000
Reply-To: [EMAIL PROTECTED]
> Actually, WDM starts with the NT Driver model. We would probably start
> with the NT DKK.
>
Have you any idea of what are you saying ?
NT DDK is nothing by itself, you should reproduce all NT Kernel
components to do any simple piece of driver to work. That is all the
operating system. Win32 is in fact a layer above that.
Maybe is better to move to NT.
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 04 Jan 1999 16:51:35 -0500
George MacDonald <[EMAIL PROTECTED]> writes:
> Doesn't even need to be Unix specific and the "Active" tends to indicate
> other Microsofty type things(Active X, ...) so I would prefer not to
> confuse people with that term. Other names I have thought of for a
> project to do this:
>
> OpenStore - Shorter version opStore
> OpenConfig
> NetConfig
> ConfigBase
>
> SNCP - Simple Network Configuration Protocol
> NOCP - Network Object Configuration Protocol
> CIB - Configuration Information Base -> Descriptions of schemas
>
> NOCS - Network Object Configuration System (Hmm I like this one)
>
> Thoughts?
well, from what i gather so far, your idea is to have some kind of a
configuration parsing engine taking input from various multiple
sources... so how about Multple Source Configuration Engine? <G>
more seriously, i kinda like NAOCS a little better - Network Aware Object
Configuration System.
two other random thoughts i just had wrt security -
it would need a slightly different API for opening encrypted
files/channels, as it should prompt for a passwd. you could have the
library itself prompt for the credentials, but that could interfere with
the program output...
another good idea might be to have the ability to mark certain values as
'sensetive'. this could then place certain restrictions on how the library
deals with it - for example, it might refuse to send it in plaintext
accross the network, or save it in an unencrypted or world readable file.
anybody know of any good libraries to allow you to transparently open an
encrypted file securely (no tmp files or anything), ala zlib?
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
How do I type "for i in *.dvi do xdvi i done" in a GUI?
(Discussion in comp.os.linux.misc on the intuitiveness of interfaces.)
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Mon, 04 Jan 1999 21:24:34 GMT
In article <76qv5n$t5t$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Craig Kelley) wrote:
> ... and yet you fail to answer the obvious question: Why?
>
> What does making sendmail.cf a tree buy us? I don't think that it
> will "better organize" anything. You will still have the same keys
> and values (unless you want to re-write sendmail, in which case you
> are quite insane), so a user will either know what he is doing or he
> won't, and the exact same rulesets apply with a regsitry as they do
> with the current text file. In addition, we have the following
> disadvantages:
We can argue about sendmail until we're old and grey, sendmail.cf will
probably never be easy to understand. I was just playing out an example. I
dont know enough about the actual code in sendmail to say what is and what
isn't possible. Everyone immediately jumps to the most complicated of all
examples and expects the solution to deal with it 100%. Maybe sendmail can be
coaxed into the world of a central config, maybe not, let the sendmail
experts decide. IMHO if the goal is ease of administration or use sendmail
should not even be in the picture.
>
> o special tools will need to be built to access configuration
> information without a running instance of a program (ala
> regedit.exe).
Why does everyone liken a special tool to the worst example of that tool? I
dont know how many times I can say this but WINDOWS REGISTRY IS A PIECE OF
JUNK. Linu on the other hand has programmers everywhere which can insure a
quality utility if you give it the time. This very discussion is an example
of how nothing makes it into Linux without debate and forethought. Everyone
is pointing out why any given idea is bad, but few are offering input on what
would make it good.
>
> o The system will have one point of failure; if a tree become
> corrupt, then everything under that node is also corrupt. This
> means re-implementing some sort of e2fsck for your registry file:
> why re-invent the wheel?
Again, trash something in /etc and tell me how that's not a single point of
failure. It's a different kind of failure, but a failure nonetheless. If you
have to go to the bootdisk the system is down and it's time for disaster
recovery. Whether that disaster is a central config database or from a trashed
/etc/fstab it makes no difference.
>
> o These rescue tools will need to be incorporated into every rescue
> disk.
Yes they will. Everyone seems to be so adamant that this wont fit on a floppy.
RedHat installs fine with 2. Windows NT requires at minimum 3. Is it that
important to you that all utilities be on a single floppy? If it is, then dont
use the central config database.
>
> o You will need to re-write EVERY single application which uses any
> sort of configuration file. Two versions of these applications
> will need to be kept up-to-date (do you have the <snicker> "Linux
> Registry" on your system? No. Good.) in order to maintain
> compatibility with _UNIX_.
Introducing new code does not mean there has to be a code fork. Many packages
seem to do fine while supporting NIS and other similar schemes. There are
ways to hook into existing structures as well. It does not have to happen
overnight.
>
> o You will need to supply a comprehensive rule-set, and be able to
> anticipate future programming needs.
Who says the rules cant be a function of the software. No one is proposing a
totalitarian database that does not allow the app to do as it pleases with
the data it received from the config database. The goal is to have something
that is central, is well-defined, and offers standard way in which you can
begin to debug a problem or make a system change.
>
> o Applications will be linked against certain libreg.version.so and
> you will probably have problems when you upgrade your libreg
> version numbers, which could cause the entire system to bomb. We
> already have this problem with libc, do we need another one?
This does not have to be an issue, especially if things are done right. As
long as functions are designed to be extensible new versions need not break
old ones.
>
> o It buys you ABSOLUTLY NOTHING which cannot be accomplished with
> your own library and/or other people's libraries.
I'm not sure where you're going with this. Just because something is
pre-existing does not dictate it's superiority. If people would quit assuming
everything being talked about is the same as what they have seen in Windows
maybe they could think about alternatives and we can move forward from the
text-file scheme.
>
> o It is not in the UNIX specification, and while Linux isn't UNIX --
> we don't make friends by going out of our way to not be UNIX.
Indeed. However if Sun were to do this is in their next release of Solaris
who would be left standing with no input into the specs? Linux. We have the
oportunity to define an open standard which can bleed into other UNIX's as
well, rather than being forced to adopt some other vendor's scheme. No one
has to adopt this tomorrow. No one has to adopt it ever. It's just an idea to
get rid of some of the needless inconsistency in the way systems are
currently set up.
Which brings me to another point I (and others I presume) have made before.
If you dont like it, dont use it. You have the source code, do as you please.
Such is the power of Linux.
-Rich
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: HOW-TO submit?
Date: 4 Jan 1999 23:28:13 +0100
Hello people.
I'm new one in the business of contributing something except bug reports.
While playing with (learning in reality) Gimp I made (and remade) some
terminal icons of xterm.xpm style. (Yes, low-number-of-colors linux pinguin is
here too accompained by FreeBSD daemon) I sent it to SuSE (I use SuSE 5.3
distribution) but they probably thought for a very long time and replied:
<quote>
Thank you, if they are good new icons, they should probably made public,
give them a free license(GPL), and should be put on web servers.
However, I can't assist in doing so except answering questions. ;-)
<end of quote>
So could anybody enlight me what should I write in GPL license or better
where to get the _correct_ form and where to put the icons. Which of the
dozens Linux related web servers I should use for this purpose?
Further. I think would be nice to add there xterms for AIX, UnixWare, SCO,
BSDI (did I forget 1 or 2 known systems with xterm/terminal capability?).
As there a reSunOS, Solaris, IRIX (SGI-cube), HP-UX ( (hp) symbol), Dec
(D i g i t a l), AXP, Linux, FreeBSD currently.
So I need logos of mentioned systems AIX .... You know symbols like pinguin,
or daemon, or SGI-cube. where to get them?
Of course these are small and unnecessary toys but I find it is quite handy,
it helps if you have plenty of xterms on different hosts. And also I think
some polishing would be nice to Linux.
Constructive replies to this post via email won't call my anger :).
--
Andrey Nikolaev Ulm university,
Department of Biophysics. Germany.
Email: Andrey.Nikolaev@!get-lost-spammer!.uni-ulm.de
Substitute physik instead of !*! .
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 04 Jan 1999 22:20:29 -0500
[EMAIL PROTECTED] (Christopher Browne) writes:
> It's easy enough, in C, to fiddle with argc/argv, that people often
> enough "roll their own" argument parsers. If people made more common
> use of one or two of the better argument parsers, this could improve the
> consistency of the parsing of commands. Fortunately, since Microsoft
it already has - take a look at most GNU software, which uses the getops
routines. it's good from the point of view of the programmer, because you
can just specify which options you want to check for, which ones take
arguments, and you automagically don't have to worry about what order they
come in, dealing with clustered args, etc. it's also good from the user
point of view, because they get get good features (clustering of single
char args, --foo always means a long arg, --) that act consistently from
one package to the next. like you said earlier, not everyone is using
enough, but certainly enough to make it worthwhile.
another point here - this thread seems to have broken apart into two
different ones. one of them is more of a linuxconf argument - provide a
single API that knows how to configure all/as many as possible different
software packages. IMHO, this is a worthy project, but will always end up
being limited due to 1) the extremely wide range of config formats already
existing out there, and 2) some packages (sendmail, emacs) have a complex
configuration closely tied to the package.
the other one (which i've been contributing to more) is a bit less
ambitous, at least at first. this is to create a library which presents a
simple API allowing programs to store and retrieve settings without knowing
or caring how or where (spread accross local files, CORBA, SNMP, SQL DB...)
they are stored. while this won't affect any existing packages without
re-writing them (not an entirely bad thing IMHO), it could make things a
*lot* easier for people writing new packages.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
OOPS! You naughty creature! You didn't run Configure with sh!
I will attempt to remedy the situation by running sh for you...
-- Larry Wall in Configure from the perl distribution
------------------------------
From: David Ronis <[EMAIL PROTECTED]>
Subject: Oops in 2.2.0-pre4
Date: 4 Jan 1999 21:34:23 GMT
I've installed 2.2.0-pre4 and compiled with default compilation flags
on an i586. I've encountered Oops (the latest syslog entry is given
below) twice so far today--in both cases, I was running netscape,
untarring a large compressed file, and using X. I followed the
upgrade instructions and rebuilt all the packages listed in the
Changes file.
Any suggestions?
David Ronis
Unable to handle kernel paging request at virtual address 00020014
Jan 4 16:27:52 ronispc kernel: current->tss.cr3 = 00101000, Lr3 = 00101000
Jan 4 16:27:52 ronispc kernel: *pde = 00000000
Jan 4 16:27:52 ronispc kernel: Oops: 0000
Jan 4 16:27:52 ronispc kernel: CPU: 0
Jan 4 16:27:52 ronispc kernel: EIP: 0010:[<c0123c5e>]
Jan 4 16:27:52 ronispc kernel: EFLAGS: 00010206
Jan 4 16:27:52 ronispc kernel: eax: 00020000 ebx: c01f0d10 ecx: 00000c9b edx:
00006000
Jan 4 16:27:52 ronispc kernel: esi: 00020000 edi: 00020000 ebp: c01f0d10 esp:
c000ffa8
Jan 4 16:27:52 ronispc kernel: ds: 0018 es: 0018 ss: 0018
Jan 4 16:27:52 ronispc kernel: Process kswapd (pid: 3, process nr: 3,
stackpage=c000f000)
Jan 4 16:27:52 ronispc kernel: Stack: 00000000 00026c8f c0119520 c01f0d10 00000008
00000008 c011e11f 00000008
Jan 4 16:27:52 ronispc kernel: 00000000 00000000 c01808ae c000e000 00009000
c011e243 00000000 00000f00
Jan 4 16:27:52 ronispc kernel: c0003fc0 c0106000 c010651f 00000000 00000f00
c01a7fd8
Jan 4 16:27:52 ronispc kernel: Call Trace: [<c0119520>] [<c011e11f>] [<c01808ae>]
[<c011e243>] [<c0106000>] [<c010651f>]
Jan 4 16:27:52 ronispc kernel: Code: 8b 76 14 83 78 20 00 75 06 f6 40 18 46 74 0f 6a
00 e8 5c 01
Jan 4 16:28:53 ronispc kernel: Unable to handle kernel paging request at virtual
address 00020014
Jan 4 16:28:53 ronispc kernel: current->tss.cr3 = 00493000, Lr3 = 00493000
Jan 4 16:28:53 ronispc kernel: *pde = 00000000
Jan 4 16:28:53 ronispc kernel: Oops: 0000
Jan 4 16:28:53 ronispc kernel: CPU: 0
Jan 4 16:28:53 ronispc kernel: EIP: 0010:[<c0123c5e>]
Jan 4 16:28:53 ronispc kernel: EFLAGS: 00010206
Jan 4 16:28:53 ronispc kernel: eax: 00020000 ebx: c01f0d10 ecx: 00000c9b edx:
00006000
Jan 4 16:28:53 ronispc kernel: esi: 00020000 edi: 00020000 ebp: c01f0d10 esp:
c0421f04
Jan 4 16:28:53 ronispc kernel: ds: 0018 es: 0018 ss: 0018
Jan 4 16:28:53 ronispc kernel: Process tar (pid: 1132, process nr: 44,
stackpage=c0421000)
Jan 4 16:28:53 ronispc kernel: Stack: 00000005 c0420000 c0119520 c01f0d10 00000014
00000008 c011e292 00000008
Jan 4 16:28:53 ronispc kernel: 00000005 0000009f fffffff4 00000000 00000005
00000001 c011eb1a 00000005
Jan 4 16:28:53 ronispc kernel: 00000020 080695c0 fffffff4 00000000 bffff33c
c0421f7c 00000001 c0420000
Jan 4 16:28:53 ronispc kernel: Call Trace: [<c0119520>] [<c011e292>] [<c011eb1a>]
[<c0127dc4>] [<c01282dc>] [<c0120db2>] [<c01158f1>]
Jan 4 16:28:53 ronispc kernel: [<c0108b8b>] [<c0107964>]
Jan 4 16:28:53 ronispc kernel: Code: 8b 76 14 83 78 20 00 75 06 f6 40 18 46 74 0f 6a
00 e8 5c 01
------------------------------
From: nobody <[EMAIL PROTECTED]>
Subject: Re: things I'd pay to have developed for Linux...
Crossposted-To:
comp.os.linux.misc,comp.os.linux.development.apps,comp.os.linux.hardware
Date: 4 Jan 1999 20:28:20 +0800
In comp.os.linux.misc James Youngman <[EMAIL PROTECTED]>
wrote:
> Ilya <[EMAIL PROTECTED]> writes:
> > JFS.
> Being worked on.
Excellent.
> > LVM.
> I understand there are patches against 2.1.x for this, but the
> facility isn't stable enough for inclusion in 2.1.x or 2.2.x.
Good.
> > Mirroring and stuff
> You mean Software RAID? Which level? 1?
Yes, RAID 1.
------------------------------
Date: Mon, 04 Jan 1999 21:28:37 -0700
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: What does "set_fs( )" and "get_fs( )" ?
"J. A" wrote:
>
> I'm wondering if anyone can tell me what the functions "set_fs()" and
> "get_fs( )" does?
>
> I am using these functions in a little "device driver" I'm working on, and
> they makes it possible to read and write to/from a file on disk. Without
> them it doesn't work. So if you know what these functions actually do,
> please let me know!
>
> Thanks in advance //
> Jimmy
No idea. But try that great tool, strace, on your program.
strace -oSomeLogFileName YourProgram
It outputs system calls in a C-like syntax.
------------------------------
From: [EMAIL PROTECTED] (Craig Kelley)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 4 Jan 1999 16:32:47 -0700
In article <76rbig$iu5$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
[snip]
->Everyone is pointing out why any given idea is bad, but few are
->offering input on what would make it good.
The proponents of change usually carry the burden of proof.
->> o The system will have one point of failure; if a tree become
->> corrupt, then everything under that node is also corrupt. This
->> means re-implementing some sort of e2fsck for your registry file:
->> why re-invent the wheel?
->
->Again, trash something in /etc and tell me how that's not a single
->point of failure. It's a different kind of failure, but a failure
->nonetheless. If you have to go to the bootdisk the system is down
->and it's time for disaster recovery. Whether that disaster is a
->central config database or from a trashed /etc/fstab it makes no
->difference.
No, not really. While I grant you that having a backup and/or
redundant storage is the only way to guarantee consistency, you must
realize that a centralize registry is being written to ALL THE TIME.
An /etc/fstab file will not be written to after the initial
configuration, and stands little risk of being corrupted. It is read-
only for all intents and purposes.
A tree, OTOH, will fall apart when something goes wrong.
->> o These rescue tools will need to be incorporated into every rescue
->> disk.
->
->
->Yes they will. Everyone seems to be so adamant that this wont fit on
->a floppy. RedHat installs fine with 2. Windows NT requires at
->minimum 3. Is it that important to you that all utilities be on a
->single floppy? If it is, then dont use the central config database.
Windows NT does not boot with 3 disks. It requires a CD, and even
then one cannot 'repair' the system from there -- you must restore all
the system files, then re-install all the OEM drivers, re-apply the
latest service pack, re-apply the latest adminfix and then re-apply
all the current hotfixes (not forgetting to reboot after each step).
And, as a bonus, if you restore your backup registry without following
the EXACT SAME STEPS that you used for the snapshot then your system
will die again and you must go back and do it all over again. A
centralized registry is sooooo much fun.
->> o You will need to re-write EVERY single application which uses any
->> sort of configuration file. Two versions of these applications
->> will need to be kept up-to-date (do you have the <snicker> "Linux
->> Registry" on your system? No. Good.) in order to maintain
->> compatibility with _UNIX_.
->
->Introducing new code does not mean there has to be a code fork. Many
->packages seem to do fine while supporting NIS and other similar
->schemes. There are ways to hook into existing structures as well. It
->does not have to happen overnight.
It won't happen for much longer than that, especially without the
support of BSD and the commercial UNIX vendors-- most Linux
applications aren't designed to just run under Linux (or designed to
run under Linux at all, it is through compatibility that we gain all
these benefits).
And I have still yet to see any benefits from using a registry...
->> o You will need to supply a comprehensive rule-set, and be able to
->> anticipate future programming needs.
->
->Who says the rules cant be a function of the software. No one is
->proposing a totalitarian database that does not allow the app to do
->as it pleases with the data it received from the config
->database. The goal is to have something that is central, is
->well-defined, and offers standard way in which you can begin to
->debug a problem or make a system change.
What's wrong with the FILES section of a man page?
How's the registry going to be easier than that?
->> o Applications will be linked against certain libreg.version.so and
->> you will probably have problems when you upgrade your libreg
->> version numbers, which could cause the entire system to bomb. We
->> already have this problem with libc, do we need another one?
->
->This does not have to be an issue, especially if things are done
->right. As long as functions are designed to be extensible new
->versions need not break old ones.
What a great idea! You should mention that to the libc developers,
I'm sure that once they know that, they will be able to develop their
libraries after this manner. I'm a system administrator, and
skeptical by definition.
->> o It buys you ABSOLUTLY NOTHING which cannot be accomplished with
->> your own library and/or other people's libraries.
->
->I'm not sure where you're going with this. Just because something is
->pre-existing does not dictate it's superiority. If people would quit
->assuming everything being talked about is the same as what they have
->seen in Windows maybe they could think about alternatives and we can
->move forward from the text-file scheme.
Then *please* enumerate the benefits of using a registry.
->> o It is not in the UNIX specification, and while Linux isn't UNIX --
->> we don't make friends by going out of our way to not be UNIX.
->
->Indeed. However if Sun were to do this is in their next release of
->Solaris who would be left standing with no input into the specs?
->Linux. We have the oportunity to define an open standard which can
->bleed into other UNIX's as well, rather than being forced to adopt
->some other vendor's scheme. No one has to adopt this tomorrow. No
->one has to adopt it ever. It's just an idea to get rid of some of
->the needless inconsistency in the way systems are currently set up.
Can you give an example of these inconsistencies?
->Which brings me to another point I (and others I presume) have made
->before. If you dont like it, dont use it. You have the source code,
->do as you please. Such is the power of Linux.
What source code? You haven't given any to try out.
--
The wheel is turning but the hamster is dead.
Craig Kelley -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
------------------------------
** 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
******************************
