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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org