I'll describe first the situation, and the actual question is at the very end.
I'm speaking from the perspective of electronic musicians and sound geeks - i'm using Linux to run sequencers and other MIDI software, JACK, DAW applications, external synths and effect boxes interfaced via MIDI and analog audio, etc. And i'm running all that on Fedora.
For this kind of usage, up-to-date sound drivers are essential. ALSA has been fixing bugs and adding new useful features at a steady and rapid pace. So far, on distributions based on kernel-2.4 (Red Hat 9, Fedora Core 1), i was content to download the ALSA rpms from http://freshrpms.net/ , rebuild the src.rpm, install the binaries and i was good to go. Because ALSA and the kernel were essentially decoupled, nothing prevented me from keeping up with the newest ALSA (short of small occasional incompatibilities between ALSA and the Red Hat modifications to the kernel). This helped me a lot with my work. It allowed me to get new improved mixers when they were ready, it allowed me to squish bugs out of the system, etc.
But i wonder about Fedora Core 2. That one will be using kernel-2.6, which includes ALSA. Typically, a Red Hat / Fedora release does not increment the kernel version during the release cycle. That means that FC2 and beyond will get stuck with whatever ALSA version was available at release time. For anyone using Linux for sound / music work, that is not ok. If you buy a piece of hardware (e.g. an expensive professional sound card such as an RME Multiface) and an essential feature is only supported by ALSA versions newer than what your distribution provides, then... well, it's not the end of the world, but it's definitely not good. Sure, one could compile a newer kernel, but that way the Red Hat changes to the kernel (which are often good for demanding apps such as digital recorders) will be lost.
Long story made short, is there any mechanism provided by Fedora Core 2 to allow users to painlessly upgrade to newer ALSA versions without having to ditch the kernel bundled with the distribution?
On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote:
Sure, one could compile a newer kernel, but that way the Red Hat changes to the kernel (which are often good for demanding apps such as digital recorders) will be lost.
The stated goals of Fedora are to stay as close to mainline upstream as possible. This includes the kernel.
On Thu, 2004-04-15 at 19:36, Charles R. Anderson wrote:
On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote:
Sure, one could compile a newer kernel, but that way the Red Hat changes to the kernel (which are often good for demanding apps such as digital recorders) will be lost.
The stated goals of Fedora are to stay as close to mainline upstream as possible. This includes the kernel.
Ok...
[florin@stantz florin]$ cat /etc/redhat-release Fedora Core release 1 (Yarrow) [florin@stantz florin]$ uname -r 2.4.22-1.2174.nptlsmp [florin@stantz florin]$ lynx -dump http://www.kernel.org/kdist/finger_banner | grep 2.4 The latest 2.4 version of the Linux kernel is: 2.4.26 [florin@stantz florin]$
That doesn't seem to me like any kind of closeness to the alleged "goals". ;-)
Florin Andrei wrote:
On Thu, 2004-04-15 at 19:36, Charles R. Anderson wrote:
On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote:
Sure, one could compile a newer kernel, but that way the Red Hat changes to the kernel (which are often good for demanding apps such as digital recorders) will be lost.
The stated goals of Fedora are to stay as close to mainline upstream as possible. This includes the kernel.
Ok...
[florin@stantz florin]$ cat /etc/redhat-release Fedora Core release 1 (Yarrow) [florin@stantz florin]$ uname -r 2.4.22-1.2174.nptlsmp [florin@stantz florin]$ lynx -dump http://www.kernel.org/kdist/finger_banner | grep 2.4 The latest 2.4 version of the Linux kernel is: 2.4.26 [florin@stantz florin]$
That doesn't seem to me like any kind of closeness to the alleged "goals". ;-)
Closer to 2.6 in that case. =)
Seriously though, in 99% cases the only way you will get anything into the Fedora kernel is to convince upstream to include it. Upstream inclusion means that a LOT more users and developers will be using and supporting it than Red Hat or Fedora alone. That is a significant advantage that should not be overlooked.
Nudge upstream please.
Warren
On Fri, 2004-04-16 at 07:26, Warren Togami wrote:
Seriously though, in 99% cases the only way you will get anything into the Fedora kernel is to convince upstream to include it.
Yes, but that was not the question.
I guess newer kernels include newer ALSA. How to update FC kernels with newer kernel versions, but also keeping fedora patches? (which, btw, should go upstream :P)
Replacing the kernel in src rpm with upstream and updating spec will create conflicts with existing patches?
On Thu, 2004-04-15 at 22:42, Marius Andreiana wrote:
On Fri, 2004-04-16 at 07:26, Warren Togami wrote:
Seriously though, in 99% cases the only way you will get anything into the Fedora kernel is to convince upstream to include it.
Yes, but that was not the question.
Thanks Marius, it's not the first time we're on the same "wavelength" without meaning to. :-)
I guess newer kernels include newer ALSA. How to update FC kernels with newer kernel versions, but also keeping fedora patches? (which, btw, should go upstream :P)
Actually, i'd take the minimalist approach and say: i'd be happy to be able to upgrade just ALSA, while leaving the rest of the kernel alone.
Replacing the kernel in src rpm with upstream and updating spec will create conflicts with existing patches?
Most likely.
I just realised that, with this thread, i re-opened the old and painful flamewar "why the Linux drivers are so tightly attached to the kernel, so that if i upgrade the kernel i have to upgrade all 3rd party drivers, or vice-versa". Tannenbaum scoffing at Torvalds for not using a microkernel, and all that...
Ah well, i was merely hoping i could avoid wasting the time required to recompile the kernel when a new ALSA version comes out.
On Thu, Apr 15, 2004 at 11:21:24PM -0700, Florin Andrei wrote:
I just realised that, with this thread, i re-opened the old and painful flamewar "why the Linux drivers are so tightly attached to the kernel, so that if i upgrade the kernel i have to upgrade all 3rd party drivers, or vice-versa". Tannenbaum scoffing at Torvalds for not using a microkernel, and all that...
It's not just a driver. ALSA is an entire *architecture* for moving sound into and out of the system. Try replacing the entire sound architecture of any other OS....
Ah well, i was merely hoping i could avoid wasting the time required to recompile the kernel when a new ALSA version comes out.
Well, if you switch to FC2 when it comes out, then updating kernels should be easy since there won't be any/many Fedora-specific patches to miss in the standard kernel.
On Friday 16 April 2004 00:26, Warren Togami wrote:
Florin Andrei wrote:
On Thu, 2004-04-15 at 19:36, Charles R. Anderson wrote:
On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote:
Sure, one could compile a newer kernel, but that way the Red Hat changes to the kernel (which are often good for demanding apps such as digital recorders) will be lost.
The stated goals of Fedora are to stay as close to mainline upstream as possible. This includes the kernel.
[the FC1 latest kernel is] 2.4.22-1.2174.nptlsmp The latest 2.4 version of the Linux kernel is: 2.4.26
That doesn't seem to me like any kind of closeness to the alleged "goals". ;-)
Seriously though, in 99% cases the only way you will get anything into the Fedora kernel is to convince upstream to include it. Upstream inclusion means that a LOT more users and developers will be using and supporting it than Red Hat or Fedora alone. That is a significant advantage that should not be overlooked.
Everbody is missing the point. The point is this: FC2 is released, possibly with kernel 2.6.6.
A month later, 2.6.7 is released, incorporating security fixes as well as new features, like a new ALSA that better supports, say, Echo Layla24 (the current ALSA support is experimental). (Layla24, BTW, is an 8 input 10 output high end 24bit /96ksps audio interface (not a sound card, since the card in the PC is just a special digital bus interface to an external 1U rack mount box) that has killer professional specifications, but has not been very well supported as yet). The 2.6.7 release might also have, say, a major ATM bug fixed in the ForeRunner HE622 driver (listed as unsupported) (I use an HE622 here). The linux-atm project does not release separate patch tarballs, but only releases through 'upstream' kernels.
Traditional Red Hat and FC1 backported the security fix only and kept the kernel version the same (in this example, that would lose the improved Layla24 support as well as the HE622 bugfix that are in the new UPSTREAM kernel).
The question before the group becomes: "Will FC2 release an errata for a patched 2.6.6 or will FC2 release a 2.6.7 that has the security fix AND the updated drivers/features/whatnot, along with any updated packages that might be necessary for the new kernel?" We know the previous policy; we want to better understand the new policy. Just saying that the goal is to be closer to upstream doesn't directly address this issue, IMHO. To me, the current statement simply means that the Fedora Core kernel, at the time of release, will be as close as possible to the upstream kernel, at the time of the Fedora prerelease freeze. Errata kernels are not mentioned, AFAICT, unless I am very much misreading the statement.
On Thu, Apr 15, 2004 at 08:25:57PM -0700, Florin Andrei wrote:
Fedora Core release 1 (Yarrow) 2.4.22-1.2174.nptlsmp
That doesn't seem to me like any kind of closeness to the alleged "goals". ;-)
FC 1 was still closer to the RH 9 mentality in that regard, and this is a good thing, and we would not have wanted to lose nptl and 0(1) just to be closer to mainline. As a result of the number of patches there, it is very difficult (read time consuming) to rebaseline the kernel to a newer release. I think you will find that 2.4.22 was pretty much left behind quite some time ago, but it remains the pristine source to which all of the other patches are applied.
FC2 is in a different boat, moving to 2.6 means most of the desired features exist already, and staying closer to mainline becomes much easier. I really do not see this changing at all until the 2.7 development cycle moves forward a bit. That is the time where we will see if the goal of staying closer to mainline is met, or if we get back into the habit of backporting features at the expense of flexibility in rebaseline.
Justin
On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote:
Long story made short, is there any mechanism provided by Fedora Core 2 to allow users to painlessly upgrade to newer ALSA versions without having to ditch the kernel bundled with the distribution?
Same as for FC1, RH9, ...: External kernel modules. Which for FC2 will override the existing ones in the kernel.
This does not apply to ALSA alone, at ATrpms autofs4, lm_sensors or bttv modules [*] have been upgraded in the same manner as well. For FC1 and higher modutils have even a special folder for external kernel module upgrades under /lib/modules/`uname -r`/updates for exactly that purpose.
[*] Note that current lm_sensors and v4l2 drivers require certain patch-only kernel extensions (i2c and v4l2-api), so the above is only half-true.
On Thu, 2004-04-15 at 23:22, Axel Thimm wrote:
On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote:
Long story made short, is there any mechanism provided by Fedora Core 2 to allow users to painlessly upgrade to newer ALSA versions without having to ditch the kernel bundled with the distribution?
For FC1 and higher modutils have even a special folder for external kernel module upgrades under /lib/modules/`uname -r`/updates for exactly that purpose.
Excellent! That answers my question. Thank you.
On Thu, 2004-04-15 at 23:28, Florin Andrei wrote:
On Thu, 2004-04-15 at 23:22, Axel Thimm wrote:
On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote:
Long story made short, is there any mechanism provided by Fedora Core 2 to allow users to painlessly upgrade to newer ALSA versions without having to ditch the kernel bundled with the distribution?
For FC1 and higher modutils have even a special folder for external kernel module upgrades under /lib/modules/`uname -r`/updates for exactly that purpose.
Excellent! That answers my question. Thank you.
There are a couple more issues that pertain to doing "professional" audio under 2.6.x that are not addressed by the current Fedora Core kernel builds, AFAIK (I very briefly tried 2.6 using Arjanv's source packages as a base, last build was based on kernel 1.286 - maybe the following is different in the "official" kernel).
If you are concerned about latency (ie: using very small audio buffers) then the stock configuration of the 2.6.x kernel has the preemptible kernel option turned off. In my tests latency is worse than with it on[1].
If you want to use the Jack low latency audio server (Jack Audio Connection Kit) with realtime privileges (SCHED_FIFO) then the obvious alternative is to build and load the LSM kernel module[2]. Regretfully that would need CONFIG_SECURITY_CAPABILITIES to be a module instead of being built into the kernel, as in the last build I tried (otherwise you can't build the LSM module).
-- Fernando
[1] plus the drm kernel modules for radeon/r128/mga have 12mSec+ latency hits and an old patch I used to use is broken...
On Fri, 2004-04-16 at 10:49, Fernando Pablo Lopez-Lezcano wrote:
There are a couple more issues that pertain to doing "professional" audio under 2.6.x that are not addressed by the current Fedora Core kernel builds, AFAIK If you are concerned about latency (ie: using very small audio buffers) then the stock configuration of the 2.6.x kernel has the preemptible kernel option turned off. In my tests latency is worse than with it on[1].
That's a showstopper for doing serious MIDI and DAW stuff. Preempt must be turned on for any kind of serious work in that field.
So, the stock 2.6 has it turned off. How about the FC2 pre-releases? Do they also turn it off?
If you want to use the Jack low latency audio server (Jack Audio Connection Kit) with realtime privileges (SCHED_FIFO) then the obvious alternative is to build and load the LSM kernel module[2]. Regretfully that would need CONFIG_SECURITY_CAPABILITIES to be a module instead of being built into the kernel, as in the last build I tried (otherwise you can't build the LSM module).
If i run JACK as root, do i still need the LSM module?
Currently i run all the audio/MIDI stuff as root, since security is not an issue on that system, and this way i don't ever see any of the privilege issues that normally come up. It's not elegant, though, i admit it.
Florin Andrei (florin@andrei.myip.org) said:
That's a showstopper for doing serious MIDI and DAW stuff. Preempt must be turned on for any kind of serious work in that field.
So, the stock 2.6 has it turned off. How about the FC2 pre-releases? Do they also turn it off?
Absolutely. Free bugs and changing behaviors out from under drivers that don't expect it isn't really a practical thing to do.
Bill
On Fri, 2004-04-16 at 12:39, Bill Nottingham wrote:
Florin Andrei (florin@andrei.myip.org) said:
That's a showstopper for doing serious MIDI and DAW stuff. Preempt must be turned on for any kind of serious work in that field.
So, the stock 2.6 has it turned off. How about the FC2 pre-releases? Do they also turn it off?
Absolutely. Free bugs and changing behaviors out from under drivers that don't expect it isn't really a practical thing to do.
Bummer. There goes my hope of not having to tweak kernels on FC2. :-(
Well, i guess one of the many yum repos, especially the multimedia-oriented ones (e.g. PlanetCCRMA), will do The Right Thing, so i won't have to waste time compiling kernels.
On Fri, 2004-04-16 at 12:51, Florin Andrei wrote:
On Fri, 2004-04-16 at 12:39, Bill Nottingham wrote:
Florin Andrei (florin@andrei.myip.org) said:
That's a showstopper for doing serious MIDI and DAW stuff. Preempt must be turned on for any kind of serious work in that field.
So, the stock 2.6 has it turned off. How about the FC2 pre-releases? Do they also turn it off?
Absolutely. Free bugs and changing behaviors out from under drivers that don't expect it isn't really a practical thing to do.
Bummer. There goes my hope of not having to tweak kernels on FC2. :-(
That was my hope too :-)
Well, i guess one of the many yum repos, especially the multimedia-oriented ones (e.g. PlanetCCRMA), will do The Right Thing, so i won't have to waste time compiling kernels.
Sigh... that would probably be me :-( [I created and mantain Planet CCRMA] -- Fernando
Le ven 16/04/2004 à 21:34, Florin Andrei a écrit :
On Fri, 2004-04-16 at 10:49, Fernando Pablo Lopez-Lezcano wrote:
There are a couple more issues that pertain to doing "professional" audio under 2.6.x that are not addressed by the current Fedora Core kernel builds, AFAIK If you are concerned about latency (ie: using very small audio buffers) then the stock configuration of the 2.6.x kernel has the preemptible kernel option turned off. In my tests latency is worse than with it on[1].
That's a showstopper for doing serious MIDI and DAW stuff. Preempt must be turned on for any kind of serious work in that field.
So, the stock 2.6 has it turned off. How about the FC2 pre-releases? Do they also turn it off?
$ grep CONFIG_PREEMPT /boot/config-2.6.5-1.326 # CONFIG_PREEMPT is not set
If you want to use the Jack low latency audio server (Jack Audio Connection Kit) with realtime privileges (SCHED_FIFO) then the obvious alternative is to build and load the LSM kernel module[2]. Regretfully that would need CONFIG_SECURITY_CAPABILITIES to be a module instead of being built into the kernel, as in the last build I tried (otherwise you can't build the LSM module).
If i run JACK as root, do i still need the LSM module?
No, sorry, you don't need it. I should have been more specific. That's only necessary for getting realtime privileges as a non-root user.
-- Fernando
On Fri, 16 Apr 2004 12:29, Florin Andrei florin@andrei.myip.org wrote:
But i wonder about Fedora Core 2. That one will be using kernel-2.6, which includes ALSA. Typically, a Red Hat / Fedora release does not increment the kernel version during the release cycle. That means that FC2 and beyond will get stuck with whatever ALSA version was available at release time.
http://fedora.redhat.com/participate/schedule/
The plan is for 2-3 releases a year, and it seems that so far we are doing reasonably well in meeting that plan. Is using a 4-6 month old version of ALSA really that bad?
Also if you know what you are doing you can mix bits between different FC releases and include rpms from rawhide when appropriate. It's not generally recommended that such things be done, but if you have unusual needs then it may be the best way to satisfy them.
Am Fr, den 16.04.2004 schrieb Russell Coker um 12:05:
On Fri, 16 Apr 2004 12:29, Florin Andrei florin@andrei.myip.org wrote:
But i wonder about Fedora Core 2. That one will be using kernel-2.6, which includes ALSA. Typically, a Red Hat / Fedora release does not increment the kernel version during the release cycle. That means that FC2 and beyond will get stuck with whatever ALSA version was available at release time.
http://fedora.redhat.com/participate/schedule/
The plan is for 2-3 releases a year, and it seems that so far we are doing reasonably well in meeting that plan. Is using a 4-6 month old version of ALSA really that bad?
IMHO: Libs, Utils: Not really. Driver: Yes.
As long as Hardware-Vendors don't provide Linux-Drivers that are installable in an *easy* way *we* need to provide device-driver updates during lifetime of the current Fedora Core version to support newly released hardware. Sound-Cards are a nice example, there are many other.
Dave did IMHO a good job with the fedora kernel with integrating newly released drivers (from external sources or later released "vanilla"-kernels). Especially when he integrated support for SATA Controllers that were not supported by the FC1 release kernel. But IMHO we need to do more in this area so newly released hardware is supported shortly after it's availably (if these linux-drivers exists, of course -- I don't mean writing them completely).
Also if you know what you are doing
than you can often fix it yourself ;-) Fedora target is not exactly the end-user, but I think we have enough users that don't know how to fix such things. Look at fedora mailing lists for examples ;-)
CU thl
On Sat, 17 Apr 2004 04:27, Thorsten Leemhuis fedora@leemhuis.info wrote:
The plan is for 2-3 releases a year, and it seems that so far we are doing reasonably well in meeting that plan. Is using a 4-6 month old version of ALSA really that bad?
IMHO: Libs, Utils: Not really. Driver: Yes.
As long as Hardware-Vendors don't provide Linux-Drivers that are installable in an *easy* way *we* need to provide device-driver updates during lifetime of the current Fedora Core version to support newly released hardware. Sound-Cards are a nice example, there are many other.
Installing a kernel from rawhide is quite easy, and generally there should not be any problems with it. I think you can safely assume that newer kernels will be available reasonably often if you don't restrict yourself to main Fedora releases.
Also if you know what you are doing
than you can often fix it yourself ;-) Fedora target is not exactly the end-user, but I think we have enough users that don't know how to fix such things. Look at fedora mailing lists for examples ;-)
True. However testing a new kernel for release takes a significant amount of effort. Just doing a quick compile and throwing it to the users isn't going to make many people happy! Providing the very latest kernel at all times conflicts with the goal of providing software that is tested and known to be reasonably reliable.
I think that if you want to have the latest kernel at all times then you just need to know enough to solve these problems, including compiling your own kernel on occasion.
Am Fr, den 16.04.2004 schrieb Russell Coker um 22:00:
On Sat, 17 Apr 2004 04:27, Thorsten Leemhuis fedora@leemhuis.info wrote:
The plan is for 2-3 releases a year, and it seems that so far we are doing reasonably well in meeting that plan. Is using a 4-6 month old version of ALSA really that bad?
IMHO: Libs, Utils: Not really. Driver: Yes.
As long as Hardware-Vendors don't provide Linux-Drivers that are installable in an *easy* way *we* need to provide device-driver updates during lifetime of the current Fedora Core version to support newly released hardware. Sound-Cards are a nice example, there are many other.
Installing a kernel from rawhide is quite easy and generally there should not be any problems with it.
Normally yes. But I's not that easy that my parents could do it and not 99% risk free (nothing ist 100% risk free ;-) ). An it's way harder and riskier then installing a windows device driver. This is the level I want to reach (okay, with I dream of).
I think you can safely assume that newer kernels
Please don't read my post as I wanted a 2.4.26 Kernel for FC1 now. I only want easy installable device drivers. If they are in the kernel or somewhere else (printer/scanner driver) is not important for an ordinary user.
will be available reasonably often if you don't restrict yourself to main Fedora releases.
Also if you know what you are doing
than you can often fix it yourself ;-) Fedora target is not exactly the end-user, but I think we have enough users that don't know how to fix such things. Look at fedora mailing lists for examples ;-)
True. However testing a new kernel for release takes a significant amount of effort.
Of course.
Just doing a quick compile and throwing it to the users isn't going to make many people happy!
+1
Providing the very latest kernel at all times conflicts with the goal of providing software that is tested and known to be reasonably reliable.
Not my point and not my wish. I only want the drivers for the newly released Hardware so we don't let users in the stand in the unsupported rain for ~5-7 month (feature freeze until next release).
Yes, in most times new drivers come with new kernels, but Alsa is a neat example where something other is possible.
CU thl
On Sun, 18 Apr 2004 05:19, Thorsten Leemhuis fedora@leemhuis.info wrote: [regarding installing a kernel from rawhide for ALSA]
Normally yes. But I's not that easy that my parents could do it and not 99% risk free (nothing ist 100% risk free ;-) ). An it's way harder and riskier then installing a windows device driver. This is the level I want to reach (okay, with I dream of).
So your parents need bleeding-edge ALSA sound capabilities? My parents didn't even notice when I broke sound on their machine and I still haven't got around to fixing it...
I intentionally don't let my parents install anything on their machine. When they need something installed I'll install it for them. Making Fedora administration possible for the average office worker or the average child is worth-while, making it possible for the average 60yo is not going to work.
On Sun, 18 Apr 2004, Russell Coker wrote:
riskier then installing a windows device driver. This is the level I want to reach (okay, with I dream of).
So your parents need bleeding-edge ALSA sound capabilities? My parents didn't even notice when I broke sound on their machine and I still haven't got around to fixing it...
There is a problem with drivers that are updated in later kernels and which is not updated in FC. I have a network card that sometimes locks up the computer which is supposed to be fixed in 2.4.25.
It's not a security risk, but it's a bit annoying when the computer locks up. Hopefully the FC2 kernel will contain fewer patches and be easier to upgrade.
I'd say that the kernel is more important to update then normal program. A broken driver that crashes the computer is worse then a single program that segfaults every once in a while.
Russell Coker wrote:
On Sun, 18 Apr 2004 05:19, Thorsten Leemhuis fedora@leemhuis.info wrote: [regarding installing a kernel from rawhide for ALSA]
Normally yes. But I's not that easy that my parents could do it and not 99% risk free (nothing ist 100% risk free ;-) ). An it's way harder and riskier then installing a windows device driver. This is the level I want to reach (okay, with I dream of).
So your parents need bleeding-edge ALSA sound capabilities? My parents didn't even notice when I broke sound on their machine and I still haven't got around to fixing it...
I intentionally don't let my parents install anything on their machine. When they need something installed I'll install it for them. Making Fedora administration possible for the average office worker or the average child is worth-while, making it possible for the average 60yo is not going to work.
Hey! watch that about 60yo, there might be some 59 1/2 year old lurking that may have been programming before you were born 8-}
Am So, den 18.04.2004 schrieb Russell Coker um 02:01:
On Sun, 18 Apr 2004 05:19, Thorsten Leemhuis fedora@leemhuis.info wrote: [regarding installing a kernel from rawhide for ALSA]
Normally yes. But I's not that easy that my parents could do it and not 99% risk free (nothing ist 100% risk free ;-) ). An it's way harder and riskier then installing a windows device driver. This is the level I want to reach (okay, with I dream of).
So your parents need bleeding-edge ALSA sound capabilities?
Normally not -- but if they buy a new PC with an by Fedora Core unsupported card they may need a newer Alsa version if it supports the card. That not an unusual situation for new PCs.
In times where Computer sometimes only live 3-4 years waiting 5up to 7 Month for an "official" Linux-Driver for my Distribution is annoying.
I intentionally don't let my parents install anything on their machine. When they need something installed I'll install it for them. Making Fedora administration possible for the average office worker or the average child is worth-while, making it possible for the average 60yo is not going to work.
+1
;-)
CU thl
On Fri, 2004-04-16 at 03:05, Russell Coker wrote:
Also if you know what you are doing you can mix bits between different FC releases and include rpms from rawhide when appropriate. It's not generally recommended that such things be done, but if you have unusual needs then it may be the best way to satisfy them.
I agree with that from a technical p.o.v.
However, given the fast pace at which the Linux audio/music community grows, maybe "unusual needs" is not an appropriate term anymore. Or we're close to that.
-
Axel Thimm -
Bill Nottingham -
Chuck Anderson -
Dennis Bjorklund -
Fernando Lopez-Lezcano -
Florin Andrei -
Féliciano Matias -
Justin M. Forbes -
Lamar Owen -
Marius Andreiana -
Richard Hally -
Russell Coker -
Thorsten Leemhuis -
Warren Togami