Linux-Development-Sys Digest #287, Volume #6 Sat, 16 Jan 99 00:13:59 EST
Contents:
Re: How to share memory between device driver and user space app. (Marc SCHAEFER)
Re: egcs - where is the official site? (Joe Buck)
Re: BogoMips (Mathieu ARNOLD)
Re: How to get disk I/O rate? (Rik van Riel)
Re: glibc and utmp/wtmp (Juergen Heinzl)
intriguing offer: Visual Prolog Freeware ("Carsten Christoffersen")
Re: disheartened gnome developer (steve mcadams)
Asynchronous IO (Guillaume Alleon)
Re: File descriptor as array index? (James Youngman)
Re: Why no core file? (James Youngman)
Ext2 within ExtendedX? (Ahilan Anantha)
FTP halts, no TCP window (Bruce Barnett)
Re: disheartened gnome developer (Christopher Browne)
Re: Registry - Already easily doable, in part. (Todd Knarr)
Re: disheartened gnome developer (Perry Pip)
Re: Open Configuration Storage - was Registry for Linux (Christopher Browne)
----------------------------------------------------------------------------
From: Marc SCHAEFER <[EMAIL PROTECTED]>
Subject: Re: How to share memory between device driver and user space app.
Date: 15 Jan 1999 20:20:51 +0100
jian.zhang <[EMAIL PROTECTED]> wrote:
> to share memory between driver and application? How to do this? I only
> know how to share application between two user space applications.
You should look into the User DMA patch or the Direct I/O patch
to the kernel to see how you can share memory between kernel and
user-space.
Alternatively, look at soundcard.c in the kernel since this maps
a DMA buffer to user space.
------------------------------
From: [EMAIL PROTECTED] (Joe Buck)
Subject: Re: egcs - where is the official site?
Date: 15 Jan 1999 12:33:45 -0800
Mike Dowling <[EMAIL PROTECTED]> wrote:
>Until recently, we had a local mirror of tsx-11, and it is from this mirror
>that I downloaded egcs-2.90.29. We now no longer have this mirror, and,
>besides, I somehow doubt that this is the most recent release.
>
>Does anybody know where the latest, official version is to be found?
In the spirit of the expression "Teach a man to fish, and he can eat for
a lifetime":
Allow me to recommend the Google search engine: www.google.com. What's
different about Google is that they use a ranking system that is obvious
once described: a page scores higher the more other pages link to it;
there are extra bonuses for being linked to by a page that itself has
lots of pointers to it.
The result of this is that, for almost any free software program, typing
the name of the program to Google gives you the home page of that program
as the first link.
Thanks to this methodology, you can even type common words like Linux
and get good results. If you do this, the first page gives the following
home pages:
www.linux.org
Red Hat
Debian
Linux Journal
www.linuxmall.com
Linux International (www.li.org)
www.linuxresources.com
The Linux Documentation Project
There's only one oddball: a Hungarian page comes up. I'm not sure why,
maybe every site in Hungary points to it or something.
As Google will reveal, the answer to your question is egcs.cygnus.com.
--
-- Joe Buck
work: [EMAIL PROTECTED], otherwise [EMAIL PROTECTED] or [EMAIL PROTECTED]
http://www.welsh-buck.org/
------------------------------
From: Mathieu ARNOLD <[EMAIL PROTECTED]>
Subject: Re: BogoMips
Date: Thu, 14 Jan 1999 22:07:33 GMT
Vincent Lai wrote:
>
> Does anybody know the meaning and measurement reference of the bogomips in
> linux? I have 2 PCs (200MHz MMX Pentium and 415MHz Pentium II) and they got
> about the same bogomips (around 400). Why?
you should go and take a look to the Bogomips mini howto.
--
Cordialement
Mathieu ARNOLD PGP key id : 0x2D92519F
IRC : Dalnet #mygale _mat ICQ uin:1827742
mailto:[EMAIL PROTECTED] http://www.multimania.com/arn
------------------------------
From: Rik van Riel <[EMAIL PROTECTED]>
Subject: Re: How to get disk I/O rate?
Date: Thu, 14 Jan 1999 22:38:11 +0100
On Tue, 12 Jan 1999, Aurel Balmosan wrote:
> JiSook Kim <[EMAIL PROTECTED]> wrote:
>
> > I'm writing a program that monitors disk I/O rate(bps) per disk.
>
> > The system has three hard disks(/dev/hda1, /dev/sda1, /dev/sdb1).
> > How to get disk I/O rate per disk ?
>
> Check vmstat which is included with the ps package.
Or better, use the vmstat program that's included with
Larry McVoy's BitCluster (ftp.bitmover.com). It's much
better than the standard vmstat...
Rik -- If a Microsoft product fails, who do you sue?
+-------------------------------------------------------------------+
| Linux memory management tour guide. [EMAIL PROTECTED] |
| Scouting Vries cubscout leader. http://www.nl.linux.org/~riel |
+-------------------------------------------------------------------+
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: glibc and utmp/wtmp
Date: Thu, 14 Jan 1999 22:21:55 GMT
In article <1wsn2.529$[EMAIL PROTECTED]>, Niels Andersen wrote:
>>>I recently upgraded to glibc-2.0.6.
>>>I have also started building my system programs to use the library.
>>>After building and installing sh-utils-1.16 I have noticed that
>>>"users" and "who" don't work (they run but give no output).
[...]
>I'm having troubles with utmp too. w, users, top etc. don't work. (There
>must be an FAQ or HOWTO about this...) I have no idea why they suddenly
>don't work. I THINK my glibc is ver 2.0.7 (how do I check that?).
ls -l /lib -> ... libc-2.0.7.so
If you've got a distribution it might be better to wait, since there
are some things to consider and you can mess up your system pretty
well and, forgive me, if you do not know how to determine what lib
you've installed you might forgo upgrading yourself.
Said that ... they compile as usual, usually and there is a glibc-FAQ ...
http://www.imaxx.net/~thrytis/glibc/glibc-FAQ.html
... here and the "problem" is, again, the changed format of struct utmp.
It depends what is up and running on your machine too, but here
is an (for sure) incomplete list ...
sysvinit, getty's, login and friends, xterm, rxvt, in.rlogind and
friends. You better have some shell ready that is linked to the
ncurses lib too, although the bash even works with the old termcap
library, at least if the latter one is not linked against the
old libc5..
If you've got a spare root partition, can become handy too. If not,
now is the time.
>I really need some more exact help on how to compile these programs, and
>which programs it is.
>I'm currently running RedHat 5.1, planning to upgrade to 5.2 soon. Would
>that solve my problem?
See above, probably better for you to wait, the latest RH is glibc
anyway (FIX ME).
Cheers,
Juergen
--
\ Real name : Jürgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
\ Phone Private : +44 181-332 0750 \ /
------------------------------
From: "Carsten Christoffersen" <[EMAIL PROTECTED]>
Subject: intriguing offer: Visual Prolog Freeware
Date: Thu, 14 Jan 1999 15:27:51 +0100
A fully functional Visual Prolog software development system is
now available for Win 3.1/95/98, NT, OS/2, SCO UNIX and Linux
on a special Freeware license.
There are no technical or time restrictions, and it includes all
features from the Visual Prolog Professional commercial version
except the source code to the development environment.
However, all executables made with the Freeware version will
start up with a banner saying that it has been produced with a
non-commercial license.
For detailed information about Visual Prolog visit
http://www.visual-prolog.com
Rgds,
Prolog Development Center
Carsten Christoffersen
------------------------------
From: [EMAIL PROTECTED] (steve mcadams)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Fri, 15 Jan 1999 00:11:47 GMT
[Snipped for brevity, quoted material marked with ">"]
On Thu, 14 Jan 1999 17:58:01 GMT, [EMAIL PROTECTED] (Perry Pip)
wrote:
>Steve, I agree with your conclusion that QPL is more open than GPL, but I
>strongly disagree with your assertion that QPL is more open than LGPL.
>LGPL allows you to link *anything* to it, whereas QPL does *not* allow you
>to link a closed source program to it. (To link a closed source app to you
>must buy the commercial version of Qt, which is not under QPL). That's my
>interpretation of QPL clause 6, where I think the term "These items" is
>made pretty clear.......
I don't think the term "item" is defined clearly enough for legal
purposes, whether I'm right or wrong. I think TT needs to have more
lawyers work on their license because it has what appears to be holes
in it, where the GPL reads watertight to me. The LGPL is a hack off
the GPL with a couple minor modifications, and I'm not sure there
aren't holes in it too.
Frankly it is not clear to me what "problem" TT is attempting to solve
with their license, since the GPL satisfies their desire to sell
commercial licenses to Qt if companies are going to use it in
commercial products. I'd be interested to learn the answer.
Personally, though I expect to use the GPL in the future, I don't
think that I'd ever use the LGPL or the QPL precisely because in
addition to being less "watertight" in their wording (imo) they do
allow you to link closed-source code. Personally I think that is
silliness; the only reason to write closed-source code that I have
come up with is for maximum profit, and if someone is looking to do
that with my code, I'll be glad to sell them a proprietary license
assuming I choose to do business with them. I wouldn't have that
choice with either LGPL or QPL; any company including the dreaded
Microsoft could use my code in their proprietary applications without
so much as a "by your leave", much less a fat check. Free code in
free code is a good thing, free code in proprietary products is plain
stupidity imo, better for proprietary products to pay for free code
development. And anybody whose initials are BG is likely to pay
through the nose.
ALL of this is opinion and obviouslly ymmv. -steve
========================================================
Tools for programmers: http://www.codetools.com/showcase
------------------------------
From: Guillaume Alleon <[EMAIL PROTECTED]>
Subject: Asynchronous IO
Date: Fri, 15 Jan 1999 23:27:20 +0100
Hi !
I am doing intensive IO for numericall applications, I was wondering
if somebody had developed some asynchronous POSIX functions
(aio_write, aio_read, ...)
If not I am wondering how large is the work to do it ?
If you have any pointer, please help
Yours
Guillaume
------------------------------
From: James Youngman <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: File descriptor as array index?
Date: 15 Jan 1999 22:44:34 +0000
Will Mason <[EMAIL PROTECTED]> writes:
> Save yourself the headache and use a map instead of a vector. If you're
> using STL, it's really quite simple to implement. If you try to leverage
> some internal truth about the way that file descriptors are assigned,
> then your shooting yourself in the foot: no portability and someday they
> may change file descriptor allocation without telling you.
Actually, in the sense that I think you mean, file descriptor
allocation is completely defined. open(), fopen(), dup(),
fcntl(,F_DUPFD) are all defined to use the first available file
descriptor. (This is in the Single Unix specification, at least).
For example, in the case of open():-
The open() function will return a file descriptor for the named
file that is the lowest file descriptor not currently open for
that process.
I note that the same guarantee apparently does not hold for accept(),
socket(), or socketpair(). I'm not sure if this is an oversight or
not.
--
ACTUALLY reachable as @free-lunch.demon.(whitehouse)co.uk:james+usenet
------------------------------
From: James Youngman <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why no core file?
Date: 15 Jan 1999 23:05:19 +0000
BL <[EMAIL PROTECTED]> writes:
> on my system (redhat 4.2, kernel 2.0.36) ulimit is NOT IMPLEMENTED.
> even 'man ulimit' says this.
That is ulimit(2). The command you are looking for is the /bin/sh
builtin "ulimit" command. "help ulimit".
> btw, I'm using the tcsh 6.06, but I've also tried csh and bash - neither one
> wants to dump core.
For tcsh, the equivalent builtin is "limit".
--
ACTUALLY reachable as @free-lunch.demon.(whitehouse)co.uk:james+usenet
------------------------------
From: Ahilan Anantha <[EMAIL PROTECTED]>
Subject: Ext2 within ExtendedX?
Date: 16 Jan 1999 01:13:02 GMT
Hi,
I was wondering if it was possible to create and use ext2 filesystems
made as logical partitions within an ExtendedX partition (the LBA Extended
partition type introduced in Win9x). Basically, I'm trying to find out how
to efficiently partition a >8.4 gb hard disk between Win98 and Linux. I'm
assuming that LILO still doesn't know how to boot logical partitions within
and ExtendedX, so I'm expecting to make the Linux root filesystem a primary
partition before the ExtendedX (in the first 1024 cylinders).
So the idea is this:
-----------------
| FAT32 boot |
| type 0xB |
| (~2 GB) |
~2GB -----------------
| Linux root |
| type 0x83 |
| (~75 MB) |
~2.1GB -----------------
| ExtendedX |
| (type 0xF) |
| (rest of disk)| <- lots of FAT32's and Linux ext2's
| | in here (swap, /usr, /var, /home, etc)
| |
>8.4GB -----------------
So the 1024 cylinder barrier is somewhere in the middle of that
ExtendedX. The alternative would be having a standard Extended partition
ending before the 1024 cylinder, and creating one large ext2 partition that
spans the barrier and goes to then end of the disk. With a 13 GB disk, for
example, that would result in a humongous 6 GB ext2 partition.
I guess this all really comes down to kernel support and
mount/umount support for ext2's within ExtendedX. Unfortunately, I don't
have a large drive to test this idea out on. I'm asking this question to aid
friends who will soon be grappling with this problem.
Thanks!
Ahilan
------------------------------
From: Bruce Barnett <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.network,comp.protocols-tcp-ip,linux.dev.ppp
Subject: FTP halts, no TCP window
Date: 15 Jan 1999 14:09:35 GMT
I don't know if this problem is a bug in the implementation of PPP on
Linux, a lack of resources on my machine, or a failure of my
understanding of the TCP stack.
I'm using RedHat 5.2, Kernel 2.0.36, PPP 2.3.5 and a V.Everything modem
Netscape 4.07.
I started a ftp to another system, (started from netscape)
transferring a 11MB file. In the middle of the transfer, the FTP
stalled. I started up tcpdump, and it shows:
08:10:55.790560 abc.com.64905 > grymoire.com.6470: . 2065485210:2065485211(1) ack
985442430 win 8760 (DF) [tos 0x10]
08:10:55.790560 grymoire.com.6470 > abc.com.64905: . ack 0 win 0 (DF)
08:14:55.740560 abc.com.64905 > grymoire.com.6470: . 0:1(1) ack 1 win 8760 (DF) [tos
0x10]
08:14:55.740560 grymoire.com.6470 > abc.com.64905: . ack 0 win 0 (DF)
08:18:55.720560 abc.com.64905 > grymoire.com.6470: . 0:1(1) ack 1 win 8760 (DF) [tos
0x10]
08:18:55.720560 grymoire.com.6470 > abc.com.64905: . ack 0 win 0 (DF)
08:22:55.700560 abc.com.64905 > grymoire.com.6470: . 0:1(1) ack 1 win 8760 (DF) [tos
0x10]
08:22:55.700560 grymoire.com.6470 > abc.com.64905: . ack 0 win 0 (DF)
08:26:55.680560 abc.com.64905 > grymoire.com.6470: . 0:1(1) ack 1 win 8760 (DF) [tos
0x10]
08:26:55.680560 grymoire.com.6470 > abc.com.64905: . ack 0 win 0 (DF)
08:30:55.660560 abc.com.64905 > grymoire.com.6470: . 0:1(1) ack 1 win 8760 (DF) [tos
0x10]
08:30:55.660560 grymoire.com.6470 > abc.com.64905: . ack 0 win 0 (DF)
pppstats says:
IN PACK VJCOMP VJUNC VJERR | OUT PACK VJCOMP VJUNC NON-VJ
11262230 25549 18559 2113 0 | 7527470 26254 17414 3459 5381
Apparently the TCP stack on my machine has no buffers left, and the
file transfer therefore stopped. I have a 32K system, and top shows 1.2MB
Free. Swap has 128MB free. vmstat agrees, and buff=248, cache=9168.
I have the memory. Yet TCP halted because of insufficient buffers.
I tried to kill netscape with a HUP signal, and the download
process didn't quit. kill -15 didn't work either. I had to kill -9
netscape. At which point, The 6MBytes transferred were then deleted,
and 40 minutes of downloaded was wasted.
What is causing the problem here? PPP Netscape? the TCP stack?
Linux's memory? Any suggestions?
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 15 Jan 1999 02:44:37 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 14 Jan 1999 18:18:12 GMT, Perry Pip <[EMAIL PROTECTED]> wrote:
>On Mon, 11 Jan 1999 16:47:37 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>And how is that related to whatever I said? I was just noting that
>>there is really very little interest on coding in C instead of C++.
>
>Oh. Really? How does the fact that no one wants to use a C "extension" to
>a C++ toolkit indicate that there is very little interest on coding in C
>instead of C++. Did it ever occur to you that people who want to program
>in C are busy coding away in native C toolkits, i.e GTK+??
There are several effects here:
a) People that want to use C++ tend towards Qt, and people that want to
use other languages tend to shy away from Qt.
b) Secondary language wrappers take additional time and effort to
generate.
Thus, a C wrapper of Qt won't be quite as up to date as the native C++
bindings.
c) The extra wrapper introduces more code, thus potentially reducing
reliability and likely increasing code size.
Thus, a C wrapper for Qt will be bigger and can introduce bugs. Not
because C is bad, but because of the "impedance difference" that C is
not identical to C++.
Put these things together, and they represent a nice set of reasons for
people who prefer programming in C to want to avoid Qt.
--
Be warned that typing "killall name" may not have the desired
effect on non-Linux systems, especially when done by a privileged user.
(From the killall manual page)
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 15 Jan 1999 02:50:58 GMT
In comp.os.linux.development.system Frank Sweetser <rasmusin> wrote:
> really? so people working on a corporate environment should be able to do
> things like setting their NT PDC to whatever machine they like, or screwing
> around with the mail relay?
Depends. If you're talking about developers where they need to do things
with a PDC that will break everything else, and this _has_ to be done to
get the next generation of software out, then yes they _do_ need to
reset to use a different PDC than the rest of the company. This means that,
if the company has a configuration item naming the PDC that is set to
override any local settings for all machines, there needs to be some way
to override the override.
Ditto for an outside consultant who needs to attach to the local network
for some reason. If he's running the same word processor as the company
and the company admins have set a top-down policy that all machines on
the network must use configuration item X that will render his word
processor inoperative on his machine because the documents he has depend
on having that configuration item be other than X, he needs some way to
overrule the company policy regardless of what the company admins may have
set up.
Note: I'm more sensitive to this because, as a developer, I regularly work
on software that's 3-4 releases ahead of what the rest of the company is
using, and often my projects are specifically to rework the software to
use a completely different configuration because it's going to do things
in a completely different way. If we couldn't overrule mandatory policies,
we'd either not be able to run and test the new software or we'd crash
everything else in the company every time we turned something on.
> if the admins decided to hardcode the printer, then the admin did something
> pretty stupid. just because values from the top of the tree *can* be
> forced doesn't mean they're *always* forced.
And often at a company they _will_ be forced from the top, and inevitably
there will be situations where this will be inappropriate ( maybe because
the company admins simply didn't ever think that this situation would come
up ). If your configuration system doesn't allow the local machine to
ignore mandatory top-down policies, you'll end up with a situation where
the $1k/hour consultant can't print the report the CEO _must_ have for
the board meeting in 15 minutes, and about 15 minutes after that your
configuration system will no longer be in use no matter how good it is
otherwise. This would be a Bad Thing.
--
Contrary to popular belief, Unix is user friendly. It just happens to be
very selective about who its friends are.
-- Kyle Hearn
------------------------------
From: [EMAIL PROTECTED] (Perry Pip)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jan 1999 04:04:29 GMT
On Fri, 15 Jan 1999 17:20:47 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>In article <77ma2l$usm$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>[Snip some reasonable reasons to not use Qt from C]
>
>1) Don't all these arguments apply equally well to any language binding?
No they don't. I stated why in a previous post. See Steve's post in this
thread some more concrete explainations why.
>2) Wouldn't those who would be discouraged by the poor Qt C binding first
> have to download it? I mean, I will even say that it is not really a
> good one, but as I said, people wouldn't even download it to see if
> it sucks. At least I would do it like that.
>
I don't think many expected it to be good. Furthermore, I think most
people who are interested in open source C GUI programing are already
involved in Gtk. In other words, even if you wrote a C binding to Qt
that was a good as native C programming in Gtk, and had a license that I
equally liked, I would still stay with Gtk because I already know it.
Some day though, I'll probably use the python, perl, or some other
binding as well. I'll stay with GTK because I already know the widgets.
Perry
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Open Configuration Storage - was Registry for Linux
Date: 15 Jan 1999 02:44:31 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 14 Jan 1999 06:53:58 GMT, George MacDonald <[EMAIL PROTECTED]> wrote:
>Christopher Browne wrote:
>> But a tool that exported this into a form where it *looked* like a
>> virtual file system (like /proc) would allow one to readily use existing
>> file management tools to examine system configuration. And possibly
>> even manipulate it, given the ability to write to the "virtual files."
...
>> We 'win' if we can get a suitable representation that lets us use
>> existing tools 'for free.'
>Using /proc a lot myself, I rather like this idea. If I understand
>correctly a loopback file system would allow the implementation
>to be a program vs in the kernel.
I think so. I have yet to make use of loopback for anything useful.
Unfortunately, this provides a Linux-specific approach to this, and
further, one which requires a particular kernel function, which makes me
a little uneasy, from two perspectives:
a) It means that we have to "impose" a particular kernel configuration
on users of this facility.
b) It isn't friendly to other systems (FreeBSD, Hurd, other "official
UNIXes") that might be able to use this sort of functionality.
What The World Probably Needs is some common "loopback scheme" where the
same "front end" code can be connected using a common interface to Linux
and some of the BSDs.
Make sure that the common interface isn't dependent on things that users
will have to fool with very much, so that it is *easy, easy, easy* to
connect things to this "generic loopback" system, whether we're talking
Linux 2.0.x, 2.1.x, 2.2.x, or FreeBSD [whatever] or OpenBSD [whatever].
Given some reasonable population that uses the scheme, this can be
enough to encourage its adoption elsewhere.
>In my original plan I was thinking about combining the
>"system config tree" with the "user config tree" to provide
>a config tree. My initial thoughts were to use "helper processes".
>These could be called "store managers", and thier purpose
>would be to do the notification for config change listeners
>as well as other things such as performance improvements.
>
>Your probably wondering about having a "user store" process.
>I figured it would be better to also have a per user process vs just
>one system daemon. Partially because of load distribution,
>partially because of security issues(i.e. when writing a
>file in user space the process needs to be setuid to
>the appropriate user so the file ownership works). This is
>similar to what sendmail does when processing mail for
>a particular user.
That sounds pretty sensible. If a *LOT* of messing around with
configuration is taking place, it makes sense to have multiple processes
around.
- An extra couple processes that sit largely idle won't be costly;
- If you reduce the likelihood that any process will become a
bottleneck, that's also good.
>The only problem I see with this idea is that the "object
>names" would be limited to the normal file name space
>limitations. Not a huge limitation.
Workarounds should be possible.
>How did you envisage implementing it? As a kernel module
>or a user space process? Would you still keep user
>config settings under the users space i.e. $HOME?
>I have several reasons for wanting to do it that way, a big
>part is that a user can copy there $HOME and all
>there settings get copied.
User space, for sure.
Having user-specific config sit in $HOME has the benefits you indicate,
as well as the consideration that it can be NFS mounted to multiple
systems.
--
"take USABLE from UNSTABLE and you get NT"
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
** 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
******************************
