On Tue, 2014-11-18 at 18:43 -0500, S. wrote:
Thanks to everyone for their replies!
Roger Luedecke wrote:
the font rendering issue is being worked on actually and should be fixed in an update soon.
Great to hear this! What does the fix involve?
I'm aware that the subpixel rendering used by the Infinality project (arguable the best font rendering available for Linux) is patent-encumbered, but in my experience Arch has fonts that are *almost* as good as Infinality, and I'm pretty sure they don't use anything patent-encumbered. In my experience, the DejaVu Sans fonts with "slight" hinting and RGBA antialiasing look pretty nice, even with the default openSUSE fontconfig. So that's an example where considerable improvement could be made in the default openSUSE settings, even within the confines of purely open source solutions. As I understand it, they are actually merging the Infinality stuff into the libraries. Either they are not including encumbered bits, or they aren't as encumbered as we assumed.
Roger Luedecke wrote:
As for installing proprietary drivers, I'm not sure how much easier we could really make it.
Well, I do think that the Ubuntu Restricted Drivers tool is pretty fantastic. The reason is that most newish Linux users aren't really aware of the existence of libre/proprietary drivers, they just want their hardware to work. Many users aren't even all that sure about what sort of hardware they have, and it gets even more complicated with dual-graphics Intel/Nvidia Prime systems. So it requires more than a little bit of manual investigation to get certain hardware pieces working. The users has to find the hardware device in the YaST hardware tool, and then has to Google around to figure out what the names are of the drivers that correspond to the hardware, then they have to find the openSUSE package name as well as the repo that contains it. Sometimes there are libre drivers that work to a certain extent, but some users require the more complete functionality of a proprietary driver. Yes, it's not *terribly* difficult, and us seasoned Linux users can do it with our eyes closed, but I think that a lot of openSUSE users aren't interested in learning about their system-- they just want it to work correctly. A tool like the Ubuntu Restricted Drivers does all the hard work for the user, it tells them what pieces of hardware have an available proprietary driver, which versions are available, and a one-click button to enable it if desired. I'm aware of this tool, but I'm not sure that we can port it. Might not be a bad idea, though in a way I would almost rather have it be less obvious. I get exhausted very quickly by Ubuntu users and their tendency towards petulant demands and insults.
Roger Luedecke wrote:
I don't know about our packages being crippled to complicate using codecs etc
The most concrete example I can remember off-hand is K3B. To rip MP3s from an audio CD, it required LAME. But the openSUSE version of K3B was not compiled with the flag that made it look for the LAME libs, and therefore it couldn't use LAME even if it was installed.
Perhaps a more modern example are the gstreamer -bad and -ugly packages. They are offered in the official openSUSE repos, but they don't seem to actually contain any proprietary codec support, because even after installing them I couldn't play MP3 or MP4 files.
I'm sure there's more examples of this sort of crippling of openSUSE packages, but these are some easy examples. Of course, us seasoned openSUSE users know that it's just a matter of adding Packman, setting its priority to a lower number to increase the priority (rather counter-intuitive for beginners) and switching installed packages to the Packman versions, then adding the gstreamer -bad and -ugly -addon packages. But that process is long and convoluted compared to other distros.
I know that openSUSE can't offer proprietary codecs out of the box with the ISOs, but would it be possible to add a YaST module called "Proprietary Software Support" that offers a "Install proprietary codecs from Packman" checkbox that runs a simple script to do the whole process I described in the previous paragraph? Ah, now that would explain some things. I wonder if that is why Totem segfaults when I try to play an .avi. That seems like a lousy policy to disable their ability to use proprietary codecs if they are available. I think this would be a case for bug reports. I'd bet it is kept that way since it was done once and simply hasn't been changed yet.
Roger Luedecke wrote:
We need an integrated 'command-center' for the project so that communication will be more transparent and issues can be tracked in order to avoid regressions.
I see. Meanwhile until that gets implemented, would Bugzilla reports of these individual issues I mentioned be sufficient? It'd be the most effective mechanism we currently have.
jdd wrote:
so, the good way now should be to enable packman, give it some lower number as priorité, go to yast software, *repositories view* and call for software from there. A bit complicated.
My thoughts exactly. I think that if openSUSE can offer a wiki page to do this whole process manually, it should be possible to add a YaST module and script to do the same thing, still pulling from Packman and thus avoiding hosting proprietary software on openSUSE's repos. Our wiki is an unsearchable disaster zone. Frankly I don't really understand what structure it is supposed to have. I believe there are articles on how to enable all the proprietary multimedia support. But articles don't matter much if new users don't know they exist. I'd frankly want each desktop to have a 'greeter' that emphasizes such caveats that new users would have.
Lars Müller wrote:
Has one of you thought about filing bug reports for the individual issues and create one meta bug which references all these reports?
I can do that, I just wanted to make sure it wouldn't be too vague to report some of these issues that don't relate to a specific package. In response to Lars; yes, and I do file reports. After a certain point I do get fatigued with filing reports, and that tends to be by the time I start fussing with fun things like multimedia. This is especially the case since I tend to forget how to get to relevant logs and things like that once an issue has been resolved since I'm not exactly the most technical user.
Regarding my #2 issue "Automatic installation of extraneous/unrequested packages, especially after initial installation":
I think that there should be a prompt or something when using YaST Software for the first time, asking users if they want the resolver to #1) install recommends for already installed packages, and/or #2 install recommends for future installed packages. Additionally, I think that there should be a YaST Software option to enable/disable installation of recommends for future installed packages-- currently the option is only available for previously installed packages' recommends. Of course it is possible to adjust the /etc/zypp/zypp.conf option to not install recommends, which is obeyed by YaST, but I think a simple GUI checkbox would be better. I think we simply need saner 'recommends'. I once installed some small thing from KDE, and the next PK update pulled in the ENTIRE KDE ENVIRONMENT. I was very much not happy about that. Most recently I installed the broadcom-wl driver and it though xboards was a dependency. Xboards is a chess engine...
Also, I think that adding a YaST module with checkboxes for installing common stuff like Flash and openJDK would be better than using the update mechanism with packages like "pullin-fluendo-mp3" and "pullin-flash-player" to arbitrarily add this proprietary software, whether the user wants it or not. I think maybe doing that in the installer is feasible, but as a dedicated YaST module seems to me to be outside of the scope of YaST.
Sorry for the long email. I'd be very interested to read your further thoughts. Thanks for your time!
-- Roger Luedecke openSUSE Project Member and Advocate since 2011 http://www.opensuseadventures.blogspot.com -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org