. Alec Warner
. Alex Alexander
. Alex Legler
. Alexis Ballier
. Andreas Proschofsky
. Andrew Gaffney
. Arun Raghavan
. Ben de Groot
. Bernard Cafarelli
. Bjarke Istrup Pedersen
. Brent Baude
. Caleb Tennis
. Christian Faulhammer
. Christian Zoffoli
. Damien Krotkine
. Daniel Drake
. Daniel Gryniewicz
. Daniel Ostrow
. David Abbott
. David Shakaryan
. Davide Italiano
. Denis Dupeyron
. Diego E. Pettenò
. Donnie Berkholz
. Doug Goldstein
. Gentoo Haskell Herd
. Gentoo News
. Gilles Dartiguelongue
. Greg KH
. Gunnar Wrobel
. Gustavo Felisberto
. Hanno Böck
. Hans de Graaff
. Ioannis Aslanidis
. Jan Kundrát
. Jeffrey Gardner
. Jeremy Olexa
. Joe Peterson
. Jonathan Smith
. Jorge Manuel B. S. Vicetto
. Joseph Jezak
. Josh Saddler
. José Alberto Suárez López
. Kenneth Prugh
. Krzysiek Pawlik
. Lance Albertson
. Luca Barbato
. Luis Francisco Araujo
. Marcus Hanwell
. Mark Kowarsky
. Mark Loeser
. Markos Chandras
. Markus Ullmann
. Mart Raudsepp
. Matthias Geerdsen
. Michael Marineau
. Michal Januszewski
. Mike Doty
. Mike Pagano
. Mounir Lamouri
. Nathan Zachary
. Ned Ludd
. Nirbheek Chauhan
. Olivier Crête
. Patrick Kursawe
. Patrick Lauer
. Patrick McLean
. Paul de Vrieze
. Peter Weller
. Petteri Räty
. Piotr Jaroszyński
. Remi Cardona
. Renat Lumpau
. Rob Cakebread
. Robert Buchholz
. Robin Johnson
. Romain Perier
. Ryan Hill
. Sebastian Pipping
. Serkan Kaba
. Shyam Mani
. Steev Klimaszewski
. Stefan Schweizer
. Steve Dibb
. Stuart Longland
. Sune Kloppenborg Jeppesen
. Sven Wegener
. Thilo Bangert
. Thomas Anderson
. Timothy Redaelli
. Tiziano Müller
. Tobias Klausmann
. Tobias Scherbaum
. Yuval Yaari
. Zack Medico
. Zhang Le
Last updated:
October 09, 2009, 23:03 UTC
Disclaimer:
Views expressed in the content published here do not necessarily represent the views of Gentoo Linux or the Gentoo Foundation.
Bugs? Comments? Suggestions? Contact us: planet@gentoo.org
Powered by:
Planet Venus
Welcome to Planet Gentoo, an aggregation of Gentoo-related weblog articles written by Gentoo developers. For a broader range of topics, you might be interested in Gentoo Universe.
|
Assuming all goes well today (I don't fall into an alternate universe), I'll be taking part in the Utah Open Source Conference a bit. There is going to be a *nix Distribution Round Table discussion, and I'll be representing Gentoo Linux. Yeehaw. Please be sure to hold your applause until the end. Acutally, to be honest, I'm a bit nervous, since I have no clue what I'm going to say, and I don't do well with crowds. Should be interesting. Maybe it'd be a good time to pitch Ubeantoo. |
|
You might wonder why the PAM support for special authentication method is somewhat lacking in Gentoo; the reason is that, mostly, I maintain PAM alone, which means that you get to use whatever I use myself most of the time. One of the things that I was very upset we didn’t support properly was the Smartcard/Token based authentication; unfortunately, while I got two smartcard readers in the past months to do some work, I hadn’t fetched a smartcard yet, and tokens seem to be quite difficult to find for end users like me. Thanks to Gilles (Eva), I now have a token to play with, and that means I’m looking to write up proper support for token-based authentication (and thus, smartcard-based as well). This already started well, because I was able to get one patch (split in three) merged in pam_pkcs11 upstream (available in the gentoo 0.6.1-r1 ebuild), as well as cleaning up the ebuild to work just like it’s supposed to as a PAM ebuild (for instance not installing the .la files which are not used at all). But since this is not yet ready to use, it’s easier if I show you how it works after a day or two of tweaking: Yes today I was quite bored. Please note that this is not really “production ready” in my opinion:
This mostly means that there’s going to be a long way to go before this is ready, and I’m pretty sure I’ll have to write a complete documentation on how to set it up, rather than just a blog post with a video, but at least it’s going to be feasible, at one point. Please feel free to comment on whether the video is useful at all or not; I’m trying to experiment with less boring methods of explaining stuff related to Gentoo and free software in general, but I have no clue whether it’s working or not, yet. |
|
And here, the term “man” refers to the manual page software. I already noted that I was working on fixing man-db to work with heirloom-doctools but I didn’t go in much details about the problems I faced. So let me try to explain it a bit in more detail, if you’re interested. The first problem is, we have two different man implementations in portage: The “classic” implementation is often despised because, among other things, it’s not designed with UTF-8 in mind at all, and even its own output, for locales where ASCII is not enough, is broken. For instance, in Italian, it outputs a latin1 bytestreams even when the locale is set to use UTF-8. Confusion ensures. The new implementation should also improve the caching by not using flat-files for the already-processed man pages, but rather using db files (berkeley or gdbm). So what’s the problem with man-db, the new implementation? It supports UTF-8 natively, so that’s good, but the other problem is that it’s only ever tested coupled with groff (GNU implementation of the (n)roff utility), and with nothing else. How should this matter? Well, there are a few features in groff that are not found anywhere else, this includes, for instance, the HTML output (eh? no I don’t get it either, I can tell that the nroff format isn’t exactly nice, and I guess that having the man pages available as HTML makes them more readable for users, but why adding that to groff, and especially to the man command? no clue), as well as some X-specific output. Both those features are not available in heirloom, but as far as I can see they are so rarely used that it really makes little sense to depend on groff just because of those; and the way man-db is designed, when a nroff implementation different from groff is found, the relative options are not even parsed or considered; which is good to reduce the size of the code, but also requires to at least compile-test the software with a non-groff implementation, something that upstream is not currently doing it seems. More to the point, not only the code uses broken (as in, incomplete) groff-conditionals, but the build system does depend on groff as well: the code to build the manual called groff directly, instead of using whatever the configure script found, and the testsuite relied on the “warnings” feature that is only enabled with groff (there was one more point to that: previously it returned error when the But it doesn’t go much better from here on: not only man-db tries to use two output terminals that are no defined by the heirloom nroff (so I hacked that around temporarily on heirloom itself, the proper fix would be having a configuration option for man-db), but it also has problems handling line and page lengths. This is quite interesting actually, since it took me a long time (and some understanding of how nroff works, which is nowhere near nice, or human). Both nroff and groff (obviously) are designed to work with paged documents (although troff is the one that is usually used to print, since that produces PostScript documents); for this reason, by default, their output is restricted width-wise, and has pagebreaks, with footers and headers, every given number of lines. Since the man page specification (command, man section, source, …) are present in the header and footer, the page breaks can be seen as spurious man page data in-between paragraphs of documentation. This is what you read on most operating systems, included Solaris, where the man program and the nroff program are not well combined. To avoid this problem, both the man implementations set line and page breaks depending on the terminal: the line break is set to something less than the width of the terminal, to fill it with content; the page break is set as high as possible to allow smooth scrolling in the text. Unfortunately, we got another “groff versus the world” situation here: while the classic nroff implementation sets the two values with the The classic man implementation, then, uses both the command and the register approach, but without option switches; instead it prepends to the manpage sources the roff commands ( Now we’re in quite a strange situation: from one side, the classic man implementation sucks at UTF-8 (in its own right), but it works mostly fine with heirloom-doctools (that supports UTF-8 natively); from the other side we got a newer, cleaner (in theory) implementation, that should support UTF-8 natively (but requiring a Debian-patched groff), but has lock-ins on groff (which definitely sucks with UTF-8). The obvious solution here would be to cross-pollinate the two implementations to get a single pair of programs that work well together and has native UTF-8; but it really is not easy. And at the end… I really wish the roff language for man pages could die in flames, it really shows that it was designed for a long-forgotten technology. I have no difficulty to understand why GNU wanted to find a new approach to documentation with info pages (okay the |
|
I say “default editor” in quotes because Gentoo really does not have a default editor, but rather a fallback-editor for whenever the users hadn’t chosen one themselves. And this is why stuff like the stage3, sudo, openrc and so on default to that when Paul, in the previous post explained it quite well, albeit briefly, but since some other people asked me about that again, I’ll quote him and then go in a bit more of details:
Indeed Paul speaks well: neither vi (or vim) nor emacs (or xemacs) is going to work. Why is that? Some people even goes as far to say that “it’s called *vi*sudo“ and “vi is the default Unix editor”. At the same time, I wouldn’t be surprised to hear “Emacs is the default GNU editor”. Well, let’s decompose it in two different problems. Technical problem: the system set is messy already (and this is also “thanks” to my own pambase creation — which is, though, a solution to a previous problem). The packages that do enter the system set should be, whenever possible, small and with little dependencies. This includes, obviously, USE-optional dependencies, since when they are enabled, the dependencies also become part of the system set (like it happens with gnome and pambase). The dependency tree of nano is near invisible, while those of both vim and emacs are quite long (sure there are things like elvis, nvi, zile and jove, but this will bring us to the next point…). Reality problem (or flame-retardant method): there is no way on Earth that any average number of people will be accepting to use the same editor as default, when taken from the list of “most popular” editors. Hey we cannot even find consensus among the three developers of lscube (I’m using Emacs – yeah I’m an Emacs user, burn me – and my colleagues using VIM and Eclipse). If we were to choose vim, all Emacsen users will complain, if we were to use GNU Emacs, both vim and XEmacs users will complain, and so on so forth. So we use nano, which is likely to make unhappy the most people, but all in the equal amount. There’s a corollary to the reality problem above: if we were to choose any of the lightweight variants that I named above, or more of them, most likely the problem would be more or less the same, since almost all people would be pretty unhappy with the choice and would then unmerge that and install their editor of choice. But it would most likely upset the two “main factions” unequally, which would make one feel discriminated against. Newbie problem: finally, there is another note: both Emacs and VI (and respective clones) aren’t exactly the most user-friendly editors. A newbie user who has no clue how to work in Gentoo is unlikely to guess at first sight how to use either of them, while nano is pretty much the easiest thing you might find around. You can fight as much as you want about powerfulness (Emacs and VI are obviously much more powerful than nano) and you can fight about relative easiness of use ( So no, we’re not going to change the default anytime soon. |
|
Happy Tenth Birthday, Gentoo! Gentoo Linux is proud to announce the immediate availability of a new, special edition LiveDVD to celebrate this monumental occasion. The LiveDVD features a superb list of packages, some of which are listed below. 
The Gentoo-Ten LiveDVD is available in two flavors, a hybrid x86/x86_64 version, and an x86_64-only version. The livedvd-x86-amd64-32ul-10.0 will work on x86 or x86_64. If your arch is x86, then boot with the default gentoo kernel. If your arch is amd64 boot with the gentoo64 kernel. This means you can boot a 64bit kernel and install a customized 64bit userland while using the provided 32bit userland. The livedvd-amd64-multilib-10.0 version is for x86_64 only. Please select your architecture to be redirected to a mirror for download: x86amd64 A FAQ is available to assist you. We have also started a thread in our Forum. Please post any bugs you encounter. In addition, we have some exceptional new artwork from Ben Stedman, and Gentoo Developer Alex Legler. Thank you for your continued support, Gentoo Linux Developers, The Gentoo Linux Foundation, and The Gentoo-Ten Project |
|
In overlay news, we are currently at 75% of completeness for the 2.28 release. Currently reviewed 46 ebuilds, at bit less than 55 to go. In other news, if you get strange gnupg related failures, head over to bug #275291. We will apply patch when someone from gnome herd has a chance to get around it. Update: fix typo |
|
Gentoo/PPC team is here to make sure packages are marked stable and are keyworded as soon as possible and without breaking the tree. Unfortunately, we can't manage the flow of bugs coming and the list is growing too quickly. So if you have a PowerPC and you want to help, you can and we will appreciate it ! I've made some bug lists to make the life of everybody easier: Please, refer to the Gentoo/PPC testing doc if you want to help on one of these bugs. Do not hesitate to come see us on #gentoo-powerpc on freenode. |
|
Woot! Happy Birthday Gentoo. As part of the Birthday party today we announce the winning screenshots. Thanks to everyone who entered the contest. There were 54 entries using 5 different window managers / desktop environments.
For all the specifications and cool details please visit the winners page. |
|
Some of you might have noticed that I’ve been attacked in the past few days over a feature change bug (now unrestricted so you all can judge it for what it was) with sudo. Let’s try to explain what the problem seems to have been with that bug: the sudo ebuild, since a long time ago, when it was maintained by Tavis Ormandy (taviso, of, among other things, ocert fame), changed the default editor used to nano. The reasoning for this is that you have to have a valid default editor in sudo, and that, after all, is what we ship in the stage3 as default editor, and what OpenRC sets as default editor if the user sets nothing else. I kept the same setting because, well, I could see the point in it; and I’m not a nano user, I don’t have a single nano executable on my main running systems: I use GNU Emacs for all my “heavy” editing, and zile (of which I’m a minuscule contributor from time to time) for the smaller stuff. This is just the default editor used by sudo, but by no definition the only one. Indeed it’s mostly used in two places: visudo and sudoedit. The former, respects the EDITOR variable, with the usual rules, so if your root user has the EDITOR variable set to anything it’ll be used (this is also not a default, we pass explicitly the Why did we ask sudo to explicitly honour the EDITOR variable? Isn’t that unsafe? Well, not really. First of all, sudoedit is a special command that takes care of allowing an user to edit a file without running anything as root user, so the EDITOR will always be fired up with the same permission as the user running it (pretty cool stuff); and for what concerns visudo… if you allow an user to run visudo, they can easily set up their user to do anything at all, so the permission under which EDITOR runs is pretty much moot. So why did I refuse to use the EDITOR variable in the ebuild? Well the reason is that I hate that particular dirty hack (because a dirty hack it is). Other ebuilds, like fcron, have been doing it, and I don’t like its use there either. The reason is that it makes package building relying on a variable that is not by default saved anywhere, and that might not really be the same between the build and host machines (just as a further example, I have different EDITOR settings between root and my user… if I were to build sudo right now_, with solar’s changes, with my usual method – sudo emerge with envkeep – I would get a build error: #!/bin/sh
if [ $# != 1 ]; then
echo "$0 accepts exactly one parameter." >/dev/stderr
return 1
fi
if [ "x$EDITOR" = "x" ]; then
echo "The EDITOR variable must be set." >/dev/stderr
return 1
fi
exec "$EDITOR" "$1"Note: I wrote this snippet right at my blog, I haven’t tested, checked, re-read it at all. This would allow ebuilds to properly set a default (or even a forced default!) in their configuration stages, without getting in the way of users’ choices. Now, this is going to require a bit of work; the reason for that is that you have to make sure that it works standalone, that it works with the packages that would like to use it, and most likely you want to make available a “safe-editor” script as well, to enable eventual safe modes where shell-escape (as well as opening random files) is disabled, for those applications that do open the editor as a different user. Since I have never seen much point in pushing this further (I have a long TODO list of stuff much more important for QA, Gentoo and users as a whole), I haven’t done anything about it before, and I didn’t want to start that. But hey if somebody wanted to contribute it, I would have been the first one making use of it. Now, how much in the way of users I have been by passing Too much work to use # mkdir -p /etc/portage/env/app-admin
# echo &aposEXTRA_ECONF=\&apos$EXTRA_ECONF --with-editor="${EDITOR}"\&apos&apos >> /etc/portage/env/app-admin/sudoIt really isn’t that dificult, is it? And what really ticked me off is users, which, as precious as they are, are still just users (in this case not even a well-known power user) telling me what the “Gentoo way” is… I think I know pretty well the Gentoo way, given I’ve been a major developer for the most part of the past five years, I’m one of those trying his best to keep everything up to date and maintained, I’m the one who’s running his own workstation to make sure that Gentoo packages do build out of the box. |
|
For hose who’re still worried after my latest health post I have good news finally. In the past three weeks my blood sugar levels kept between 62 and 118 mg/dL which is definitely not bad. This is, though, while I’m taking both metformin and glibenclamide pills (400+2.5g each meal). I also increased my usual exercise, thanks to Nintendo’s Wii Fit (the best way to stop a geek from being sedentary: give him a chart to follow!). My eyesight is, though, still fluctuating, although the €65 glasses I bought are definitely useful hen reading, especially stuff written quite small, I’m now using fewer days than I expected them to be used. They are also only for near sight obviously, so I can only use them to read or write, but that’s also fine. After all, they are temporarily and I paid them quite less than the ones I used before, even though the lenses are quite huge. All in all, I cannot really complain at how things are going, if not for the fact that I’m really sleeping too little, between one thing and another; last night (at the time I’m writing) I was up till 5am to fix my radeon’s driver installation (and I just now remembered that I haven’t opened two bugs for it yet!), and the night before I was up till 3am to prepare charts for some Gentoo-related analysis. This is mostly why I start to have a short fuse with people who attack me for the work I’m doing. I’m not expecting all the users to be thankful, and I know a lot will always complain about something, see the whole XMMS crap-spreading, but really it gets old after a while, given I’m not paid to do what I do already. |
|
Gosh, just look at all the buzzwords in the title! As you may have guessed, I'll be talking a bit about the recent developments on the FOSS drivers for RadeonHD cards, specifically for R700 cards. And some other hardware stuff. Radeon Yesterday, October 3, I made some big ol' changes to my workstation. I decided to try out the new video driver stack that all the kids have been talking about. Kernel Mode Setting, git Mesa/xf86-video-ati/libdrm, git kernel 2.6.32_rc1-git3. All that jazz. I wanted to see if the 3D and KMS features were really working on my RadeonHD 4550 or not. I normally run a stable graphics stack, with ~arch Mesa/x86-video-ati/libdrm where necessary to keep up on 2D acceleration and features. This was a big leap for me. So I first consulted some of the X11 team members, remi and nirbheek, who were quite helpful. I installed the latest git-sources kernel, which at the time was 2.6.32_rc1-git3. Mike Pagano has since added -git5. Next, I downloaded the individual -9999 ebuilds for the git master packages from the X11 overlay, stuck 'em in my local overlay, and merged 'em. Only thing left to do was reboot. Lemme tell ya -- KMS in action is awesome. The console output is just beautiful, and there's no more flickering when SLiM and Xfce load. I did notice some minor graphical corruption of the default mouse pointer. However, the corruption isn't present when using any pointer but the default "arrow", and it also isn't seen when hovering inside a Firefox window. I was told this is because Firefox uses its own cursors. Anyway, I reported the bug upstream. Disclaimer: I know glxgears isn't a benchmark. But folks always want to know its results anyway. I tried running glxgears, which gave me a result of over 1300FPS with desktop compositing activated. My window manager is xfwm4, so all compositing is via Xrender, not OpenGL. Disabling compositing resulted in a 500FPS boost to over 1800FPS. What's this mean? Who knows. Probably nothing. Moving on. I took the advice of my fellow developers on IRC and installed quake3-demo. Couldn't run it, though. It blanked the screen, then a message from my LCD firmware appeared, some kind of "input not supported" or "input not detected" error. It slowly repeated the window, drawiing it from center to the top right. I had to Ctrl-Alt-Bksp to get to the console. It also locked up SLiM in the background, pegging one of my CPU cores at 100%. At this point, I rebooted just to test that KMS was still working, then called it a night. Today, I revisited my pointer corruption bug tried the workarounds posted by Alex Deucher. To my surprise, each one worked! Booting with radeon.modeset=0 removes the glitch, though it makes each boot extremely ugly, of course. Specifying EXANoDownloadFromScreen "true" in /etc/X11/xorg.conf also fixes the corrupted pointer, though it may also be slowing down all screen drawing operations by the tiniest bit. The jury's still out on that one; it may just be my imagination. I decided to keep this second fix, as KMS is just too glorious to throw out. I like pretty boots. I also revisited quake3-demo, since I found some pointers on the Phoronix forums that had a workaround, which is to run OpenGL applications prefixed by LIBGL_ALWAYS_INDIRECT=1. To my surprise, this worked nicely. I tested resolution has high as 900-something by 720. My screen is 1440x900, but I haven't felt like pushing it that far, yet. The game is fluid and playable. I need to figure out how to display FPS so I can properly record what I'm seeing. With the success of Q3demo, I remembered that QuakeLive has recently added Linux support. I installed the add-on for Firefox and tried it out. Works nicely, though I'm also running Firefox with LIBGL_ALWAYS_INDIRECT=1 just to be sure. As Alex Deucher and John Bridgman have pointed out on the Phoronix forums, that variable really isn't the safest thing to do, since if something crashes it can take down the whole X server, not just the application. However, it's also the only way I get working 3D games. QuakeLive is pretty playable, though the framerates in a few places aren't smooth -- I can't tell if this is because of my card's capabilities, or the driver stack, or the whole weird idea of playing a 3D first-person shooter inside a web browser. I've also installed the latest Nexuiz, version 2.5.2, in anticipation of future testing. One of these days I'll reinstall UT2004, but I haven't read any succesful reports of that game on R700 cards. There's a lot of testing to do in the future! Overall, I'm thrilled with the new driver hotness for my ATI card. I bought it specifically because I knew the 2D support at the time was excellent, and because there would be so many good things coming down the way for other features, including 3D acceleration. (Yes, just like the latest XKCD strip. I swear, it's like that guy listens to everything I say and watches everything I do. It's really spooky!) Hats off to all the developers for making it happen. Many thanks! SSD After August's fiasco with a defective SSD, I decided to use my refund from the RMA and order a different SSD a few days ago. This time I've settled on a SanDisk enterprise SSD from an HP blade server. Only cost $49, no shipping charges. Brand new. eBay for the win. It packs 16GB of SLC flash, which makes it perfect for mounting /usr/portage and /var on it. This way I can feel free to sync whenever I want, instead of only once a week or more. My system drive uses MLC flash, so I've been trying to ease the write load on it, which means putting the high-write activity on a dedicated disk. The SanDisk SSD "only" has sustained reads/writes at 60MB/sec, but that's plenty for syncing Portage, as the real limiter is not how fast data can be dumped to the disk, but how fast the rsync servers can send it to my box. Same for /var writes -- it's mostly just log files and some tiny temp things, as /var/tmp is already mounted on a RAMdisk. No large files that need >100MB/sec bandwidth. I'm lookin' forward to shovin' it in my box! More hardware Since September 28 was my birthday and all, I've been treating myself to various bits of cheap hardware. Like a replacement AC adapter for my DC PicoPSU. The current AC brick is rated at 102W, which is way more than I need, but the problem is that it spins up its tiny fan at only 50%-75% load. This means that opening up a bunch of tabs, compiling packages, playing Quake, watching large-sized Hulu videos and whatnot turns on the fan right away. And it's the world's most annoying fan. It's loud, whiny, it hisses, and it blows the bad smell of very hot electronics out into the room. Lemme tell you, hot plastic and PSU guts do not smell good. I just ordered a replacement fanless adapter. This thing is high-quality, designed to run very cool. And it's rated at 150W output, meaning it can match my 150W PicoPSU. My max system draw is maybe 60W, but I'll have overhead room in case I ever feel like upgrading a key component somewhere. I also bought a $40 wireless router, an Asus WL-520gU. I already have a WL-500gP v2, which I hacked and flashed with DD-WRT a long time ago. This new router is so that I can hook up my Xbox 360 to the network without having to run 50 feet of cable across the carpet. I chose the 520gU instead of the gC because the gU supports Xlink Kai, which seems prett cool to me, as I don't have a Gold Live account. Yay for tricky internets. Apparently it's pretty common to buy a cheap wireless router and put it into client mode, rather than buying the $100 official USB dongle . . . which doesn't even support WPA2-AES or any decent security. Asus routers are known for excellent open-source support, and I've had nary a complaint about my current one. Yay for Linux on routers! Yay for online gaming! * * * Oh yes, and before I forget, this month's Xfce desktop:
It's October, but my current desktop is so pretty (gallery link) I haven't felt the need to switch for the last couple of weeks. There's another clean version that just shows off the wallpaper in my devspace. |
The big problem with QuakeLive is that the sound is terribly distorted: the voices are greatly drawn-out and slowed down, like playing an old tape recorder at 1/4 speed. There are some solutions on the QL forums, but they're mainly for Ubuntu/Pulseaudio users. I haven't found anything that works for me, yet. The effects and music are okay; it's just the voices that lag horribly.
|
Happy Birthday Gentoo
LINKS:
|
|
I recently had a bit of downtime on my linode. If you are wondering what a 'linode' is, check out my review or the website. And a big thank you to the folks that used my referral code when they got setup with linode themselves, you guys rock! So, about my recent 1/2 day downtime. It was self-inflicted because I wanted to move to a different datacenter. I moved my linode from Newark, NJ to Dallas, TX. It is quite a long story, but it boils down to a problem with my ISP (Comcast). I was only able to pull 100K/s from the Newark datacenter and 2-3M/s from the others. This was unacceptable. I tried to get it escalated past Comcast's frontline support but they kept asking me questions like "Do you use a router? If so, each computer only gets 1/2 the speed" & "Every computer is different. I'm glad that you can get 3M/s from another host, that is really good" Sigh. At least Linode's customer server was helpful and allowed me to work around the ISP. The steps to move a linode are as follows:
So, to finish the story off. Linode++, Comcast--. I wish I didn't need to do something like this, I wish my ISP was...I don't know...smart? |
|
|
I've been busy collecting some really great stories from people using Gentoo in places that I really didn't expect.
Some of them want to remain anonymous, which I have no issue with. But there are some gems like this one:
|
**fixing bugs with both users and devs together. Join us in #gentoo-bugs on Freenode, please! |
|
flame@yamato bzr % bzr branch http://bzr.savannah.nongnu.org/r/man-db http://bzr.savannah.nongnu.org/r/man-db/ is permanently redirected to http+urllib://bzr.savannah.gnu.org/r/man-db/ bzr: ERROR: Not a branch: "http+urllib://bzr.savannah.gnu.org/r/man-db/.bzr/branch/". The command is copy-pasted from Savannah … And yes, this was trying to fix man-db with heirloom-doctools . |
|
I’m not sure if I went to a large extent writing about this before, but I probably should try to write about it here again, because, once again, it helps removing some useless Shared objects are, generally, a good thing because they allow different programs to share the same code in memory; this is why we consider shared libraries better than the static archives. Unfortunately, simply using, boilerplate, a shared object is a bad thing: you need to know what you’re doing. For instance, if your software simply uses a single executable, propose no API for other software to use and you don’t use plugins then you really should not be using libraries at all, and should rather link everything together in the executable. This avoids both the execution overhead of PIC code, and the memory overhead of relocated data .
And again, here are some explanation:
|
|
For those that might have been wondering where was that guy speaking about imminent stabilization of gnome 2.26, well I was taking some time off (sort of). The Gnome 2.26 situation got a bit better in the last weeks as due to the production of a release media, a lot of dependencies we were waiting on are finally getting stabilized. You can still see progress on bug #263083, closer than ever ! Since I can't stand working on Gnome 2.26 anymore and since upstream has been kind enough to drop their new almost shiny 2.28, I started doing some QA on ebuilds in overlay before allowing them to move to the tree. Over 92 ebuilds, all of which are not necessarily interesting for gnome 2.28, I've currently reviewed 25 and that's with current 65% of completeness of the ebuild bumps, so there is still quite some work, and don't expect the overlay to be safe for use just yet. One last word on 2.26, there will be a migration guide, it's still getting a few modifications before it all goes public with stabilization but I'm spreading the word in the hope that we won't see any new bugs concerning what has been documented. |
|
There is one interesting thing that, I’m afraid, most devleopers happen to ignore, either spontaneously, or because they really don’t know about them. One of this is the fact that static libraries and plugins usually don’t mix well. Although I have to warn you, that’s not an absolute and they can easily designed to work fine. The main problem though is to ponder whether it is useful to use static libraries and plugins together, and then it’s to find out if it’s safe to or not. Let’s start from the basis. What are static libraries used for? Mostly for two reasons: performances, and not having to depend on the dynamic version of the same library in the system. If performance of the library is a problem, it’s much more likely that the culprit is the plugins system rather than the dynamic nature of the library; I have said something about it in the past, although I didn’t go much in details and I haven’t had time to continue the discussion yet. For what concerns dependencies, the plugins usually need a way to access the functions provided by the main library; this means there is an ABI dependency between the two; now the plugins might not link against the library directly, to support static libraries usage, but it also means that if the internal ABI changes in any way between versions, you’re screwed. What does this mean? That in most cases when you have plugins, you don’t want to have static libraries around; this means that you also don’t need the More to the point, if you’re building a plugin, you don’t want to build the static version at all, since the plugin will be opened with the Now, you can see where this brings us again: more |
|
Turned out that xorg-server 1.6 is pretty much ready for stabilization, as only a handful of bugs were reported over the testing period since last week, and they only concerned the stabilization list. Without further ado, I've asked our faithful Arch Teams (pretty much all of 'em) to stabilize xorg-server 1.6 and friends. amd64 was the first one to the finish line with a stabilization done in under a day! Gentoo is again back in business for X. Woo! Now to all stable users, don't forget to read the upgrade guides we wrote : Don't forget, please file bugs in bugzilla. |
|
As promised, I released a new version, flagedit-0.0.8. Nothing really exciting in here, flagedit now supports /etc/portage/*.keyword as folders (bug #241668 ) I'll move on and try to implement features suggested in the previous blog entry comments, namely :
|
|
It's been quite a while since I've done anything for Gentoo. It's a new year, and it's a good time to start contributing again. You know how it is : real life versus OSS contributions... Well the real life got the best of me for too long, but although things was very interesting - albeit time consuming - I miss the good old satisfaction of updating the ebuild of my small software that nobody uses :) I'm even more motivated by the fact that I realized recently that I own some piece of software that are actually used by quite a lot of people (more than 2 is a lot for me). Namely : Flagedit the Ultimate Console Based Use Flags Editor. Albeit a bit old, it's still used b quit a lot of people, and it really needs some love from me. So I'm going to start committing stuff again. My motto : start small so you don't stop. So I started by updating the homepage and gave flagedit a new home . Next on list : bug 241668 to support folder structure of portage But hey, you fellow reader : what would you like to see improved in flagedit ? Note : if you want to beta test upcoming versions of flagedit, drop me a mail, or comment. |
|
It's been a long time since my last commit in the gentoo tree ! I had lost motivation and interest. But now I'm back with one simple goal for now : just maintain my ebuilds, don't get involved in any discussion, and take it easy :) So I'm happy to celebrate my comeback with the much awaited ebuild for the new version of booh : 0.9.1. This new version (well actually 0.9.0) brings a lot of new features and programs : album2booh booh-classifier booh-fix-whitebalance booh-gamma-correction webalbum2booh Enjoy! |
|
The server I'm paying for (dedibox) crashed for unknown reason, I had to reinstall it. Luckilly enough I could boot in rescue mode and archive my important data, it helped to get everything up and running again, or at least the important bits (gentoo, apache, this blog, postgresql) The newest addition on this server :
backup-manager is not very powerful, but it's small, light and simple to install and configure. All you need is Perl and gettext :) It'll do until I migrate to bacula. |
|
On our way back from FOSDEM, I had a quick discussion about ssh with Chris, and it motivated me to clean up all my ssh keys, passphrases, agents. So now I use different keys for work and home, and ssh keychain on both. Next move is to add my work identity to my home session to be able to connect directly to servers at work without having to go through my workstation at work. Without putting my home private id on my machine at work, nor copying my home public id on all servers at work. It should be possible I've heard :) Anyway, here is briefly how I did it : ssh-keygen (dsa as main key). Then install keychain (see http://www.gentoo.org/proj/en/keychain/ and con figure it a bit. I added the following script in /etc/profile.d/keychain.sh (gentoo host), and I use the built in keychain on my mac. #!/bin/bash I know, I know, everybody is supposed to know everything about ssh, but I'm happy to admit that I learnt 2 or 3 things while setting up everything properly. Besides, how many of you have no passphrase on your ssh key ? :) |
|
This blog now runs on apache + mod_fastcgi. I can feel the difference, especially given the fact that the hardware is not that powerful. I was curious aboud mod_fcgid, which claims to be better but compatible, but I'm not sure why exactly (I think something to do with better timing in spawning / killing cgi persistents processes). |
|
On Monday 21 September we packed the majority of our belongings into the back of a Penske truck and made the 500 mile drive (in convoy - Louise, William, Dax and myself) from Pittsburgh, PA to Clifton Park, NY. Since then we have been unloading the truck, unpacking our things into our new home and doing all those things you have to do when you move house, and several things necessary when moving between states and jobs. This is certainly the most rural house I have lived in since I was very young. We found a nice duplex on the outskirts of Clifton Park, it uses well water and I am the proud owner of the contents of two full propane tanks (no natural gas lines run out to the house). We also have a really nice wood fire in the living room, and I snagged the family room and am using it as a large home office! Thankfully they were able to hook up a cable Internet connection on Tuesday last week, and so I was not offline for too long. Tomorrow is my first day with Kitware, I will be attending a training course being run by Kitware for the remainder of the week and so won't have my first day in the office until next Monday. I will be working in the scientific visualization group on projects such as ParaView, and have had lots of ideas for future Avogadro development over the last few weeks. I am very much looking forward to working in some new areas, but also to enhancing the previous research and development I have done in the area of visualization in chemistry. I am also looking forward to working on CMake. |
|
Global Financial Derivatives trading company, OSTC Poland, uses Gentoo Linux in significant sectors of its IT infrastructure. We spoke with long time Gentoo user and head of OSTC Poland's IT department, Patryk Rządziński, to learn more about how and where Gentoo is used. We discovered, as you will read in the full interview, that Gentoo, and more generally open source software, serves well in the commercial world. |
|
You might remember my problem with C++ especially on servers; yes that’s a post of almost two years ago. Well today I was able to go one step further, and kill another piece of C++ from at least my main system (it’s going to take a little more for it to apply to the critical systems). And that piece is nothing less than groff. Indeed, last night we were talking in #gentoo-it about FreeBSD’s base system and the fact that, for them similarly to us, their only piece of C++ code in base system is groff; an user pointed out that they were considering switching to something else, so a Google run later I come up with the heirloom project website. The heirloom project contains some tools ported from the OpenSolaris code base, but working fine on Linux and other OSes; indeed, they work quite well in Gentoo, after creating an ebuild for them, removed groff from profiles, and fixed the dependencies of man and zsh. A few notes though:
|
|
Since I have been still fighting with the damned .la files and I’m pretty sure that even though I have explained some use cases most of my colleagues haven’t really applied them, I decided to go with a different approach this time: graphical guides. Since the post about the tree size has gotten so much feedback, probably because the graphs impacted on people, this might actually prove useful.
Note: I first tried to draw the chart with Inkscape, but the connector available on its code only draws straight lines, which are unusable for stuff like this; I found no way to anchor lines to an arbitrary point of objects either, so I gave up; dia is tremendously bad to work with; kivio 2 is not in Portage nor available as binary package for either Windows or OSX; OpenOffice to the rescue, worked almost flawlessly, unfortunately I didn’t want to waste time to define customised colours so you get the bad and boring ones in the image. As you can see from this graph, my idea is that, at the end, every .la file is removed. Of course this is not immediate and depends on a series of factors; this graph shows at least the basic question you got to ask yourself when you have to deal with shared libraries. Please note that this does not apply the same to plugins and for that I’ll post another, different flow chart.
|
|
(For readers on planet.g.o: This one is in German language only, but i do consider this important enough to be published on planet.g.o although.) Wichtig: Ich schreibe hier als Privatperson, nicht als Vorstandsmitglied des Förderverein Gentoo e.V.! Die am vergangenen Freitag stattgefundene Mitgliederversammlung hat sich mehrheitlich dafür ausgesprochen, den Förderverein Gentoo e.V. aufzulösen. Entgegen der Tagesordnung wurde mangels Kandidaten kein neuer Vorstand gewählt, so dass der bisherige Vorstand weiterhin geschäftsführend im Amt bleibt. Alle Mitglieder des Vereins werden in den kommenden Tagen angeschrieben und zu einer außerordentlichen Mitgliederversammlung eingeladen, die voraussichtlich am 07.11. in Bottrop stattfinden wird und in welcher über die Auflösung formal beschlossen werden kann. Vorweg: Auf die Gentoo-Distribution an sich hat dies keinerlei Auswirkungen, Gentoo ist nicht tot und wird weiter bestehen – auch unabhängig von einem Förderverein im deutschsprachigen Raum. Was ist der Förderverein Gentoo e.V.? Der Verein wurde im Herbst 2003 am Rande der Practical Linux in Gießen mit dem Ziel gegründet, die Verbreitung und Präsenz von Gentoo im deutschsprachigen Raum zu fördern und unterstützen. Warum will sich der Verein auflösen? Es konnte aus dem – kleinen – Kreis der bei der Mitgliederversammlung anwesenden Mitglieder kein neuer Vorstand gefunden werden. Die Mehrheit der anwesenden Mitglieder sieht keine Perspektive den Verein weiter sinnvoll zu betreiben. Es ist seit Gründung des Vereins im Jahr 2003 nicht gelungen, eine kritische Maße zu erzeugen, die sich und den Verein gegenseitig pusht und weiterbringt, aktiv am Vereinsleben teilnimmt. Realistisch betrachtet war ich in der vergangenen Zeit ein Einzelkämpfer – zu wenig für einen Verein. Welche Konsequenzen ergeben sich aus der Entscheidung? Die Präsenz von Gentoo auf Messen und Veranstaltungen wird darunter leiden. Auch wenn es um den Verein in der Vergangenheit ruhig war, konnte dieser dennoch über Mitgliedsbeiträge und Zuwendungen die Finanzierung von Flyern und Bannern, Vorfinanzierung von T-Shirts, etc. pp. sicherstellen. Ob sich Privatpersonen finden, die künftig nicht unerhebliche Beträge vorfinanzieren oder für Flyer etc. aufwenden wollen und können, wird sich zeigen müssen. Insgesamt gehe ich davon aus, dass sich die Präsenz auf Veranstaltungen zunächst nicht großartig verändern wird – langfristig mag ich keine Perspektiven abgeben. Was diese Entscheidung für mich persönlich bedeutet, wird sich auch noch zeigen müssen – meiner Motivation sind insbesondere diverse Begleitumstände der Mitgliederversammlung nicht sonderlich zuträglich. Auch fraglich ist zunächst, inwieweit es das Portal gentoo.de künftig noch geben wird, wenn kein Verein zur Finanzierung des Betrieb des Servers bereit steht. Und: Es gibt sicherlich weitere Implikationen einer Vereinsauflösung, die sich erst im Nachhinein zeigen werden. Schade. |
|
Attention Gentoo Community, In honor of Gentoo's 10th birthday, we are producing a new livedvd! We need YOU to test it on as many x86 and x86_64 machines as you can and post bugs. Please report your bugs. Feel free to entertain yourself and fellow Gentoo rock stars on our forum. The livedvd-x86-x86_64 will work on x86 or x86_64. If your arch is x86 boot with the default gentoo. If your arch is amd64 boot with gentoo64. The livedvd-amd64 is for well, amd64 only. UPDATE: Due to demand, we have moved the files onto the regular mirror infrastructure. Please select your archiecture to be redirected to a mirror: x86amd64 So, give us a hand by testing like crazy AND posting bugs and we'll have the greatest livedvd ever. Thanks for your continued support, The Gentoo-Ten Project David Abbott contributed to the draft for this announcement. |
|
|
|
real 2876m48.775s user 2897m44.342s sys 10m28.831sThat's what "time" had to say about my little experiment. Almost 2 days of CPU-time at 2.6Ghz ... and that's with a naughty tweak. I reduced the amount of items because I realized that it was going to take Too Long (tm). So instead of representing each file ... why not represent each directory as one "thing"? filename = filename.replace('files/','')
filename = filename.replace('/var/cvsroot/gentoo-x86/','')
filename = filename.replace('Attic','')
filename = "/".join(filename.split('/')[:-1])
That's all the mods I needed - strip the repo location at the front, fold
files/ and Attic/ away and cut off the filename. Ends up with
"category/package" instead, which for the purposes of Gentoo is a much more
useful identifier. And the rendering time went down from one frame every 30
minutes worst case to about one frame every 3 minutes worst case. Y'know, the
"unmodified" version is still processing after over 118 hours CPU time ... not
that nice :)One positive effect is that it reduces the input from over 200MB to just around 100MB. Now after 48h CPU I have 13367 single PNGs with a total size of pretty exactly 5GB. Feeding those into mencoder generates 557.8 seconds of video with an average bitrate of 1737.2kB. The encoding takes 22 minutes walltime or 40 minutes CPU-time - in other words mencoder uses two threads properly. Good to know! So just to warn you, the result of my little experiment is a high-bitrate 1080p video. It is about 116MB in size ... Get it here (US mirror) Enjoy! |
|
Here we go again. This time, we're going for the double sweepstakes as we're trying to stabilize both libxcb 1.4 and xorg-server 1.6! For once, the server upgrade shouldn't be too hard and the server upgrade guide is remarkably slim. There's been no change in input, nor HAL, nor just about anything else for most users. Only Intel users might have a few surprises with DRI2 and UXA. But at this point, they should be good surprises However, the libxcb upgrade is going to cause more troubles for some users. If you are/were using I would say the libxcb guide is more important than the xorg-server upgrade guide. Anyhow, right now, I calling out for help among our stable users. If you've always wanted to contribute to Gentoo but didn't know how, here's your chance.
Again, don't forget to read both upgrade guides before running the update, just so you don't start panicking when portage is unable to continue the upgrade. As always, you're more than welcome to CC yourself in the stabilization tracker, but please DO NOT COMMENT IN THE TRACKER if you have issues, you'll just annoy everyone there. Just file a new bug and we'll look at it. Don't forget that most X maintainers lurk in #gentoo-desktop on FreeNode if you have any questions. That's all for today |
|
I've just commited PEAR 1.8.1 to the tree (and will do 1.9.0 shortly to get us up to speed), but I wanted to let users know about a change in the way packages are installed. Actually, it only affects the base packages. Up until now, the PEAR-PEAR package in portage included all the necessary deps in one ebuild. With this new version, I've split each package up into its own ebuild. There's a couple of reasons for this, but the most important is that it will give us flexibility to deal with changes from upstream. For example, with 1.8.1 and above, PEAR changed it's base XML dependency to XML_Util. That one was already in the tree, and so the new pear base system relies on that. If the other base ones change between versions, we can focus on that. Another nice little change is that the base system ebuild now is just dev-php/pear. So, "emerge pear" and you're done. The new versions are all currently marked as unstable across the arches. I would appreciate any and all feedback on the change. I'm still a bit skeptical that this is the best approach, and a bit nervous at any fallout that may occur, so please file bug reports and let me know if you have any issues. Thanks, all. |
|
I ran into this today, while working on the USE=modules changes for linux-mod.eclass. As an attempt to solve this, I munged up some GraphViz work to show profile inheritance, pictures as the end. Both sets have the trailing profiles "/desktop", "/developer", "/server" turned off for the 2008.0 and 10.0 releases, to cut down on the noise. Graphs and script for download. My answers as to which profiles:
Odd observations
Thumbnail of one graph
Question for any skilled GraphViz users:If all nodes in a given subgroup/cluster have an edge going to a single destination node, is there any way to get graphviz to replace them with a single fat edge from cluster to destination node? |
To add a new USE flag, that's globally enabled for all Linux profiles, what's the minimum set of profiles that need to change? Deprecated profiles must be handled as well, for users that need to migrate still.
|
So I recently was messing around with Opera 64bit on Gentoo and trying to get Java to work. The process was actually a lot easier than I expected. First I made sure I had the latest sun-jdk installed, which was dev-java/sun-jdk-1.6.0.16 in this case. Now to make it work with Opera I did the following:
Opera doesn’t seem to work by default like this, probably because it ignores the plugin and uses java directly. Because of this, you need to symlink the libjvm.so so Opera can find it:
Set opera to use If anyone knows a more proper way of doing this, be sure to let me know |
|
$ bash -x foobar.sh bash: foobar.sh: No such file or directoryThis is not: ... In program paludis -ip portage: ... When performing install action from command line: ... When adding install target 'portage': ... When parsing user package dep spec 'portage': ... When parsing generic package dep spec 'portage': ... When disambiguating package name 'portage': ... When finding all versions in some arbitrary order from packages matching */portage with filter all matches filtered through supports action install: ... When loading entries for virtuals repository: ... When finding all versions sorted from packages matching sys-kernel/gentoo-sources with filter all matches filtered through supports action install: ... When generating metadata for ID 'sys-kernel/gentoo-sources-2.6.28-r5::gentoo': ... When running an ebuild command on 'sys-kernel/gentoo-sources-2.6.28-r5::gentoo': ... When running ebuild command to generate metadata for 'sys-kernel/gentoo-sources-2.6.28-r5::gentoo': ... When running command 'sandbox /usr/libexec/paludis/ebuild.bash '/usr/portage/sys-kernel/gentoo-sources/gentoo-sources-2.6.28-r5.ebuild' metadata': ... In ebuild pipe command handler for 'LOG0qaglobal scope tr': ... global scope tr paludis@1253390790: [QA e.child.message] (same context) global scope tr paludis@1253390790: [QA e.child.message] (same context) global scope tr paludis@1253390790: [QA e.child.message] (same context) global scope tr paludis@1253390790: [QA e.child.message] (same context) global scope tr paludis@1253390790: [QA e.child.message] (same context) global scope tr paludis@1253390790: [QA e.child.message] (same context) global scope tr paludis@1253390790: [QA e.child.message] (same context) global scope tr paludis@1253390790: [QA e.child.message] (same context) global scope tr paludis@1253390790: [QA e.child.message] (same context) global scope tr paludis@1253390790: [QA e.child.message] (same context) global scope tr paludis@1253390790: [QA e.child.message] (same context) global scope tr paludis@1253390790: [QA e.child.message] (same context) global scope tr paludis@1253390790: [QA e.child.message] In thread ID '19463':That's about 1/35th of the whole output ... which is just drowning out any reasonable information. Complete output is just under 750 lines, so good luck finding any error. But I guess there's a reason for that. Now something really neat: ... In program paludis -ip portage: ... When performing install action from command line: ... When adding install target 'portage': ... When parsing user package dep spec 'portage': ... When parsing generic package dep spec 'portage': ... When disambiguating package name 'portage': ... Package name 'portage' is ambiguous, assuming you meant 'sys-apps/portage' (candidates were 'sys-apps/portage', 'virtual/portage')Let me say this as clearly as possible. Never assume. If you try to guess what I might have meant to say you may do something I explicitly do not want to happen or even something which breaks things. If your app is unable to unambiguously parse my input quit. Failure to do so will reduce in lots of tears and you falling on sharp objects. Multiple times. And of course ... Fetch error: * In program paludis -ip portage: * When performing install action from command line: * When executing install task: * When performing pretend actions: * When fetching 'dev-db/sqlite-3.6.18:3::gentoo': * Fetch error: Fetch of 'dev-db/sqlite-3.6.18:3::gentoo' failedI don't think that means what you think it does. A pretend action that doesn't only pretend, but claims to fetch things? That better be a small oopsie in the explanation that doesn't, in any way, describe what actually happens. Now, Ciaran. You can try to ridicule me through your blog. You can relabel comments as my name if you don't like them (it's your blog after all - even though that's exquisitely rude) and then deny you did it (we call that lying). But if you have to do so do it directly. Don't try to be funny (you saw what that did in the Funtoo-uses-Internet-Explorer Situation). Don't label any criticism as FUD (see "Ten Ways PMS Raped your Baby"). And if you fork PMS then do so. You have your own hosting already. Now all you need is your own mailinglist and please leave those that work on the official version alone. And don't command us around, we're not your slaves. Think you can do that? That would be awesome. Thanks! |
|
From bash Changelog: *bash-3.0-r12 (05 Jul 2005) *bash-3.1 (10 Dec 2005) *bash-3.2 (12 Oct 2006) *bash-4.0 (21 Feb 2009)So anyone not having bash 3.2 hasn't updated since May 2007. Seriously. That's when bash-3.2_p17 went stable. (October was just when the ebuild was added, the Changelogs are a bit tricky to parse) So for all intensive purposes (and of course all intents and purposes) we can assume bash 3.2 installed anyway. Plus there's no older ebuild anyway, apart from the 3.1_p17 that is a leftover from a horrible upgrade path. Even worse, for at least a year there has been a "contamination" of the tree in the form of bash 3.2 features like the "+=" assignment. Which means that some ebuilds won't work with 3.0 anyway. Extra bonus? Many eclasses use it, which means, in short, that you need 3.2 or higher. And it has been tolerated (maybe even encouraged) for such a long time that there's no way to undo that change now. The obvious thing to do (fix PMS) has been ignored for quite some time. So I thought I'd send an email to the gentoo-pms mailinglist to get it sorted out. Guess what? The amazing one-character patch was denied. That's the best way to make PMS irrelevant - refuse to let it document reality. |
|
If you would prefer to read the interview;
LINKS: |
|
Searched high and low to find this silly little info. Finally found it here. Now my only wishlist is to do something similar for var.logdir, but %[1-4] is only set up with evhost. So, do you do anything smarter than this for your server? |
|
Earlier this month, I found myself embarking on a last-minute journey to a One Laptop per Child workshop in Port Harcourt, Nigeria. They are preparing for a 6000 XO laptop deployment in that region of the country. I attended to support the 5-day event, which was coordinated by Michael Tempel and Claudia Urrea. The laptops were donated by Rusal/Alscom, and the deployment will be primarily run by Schlumberger’s Excellence in Educational Development division. SEED already uses its local staff to run some education projects in Nigeria (and many other countries).  We covered a range of activities including Write, Record and Paint, then spent a decent amount of time on TurtleArt and Scratch. We also handed out 75 sensors and ran some activities around the measurement of humidity, temperature and light.  The group consisted of about 80 teachers and 20 children. Both the size of the group and the wide age range presented some challenges. Usually, such workshops would be run only with the core teams behind the deployments (a smaller group overall), but the way that things are developing in Nigeria meant that it made more sense for us to work with a larger group at this time. One of the biggest stumbling blocks of the workshop was working with the Scratch activity – while a very valuable activity, its integration with the Sugar desktop environment is damagingly minimal. For example, instead of using Sugar’s simplistic “Journal” storage system, it presents regular-looking Load and Save dialogs which proved very challenging for the new users. Seeing people struggle with interfaces that we see all over the desktop computing world really reminds you just how ground-breaking and significant the simplicity of Sugar is. We also ran into some problems with the Paint activity regularly freezing the systems, unreliable saving/loading with USB disks, and some confusion relating to Measure’s sensors interface. We were kept on our feet at all times, meaning that I didn’t really have time to sit down and diagnose the issues in detail, but they should not be hard to reproduce at a later date. The issues were not significant enough to cause any major disruption.  I ran a few technical sessions with a few people who will become the basis of the technical team, plus some interested volunteers and teachers. As I’ve seen in other places, this was challenging because prior experience with Linux is low and internet access is scarce, so “look up this topic on the OLPC wiki” is not an answer that everyone is able to work with, and “run this command at the terminal” requires a decent amount of explanation. Nevertheless, the enthusiasm is overwhelming (as always) and I went away feeling confident that the core team is now comfortably in a position to get things moving and pass on knowledge to a wider group. Our hours were cut short by the high security around us, meaning that we didn’t have much non-workshop time to interact with the attendees (or really see the country at all), but overall it was a lovely group to work with and I’m confident that we’re going to see great things come out of their efforts. I’m now back in Nepal until November. |
|
I figured I’d blog this so I wouldn’t stop forgetting how to do this and possibly learn a “better” way to do this. I’m going to assume that vanilla x11 forwarding works outside the chroot as a starting point. The process is relatively simple that I use. First I ssh into my server as a user using the -Y option like so:
Then I su to root:
Now comes the part that makes the forwarding work. We need to export the magic cookie that our current session is using so that the chroot can import it and use it. We do this like so:
This saves the magic cookie info into a file under /tmp so that we may access it later. Now its time to chroot in:
and I generally like to set my PS1 to remind me that it’s a chroot but is not necessary:
Now we need to import the magic cookie after chrooting in:
At this point x11 forwarding should now be working in the chroot. An easy way to test is to simply launch an xterm inside the chroot.
If the xterm appears everything is in working condition. At this point you should probably delete the |
|
*** glibc detected *** /usr/lib/jvm/sun-jdk-1.6/bin/java: free():
invalid pointer: 0x00000000420eef40 ***
======= Backtrace: =========
/lib/libc.so.6[0x3002271e46]
/opt/sun-jdk-1.6.0.16/jre/lib/amd64/libdcpr.so[0x7f8c503d2b52]
/opt/sun-jdk-1.6.0.16/jre/lib/amd64/libdcpr.so[0x7f8c503dbe05]
/opt/sun-jdk-1.6.0.16/jre/lib/amd64/libdcpr.so(Java_sun_dc_pr_PathFiller_reset+
0x43)[0x7f8c503d51c3]
[0x7f8cf52a4f50]
======= Memory map: ========
40000000-40009000 r-xp 00000000 09:00 85671701 /opt/sun-jdk-1.6.0.16/bin/java
40108000-4010b000 rwxp 00008000 09:00 85671701 /opt/sun-jdk-1.6.0.16/bin/java
41716000-42288000 rwxp 00000000 00:00 0 [heap]
So I think "well, sun-jdk is teh shizzle, I'll try ... err ... no, that one is
fetch restricted. So is this one. Err, yeah, icedtea-bin!Guess what. Same result. Not good. Now I'm thinking "A crash _in the Java core_? No wai!". /opt/sun-jdk-1.6.0.16/jre/lib/amd64/libzip.so( Java_java_util_zip_Deflater_deflateBytes+0x305)[0x7fe671a33e95] [0x7fe66eb3d4a2]What, a crash in libzip? That smells bad. Random code execution bad. I find that very unlikely! How on earth does this happen? Now, let's go bleeding edge and try to build icedtea from source. That only takes ... sigh. About one hour on a quadcore. Grumble grumble yell moan grumble. And? Can you guess it? Implodes the same way. This is getting really interesting! Hmm. Looks like all the code this app uses is pure Java. Hmm, this makes no sense. But ... wait ... what's that? "core.jar" - guessing from imports this is the Processing library. That looks like a candidate. Let's have a look at the homepage ... yes, this seems to be C++ code with a Java interface. Ok, this could mess with things. But how? Just injecting the .jar with the newest version doesn't change a thing. Crummy. And I do notice that their LINUX tarball has files with the .dll ending. File says: PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bitUhm. Yah. No good. But I can try to build it from source, yes? Yes. These nice people have a svn repository I can pull from. And as a Gentoo user I'm used to playing with such things. If you have a weak stomach you should stop reading now! Now, svn checkout. unzip, make, c++, I have all of those (Gentoo sei Dank!). Let's have a look at the build syste... the build... what the ... Ok, there's a build/ directory with linux/ and windows/ and other directories. And in those directories are, uhm, scripts. And the eclipse editor preferences? What the ... but I digress. Scripts. There's one called "make.sh". Good! Let's have a look. #!/bin/shOk, so they aren't using any bash features I hope! ARCH=`uname -m`
if [ $ARCH = "i686" ]
then
echo Extracting JRE...
tar --extract --file=jre.tgz --ungzip --directory=work
else
# echo This is not my beautiful house.
# if [ $ARCH = "x86_64" ]
# then
# echo You gots the 64.
# fi
Wat. SRSLY. I lack words to describe this. So the whole 64bit part is commented
out. Why do I think that that's not a good idea? And what is "Extracting
JRE..." supposed to mean? Noone sane would ... but ... omg. MAH BRAINZ. There's
a FULL JRE in the svn checkout.
echo "
The Java bundle that is included with Processing supports only i686 by default.
To build the code, you will need to install the Java 1.5.0_15 JDK (not a JRE,
and not any other version), and create a symlink to the directory where it is
installed. Create the symlink in the \"work\" directory, and named it \"java\":
ln -s /path/to/jdk1.5.0_15 `pwd`/work/java"
exit
Some things are not meant to be seen. Like this message, which throws up many
questions (and the rest of my lunch). At this point my motivation approached
zero (or rather, my motivation to do useful things. I had a strong motivation
to hurt some people).And I try to run that crashy code in my i686 chroot. Guess what. Yes! Now I do wonder. Who is to blame here? The clueless upstream that doesn't even know how to cut a release without including their editor config? The Java runtime that loads any crap without doing sanity checks? (Seriously ... how can you load a 32bit .so or even a .dll into your adress space without immediately exploding?) Or me, who still thinks there are Java apps out there that don't make you go insane? So, after a few hours of tracking it down I'm again reminded why I usually don't touch Java at all. The amount of stupid I've found today is enough to last a small african country for a year ... Oh, one small final note. I can't really blame people for not knowing platform-specific things. But there's a fine line between being a bit ignorant and being purposefully incompetent. If you don't know how to package for a platform find someone who does. Ask on IRC, or if you don't like that on mailinglists. But please, don't release broken stuff like that. It's very rude and can be devastating for the mental state of people that might use your software! |
|
I just ran into “No space left on device” from Portage again. In such a situation previously I ran # df -H just to find that there was space left on all mounted devices! Confused I deleted a few distfiles through # rm -vf /usr/portage/distfiles/* and found Portage to work again magically. This time I remembered a chat with rbu: Inodes can run out, too. Checking the number of free inodes I was in trouble indeed: # df -i -H Filesystem Inodes IUsed IFree IUse% Mounted on .. /dev/sda7 1.3M 1.3M 1 100% /var .. That’s all I wanted to share. (PS: With /var on a different partition now deleting distfiles no longer helps…) |
|
FEATURES="buildpkg" NOCOLOR="true" PORT_LOGDIR="/var/log/portage" PORTAGE_ELOG_SYSTEM="save" PORTAGE_ELOG_CLASSES="info warn error log qa" USE="X gcj objc" VIDEO_CARDS="vga" Why would I do that? Well, first of all buildpkg. That saves a binpkg of everything built, which saves quite a bit of time. The whole logging thing is very convenient if you build things with a script like this: for i in `pquery --max -a 'x11-drivers/*'`; do emerge $i; doneWhy would I do such a thing? Well, maybe someone asks me if all x11-drivers work with the new mesa or xorg-server. And like this I just kick it off and grep the logfiles later. Obvious, eh? Lastly the useflags are optimized to make the toolchain capable of building exotic stuff like gnustep or java packages out of the box. Otherwise you'd soon be rebuilding gcc, which takes time and effort ... so let's add it as early as possible. And VIDEO_CARDS to make xorg "thinner" - less drivers installed, and we don't actually use the drivers anyway! Now if I want to test a package I usually use: FEATURES="test" emerge -1avk somepackagewhich has the advantage that it uses binpkgs if available (k), shows me what will happen and (a)sks. And -1 / --oneshot so it doesn't end up in world file, so I can get rid of everything with a simple emerge --depclean. Since there are so many packages where tests fail I often short-circuit and use --onlydeps to get everything installed without having to run and fail tests and only run the tests of the package I actually want to test. As you can see that's quite streamlined to get as many things compiled with as little effort as possible. To work on things I usually group one console tab in the shared PORTDIR (which in my case is a cvs checkout) with one console tab in the chroot. That way I can easily toggle between ebuild editing and compiling. Usually I only have two such tab groups open because otherwise I tend to forget things. Whenever possible I try to avoid doing two things at once in one chroot because that can cause some headaches, it is easier for me to use a different chroot for it. And setting up a new one is quite easy :) A short while ago I deleted ~12000 binary packages because I was getting a few inconsistencies - the gcc 4.3 to 4.4 migration cost me quite a lot in terms of build time. But now I've mostly caught up, the common packages exist as binaries for fast install and everything else would need to be compiled anyway. So much for the "how to compile things" part. Next week on BBC: How to make an omelette without eggs! |
|
Somehow I got convinced to give a tutorial at LinuxCon this year, and it was originally scheduled to be my normal "Write a Real, Working, Linux Driver" tutorial I've been giving for the past 4 years or so (which happens to be online here, if you are bored and need something to fall asleep to.) But that's old-hat, as people on 4 major continents have seen it before. So, to try to break up the boredom, I'm please to announce a change: Write and Submit Your First Kernel PatchThis tutorial will cover the steps necessary to properly compose, describe, and submit a Linux kernel patch. It will cover the basic usage of git, and how that works with the Linux kernel development cycle. As part of the tutorial, every attendee will compose and submit a patch to the Linux kernel that will be included in the main kernel tree. Every attendee should have a solid grasp of the C language, and know how to build and install, a Linux kernel from scratch (if not, reading the book, Linux Kernel in a Nutshell, free online, ahead of time would be a very good idea.) The latest source tree, from the git repository, of the Linux kernel should be installed on every attendees laptop before they arrive. Sign up on the tutorial web site if you are going to attend so I get a clue how many people to expect. Right now I have unique material for 100 people to write new patches for, but can come up with more if needed. See you all at LinuxCon, should be a fun time. I'm also giving a few other talks there as well, so come and heckle. |
|
In 2006 Jo Vermeulen compared Bazaar and Git performance-wise. Up to today Bazaar has a bad reputation regarding speed and from the results of Jo you see at least that Git is incredibly fast, Bazaar is usable but a bit slow on the uptake in some scenarios. Jo strictly did not use any remote operations which are hard to compare, but from some own tests I do know that Git is incredibly fast there, too, while Bazaar can be really slow on the initial clone operations. The latter fact may be history now, as the new 2a repository format has been introduced with Bazaar 1.17 and enabled by default in 2.0 (both are in Portage). It gives improved speed and flexibility while using up a bit more disk space than the old formats. Back to what we are really looking at: The scenario. Operations chosen by Jo were:
The results were clearly in favour of Git, especially the empty diff was quite awkard for Bazaar. The same operations were done by Jordan Mantha in 2008, also including Mercurial in a follow-up. A clever idea by Jordan was to provide time ratios, as test environments and settings were a bit different (other kernel version, different computer system). He concluded that Bazaar got faster, so did Git, but in the end Bazaar gained more ground. So now is the time to repeat the tests with current versions of both SCM systems, the following table only has the ratios of the other two guys. You will note that Git is mostly faster than Bazaar (apart from the add operation), but the absolute time of Bazaar is more than sufficient (got faster since 2006 and 2008) and outweighed by its better user interface in my eyes. Ranked by used space Git (471MB) wins, followed by Bazaar (482MB) and Mercurial (554MB); the numbers are for the whole tree including working tree. The used versions are given in the table, all times in seconds. For the sake of completeness, Mercurial is also listed in the table and compared to the ratios Jordan reached. Edit: I corrected the repository sizes because Git's gc command gives a good improvement in repository size. Additionally I should add that no custom options were used, just the straight commands.
|
|
Maybe I’m the last to stumble upon this… anyway: Nabble is monitoring gentoo-dev offering a search and browse interface and two feeds for it: “new message” and “new threads”. I was thinking the “new threads” one could be a great tool to Gentoo users that are not interested in every single mail (I currently am) but still would like to keep on track of the big picture of gentoo-dev. I would have needed just that for the Google Summer of Code mailing list. |
Views expressed in the content shown above do not necessarily represent the views of Gentoo Linux or the Gentoo Foundation.