A Google Rant

I love what Google has been doing, and they’ve made huge contributions to FOSS. However, I have to join the chorus of those who are concerned with their lack of distro-friendliness.

The start of my saga was Gentoo bug 320407. Apparently Google re-bundled swt in their android SDK, and the version they re-bundled breaks sometimes.

So, the solution is to not install swt, and patch their android script so that it uses the system library. I still have to figure out which version of swt they re-bundled so that I can try to match it. Maybe that won’t be much work.

Then I need to look at all those other libraries and see which of those can go. I’ll need to patch in their paths, and I’ll need to figure out which upstream versions they re-bundled so that I can set the correct dependencies. Maybe each of those won’t be much work. Maybe some poor user will get burned when it turns out that they modified one of them and I miss it in testing.

Oh, and every time they do a new release they’re not going to tell me if they upgraded one of those bundled libs to a newer API/etc, so maybe if I’m lucky I’ll spot problems during testing and not burn users. Maybe that isn’t too much work either.

Maybe each of these things won’t be much work, but this is already sounding like a royal pain to me. It is also a recipe for end-user problems.

Let me pick my next favorite Google package – chromium. I have a chromium upgrade pending that I’ve been postponing. Building and installing chromium takes hours on my system (an old Athlon 64 3200+). Actually, building chromium probably isn’t the problem – it is building the other half-gigabyte of re-bundled dependencies that get rebuilt every time I upgrade chromium, even though I already have most of them on my system (and if I didn’t the package manager would take care of that for me – ONCE).

My hat is off to the chromium maintainers because they’ve done a good job managing it, and I understand that they’re trying to strip out the embedded libs. However, the project facing them makes my android headaches seem like a trifle.

Google – just use and list dependencies! If you want to have an alternate all-in-one package for those without package managers, feel free – other projects do it. However, if Mozilla can play nice with distros, you can do it too.

All that said, I have no objections to embedding contributed libraries in the sdk itself – the part used to build and test android apps. In this case app developers need to build and test their apps against the libraries that will be on target devices and not their development workstation. Since no code will run natively (except perhaps on an emulator) there aren’t really the usual compatibility and security issues associated with this.

A Random Btrfs Experience

After all the buzz about btrfs and Ubuntu I figured I’d try experimenting with it a little. Aside: I think the hype over Ubuntu is a bit overblown – more power to them if they can pull it off but I suspect that it won’t be more than an option in the end.

I’m really looking forward to btrfs maturing enough for everyday use. I’ve been battling with md and lvm for ages and btrfs has a lot of promise. Some of the things I’m looking forward to are:

• The resizeability and reshapeability of linux md.
• The ability to create subvolumes as in lvm.
• The potential performance boost of COW.
• The snapshot ability and performance as compared to lvm.
• Full barrier support down to the metal. Right now I can’t do that as md doesn’t support barriers.

So, how did it go?