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 at 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 at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/fedora-kde > New to KDE4? - get help from http://userbase.kde.org >
