Luca Barbato

I tried not to get into this discussion, mostly because it will degenerate to a mud sliding contest.

Alexis did not take well the fact that Tomáš changed the default provider for libavcodec and related libraries.

Before we start, one point:

I am as biased as Alexis, as we are both involved on the projects themselves. The same goes for Diego, but does not apply to Tomáš, he is just a downstream by transition (libreoffice uses gstreamer that uses *only* Libav).

Now the question at hand: which should be the default? FFmpeg or Libav?

How to decide?

- Libav has a strict review policy every patch goes through a review and has to be polished enough before landing the tree.

- FFmpeg merges daily what had been done in Libav and has a more lax approach on what goes in the tree and how.

- Libav has fate running on most architectures, many of those are running Gentoo, usually real hardware.

- FFmpeg has an old fate with less architectures, many qemu emulations.

- Libav defines the API

- FFmpeg follows adding bits here and there to “diversify”

- Libav has a major release per season, minor releases when needed

- FFmpeg releases a lot touting a lot of *Security*Fixes* (usually old code from the ancient times eventually fixed)

- Libav does care about crashes and fixes them, but does not claim every crash is a Security issue.

- FFmpeg goes by leaps to add MORE features, no matter what (including picking wip branches from my personal github and merging them before they are ready…)

- Libav is more careful, thus having less fringe features and focusing more polishing before landing new stuff.

So if you are a downstream you can pick what you want, but if you want something working everywhere you should target Libav.

If you are missing a feature from Libav that is in FFmpeg, feel free to point me to it and I’ll try my best to get it to you.

Again we got a fun thread about having to do some extensive change on perfectly working systems because somebody has a *plan* and you must abide to it.

If before the plan was to have systemd as the true and only init system (on why systemd seems to me a bad idea by itself I’ll discuss on a later post, possibly after throughly study its latest iteration and comparing it), now the plan is to force people not to have a separate /usr or use an initramfs with an early boot system because… “because doing otherwise is broken and already had been in ages”.

That doesn’t tell you much and if you have lots of systems running perfectly on a separate /usr setup and you went that way because it was documented as a best practice, you might feel enraged.

Now, let’s make clear that there are operating systems that keep everything in /usr and have next to nothing in / (and system that do not have /usr at all and everything is in /), you can argue a lot about what’s the best and why. FreeBSD or Hurd approaches have both interesting perks.

The fact is that *now* you have lots of people with perfectly working system in a configuration somebody decided that is wrong and *unsupportable*.

If you try to dig down a bit more you’ll discover that the “brokeness” is mainly due:

• Somebody keen in using a library that traditionally is in /usr for some fringe feature
• Somebody hell bent to use glib everywhere
• Somebody wanting to have d-bus running in the early boot phase
• Some udev rules using some data that currently resides in /usr

All considered forcing people to spend lots of time because somebody might want to use a bluetooth keyboard on early boot (thus requiring bluez, thus requiring d-bus basically because you can’t use bluez without it) or other non widespread use case is not exactly nice.

Surely trying to get a cleaner layout so we have a bare mountpoint directory, a early boot system in initramfs and the rest of the system cleanly split isn’t bad by itself and probably it is something I would consider neat.

But you still need to have a good separation between what is early boot and what is not and you need to make sure the boot process doesn’t get too complex or too tightly coupled with systems that can and will break easily.

I’m quite happy that alternatives are already almost available for simple systems not needing the additional features requiring those extensive changes.

Hopefully somebody will have time to try to add rules marking in udev so complex rules won’t be triggered when the system isn’t ready for them and deploys using special layouts could stay supported in a way or another.

In the other news Gentoo had been accepted to participate to the Google Summer of Code and there are two projects proposed by me, one is about documenting and if needed extending openrc to be a complete viable alternative to systemd, the other about using containers and qemu-user to have better tools to do cross developement.

Recently I came up to read this thread the initial proposal is to add systemd in some kind of fashion to gnome, with Lennart suggesting new and many features coming from that.

That alone isn’t a problem until people not caring about a broken toy from him (both systemd and pulse had been and are considered as such) can keep playing with gnome with their toys (e.g FreeBSD, any non systemd linux distro). The thread then evolved in something that could be sort of summarized with systemd developer not caring about anything else but Linux and so Gnome should do as well, with extremes from other people suggesting to ditch distributions and have a Gnome OS alone.

In the light of what happened before with HAL and on a minor degree with pulse that makes me wary.

So people willing to use Gnome in Lennart opinion must probably:

- Use Linux

- Use systemd

A quick reality check tell me that:

- Sun contributed a lot to Gnome, there are plenty of BSD users hacking on Gnome and/or using it.

- systemd is still a broken increasingly complex mess and the fact it needs _that_ many linux specific features to try to work tells a lot (Remember the UNIX way: small simple things you can understand and replace quickly)

- Gnome isn’t something that doesn’t have good or better replacements (Unity and Xfce come to mind if we want to consider gtk+)

I already switched from Gnome to e17 long time ago since I want that the WM/visual shell doesn’t get in my way and let me do what I want as I want.

Keeping Posix as baseline is important. Having your software working in different environments help you spot bugs quickly, get a more wider audience and generally improve. Even if I don’t particularly like KDE still I consider their approach to make porting KDE everywhere as easy as possible laudable.

***Update***

Sebastian asked me if there could be something constructive about this post since it looks pretty much a rant. Well, most of the post IS a rant (and categorized as that) and a not so humble request to not rush adopting/forcing upon people random technologies as they are sound and tested when they are not at all.

There isn’t anything constructive to be said, I just hope that we don’t have yet another situation like the one we had with other unproven technologies forced upon people like HAL had been.

On a side note, not completely related I wonder why people wants systemd  and doesn’t ask us to adopt upstart then. It is from Ubuntu as systemd is from Fedora, and Ubuntu at least tries to be present in non-desktop environments while Fedora is quite focused on the Desktop and only that.

Gentoo has OpenRC as init system. It is simpler and smaller. Works well in quite a good number of environments and for a quite large deal of situations. Surely there is space for improvements but at least does not require daemons to be written for it and had been tested in years.

Probably you already know that my side of FFmpeg got forced to rename itself to Libav. Some people is still wondering why we did that, you might read some short and longer summaries, have a look at our git or our mailing lists to see how we are faring and where we are heading.

So far I’m quite happy with what we are achieving little by little and day by day: a shared and quite defined plan for the future of the library, releases being a first class citizen, long standing issues being tackled and solved.

We were sorely lacking in the communication side and now we are trying to improve there as well. (This blog post and the website work is just part of it)

In the Gentoo land Scarabeus helped me adding libav, now it is pending some migration work to have all the software working with both libav and ffmpeg.

I hope you’ll be pleased by the outcome (people longing for the multithread work being fully merged I think are).

Thanks to Theo I have the blog at gentoo working again =)
In the past time I used my company blog as fallback.

Now I’m reading this and I wonder if we, as distribution did help or not to maintain things as lean as possible giving enough feedback to upstream and proposing tools that work fine.
Diego is probably doing his best even if from time he gets frustrated since things might not move as fast as should.

I do hope we won’t end up unleashing strange beasts like systemd and upstart (those are missing from that abstract but for me those are the most immature technologies around nowadays) or equivalents before they behave.

Poppler has a CMake ebuild now. Given how poppler is used it seems to me quite a bad move, poppler is small and used in system that may not have cmake already installed.

I run some numbers when wesnoth moved to cmake and claimed that it took about twice for me to build wesnoth+cmake on a phenom and building wesnoth alone took nearly the same time. Later a friend of mine wanted to play with me with wesnoth and given her pc is a _bit_ old, took ages to build an up to date wesnoth, about twice the time you may consider bearable thanks to the cmake switch.

Let’s see what means switching poppler to CMake now, after the previous post I got some news of nice improvements, hopefully it improved even more while I wasn’t watching.

Now some numbers:

I have my system in need to update poppler, still the phenom I used the other time, it is doing nothing right now:

cat /proc/cpuinfo | grep model_name
model name : AMD Phenom(tm) 9500 Quad-Core Processor

first: I need cmake

cmake ebuild tell me that I need xmlrpc-c with curl and curl with a kind of ssl support. I don’t see the point of having an xmlrpc library and two xml libraries for a make system, well let’s set the right useflags and trigger emerge cmake

time says

real 8m9.854s
user 13m8.121s
sys 3m7.664s

qlop on the cut down emerge.log says

domino ~ # qlop -t cmake -f mylog
cmake: 207 seconds average for 1 merges
domino ~ # qlop -t curl -f mylog
curl: 233 seconds average for 1 merges
domino ~ # qlop -t xmlrpc-c -f mylog
xmlrpc-c: 40 seconds average for 1 merges

So cmake is taking about the time of curl and it’s indeed faster to build that before (it alone), still autoconf+autotools take less than 60s here, and if we factor in the deps then we still have large margin for improvements (please make xmlrpc-c, curl, libxml and expat optional)

app-text/poppler

takes about 37-40 seconds

Hacking a bare ebuild w/out touching poppler configure.ac makes it take about 60-66 seconds

So if you are having cmake already installed this poppler ebuild is _quite_ an huge improvement. If you are wondering why that happens I could guess that given that poppler is quite small the cmake quicker configure step gives this large boost, probably not having libtool in the way helps as well.

To sum up:
- the cmake poppler builds quite faster than autotools poppler.
- CMake improved a lot its build time, yet is largely bloated and could enjoy a trim.
- Poppler configure.ac probably could be improved to be in line with the cmake times.

Ok, we got a new council, I’m still there so thank you for renewing the trust on me =)

Looks like that less people found me or what I did that compelling to make me into the council, so surely I did something wrong. Solar got the first place so his cleanly cut ways are perceived better.

I started polling people about what they feel about Gentoo and what they’d like. The first thing I noticed is that people are sick of endless discussions on marginal stuff and even more sick of outside projects trying to push it’s agenda on Gentoo using the shovel-in-throat way.

Second item is about trying to make the place nicer for everybody and better involve our large userbase. We used to be the nicest distribution regarding attitude towards newcomers and slow learner, now other distributions are better. We could re-learn from them.

That’s what I perceived so far. As I said before I see the council just as the last resort to get something decided if we, developers, cannot find a large agreement. Solar likes more to be proactive in my opinion. You liked him so I guess we as council should try to push people express themselves and get new&interesting stuff done instead of discussing which is the new way to define a quantity next to infinity or why embedding information somewhere is right or wrong in theory.

That said, how wrong I am so far and how we could get Gentoo to improve even more?

I’m eventually back home, I’m dead tired, the c-base party was great in many ways (people, food, place) and ending the night (actually starting the morning) playing Go with beer and music was _quite_ fun (thanks again for the games =))

I’ll try to wrap up everything in a short post before falling asleep completely: the LinuxTag had been a wonderful experience I had been more there as FFmpeg developer and less as Gentoo developer (mostly because I had to man the FFmpeg booth mostly since we aren’t that many and that I failed to chat in a proficuous with the gentoo people even if we spent the evening in the same place most of the time =| In the end I had a refreshing conversation about Gentoo with rbu luckily and I managed to chat a bit more with fauli just before he was leaving…)

Was quite fun going at the end of the event to the fsfe stand to do explain the FFmpeg stance about patents, Theora (more will follow) and why, in our humble opinion at least, isn’t correct to propose^Wactually shove down to the web users throat such codec just because of some claims that are yet to be validated…

The discussion was quite pleasant mostly because to my surprise fsfe people there weren’t zealots, so the whole discussion discussion even evolved to touch more interesting topics, like reverse engineering, making sure our license is respected and actually multimedia, with a brief discussion on containers, codec and streaming (that part actually started from an explanation why Theora isn’t that perfect fruit of opensource that is claimed and why Ogg has many
shortcomings as container and why in multimedia you do not have one-size-fit-all solutions… )

After about 4 years I eventually managed to get there! Today is the first day and I’m actually sort of manning the FFmpeg Booth and from time to time I could happen to be in the Gentoo one as well.

In the FFmpeg stand we are showing BBB high res in a big LCD screen from a small beagleboard. The operating system image is obviously Gentoo as well the other system present showing some jumpy Japanese idol video (not my idea).

See you! (Pictures will come later)

During the last month we got many arguments about how fundamental was one or another change to portage and how this or that had been a life change for many users.

I’m talking about the whole discussion about glep54 and the following one.

When it was first proposed I found the glep lacking details and given that some people were vehemently against it I asked to have it updated. Since some other people found the idea of improving our support for live ebuilds as whole (not just the versioning) interesting I tried to gather ideas and put them all into a draft. The thing got quite big and covered many steps needed, most of them not detailed yet.

Basically the live template draft aims to have portage do the following:

- let you automatically merge from a specific live branch
- have emerge –fetch work as supposed introducing a phase just for that
- let you track what you installed and possibly re-install as is
- have a way to generate automatically snapshot ebuilds and binpkgs in a non ambiguous way
- some more (like have portage show you which revision and from which branch comes what you installed on emerge -upv)

Glep 54 just aim to make sure versioning is theoretically and thoroughly correct, no matter how crazy overlays, upstream and package maintainer could be. To make an example, right now if someone wants to provide a live ebuild he could prepare an ebuild with a large version value (say 9999) and assume nothing bigger would appear, version usually are small values like 1.2.3.
Now, nothing forbids to have a version that is, say, 10000, making invalid the assumption cat/pkg-9999 is the higher value. The glep54 comes with a solution for this issue, have a new prefix to state that he ebuild is live, thus has to be considered above all the others within it’s range. This change has to be folded within a EAPI change or even better to a file extension change as stated in glep55 since it’s as simple to state as radical: older portage, not knowing anything about what this prefix is, will issue a warning.

Installing from live sources is completely unsupported thus those ebuild are rightfully p.masked and their use is quite specific. The current amount of them is scarce: 90 on 26130 ebuilds are live.

So, if you got the question about if you’d approve this proposal and consider implementing that and all the changes due that would follow or just put it on hold till it would be more useful what would you do?

A pragmatic approach would either be either reject it since does pretty much nothing in the big scheme (0.003 is nearly nothing) a less pragmatic approach, due the tendency to thinker, would be just try to make it more useful so it could be of appeal to a wider interest…

Probably the same time would have been better spent on things that are more interesting like have a better way to state what a dependency is (if it is something I’ll need to link to, something that I need to run) to ease the life of our embedded arches (say ppc, arm, sh, mips) or to fully support multislot and multiabi so we can avoid emul-linux on amd64 and have ppc64 being able to run xlc w/out many annoyances *cough*, or start thinking about how to enable pgo as widely as possible since it appears to make the difference in certain situations (e.g. firefox).