Linux-Development-Sys Digest #213, Volume #6 Mon, 4 Jan 99 18:14:30 EST
Contents:
Re: WDM Emulator, anyone? (Mark Roddy)
Re: Registry for Linux - Bad idea (Frank Sweetser)
binfmt-0064 module (David Ronis)
Re: x windows redhat (David T. Blake)
Re: things I'd pay to have developed for Linux... (Johan Kullstam)
Re: WDM Emulator, anyone? (mlw)
Re: silly question (mlw)
Re: pthread debugging ("George Talbot")
Re: Registry for Linux - Bad idea ([EMAIL PROTECTED])
Persistent sound hangs (2.0.0 - 2.2.0pre4 tested) (Erik Inge Bolso)
Re: Registry - Already easily doable, in part. (Bulent Murtezaoglu)
Re: silly question (Tristan Wibberley)
Re: HELP w/ Yamaha OPL3-Sa Sound (Daniel N. Sands)
Sound Blaster Live! ("ncc1701d")
Re: Registry for Linux - Bad idea (Frank Sweetser)
Re: Matrox Millenium G-200 Drivers (Torbjorn Lindgren)
Re: silly question (Peter Pointner)
Re: Soundcard with Digital in? (Clifford T. Matthews)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Roddy)
Crossposted-To: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: WDM Emulator, anyone?
Date: Mon, 04 Jan 1999 15:44:24 GMT
I think it is both do-able and a good idea too, which is not the same
as saying I'm going to commit any of my time to it.
This hurts microsoft right where they are vulnerable. They've defined
the kernel portability layer between windos98 and NT (WDM) so they
have to more or less stick to the definition so that the hardware
vendors can write drivers that actually work in both kernels. M$ wants
to get to one OS base so they are pushing HW vendors to use WDM.
However, you should be aware that currently only a very few windos98
drivers are 'WDM' drivers and no (none zero zed zilch) NT drivers are
WDM drivers (for now anyway.) So this is not a panacea. It won't, for
example, solve the winmodem or hp printer problems. (And AFAIC the
lack of support for these two pieces of hardware leaves linux doa on
the home desktop.)
So, as a long term strategic linux product: excellent idea. Immediate
benefit: nearly nothing.
p.s. see threads regarding "does linux need a registry?". You need one
if you do WDM.
p.p.s ISA pnp support in linux is a joke. It makes windos isa pnp look
like a miracle of programming greatness.
On Mon, 04 Jan 1999 14:43:10 +0000, mlw <[EMAIL PROTECTED]> wrote:
>This is my second post about this, I can't believe there are no takers
>this far.
>
>I want to write a WDM emulator for Linux.
>
>It should work with Wine, of course. If there are NT or Linux kernel
>hackers that are interrested, please e-mail me directly.
>
>We will start with the generic NT DDK functions as a statically linked
>library. We will then compile DDK samples into native Linux drivers.
>
>Once that step is done, we will write a binary loader for 3rd party
>drivers.
>
>There has to be someone interrested out there!
>
>Send replies to [EMAIL PROTECTED]
Mark Roddy
_
------------------------------
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 15:28:35 -0500
[EMAIL PROTECTED] writes:
> In article <[EMAIL PROTECTED]>,
> Robert Krawitz <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] writes:
> > >
> > > I dont see how this is a valid argument. So it's something extra.
> > > Why is that "wrong"? What does this have to do with centralizing the
> > > configuration data? There cant be progress without change.
> >
> > All other things being more or less equal, the more things that have
> > to be running in order to boot, the more chances there are for
> > something to go wrong. If some kind of database server needs to be
> > running in order just to boot, it's just one more place where
> > something might break.
>
> Many who have spoke in this thread, inclusing myself want to stay away from a
> conventional database server if possible. I agree with you that it is more
> room for failure.
*mandatory* databases are. why not have a library flexible enough to deal
with multiple data types, including flat text, databases, CORBA, etc?
--
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: David Ronis <[EMAIL PROTECTED]>
Subject: binfmt-0064 module
Date: 4 Jan 1999 20:47:00 GMT
I've just upgraded an i586 to 2.2.0-pre4, where a.out support was
configured as a module. It works although some older programs trigger
a can't locate module binfmt-0064 message. I'm pretty sure all I have
to do is to add an alias to binfmt_aout in conf.modules. What other
aliases/special module numbers are necessary?
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: x windows redhat
Date: 04 Jan 1999 07:51:51 -0800
[EMAIL PROTECTED] (User470357) writes:
>
>5.1 I have redhat on a 225cds satellite toshiba labtop.
The web site
http://www.geocities.com/SiliconValley/Hills/3140/220redhat.html
suggests that Xconfigurator finds the correct modes all
by itself.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
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: 04 Jan 1999 13:25:19 -0500
Ilya <[EMAIL PROTECTED]> writes:
> JFS.
> LVM.
these would be nice.
> Mirroring and stuff
i think linux already supports this. raid controllers exist to
duplicate harddrives. scripts can launch tar and/or ncftp from cron
entry just like any other unix.
> Please.
--
johan kullstam
------------------------------
From: mlw <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: WDM Emulator, anyone?
Date: Mon, 04 Jan 1999 16:10:14 +0000
Mark Roddy wrote:
>
> I think it is both do-able and a good idea too, which is not the same
> as saying I'm going to commit any of my time to it.
>
> This hurts microsoft right where they are vulnerable. They've defined
> the kernel portability layer between windos98 and NT (WDM) so they
> have to more or less stick to the definition so that the hardware
> vendors can write drivers that actually work in both kernels. M$ wants
> to get to one OS base so they are pushing HW vendors to use WDM.
I am not saying this should be done to hurt Microsoft. Far from it, I
want to do this to help Linux. These two motives are not the same thing.
>
> However, you should be aware that currently only a very few windos98
> drivers are 'WDM' drivers and no (none zero zed zilch) NT drivers are
> WDM drivers (for now anyway.) So this is not a panacea. It won't, for
> example, solve the winmodem or hp printer problems. (And AFAIC the
> lack of support for these two pieces of hardware leaves linux doa on
> the home desktop.)
Actually, WDM starts with the NT Driver model. We would probably start
with the NT DKK.
My idea is to first write a static library with which Windows NT or WDM
drivers can be compiled and linked to make native Linux drivers. Later
we will add a binary loader.
>
> So, as a long term strategic linux product: excellent idea. Immediate
> benefit: nearly nothing.
I think NT Winmodems should work. They should be the next priority after
the initial framework.
>
> p.s. see threads regarding "does linux need a registry?". You need one
> if you do WDM.
I would implement the registry as a heirachal set of directories and
config files.
>
> p.p.s ISA pnp support in linux is a joke. It makes windos isa pnp look
> like a miracle of programming greatness.
PnP could be done. For the drivers.
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit the Mohawk Software website: www.mohawksoft.com
------------------------------
From: mlw <[EMAIL PROTECTED]>
Subject: Re: silly question
Date: Mon, 04 Jan 1999 20:03:50 +0000
Peter Pointner wrote:
>
> mlw <[EMAIL PROTECTED]> wrote:
>
> > Actually, I would love to see Xcopy on Linux. "xcopy /s /e /h /c this
> > there" would be great.
>
> I can't remember all the options, but are you sure "cp -a" doesn't do
> what you want?
>
> Peter
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.
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit the Mohawk Software website: www.mohawksoft.com
------------------------------
From: "George Talbot" <[EMAIL PROTECTED]>
Subject: Re: pthread debugging
Date: Mon, 4 Jan 1999 11:27:42 -0500
Upgrade to RH5.2. The GDB patch isn't enough. There's also patches to
glibc and glibc-profile to get this to work.
--
George T. Talbot
<[EMAIL PROTECTED]>
------------------------------
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:37:52 GMT
In article <76r0va$tnq$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Craig Kelley) wrote:
>
> And yet nobody has been able to come up with anything better.
Because everyone is too busy bashing the alternatives rather than trying to
create one.
>
> It is *not* dated, unscalable nor unwieldy. Using tools such as
> secure shell or rdist one can easily write a program to update
> numerous machines automatically. It took me less than an hour to come
> up with a perl script which updates all of our Linux servers
> automatically. It does this using RSA encryption, and requires each
> machine's root password to be typed in before it will execute. The
> reason why these things are so easy to construct: they use PLAIN OLD
> TEXT and standard I/O.
You, are a system administrator. You know perl, you're familiar with rdist,
sounds to me like you used PGP to encrypt outbound data. Clearly, you have a
command over the systems involved here.
Not everyone does.
>
> As for it being expensive for "administration and training resources",
> I have one word: linuxconf. I think you will be very surprised when
> RedHat 6+Gnome+linuxconf hits the shelves.
I cant wait. I hope it becomes the standard adminsitration tool. I hope it
fits on the rescue floppy too.
>
> Linuxconf already works just fine, and it has managed to centralize
> more configuration information in one easy-to-use place than Microsoft
> has ever dreamed of (SMC is just a ghost of what linuxconf can already
> do).
It's my understanding that linuxconf works by directly accessing the text
files when it needs to do work. Wouldn't it be nice if linuxconf only had one
interface into all the configs? Wouldn't it be nice if someone who is using
vi or emacs on a config file would not clobber changes that are pending in
linuxconf? Wouldn't it be nice if the folks at RedHat could concentrate on
making the interface truly first rate rather than coding plugins and allowing
for software changes everytime the author of a program gets industrious?
-Rich
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Erik Inge Bolso <[EMAIL PROTECTED]>
Crossposted-To: revue.linux-kernel
Subject: Persistent sound hangs (2.0.0 - 2.2.0pre4 tested)
Date: 4 Jan 1999 17:57:30 +0100
Hi all.
I'm having very persistent trouble using the standard sound drivers, I
suspect a hardware glitch, either in the soundcard or in the mainboard
chipset.
The computer randomly hangs solid when it completes playing a sound file,
probably when releasing the sound device. The only thing I can do when
this occurs is cycle the power or press the reset button. (This happens in
all OS's I've tried as well, Linux/MS-DOS/several windoze versions - so
probably a hardware problem)
This is probably a hardware problem. But if a software workaround is
possible, this list probably is the place to go for help.
Hardware:
Old Hyundai ISA-only 486 mainboard, w/VIA VT82C480 chipset...
(this machine was low-end when I bought it in '94 :-)
SoundBlaster 16 Value (firmware 4.11) at
IO - 0x220, IRQ - 7, DMA - 1, DMA16bit - 5
Alan? I recently saw you saying something on the list to a guy who seemed
to have the same problem... suggestions? Maybe VIA has been buggy for a
longer time than we thought?
I've tried changing IRQ's, to no avail. Running the system for a long time
without any sound driver and watching for use of DMA 1 and/or 5 by other
cards has gone to no avail. And there is no problem with I/O 0x220, as far
as I can ascertain.
(I talked to a guy who had the same chipset+soundblaster combination ...
he solved his problem by buying a cheap soundblaster-clone... wimp's way
out *grin*)
(A CC: to [EMAIL PROTECTED] of any replies would be welcome)
--
Erik I. Bols� <knan at mo.himolde.no>
The White Tower: http://home.sol.no/~eibolsoe/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Bulent Murtezaoglu <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 04 Jan 1999 11:59:23 -0500
>>>>> "AM" == Andrew Morton <[EMAIL PROTECTED]> writes:
AM> This is workable within a LAN. But what about a WAN?
Hmm, now I'm beginning to see. But I also think you are moving the
goalposts on me...
AM> Also the update distribution needs to be able to cope with
AM> uncontactable hosts. If I take my laptop home in the evening
AM> I'll miss those rdist updates.
I don't know what should happen in that case? What's being updated?
This does not saound like a configuration problem. Maybe you are
thinking sth. like Coda? (ie application data also)
AM> Of course a suitable distribution mechanism is available
AM> today. One which does store-and-forward, retries, route
AM> redundancy, error reporting, etc. email!
Yes, but if you worry about the late pm rdist, e-mail won't help you.
There's no guaranteed delivery time.
[...]
AM> The other problem here is that SIGHUP just says "something's
AM> changed". 'twould be better to know what has changed. This
AM> implies some srot of commit/rollback semantics.
Yes, but that's very heavy weight machinery for something simple, IMHO.
[...]
AM> A lot of the effort which is going into Win2k is related to
AM> the ability to manage a large number of servers and
AM> workstations from a few points. Data replication,
AM> distribution, etc. I wouldn't pretend to know a lot of the
AM> details, but I appreciate it's a formidable problem.
Well I don't think THEY know either. What we hear from Microsoft is
mostly marketing hype spewed by their FUD apparatus (THEM) -- we do not get
to talk to the developers. Part of MS's problem (and there is a
decent article on the web about this) is that they way they have been
doing things does not help them with the way they want to do them now.
[...]
AM> Oh I agree. The benefits of the Windows registry are minor:
AM> uniform syntax/structure, single API, one thing to
AM> backup/restore, can't think of much else.
Horrible access tools and no embedded comments... All fixable, but not
fixed. As for back-up, it depends on how disciplined your packaging
tools are in listing user supplied configuration files (ie do they
tell you about the config files that do not come with the package but
might be created by the user) In the worst case you could just tar up
/etc and some oddball conf. files that live outside it and the back-up
problem is solved. Actually the entire /etc is too much. I find I
can get away with about 1400 lines (gzipped and uuencoded to be
e-mailed to someplace safe) of selected config files and the output of
dselect --get-selections for debian (for system not user conf.) The
script that does this trivial if you have a list to feed to tar...
Incidentally, what makes things easier with distributions is a sane
convention and consistent reasonable defaults. As someone else
pointed out, one can think of this as layers of abstraction except the
layers do not need to be explicitly structured. If the defaults are
good, you end up with scripts which I find somewhat more convenient than
Microsoft's wizards that help you add the little bit of config that
cannot have defaults. You effectively get the superficial but easy
level by just not mucking with things that can have default values.
AM> The problems revolve around the fact that it's a local file
AM> rather than a network service. Look at it from the other end:
AM> the application should go out on the network and say "gimme
AM> some config". If that config is supplied by the local
AM> server's cache then that's the same as windows. But the
AM> server has the option of consulting a reference server, or of
AM> always punting the request elsewhere, or of passing it to a
AM> daemon for dynamic treatment, or...
Actually MS does have part of this functionality now. With Linux
the user preferences automatically move with the user if you're mounting
home (LAN not WAN). Of course if the server that has your home goes you are
stuck. But then we are talking about replicating user data also.
BM
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: silly question
Date: Mon, 04 Jan 1999 21:07:39 +0000
Reply-To: [EMAIL PROTECTED]
mlw wrote:
>
> Actually, I would love to see Xcopy on Linux. "xcopy /s /e /h /c this
> there" would be great. As for command.com, NO stop, you can't do that it
> is evil.
>
What does xcopy do? copy a filesystem? if so, the media need to be
identical so you can just 'cp /dev/this /dev/there'.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: [EMAIL PROTECTED] (Daniel N. Sands)
Subject: Re: HELP w/ Yamaha OPL3-Sa Sound
Date: 4 Jan 1999 17:16:55 GMT
Peter Samuelson wrote:
#-> [Ralph <[EMAIL PROTECTED]>]
#-> > I have a Yamaha OPL3-Sa sound card that is supposed to be Sound
#-> > Blaster compatible. When i configure the card under sndconf I've
#-> > tried regular, 16bit, and Pro settings w/ correct IRQ, DMA, and I/O
#-> > settings. My specific card is supposed to be Sound Blaster Pro
#-> > Compatible, which I have never gotten to work at all. NO Sound.
#->
#-> Is this the OPL3-SA1 or OPL3-SAx or what? In any case try the MSS
#-> emulation. Sound Blaster emulations generally don't work in Linux.
#->
#-> Recent development kernels have support for OPL3-SAx as well as
#-> OPL3-SA1 directly, though I don't think they do all that much besides
#-> link the relevant MSS stuff in.
Actually, they link in all of the compatibility: Sound Blaster, MIDI, and
WSS. Since they all use overlapping resources, it is impossible to load
the drivers separately.
---
If guns are outlawed, can we use swords?
------------------------------
From: "ncc1701d" <[EMAIL PROTECTED]>
Subject: Sound Blaster Live!
Date: Mon, 4 Jan 1999 11:14:26 -0600
Hi Guys,
I was just wondering if anyone using any version of Linux has sound working
with the Sound Blaster Live! sound card? I'm not having any luck at all
getting it going. My guess is that the card doesn't conform to any
standard's of PCI sound cards supported by Linux currently. If I run the
sndconfig utility it detects the card as UNKNOWN, and no manual selection of
the card works at all. The card works great in Win98 so I know it isn't
hardware problems I'm running into.
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....
Thanks
Jason
------------------------------
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 11:59:09 -0500
George MacDonald <[EMAIL PROTECTED]> writes:
> I want to be able to update the config from within an application, i.e.
> a preference type mechanism. I have been thinking about what it would
> take to create X resources on the fly, and update an application
> config file. In fact it could be several config files that are included
> in one X resource file. But this design requires X, which is not generic
> enough for all applications.
it shouldn't be too hard to set up a simplistic, probably inneficient
scheme using some gratuitous file locking. the difficult part, i think,
would be seperating system defaults in /etc/ from user preferences. if a
setting is specified in /etc/foo.conf but not in ~/.foo.conf, you wouldn't
want to write out the value to ~/.foo.conf unless it differed... hmm... i
think i might have just answered my own question, treat ~/.foo.conf as a
COW copy of /etc/foo.conf =)
> It is also missing many advanced features, such as ensuring changes
> are made atomically to multiple config files.
hmm... it should be fairly easy with a single config file. what kind of
scenario do you see where it would be updating multiple config files as a
single operation?
> >
> > > No typing/classifying of values so can't write one parser - see
> > > SNMP MIB's
> >
> > not sure what you mean here... would you mind clarying this a bit?
>
> Sure,
>
> SNMP = Simple Network Management Protocol,
> MIB = Management Information Base
okay... i'm familiar with the concept of SNMP, just didn't see how your
point applied here (good def of SNMP, though =).
> The MIB is a data file, it can be read by Network Management Systems which
> can then query the devices for information and or get/set config parameters.
> The really cool thing is that the NMS systems have *no* code that is
> written for the specific piece of hardware! i.e. new hardware can
> be supported just by adding new data files.
partially true... i think the reason that most network hardware works like
that is because so many of the values are shared (byte counts, packet
counts, errors, etc). for more advanced, often proprietary stuff (filters,
security) the software must be aware of the meanings of those values.
trust me, we've had to upgrade the NMS software on our machine here to deal
with new hardware in anything but the basic generic functions several
times...
however, to get back OT, i don't think this would be an issue, as the
config library would simply be handing back values for the requested keys
and letting the application deal with 'em from there.
>
> > > > No range specifiers so can't have independent tools validate
> configs > > shouldn't be hard for numerical values, not sure how it would
> apply to > strings.
>
> Well, one needs an external description to know what type the fields are.
>
> Strings are more complicated, some simple ones are length, list of
> valid OCTETS, ... This is an area where plug in modules might be useful.
fair enough. perhaps a strlen and valid charset? any other data types
beyond numeric, str, and groupings thereof?
>
> >
> > > No syncronized writes i.e. for multiple processes
> >
> > > No networking so I can pull config from another site
> > > No publishing so I can publish part of my config.
> >
> > what protocols would you propose using?
> >
>
> I was thinking of developing one, then also allowing SNMP, CORBA,
> RPC, HTTP, ... to be added as modules. Many of these are not
> required for small systems, which for the most part could get
> by with a small library. The above protocols would allow
> adaptation to existing large site managment mechanisms.
>
> The protocol I had in mind was an OO based extensible protocol
> which would allow security, encryption, authentication objects
> to be pushed in the protocol stream as needed.
>
> It would be easier to just say CORBA, but I don't want to be
> bound to it as it's not yet universal.
i like it, i like it.... an API with something like
get_key(char *key)
set_key(char *key, foo *value)
create_num_key(char *name, int upper_bound, int lower_bound)
create_str_key(char *name, foo charset)
write_config(pointer to the whole config tree)
also, what language were you planning on using?
i'm not sure it would be worth it to develop a new protocol and
accompanying server for it. to me, the most useful ones would be local
files, SNMP (fairly lightweight, for smallish networks primarily), SQL so
you can store 'em on a full-featured database for better scalability,
backups, transactions, etc, and HTTP (to make it simply, could use the same
file format as local files... would make writing the config files a little
harder - WebDAV, perhaps?) primarily for roaming users to get around
firewalls and low bandwidth configs. CORBA sounds like it would also be
well suited for this, and it seems to be getting more common nowadays.
i definatelly like the way this project is looking.... i'd be willing to
contribute, if you're interested.
--
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
"Hydroponics, that's what I like!"
------------------------------
From: [EMAIL PROTECTED] (Torbjorn Lindgren)
Subject: Re: Matrox Millenium G-200 Drivers
Date: 4 Jan 1999 17:13:04 GMT
David Fox <d s f o x @ c o g s c i . u c s d . e d u> wrote:
>"James A. Cleland" <[EMAIL PROTECTED]> writes:
>> supports the G200 AGP. Check out the xfree86.org website and look at the
>> release notes for Matrox cards. I'll bet you find your card is supported in
>> 3.3.3. I would also bet that someone else will respond to this post and
>> confirm this in short order.
>
>There are RPMS for XFree86 version 3.3.3 on developer.redhat.com,
>these will make upgrading easier. With these my G200 AGP works well.
Be carefull with those RPM's, they are dangerous! I installed them on
my machine but they caused Netscape to die very frequently (we're
talking 5 minutes before it died).
Yes, it was the current version rhcn*-3.3.3-6, with a Matrox G200...
Yanking them out and installing *RedHat*'s own 3.3.3 RPM from updates
[1] instead fixed this... The RedHat XFree86 rpm is actually one day
older than the latest rhcn version.
I also noticed that it was rather hard to go in that direction, RPM
didn't like it at all. It didn't recognize that XFree86-3.3.3 and
XFree-rhcn-3.3.3 was essentially the same package, so you had to use a
lot of force to make it behave (uninstall all of the -rhcn packages
with --nodeps, then installing the RedHat 3.3.3 packages).
1. ftp://updates.redhat.com/5.[012]/i386/XFree86-*
ftp://updates.redhat.com/4.2/i386/XFree86-*
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: silly question
Date: Mon, 4 Jan 1999 15:51:15 GMT
mlw <[EMAIL PROTECTED]> wrote:
> Actually, I would love to see Xcopy on Linux. "xcopy /s /e /h /c this
> there" would be great.
I can't remember all the options, but are you sure "cp -a" doesn't do
what you want?
Peter
------------------------------
From: [EMAIL PROTECTED] (Clifford T. Matthews)
Subject: Re: Soundcard with Digital in?
Date: 04 Jan 1999 08:05:34 -0700
>>>>> "Bill" == Bill Morgan <[EMAIL PROTECTED]> writes:
Bill> Za2 from Zefiro (?) has some driver support.
I spent a few tens of hours capturing digital audio with a ZA-2 using
the paid version of the ZA-2 option from 4front-tech
<http://www.4front-tech.com> and recently began having trouble with
channels switching during the capture. This is happening on a project
involving preserving audio data that was originally written on DAT.
After discussing the issue with other ZA-2 users and with the folks at
4front, it appears to be a problem that will never be resolved, so I
now have to recapture all the data because I can't be sure that
earlier transfers were flawless.
I'm now using a "Prodif32" card which is better supported by 4front.
The Prodif32 is also known as the RME Digi32.
Although there's a free ZA-2 driver (with source available), it hasn't
been modified in a long time, even though it had several items on its
"TO DO" list, so I never fiddled with it.
I highly recommend not using a ZA-2 with Linux. I don't yet have
enough experience with the Prodif 32 (or other Prodif/RME cards) to
recommend them but 4front clearly prefers them over ZA-2.
Cliff Matthews <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
