openSUSE 11.2 is out the door and it looks great – be sure to get your copy while it’s hot! One of the really great features of 11.2 is the opportunity to deploy the live media to USB in no time. Thanks to hybrid iso and clicfs you can carry around your persistent openSUSE 11.2 and use it wherever you are. What does persistence mean? Changes you do to the live media are preserved across reboots and you have a real operating system in a pocket without any restrictions. Isn’t that easy?

The setup is a breeze:

1. Download the 11.2 hybrid live media

2. Byte-copy the hybrid iso to your USB stick /dev/sdX
dd if=openSUSE-11.2-KDE4-LiveCD-i686.iso of=/dev/sdX bs=32kBe aware that dd will erase all vital data from your flash media! Thus double-check that /dev/sdX actually is your USB stick.

3. Utilize fdisk to prepare an empty 0x83 partition for persistence from the remaining space on /dev/sdX, i.e. /dev/sdX2 (you should have at least a 2GB USB stick to be able to do this). The 0x83 partition /dev/sdX2 doesn’t need to be formatted with any filesystem – Kiwi will take care of this on first boot fully automatically.

That’s it! More detailed information about persistent 11.2 LiveUSB setup can be found on the wiki

Have a lot of fun!

Additional Hint: If you happen to have an installed version of openSUSE 11.2 already and prefer a GUI method to deploy the hybrid iso to USB flash media, you also may use kiwi-tools-imagewriter instead of dd.

Me gusto este post. Muchas ocasiones en mi 'nuevo' empleo he comentado la importancia de decir un no a tiempo, razonado y justificado.

Por supuesto que decir siempre 'no' dista del ideal. Pero ayuda a establecer prioridades y funcionalidades realmente requeridas.

Es todo un arte eso de decir "no", que sería bueno dominar. Recordemos que más no siempre es mejor.

After speaking to various people within open source communities, one thing that is lacking, or would rather be avoided, is responsibility for leading projects and/or movements. Institutions within society in which we are trying to sell the benefits of open source to are looking for legitimate communities which offer proven sustainable results no matter how large or small they might be.

So much momentum has been gathered over the years through the development of communities and their product of innovation that it has produced projects yielded by "leaderless" communities. These communities work within circular networks which are often driven by shear idealist interest rather than practical goals.

Adversely, Traditional institutions are measured though a result based approach that is highly focused on either top-down or semi-flat management structures where the goals are defined by management.

Here is a good comparison of both aspects


I believe there is a spot in societies for both beliefs and their followers, but the future might bring more of a hybrid concept where one concept builds off the other. It will be interesting to see, but overall we need to start thinking more dynamically no matter what school of thought we subscribe to, and unfortunately I do not think we have quite made it there yet.

One day................A day after tomorrow.

Google lanzó el lenguaje Go. Por si usted amigo geek no sabia que hacer esta navidad, ya tiene garantizadas horas de diversión...

...no son lo mejor del mundo. Mejor dejar que todos hagan lo que requieren para su chamba y luego auditar. Vean el post de Schneier.

I've just learned out, that openSUSE zypp has wery useful configuration file /etc/zypp/zypp.conf, which contains crucial option solver.onlyRequires. If you set it to True, only really needed dependencies will be installed (of course you can install other packages manually).

This should be also possible to set during the installation. Just need to set the value from console before the libzypp is initialize - during first few screens of installation. But don't forget that it must be set after reboot/kexec as well so it is also valid for 2nd stage of installation and installed system.

...o menos, si son muy chingones. Los cursos aquí .

...instala wp y usa wptouch.

We’ll do a launch party in our Nürnberg office on Thursday Nov 12, 7-10pm CET. We’ll try to attract people from the Nürnberg area and show them what’s new in openSUSE 11.2, hand out some media and show openSUSE 11.2 in action. Additional we’ll have a number of outstanding openSUSE folks from SUSE attending and looking forward having interesting discussion. With openSUSE 11.1 we opened up for the first time the “internal” release party to the public. This time we’d like to go one step further and having the launch party just for people interested in openSUSE. We appreciate and invite of course any buddies interested in openSUSE from the Nürnberg office.

What about doing a launch party in your area and share openSUSE 11.2 with others? Just add your party to the list of openSUSE launch parties.

Fellow Package Maintainers,

How are you dealing with this ?

I guess f-spot is not the only project maintaining multiple parallel branches, a STABLE one, from which the releases and bugfix releases are created, and a master, open for business, new stuffs, and experimentations.

When we need to correct something on the STABLE branch, we push a new commit over there, then merge the STABLE back to master so it gets the same fixes. That works fine.

But it gets harder with translation commits. Most of the (awesome) translators (well, all except of one) translates the master and commits right there. Then, when it's time to release, I either ignore those translations (and that's seriously annoying for translators who pushed soem work in the .po), or I blindly backport (cherry-pick) the translations back to the STABLE branch and hope that no strings was removed in master's code. Then I merge the STABLE back to master. Both solutions are seriously suboptimal. Really.

I know how this problem is "solved" in most of the GNOME projects by putting deadlines and code freezes, and string freezes, but I guess we're not the only project around with this kind of issue.

The ideal workflow would be to have the translators (hey guys) aware of the STABLE branch, make them translate that branch, have them merge it back to master, and then, optionally, translate the missing/changed strings and commit that to master. I said ideal, cause I'm NOT gonna ask any translator to understand and follow this, be able to maually merge if something goes wrong, etc...

Translators (did I say thanks for your job lately) are already doing an ant job, most of them with no tools but a text editor, and we can't really add any pain to the process.

So, what are you doing in that case. How could we improve the process ?

Comments are open.