July 21, 2008

New blog
Sometimes happens
I suddenly felt that a dedicated server or a VPS was too much for my uses (and way too expensive) that's why I decided to switch over google's services.
I moved the old blog to blogger.com and I managed to import all my previous posts.
Note: for those of you who are reading planet.fedoraproject.org, it seems that planetplanet is replaying all my old posts, I'm sorry for this unexpected issue but my posts labeled as 'Fedora' were only two or three.
I am psyched!
Well, I started physical therapy last Friday. Over the weekend, I kicked my own ass doing all of the exercises that the therapist had me doing. Today, I went back for my second appointment, and something that had caused me significant pain on Friday - stretching my arm out to my side as far as I could - was almost effortless.

She then had me extend my arm out in front of me as far as I could, and I was able to fully extend my arm, something that she said no one had ever been able to do their first time! Again, this was without much effort or pain. Followed by some pully exercises, and I could definitely feel it stretching, but not to the point of pain.

All in all a great day, and I can't wait to see my doctor next week to get some of the activity restrictions lifted hopefully. Sometimes it's the little victories in life that make you feel the best :)
Transifex 0.3 released

Yeehaa! I’m quite happy to say we Transifex v0.3 yesterday. For the folks that haven’t heard about this (fantastic) project, here’s a snippet from its homepage:

Transifex is a highly scalable localization platform with a focus on integrating well with the existing workflow of both translators and developers. It aims in making it dead-simple for content providers to receive quality translations from big translation communities, no matter where the project is hosted.

Transifex 0.3 is a major release, including a lot of under-the-hood changes. We’ve added full i18n support, and now in addition to the templates, per-module information stored in the database, such as names and descriptions, can be translated as well. As soon as possible we’ll switch to eating our own dogfood, and translations to Transifex will be served from Transifex. The biggest change in 0.3 is probably the change of the libraries used for our models, views and widgets. Now these componenets should be easier to develop on top of, and more ready for switching to TurboGears 2 when it stabilizes. To increase the quality of our code and releases, we’ve added unit test cases for most of the views and models, and more will come in 3.0.1.

Here are the major changes, taken straight from the NEWS file.

Transifex version 0.3 “Get smart”

Released: 2008-07-20

  • New Features:
    • Full i18n support in both templates and database (Diego Búrigo Zacarão)
    • Support for editing repositories (Diego Búrigo Zacarão)
    • Switched model library from SQLObject to SQLAlchemy (Asgeir Frimannsson)
    • Switched templating language from Kid to Genshi (Diego Búrigo Zacarão)
    • Switched widget library to ToscaWidgets (Diego Búrigo Zacarão)
    • Code quality control, unit testing (Dimitris Glezos, Diego Búrigo Zacarão)
    • Development moved to transifex.org, references updated (Dimitris Glezos)
  • Translations:
    • German (Fabian Affolter)
    • Italian (Silvio Pierro, Francesco Tombolini)
    • Malay (Sharuzzaman Ahmat Raslan)
    • Hungarian (Sulyok Péter)
    • Brazilian Portuguese (Diego Búrigo Zararão)
  • Bugfixes:
    • Better support for multiple pages in tables (Dimitris Glezos)
    • Fixed GIT support for non-master branches (FH #17) (Christos Trochalakis)
    • Hide links to admin pages from homepage for non-admins (Dimitris Glezos)
    • Form validation in submit form (FH #51) (Diego Búrigo Zacarão)
    • Cleaner commit msg for decentralized VCS (Tx #3) (Dimitris Glezos)
    • Fixed redirect after submission to correct branch (Diego Búrigo Zacarão)

Tarballs are available at http://transifex.org/wiki/Download.

Thanks to all those who made this possible.

Right. On to merge the next set of features now.

The sunshine makes everything so dark...
Study: OSS Communities Are Often Slackers in Security

As usual, when you read these type of articles in reverse everything is so much clearer. So let's start from the end:
  • One paragraph before last, they bother mentioning the research company also provides "audited versions of several open source packages" and link to their friendly Open Review Project. OK, so it's not about security, or rather it's about their financial security...
  • Somewhere in the middle of the text, it becomes clear they only talk about open source Java and for the study they examined some 11 projects -- that's no doubt a typical representation of the FOSS community projects.
  • Also great quotes:
  • ..."One is the absence of any procedures for reporting bugs or security flaws."
    • Can you show me a decent FOSS project without a bugzilla?
    • Can you point to the URL for public reporting of bugs in proprietary products?
  • After reading through the text I found they try to compare "community" FOSS with "commercial" FOSS. They don't even mention proprietary.
  • Oh, we finally got to the title... yes, it was the communities they were bashing all along, not FOSS per-se. They actually claim to help FOSS by selling audited versions of the untrusted community editions. Just like our MS friendlies that simply love FOSS as long as it's on their terms.
So what can be said about this crap:
  • If these Fortify Software chaps really have a business plan around FOSS than a good advice would be -- if you want to drink from this well, don't piss in it...
  • And lets be clear about it -- I'm all for full disclosure of security flaws (FOSS or otherwise), but this article didn't disclose anything except paragraphs upon paragraphs of FUD.
Pretty obvious from the title, don't you think?
Foundation of the OLPC SIG
Yeah! Here we go...

Greg DeKoenigsberg has just announced the Fedora OLPC SIG - just to say it in one word: brilliant!

The whole OLPC project is doing a great job, including the work concerning the sugar desktop environment, which is also available in Fedora. I'm looking forward to further work of the OLPC SIG and hope that we'll be for example able to produce for example a sugar based spin.

So, I hope to see you soon either on #fedora-olpc or on the fedora-olpc-list!
Getting the ZYpp Stack in Fedora

In my spare time, when I’m not working on my GSoC project, I still update source rpms for the ZYpp package management stack.

It seems that with the latest releases of sat-solver, libzypp and zypper, the whole stack has become more stable on Fedora, especially, in the past few weeks I wasn’t able to update packages due to various resolver’s problems, but now it seems that "zypper up" does its job smoothly.

Having the ZYpp stack on Fedora would be a great step toward integration. The OpenSuSE folk is doing a great job on ZYpp to better support our repomd format and they’re providing the yum stack working out-of-the-box as well!

So, why don’t do the same thing on Fedora?

If you are interested, you will find the review requests on bugzilla, bug IDs are: 442714 (sat-solver), 447738 (libzypp) and 442714

Stay tuned ;-)

Zypp stack in Fedora? (Hint: Interoperability)

During the last two days I’ve been busy with school (obviously) and since I felt too much absent-minded to do something useful for my GSoC project, I decided to package the whole zypp stack and send it for review by filling a request at redhat bugzilla (here you can find the packages by searching for sat-solver, libzypp and zypper).

But why bother with the zypp stack? Simple: Interoperability. As reported by Duncan, (I suggest you to read the whole article here, mine is just an abstract) openSUSE and ZYpp developers are working hard to get a fully working backend for repomd which is standard-compliant. In addiction to that even openSUSE now provides updates and patches informations using an updateinfo.xml file and they will provide deltarpms using the same format used by yum-presto, this means that the yum stack can be used on openSUSE without hassles. But they went even further! Thanks to these changes in openSUSE infrastructure update metadata can be generated using tools already available in Fedora (Bodhi) or generate deltarpms using yum-presto toolchain. In the future Duncan and ZYpp developers will extend the parser to understand our comps.xml file and make metadata available as ‘patterns’.

Thanks to these efforts spent on interoperability a potential user will be finally able to migrate smoothly from openSUSE to Fedora or from Fedora to openSUSE because he will have the tools he’s used to out of the box!

Why I do bother with ZYpp if I’m a Fedora user? Because I see some (mainly practical) benefits: one of them is speed of “simple installation” tasks. I often have to install a couple of -devel packages and considering that yum 3.2.16 (with standard repo files + livna + fedora 8 repo files [and that's for xorg 1.3 and nvidia binary drivers], a couple of excludes and includepkg) still takes about one minute to compute metadata (compute, not refresh metadata, redownloading it nor downloading and installing packages) on my ageing Pentium 4 system equipped with 1Gb of DDR400 RAM while zypper computes the same metadata in about 2 seconds. My system is slow enough that I prefer to not waste my time, if possible.

Honestly, I see that yum has greatly improved over time (kudos to the developers) but I can’t agree with James Antill’s post (I invite you to read the whole article), whose answer to a comment left me with the sensation of being fooled:

Well I tried to make sure I mentioned it in the article, and I did link to the performance tests on different yum versions, but yes we know that older versions did cross the threshold from “fast enough” to “not fast enough” for various reasons. However current YUM code (I’m using 3.2.16 in Fedora 9) does “simple queries” in less than 2 seconds and “simple installs” in about 6 seconds (but note that you’ll often need pacakges to be downloaded, and even if not RPM will need to install the packages — which will add significantly to this) on the other end a full Fedora 8 to Fedora 9 update takes less than a minute within YUM (40ish seconds, IIRC)

I’m glad that on his computers yum runs smoothly but, I repeat, on my low-end machine it takes about one minute (47 seconds to be precise) just to compute dependencies.

Please note that I’m not running down yum and yum developers, I’m perfectly aware that yum has more features than zypper and that zypper still has problems managing Fedora’ updates and that’s why I still use yum to keep my systems up-to-date and I use zypper to install some last-minute packages.

I think we should keep the best of both solutions. In one word: kudos to Yum and ZYpp developers, you’re doing a great job toward optimization, integration and interoperation.

Automating Sieve mail filter rule creation

For those of you who use Sieve to control their mail filtering, you probably know the web interface to create rules is a huge pain to use. Here's a quick little script I wrote to automate setup of rules based on list ID's of mailing lists I'm subscribed to.

List each list-id, one per line, in a text file like this:


acme-list.example.org
foo-list.example.org

and run the following


python makesieve.py < sievedata.txt > sieverules.txt

Here's the source: makesieve.py

After some pruning and unsubscriptions, I'm only a member of 36 lists that I know about. Not too bad.

Help test recent xulrunner updates.

Recently there were problems with a new version of xulrunner being sent as an update to Fedora 9. Several packages that are built against xulrunner were not rebuilt to the new version and submitted to the repositories before xulrunner was. This issue would cause a dependency issue resolving error that might look like this:

Loaded plugins: fastestmirror, refresh-packagekit
Loading mirror speeds from cached hostfile
 * livna: mirrors.tummy.com
 * fedora: mirror.anl.gov
 * updates: mirror.anl.gov
Setting up Update Process
Resolving Dependencies
--> Running transaction check
--> Processing Dependency: gecko-libs = 1.9 for package: Miro
--> Processing Dependency: gecko-libs = 1.9 for package: gnome-python2-gtkmozembed
---> Package pilot-link.i386 2:0.12.3-14.fc9 set to be updated
---> Package rsync.i386 0:3.0.3-0.fc9 set to be updated
---> Package totem-mozplugin.i386 0:2.23.2-5.fc9 set to be updated
---> Package xulrunner.i386 0:1.9.0.1-1.fc9 set to be updated
---> Package system-config-language.noarch 0:1.3.1-2.fc9 set to be updated
---> Package selinux-policy.noarch 0:3.3.1-78.fc9 set to be updated
---> Package nfs-utils-lib.i386 0:1.1.1-5.fc9 set to be updated
---> Package xen-libs.i386 0:3.2.0-14.fc9 set to be updated
---> Package binutils.i386 0:2.18.50.0.6-4.fc9 set to be updated
---> Package totem-gstreamer.i386 0:2.23.2-5.fc9 set to be updated
---> Package qemu-img.i386 0:0.9.1-6.fc9 set to be updated
---> Package selinux-policy-targeted.noarch 0:3.3.1-78.fc9 set to be updated
---> Package libvirt.i386 0:0.4.4-2.fc9 set to be updated
---> Package qemu.i386 0:0.9.1-6.fc9 set to be updated
---> Package cpio.i386 0:2.9-8.fc9 set to be updated
---> Package yelp.i386 0:2.22.1-4.fc9 set to be updated
---> Package nspluginwrapper.i386 0:1.1.0-3.fc9 set to be updated
---> Package libvirt-python.i386 0:0.4.4-2.fc9 set to be updated
---> Package device-mapper-multipath.i386 0:0.4.7-16.fc9 set to be updated
---> Package firefox.i386 0:3.0.1-1.fc9 set to be updated
---> Package dmraid.i386 0:1.0.0.rc14-8.fc9 set to be updated
---> Package totem.i386 0:2.23.2-5.fc9 set to be updated
---> Package kpartx.i386 0:0.4.7-16.fc9 set to be updated
--> Finished Dependency Resolution
gnome-python2-gtkmozembed-2.19.1-16.fc9.i386 from installed has depsolving problems
  --> Missing Dependency: gecko-libs = 1.9 is needed by package gnome-python2-gtkmozembed-2.19.1-16.fc9.i386 (installed)
Miro-1.2.4-1.fc9.i386 from installed has depsolving problems
  --> Missing Dependency: gecko-libs = 1.9 is needed by package Miro-1.2.4-1.fc9.i386 (installed)
Error: Missing Dependency: gecko-libs = 1.9 is needed by package gnome-python2-gtkmozembed-2.19.1-16.fc9.i386 (installed)
Error: Missing Dependency: gecko-libs = 1.9 is needed by package Miro-1.2.4-1.fc9.i386 (installed)

There is an update in Bodhi to correct this dependency issue. However, this update needs people to download, install, and test it. Then report on Bodhi what the results were. Usually either that it worked great or that there was issues.

Here are the steps to do the test and report to Bodhi the results:

  1. Run
    yum update
  2. From the output determine what packages are missing for you, you are looking for dependencies that could not be resolved. For this issue they should all be related to Miro and gnome-python2
  3. In a web browser go to the Bodhi page for this update: https://admin.fedoraproject.org/updates/F9/pending/Miro-1.2.4-2.fc9,gnome-python2-extras-2.19.1-17.fc9
  4. Towards the top of the page you will see a section called Builds:. Open a new browser tab/window for each build listed. This will take you to the test build for each package in Koji.
  5. On the Koji page, look for the section called RPMs. Look for each package of the right architecture that you need.
  6. Create a temporary directory to download each of these files to. In my case I created a directory called testingUpdates:
    [jfenner@localhost Download]$ mkdir testingUpdates
    [jfenner@localhost Download]$ cd testingUpdates/
  7. Download all of the RPMs that you need from Koji into the temporary directory. I used wget to do this because I think it’s the easiest way. However, use whatever method works best for you.
  8. Once you’ve done that, then localinstall all of the packages in the temporary directory.
    [jfenner@localhost testingUpdates]$ sudo yum --nogpgcheck localinstall *
  9. Note: You have to turn off the gpg signing check above, because at this stage the packages have not been signed yet. This will happen once they’ve been pushed to stable.
  10. Assuming that you were able to install all packages with no errors, now run a normal yum update. This should also run with no more dependency errors.
    [jfenner@localhost testingUpdates]$ yum update
  11. Excellent! Now do a test run of Firefox and Miro, if you have them installed and make sure that they appear to be working right.
  12. Now you have concluded testing this pending update. The last step is to submit your findings to Bodhi to help get this update sent to the world. Go back to this update’s page on Bodhi. At the bottom of the page, enter your name and click on the appropriate radio button for your findings. If everything worked fine click on Works for Me. Enter a brief comment if you’d like. Fill out the captcha and click Add comment.

That’s all there is to it. You just helped improve QA for the Fedora community. The test you conducted and feedback you provided will help this update go out to all the Fedora repositories fast and of higher quality. I encourage you to check back often at Bodhi and test other packages that appy to your system and provide your feedback. The more of the community that does this, the higher the quality of the updates we receive will be.

Nodoka GTK Engine - towards next big release
Well, I've got some time and ideas how to improve the nodoka gtk2 engine and started working on the new branch (0.8.x), though only in inkscape and in wiki so far... It's a little sad that I have to wait a little more to do more work since in Thursday I've got exams from Classical Electrodynamic (though Special Solutions to Maxwell Equations would be more fitting because most of the time we did electrostatics and magnetics :-D) and after that I'll go on a short vacation. If I wasn't a lazy bum I would have done it a month ago already... Anyway, back to the topic. What's big on the next release?

The next branch of nodoka will recive something what you might call face-lift. I started redesigning the gradients, though in a evolution-like way. Also I made designs for previously 'unthemed' things, like arrows, radio/check buttons, etc. The goal of this release is to complete consistent and complete engine+set of themes that will be natural evolvement of the previous releases and at the some making itself distinguishable from other big players like Clearlooks, Murrine or Aurora. Another goal is to make the engine highly customizable, while maintaining the over speed - we like both speed and configurability, after all :-)

As I've already created a bunch of designs, I think the vacation might come handy - after then I'll check your reactions, suggestions, comments, ... and see which way I'll eventually take. So if you have some ideas, comments, suggestions, ... feel free to either add a comment here or drop a mail at the fedora-art-list.

In my initial mail to the art list I mentioned Fedora 10 release, but when I started designing I came with a lot of ideas and it seems more realistic to make it in time for Fedora 11. The reasons are obvious - it'll take some time to finish the art designs, given the current state of things the code, mostly the drawing functions, will need a major rewrite and extensions and I'll need to think how to make the code effective. It'll take a long time before I'll be able to build something consistent enough to push it even to rawhide, and I don't wan't to start testing just weeks before final release.

So, as the things are now, I think the most possible scenario is early branching of nodoka for F-10 which will make the new packages appear in Rawhide just after the release. Then we'll have the full release cycle to fine-tune the design, perhaps make a Qt4 port, and sort out most bugs.

And now some teasers:




More stuff can be found on the wiki page I created as a "container" for all 0.8.x branch related info.

And the future? Well, now I have a feeling like the 0.8.x branch could be the last pre-1 release. And what would be in the 1.0.0? Perhaps finally support for RGBA, more widgets animation (optional), perhaps some dynamic widgets stuff (optional) and of course it should definitely work well :-D Well, it would be great if the 1.0.0 release was released about the time GTK 3.0 will be out, since it seems like GTK 3.0 will be the first gtk+ version to sort out the problems with theming entries and progress bars and it also looks like GTK 3.0 would also be RGBA enabled. Well, we'll see what the future brings :-D
General update

It’s been a while. I’ve been doing loads of little things lately, and that tends to stop me blogging. If I’m working on only one big thing then I tend to write about it as a break, often at the end of the day when I don’t want to start anything else, but hopping from task to task means there’s not one obvious thing to either a) write about or b) take breaks from. Ah well…

Probably the single biggest thing is that I started the process of getting an official OpenJDK porters project for zero. Zero’s been pretty much stable since the end of March so it’s high time I did this, but I’ve been procrastinating about it because I’m not sure how I’ll be able to develop in that environment. I want my local tree to be as close as possible to whatever upstream I’m using, which is currently the ecj-bootstrap side of IcedTea, but I won’t be able to use ecj to build straight from a project repository without either applying and committing the icedtea-ecj.patch (bad) or applying it locally and having a non-buildable repository (also bad). I may have to bite the bullet and use IcedTea to build it, which isn’t as bad as it initially seems since the target I use for rebuilds contains no Java. The initial build will be painful but I’ll just have to do it and be more careful not to blow away my tree!

Of course, the increasing interest in zero means I’m getting more bug reports. A few people have mentioned builds failing with java.lang.IllegalArgumentException: disparate values. I assumed they were all the same, so I investigated (and fixed) it on ia64, but that particular issue was little-endian specific and so doesn’t explain that people have been seeing it on ppc EPEL. It seems that this is the first place in the build where floating point values are used and checked, so this message is not one specific error but a catch-all for generic floating point bugs. Anyway, if you’re seeing this error then please let me know.

I’ve been thinking about TCK runs too. I didn’t fancy the idea of setting up an entire TCK environment on ppc, so I filed it in my head under “Future work”, but it occurred to me that zero works (or should do) on amd64 too, so it shouldn’t be too difficult to drop it into our nightly tester. I’ve not done more than thinking about this as yet since there’s not much point in doing it without copious free time to fix the thousands of bugs it’ll doubtless find — which I don’t have!

All this zero stuff has left Shark on the back-burner for a bit, but work there is progressing too. Lately I’ve been working on making unimplemented stuff abort only that compilation (not the entire VM) so that a)  people can use it in it’s unfinished state, and b) I can run some benchmarks and get some idea of the progress I’m making.

Let’s talk about release notes, shall we?

This process is really simple:

  1. You write content here.
  2. We edit the heck out of it.
  3. For Alpha and Beta releases, we make a one-page here.
  4. For RC to final, we take all that writing and editing to make up one set of rump-bumping release notes.

People, please! You know something already that should be in the Fedora 10 release notes, now is the time to post it. Not sure what to write or what to do with it? Use one of the six ways to submit a release note.

Act on ACTA

Nobody knows yet what the Anti-Counterfeiting Trade Agreement (ACTA) will consist of, but the few available indications are so ominous that the Free Software Foundation (FSF) has started a campaign to raise public awareness of the possibilities. According to Matt Lee, an FSF campaign manager, ACTA threatens to "create a culture of fear and suspicion," and, in the worst-case scenario, undermine and demonize free software.

Read the full interview with me over on Linux.com

Announcing the Fedora OLPC Special Interest Group
The engineers at OLPC are busy building an educational experience for the kids of the world. They are basing their excellent work on Fedora.

Their time is stretched perilously thin. Every hour an overworked OLPC engineer spends doing Fedora work is an hour they could be spending doing something else. We in the Fedora community can therefore have a huge, direct, and immediate impact on the success of the OLPC project.

Thus, I am proud to announce the formation of the Fedora OLPC Special Interest Group. Our mission: to provide the OLPC project with a strong, sustainable, scalable, community-driven base platform for innovation.

Immediate Goals:

1. To identify and take responsible ownership of as many OLPC base packages as possible.

2. To maintain an excellent Sugar environment for Fedora, including a dedicated Sugar spin.

3. To identify useful opportunities for collaboration (infrastructure, localization, etc.)

We should convene our first meeting as soon as possible. If you are interested in participating, please join the Fedora OLPC mailing list and introduce yourself.
FLOSSCamp 2008 - Romania
[floss camp]At the initiative of the Grupul pentru software liber (the Group for Free Software) there is an event organized in Romania for the first time this year: FLOSS Camp, on 29-30-31 August at Păltiniş, with the ideea to "take out of their houses all the people wanting to discuss or to exchange ideas and opinions about Free software".

So I guess everyone is invited - it is an offline event, there won't be Internet access and most likely not even electric power, but a couple of days away from our computers should be good, healthy and refreshing.

If nothing really brutal happens, I plan to attend and will share impressions about it (good thing it is not the same week end as FUDCon, for which I still have to make a decision for myself).
When to say to someone: you suck?
Living in the Eastern Europe I wasn't brainwashed into Political Correctness but still have a scale of moral values (which may be different from those in, say USA or Australia) so I have a mental blockage of saying to someone directly "you suck" or "your work suck", even if there are times when I really fell a need to do so.

Example: someone comes to the Fedora Art list, introduces himself and shows some graphics which are supposed to be a proof about his experience in the field. But the graphics are so bad, that there is no chance that person will be able to ever produce something useful. Usually you ignore the message or give a polite, but cold, reply, hopping he will understand (as anyone else, I had my share of those and sometime I think I understood the message, butprobably not always).

So a question I ask myself over and over is: is not more honest (and maybe the better thing to do) to say to that person directly "your work is not good enough"? That way he will not have false hopes, will not work in vain and maybe will have a chance to explore another area, where he may be good enough (but them, you will not be considered a "friendly community").

Of course, the same question may be asked outside the tiny niche of Linux graphics and I bet everyone wanted at least once to have heard a blunt "you suck" right from the start.

Note: this is not about literally saying "you suck", but about not necessarily trying to say nice things at all costs.
Instalasi offline rpm dengan lebih mudah
Banyak pengguna linux yang merasa kesulitan ketika harus melakukan instalasi sebuah aplikasi tanpa terhubung dengan internet. Tanpa tersedianya akses internet, instalasi paket berbasis rpm harus dilakukan dengan mendownload paket yang dibutuhkan untuk kemudian dieksekusi secara offline. Masalah yang sering timbul adalah ketidaklengkapan dependency (ketergantungan) terhadap paket-paket pendukung yang dibutuhkan sehingga harus kembali lagi mendowload paket-paket [...]
Notes on a weekend.

It was a nice weekend even though it was blisteringly hot. Saturday my wife took my daughter out for haircuts and some shopping, so I stayed at home with Trouble (we should probably just get around to changing my son’s name legally) and we played a bit. I also checked to see how his reading is coming along, and at age 4.5 he’s doing about as well as we could possibly hope. He trips a bit on words like “casually” but generally he can read even things he’s never seen before at a decent speed.

I also tuned my wife’s old autoharp — which has been sitting in various closets since we moved in together close to 20 years ago — so my daughter could use it. In actuality it probably badly needs new strings, but those generally cost upward of $60 and I have yet to see if Evie will keep up with it. They’re kind of limited, but very easy to play, and there’s a huge number of songs that are within reach with just a handful of chords. She seemed pretty psyched about it, but she’s much more into reading, writing, and making crafts.

I worked a little on a revamp of the Fedora release notes to try and get them building with publican. However, I ran into some pretty thorny problems because publican doesn’t seem to do things with XML in an XML-ish way. Instead, it relies on a lot of awk and sed commands to query or change the XML during the validation, translation, and build processes.

I remember several years ago when I was one of the people working on the Fedora documentation tool chain, that I had initially tried doing a lot of work this same way. The downfall in that methodology is it makes assumptions about the way the input document is physically formatted, which is a huge fail when it comes to XML (as I later learned, slowly and painfully). It also makes life very hard for people who want to use your tools on their pre-existing documents. Instead, there are a large variety of ways to do these same things programmatically using XSLT. Your input document is “understood” as a set of data nodes, and can be queried, manipulated, and output in ways that are sensible.

In any case, I was pretty disappointed, and although I was initially very enthusiastic about getting our Fedora docs working using this toolchain, I’m a little less so now. I’ll probably see if I can’t pull out some specific problems and file them as bugs. That means I should probably publish a git repository of the document on which I’m working, as a sort of test for the toolchain. Hopefully I’ll get some time for that this week.

Saturday night I stayed up a bit and watched Le scaphandre et le papillon (The Diving Bell and the Butterfly), which was simply superb. The lead, Mathieu Amalric, was great, but the actor who most surprised me was Max von Sydow as his father — phenomenal performance.

On Sunday morning Evie and I went out for some more bike riding practice. There were a couple of near-spills, but nothing too traumatic, other than the usual whining because she couldn’t immediately do it perfectly. I think it’s just a matter of a few more practices and she’ll be confident enough to start turning. By lunchtime, it was practically too hot to be out, but nevertheless I was running alongside her down the street as she went. We finished up covered with sweat, and went in to get cleaned up and have lunch.

Last night, Eleya and I watched another great film — El Orfanato (The Orphanage). It’s a Spanish language film that purports to be a horror movie, but only in the same sense as The Sixth Sense. Notably, it was produced by Guillermo del Toro, who seems to be racking up quite the résumé of tragedic horror fantasies featuring children. Well worth seeing.

K3RNEL: Ep 6: Showtime!

Los lunes son de K3RNEL en Fedora México

Hace tiempo que no publicabamos comics, una disculpa, pero por motivos personales no habiamos podido terminar esto. De todas formas, aqui esta el siguiente comic.

Haz click en la imagen para agrandar

English version - Click to view

Libera tus Bytes!
-Nushio

The fallacy of the completely inclusive community
Emma Jane Hogbin gave a presentation on the gender gap in free software at Lugradio Live this weekend. One of the central messages was that a great deal of how to avoid putting women off computing can be distilled down to "Don't be a dick". This ties in well with Mako's restatement of the Ubuntu code of conduct as "Be excellent to each other" (a wonderful phrasing which demonstrates that Bill and Ted's Excellent Adventure is the most philosophically worthwhile film that Keanu Reeves has ever appeared in, and certainly not The fucking Matrix) and led to my 5 minute rant on why I hate the Linux community slightly later in the day, but does leave a certain problem. What standards are used to define whether given behaviour is dickish or not? The comments here show that there's disagreement even within a single sub-community of the larger free software world. Ben suggests that the reaction to perceived inappropriate behaviour is perhaps even more discouraging than the original behaviour, suggesting that bitching about things that offend you is dickish behaviour in and of itself. How do we decide whether someone is being a dick or helping the community? Is lack of tolerance a form of exclusionary behaviour?

This topic is actually one of the issues discussed in the Geek Social Fallacies, but here's a nice easy example. Would tolerating planet posts encouraging the eradication of the Jewish population be inclusive or exclusive? I suspect that most people would agree that it wouldn't be acceptable behaviour, which leads us to the next question. Why? There's two obvious arguments here. The first is that at a community level we have some form of rough moral consensus that advocating genocide is Just Wrong, and so criticising Nazis is obviously the right thing to do. The second argument is more pragmatic than philosophical - alienating millions of people in order to avoid alienating hate groups could be considered to reduce our potential contributor base in an unfortunate way.

I'm a fan of the second argument. The example I gave is emotive and relatively recent history has resulted in people tending to be pretty uniform in considering genocide to be a bad thing, but many other cases aren't clear cut. What I consider to be objectification of women is seen by others as appreciation of natural beauty. What I think of as sexist jokes are perceived by others as acceptable humour. When I advocate intolerance of certain behaviour, people are going to see me not having enough tolerance. So we end up in a situation where people make the "We should all just get along and be tolerant of each other" argument, which sounds fine but is fundamentally flawed in one significant way.

Advocating tolerance excludes the intolerant.

The reason people fail to see this is that it doesn't sound like a flaw. If you ask people whether we need to support intolerance, the immediate answer is probably no. But by advocating exclusion of intolerance, you're excluding all those who have good reasons to be intolerant. You're excluding the women who don't want to feel that the community sees them as a pair of breasts attached to some legs. You're excluding the ethnic groups who would prefer to avoid racist slurs or ethnic stereotyping. Telling anti-fascism protestors that they're being intolerant isn't likely to endear you to them. Advocating tolerance is telling the intolerant that they're wrong and should just deal with whatever it is that makes them unhappy.

So, ironically, tolerating certain types of intolerance is probably required in order to avoid alienating many potential contributors. That means some way of deciding what kinds of behaviour are acceptable and which are unacceptable. In the absence of either pre-existing community consensus or some philosophical breakthrough that allows unambiguous determination of the "rightness" of a given action, I'm going to suggest that we look at it from a pragmatic viewpoint. How many potential contributors do we discourage by criticising a certain type of behaviour? How many do we discourage by tolerating it?

The fallacy of the completely inclusive community is the idea that it includes everyone. The reality is that a certain level of social exclusion is required in order to include a wider range of people. So don't criticise people purely for criticising someone else's behaviour - make an argument for why that behaviour benefits the community. And when you see behaviour that you think discourages others, call people on it. Even if nobody's behaviour changes as a result, you're sending a signal that not everyone in the community agrees. Sometimes all people want is to know that there'll be some people on their side.

But, above all, try not to be a dick.
Transformer un terminal Linux en invite de commandes MS-DOS

MS-DOS

Voici une petite astuce qui permet de transformer un shell Linux en invite de commande MS-DOS. Bien entendu, cela ne sert pas à grand chose sauf si vous êtes un inconditionnel du système d’exploitation Windows.


Pour réaliser cette transformation, lancez cette commande dans un terminal :

PS1='C:${PWD//\//\\\}>'

Si vous souhaitez que cette modification soit permanente, il suffira d'ajouter cette ligne dans le fichier ~/.bashrc.

Invite de commandes MS-DOS avec un shell Linux


Billet original de Tux-planet.

CentOS 5.2 Live-CD
Die Linux-Distribution CentOS 5.2 ist nun als Live-CD für x86-Rechner verfügbar. Die CD kann als Desktop-Ersatz verwendet werden, aber auch als Rettungssystem. Aus diesem Grund sind einige Systemwerkzeuge auf der CD enthalten.

CentOS 5.2 erschien im Juni 2008 und basiert auf den frei verfügbaren Quellen von Red Hat Enterprise Linux 5.2 (RHEL). CentOS nutzt, wie Fedora, zur Aktualisierung Yum. Die Live-CD lässt sich installieren und wurde wie die Fedora Live-CDs mit den livecd-tools hergestellt.

Für die Desktop-Funktionalität

  • openoffice.org 2.3.0
  • firefox 3.0
  • thunderbird 2.0.0
  • pidgin 2.3.1
  • scribus 1.3.3.2
  • xchat 2.6.6
  • k3b 0.12.17
  • gimp 2.2.13

Werkzeuge für ein Rettungseinsatz

  • memtest86+-1.65
  • Full set of LVM and RAID command line tools
  • QTParted
  • Nmap and NMapFE
  • traceroute
  • samba-3.0.28 with cifs kernel support to connect to Windows file shares
  • System Log Viewer
  • GUI Hardware Device Manager
Die CentOS 5.2 Live-CD ist auf verschiedenen Mirror-Servern verfügbar.


Taking Charge
2 new housemates moved into my house on last SAT. There was an extraordinary action done by one of them during dinner last night...

=====

Today attended "Taking Charge" training provided by the company. The highlight was the role play at the end, which we simulated a team member who was requesting for pay raise from her team leader.

The person who acted as team leader has done so excellent. He managed the conversation professionally and wisely. Neither side pissed off at the end. Therefore, I circled both "yes" and "no" as the answer of "Is the problem resolved?".

Why is that? "Yes" means the team member is calmed will wait for the team leader getting back with results of negotiations with HR. "No" means she will probably still very likely to quit if nothing significant that could hold her.

Sadly, when topic comes to money figure, intangible considerations factors would be at minimal. It is just an "uncertainty vs. opportunity" decision.

You stand on the ship deck of current company, only bling bling money becomes the best lighthouse if your career journey is heavily fogged.
weekend

Saturday morning - midnight - watched the ending to dr. horrible. The ending, while a bit sad and dark was still fantastic. Consistent with what Whedon has done on many other occasions and as one commenter on whedonesque.com wrote: “This is an origin story” which gives it more sense. Thoroughly enjoyed the musical and while I’d be happy to see more of them, b/c they’re fantastically funny, I’m fine with the ending we got out of it.

Saturday afternoon it was hot and kinda miserable outside so I went to one of the coffeeshops nearby and I wrote some more on some docs I’ve been working on. They’re shaping up reasonably nicely. Mostly they’re docs to fill in the spaces on some of the things yum/createrepo/yum-utils can do and to help explain things about how and why to manager repos and systems in certain ways. If you want to see more you can look in the yum-docs git repo.

Saturday evening went out in the torrentially pouring rain for the habitat for humanity full moon ride. The last time I did this ride it was wet and spitting rain and completely covered in clouds. This time it was raining like piss from a boot when I started out and visibility was, umm, poor. It would have been better if I hadn’t forgotten my bag when I left and had to turn around on my way there come back and get it. But the thing to remember is this: Once you decide you’re okay being soaked all the way through on every layer, it really does get easier. It was just an enormous amount of water, after all. :)

It ended up drying off and clearing away which was good, we actually got to see the moon, which was nice for a change. I kinda wish they hadn’t made us stop every 3 miles or so, that got a bit old.

Sunday was slow day. Coffee shop, crosswords, made pancakes with the girl, sat and read things, talked about cellphones for a while, then later we made completely kickass food for dinner. Seriously, good stuff. These are some of our Sunday dinners. It’s nice to have the kitchen back and sane.

That was most of my weekend.

Reminder: FESCo election closes on July 21st

This is a reminder that the current FESCo election(1) is open until
Monday, July 21st, 2008 23:59 UTC. So, if you haven’t gotten around to
voting yet, there is still a little over 24 hours to rectify that.

(1) https://www.redhat.com/archives/fedora-announce-list/2008-July/msg00005.html

July 20, 2008

technology fail weekender...
So this weekend was a total technology fail..

so on Sat night Gia rented a DVD to watch on a laptop, I was all should be no problem with this, armed with my livna (and livna-development) repositories, I started off on laptop 1, Thinkpad T60P. totem pulled an immeditate choke with some useless error message. mplayer choked similiarly with a nice bonghits in the libdvdread error message. This I tracked down to the region not being set correctly, so I set the drive region to region 4, and then mplayer failed even harder in a tight loop with kill -9 the only way out. It looked like bad sectors or something in the kernel.

So I went and tried it on laptop number 2, my Dell Insprion 6000, this machine is the oldest piece of kit I own and has been steadily on it way out the door (backlight flickers on/off due to dodgy connections internally). However it is also the only machine I have at home with a non-Lin