Planet Gentoo

Donnie Berkholz: links for 2009-11-06

Donnie Berkholz (dberkholz) — Sat, 07 Nov 2009 01:56:11 +0000

The trough of disillusionment for Ubuntu?

“The Hype Cycle describes the way that new technologies and projects are perceived over time, if they do a good job of handling themselves, going from a technology trigger, inflated expectations, disillusionment, enlightenment, before arriving at “the plateau of productivity” – a state where there is no more hype and the new technology is simply a normal part of our lives.”

The perception over the past few years that Gentoo is dying is in reality Gentoo’s arrival at the plateau of productivity. Hype has gone away and remaining is a distribution with a true niche that fits into the broader Linux ecosystem.

(tags: gentoo communication)

Tagged: communication, gentoo, greatness, pr

Gentoo News: Gentoo KDE3 Deprecation Notice

Gentoo News () — Fri, 06 Nov 2009 06:02:08 +0000

Please turn your KDE radio on, and make sure to increase the volume to its maximum level for this important message.

After multiple setbacks we have finally managed to stabilise KDE4 on both major desktop architectures (amd64 and x86), with other teams to follow.

For this and other reasons as discussed , those of you who still use KDE3 should be seriously considering an upgrade in the near future.

The KDE3 support is being deprecated with immediate effect. This means that ebuilds are dropping KDE3 support where they were broken, or clashing with KDE4.

If you wish to still use KDE3, and you want to help others with having KDE3 around, drop a mail to kde@gentoo.org, where we can give you commit access to the special overlay which will specifically contain only KDE3 packages.
This overlay (named kde3) can be easily used via layman.

Sadly upstream is not supporting KDE3 anymore and we simply lack the manpower to keep support for both (as you might have noticed in the past few months KDE3 has become more and more rusty for which we humbly apologize).

Sorry to bring you the bad news and with hope that KDE4 will suit your needs,

Tomas Chvatal
KDE Teams substituting Lead

KUDOS to Nirbheek Chauhan and David Abbott for helping to put this announcement together and Alec Warner for proofreading it.

Alex Alexander: KDE in Gentoo, an update

Alex Alexander (wired) — Thu, 05 Nov 2009 15:22:59 +0000

KDE 4.3.3 was released on Tuesday, with ebuilds instantly available to users in the main tree.

We also have KDE 4.3.1 in stable \o/

KDE 3.5 is on its way out of portage, with kde-sunset being the overlay that will (hopefully) be maintained by users still interested in it.

Finally, KDE 4.4 Beta 1 is due December 1st and you’ll find it in the kde-testing overlay as usual

Diego E. Pettenò: Distributions are the strength of Linux

Diego E. Pettenò (flameeyes) — Wed, 04 Nov 2009 20:56:18 +0000

People disagree, some people think that no operating system has any need for distributions, with all their difference and their central repositories that aren’t as central. But one of the thing that impress most the users who switch is, in many cases (at least that I could look at myself) the presence of distributions and the ability to install almost any software by simply looking it up in the package manager.

This said, when people think that overcomplex solutions are a perfect way to solve the issues that “vendors” have with distributing their software, you’re probably missing the point quite a bit. Instead of proposing changes in all the possible layers of the operating system stack, you should try to speak with with the distributors and see what you can do to make your software behave in such a way that they can lift the “send the software to the user” problem from you.

It’s a tremendously important point I’m making here: when you develop your software coming from a Windows background to work on Linux, youŕe probably making a huge amount of mistakes; the most common one is to assume that the directory to work on is the directory the program is in, or that the current working directory is the home of the user. Both differ between Windows and Linux. Fixing these minor issues is usually trivial, if you have access to the code, and if you’re willing to bend a bit around to accommodate the requests. In the case that icculus brought up, the proper solution is, generally, splitting the data from the engine, so that you can reuse the data between different architectures, and have a different engine for each architecture; or have a single huge download with all the architectures available, if they are, say, 10% over the size of the data.

The main point here is still that you have first to remember that distributions exist and that users like to rely on them (most of the time) and second to understand that neither the Windows way nor the OS X way applies to Linux. This doesn’t make Linux right and the other wrong, or vice-versa; they are three different worlds, and each one has its own good and bad side.

The biggest mistake in misunderstanding Linux for just another Windows version is providing a setup program, even worse a graphical setup program. If your software has no drivers to install, nothing to register itself into (there is no registry on Linux, after all), you most likely should not give that as the only option. First of all such a program would rarely tell you what’s going to do, and you’d also be going to run that with root privileges to install the stuff, so why should you trust proprietary software with root on your system? Of course if you’re just a “Joe User” you won’t care, you have no clue about that, but any decently skilled user would know that it’s never a good idea to trust any software you cannot control with root privileges on your box.

The second misconception is that some people seem to think that it’s a task for upstream of a project – be it a proprietary software vendor or a free software project – to provide binaries, installer and packages. This is the main reason why that silly FatELF idea is still tickling on some people. Well, let me say it once and for all it’s the distributions’ task to provide packages to the users!

Of course the problem is that distributions rarely can provide all the possible software in the world as package, may it be because their policy is to only allow Free Software (like Debian and Fedora) or for other reasons. In any case the solution is not to say “The distributions are the problem” but rather to wonder “Why are they not packaging my software?”. Of course when the problem is policy related to the license there is little to do, so you’re forced to rely on third party repositories (like RPM Fusion ) that don’t have such problems with policies. In general, a very little leeway for the distributions can go a great deal into making your software available to users.

All kind of projects who want to reach for users should listen to the distributors: that means that if a distributor complain about the way you (don’t) release software, for instance because you only use a “live” repository for the users to use, or about the way you make use of bundled libraries, you should most likely discuss with them a way to handle the situation; failing to do that is going to drive the distributor away (and then you’d probably be complaining that you’ll have to provide binaries for that distribution yourself). Unfortunately I’m quite sure that especially icculus have problems with stuff like that, given I’ve reported more than one Gentoo policy violation for ebuilds that come from icculus.

For proprietary software, this often goes not as much into the way of changing the development of the software but rather to change some distribution details: allow the developer to redistribute your software (so don’t use strange click-through download systems, don’t require the user to go a long way to find what it has to download); give a “raw tarball” option that the distribution can use as source for their packaging, be it binary packages, or source-based packages like Gentoo’s.

Move the packaging task to the packagers, they know it better.

And if you’re developing proprietary commercial software, you might want to approach some developers, and eventually give out some free licenses for them to play with so that they can package the software, and eventually give you feedback in what they would like for you to change. Most of the time, packagers are pretty pragmatic and will not be scared off by “helping proprietary software”; for instance in my overlay you can find some packaging for the Visual Paradigm Suite for which I bought a license a few weeks ago (I needed a working UML software for a job); it’s nowhere near Gentoo-ready, but I’ve not given up on it; since the Visual Paradigm customer support is also quite ready to answer to problems and suggestions, I’ve been sending them my feedback, both as user and as packager. Hopefully I might get to the point where the package is fine with Gentoo policies and I can add it to the main tree normally.

A similar situation happens with the EntropyKey software packaging since I was interested I got two of those and packaged it up; if upstream was interested in packaging this beyond their own support (I think they already have a Debian packager as part of the staff anyway), they could have created a developer program for distributors, and I’m pretty sure almost all distributors would have supported the ekeyd software in no time.

Yes, I am seeing all this situation from a packager point of view, but that’s because I definitely like this approach and instead of resent us for “not providing the stuff you want” or attacking distributions because “you have to make dozens of different packages”, try working with them. Like I said before, Ryan should stop keep inside his own little world where he can do whatever he wants and then expect people to bend at his needs, he should listen to the needs of distributors (which aren’t really so impossible!) and so should anybody who want to enter the Linux ecosystem as it is now.

And it’s definitely not only proprietary software that still doesn’t get this, Mozilla has had a hard time to get to work with distributors, OpenOffice still has such a hard time, Avidemux is a perfect example of how a package gets to ignore all the possible distribution requests (by still shipping a modified FFmpeg for instance).

Most of the time, the reasons why developers don’t want to make accommodations for distributions, are stuff along the lines of “I don’t see what difference does it make”… which is also the very reason why they have such a hard time to get their packaging together.

Steve Dibb: my blu-ray ripping trial run

Steve Dibb (beandog) — Wed, 04 Nov 2009 15:04:54 +0000

Yesterday, I wanted to see if I could rip a Blu-Ray disc using my PS3. I really want to get a BD-ROM drive, but they are so expensive still, and since I can install Linux on my PS3, I figured maybe I'd try and save myself some money and see if I could manage to get one ripped and decrypted. It actually worked, which surprised me. Ripping the disc was the simplest thing in the world, but the key on the movie I tried (Willy Wonka and the Chocolate Factory) was too new, and currently only AnyDVD has support for it. I'd love to buy a copy of that, but it only runs in Windows, and it's really expensive. Instead, I'll just have to wait for the keys to pop up eventually on the doom9 forums.

The first step, though, was getting the PS3 to run Linux. I took the shamelessly easy way out (and I don't regret it either) and installed Xubuntu. I won't go into details about how I got Linux on my PS3 since that's well documented. I will say that I remember quite vividly now why I can't stand binary distros. Bleh.

The BD filesystem is UDF. Providing you have a recent kernel (2.6.20, I think) with UDF v2.5 support, you are good to go. I mounted a remote share and just dumped the disc to an ISO file onto my desktop.

$ cat /media/cdrom0 > wonka.iso

That was the easy part.

The hard part was trying to get it decrypted. I had to use Java tools (bleh) to get to the source. There are three applications you need. And if you hate digging through forums and using download services, then I've got direct links for yah:

For Gentoo, you'll need to install the JDK to build the aacskeys library and binary. I just emerged dev-java/sun-jdk and it worked for me (I know absolutely nothing about Java, but my stabbing in the dark miraculously worked). You'll also need a runtime environment to actually execute the stuff, and I emerged dev-java/sun-jre-bin and that worked fine, too on my amd64 box.

For aacskeys and Gentoo, you'll need to apply this patch that I cobbled together from what I found on the doom9 forums to get it to compile. It just fixes the Java include directorys for the Makefile.

Now, I'm still a bit fuzzy about what each program does, and whether you need all of them or not, so I won't go into a lot of detail. What you want to use, though, is the dumphd program. But to use it, you'll need to copy the aacskeys library and a file from the bdvmdbg package as well into the path or same directory as the dumphd program.

Once you have that, you can just run dumphd.sh and it'll fire up a simple little GUI telling you if it has all the libraries it needs. Then you just specify the source and destination, and aacskeys will see if it has a working key to access the disc.

I can't really give much more detail than that, since I'm so new to this. Suffice it to say, if you read the accompanying README doc that comes with each one, you'll get along just fine.

It took me a long time last night to get just one disc ripped and transferred over my subnet to try it out, and by the time I managed to get it mounted (mount -o loop -t udf wonka.iso /mnt/udf) and access it, it was pretty late. The keys I had didn't work for my disc, and I didn't want to try the whole procedure over to try another disc.

Anyway, good luck if you try it. One thing that impressed me is how much simpler it was than I thought it'd be, but what a pain it was trying to figure out where things went wrong. The doom9 forums are a good resource, but not exactly the best place to find clear, concise information for a beginner. That part was frustrating.

Personally, I don't think it's worth the hassle right now, the way I did it. I'll get a BD-ROM sooner or later so I don't have to transfer the content over the network and can instead just test it directly. But, I started out to see if I could at least get a copy of the ISO and get the tools running all without Windows, and I can. So, that's progress right there.

Diego E. Pettenò: ELF should rather be on a diet

Diego E. Pettenò (flameeyes) — Wed, 04 Nov 2009 14:08:06 +0000

I’ve been first linked the FatELF project in late October by our very own solar; I wanted to write some commentary about it but I couldn’t find the time; today the news is that the author gave up on it after both Linux kernel and GLIBC developer dissed his idea. The post where he noted his intention to discontinue the project looks one drama-queen of a post regarding the idea of contributing to other projects… I say that because, well, it’s always going to be this way if you think about an idea, don’t discuss it before implementing, and then feel angry for the rejection when it comes. I’m pretty sure that no rejection was personal in this rejection, and I can tell you that what I would have written after reading about it the first time would have been “Nice Proof of Concept, but it’s not going to fly”.

Let’s first introduce the idea behind the project: to copy Apple’s “Universal Binaries”, that technique that allowed programs to run both on PPC-based Mac as well as the new Intel-based Mac when they decided to make the transaction, this time applying the same principle to the ELF files that are used on basically all modern UNIX and Unix-like systems (Linux, *BSD, Solaris). There is a strange list of benefits in the project’s homepage; I say strange because they really seem straw arguments for creating FatELF, since I rarely have seen this applied in real world.

Let’s be clear, when Ulrich Drepper (who’s definitely not the most charming developer in our community) says this:

Yes. It is a “solution” which adds costs in many, many places for a problem that doesn’t exist. I don’t see why people even spend a second thinking about this.

I’m not agreeing to the fact that nobody should have spent a second thinking about the idea; toying with ideas, even silly ideas like this one (because as you’ll soon see, this is a silly idea), is always worth it: it gives you an idea of how stuff works, they might actually lead somewhere, or they might simply give yo the sense of proportion of why they don’t work. But there are things to consider when doing stuff like this, and the first is that if there is a status quo, it might be worth discussing the reason of that status quo before going in full sprint and spend a huge amount of time to implement something, as the chance that’s just not going to work is quite high.

To make an example of another status quo-fiddling idea, you might remember Michael Meeks’s direct bindings for ELF files; the idea was definitely interesting, it proven quite fast as well, but it didn’t lead anywhere; Michael, and others including me, “wasted” time in testing it out, even though it was later blocked by Drepper with enough reasons and it’s no longer worked on. Let me qualify that “wasted” though: it was wasted only from the point of view of that particular feature, which led nowhere, but that particular work was what actually made me learn how the two linkers worked together, and got me interested in problems of visibility and cow as well as finding out one xine bug that would have been absolutely voodoo to me if I didn’t spend time learning about symbol resolution before.

Back to FatELF now: why do I think the idea is silly? Why am I agreeing with Drepper about the fact that it’s a solution with too high costs for the unrequested results? Well the first point to make is when Apple made the first step toward universal binaries; if you think the idea sprouted during the PPC to Intel transition, you’re wrong. As Wikipedia notes Apple’s first fat binary implementation dates back to 1994. During the M68K to PPC transition. Replicating the same procedure for an architecture change wasn’t extremely difficult to them to begin with, even though it wasn’t OSX that was used during that particular transition. The other fact is that the first Intel transition was – for their good or bad – a temporary one. As you can probably have noted, they are now transitioning from i386 software to x86-64 software (after my post on PIE you can probably guess why that’s definitely important to them).

But it goes much further than that: Apple has a long history of allowing users to port the content their computer from one to the next with each update, and at the same time they have a lot of third party providing software; since third parties started upgrading to universal binaries before Intel Macs were released for the users, if users kept up to date with the release, one they got their new Intel Mac they would just had to copy the content from the old to the new system and be done with it. This is definitely due to the target audience of Apple.

There is another thing to know about Apple and OS X, that you might not know about if you’ve never used a Mac: applications are distributed in bundles, which are nothing more than a directory structure, inside which the actual binary is hidden; inside the bundle you find all the resources that are needed for the program to run (translations, pictures, help files, generic data files, and so on). To copy an application you only have to copy the bundle, to remove almost all applications you just shove the bundle in the trash can. This forces distributions to happen in bundles as well, which is why Universal Binaries were so important to Apple: the same bundle had to work for all people so that it could still be copied identical between one computer to the other and work, no matter the architecture. This is also why, comparing the size of bundles built Universal, PPC-only and Intel-only, the first is not as big as the size of the other two: all the external resources are shared.

So back to Linux, and see how this applies: with a single notable exception all the Linux distributions out there use a more or less standard Filesystem Hierarchy Standard compatible layout (some use LSB-compatible layout, the two are not one and the same, but the whole idea is definitely similar). In such a setup, there are no bundles, and the executable code is already separated from the code that is not architecture-dependent (/usr/share) and thus shareable. So the only parts that cannot be shared, that FatELF would allow to be shared are the executable code parts, like /bin and /lib.

Now let’s start with understanding where the whole idea is going to be applied: first of all, Linux distributions, by their own design, have a central repository for software, which OS X does not have; and that central repository can be set up at installation time for getting the correct version of the software, without asking the user to know about the architecture by itself. The idea of using fat binaries to reduce the size of that repository is moot: the shareable data is already, for most distributions I know, shared in -noarch packages (arch-independent); the only thing you’d be able to spare would be the metadata of packages, which I’m quite sure for most “big” applications is not going to be that important. And on the other hand, the space you’d be saving on the repository side is going to be wasted by the users on their harddrive (which is definitely going to be disproportionally smaller) and by the bandwidth used to push the data around (hey, if even Google is trying to reduce the downloaded size fatelf is not only going against the status quo but also the technical trend!).

And while I’m quite sure people are going to say that once again, disk space is cheap nowadays, and thus throwing more disks at the problem is going to fix it, there is one place where it’s quite difficult to throw more space at it: CDs and DVDs, which is actually one of the things that FatELF is proposing to make easier, probably in light of users not knowing whether their architecture is x86, amd64 or whatever else. Well, this is already been tackled by projects such as SysRescueCD that provide two kernels and a single userland for the two architectures, given that x86-64 can run x86 code.

The benefits listed in FatELF’s page seem also to focus somewhat to the transition between one arch and the other, like it’s now happening between x86 and x86-64; sure it looks like a big transition and quite a few players in the market are striving to do their best to make the thing as smooth as possible, but either we start thinking of the new x86-64 as the arch, and keep x86 as legacy, or we’re going to get stuck in a transition state forever; Universal Binaries for Apple played a fundamental role in what has been a temporary transition, and one they actually completed quite fast: Snow Leopard does no longer support PPC systems, and everybody is expected the next iteration (10.7) to drop support for 32-bit Intel processors entirely to make the best use of the new 64-bit capabilities. Sure there could be some better handling of transitioning between architectures in Linux as well, especially for people migrating from one system to the other, but given the way distributions work, it’s much easier for a new install to pick up the home directories set up in the older system, import the configuration, and then install the same packages that are installed in the previous one.

After all, FatELF is a trade-off: you trade bigger binaries for almost-universal compatibility. But is the space the only problem at stake here? Not at all; to support something like FatELF you need changes at a high number of layers; the same project page shows that changes were needed in the Linux kernel, the C library (glibc only, but Linux supports uclibc as well), binutils, gdb, elfutils and so on. For interpreted language bindings you also have to count in changing the way Ruby, Python, Java, and the others load their libraries since they now hardcode the architecture information in the path.

Now, let’s get to the real only speakable benefit in that page:

A download that is largely data and not executable code, such as a large video game, doesn’t need to use disproportionate amounts of disk space and bandwidth to supply builds for multiple architectures. Just supply one, with a slightly larger binary with the otherwise unchanged hundreds of megabytes of data.

You might or might know that icculus.org where the FatELF project is hosted is the home of the Linux port of Quake and other similar games, so this is likely the only real problem that was, up to now, really come up before: having big packages for multiple arches that consists mostly of shareable data. As said before, distributions already have architecture-independent packages most of the time; it’s also not uncommon for games to separate the data from the engine source itself, since the engine is much more likely to change than the data (and at the same time, if you use the source version you still need the same data as the binary version). The easiest solution is thus to detach the engine from the data and get the two downloaded separately; I wonder what the issue is with that.

On the other hand, there is a much easier way to handle all this: ship multiple separate ELF binaries in the same binary package, then add a simple sh script that calls the right one for the current host. This is quite easy to do, and requires no change at any of the previously-noted layers. Of course, there is another point made on the FatELF project page that this does not work with libraries… but it’s really not that of an issue, since the script can also set LD_LIBRARY_PATH to point to the correct path for the current architecture as well. Again, this would solve the same exact problem for vendors without requiring any change at all in the layers of the operating system. It’s transparent, it’s easy, it’s perfectly feasible.

I hear already people complaining “but a single FatELF file would be smaller than multiple ELF files!”. Not really. What you can share between the different ELF objects, in theory, is still metadata only (and I’m not convinced by the project page alone that that’s what it’s going to do, it seems to me like it’s a sheer bundling of files together): SONAME, NEEDED entries and similar. Unless you also start bundling different operating systems together – which is what the project also seem to hint at – because in that case you also have no warranty that the metadata is going to be the same: the same code will require different libraries depending on the operating system it’s built for.

Generally, an ELF file is composed of executable code, data, metadata related to the ELF file itself, and then metadata related to the executable code (symbol tables, debugging information) and metadata related to the data (relocations). You can barely share the file’s metadata between architectures, you definitely cannot share it between operating systems as stated above (different SONAME rules, different NEEDED).

You could share string data, since that’s actually the same between different architectures and operating systems most of the time but that’s not really a good reason; you cannot share constant data because there are different ordering, different sizes and different paddings across architectures, even two very alike like x86 and x86-64 (which is why it’s basically impossible to have inter-ABI calls!).

You cannot share debugging information either (which might be the big part of an ELF file) because it’s tied to the offset of the executable code, and the same applies to the symbol tables.

So, bottomline, since there are quite a few strawy benefits on the FatELF project page, here is a list of problems caused by that approach:

introduces a non-trivial amount of new code at various layers of the system (kernel, loader, linker, compiler, debugger, language interpreters, …), it doesn’t matter that a lot of that code is already published by now, it has to be maintained long-time as well, and this introduces a huge amount of complexity;
would increase dramatically the size of downloading packages for the optimistic case (a single architecture throughout a household or organisation) since each package would comprise of multiple architectures at once;
would use up more space on disk since each executable and library would then be duplicated entirely multiple times; note that at the time Universal Binaries started popping up on systems, more than one software was released to strip the other architecture out of them to reduce space to be wasted on already-ported or won’t-be-ported systems; while FatELF obviously comes with the utilities by itself, I’m pretty sure most tech-savvy users would then decide simply to strip off the architectures that are useless to them;
would require non-trivial cross-compilation from build servers which right now all the distributions, as far as I know, tend to avoid.

In general, distributions will definitely never going to want to use this; free software projects would probably employ better their time by making sure the software is easily available in distributions (which often means they should talk to distributors to make sure their software has an usable build system and runtime configuration); proprietary software vendors might be interested in something like that – if they are insane or know nothing about ELF, that is – but even then the whole stack of changes needed is going to be way disproportionate to the advantages/

So I’m sorry if Ryan feels bad about contributing to other projects now because people turned down his idea, but maybe he should try for once to get out of his little world and see how things work with other projects involved, like discussing stuff first, asking around and proposing: people would have turned him down with probably most of the same arguments I used here today, without him having to spend time writing unused (and unusable) code.

Steve Dibb: closed captioning on dvds (and ripping them)

Steve Dibb (beandog) — Tue, 03 Nov 2009 21:10:38 +0000

In ripping my DVDs, I try to future-proof it as much as I can, by putting in as many elements as I *think* I might need or want someday down the road. One of those elements is subtitles. There are three types of subtitles that can be on DVDs -- VobSub, closed captioning and SDH -- and the first two can be extracted fairly easily. I have no idea how to access the SDH ones. I think you need either a newer DVD player or a Blu-Ray one.

I've been ripping my TV shows, and so far I haven't seen any really hard and fast rules on what to expect with them on DVD. Part of the reason is that I just haven't been paying much attention to subtitles until recently.

I was playing with ripping one show last night, and I saw the CC logo on the back of the case, so I went to check the rest of my library to see which other ones had it. Nearly my entire library of Warner Bros. DVDs displayed the logo -- even for much older cartoons (Looney Tunes, Scooby Doo) -- once again staying consistent with the fact that the studio puts a lot of effort into the quality of their releases.

I just started playing with extracting CC though, and just barely wrote the code to my DVD ripper to extract them, so I have no idea what the other series are like, if they have subtitles or not -- VobSub or CC. I usually don't find out until I actually go to rip them.

Extracting the closed captioning subtitles is a lot easier and faster than getting the VobSub streams. For Linux (and Mac and Windows) there's a nifty OSS program called ccextractor. Once you have your VOB video file on your harddrive, just run that on the movie, and it will create an SRT subtitle file of the closed captioning text. It's great, and really fast, taking probably under a minute on a 60-minute video on my box. Comparatively, when ripping a VobSub stream, you need to read the DVD directly which causes its own bottleneck, and then demux the entire stream. It takes probably around 3 to 5 minutes for an episode of the same length.

Another thing I like about the closed captioning titles is that because they are extracted as SRT, it's easy to look through them since they are just text files. If you're really anal, you can correct typos yourself. The VobSub subtitles are all bitmaps. I've also noticed that on some DVDs, where there were issues with framerates or something else, that the VobSub timestamps will be off ... and sometimes either they will show up clumped together at the beginning of the film or the sync will be way off. I think that this has to do with the dumping process, somewhere, but I'm not sure. I've never really taken the time to pin down the source.

So, with closed captioning being easier and faster to extract, as well as editable and the timestamps haven't had any issues for me (yet), it's quickly becoming my preferred subtitle format.

There's only one small issue with using ccextractor, and that is you won't know if there are any captions in the VOB until after it's made its trial run. The program will create an .srt file regardless when you run it, but the file will be empty if it couldn't find any. That's the only drawback. With VobSub, you can know if there are subtitles just by probing the DVD using lsdvd or something similar.

Muxing it into matroska is simple, too. Just pass it as a file argument and you're done.

As a sidenote, while my bend application that I wrote and use to rip DVDs would be a major pain to setup for someone else, I've rewritten it recently so that it uses individual classes to access every object directly: DVD, DVD track, DVD VOB, Matroska file. They are standalone classes written in PHP if anyone wanted to use them, feel free. You would also need my tiny class of shell functions as well, since they all make calls to it.

The DVDVOB one makes it simple to extract the subtitle stream. In fact, all the classes make things relatively simple. They have made writing my code so much simpler.

Diego E. Pettenò: The PIE is not exactly a lie…

Diego E. Pettenò (flameeyes) — Mon, 02 Nov 2009 16:33:52 +0000

One very interesting misconception related to Gentoo, and especially the hardened sub-profile, is related to the PIE (Position-Independent Executable) support. This is probably due to the fact that up to now the hardened profile always contained PIE support, and since it relates directly to PIC (Position-Independent Code) and PIC as well is tied back to hardened support, people tend to confuse what technique is used for what scope.

Let’s start with remembering that PIC is a compilation option that produces the so-called relocatable code; that is, code that is valid no matter what base address it is loaded at. This is a particularly important feature for shared objects: to be able to be loaded by any executable and still share the code pages in memory, the code needs to be relocatable; if it’s not, a text relocation has to happen.

Relocating the “text” means changing the executable code segment so that the absolute addresses (of both functions and data — variables and constants) is correct for the base address the segment was loaded at. Doing this, causes a Copy-on-Write for the executable area, which among other things, wastes memory (each process running will have to have its private copy of the executable memory area, as well as the variable data memory area). This is the reason why shared objects in almost any modern distribution are built relocatable: faster load time, and reduced memory consumption, at the cost of sacrificing a register.

An important note here: sacrificing a register, which is something needed for PIC to keep the base address of the loaded segment, is a minuscule loss for most architectures, with the notable exception of x86, where there are very few general registers to use. This means that while PIC code is slightly (but not notably) slower for any other architecture, it is a particularly heavy hit on x86, especially for register-hungry code like multimedia libraries. For this reason, shared objects on x86 might still be built without PIC enabled, at the cost of load time and memory, while for most other architectures, the linker will refuse to produce a shared object if the object files are not built with PIC.

Up to now, I said nothing about hardened at all, so let me introduce the first relation between hardened and PIC: it’s called PaX in Linux, but the same concept is called W^X (Write xor eXecute) in OpenBSD – which is probably a very descriptive name for a programmer – NX (No eXecution) in CPUs, and DEP (Data Execution Prevention) in Windows. To put it in layman terms, what all these technologies do is more or less the same: they make sure that once a memory page is loaded with executable code, it cannot be modified, and vice-versa that a page that can be modified cannot be executed. This is, like most of the features of Gentoo Hardened, a mitigation strategy, that limits the effects of buffer overflows in software.

For NX to be useful, you need to make sure that all the executable memory pages are loaded and set in stone right away; this makes text relocation impossible (since they consists of editing the executable pages to change the absolute addresses), and also hinders some other techniques, such as Just-In-Time (JIT) optimisation, where executable code is created at runtime from an higher, more abstract language (both Java and Mono use this technique), and C nested functions (or at least the current GCC implementation, that makes use of trampolines, and thus require executable stack).

Does any of this mean that you need PIC-compiled executables (which is what PIE is) to make use of PaX/NX? Not at all. In Linux, by default, all executables are loaded at the same base address, so once the code is built, it doesn’t have to be relocated at all. This also helps optimising the code for the base case of no shared object used, as that’s not going to have to deal with PIC-related problems at all (see this old post for more detailed information about the issue).

But in the previous paragraph I did write some clue as to what the PIE technique is all about; as I said, the reason why PIE is not necessary is that by default all executables are loaded at the same address; but if they weren’t, then they’d be needing either text relocations or PIC (PIE), wouldn’t they? That’s the reason why PIE exists indeed. Now, the next question would be, how does PIE relate to hardened? Why does the hardened toolchain use PIE? Does using it make it magically possible to have a hardened system?

Once again, no, it’s not that easy. PIE is not, by itself, neither a security measure nor a mitigation strategy. It is, instead, a requirement for the combined use of two mitigation strategy, the first is the above-described NX idea (which rules out the idea of using text relocations entirely), while the second is is ASLR (Address Space Layout Randomization). To put this technique also in layman terms, you should consider that a lot of exploit require that you change the address a variable points to, so you need to know both the address of that variable, and the address to point it to; to find this stuff out, you can usually try and try again until you find the magic values, but if you randomize the addresses where code and data are loaded each time, you make it much harder for the attacker to guess them.

I’m pretty sure somebody here is already ready to comment that ASLR is not a 100% safe security measure, and that’s absolutely right. Indeed here we have to make some notes as to which situation this really works out decently: local command exploits. When attacking a server, you’re already left to guess the addresses (since you don’t know which of many possible variants of the same executable the server is using; two Gentoo servers rarely have the same executable either, since they are rebuilt on a case by case basis — and sometimes even with the same exact settings, the different build time might cause different addresses to be used); and at the same time, ASLR only changes the addresses between two executions of the same program: unless the server uses spawned (not cloned!) processes, like inetd does (or rather did), then the address space between two requests on the same server will be just the same (as long as the server doesn’t get restarted).

At any rate, when using ASLR, the executables are no longer loaded all at the same address, so you either have to relocate the text (which is denied by NX) or you’ve got to use PIE, to make sure that the addresses are all relative to the specified base address. Of course, this also means that, at that point, all the code is going to be PIC, losing a register, and thus slowed down (a very good reason to use x86-64 instead of x86, even on systems with less than 4GiB of RAM).

Bottomline of the explanation: using the PIE component of the hardened toolchain is only useful when you have ASLR enabled, as that’s the reason why the whole hardened profile uses PIE. Without ASLR, you will have no benefit in using PIE, but you’ll have quite a few drawbacks (especially on the old x86 architecture) due to building everything PIC. And this is also the same reason why software that enables PIE by itself (even conditionally), like KDE 3, is doing silly stuff for most user systems.

And to make it even more clear: if you’re not using hardened-sources as your kernel, PIE will not be useful. This goes for vanilla, gentoo, xen, vserver sources all the same. (I’m sincerely not sure how this behave when using Linux containers and hardened sources).

If you liked this explanation that costed me some three days worth of time to write, I’m happy to receive appreciation tokens — yes this is a shameless plug, but it’s also to remind you that stuff like this is the reason why I don’t write structured documentation and stick to simple, short and to the point blogs.

Diego E. Pettenò: Changes in the comment antispam

Diego E. Pettenò (flameeyes) — Sat, 31 Oct 2009 11:02:01 +0000

You probably remember the series of posts I already wrote about my antispam that uses the User-agent field to reject at the source a number of comments that are likely to be spam. The idea is definitely working right, just yesterday it filtered out 134 spam comments (no false positives, after a quick check), and at the same time I have no need to use obnoxious captchas, or to block comments on old posts (and just yesterday I got an interesting one on an almost year old post ).

Unfortunately this was still not perfect; luckily there is a second antispam pass that is applied directly by Typo using some heuristics (like the number of links) and akismet; this second pass is both good and bad. For instance it always marks as spam the posts where people do provide references for their comment, which is a bit tiresome. Sure it does not delete the posts, but only queue them up for moderation, but still. Unfortunately the second pass couldn’t be disabled or loosened up because usually I would get around three spam comments every day or so (which is still a lot less compared to the hundreds sometimes the filter kills at the source).

But last night, thanks to Mark, I was able to refine the antispam even more (and the comment policy now is updated to reflect that); I added a couple more DNSBL (DNS-based blacklists): proxyBL DroneBL and CBL . I left them running on the untested input during the night and the results are quite interesting. Just one or two hits on ProxyBL, but about two posts an hour hit DroneBL right away, and of those a few wouldn’t have hit my usual User-Agent-only antispam.

But since I don’t want to hit other services when I can filter the spam myself, I’ve now re-configured the checks to only apply if the comment didn’t hit any other check first (this way all the bogus user agent posts would be dropped and then the remaining “valid” ones would be checked). In particular, CBL is set as the very last check, for a very important reason: CBL does not sanction its use for non-mail related filtering. Unfortunately, CBL is also the only list that had a couple of IP addresses from which false negatives arrived yesterday, so I really wouldn’t have wanted to ignore it entirely. But I am responsible for any problem related to CBL with this kind of use; please don’t ever bother CBL upstream about this.

And another change, related to the blog spam, might be of interest. I’ve tried re-enabling the trackback support, but as it was easy to guess, there seems to be nothing but spam passing through it nowadays; very few valid installations actually use the trackback support, and they definitely don’t justify the amount of spam I’d be getting; on the other hand, Typo should be able to trackback itself to link posts together when I note something about them, and that’s one thing that I’d really like to keep; so for now I’ve enabled the trackback feature from within Typo, but I’ve stopped it on the Apache configuration, by allowing only the server’s own IP address to access the location.

I’ll publish the modsecurity configuration someday in the near future, hopefully.

Jeremy Olexa: Gentoo: About “optimizing”

Jeremy Olexa (darkside) — Fri, 30 Oct 2009 18:26:29 +0000

As Linux-Mag points out (Gentoo Optimizations Benchmarked) using gcc optimizations for "omg, teh speed" is not all that practical. Sure, I'll add some compiler flags here and there as long as I am compiling everything anyway but I don't consider that a feature of Gentoo Linux.

I actually prefer Gentoo for the package management and customization via USE flags (even with the headaches that they cause sometimes).

Doug Goldstein: Improved VDPAU abstraction

Doug Goldstein (cardoe) — Fri, 30 Oct 2009 13:47:52 +0000

Recently, Aaron Plattner from NVIDIA announce libvdpau 0.2, which a wrapper for driver specific VDPAU implementations. You may have noticed that nvidia-drivers shipped a libvdpau.so library for a while now for apps to link against while placing their actual implementation in libvdpau_nvidia.so. Newer ebuilds of nvidia-drivers will no longer install libvdpau.so, nor any of the headers and install will rely on this being installed. Other applications, like MythTV will instead depend on x11-libs/libvdpau.

In addition to this change, there’s a new package called vdpauinfo in the tree. Some people might know it from the NVNews forums as vdpinfo. However, Aaron got the author’s permission to add it to freedesktop.org and rename it to vdpauinfo to match the library.

Doug Goldstein: nvidia-drivers and xorg-server compatiblity

Doug Goldstein (cardoe) — Fri, 30 Oct 2009 03:42:28 +0000

As always happens when we see a new xorg-server release people start to wonder why the Gentoo ebuilds for nvidia-drivers have blockers for the new release. To help clarify this I’ll post an ASCII table showing the current support.

driver series   maximum ABI
-------------   -----------
71.86.*         2.x
96.43.*         5.x
173.14.*        5.x
190.*           6.x

xorg server     video ABI
-----------     ---------
1.7.*           6.x
1.6.*           5.x
1.5.*           2.x

As you can see from the above, the 71.86.x series has gone into very limited maintenance mode. I would be surprised to see very many updates, if any at all to it in the future. However, for users of the 96.43.x and 173.14.x series, NVIDIA has confirmed to me that there will be an update to the latest xorg-server ABI change. This update though does not have any definite dates so I can’t provide any. I recommend users of that series stay with xorg-server-1.6.x releases for the time being so they can have a smooth X experience.

Jeremy Olexa: Using sshfs with rtorrent

Jeremy Olexa (darkside) — Fri, 30 Oct 2009 01:56:31 +0000

I had this genius idea about using sshfs with rtorrent. I thought that this use case would fit best in situations where you have good bandwidth but not much diskspace, such as my linode VPS (review). So, I'll attempt to share my findings in this regard.

If you are not familiar with rtorrent. You just need to know that it is a powerful, lightweight bittorrent client. It has a "watch" feature that watches a directory for new torrents, and obviously it can put downloaded files in a specified location. I tried both of these with sshfs.

First, I was having trouble with rtorrent just 'freezing' up when I put a torrent file in the sshfs accessible watch dir. I didn't quite know what was wrong here. Research led me to rtorrent bug 322 and that sshfs did not support filesystems without mmap properly. Darn. More research led me to a recent kernel commit that looked promising. Low and behold, reboot my host with 2.6.31.x kernel and rtorrent works with sshfs watch and destination directory. Yay.

Well, not so fast...

The performance is quite poor with the destination directory on sshfs. This is to be expected because now your download speed for torrents is limited to the download speed of your final destination. But, rtorrent was only giving me a sustained speed of 1/4 of that demonstrated with a simple file copy to the destination. I speculate that this is from the rtorrent overhead or maybe fragmenting? Not sure exactly and I don't care. My solution to this was to use the rtorrent "move on finished" feature that downloads the file to local disk and then moves it to sshfs destination after it is finished. Amazingly, this works quite well.

My testing scenario was the following:
-79MB Gentoo 2008.0 install cd torrent. With the complete sshfs solution, it took ~6 minutes to download (to the sshfs destination) and then 5 minutes to check the hash. So, roundtrip of 11 minutes from start download to seeding. With the on_finished solution, it took 1 minute to download (to local disk) and 1 minute to check the hash and move to the sshfs destination. For a roundtrip of ~2 minutes from start of download to seeding.

In conclusion, this isn't the perfect solution because you impose a large bottleneck into the mix and unintended I/O activity on the local disk. However, it works for me and what I am doing. Maybe it will give someone else some ideas in the future.

Gilles Dartiguelongue: Gnome 2.28.1 full steam

Gilles Dartiguelongue (eva) — Fri, 30 Oct 2009 00:04:29 +0000

http://cia.vc/stats/author/eva

My CIA profile went from about one commit every 17.35 housr to one every 16.56. The difference does not seem big but the calculation is diluted on about 6 years due to a KDE dev sharing the same nick. This amounts to 158 commits tonight.

~arch is now at about 85% of completeness for Gnome 2.28.1, a few commits are missing due extra complexity (hey it still took my 3 hours to do that). Beware that this release still has a few rough edges, especially policykit migration buts. So if you get cut, please come to bugzilla but do not expect sweet words and attention if I see comments like "dude why do you keep on breaking ~arch". It's ~arch, beat it.

Original post blogged on b2evolution.

David Abbott: Podcast 65 Bashed In The Head

David Abbott (dabbott) — Thu, 29 Oct 2009 18:33:43 +0000

In this podcast I talk about my progress learning Bash for Gentoo ebuild development.

LINKS:
Bash By Example
http://www.ibm.com/developerworks/library/l-bash3.html
Linux Command Line and Shell Scripting Bible
http://xrl.us/bfzigo
Learning the Bash Shell
http://oreilly.com/catalog/9780596009656
Gentoo Tools
http://devmanual.gentoo.org/tools-reference/index.html
Sed By Example
http://www.gentoo.org/doc/en/articles/l-sed1.xml
Bash Guide
http://mywiki.wooledge.org/BashGuide
Grep
http://www.panix.com/~elflord/unix/grep.html
Awk
http://www.grymoire.com/Unix/Awk.html

irc network freenode channel #linuxcrazy

Download

Remi Cardona: Response to a comment

Remi Cardona (remi) — Thu, 29 Oct 2009 08:30:25 +0000

Benjamin wrote a comment on my last post, and I'll share my answers here because those questions come up every now and then, so it's better to try to inform everyone. (That and I never write on this blog, so this is a perfect excuse to do so)

If you assume compile problems, why is that thing unmasked?

Xorg-server 1.7 is not getting stabilized, it's just getting unleashed onto unstable. Unstable means exactly that. Of course we try to do our best and we won't release something we know will break. The idea behind unstable is for users to test the new and shiny stuff before it hits stable.

If you don't want to help fix bugs, use stable. It's as simple as that.

I've always been irritated by the way the xorg team handled masked/unstable/stable releases, as even rc's were unmasked at times.

Releases in X-land are tough. The numbers almost mean nothing. For instance, the last stable version in the 1.5 series was 1.5.3-r6. And despite the apparently stable version number, it currently has 80 patches to make it run smoothly.

On the opposite side, the current stable server is 1.6.3.901-r2, which is indeed a "pre point release" only has a couple patches. And 1.7.1 doesn't have any patches.

So don't let the version number fool you, they mean almost nothing.

As for what we put in portage, well X is a complex piece of software. It used to have more than a million lines of code and it's been getting some tough love these last 2 or 3 years. And up until recently, drivers were a mess. I had shivers every time a new driver was released : "How many systems will this break?" was a question I asked myself over and over.

There are probably a lot of people who put the xorg-server in package.keywords because they needed/wanted feature X/Y or because it fixed some bug for them (it did for me). So now I get a release that possibly breaks build in unstable?

Again, unstable is for power users who are not afraid of filing bug reports if something breaks. We try to make sure that things don't break every day, but Gentoo being a source distro with billions of possibilities (USE flags, CFLAGS, arches, packages, ...),you can't reasonably expect us to try every possible combination.

So we ask for you help (via bugzilla) in return. Gentoo is a community distro, after all.

So there, that's it for today, I hope y'all know a bit more about how we manage X and unstable packages.

Doug Goldstein: Subversion Branch Office Support aka commit-redir

Doug Goldstein (cardoe) — Thu, 29 Oct 2009 05:45:19 +0000

Right now at work we’re currently having an issue with branch offices and SVN. We’ve got a machine with some decent power with decent disk space handling our SVN repos. We’re running a 1.6 version repo that was dumped and reloaded with 1.6 so its using the newer format fully. However we still have employees at branch offices that often complain about the poor speed of SVN. Oddly the biggest complainers were Windows based devs and people using obscure (at least to me) GUI SVN tools. Currently our branch offices are all linked back to our main office over a VPN link with a dedicated 1.5mbit up and down to each remote office, with a possibility to burst up to 80% of total VPN bandwidth. A few complaints were attributed to poorly coded SVN clients (i.e. one employee’s client would perform an ‘svn log’ on the top level of the repo and filter out the correct level of messages on the client side). However the complaints have remained constant. To mitigate our guy handling our infrastructure configured SVN hotcopy repos at the branch office servers that allow everyone to get their data off those SVN servers (repo UUIDs were sync’d) and then commit back to the main office.

To remedy this I’ve created a new capability in SVN trunk. I’ve called it ‘commit-redir’. Basically a branch office employee can now checkout their code from a local SVN repo and commit as they normally would to that server instead of having to go through the time consuming steps of switching back to the main office repo. Transparent to them, the client advertises the ‘commit-redir’ capability to their local server, which then sees that its a read only mirror and replies back with the correct URL they should present the commit to. The client takes this response and re-submits the commit back to the main office. Net result, employees can enjoy the full speed of having a local mirror of SVN except when committing. They don’t have to jump through loops to use that local mirror and commit back.

Now I’ve still got some bugs in the code and some touch ups to do. We’re also not actually running the code at the office yet due to the afore mentioned bugs but I’m hoping this week to submit the code upstream and to start running it at our offices.

Doug Goldstein: nvidia-drivers 190.x

Doug Goldstein (cardoe) — Thu, 29 Oct 2009 03:23:19 +0000

NVIDIA has officially blessed the 190.x driver series to replace the 185.18.x series. Release highlights include:

xorg-server-1.7 support
OpenGL 3.2 support
VDPAU decoding of MPEG-4 Part 2, DivX 4, and DivX 5 depending on your GPU
Support additional GPUs in the GeForce GT series

For more details read their release notes, here.

Gentoo has had a few different developers maintaining “unofficial” drivers in the 190.x series. However there’s a few outstanding issues with those ebuilds that still need to be resolved before they’re unmasked. I’ll hopefully push 190.42-r2 unmasked later on this evening.

Diego E. Pettenò: Blog posts are no replacement for documentation

Diego E. Pettenò (flameeyes) — Tue, 27 Oct 2009 22:23:56 +0000

Since I was asked in a previous post I’d like to make some notes about why I “document by blog post” in so many occasions.

I know perfectly well that my blog posts are no replacement for proper documentation; code, procedures and policies need to be properly documented, and tied to the project they are supposed to document. Documentation by blog post is difficult to write, manage and search, and can be indeed useless for the most art.

So why do I write it? Well, most of the time I start a blog post with some ideas in mind, write down it, and then depending on the feedback I either continue the topic or drop it entirely. I guess the most prominent counter-example is the For A Parallel World (which I know I haven’t updated in a while).

Writing proper documentation is important, and I know that pretty well, I have written and ranted about that before as well. And it’s knowing that, that I started the Autotools Mythbuster project which, to be honest, has given me mixed feedback, and satisfaction. The problem is: writing a blog takes just a modicum of effort, because I don’t have any obligation about form, or grammar, or language; I might soft-swear from time to time in a post, I might rant, I might have some smaller mistakes around, both in grammar and content, and so on. I don’t go updating blog posts to fix grammar and style and so on. Writing complex and organized documentation requires a lot more work, and when I say a lot I mean quite a lot more. Of course the result is also of much higher quality, because of that.

I have tried finding alternative routes to get the good results out without having to just apply that much effort in my (unpaid) free time; the first option was LWN, which actually helped me paying for a good part of Yamato’s hardware. Unfortunately LWN is not a perfect solution for me; partly because my topics tend to be quite low-level, too low-level for the LWN readers I’m afraid, and too distant from the Kernel as well (which is probably the only low-level area that LWN really writes a lot about); the other problem is that LWN is still something similar to a magazine, a journal, and thus does not allow an easy way to organised documentation; like autotools-mythbuster is. It would still be a puzzle of entries; of higher quality than a blog, but still a puzzle.

The classical form for organised documentation is that of a book; in today’s age, ebooks are also quite often used, to avoid the whole mass-production and distribution trouble for topics that might not be of enough interest (interestingly enough, that’s not true still for a lot of books, so lately I actually had to by more paper books because I couldn’t find PDFs of them to use with the Reader). Now, this also have troubles; as you might remember I already tried looking for a publisher for Autotools Mythbuster, before going with the open project it’s now.

The idea behind that would have been putting as much effort as possible into that single piece of documentation, complete it as much as possible and get it out in some complete form. There you go: high-quality results, paid effort, and organised up. Unfortunately, finding a publisher is never an easy task, and for that topic in particular, I ended up hitting a stone wall: O’Reilly already had somebody working on the topic, and the book is out now I think (I haven’t read it). This actually was ignoring a problem with classical books: they cannot easily be updated; and documentation often has to be, to correct mistakes, grammar, style, and especially to be kept up to date with what they document. For instance, Autotools Mythbuster has a specific section on forward porting (which I’ll probably keep updating for the future versions as well).

So the final option was making it an open book; again, the effort is not ignorable, so my first solution was to write on it on a donation basis: would have covered the effort I needed to put into it, and would still have been able to be there for everybody. I didn’t count in the fact that the topic is too developer-oriented to actually be of any use to people who would be donating. Indeed, I wish to thank the last two donors (in terms of time), Thomas Egger (who sent me a good mouse to replace the stupid Mighty Mouse, you’ll soon see results about that, by the way), and Joseph Booker (who sent me some books, I started with The Brief Wondrous Life of OScar Wao because I was meaning to read it for almost two years now, but the useful one will soon prove useful, I’m sure). But they, like most others, never explicitly named the guide. And so I’m trying to find more time for the general postings than that in particular.

Just a note before you start wondering about the guide; yes I haven’t updated it in a while. Why? Because I sincerely feel like it’s not useful any more. As I said it requires a positive amount of effort to be extended; there is, true, some interest on it, but not enough to actually have moved anyone to ever try funding its extension. With O’Reilly now publishing a complete book on the matter, I don’t think it’s worth my time keeping it up. I might still extend it if I have to correct some build system, or if I discover something new, but not going to keep extending it by my own will without such a need.

Bottom-line: I could probably write more extensive, organised, and precise documentation about lots of stuff, especially the stuff I write about on the blog from time to time, but the problem is always the same: it requires time and effort; and both are precious commodity; most of my time is already committed to paid work nowadays, and Gentoo is getting more and more to the third place (first is work, second health). Documenting what I can with the blog is, in my opinion, still better than nothing, so I’ll keep doing that.

Josh Saddler: Intel graphics and gaming, Abiword 2.8.0

Josh Saddler (nightmorph) — Tue, 27 Oct 2009 19:07:03 +0000

Last night I installed UT2004 on my laptop, after not playing it since June. The laptop in question is an older ThinkPad R61i, with an Intel X3100 graphics chip. I know -- not the best for gaming. However, most online reports I found indicate that it's acceptable for such an old game as UT2004, so I figured it'd be worth a shot. The Intel graphics drivers have made a lot of progress in the last two years, especially on the 3D front, right? Right?

Kinda. After reducing all settings to "low" and dialing back the resolution to 1024x768 (native is 1280x800), the game is playable, but with very uneven framerates. Looking toward the middle of a map, or anyplace with a lot of action, introduces a good stutterfest; frames are down to between 8 and 18FPS. I enabled a few extra options such as pixel shaders and VBOs in UT2004.ini to add a bit more performance, but it's still marginal.

I'm rather disappointed. I'm not having nearly as great an experience as other Linux users, and certainly not as good as the Windows gamers who've benchmarked Unreal on this hardware. However, I did also catch the huge xorg-server 1.7 update as well, so maybe there have been some performance regressions since 1.6. It makes it a little hard to determine the areas that could use tweaking. I don't have anything special in my xorg.conf, just a default resolution. It's possible there's a setting I'm missing.

I'd like to try UT2004 on my desktop workstation, which has a RadeonHD 4550 card, but all reports indicate that even the latest git checkouts of the open-source drivers still don't work with Unreal. Apparently the game can't even launch, much less run at playable speeds. But as rapidly as the drivers are maturing, I'm hoping this'll be fixed in a month or so. Call me optimistic.

* * *

It looks like Abiword 2.8.0 was released today, so I wrote an ebuild and made it available in my devspace. I've been hand-writing these things for awhile. It took quite a bit of research to determine what went into the 2.7 betas, and now I'll have to do another overhaul of the 2.8 ebuild to account for the new plugin system. There's no longer a separate abiword-plugins package; they're all distributed in the base 2.8.0 archive. This means there will be a lot more tricky configure checks and USE flags, which sucks from a flexibility standpoint. Keeping the plugins in an external package was much simpler, so I'm a bit disappointed by this upstream decision.

Still, right now you can download and install Abiword 2.8.0 using my ebuild. While it needs a few cleanups, it will get you set up with a fully functioning basic Abiword install, though the only available plugin (as shown in the "Plugins" dialog) is .odt support.

This new version launches much quicker than 2.7.10, and it seems to have fixed all the rendering errors and even the crashes that happened with basic operations. Basically, you can click stuff now without worrying.

Cleaning up my ebuild is a long task, thanks to those darned plugins. Patches welcome, or I suppose you could always just wait and see what ends up in Bugzilla.

Original post from Planet Gentoo.

Remi Cardona: Xorg-server 1.7 in ~arch

Remi Cardona (remi) — Mon, 26 Oct 2009 21:50:42 +0000

It's out there now, available in ~arch. Like always, you'll need to rebuild your drivers, just look-up the command given by the server's ebuild (use eread if you've lost the output).

This release took a little longer to unmask not because of the server (it's a nice change). It's because a lot of headers were moved around from library packages to proto packages and vice versa. The ABI of X libraries has not changed, but I'm pretty sure there will be compile errors in some packages.

If that's the case, please file bugs in bugzilla.

Thanks for reading this public service announcement.

Edit: There will not be a package.keywords list for stable users. Xorg-server 1.7 is intended for ~arch users only, at this moment. And all bugs from stable users will be closed INVALID. We will start creating lists when we want to stabilize it.

Steve Dibb: new feeds

Steve Dibb (beandog) — Mon, 26 Oct 2009 17:46:23 +0000

I've been having a slew of issues running Apache on my Linode VPS, which I'm still trying to pin down, so in an attempt to offload some of the usage, I'm now going to use Feedburner to provide the RSS feed for Planet Larry.

I know I've played with Feedburner in the past, and kind of flip-flopped on whether to use it or not, but this time I'm sure I'm gonna stick with it. It's better for users, since they will always have a feed available (whether I have issues or not), and it's better for me since I can offload that part of the network traffic, which is actually quite a lot.

I've already updated the feeds and my apache config to do a permanent redirect, but if you want the feed URLs directly, here they are:

Planet Larry: http://feeds.feedburner.com/planet_larry
Larry the Universe: http://feeds.feedburner.com/universe_larry

Sorry for the inconvenience. It seems like everytime I post about Planet it's bad news or maintenance. Believe me when I say that it aggravates me far more than it does you.

Specifically, the issues I'm having is that Apache is sucking up all the available RAM, of which I only have 360 megs on my account. It's then rolling over to using all the swap space as well, which only slows things down even more. I've just started playing with tweaking the MPM configuration a bit, and I'm still trying to find a reasonable solution for my configuration.

In the past, the Linode had been seizing up occassionally, and I'd normally just reboot it and get on with my life. Recently, I installed monit (an awesome app), and pinpointed that the issue seems to always be with apache. Now, I'm just trying to narrow it down even more from there, but offloading the RSS feeds seems like a good step to take anyway ... I get gigabytes of traffic per month just on that, believe it or not.

I'm toying with the idea of setting up lighthttpd instead, but I really prefer apache, and would rather set it up to behave in a low memory environment instead. So, for any downtime in the near future, chances are it's just me tweaking something. At least now, thanks to monit, I have a much better idea of when something goes wrong.

Oh, one other tweak I've made is that the planet script itself is more robust as well. That thing used to run out of control, but I've made some changes that will ensure that if it runs away, at least it won't bring down the system. I also started playing around with the idea of writing my own feed parser to replace the Planet software completely, and it looks like it's going to be much simpler than I imagine. I haven't actually started down that path yet, since I have bigger projects to complete, but I'm actually enthusiastic that it'd be far, far simpler than I imagined.

Doug Goldstein: MythTV 0.22 & the database problem

Doug Goldstein (cardoe) — Mon, 26 Oct 2009 04:14:11 +0000

Shortly everyone will start seeing MythTV 0.22 Release Candidate packages (you won’t see Release Candidate 1 but a newer revision) appearing in the tree available to ~arch. Gentoo users need to know that the upgrade path won’t be smooth sailing. Unfortunately, the MythTV developers incorrectly use MySQL which results in data corruption which must be manually fixed. The steps to fix this are available on their website at, http://wiki.mythtv.org/wiki/Fixing_Corrupt_Database_Encoding.

Now you might say to yourself, “hey! That page blames distros specifically Gentoo for the data corruption!” I’ve discussed the issue in length with several developers in the #mythtv-dev channel and unfortunately I can’t change their tune. So all I can do is explain the issue to you, the reader, and let you be better informed.

MythTV originated as a project created by a US based developer and such it only needed to support the needs of the basic US English language set. As time wore on the project gained overseas attention and needed to support non-English character sets and data. A wise decision was made to switch to UTF-8 string handling in all of MythTV so that it would work no matter the language. However, the change was implemented poorly. The MythTV developers implemented UTF-8 conversion within MythTV while leaving their database encoding the same. This wasn’t a problem technically at first because MySQL pre-5.0 defaulted to latin1 encoding (this change was made when MySQL 3.23 was all the rage, especially for the MythTV devs who were overwhelmingly Debian based devs at the time). Fast forward a few years when MySQL released 5.0 and finally acknowledged they need to support UTF-8 out of the box. Gentoo followed upstream’s wishes and shipped their MySQL with UTF-8 as the default and worked with many package maintainers to resolve issues. Several distros (Red Hat, Fedora, Debian, Ubuntu) chose to remain at latin1 as their default so they wouldn’t have to deal with any package issues. Fast forward a few more years (hey let’s be realistic, MythTV releases take forever to come out) and MythTV finally switches to Qt4 (cause its only been almost a year and half since Qt3 was completely end of life’d) and their data conversion code needs to go through some changes. Unfortunately, this changed the on disk representation which is where we’re left now.

The real fix would have been for the developers to read the MySQL Character Set Support page and properly use the database to store the data its suppose to store instead of assuming everyone’s MySQL database would always be hard coded to latin1. And not just the database, but the server, the client libraries, the database and the connection. When they’re in fact sending UTF-8 data.

As a follow-up for those that will ask, no forcing MySQL to be recompiled with latin1 before the MythTV 0.22 upgrade will not fix the issue. In fact it will make it worse since MythTV 0.22 will error if it detects your connection character set is UTF-8 but if you recompile MySQL with latin1, then it won’t know that your database may be corrupt. I recommend following their instructions to fix the issue.

Diego E. Pettenò: Proprietaryware all around us

Diego E. Pettenò (flameeyes) — Mon, 26 Oct 2009 00:15:58 +0000

In a guest post at Boycott Boycott Novell I’ve written about my frustration with so-called “Free Software Fundamentalists”. My main problem with them is that they keep insisting in not using proprietaryware, at all, rather than improving Free Software till it actually becomes the norm.

Now, one thing that might be difficult to understand is that, no matter how hard you try, it’s near impossible to not use any kind of proprietary software nowadays. And while I’m one who fights with all his force to make sure that we have Free Software alternatives in such a state that it can be used in as many things as possible, I don’t try to fight the presence of the other kind of software. I might argue which one between their and my methods is the one that can reach the goal better, but that’s not what I wanted to write about right now.

For now I just wanted to note how impossible it is to not rely at least in part in proprietary, closed-source software (this also ties with an older post of mine about updates):

do you have a cellphone? unless you’re running stuff like OpenMoko, I doubt you have it pure free software, since even Nokia’s N900 has quite a few proprietary components;
okay so cellphones are evil, but do you have a standard phone? remember: if it has an address book it has a firmware on it (and even if it doesn’t it might have a firmware to manage some functions);
do you have a VCR? a DVD player? a DivX player? Is any of that running on a free software firmware?
cable or satellite TV? Sky (UK and Italy) definitely have firmware in their decoders (there is also some documentation about GPL violations in satellite decoders);
not even that, a simple TV? You know, not only they have firmware now, but they also come with an upgradable firmware (at least, my Sony Bravia does); some TVs also have free software on them (Sharp I happen to remember), although I highly doubt they have no proprietary bits in them; heck, remote controls have firmware as well, at least the programmable ones;
any game console? none that I know run on pure free software;
computers usually have proprietary BIOS, but coreboot is working to replace that; and at the same time we know of many projects working on replacing firmware for wifi cards (although I still can’t understand; why replacing a wifi card’s firmware, but not the SATA controller firmware?); laptops, on the other hand have a lot of components with firmware on them; for instance I remember Lenovo laptops having firmware to control the fans and similar subsystems; and I’m pretty sure “smart batteries” have firmware as well; UPSes have firmware; external drive enclosures have firmware (and there, replacing the firmware with some free software would definitely be useful, given how many bugs the Genesys Logic firmware has!); even keyboards have firmware, at least Apple’s and probably Logitech’s as well; bluetooth dongles have firmware; harddrives and SSDs have firmware;
so okay, you use no external hard drive, a motherboard supported by coreboot and so on, your computer is fine; what about the monitor connected to it?
and finally, if you’re not using computers (so what are you doing advocating free software?); are you using a modern microwave oven, dishwasher or washing machine? While there are still lots of those appliances that use no computer-like parts, and thus no firmware, quite a lot of the new ones use firmware which is proprietary; I actually find those quite obnoxious because, for instance, you cannot self-repair your washing machine if the mainboard fries up; the firmware (proprietary) has to be flashed in; and to make it even more impossible, they have to flash it with a special dongle, and a special phone, with UMTS connection;

So really, are you using any proprietaryware at all? If so, stop harassing my freedom of choice for a supposedly higher freedom.

Gilles Dartiguelongue: Gnome 2.28.1 is there

Gilles Dartiguelongue (eva) — Sun, 25 Oct 2009 23:32:45 +0000

http://dev.gentoo.org/~eva/gnome/gnome-2.28.0.html

Just added gnome-2.28.1 ebuild to the overlay, only had to keep two dependencies down. Since we are now finished with gnome-2.28 core, time to squash bugs, there is quite a number of them already, if you want to participate, just visit the overlay status/TODO or status/BUGS files, or visit gnome 2.28 official release tracker bug

Played with gnome-shell, kind of nice but still needs applet work done as I can't use gnome-globalmenu applet anymore and I'd like to keep to vertical space real estate. Plus I don't like the actual replacements for notification area and clock applet, they do less. I bit worried about speed in activities menu as well, it's damn slow on my Core2@2.2Ghz which I can't understand.

Also worked on some other ebuilds like geoclue, emerillion and seed, not easy on downstream packaging so delayed until further notice.

Original post blogged on b2evolution.

Diego E. Pettenò: A shared library by any other name

Diego E. Pettenò (flameeyes) — Sun, 25 Oct 2009 19:18:22 +0000

One interesting but little known fact among users and developers alike is the reason why shared libraries are installed on systems with multiple file names. This ties a bit into the problem of .la files, but that’s not my topic here.

Shared libraries, especially when built and installed through libtool, usually get installed with one file, and two symlinks: libfoo.so, libfoo.so.X and libfoo.so.X.Y.Z. The reasoning for this is not always clear, so I’ll try to shed some light on the matter, for future reference, maybe it can help solving trouble for others in the future:

first of all, the real file is the one with the full version: libfoo.so.X.Y.Z: this because libtool uses some crazy-minded versioning scheme that should make it consistent to add or remove interfaces… in truth it usually just drives developers crazy when they start wondering which value they have to increase (hint: no, the three values you set into libtool flags are not the same three you get in the filename);
the presence of the other two names are due to the presence of two linker programs: the build-time linker (or link editor) and the runtime (or dynamic) linker: ld and ld.so; each one uses a different name for the library;
the link editor (ld) when linking a library by short name (-lfoo) isn’t in the known about which version you’re speaking of, so it tries its best to find the library transforming it to libfoo.so, without any version specification; so that’s why the link with the unversioned name is there;
the dynamic linker, when looking up the libraries to load, uses the NEEDED entries in the .dynamic section of the ELF file; those entries are created based on the SONAME entry (in the same section) of the linked library; since the link editor found the library as libfoo.so it wouldn’t be able to use the filename properly; the SONAME also serves to indicate the ABI compatibility, so it is usually versioned (with one or more version components depending on the operating system’s convention — in Gentoo systems, both Linux and FreeBSD, the convention is one component, but exceptions exist); in this case, it’d be libfoo.so.X; so this is what the dynamic linker looks up, it’s also not in the known about the full version specification.

Now there are a few things to say about this whole situation with file names: while libtool takes care of creating the symlinks by itself, not all build systems do so; one very common reason for that is that they have no experience of non-GNU systems (here the idea of “GNU system” is that of any system that uses the GNU C library). The thing is, ldconfig on GNU systems does not limit itself at regenerating the ld.so cache, but it also ensures that all the libraries are well symlinked (I sincerely forgot whether it takes care of .so symlinks as well or just SONAME-based symlinks, but I’d expect only the latter). A few packages have been found before explicitly relied on ldconfig to do that using a GNU-specific parameter (a GNU lock-in — might sound strange but there are those as well) that takes care of fixing the links without changing the ld.so cache.

And there our beloved .la files come back in the scene. One of the things that .la files do is provide an alternative to the -lfoo → libfoo.so translation for the linkers that don’t do that by themselves (mostly very old linkers, or non-ELF based linkers). And once again this is not useful to us, at least in main tree, since all our supported OSes (Linux, FreeBSD, with all three the supported C libraries) are new enough to properly take care of that by themselves.

Nirbheek Chauhan: What's missing in Btrfs

Nirbheek Chauhan (nirbheek) — Sun, 25 Oct 2009 16:33:23 +0000

So, after being completely betrayed[1] by Ext4 not once, but twice, I decided to evaluate my FS options for /home .

FAT* are not an option, neither is NTFS.
Ext2 is primitive and HFS/HFS+ is just not Linux.
JFS is nice, but (atleast parted) doesn't support grow/shrink.
I've used XFS before, and found it to be more reliable than Ext4. However, deleting dirs with thousands of small files is too slow (a common operation when compiling)
ZFS would've been an option if my earlier experiences with ZFS-FUSE weren't so horrid.
Did not even consider NILFS. It's too new, and I don't know much about it.

It ended up being a choice between the reliable Ext3, or the new-fangled Btrfs. Why Btrfs? Because I've been using it as my Gentoo Distfiles and Portage tmpdir since v0.16, and found it to be the /most/ resilient to power failures of all my partitions.

I ended up selecting Ext3 for /home, but let's see why.

What's missing in Btrfs:

Growing the filesystem to the "left" of the partition. The error message when you try this is cryptic (common in btrfs-progs). However, since for other FSes this essentially involves "move to left and grow to right", I suppose the "move" part is what's missing in btrfsctl.
Pathetic ENOSPC handling. It either throws an ENOSPC at around 75% or when the metadata space fills up. Not sure which, but it's supposedly fixed for 2.6.32.
Volumes once created cannot be deleted. Again, fixed in 2.6.32.
Parted doesn't support editing/creating Btrfs partitions. Support for detecting it was proposed recently; but, I still don't see it in either "master" or "next". This is not a Btrfs problem, but certainly affects whether I'd use it.
There were other minor irritants (with btrfs-progs, mostly), but those will go away with time

Ext3 might have bad performance (especially w.r.t fsync), but atleast it's more reliable. In conclusion, I'll use Ext3 in data=ordered mode for /home till 2.6.33 is out; and then I'll convert my Ext3 partition to Btrfs and forever be happy :}

1. betrayed == sending everything into /lost+found after a forced fsck due to an earlier fsck after a power failure

Stuart Longland: Dusting off the MIPS boxes

Stuart Longland (redhatter) — Sun, 25 Oct 2009 12:06:37 +0000

Well… it has been a while… No, I haven’t gone AWOL, just been busy with other things for the past few months.

I’m now in the process of updating my MIPS boxes so that I can resume testing packages. I now have a stable kernel on my O2 (I nicked Debian’s kernel image… to install you just run ar x on the .deb, then unpack the data.tar.gz created into your /) and can seriously look at the userland.

First priority will be developer-related tools that I know well and can test quickly… Subversion is one that I’ll probably tackle, since the version we currently have keyworded is masked. Ditto for git. I’m sure I’ll find other things to get started on, but those two will make doing everyhing else easier.

I’ve also started on some new profiles. People can have a look at http://git.longlandclan.yi.org/?p=gentoo-mips-profiles.git or clone the repository at git://git.longlandclan.yi.org/gentoo-mips-profiles.git to give them a try. When I’ve given them a good thrashing and am satisfied, I’ll look at merging them into the tree, but for now, this is my staging area.

Hopefully with a stable base system upcoming, and new profiles, then I’ll look at new stages, and get this show back on the road.

Christian Faulhammer: Testers wanted for x86

Christian Faulhammer (fauli) — Sun, 25 Oct 2009 11:15:18 +0000

You are running a stable x86 system (at least almost, and for the core components like kernel, system set and X)? Great, we are looking for your help. If you want to try out the following packages and report back (even if everything is running smooth) to me (fauli AT gentoo.org) or the team (x86 AT gentoo.org), we would be happy. Stabilising so many core compontents that might render you system unusable is a big thing, so a lot of testing is appreciated. The packages in detail:

Thanks in advance to everyone who cares

Gentoo News: Gentoo Ten Live DVD 10.1 Release

Gentoo News () — Sun, 25 Oct 2009 04:02:12 +0000

Attention Gentoo Community,

After numerous bug fixes and enhancements the Ten Team would like to encourage everyone to try out the 10.1 release.

A FAQ is available to assist you. We have also started a thread in our Forum. Please post any BUGS you encounter.

Please download the latest testing release for your architecture Gentoo Ten Live DVD 10.1 x86 | Gentoo Ten Live DVD 10.1 amd64.

Thanks for your continued support,

The Gentoo-Ten Project

David Abbott contributed to the draft for this announcement.

Tobias Klausmann: Working together

Tobias Klausmann (klausman) — Sat, 24 Oct 2009 15:33:23 +0000

Recently, I've noticed some behaviour by package maintainers that really annoys me. I'm talking about the way stabilization requests are made. Normally, a package maintainer opens a stabilization request bug (STABLEREQ) detailing which version(s) of which package(s) he wants the arch teams to test and stabilize.

Another closely related request which suffers from the same problems I'll detail below are keyword requests. Those are pretty much the same as STABLEREQ, but for "~arch" instead of "arch". Also, the testing required usually is not as strict as that for STABLEREQ for obvious reasons.

For simple packages, neither usually causes problems. For complex packages, this may mean that dependencies need testing and keywording, in some cases five to ten packages on top of the one requested. Unfortunately, some package maintainers have taken up the habit of just dumping the request for their package in bugzilla without checking what dependencies might be needed. Checking the dependencies also involves which versions of the dependencies actually work, which ones are stable (yes, this might mean talking to other package maintainers!).

Another related gripe I have is being pushy with time frames when stuff should be tested and stable and when trouble comes up (test suite fails etc), completely ignoring the bug report the arch team files for half a year or longer.

This kind of added workload (of rather dreary work, to boot) is what makes arch testing so tedious sometimes. Not to mention the burn-out it causes. Not getting any positive feedback (from either users or other devs) doesn't help, either.

Guess I'm turning into a grumpy old dev. But still, try to be a bit nicer to the arch testers, mkay?

PS: Note that there are very positive counterexamples, too: the emacs guys always provide test plans, the security guys are always nice to work with, too. And of course several individuals who are just nice to work with.

Marcus Hanwell: Avogadro 1.0.0 Released!

Marcus Hanwell (cryos) — Fri, 23 Oct 2009 22:02:00 +0000

It is with great pleasure that I announce the release of Avogadro 1.0.0. After many years of work we have released what we consider to be a stable Avogadro release on Mole Day, which seems appropriate given the projects's name. There are still some rough edges, but I think this is a good release. With your help we can fix bugs in the release while working on new features in trunk.

Avogadro - Code Swarm from Marcus Hanwell on Vimeo.

What better time to look back to the beginnings of Avogadro. There was a blog post made today by Sourceforge about Avogadro detailing a little of that history. I have also made a code_swarm movie visualizing the history of the Avogadro project. There have been quite some changes in that time both at a project level and a personal level.

I would like to thank Google for sponsoring me for a GSoC project in the summer of 2007. Also Geoff Hutchison for giving me the opportunity to work with him at the University of Pittsburgh on interesting computational and visualization projects. Then there is my new employer, Kitware, who have provided me with an exciting opportunity to push scientific visualization and cross platform development to its limits.

To finish off a great day, my wife has informed me my new espresso machine has arrived! I am going to Camp KDE in January too!

Ryan Hill: Machinarium on 64bit Gentoo Linux

Ryan Hill (dirtyepic) — Thu, 22 Oct 2009 03:32:00 +0000

I had to spend a few hours trying to get Machinarium(flash required) running on my laptop the other night. Turns out the solution was too easy:

# USE=32bit emerge -av www-plugins/adobe-flash

Damn.

PS. if you like old-school adventure games, puzzles, or desolate post-apocalyptic cityscapes populated by melancholy anthropomorphized robots (yay), you could do worse than support Linux gaming by dropping 20 bucks on this fine piece of work.

Jonathan Callen: ... Is This Thing On?

Jonathan Callen (abcd) — Wed, 21 Oct 2009 21:41:22 +0000

Well, I finally broke down and created a blog. I’ll mainly be posting Gentoo-related stuff here, assuming I remember to update it.

Romain Perier: elog - why it's so important and why you must read it

Romain Perier (mrpouet) — Wed, 21 Oct 2009 19:23:23 +0000

That's not the first post about elog, previously Gilles (eva) posted an excellent entry about that (he was a slightly angry probably ). All these entries are published in order to warn users and they have its importance...So based on that fact it would be really nice if users start reading them

Last week, I did read at least 4 bugs about a problem due the newer version of shared-mime-info (which includes a new database format)... If you as users would read your elogs, guess what? Yes you would find the solution in elog messages.

Important...why ?

When a developer has a important message to deliver to a set of users for a given package, usually he uses elog (elog is logged => no excuses..).
Consider the previous example with shared-mime-info, you will have a lot of problems when you try to open some files (typically gnome/kde startup) which would have not happened if you have a look at your logs.

awesome... but how I can read them ?

That's seriously simple :

If you're a geek who loves GTK+ based applications (like me ) have a look at elogviewer
Use eread (c.f: man eread)

But for our sanity and peace in our souls "READ THEM" before you post a bug .
That will help us a lot, by implicitly reducing the number of useless bugs, and in this way, we will not have to repeat things 50 times.

have fun with gentoo

edit: many thanks to scarab for typos & grammar

Original post blogged on b2evolution.

Sune Kloppenborg Jeppesen: Supressing repeating log messages with Syslog-ng

Sune Kloppenborg Jeppesen (jaervosz) — Wed, 21 Oct 2009 17:57:09 +0000

Again today I was hit by Stunnel's excessive logging behaviour, causing my log files to grow rapidly with messages like:
stunnel: warning: can't get client address: Bad file descriptor

Which is caused by my Wifi going offline, I fail to see why Stunnel should log hundreds of lines each second if the network is unavailable....

In my five minute search I couldn't really see how I could get Stunnel to change logging behaviour, without disable logging alltogether.

However I finally figured out how to suppress repeat messages with Syslog-ng, like Metalog did back in the old days when I used that. Stunnel from 2.1.1 and up has a suppress(X) option that is not documented very good. With the suppress option Syslog-ng will apparently suppress repeat messages in X second intervals. You can use it simply like this:
destination messages { file("/var/log/messages" suppress(30)); };

So with a bit of luck I should not be hit by Stunnel logging again.

Ryan Hill: broken libgomp.la in recent GCC upgrades (aka "my imagemagick's broken")

Ryan Hill (dirtyepic) — Mon, 19 Oct 2009 03:23:28 +0000

Yeah, this bug is back again. Turns out the code that fixes the paths in gcc's own .la files was broken on new version installs. This means that everyone in stable that updated to gcc-4.3.4 and anyone in unstable that updated to 4.4.2 in the last week or so should resync their portage tree and rebuild gcc now.

See https://bugs.gentoo.org/283761 for the poop.

We won't be doing a revbump because this wasn't version specific. It just sucks that no one noticed the problem until a new version was released.

edit: if you're still getting errors when building, such as

/bin/grep: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgomp.la: No such file or directory
/bin/sed: can't read /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgomp.la: No such file or directory
libtool: link: `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.1/libgomp.la' is not a valid libtool archive

where "4.4.1" is the previous version of gcc you upgraded from, run

# fix_libtool_files.sh <old gcc version>

Christian Faulhammer: app-(x)emacs/gentoo-syntax 1.15 is out

Christian Faulhammer (fauli) — Mon, 19 Oct 2009 00:03:41 +0000

The last news I wrote about the Ebuild mode for both GNU Emacs and XEmacs is some days old and covered version 1.10. Meanwhile we added some functionality that will greatly improve your user experience. All detailed changes are to be found in the shipped ChangeLog file, but I want to give a rough overview about the most important features and the main contributor.

faster and more elegant code (ulm)
a manual in Info format (fauli), see C-h i under section Gentoo or Emacs, needs fine-tuning, patches welcome
support for GLEP 42 news items (ulm)
add skeleton support for ebuilds/news items from scratch (ulm)
keep eselect mode in sync with eselect features (ulm)
keep keywords in sync with eclasses and adding new ones, like mono and kde4 (fauli)
reinstate compatability with GNU Emacs 21 (ulm)
support for eblit files (ulm)

Now I want to move the spotlight onto the skeleton modes: Pressing C-c C-n in an empty file with ebuild extension, or whose file name matches the GLEP 42 requirements for a news file, will guide you through the creation of a new ebuild. You are asked for the needed items and with the tab key you can often choose from a list with sane entries. Especially news item creation gets easier as this is a seldom task for developers and thus error-prone while being a good measure to communicate important changes to users.

Gilles Dartiguelongue: The unending tale

Gilles Dartiguelongue (eva) — Sun, 18 Oct 2009 23:03:25 +0000

Ok guys, buckle up, I've finished reviewing Gnome 2.28 ebuilds except for the gnome-shell stuff. Now Gnome 2.28.1 is expected on wednesday so we can start bumping like crazy to be half-decently on time this time (feels like we'll never be done with the catch-up). There are still quite a few problems with packages as noted in my papers and files under status/ in overlay but upgrade experience should be smoother.

If you are about to test the overlay, please keep us posted on your problems (or your non-problems too) by contacting us on #gentoo-desktop or by filling bug reports. Thanks again to everyone who kept the overlay updated during 2.27 cycle.

edit: fix typo thanks to remi.

Original post blogged on b2evolution.

Diego E. Pettenò: Tip of the day: if Samba 3.4 fails to work…

Diego E. Pettenò (flameeyes) — Sun, 18 Oct 2009 12:18:34 +0000

I fought with this today… if you are running Gentoo ~arch you probably noticed that the current Samba support is “definitely suboptimal” (to use the words of the current maintainer) and indeed it failed to work on me once again (third time; the first was a broken init script; the second was missing USE deps so I was quite upset). If you find yourself unable to log-in Samba, you need to consider two possible problems.

First problem: the Samba password system seems to have either changed or moved so you have to re-apply the password to your user (and re-add the user as well!). To do so you have to use the smbpasswd command. Unfortunately this will fail to work when the system has IPv6 configured. And here comes the next problem.

Samba is likely having trouble upstream to deal with IPv6; indeed it comes down to having the smbpasswd command trying to connect to 127.0.0.1 (IPv4), but the smbd daemon is only opening :: (IPv6), so it’ll fail to connect and won’t let you set your password. To fix this, you have to change the /etc/samba/smb.conf file, and make sure that the old IPv4 addresses are listened to explicitly. If you got static IPs this is pretty simple, but if you don’t, you’ll have a little more complex situation and you’ll be forced to restart samba each time the network interface changes IP, I’m afraid (I haven’t been able to test that yet).

[global]
interfaces = 127.0.0.1 wlan0 br0
bind interfaces only = yes

As you can see we’re asking for some explicit interfaces (and the localhost address) to be used for listening; since samba uses the IPv4 localhost address for the admin utilities you explicit that to make sure it listens to that. For some reason I cannot understand, when doing this explicitly, samba knows to open different sockets for both IPv4 and IPv6, otherwise it’ll open it for IPv6 only.

I’m not even going to fight with upstream about this, I’m tired and I’m tracking down a bug in Gtk#; a nasty one that crashes the app when using custom cell renderers, and I already fixed iSCSI Target for kernel 2.6.32 (as well as version-bumped it).

Sebastian Pipping: Show desktop (or minimize all) in KDE 4

Sebastian Pipping () — Sat, 17 Oct 2009 12:36:13 +0000

Disclaimer: Please correct me if you know better. Thank you.

Back in KDE 3 I’ve been using WIN+D repeatedly to minimize all open windows (”show desktop”). In KDE 4 the “show desktop” feature seems to have been replaced by “show dashboard” (CTRL+F12), which is quite a different thing and not what I want.

As missing the minimize-all hotkey started really bugging me I invested a little time to find out if this is really the end. Luckily it’s not though I can only present a workaround rather than a “real solution”.

The easiest (only?) way to assign global hotkeys to programs in KDE 4 is adding an item to the KDE menu. So if we had a program/command to trigger a toggle on “show desktop” we were done. I found a tiny Bash script to do that:

#!/bin/sh
target=on
if xprop -root  _NET_SHOWING_DESKTOP | fgrep '= 1' ; then
    target=off
fi
wmctrl -k ${target}

(requires xprop and wmctrl, i.e. x11-apps/xprop and x11-misc/wmctrl in Gentoo)

Put that in a file called toggle-show-desktop.sh or so, make it executable and add a KDE menu entry for it:
(The Menu Editor can be found in the contect menue of the “KDE button” also know as Application Launcher Menu.)

Now assign a hotkey in the “Advanced” tab, done.

For comparison/completeness in KDE 3 it’s here:
.. and in XFCE here:

My next post/rant on KDE4 will probably be about the removal of vertical gradiants as desktop backgrounds. No, I don’t wat to do that with Gimp. Seems like I’m the only one ever having used it. Anyway…

Diego E. Pettenò: Tip of the day: move your f-spot Photo collection

Diego E. Pettenò (flameeyes) — Sat, 17 Oct 2009 12:26:57 +0000

Since today I’m pretty busy, I have no time for a complete post, but rather will give you a tip, if you’re using F-Spot and plan on moving your photos collection. Changing the location of the collection from the preferences not only won’t move your existing photos, but it won’t update the references in the DB either. This gets pretty bad if, like me, you’re forced to move the photo around between different filesystems (or in my case, disk entirely).

To solve that problem, I wrote this little Ruby script using sqlite3-ruby, that takes care of all that’s needed to move the photos:

#!/usr/bin/env ruby

require 'sqlite3'

db = SQLite3::Database.new(ARGV[0])

db.execute("SELECT DISTINCT base_uri FROM photos") do |row|
  newuri = row[0].gsub(ARGV[1], ARGV[2])
  db.execute("UPDATE photos SET base_uri = '#{newuri}' WHERE base_uri = '#{row[0]}'")
  db.execute("UPDATE photo_versions SET base_uri = '#{newuri}' WHERE base_uri = '#{row[0]}'")
end

It takes three parameters: the path to the SQLite database for F-Spot (generally ~/.config/f-spot/photos.db), the old path and the new path. Since the substitution is applied as-is, you need to use two slashes to make sure to start from the real root directory (like //media/photos).

Oh and for the Gentoo users reading this, what I wanted to write about was already written by Robin with better examples that I might have done. Kudos to Robin, and long live for the “old” networking scripts!

Robin Johnson: Useful and complex /etc/conf.d/net setups (In support of USE=oldnet)

Robin Johnson (robbat2) — Sat, 17 Oct 2009 10:29:58 +0000

I've been prodding at the concept of the new network script in OpenRC-0.5, and I'm at a loss to try and see why Roy has decided to toss the old network config system away. The new system doesn't have a lot of capabilities, and most significantly totally loses the ability to restart a single interface without affecting the rest of the system. If it's just for a rewrite, then I'm not too worried, but unless all the functionality is still there, I'm worried we are going to move backwards with it.

At the same time, I don't think many people are aware of how powerful the "old" network configuration mechanism is. The net.examples file is only the start, once you start mixing in the pre/post calls, there's a lot of power. It's capable of some feats that I don't see used even in certain parts of the Gentoo documentation^[1]. I've put together some of my gems of conf.d/net, and if you have some, I'd love to hear them. Leave a comment or email me the scripts, along with a description.

Configurations available

Easy to maintain HE.net (Hurricane Electric) IPv6 tunnels - Download
Running two ISPs at home (basic multi-homing) - Download
"Enterprise" multi-homing setup, with 4 paths to the Internet - Download

Hosting

I've also started a bit of storage in my Gentoo webspace for these collected works of network configuration, with a bit more documentation.

Notes

The Gentoo docs have this for IPv6: Gentoo IPv6 Router Guide, Tunnel Configuration. You could bring it up manually, or you could just take the IPv6 config above and use it straight with your variables filled in. Volunteers welcome to help merge that config into the Gentoo IPv6 documentation.

Markos Chandras: zen-sources again on Gentoo

Markos Chandras (hwoarang) — Thu, 15 Oct 2009 08:50:37 +0000

Having been a crazy ‘zen-sources’ user, I really miss those kernel patches nowadays. So I took up the bug 288512 and zen-sources are again available for all Gentoo users[1]
I haven’t committed them yet on portage tree because I want to ensure that they are safe enough for everyday usage. So until then, you can get them via a new overlay hosted on github

git clone git://github.com/hwoarang/zen-sources.git

or via layman

layman -a zen-sources

Special thanks to Brandon Berhent for providing the initial Gentoo ebuilds, and for developing the zen-sources

Thanks Brandon

Have fun with your brand new kernel sources[2]

[1] http://github.com/hwoarang/zen-sources

[2] http://www.zen-kernel.org

Tobias Scherbaum: Förderverein Gentoo e.V: Vorerst keine Auflösung

Tobias Scherbaum (dertobi123) — Wed, 14 Oct 2009 15:48:26 +0000

Vor rund 14 Tagen schrieb ich über die anstehende Auflösung des Förderverein Gentoo e.V. – nun 14 Tage später sieht erst einmal vieles danach aus, als wenn auf der kommenden Mitgliederversammlung ein neuer Vorstand gewählt werden kann und zumindest die Auflösung (vorerst?) vom Tisch ist. Die angedachte Mitgliederversammlung am Wochenende 07./08.11. in Bottrop findet ebenso nicht statt. Anstelle dessen wird voraussichtlich im Rahmen des 26C3 in Berlin (vermutlich am 27.12.) eine außerordentliche Mitgliederversammlung stattfinden. Alle Mitglieder des Vereins werden selbstverständlich zeitig hierzu eingeladen.

Ich möchte mich ausdrücklich bei denen entschuldigen, die mir in den vergangenen Wochen Mails mit Hilfsangeboten etc. zukommen lassen haben – ich konnte nicht alle Mails beantworten, aber es tut durchaus gut, zu sehen, dass auch andere noch ein Interesse am Verein haben. Dafür Danke!

Möglichst kurzfristig soll die Webseite des Vereins ein Facelift erhalten und ab dann im Idealfall regelmäßig mit frischen Informationen versorgt werden.

Gilles Dartiguelongue: To sleep or not to sleep

Gilles Dartiguelongue (eva) — Mon, 12 Oct 2009 23:23:11 +0000

It's over 1AM again, and I'm still not finished with Gnome 2.28 review. I've spent quite some time this weekend and tonight looking at what was wrong with gnote, gnome-system-monitor, gparted and a few other c++ apps suddendly starting to crash after I updated glib on Friday. Turns out something in the mm stack is doing something wrong so I filled Gnome bug #598209.

Updated to epiphany-2.28 since I got sick of epiphany-2.26 crashing when I wanted to make it remember a new password. Turns out it's not as nice as I would have thought a nearly two years efforts would be. Lots of problems where loading of a page would stop in the middle of the process. I had to install firefox to fill bug reports and access the pages that fails. That's quite a regression but upstream is now aware of it through Gnome bug #598115. Hopefully it'll be fixed for Gnome 2.28.1.

I also spent some time cleaning up unneeded revisions in tree since I had to occupy myself when building all those c++ bindings. So where are we now, a bit less than 41 packages to go for review and about 80% of completeness on my gnome 2.28 status page.

Original post blogged on b2evolution.

Gunnar Wrobel: layman moves from subversion to git

Gunnar Wrobel (wrobel) — Mon, 12 Oct 2009 13:49:04 +0000

In preparation for layman-1.2.4 the repository has been converted from subversion to git. The new repository can be found at git://layman.git.sourceforge.net/gitroot/layman/layman

Diego E. Pettenò: And finally, the Portage Tree overhead data

Diego E. Pettenò (flameeyes) — Sat, 10 Oct 2009 17:35:06 +0000

I’m sorry it took so long but I had more stuff to write about in the mean time, and I’m really posting stuff as it comes with some pretty randomly ordered things.

In the post about the Portage Tree size I blandly and incompletely separate the overhead due to the filesystem block allocation from the rest of size of the components themselves. Since the whole data was gathered a night I was bored and trying to fixing up my kernel to have both Radeon’s KMS and the Atheros drivers working, it really didn’t strike as a complete work, and indeed it was just to give some sense of proportion on what is actually using up the space (and as you might have noticed, almost all people involved do find the size, and amount, of ChangeLogs a problem). Robin then asked for some more interesting statistics to look at, in particular the trend of the overhead depending on the size of the filesystem blocks.

This post, which comes after quite some angst is going to illustrate the results, although they do tend to be quite easy to see with the involved graphs. I hope this time the graphs do work for everybody out of the box; last time I used Google Docs to produce the output and linked it directly, this saved a lot of traffic on my side, but didn’t work for everybody. This time I’m going to use my blog’s server to publish all the results, hoping it won’t create any stir on it…

First of all, the data; I’m going to publish all the data I collected here, so that you can make use of it in any way you’d like; please note that it might not be perfect, knowledge about filesystems isn’t my favourite subject, so while it should be pretty consistent, there might be side-effects I didn’t consider; for instance, I’m not sure on whether directories have always the same size, and whether that size is the same for any filesystem out there; I assume both of these to be truths, so if I did any mistake you might have to adapt a bit the data.

I also hasn’t gone considering the amount of inodes used for each different configuration, and this is because I really don’t know for certainty how that behaves, and how to find how much space is used by the filesystem structures that handle inodes’ and files’ data. If somebody with better knowledge of that can get me some data, I might be able to improve the results. I’m afraid this is actually pretty critical to have a proper comparison of efficiency between differently-sized blocks because, well, the smaller the block the more blocks you need, and if you need more blocks, you end up with more data associated to that. So if you know more about filesystems than me and want to suggest how to improve this, I’ll be grateful.

I’m attaching the original spreadsheet as well as the tweaked charts (and the PDF of them for those not having OpenOffice at hand).

This first graph should give an idea about the storage efficiency of the Gentoo tree changes depending on the size block size: on the far left you got the theoretical point: 100% efficiency, where only the actual files that are in the tree are stored; on the far right an extreme case, a filesystem with 64KiB blocks… for those who wonder, the only way I found to actually have such a filesystem working on Linux is using HFS+ (which is actually interesting to know, I should probably put in such a filesystem the video files I have…); while XFS supports that in the specs, the Linux implementation doesn’t: it only supports blocks of the same size of a page, or smaller (so less than or equal to 4KiB) — I’m not sure why that’s the case, it seems kinda silly since at least HFS+ seems to work fine with bigger sizes.

With the “default” size of 4KiB (page size) the efficiency of the tree seems to be definitely reduced: it goes down to 30%, which is really not good. This really should suggest everybody who care about storage efficiency to move to 1KiB blocks for the Portage tree (and most likely, not just that).

This instead should show you how the data inside the tree is distributed; note that I dropped the 64KiB-blocks case, this because the graph would have been unreadable: on such a filesystem, the grand total amounts of just a bit shy of 9GB. This is also why I didn’t go one step further and simulated all the various filesystems to compare the actual used/free space in them, and in the number of inodes.

This is actually interesting, the fact that I wanted to comment on the chart, not leaving them to speak for themselves, let me find out that I did a huge mistake and was charting the complete size and the overhead instead of the theoretical size and the overhead in this chart. But it also says that it’s easier to note these things in graphical form rather than just looking at the numbers.

So how do we interpret this data? Well, first of all, as I said, on a 4KiB-sized filesystem, Portage is pretty inefficient: there are too many small files: here the problem is not with ChangeLog (who still has a non-trivial overhead), but rather with the metadata.xml files (most of them are quite small), the ebuilds themselves, and the support files (patches, config files, and so on). The highest offender of overhead in such a configuration is, though, the generated portage metadata: the files are very small, and I don’t think any of them is using more than one block. We also have a huge amount of directories.

Now, the obvious solution to this kind of problems, is, quite reasonably actually, using smaller block sizes. From the reliability chart you can see already that without going for the very-efficient 512 bytes blocks size (which might starve at inode numbers), 1 KiB blocks size yields a 70% efficiency, which is not bad, after all, for a compromise. On the other hand, there is one problem with accepting that as the main approach: the default for almost all filesystems is 4KiB blocks (and actually, I think that for modern filesystems that’s also quite a bad choice, since most of the files that a normal desktop user would be handling nowadays are much bigger, which means that maybe even 128KiB blocks would prove much efficient), so if there is anything we can do to reduce the overhead for that case, without hindering the performance on 512 bytes-sized blocks, I think we should look into it.

As other have said, “throwing more disks at it” is not always the proper solution (mostly because while you can easily find how to add more disk space, it’s hard to get reliable disk space. I just added two external WD disks to have a two-level backup for my data…

So comments, ideas about what to try, ideas about how to make the data gathering more accurate and so on are definitely welcome! And so are links to this post on sites like Reddit which seems to have happened in the past few days, judging from the traffic on my webserver.

Robin Johnson: Gentoo release statistics as of 2009/10/09 23h59 UTC

Robin Johnson (robbat2) — Sat, 10 Oct 2009 05:53:20 +0000

solar was asking about release statistics, so I grabbed the current data from Bouncer. The nearly 34k releases for 10.0 is just in the 5 days that it's been out. I included the various architetures that were part of each released 'product', to make some degree of comparision possible.

What	Hits	Arches
2005.1
installcd-minimum	228561	alpha,amd64,hppa,ia64,ppc,ppc64,sparc64,x86
installcd-universal	374388	alpha,amd64,hppa,ppc,sparc64,x86
packagecd	162537	alpha,amd64,ppc,ppc64,sparc64,x86

2006.0
livecd	242422	x86
minimal	287496	alpha,amd64,hppa,ia64,ppc,ppc64,sparc64,x86
packagecd	42572	amd64,ppc-g4,ppc-ppc,sparc64
packagecd-32ul	10909	ppc64
packagecd-64ul	2981	ppc64
universal	111359	alpha,amd64,hppa,ppc,ppc64,sparc64

2006.1
livecd	307481	amd64,x86
minimal	330505	alpha,amd64,hppa,ia64,ppc,ppc64,sparc64,x86
packagecd	39118	ppc,ppc-g3,ppc-g4,ppc64,ppc64-g5
universal	122280	alpha,hppa,ppc,ppc64,sparc64

2007.0
bt-http-seed	72980	ALL
livecd	411958	amd64,x86
minimal	496943	alpha,amd64,hppa,ia64,ppc,ppc64,sparc64,x86
packagecd	27593	ppc-g4,sparc64
universal	137554	hppa,ppc,ppc64,sparc64

2008.0_beta1
livecd	19426	amd64,ppc64,x86
livedvd	4	amd64,x86
minimal	14069	alpha,amd64,hppa,ia64,ppc64,sparc64,x86
universal	1745	ppc64,sparc64

2008.0_beta2
livecd	37771	amd64,x86
livedvd	17842	amd64,x86
minimal	55745	alpha,amd64,hppa,ia64,ppc,sparc64,x86
universal	3142	ppc,sparc64

2008.0
livecd	477934	amd64,x86
minimal	406531	alpha,amd64,hppa,ia64,ppc,sparc64,x86
packagecd	12308	sparc64
universal	83600	hppa,ppc,sparc64

10.0_pre20090926-1952
livedvd	4870	amd64,x86

10.0
livedvd	33703	amd64,x86

10.1
livedvd	0	amd64,x86

Notes

2008.* has the LiveDVD's pulled from mirrors due to size complaints.
bt-http-seed was an (failed) experiment with a set of mirror URLs for trying to load-balance Bittorrent's HTTP seeding
Bouncer really needs replacing, but there's nothing really good to do so that I'm aware of. mod_sentry isn't nice. Other suggestions welcome. Should support products, architectures within products, seperate check/serve URLs, detailed hit recording for analysis.

David Abbott: Gentoo Ten Live DVD 10.1 (New Release)

David Abbott (dabbott) — Sat, 10 Oct 2009 01:41:28 +0000

After numerous bug fixes and enhancements the Ten Team would like everyone to try out the 10.1 release.
Downloads
Gentoo Ten Live DVD 10.1 x86
Gentoo Ten Live DVD 10.1 amd64

A FAQ is available to assist you. We have also started a thread in our Forum. Please post any BUGS you encounter.

Thank you for your support.

Planet Gentoo

Donnie Berkholz: links for 2009-11-06

Gentoo News: Gentoo KDE3 Deprecation Notice

Alex Alexander: KDE in Gentoo, an update

Diego E. Pettenò: Distributions *are* the strength of Linux

Steve Dibb: my blu-ray ripping trial run

Diego E. Pettenò: ELF should rather be on a diet

Steve Dibb: closed captioning on dvds (and ripping them)

Diego E. Pettenò: The PIE is not exactly a lie…

Diego E. Pettenò: Changes in the comment antispam

Jeremy Olexa: Gentoo: About “optimizing”

Doug Goldstein: Improved VDPAU abstraction

Doug Goldstein: nvidia-drivers and xorg-server compatiblity

Jeremy Olexa: Using sshfs with rtorrent

Gilles Dartiguelongue: Gnome 2.28.1 full steam

David Abbott: Podcast 65 Bashed In The Head

Remi Cardona: Response to a comment

Doug Goldstein: Subversion Branch Office Support aka commit-redir

Doug Goldstein: nvidia-drivers 190.x

Diego E. Pettenò: Blog posts are no replacement for documentation

Josh Saddler: Intel graphics and gaming, Abiword 2.8.0

Remi Cardona: Xorg-server 1.7 in ~arch

Steve Dibb: new feeds

Doug Goldstein: MythTV 0.22 & the database problem

Diego E. Pettenò: Proprietaryware all around us

Gilles Dartiguelongue: Gnome 2.28.1 is there

Diego E. Pettenò: A shared library by any other name

Nirbheek Chauhan: What's missing in Btrfs

What's missing in Btrfs:

Stuart Longland: Dusting off the MIPS boxes

Christian Faulhammer: Testers wanted for x86

Gentoo News: Gentoo Ten Live DVD 10.1 Release

Tobias Klausmann: Working together

Marcus Hanwell: Avogadro 1.0.0 Released!

Ryan Hill: Machinarium on 64bit Gentoo Linux

Jonathan Callen: ... Is This Thing On?

Romain Perier: elog - why it's so important and why you must read it

Sune Kloppenborg Jeppesen: Supressing repeating log messages with Syslog-ng

Ryan Hill: broken libgomp.la in recent GCC upgrades (aka "my imagemagick's broken")

Christian Faulhammer: app-(x)emacs/gentoo-syntax 1.15 is out

Gilles Dartiguelongue: The unending tale

Diego E. Pettenò: Tip of the day: if Samba 3.4 fails to work…

Sebastian Pipping: Show desktop (or minimize all) in KDE 4

Diego E. Pettenò: Tip of the day: move your f-spot Photo collection

Robin Johnson: Useful and complex /etc/conf.d/net setups (In support of USE=oldnet)

Configurations available

Hosting

Notes

Markos Chandras: zen-sources again on Gentoo

Tobias Scherbaum: Förderverein Gentoo e.V: Vorerst keine Auflösung

Gilles Dartiguelongue: To sleep or not to sleep

Gunnar Wrobel: layman moves from subversion to git

Diego E. Pettenò: And finally, the Portage Tree overhead data

Robin Johnson: Gentoo release statistics as of 2009/10/09 23h59 UTC

David Abbott: Gentoo Ten Live DVD 10.1 (New Release)

Diego E. Pettenò: Distributions are the strength of Linux