What if, instead of passing out Live CD images, you passed out virtual
These could be compact (at least around the range of a Live CD/DVD),
but a little speedier (I personally find that even on my recent
laptop, a virtual machine runs much smoother than a live CD booted
Assuming this was integrated with an initiative on how to teach users
to quickly install and setup the virtual machine, this would have the
1. Current Fedora users could easily participate without modifying
their system, and in a much more efficient manner than booting other
2. Setup would be much easier -- perhaps the installation and removal
of the images could be handled through a package. This would also
mean that you could pass down updated images for Testers using the
The only clear disadvantage would be that 1) no live Image for those
who do not have a virtual machine manager (but since all Fedora users
have access to KVM, surely that should be enough -- obviously the bulk
of Fedora tests is Fedora users), and it would be more difficult to
test sound and 3D, which are crippled in VMs. (No one would be doing
Compiz QA with this).
But then again, a live CD itself can be too slow for rigorous
multimedia or graphics experience testing. At least VMs allow
potentially even easier distribution and management, and you could be
a flagship use of Fedora's new VM capability.
On Tue, Jun 30, 2009 at 10:00 AM, Kevin Kofler<kevin.kofler(a)chello.at> wrote:
Eli Wapniarski wrote:
> Stop trying to integrate or force integration of everything into
I disagree. It's important for components to work together.
> And there is of yet, still no official support for pulse under wine.
But there is the WinePulse project which is what we're shipping.
If you encounter bugs with it, you need to
And the reason upstream WINE refuses to merge the patch is because they want
to rewrite the whole sound system and they don't want any new backends
until that happens, no matter how important those new backends are. :-/ It
has nothing to do with the quality of the backend.
> Why should a soundserver interfere with networking?
I don't know. But there's certainly an explanation.
> Right now the defacto standard Linux soundserver is alsa.
No, the de-facto standard is PulseAudio now. We aren't the only ones
shipping it as the default, at least Ubuntu and Mandriva ship it too.
It's not possible to have apps only support hardware ALSA in a PulseAudio
environment, they'll not work (because PulseAudio needs the sound device).
The problem with WINE's ALSA backend is that it needs mmap and thus won't
work with the PulseAudio ALSA plugin.
You can try the ESD backend (wine-esd), which uses PulseAudio's ESD
compatibility layer (pulseaudio-esound-compat).
> Please lets do what we can to not go the Redhat 8 route again. Please.
Do you have anything against Bluecurve? I still use it. :-)
fedora-kde mailing list
New to KDE4? - get help from http://userbase.kde.org