Distributions
Why Debian returned to FFmpeg
Slightly less than one year ago, the Debian community had an extended discussion on whether the FFmpeg multimedia library should return to the distribution. Debian had followed the contentious libav fork when it happened in 2011, but some community members were starting to have second thoughts about that move. At the time, the discussion died out without any changes being made, but the seeds had evidently been planted; on July 8, the project's multimedia developers announced that not only was FFmpeg returning to Debian, but it would be replacing libav.
Chances are that many Debian (and Ubuntu) users are not more than peripherally aware of which multimedia library is running on their system. Libav has been in use for some years and has generally filled the bill, so it is natural to wonder what drove the project to make a change that will require a lot of work and which seems certain to prove disruptive while it is underway. Getting to the answers is an interesting study in how distributions try to ensure that the code they ship comes from healthy upstream projects.
Security and more
The Debian project is not normally known for being afraid to ship multiple packages providing the same function, so one might wonder why it can't just ship both FFmpeg and libav, letting users decide which one they want to use. The big sticking point in 2014 was security support. Both projects have had more than their share of security issues, and the Debian security team didn't think it could keep up with patching both of them. At that time, FFmpeg seemed to have a better record of responding to vulnerabilities than libav, but that still was not enough to convince the security team to support both libraries.
One year later, security issues remained at the top of the list, but it would appear that FFmpeg has pulled well ahead of libav in this regard. Debian security team member Moritz Muehlenhoff made it clear that he saw FFmpeg as being more responsive to security reports. A rather stronger argument came from Mateusz “j00ru” Jurczyk who, in his security-oriented role at Google, has been doing extensive fuzz testing of both projects and reporting the problems that come up:
The notion of hundreds of open security issues is generally unappealing. FFmpeg does not appear to lead on just security updates, though; by all accounts, it now supports a far wider variety of codecs and containers than libav does. There is an increasing range of formats that FFmpeg can play, but libav cannot. As the feature gap grows, the project's desire to stay with libav wanes.
The libav maintainer's perspective
When Alessio Treglia restarted the discussion at the end of April, the above points were quickly expressed. Even so, the conversation did not appear to be heading toward any sort of consensus. Arguably, the turning point was when Debian libav maintainer Reinhard Tartler entered the discussion. Reinhard argued forcefully for the advantages he saw in libav, but, in the end, could not bring himself to say that he was sure libav was the better choice.
With regard to security issues, Reinhard attributed the difference in fix rates to a difference in how the two projects approach development ("Michael" is Michael Niedermayer, the lead developer of FFmpeg):
Reinhard initially asserted that, even so, libav had parity with FFmpeg when it came to fixing security-related bugs, but he later backed down on that.
In Reinhard's view, the two projects are managed differently, with
different goals;
that difference makes libav appealing in a number of
ways. Libav, he said, is trying to improve the state of the code and come
up with something better than the "horrible
" APIs it inherited
from FFmpeg. He summarized the differences between the project this way:
Even through he seems to like the libav approach more, Reinhard, in the end, was
not able to argue against the change; his position came down to:
"I still have some concerns with this move, but I can't claim Libav
to be superior to FFmpeg at this point
". With the project's libav maintainer
taking that position (and also, importantly, saying that he no longer has
the time to maintain libav at the same level as he has in the past), the decision
seemed to settle out fairly quickly.
Other concerns
A desire that was expressed more than once in this discussion was that the two projects would stop fighting and join back into a single, well-supported effort. There is, however, no real indication that any such reconciliation is in the cards. There is another way that the community could go back to having a single project, though: if one of them were to simply fail. Dmitry Smirnov suggested that a switch to FFmpeg by Debian could maybe bring that about:
Opinions vary on how much "life support" Debian actually provides to libav, but the loss of Debian and Ubuntu seems certain not to do the project any good. There aren't a lot of distributions out there that carry libav anymore; without Debian, that list will be short indeed. It might just be that libav is not sustainable without Debian.
That said, there are some concerns about the sustainability of FFmpeg as
well. By all accounts, Michael is a highly productive developer; he
accounts for, by far, the largest share of the patches going into FFmpeg.
Reinhard asked whether FFmpeg is a one-developer project that would find
itself in trouble should Michael stop working on it. "To me, this
constitutes a serious bus-factor: Without Michael, (probably) nobody is
able to replace him.
" He went on to suggest, though, that Michael's
departure could do a lot to bring an end to the fork.
As an argument against the "one-man show" concern, Andreas Cadhalpun posted some commit statistics for both projects, covering the period since September 2014:
libav FFmpeg Commits Developer Commits Developer 294 Vittorio Giovara 1831 Michael Niedermayer 253 Martin Storsjö 294 Vittorio Giovara 206 Anton Khirnov 252 Martin Storsjö 131 Luca Barbato 197 Anton Khirnov 72 Diego Biurrun 179 Clément Bœsch 46 Michael Niedermayer 155 James Almer 32 Rémi Denis-Courmont 150 Carl Eugen Hoyos 21 Andreas Cadhalpun 114 Andreas Cadhalpun 17 Hendrik Leppkes 113 Luca Barbato 16 Gabriel Dume 98 Lukasz Marek 16 Himangi Saraogi 93 Paul B Mahol 16 wm4 85 Ronald S. Bultje 14 Federico Tomassetti 83 wm4 12 Peter Meerwald 66 Christophe Gisquet 11 Janne Grunau 48 Benoit Fouet
At a first glance, the table shows that (1) FFmpeg appears to have a much higher commit traffic than libav, and (2) Michael, while being the largest contributor, is certainly not the only contributor. But, as Reinhard pointed out, there is a bit more to this story. Changes to libav are routinely merged into FFmpeg, but the flow of patches in the other direction is quite low. If the libav changes are subtracted out of the FFmpeg numbers, the result is that Michael very much stands alone; no other developer is even close.
The Debian multimedia developers decided to make the switch to FFmpeg even though nobody really had an answer to Reinhard's concern. For now, FFmpeg appears to be going strong, but there is a single-developer risk there that could come to the fore in the future. Given that nearly the entire distribution ecosystem now depends on FFmpeg, chances are that a way would be found to keep the project going if Michael were to decide he had better things to do. But the process of getting there might prove to be a little rough.
The Debian project was faced with a difficult choice: given that it was not possible to support both libraries in the distribution, which one offers the most to Debian's users while presenting the least long-term sustainability and security risk? The developers involved chose to move away from a project that many of them see as lacking the resources needed to be truly healthy. That choice will result in a lot of work, but, assuming the choice was the correct one, Debian users should benefit in the long term.
Brief items
Distribution quotes of the week
rBuilder Open Source
SAS purchased technology from rPath, including rBuilder. SAS has re-licensed rBuilder to Apache 2 and released it on GitHub. "We have now completed the process of separating out non-open-source third-party dependencies and have released the full source code for the current rBuilder technology under open source licenses (Apache 2 wherever possible). We have also released an installable image from which an rBuilder can be installed, as well as instructions to build it from source. It includes the ability to build systems and images based on CentOS 6, with CentOS 7 support currently being developed."
SUSE Linux Enterprise 11 SP 4 is out
SUSE has released the fourth service pack for SUSE Linux Enterprise 11. "SUSE Linux Enterprise SP4 includes a lot of updates like new versions for openSSH and zypper. OpenSSH is constantly improving and gaining new and more secure cipher suites. The newest SUSE Linux Service pack ships with version 6.6p1 of openSSH which includes modern elliptic curve ciphers based on the elliptic curve Curve25519, resulting in public key types Ed25519. Also the new transport cipher "chacha20-poly1305@openssh.com" was added, using the ChaCha20 stream cipher and Poly1305 MAC developed by Dan Bernstein." There are release notes for server and desktop.
FSF endorses embedded GNU/Linux distro ProteanOS as fully free
The Free Software Foundation has announced the addition of ProteanOS to its list of recommended GNU/Linux distributions. "ProteanOS is a new, small, and fast distribution that primarily targets embedded devices, but is also being designed to be part of the boot system of laptops and other devices. The lead maintainer of ProteanOS is P. J. McDermott, who is working closely with the Libreboot project and hopes to have ProteanOS be part of the boot system of Libreboot-compatible devices."
Distribution News
Debian GNU/Linux
Bits from the DPL - July
Neil McGovern shares a few bits about what he's been up to over the last couple of months. Topics include press and articles, conference invites, funding, TOs, legal issues, and DebConf.
Newsletters and articles of interest
Distribution newsletters
- DistroWatch Weekly, Issue 618 (July 13)
- 5 things in Fedora this week (July 9)
- Launchpad news (April-June)
- Ubuntu Weekly Newsletter, Issue 425 (July 12)
Microservices 101: The good, the bad and the ugly (ZDNet)
ZDNet has an interview about "microservices" with Red Hat VP of engineering for middleware, Dr. Mark Little. Microservices are a relatively recent software architecture that relies on small, easily replaced components and is an alternative to the well-established service-oriented architecture (SOA)—but it is not a panacea: "'Just because you adopt microservices doesn't suddenly mean your badly architected ball of mud is suddenly really well architected and no longer a ball of mud. It could just be lots of distributed balls of mud,' Little said. 'That worries me a bit. I've been around service-oriented architecture for a long time and know the plus points and the negative points. I like microservices because it allows us to focus on the positive points but it does worry me that people see it as the answer to a lot of problems that it's never going to be the answer for.'"
Mangaka Is an Artful Blend of Simplicity and Style (LinuxInsider)
LinuxInsider takes a look at Mangaka. "The new Mangaka release is based on Ubuntu 14.04 LTS, or Trusty Tahr. Actually, Mangaka is much more of a hybrid than its Ubuntu core underpinnings suggest. It is built around elements of the ElementaryOS, which also is designed around the Ubuntu core. Both run the Pantheon desktop. A newcomer to LinuxLand, this desktop is not found in many mainstream distros."
Brooks: Docker, CentOS 6, and You
Jason Brooks discusses the challenges of running Docker on CentOS 6. "Docker and CentOS 6 have never been a terrific fit, which shouldn’t be surprising considering that the version of the Linux kernel that CentOS ships was first released over three years before Docker’s first public release (0.1.0). The OS and kernel version you use matter a great deal, because with Docker, that’s where all your contained processes run. With a hypervisor such as KVM, it’s not uncommon or problematic for an elder OS to host, through the magic of virtualization, all manner of bleeding-edge software components. In fact, if you’re attached to CentOS 6, virtualization is a solid option for running containers in a more modern, if virtual, host."
Page editor: Rebecca Sobol
Next page:
Development>>