Linux-Development-Sys Digest #223, Volume #6 Wed, 6 Jan 99 01:14:15 EST
Contents:
Re: Registry for Linux - From the top (was Bad Idea) (Matthew Hannigan)
Re: Why I'm dumping Linux, going back to Windblows (Namtog)
Re: interrupted system calls (Brian McCauley)
Redefining time_t (William McBrine)
Re: Kernel v2.2 (Piniek (aka Piotr Ingling))
Re: Registry for Linux - Bad idea (Frank Sweetser)
Re: silly question (Matthew Hannigan)
spin_lock* and SMP (Martin Recktenwald)
Linux 2.0.35 - Linux 2.0.36 (Jan Hühne)
Re: GUI, The Next Generation (H. Peter Anvin)
Re: Why I'm dumping Linux, going back to Windblows (Gordon Scott)
Re: things I'd pay to have developed for Linux... (Pete Zaitcev)
Glibc2.0.7 where is it ? (Matt)
Re: Sound Blaster Live! (Piniek (aka Piotr Ingling))
Re: Linux 2.0.35 - Linux 2.0.36 (Craig Kelley)
Re: GUI, The Next Generation (Derek B. Noonburg)
Re: Registry for Linux - From the top (was Bad Idea) ([EMAIL PROTECTED])
Re: things I'd pay to have developed for Linux... (Leslie Mikesell)
Printing broke with 2.2.0-pre4 (David Ronis)
Re: Registry for Linux - Bad idea (Tristan Wibberley)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Matthew Hannigan)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - From the top (was Bad Idea)
Date: 6 Jan 1999 02:28:39 GMT
In article <76u1u0$tc4$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>>
>> > - apps must be restarted
>>
>> A well designed application doesn't require this, it just needs to be
>> told via SIGUSR1 or such to reread it's config and continue gracefully.
>> You can do this with a simple tool that knows how to tell applications
>> to do this. (and no, doing it automatically as soon as a change is made
>> to the config is not good enough, the superuser must do it).
>
>I agree, application state should be left to the app. SIGHUP seems to be the
>standard signal for reloading, but I have encountered apps in the past that
>died rather than reloading on a SIGHUP. Either way it's probably not wise to
>send a signal to an app if you cant be certain what it will do.
Indeed.
SIGHUP is only used to tell daemons to restart internally.
Thats because HUP (hang up) is not applicable to a daemon
because it doesnt have an associated terminal, and so the
authors of daemons figure they can reuse it.
SIGUSR{1,2} are probably appropriate in general.
--
-Matt
------------------------------
From: [EMAIL PROTECTED] (Namtog)
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: 6 Jan 1999 03:22:09 GMT
This newsgroup is starting to sound more like alt.slack eveyday. Namtog
------------------------------
From: Brian McCauley <[EMAIL PROTECTED]>
Subject: Re: interrupted system calls
Date: 05 Jan 1999 19:27:28 +0000
[EMAIL PROTECTED] (Constantinos A. Kotsokalis) writes:
> signal(SIGALRM, alh);
> alarm(5);
> tmp = recvfrom(sock, (void *)buf, 4, 0, &sender, &sender_len);
> According to POSIX.1 (and Dr. Stevens ;-)) this should wait for
> five seconds (provided there is a time server at port 37), then
> catch SIGALRM, print ``Alarm caught'' and return from the recvfrom()
> system call with a value of -1 and an error of interrupted system
> call - then exit.
Really? I thought POSIX explicitly did not define the behaviour of
signal().
Use sigaction() not signal().
--
\\ ( ) No male bovine | Email: [EMAIL PROTECTED]
. _\\__[oo faeces from | Phones: +44 121 471 3789 (home)
.__/ \\ /\@ /~) /~[ /\/[ | +44 121 627 2173 (voice) 2175 (fax)
. l___\\ /~~) /~~[ / [ | PGP-fp: D7 03 2A 4B D8 3A 05 37...
# ll l\\ ~~~~ ~ ~ ~ ~ | http://www.wcl.bham.ac.uk/~bam/
###LL LL\\ (Brian McCauley) |
------------------------------
From: [EMAIL PROTECTED] (William McBrine)
Subject: Redefining time_t
Date: 5 Jan 1999 19:45:08 GMT
Here's part of a discussion that took place recently on the Fidonet Linux
echo. Someone said that the Y2038 problem would be fixed when everyone
converted to 64-bit systems; this was my response. OK, someone tell me why
I'm wrong...
=====================================================================
System: Doc's Place Bbs Online.
Area: LINUX
Date: 12-09-98 11:03
From: WILLIAM MCBRINE
To: BRUCE KINGSBURY
Subj: y2k
=====================================================================
-=>BRUCE KINGSBURY wrote to JUSSI HAMALAINEN <=-
BK> The [y2038] problem will fix itself;
A dangerous assumption -- that's probably just what the programmers
responsible for y2k problems thought.
I'd like to see it fixed now, if possible, while date problems are still
on everyone's minds. After the y2k "crisis" loses its momentum, things
might just slide along until 2036 or so. There's bound to be plenty of old
32-bit software still running at that time, and if the date problem isn't
fixed now, it might not be done in time.
On my 32-bit Linux system, gcc 2.7.2.1 already supports the "long long"
type, which is 64 bits. time_t could be changed to a long long. (On my
32-bit NetBSD system, off_t is already a long long. Linux could benefit
from that, too, as it allows files larger than 4 gigs.)
... The sex was so good, even the neighbors lit cigarettes.
--- MultiMail/Linux v0.20
--
William McBrine | http://www.clark.net/~wmcbrine/
[EMAIL PROTECTED] | ./\./\./\./\./\./\./\./\./\./\.
------------------------------
From: [EMAIL PROTECTED] (Piniek (aka Piotr Ingling))
Subject: Re: Kernel v2.2
Date: Tue, 05 Jan 1999 19:31:47 GMT
Reply-To: [EMAIL PROTECTED]
Dnia Mon, 04 Jan 1999 17:53:31 -0800, Edward Lee <[EMAIL PROTECTED]>
napisa³(a):
[...]
>Where did you get the modules package to compile 2.1.132?Did you find a newer
>modules package in debian somewhere?
>I need the "-k" option of genksyms in the modules package.
>With modules-2.0.0 (in sunsite & tst-11 mirrors), i can't even compile the
>kernel.
>
I guess you mean modutils? Go to your nearest kernel.org mirror (links are on
www.kernel.org) and from the /pub/linux/kernel/v2.1 directory get the
modutils-2.1.121.tar.bz2
Piotr Ingling
e-mail: [EMAIL PROTECTED]
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 05 Jan 1999 14:30:57 -0500
Tristan Wibberley <[EMAIL PROTECTED]> writes:
> Frank Sweetser wrote:
>
> > 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.
>
> IMHO, this can be done using a network filesystem such as CODA, then the
> server just gives the configuration and the software accesses it as
> normal. You get encryption (?) and cacheing to boot. I have another
> message somewhere (very recently) about this.
that's one option. and it does give those advantages. however 1) last
time i looked, CODA was pretty difficult to set up, and 2) program authors
still end up writing their own config file parsers. for most programs, the
ability to simply call something like get_config(option_name) instead of
doing it manually will completely eliminate the need to muck about with
groking the config files manually.
--
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
INTERCAL. Designed very early one May morning in 1972 by by two
hackers who are still trying to live it down.
------------------------------
From: [EMAIL PROTECTED] (Matthew Hannigan)
Subject: Re: silly question
Date: 6 Jan 1999 02:47:23 GMT
In article <[EMAIL PROTECTED]>,
Horst von Brand <[EMAIL PROTECTED]> wrote:
>
>[...]
>
>>>I have looked, maybe I am dense, but, I would like to do something like:
>>>
>>>xcopy *.cpp -s -e -h -c ../anotherdir
>>>
>>>This will copy all of the files that end with .cpp to another directory,
>>>recreating the directory structure with them. If an error happens it
>>>will continue.
>>
>Easy, one-liner (using bash's $(...), others use backquotes):
>
> cd sourcedir; tar cf - $(find . -name "*.cpp") | (cd destdir; tar xf -)
Ya have to be careful, since the find might overflow a bash
limit on length of a command line. Also, be paranoid and
use && rather than ; in case you make a typo in the dir names
and end up overwriting stuff in the current dir!
I'd use something like:
cd sourcedir && find . -name "*.cpp" -print |
cpio -cpdmu destdir
I don't claim this to be error free. This sort of question
comes up in comp.unix.* often. It's probably in the FAQ.
The complete, general, portable, error free solution is
surprisingly hard to come up with.
--
-Matt
------------------------------
From: [EMAIL PROTECTED] (Martin Recktenwald)
Subject: spin_lock* and SMP
Date: Tue, 05 Jan 1999 21:25:01 +0100
Reply-To: [EMAIL PROTECTED]
Hi,
I have some questions regarding spin_lock´s and SMP although I already
read Documentation/spinlocks.txt
- Is it possible that an interrupt for a device is executing on two
(or even more) processors at once, i.e. processor 1 gets an
interrupt for device foo and begins to execute its ISR and then
another interrupt _for the same device_ happens which is executed by
processor 2?
- If yes, it´s necessary to have some kind of lock around critical
regions. What lock should I use? spin_lock()? spin_lock_irq() (seems
quite useless because it seems to turn interrupts off only for the
current processors which should be off when executing the ISR anyway
- at least I think so) or just a simple spin_lock() (most likely) or
even spin_lock_irqsave()?
- What about accesses to critical data structures that could be
accessed from interrupts and syscalls? Should they be protected by
spin_lock_irq() or by spin_lock_irqsave()? In other words, what
exactly is the difference between these two functions? Is it just as
in the following cli()/sti() example
void foo() { cli(); sti(); }
void bar() { save_flags(); cli(); foo(); critical_stuff();
restore_flags(); }
where save_flags()/restore_flags() should be used in foo() because
it could be called with interrupts turned off or is there anything
else why I should use the irqsave()-version? (In short, is the
irqsave() version only necessary in functions which could be
executed with interrupts turned off?)
- And the last question: Could the same bottom half be running on two
different CPUs at the same time? (Which seems quite likely iff the
same ISR could be running on two different CPUs at the same time.)
Ok, that´s it (for now), if there is any other place where I could
find more information about this topic, please tell me. If you know
the answers, please tell me too, and if you only think you know the
answers, let me hear what you think :-)
TIA
Martin.
(Please answer as Followup or via Mail at [EMAIL PROTECTED] - sorry,
it might be that my Netscape is configured wrong, because it's not mine
...)
------------------------------
From: [EMAIL PROTECTED] (Jan Hühne)
Subject: Linux 2.0.35 - Linux 2.0.36
Date: Tue, 05 Jan 1999 20:05:01 +0100
Hello
I've got a problem!
I had SuSE-Linux 5.3 with the Kernel-Version 2.0.35 and now had it
updated on the Kernel-Version 2.0.36! And now on start up the Kernel
prints: module unable to load, this module is compiled for Kernel 2.035!
Must must I do to run my system fine????
Jan Hühne
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: GUI, The Next Generation
Date: 5 Jan 1999 20:39:19 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <d86k2.6993$[EMAIL PROTECTED]>
By author: Marco Anglesio <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> > I think the current UI is a lot like stering wheels on cars. I can't
> > think of a more stupid paradigm directing the vehical going 80 MPH, but,
> > I can't come up with anything better.
>
> Stick, perhaps? The wheel isn't a bad design as bad designs go, actually,
> and mapping directions through ninety degrees is not unknown in nature
> (bee dances, for example, map the horizontal through the vertical).
>
At high speed (no sharp turns), I usually drive a car much like flying
a yoke-equipped nosewheel airplane... using only three fingers on one
hand, and small hand movements. I think modern steering wheels make a
*lot* of sense: they allow large movements at low speeds, using
hand-over-hand, whereas at high speeds are quite sensitive to very
small movements.
A joystick would work well at high speeds, but probably would have
problems parallel parking.
It is interesting to note that airplanes have largely moved away from
the stick in favour of the yoke, which looks somewhat like a steering
wheel.
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bahá'í -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Misérables
------------------------------
From: [EMAIL PROTECTED] (Gordon Scott)
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: 5 Jan 1999 17:57:35 GMT
Reply-To: Gordon Scott <[EMAIL PROTECTED]>
Nick Andrew ([EMAIL PROTECTED]) wrote:
: In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Mike) writes:
: >I'm sorry! But this sentiment on the user interface is simply
: >nonsense. Wanting to learn or use "vi" as opposed to something like
: >super note tab is like wanting -- insisting-- on using a rock instead
: >of a hammer to do your cabinet making.
: In that case, I insist that all my rocks have functionality equivalent to
: vi(1).
That's a gem :-)
G. -- vi afficionado.
--
Gordon Scott Opinions expressed are my own.
[EMAIL PROTECTED] (official) [EMAIL PROTECTED] (backdoor)
[EMAIL PROTECTED] (home) http://www.apis.demon.co.uk
Linux ............... Because I like to _get_ there today.
------------------------------
Crossposted-To:
comp.os.linux.misc,comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: things I'd pay to have developed for Linux...
From: [EMAIL PROTECTED] (Pete Zaitcev)
Date: Tue, 05 Jan 1999 21:12:43 GMT
[EMAIL PROTECTED] (Leslie Mikesell) writes:
>In article <368e86a7.0@calwebnnrp>, Ilya <[EMAIL PROTECTED]> wrote:
>>
>>JFS.
>>LVM.
>>Mirroring and stuff
Ilya, check out the work of Ingo Molnar and support him.
Personally I do not agree on how he ties LVM and VFS but
he is very competent anyways.
>Does LVM do things you can't with RAID controllers like the Mylex DAC960?
>It will do the mirroring, hot spare swaps, etc. I think you can
>add drives to existing volume groups if you need to grow a partition
>but under Linux you would need to shut down and make the change
>through the card's ROM bios.
Think Big, Leslie. My workhorse system has 6GB of RAM and 56 drives
attached. Ultimately when your system grows it outgrows controller
boundaries. Then you need a software RAID to bind pieces together.
Besides, cost of hardware controllers mounts pretty quickly when
your system gets bigger. I imagine if Ilya could spare some megabucks
he spent on EMC or HP or other hardware RAID with Ingo he would
win big money in the end with software LVM.
--Pete
------------------------------
Date: Tue, 05 Jan 1999 20:25:19 -0500
From: Matt <[EMAIL PROTECTED]>
Subject: Glibc2.0.7 where is it ?
Crossposted-To: comp.os.linux.misc
Help,
I need to upgrade to glibc2.0.7 I have upgraded to 2.0.6 but
now I need glib2.0.7 does anyone know where I can get a download
of the locale, crypt and other files I need (like the 2.0.6 ones ?
Many thanks
Matt
------------------------------
From: [EMAIL PROTECTED] (Piniek (aka Piotr Ingling))
Subject: Re: Sound Blaster Live!
Date: Tue, 05 Jan 1999 21:13:00 GMT
Reply-To: [EMAIL PROTECTED]
Dnia 05 Jan 1999 15:18:32 +0100, [EMAIL PROTECTED] napisa³(a):
>"ncc1701d" <[EMAIL PROTECTED]> writes:
>[...]
>> So the next question is.... Anyone working on it? I'd be happy to beta test
>> as I really want sound but have no idea how to even attempt writing a driver
>> for the card....
>
>Hmm... I think the new sound driver project has a working SB-Live
>driver. What was it's name ... Alsa ?
>
Nope. There won't be a driver for SB-Live in ALSA unless Creative reveals the
tech specs for it. There's an announcement on it on the ALSA homepage
(http://alsa.jcu.cz).
Piotr Ingling
e-mail: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Craig Kelley)
Subject: Re: Linux 2.0.35 - Linux 2.0.36
Date: 5 Jan 1999 14:23:18 -0700
In article <[EMAIL PROTECTED]>,
Jan Hühne <[EMAIL PROTECTED]> wrote:
->I had SuSE-Linux 5.3 with the Kernel-Version 2.0.35 and now had it
->updated on the Kernel-Version 2.0.36! And now on start up the Kernel
->prints: module unable to load, this module is compiled for Kernel 2.035!
->Must must I do to run my system fine????
See the kernel-howto
You must make the modules for 2.0.36 and install them.
cd /usr/src/linux
make modules
make modules_install
(be sure that you have the desired modules selected in your kernel
configuration)
--
The wheel is turning but the hamster is dead.
Craig Kelley -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
------------------------------
From: [EMAIL PROTECTED] (Derek B. Noonburg)
Subject: Re: GUI, The Next Generation
Date: 5 Jan 1999 23:32:03 -0600
[EMAIL PROTECTED] (Peter Samuelson) writes:
> [Derek B. Noonburg <[EMAIL PROTECTED]>]
> > Or how about this: holding down that useless left-windows key (on new
> > "Win95 keyboards") would instantly turn all windows translucent.
>
> Hey, you messing with my meta key? (Recall that X11 allows for
> separate meta and alt keys. I'm not sure who originally thought the
> world needed both, but thanks to the "useless key", XFree86 lets you
> have them.)
Who needs an alt key? :-)
Anyway - there are three keys to the left of my space bar. (The
control key is up next to the 'A' key, where all good emacs users put
it.) That still leaves an extra key.
Or a foot switch, like another followup mentioned.
> Your idea *does* have merit, though. The colormaps would be a
> nightmare to maintain, but maybe future graphics cards could help out
> with some sort of hardware-managed layers with alpha channels. The
> GIMP on a graphics board, as it were.
On a TrueColor visual, this wouldn't be so bad. You'd have to force
all of the windows to redraw, and somehow munge the X colormap in the
process. Ugh, ok, this might be a little tricky. (Actually, it might
not be too hard on a modern 3D card -- just run each window through as
a texture, and draw them back to front with an appropriate alpha
setting.)
How about just drawing window title bars and borders? When you press
the magic key, all of the window contents vanish, leaving you with
just title bars and borders. You pick the window you want, it gets
moved to the front, and then everything redraws. This wouldn't look
as cool as translucency, but it would do pretty much what I wanted.
- Derek
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - From the top (was Bad Idea)
Date: Tue, 05 Jan 1999 21:58:25 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Andrew Morton wrote:
> > - no provision for local overrides (inheritance)
>
> I agree, this is awkward, but a well designed application makes this
> easily possible (and it's not difficult to do it). One solution I've
> seen is to have a number of files each inheriting from the next. Though
> I agree, the key/value pair method does make this easier. I think there
> is too much cruft on this argument for the discussion to continue in
> this thread or in THREE newsgroups. Start a new thread (leaving out the
> word registry - it's not) in comp.os.linux.development.apps and discuss
> the requirements, then look at how the current system doesn't meet
> those, and come up with ways to alter it (rather than scrap it).
Hear Hear.
>
> > - apps must be restarted
>
> A well designed application doesn't require this, it just needs to be
> told via SIGUSR1 or such to reread it's config and continue gracefully.
> You can do this with a simple tool that knows how to tell applications
> to do this. (and no, doing it automatically as soon as a change is made
> to the config is not good enough, the superuser must do it).
I agree, application state should be left to the app. SIGHUP seems to be the
standard signal for reloading, but I have encountered apps in the past that
died rather than reloading on a SIGHUP. Either way it's probably not wise to
send a signal to an app if you cant be certain what it will do.
> > What we're doing here is exploring the requirements and design of a
> > _new_ approach which will be uniform from end-to-end. Please stop
> > shouting at us - some good may come of all this.
>
> I don't think George is trying to do that, just get a uniform interface
> for the application programmer (As he keeps stressing the importance of
> the application, and not the administration).
I think the two are closely related. If there is a standard for storing app
specific configuration and it's intuitive, it could be extended to the system
level. This is the kind of thing that makes a system that is coherent and
behaves in a constant way.
>
> > A few random thoughts:
> >
> > - As one of our Microsoft friends pointed out in the halloween docs, the
> > OSS community is good at following tail lights. We are now almost in
> > the embarrassing position of being in the overtaking lane. It's time to
> > look ahead and to innovate. This will require some evolution of the
> > communication and management model.
>
> Change for changes sake... I think you're going to ruin you own idea
> thinking like that. The reason OSS plays catchup is because we don't
> have to scrap stuff and replace it for marketing purposes. If you're
> going to do this, do it because you have a specific problem that needs
> solving - That's why Linux is good, and why Windows isn't.
It's not for change's sake. George needs it. Others want it. Sounds to me like
there is a demand :-)
>
> > Can we please take this from the top?
>
> *VERY* good idea. I will join in and help.
Let's. I'm going to try to change the subject to this thread. I sure hope
dejanews does not puke on it this time...
Is anyone familiar with how NeXT (And soon Mac OS X) does things? User config
data is stored in ~/Library/SomeApp/, personal defaults for applications are
kept in a defaults database under ~/.NeXT and later ~/.OpenStep and probably
something else now that is MacOS X. The logical extension to this was
/NextLibrary for the system related stuff. They also have a browsable,
network and local hierarchy, NetInfo for other system related things. NetInfo
is more of a system level thing and is somewhat analogous to NIS, but has
some nice graphical tools for looking around and changing things. NetInfo is
not open source, so it's not possible for anyone to work from it.
-Rich
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To:
comp.os.linux.misc,comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: things I'd pay to have developed for Linux...
Date: 5 Jan 1999 23:34:24 -0600
In article <zaitcev.915570119@mallorn>, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
>
>>Does LVM do things you can't with RAID controllers like the Mylex DAC960?
>>It will do the mirroring, hot spare swaps, etc. I think you can
>>add drives to existing volume groups if you need to grow a partition
>>but under Linux you would need to shut down and make the change
>>through the card's ROM bios.
>
>Think Big, Leslie. My workhorse system has 6GB of RAM and 56 drives
>attached. Ultimately when your system grows it outgrows controller
>boundaries. Then you need a software RAID to bind pieces together.
The mylex scsi<->scsi array controller claims to allow up to 35 drives
(with a daughterboard) with up to 16 terrabytes to be mapped to a
single SCSI ID so you could hook 15 of these to a single normal
wide SCSI adapter. I think that would be big enough for me.
>Besides, cost of hardware controllers mounts pretty quickly when
>your system gets bigger. I imagine if Ilya could spare some megabucks
>he spent on EMC or HP or other hardware RAID with Ingo he would
>win big money in the end with software LVM.
If your system is busy, do you really want the main CPU doing that
kind of stuff? Dropping a Netapp box on the network sounds even
better. I suppose what we need is a cheap do-it-yourself equivalent.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: David Ronis <[EMAIL PROTECTED]>
Subject: Printing broke with 2.2.0-pre4
Date: 6 Jan 1999 03:52:53 GMT
I'm upgrading from 2.0.36 to 2.2.0-pre4 on an i486 with a postscript
printer connected to its parallel port. I'm now at the point where printing
a file causes the printer display to flash, but still nothing is printed.
Here's my setup:
crw-rw-rw- 1 root daemon 6, 0 Jan 5 20:39 /dev/lp0
crw-rw-rw- 1 root daemon 6, 1 Jan 5 20:42 /dev/lp1
crw-rw-rw- 1 root daemon 6, 2 Jan 5 20:42 /dev/lp2
crw-rw-rw- 1 root daemon 99, 0 Jan 5 20:46 /dev/parport0
crw-rw-r-- 1 root daemon 99, 1 Jan 5 20:48 /dev/parport1
crw-rw-r-- 1 root daemon 99, 2 Jan 5 20:48 /dev/parport2
Lp was set up as a module in the kernel:
CONFIG_PRINTER=m
CONFIG_PRINTER_READBACK=y
and I have the following in my conf.modules:
alias parport_lowlevel parport_pc
The messages file shows:
Jan 5 22:17:00 kirkwood kernel: parport0: no IEEE-1284 device present.
Jan 5 22:17:00 kirkwood kernel: lp0: using parport0 (polling).
I tried changing the setting in /etc/printcap to use /dev/parport0 directly,
but this didn't work either.
David Ronis
P.S., in case you're wondering, the printer worked under 2.0.36, the
only change being to replace /dev/lp1 by /dev/lp0 in printcap.
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Tue, 05 Jan 1999 22:14:50 +0000
Reply-To: [EMAIL PROTECTED]
Frank Sweetser wrote:
>
> Tristan Wibberley <[EMAIL PROTECTED]> writes:
>
> > Frank Sweetser wrote:
> >
> > > 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.
> >
> > IMHO, this can be done using a network filesystem such as CODA, then the
> > server just gives the configuration and the software accesses it as
> > normal. You get encryption (?) and cacheing to boot. I have another
> > message somewhere (very recently) about this.
>
> that's one option. and it does give those advantages. however 1) last
> time i looked, CODA was pretty difficult to set up, and 2) program authors
> still end up writing their own config file parsers. for most programs, the
> ability to simply call something like get_config(option_name) instead of
> doing it manually will completely eliminate the need to muck about with
> groking the config files manually.
In answer to:
1) instead of coming up with some new hard to configure scheme, wouldn't
it be more productive to help make CODA easy to configure?
2) then a couple of libraries for parsing flat text will be most
appropriate no? Simplest to implement.
The talk of complex network databases is far too premature at the moment
- everyones always in such a rush to "innovate".
I have to admit that the overriding values for local machines will be
awkward to implement using the network fs scheme, but I hope to figure
out a way of doing it that's quite easy to configure on the backend, and
transparent on the client. Maybe write some scripts to help.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
** 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
******************************
