Hacker News Reader

Comment by boxfire | Hacker News Reader

And hence the coding quality separation of gstreamer plugins. There is a reason the plugin ended up in gstreamer-plugins-bad, and most of them it is due to code quality or lack of maintainers or both.

View on HN

Oh really, the -{good, bad, ugly} axis is coding quality? I always assumed it was licensing status / patents clearance.

EDIT it's both: https://gstreamer.freedesktop.org/documentation/splitup.html , http://askubuntu.com/questions/468875/plugins-ugly-and-bad

The good plugins have both acceptable code quality and acceptable license/patent terms. The ugly plugins have acceptable code quality, but unacceptable license/patent terms. Bad plugins are lacking code review, documentation, or are unmaintained, or have other problems that keep them from being moved to good or ugly.

I would have expected that to be the "testing" branch, not a different packages. but I guesd it makes sense if you gave up updating the code

GStreamer is highly modular, so it makes totally sense to ship a set of plugins with subpar code, unclear patent/licensing, barely maintained in a dedicated package. They called it "bad", what do you expect?

The issue here is that distributions should offer more granularity with on demand codec installation. Does it make sense that to play an mp3 (not that sure this is the case) I get also the NSF decoder?

This is in gstreamer0.10-plugins-bad, which isn't installed by default nor pulled in by anything else AFAICT

No idea, I don't use ubuntu. According to OP it's pulled by default in 12.04 and 14.04 as long as you choose to enable multimedia codecs at install time.

I think the problem is not that they have a place for the bad/ugly code, but that Nautilus runs that code on any file it can with no sandboxing.

Reply on news.ycombinator.com