Question:
What if, instead of passing out Live CD images, you passed out virtual
machine images?
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
system.)
Assuming this was integrated with an initiative on how to teach users
to quickly install and setup the virtual machine, this would have the
following advantages:
1. Current Fedora users could easily participate without modifying
their system, and in a much more efficient manner than booting other
systems.
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
update system.
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
> everything.
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.
http://art.ified.ca/?page_id=40 If you encounter bugs with it, you need to
report them.
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. :-)
Kevin Kofler
_______________________________________________
fedora-kde mailing list
fedora-kde(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fedora-kde
New to KDE4? - get help from
http://userbase.kde.org