Search Results: "evo"

4 July 2012

Stefano Zacchiroli: bits from the DPL for June 2012

Monthly DPL bits, fresh from the oven^W^W^W hot from DebConf12, and just posted to d-d-a.
Howdy from DebConf12. It's hot, but it's also time to bother you again with a (not so) brief DPL activity report, this time for June 2012. Time-based freeze: DONE, short freeze: TODO Two highlights for this month. First, you've probably noticed Wheezy is now frozen, YAY. This is huge achievement for the release, but also for the project. It's the first time we do a time-based freeze, and it took some quite heated discussion at the beginning of the release cycle to decide to do this. And we did it properly: respecting the planned month and narrowing down the period later. This exercise has hopefully helped both DDs in their package planning and our upstreams in targeting Wheezy with stable releases of their software. Kudos to the release team for their coordination work! Now we've the second part still TODO: releasing Wheezy, without RC bugs, with a freeze period as short as possible. See the beginning of my last "bits from the DPL" mail for my usual song and dance :-P on how to deliver that, together. DebConf12 A lot of us will attend DebConf12. Enjoy it! ... and take the chance to both have fun and make great plans for Debian's future. But remember that "if it didn't happen on a mailing list, it didn't happen". Not all of us will be lucky enough to attend DebConf (in person or remotely). Make sure that those who don't can take part in your team decisions and get informed of what is going to happen here. Politics Zack's spring tour I spent a significant part of June doing Debian talks ins some sort of "spring tour" between Italy and France. In particular: Many thanks to the organizers of these events for inviting and sponsoring me (as well as other Debian people, in the ESRF case) and for their interest in Debian. Sprints Assets Discussions Some relevant discussions for project evolution has been going on in June and I took part into them. You might want to have a look at them: Misc Cheers.
PS the boring day-to-day activity log for June is available at master:/srv/leader/news/bits-from-the-DPL.txt.201206

2 July 2012

Raphaël Hertzog: My Debian Activities in June 2012

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (168.12 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg This month, I resumed my work on dpkg. I concentrated my efforts on some polishing of the 3.0 (quilt) format. With the latest version (1.16.6 which was uploaded to unstable shortly before the freeze), dpkg-source restores the source tree in a clean state after a failed patch application (#652970), doesn t overwrite the patch header from the pre-existing automatic patch, updates automatically debian/source/include-binaries during dpkg-source commit, and supports a new no-unapply-patches option for those who dislike the auto-unapplication at the end of the process when the patches were not applied at the start. I wanted to go further and offer a new feature that could insert the automatic patch at the bottom of the quilt series but I have been short on time to complete this feature. I just managed to factorize all the quilt handling in a dedicated Perl module (Dpkg::Source::Quilt) to have cleaner code in the module handling the source format (Dpkg::Source::Package::V3::quilt). For those who wonder, this feature is meant primarily for the X Strike Force team which maintains packages in Git and are doings lots of upstream cherry-picks (to fix regressions, etc.). But they also use quilt on top of that tree to keep some lasting Debian specific changes. With the 1.0 format, the automatic diff is a bit messy but at least it gets smaller automatically when a new upstream release gets out, there s nothing to clean out. I d like them to be able to use 3.0 (quilt) while keeping their workflow. I m leaning towards allowing --auto-commit=first:cherry-picks that would name the automatic patch cherry-picks and put it in the first position in the quilt series. (Opinions welcome on that feature, BTW) Packaging There s been quite some packaging in this last month before the freeze: While doing all this packaging work, I found 2 possible improvements that I filed as bug reports: Debian France Booth at Solutions Linux From June 19th to June 21th, I manned the Debian France booth at Solutions Linux together with Carl Chenet, Tanguy Ortolo and other members of the association. We answered lots of questions, sold all t-shirts and umbrellas that Carl imported from Germany and Switzerland (we really need to get our own merchandising stuff produced in France!), got people to join the association. We also presented a printed copy of the Debian Administrator s Handbook and of the corresponding French book. You can see Carl, me and Tanguy on this picture (click on it to see a bigger picture, thanks to S bastien Dubois of Evolix for this one!):
I know lots of people are preparing for Debconf but I decided to not attend this year, the price of the air plane ticket was a bit too hefty for me and it was also in partial conflict with our family vacations. I thought about attending the Libre Software Meeting instead but alas I won t go there either (but Roland Mas will be there!), I have too much work to complete before my own vacation in 2 weeks. Thanks See you next month for a new summary of my activities.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

26 June 2012

Petter Reinholdtsen: Debian Edu interview: Jos Luis Redrejo Rodr guez

I've been too busy at home, but finally I found time to wrap up another interview with the people behind Debian Edu and Skolelinux. This time we get to know Jos Luis Redrejo Rodr guez, one of our great helpers from Spain. His effort was the reason we added support for several desktop types (KDE, Gnome and most recently LXDE) in Debian Edu, and have all of these available in the recently published Debian Edu Squeeze version. Who are you, and how do you spend your days? I'm a father, teacher and engineer who is working for the Education ministry of the Region of Extremadura (Spain) in the implementation of ICT in schools How did you get in contact with the Skolelinux/Debian Edu project? At 2006, I verified that both, we in Extremadura and Skolelinux project, had been working in parallel for some years, doing very similar things, using very similar tools and with similar targets, so I decided it was time to join forces as much as possible. What do you see as the advantages of Skolelinux/Debian Edu? A community of highly skilled experts working together, with a really open schema of collaboration and work. I really love the concepts of Do-ocracy and Merit-ocracy and the way these concepts are been used everyday inside Debian Edu. What do you see as the disadvantages of Skolelinux/Debian Edu? Sometimes the differences in the implementations, laws or economical and technical resources in the different countries don't allow us to agree in the same solution for all of us, and several approaches are needed, what is a waste of effort. Also, there is a lack of more man power to be able to follow the fast evolution of the technologies in school. Which free software do you use daily? Debian, of course, and due to my kind of job I am most of my time between Iceweasel, Geany and Terminator. Which strategy do you believe is the right one to use to get schools to use free software? I think there is not a single strategy because there are very different scenarios: schools with mixed proprietary and free environments, schools using only workstations, other schools using laptops, netbooks, tablets, interactive white-boards, etc. Also the range of ages of the students is very broad and you can not use the same solutions for primary schools and secondary or even universities. So different strategies are needed. But, looking at these differences, and looking back to the things we've done and implemented, and the places were we have spent most of our forces, I think we should focus as much as possible in free multi-platform environments, using only standards tools, and moving more and more to Internet or network solutions that could be deployed using wireless. I think we'll see more and more personal devices in the schools, devices the students and teachers will take home with them, so the solutions must be able to be taken at home and continue working there.

25 June 2012

Raphaël Hertzog: Test Driven Development with CppUTest, now in Debian

I have recently read Test Driven Development with Embedded C by James W. Grenning and published by Pragmatic Programmers. I really enjoyed the book: while I was aware of the huge benefits of having a comprehensive test suite, I never studied seriously the principles behind Test Driven Development (TDD) and this book makes a good introduction to the topic. At the same time it focuses on the C language and contains lots of examples on how you can create tests even for projects which have to interact with hardware or other unpredictable components (the key is to create many abstractions) using all the possibilities that C offers. The author convincingly argues that developing code with TDD forces you to create a modular design that is easier to evolve when the underlying requirements change. He also highlights how the tests serve as reference documentation of the API. James W. Grenning recommends CppUTest as his xUnit test framework of choice. When I wanted to try this test framework, I discovered that it was not available in Debian. I decided to package it because it has some interesting features not offered by the contenders (at least not to my knowledge). It s now available in Debian and in Ubuntu. First, it doesn t require any explicit registration of tests and has a very lightweight syntax. The small downside is that CppUTest requires the usage of C++ for the tests. But C++ is compatible with C so it doesn t matter much if you have a C++ compiler for your target. On the contrary, usage of variables and methods scoped to the test group makes it easy to write clear tests. Here s a short sample of test code: 
extern "C"  
#include "timer.h"
#include "timefn.h"
 
 
#include "CppUTest/TestHarness.h"
 
static Time the_time;
static const int start_sec = 123;
static const int start_nsec = 456789000;
static const int delay_sec = 8;
static const int delay_nsec = 111111000; // start_nsec + delay_nsec < 10^9
 
TEST_GROUP(Timer)
 
    /* Class variables available to all tests in the group */
    Timer timer;
    Delay remaining;
 
    /* Standard setup/teardown methods of xUnit tests */
    void setup()  
        timer = timer_new();
        time_set(&the_time, start_sec, start_nsec);
        /* [...] */
     
 
    void teardown()  
        timer_free(timer);
        /* [...] */
     
 
    /* Helper functions specific to the test group */
    void start_timer_with_delay(long sec, long nsec)
     
        timer_set_real_delay(timer, sec, nsec);
        timer_start(timer);
     
 
    void ensure_remaining_is(long sec, long nsec)
     
        CHECK_EQUAL(sec, delay_get_seconds(remaining));
        CHECK_EQUAL(nsec, delay_get_nanoseconds(remaining));
     
 ;
 
TEST(Timer, NewIsNotStarted)
 
    CHECK(!timer->started);
 
/* [...] */
TEST(Timer, GetRemainingTimeWithNanosecondPrecision_ShiftOfSeconds)
 
    start_timer_with_delay(delay_sec, delay_nsec);
    time_set(&the_time, start_sec + delay_sec - 5, start_nsec + delay_nsec + 1000);
 
    remaining = timer_get_remaining_time(timer);
 
    ensure_remaining_is(4, 999999000);
To run those tests, you just need this boilerplate code in a main.cpp: 
#include "CppUTest/CommandLineTestRunner.h"
 
int main(int argc, char** argv)
 
   return CommandLineTestRunner::RunAllTests(argc, argv);
Another interesting feature is its integrated memory leak detection system. Any test that hasn t released allocated memory at the end of the teardown process will be marked as failed. The upstream developers have made some unusual choices (static library only, installation in a private directory) but this will likely change with the switch to an automake and autoconf-based build system. I have reported the oddities that I found and I requested them to provide a pkg-config file to make it easier to compile and link unit tests exploiting CppUTest. I already used CppUTest to develop a small application running on an embedded Linux. At some point, I might try to use CppUTest for dpkg development. I believe that it makes for a good fit. dpkg is already C++ ready since dselect is written in C++ and reuses a good part of dpkg s code. In any case, if you like Test Driven Development and are writing C or C++ based applications, I invite you to try CppUTest.

No comment Liked this article? Click here. My blog is Flattr-enabled.

24 June 2012

Joey Hess: trying obnam

Obnam 1.0 was released during several months when I had no well-connected server to use for backups. Yesterday I installed a terabyte disk in a basement with a fiber optic network connection, so my backupless time is over. Now, granted, I have a very multi-layered approach to backups; all my data is stored in git, most of it with dozens of copies automatically maintained, and with archival data managed by git-annex. But I still like to have a "real" backup system underneath, to catch anything else. And to back up those parts of my user's data that I have not given them tools to put into git yet... My backup server is not my basement, so I need to securely encrypt the backups stored there. Encrypting your offsite backups is such a good idea that I've always been surprised at the paucity of tools to do it. I got by with duplicity for years, but it's increasingly creaky, and the few times I've needed to restore, it's been a terrific pain. So I'm excited to be trying Obnam today. So far I quite like it. The only real problem is that it can be slow, when there's a transatlantic link between the client and the server. Each file backed up requires several TCP round-trips, and the latency kills the bandwidth. Large files are still sent fast, and obnam uses little resources on either the client or server while running. And this mostly only affects the initial, full backup. But the encryption and ease of use more than make up for this. The real killer feature with Obnam's encryption isn't that it's industry-standard encryption with gpg, that can be trivially enabled with a single option (--encrypt-with=DEADBEEF). No, the great thing about it is its key management. I generate a new gpg key for each system I back up. This prevents systems reading each other's backups. But that means you have to backup the backup keys.. or when a system is lost, the backup would be inaccessible. With Obnam, I can instead just grant my personal gpg key access to the repository: obnam add-key --keyid 2512E3C7. Now both the machine's key and my gpg key can access the data. Great system; can't revoke access, but otherwise perfect. I liked this so much I stole the design and used it in git-annex too. :) I'm also pleased I can lock down .ssh/authorized_keys on my backup server, to prevent clients running arbitrary commands. Duplicity runs ad-hoc commands over ssh, which defeated me from ever locking it down. Obnam can be easily locked down, like this: command="/usr/lib/openssh/sftp-server" This could still be improved, since clients can still read the whole filesystem with sftp. I'd like to have something like git-annex's git-annex-shell, which can limit access to only a specific repository. Hmm, if Obnam had its own server-side program like this, it could stream backup data to it using a protocol that avoids the roundtrips needed by the SFTP protocol, and fix the latency issue too. Lars, I know you've been looking for a Haskell starter project ... perhaps this is it? :)

19 June 2012

Wouter Verhelst: E-voting in Belgium

A post by Gunnar reminded me that I wanted to blog about this: e-voting in Belgium is going to change slightly. Previously, e-voting worked with a computer with a lightpen on which you would enter your vote, a magnetic card that would contain your vote in encoded form, and a magnetic card reader that would count the votes. After more than a decade when I was first eligible to vote back in 1996, it had already been implemented in the city of Antwerp, where my vote would be cast, so I've never voted on paper it had still not been rolled out everywhere, and some of the computers used for the voting were now starting to show their age. A few days ago on the news, they reported that the e-voting system was to change so that rather than magnetic cards, it would use pieces of paper. This way, voters would be able to check that the information on the piece of paper conforms with their vote. Investigating what this means, I found this website by the federal government, where they have some pictures of a test run of the new system which they ran in October last year. Rather than using magnetic cards, the new system uses paper slips with the voted information in two forms: once as a (huge) QR code, and once as a human-readable text. In theory, this is a more transparent system than using a magnetic card, and that's a good thing; additionally, it allows for a traditional recount (by people, not computers) should the need ever arise. However, I do still see some problems: Having said that, I do think the new system is an improvement over the old (in fact, it's exactly the kind of system I had thought about myself earlier when thinking about ways to improve e-voting); and if the two problems are solved in some way (it's not impossible to do that, just requires some clever thinking), I believe it has potential as a way to implement electronic voting in a good way.

18 June 2012

Gunnar Wolf: Turning failure into apparent success, and carrying on: e-voting in Jalisco

I will sound monothematic, but I have been devoting quite a bit of work to this topic lately: Trying to stop the advance of e-voting in Mexico, Latin America and the world. Why trying to stop it? Isn't technology supposed to help us, to get trustable processes? Yes, it's supposed to... but it just cannot achieve it, no matter how hard it is tried I won't get into explanations in this blog post, but there is plenty of information. Feel free to ask me for further details. Anyway Yesterday (Sunday, 2012-06-17) was the fifth simulated voting that will lead to the first wide-scale deployment of electronic voting booths in my country: About 10% of the population of the state of Jalisco (that means, ~500,000 people) will cast their votes on July 1st electronically. This particular case illustrates how simulated votings can be used to forge a lie: Pounce Consulting, the company that won the e-voting project for IEPC (Jalisco's voting authority), delivered their booths over 40 days late, just before the deadline for the project to be canceled. Oh, and by the way, it's the same company that just failed to deliver on time for another planned local authority (10% of the booths in the Federal District, where I live, where fortunately 100% of the votes will be cast on traditional, auditable and cheap paper). After this delay, five voting simulations were programmed, to get the local population acquinted with them. The first ones just failed to get the population's interest and had close to 40% failure rates (mainly regarding transmission). Several other "minor details" were reported, including mechanical details that allowed subsequent voters to see the vote of who had just left. Anyway, making long story short: The fifth and last simulation was held yesterday. Officially, it was finally successful (about time). As these booths include the "facilities" to communicate the results via the cellular network, but the populations where they are to be deployed do not yet have cellular coverage, 10% of the booths will have to be carried back to the Districtal Header (that can be a ~10hr trip) to be counted. Also, in all places, traditional paper stationery and paraphernalia will be printed just in case it is needed (and when will they now? When half of the votes are cast and lost?) Anyway... e-voting is still in its first stage in Mexico. Right now, I'm sure, no attempts to rig the election will be made (centrally). But every effort will be made (as it has been made) to dismiss the obviously big and nontrivial ways it has failed and will fail, and any problems will be labeled as "minor". And probably by 2018 we will be facing many more states (even nationwide) deployments. But propaganda fails to see the obvious: E-voting is more expensive, more complicated, leads to more possible failure states. E-voting should not be deployed in large-scale (i.e. more than a couple of hundred voters) elections. Electronic voting is insecure, violates secrecy, allows for fraud. No matter how many locks are put into it.

17 June 2012

Christian Perrier: Debian: Thou Shalt Be Packaged

Debian is such a universal system: 
# apt-get install wine and cheese
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  brasero brasero-common cheese-common desktop-file-utils evolution-data-server-common gcr gir1.2-atk-1.0 gir1.2-clutter-1.0 gir1.2-clutter-gst-1.0 gir1.2-cogl-1.0
  gir1.2-coglpango-1.0 gir1.2-evince-3.0 gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-gst-plugins-base-0.10 gir1.2-gstreamer-0.10 gir1.2-gtk-3.0 gir1.2-gtkclutter-1.0
  gir1.2-gtksource-3.0 gir1.2-json-1.0 gir1.2-pango-1.0 gnome-desktop3-data gnome-icon-theme gnome-keyring gnome-sushi gnome-video-effects gstreamer0.10-plugins-ugly gvfs
  gvfs-backends gvfs-common gvfs-daemons gvfs-libs hwdata libbrasero-media3-1 libburn4 libcamel-1.2-29 libcap2-bin libcdio-cdda1 libcdio-paranoia1 libcdio13 libcheese-gtk21
  libcheese3 libclutter-1.0-0 libclutter-1.0-common libclutter-gst-1.0-0 libclutter-gtk-1.0-0 libclutter-imcontext-0.1-0 libcluttergesture-0.0.2-0 libcogl-common libcogl-pango0
  libcogl9 libebook-1.2-12 libecal-1.2-10 libedataserver-1.2-15 libedataserverui-3.0-1 libevdocument3-4 libevview3-3 libexempi3 libgck-1-0 libgcr-3-1 libgcr-3-common libgee2
  libgjs0b libglib2.0-data libgnome-desktop-3-2 libgssdp-1.0-3 libgupnp-1.0-4 libgxps2 libisofs6 libjson-glib-1.0-0 libjte1 libmozjs185-1.0 libmpg123-0 libmx-1.0-2 libmx-bin
  libmx-common libnautilus-extension1a libpam-cap libpam-gnome-keyring libpoppler-glib8 libpoppler19 libquvi-scripts libquvi7 libsidplay1 libt1-5 libtotem-plparser17
  libtracker-sparql-0.14-0 libwine libwine-alsa libwine-bin libwine-gecko-1.4 libwine-gl nautilus nautilus-data nautilus-sendto wine-bin
Suggested packages:
  libdvdcss2 gnome-video-effects-frei0r libcap-dev sidplay-base xsidplay wine-doc libwine-cms libwine-sane libwine-ldap libwine-print libwine-openal libwine-gphoto2 eog
  xdg-user-dirs tracker pidgin gajim ttf-mscorefonts-installer winbind avscan klamav clamav 
The following NEW packages will be installed:
  and brasero brasero-common cheese cheese-common desktop-file-utils evolution-data-server-common gcr gir1.2-atk-1.0 gir1.2-clutter-1.0 gir1.2-clutter-gst-1.0 gir1.2-cogl-1.0
  gir1.2-coglpango-1.0 gir1.2-evince-3.0 gir1.2-freedesktop gir1.2-gdkpixbuf-2.0 gir1.2-gst-plugins-base-0.10 gir1.2-gstreamer-0.10 gir1.2-gtk-3.0 gir1.2-gtkclutter-1.0
  gir1.2-gtksource-3.0 gir1.2-json-1.0 gir1.2-pango-1.0 gnome-desktop3-data gnome-icon-theme gnome-keyring gnome-sushi gnome-video-effects gstreamer0.10-plugins-ugly
  gvfs-backends hwdata libbrasero-media3-1 libburn4 libcamel-1.2-29 libcap2-bin libcdio-cdda1 libcdio-paranoia1 libcdio13 libcheese-gtk21 libcheese3 libclutter-1.0-0
  libclutter-1.0-common libclutter-gst-1.0-0 libclutter-gtk-1.0-0 libclutter-imcontext-0.1-0 libcluttergesture-0.0.2-0 libcogl-common libcogl-pango0 libcogl9 libebook-1.2-12
  libecal-1.2-10 libedataserver-1.2-15 libedataserverui-3.0-1 libevdocument3-4 libevview3-3 libexempi3 libgck-1-0 libgcr-3-1 libgcr-3-common libgee2 libgjs0b libglib2.0-data
  libgnome-desktop-3-2 libgssdp-1.0-3 libgupnp-1.0-4 libgxps2 libisofs6 libjson-glib-1.0-0 libjte1 libmozjs185-1.0 libmpg123-0 libmx-1.0-2 libmx-bin libmx-common
  libnautilus-extension1a libpam-cap libpam-gnome-keyring libpoppler-glib8 libpoppler19 libquvi-scripts libquvi7 libsidplay1 libt1-5 libtotem-plparser17 libtracker-sparql-0.14-0
  libwine libwine-alsa libwine-bin libwine-gecko-1.4 libwine-gl nautilus nautilus-data nautilus-sendto wine wine-bin The following packages will be upgraded:
  gvfs gvfs-common gvfs-daemons gvfs-libs   
4 upgraded, 95 newly installed, 0 to remove and 974 not upgraded.   
Need to get 100 MB/104 MB of archives.
After this operation, 250 MB of additional disk space will be used.
Thanks to Zobel, who pointed me to this one....

11 June 2012

Aigars Mahinovs: New camera research

So, I was reading the coverage of the newly announced Canon 650D last week and it so happened that a friend needed a camera, so I sold my old Canon 550D and started looking for a replacement. For the last few years 95+% of the photos I have taken were with Canon 35mm f/2.0 lens on my Canon 550D, sometimes helped with a bounce&swivel flash. Which is very close to 50mm in full-frame equivalent. So I am looking to continue shooting in a similar way with a near-50mm prime lens and sometimes with bounce flash. As a given I have: Canon 35mm f/2.0, Canon 50mm f/1.8, Canon Speedlite 430EX II (bounce&swivel flash) and a budget of around 1k USD. It is a fun time to be looking around for a new camera body, so I found that I have many interesting options: Option 1: safe bet. Wait a bit and get the new Canon 650D body and continue shooting with the 35mm and the Canon flash. Pros: safe, new tech, good video. Cons: rather bulky and heavy, boring. Option 2: old school. Get a used Canon 5D Mark II body that pros are selling off to buy their Mark III and then start taking photos with the Canon 50mm f/1.8 lens and the Canon flash. Sell Canon 35mm f/2.0 to cover the price difference between bodies. Pros: full frame, higher resolution, huge viewfinder. Cons: very heavy and bulky, evolutionary dead-end, used, bad corner performance even with best lenses. Option 3: new wave. Sell the rest of my Canon stuff and buy into one of the new mirrorless cameras. The problem with this approach is that I can not find a mirrorless camera with all of: 18+ Mpix, sharp and fast near-50mm-equivalent prime autofocus lens, bounce&swivel external flash. Pros: light and small, new tech, funky. Cons: lens fragmentation, bad adapters (no AF), bad flashes. So, basically I am torn three ways. Any advice? Which mirrorless camera system would best match my needs? P.S. Due to work issues and the long distance, I am *not* attending this years Debconf.
P.P.S. To keep this slightly more on-topic how is the RAW files support on Linux for the new crop of the mirrorless cameras?

8 June 2012

Matthew Garrett: The security of Secure Boot

The other complaint about UEFI Secure Boot is that it doesn't add any security. There's two aspects to this - people either think it'll be quickly broken, or people think that the public availability of signing services will render it useless.
Will Secure Boot be broken?Almost certainly, yes. I'd put a significant amount of money on it. The most obvious avenue of attack is probably a malformed FAT on a USB stick, or alternatively a programmable USB device that can trigger undesired behaviour in the USB stack. If you're really lucky then you might be able to corrupt the filesystem on the EFI system partition in such a way that this happens on every boot, even if there's no USB hardware connected. It's possible that there'll be a bug in the binary validation process and a cleverly designed binary may be able to validate even though it contains unsigned code. Various vendors will probably manage to produce signed option ROMs that rely on unsigned data in such a way that they can be forced to misbehave. But most of these attacks will either involve physical access or depend on the target machine having a specific piece of hardware installed, and I'd also put money on each of them being quickly fixed once they're found. And, eventually, people will run out of new attacks.

People desperately want to believe that the Secure Boot implementation is fundamentally broken, and that's just not true. It's based on well-tested encryption technology. You calculate a SHA256 of the binary you want to sign. You encrypt that hash with the private half of a 2048-bit RSA key. You embed the encrypted hash in the binary. When someone tries to run the binary you decrypt the hash with the public key in your firmware. You then calculate the hash of the binary and compare the two. If they match then you know that (a) whoever signed the binary had access to the private half of a key you trust, and (b) the binary hasn't been modified since then.

The difference between Secure Boot and things like CSS or WEP is that Secure Boot uses existing cryptographic techniques and has been designed by people who actually understand how they work. Precisely the same technology is used in Microsoft's driver signing, and people decided it was easier to steal a key from Realtek than it was to break the underlying technology. Unless there's a crippling bug in the implementation that nobody's noticed yet, the only real way to attack this is to either force a SHA256 collision (achievable with current technology, as long as you're willing to spend many orders of magnitude more time than the universe has existed) or break RSA (which would also mean that SSL is broken). If anyone can do either of these things then we are so unbelievably fucked that Secure Boot should not be the thing you're most worried about.

So, in summary: Yes, Secure Boot will be broken. And then it will be fixed. And after this happens a few times, there will be no further breaks.
Everyone can sign, so what's the pointAnyone can pay $99 and get their binaries signed. So why won't malware authors just do that? For starters, you'll need to provide some form of plausible ID for Verisign to authenticate you and hand over access. So, sure, you provide some sort of fake ID. That's the kind of thing that tends to irritate local authorities - not only are you talking about breaking into a bunch of computers, you're talking about committing the sort of crime that results in genuinely bad things happening to you if you get caught. And secondly, the only way you get access to the system is using some physical smartcards that Verisign send you. So you've also had to hand over an actual physical address, and even if you've used some sort of redirection service that's still going to make it easier to track you down. You're taking some fairly significant real-world risks.

But ok, you're willing to do that and you obtain a signing key and you sign some malware. You'll infect some number of machines. But eventually you'll be noticed, and then Microsoft produce a key revocation blob and vendors push it out via their OS update mechanisms. If your malware was basically harmless then that's probably the end of it, but if you were using it as the basis for an attack on people's banking details then a lot of people are suddenly going to be very interested in the person who bought that key, and also your malware isn't going to be able to infect any more machines.

To put this in perspective - Windows is the dominant desktop operating system. If you want to run a botnet or steal people's bank details then Windows is the obvious thing to attack. Windows security has now improved to the point where it's not massively straightforward to do that from userspace, so the logical thing to do would be to run your malware in the kernel. The easiest way to do that would be to load a driver, but Windows won't load unsigned drivers. So you'd need a signed driver. How do you get one? With the same $99 access to the Microsoft signing service that you'd use for signing an EFI binary.

Anyone could already use the signing service to attack Windows. But people haven't. The Stuxnet authors thought it was easier to steal a key from a real hardware vendor than it was to buy their own key. So, yes, in theory an attacker could obtain signing services. But the real world evidence suggests that that's not how they behave.
SummarySecure Boot is unlikely to be broken via fundamental flaws in its implementation, and there's no evidence that public availability of the signing service will result in an explosion of boot level malware.

comment count unavailable comments

3 June 2012

Jordi Mallach: GNOME 3.4 in wheezy

Users of Debian sid will have noticed: the final (and interesting) bits of GNOME 3.4 have landed and if all looks as good as it does now, they should migrate to wheezy in about a week. 3.2 3.4 hasn't been as complicated as the previous horrible transition, but still had some complications due to Cogl/Clutter incompatibilities. Other than that, our major problem has been manpower, but this isn't new for many other Debian teams. We've also seen new incarnations of Linux-only technology is now mandatory which makes our lives a bit more miserable due to kfreebsd-* and hurd-i386, but for now we've still been able to dodge it. It seems wheezy+1 will be fun in that regard though, and we might need to take drastic approaches. If all goes well and the current lot (GNOME Shell, Control Center, Settings daemon, Mutter...) transitions without additional problems, we should be wrapping up our transitions for wheezy with Evolution and friends (currently sitting in experimental), and hopefully GDM 3.4. As we get many questions regarding the status of GDM in Debian, let's add a short note on this. Packaging GDM, at least in its current upstream form, is not a matter of unpacking a new tarball and editing debian/changelog. When Joss works on a new major version, the amount of tweaking to break away from stuff that works on other distros but is not so simple in Debian is outstanding (see, for example, the current unfinished work for GDM 3.2 in our SVN repo). In our case, to handle our GDM defaults, we even need changes to the underlying configuration system, dconf. This evidently takes some effort to do, and unfortunately our GDM expert has had little time for Debian lately, but we're confident we'll end up with a GDM in wheezy that is on par with Debian standards. We are, as always, reachable at #debian-gnome in the OFTC IRC network. Have fun!

31 May 2012

Russell Coker: Links May 2012

Vijay Kumar gave an interesting TED talk about autonomous UAVs [1]. His research is based on helicopters with 4 sets of blades and his group has developed software to allow them to develop maps, fly in formation, and more. Hadiyah wrote an interesting post about networking at TED 2012 [2]. It seems that giving every delegate the opportunity to have their bio posted is a good conference feature that others could copy. Bruce Schneier wrote a good summary of the harm that post-911 airport security has caused [3]. Chris Neugebauer wrote an insightful post about the drinking culture in conferences, how it excludes people and distracts everyone from the educational purpose of the conference [4]. Matthew Wright wrote an informative article for Beyond Zero Emissions comparing current options for renewable power with the unproven plans for new nuclear and fossil fuel power plants [5]. The Free Universal Construction Kit is a set of design files to allow 3D printing of connectors between different types of construction kits (Lego, Fischer Technic, etc) [6]. Jay Bradner gave an interesting TED talk about the use of Open Source principles in cancer research [7]. He described his research into drugs which block cancer by converting certain types of cancer cell into normal cells and how he shared that research to allow the drugs to be developed for clinical use as fast as possible. Christopher Priest wrote an epic blog post roasting everyone currently associated with the Arthur C. Clarke awards, he took particular care to flame Charles Stross who celebrated The Prestige of such a great flaming by releasing a t-shirt [8]. For a while I ve been hoping that an author like Charles Stross would manage to make more money from t-shirt sales than from book sales, Charles is already publishing some of his work for free on the Internet and it would be good if he could publish it all for free. Erich Schubert wrote an interesting post about the utility and evolution of Favebook likes [9]. Richard Hartmann wrote an interesting summary of the problems with Google products that annoy him the most [10]. Sam Varghese wrote an insightful article about the political situation in China [11]. The part about the downside of allowing poorly educated people to vote seems to apply to the US as well. Sociological Images has an article about the increased rate of Autism diagnosis as social contagion [12]. People who get their children diagnosed encourage others with similar children to do the same. Vivek wrote a great little post about setting up WPA on Debian [13]. It was much easier than expected once I followed that post. Of course I probably could have read the documentation for ifupdown, but who reads docs when Google is available? Related posts:
  1. Links March 2012 Washington s Blog has an informative summary of recent articles about...
  2. Links April 2012 Karen Tse gave an interesting TED talk about how to...
  3. Links February 2012 Sociological Images has an interesting article about the attempts to...

28 May 2012

Pietro Abate: managing puppet manifest with gitolite

Managing the puppet manifest using a vcs is a best practice and there is a lot of material on the web. The easier way to do it, is to use git directly in the directory /etc/puppet and use a simple synchronization strategy with an external repo, either to publish your work, or simply to keep a backup somewhere. Things are a bit more complicated when you would like to co-administer the machine with multiple people. Setting up user accounts, permission and everything can be a pain in the neck. Moreover working from your desktop is always more comfortable then logging in as root on a remote system and make changes there ... The solution I've chosen to make my life a bit easier is to use gitolite, that is a simple git gateway that works using ssh public keys for authentication and does not require the creating of local users on the server machine. Gitolite is available in debian and installing it is super easy : apt-get install gitolite . If you use puppet already you might be tempted to use puppet to manage your gitolite installation. This is all good, but I don't advice you to use modules like this one http://forge.puppetlabs.com/gwmngilfen/gitolite/1.0.0 as it's going to install gitolite from source and on debian it's not necessary ... For my purposes, I didn't find necessary to manage gitolite with puppet as all the default config options where good enough for me. Once your debian package is installed, in order to initialize your repo, you just need to pass to gitolite the admin public key, that is your .ssh/id_rsa.pub key and then run this command:
sudo -H -u gitolite gl-setup /tmp/youruser.pub
This will create the admin and testing repo in /var/lib/gitolite/repositories and setup few other things. At this point you are ready to test you gitolite installation by cloning the admin repo :
git clone gitolite@example.org:gitolite-admin.git
Gitolite is engineered to use only the gitolite use to manage all your repositories. To add more repositories and users you should have a look at the documentation and then editing the file conf/gitolite.conf to add your new puppet repository. At this point, you can go two ways. If you use git to manage your puppet directory, you can just make a copy of it somewhere and then add gitolite as a remote
git remote add origin gitolite@example.org:puppet.git
If you didn't use git before, you can just copy the manifest in your new git repository, make a first commit and push it on the server.
git push origin master
Every authorized users can now use git to clone your puppet repository, hack, commit, push ...
git clone gitolite@example.org:puppet
One last step is to add a small post-receive hook on the server to synchronize your gitolite repository with the puppet directory in /etc : This will sync your main puppet directory and trigger changes on the nodes for the next puppetd run. First I created a small shell script in /usr/local/bin/puppet-post-receive-hook.sh :
#!/bin/bash
umask 0022
cd /etc/puppet
git pull -q origin master
This script presuppose that your git repo in /etc/puppet has the gitolite repo as origin ... Then I added a simple hook in the gitolite git repo that calls this script using sudo :
sudo /usr/local/bin/puppet-post-receive-hook.sh
And since you are at it you should also add a pre-commit hook to check the manifest syntax. This will save you a lot of useless commits. If you use a more complicated puppet setup using environments (I'm not there yet, and I don't think my setup will evolve in that direction in the near future), you can use puppet-sync that seems a neat script to do the job. For the moment this setup works pretty well. I'm tempted to explore mcollective to trigger puppet runs on my nodes, but I'm there yet...

25 May 2012

Matthew Garrett: Fedora 17 and Mac support

Fedora 17 will be shipping next week. It's got a bunch of new features, none of which I contributed to in the slightest. What I did work on was improving our support for installation on x86 Apple hardware. There's still a few shortcomings in this so it's not an announced or supported feature, but it's sufficient progress that it's worth writing about.

There's a few ways that Apple platforms differs from normal PC hardware. The first is that Apples are very much intended to be EFI first and BIOS second, while that's still not really true for commodity PC hardware. Apple launched Boot Camp shortly after they started shipping x86 Macs (and shortly after I'd got Ubuntu running on one for the first time[1]) but the focus of Boot Camp has always been to be good enough to boot Windows and not much else[2]. The other is the integration with the boot environment. You can boot Linux easily enough by setting the standard EFI boot variables, but if you ever boot back into OS X it's easy to trigger deletion of those. There's then no straightforward way of resetting them, and you're left having to recover your installation.

The other difficult bit has been actually starting the installer at all. If you're happy to use BIOS emulation than this can be done without too much misery, but you're then left with dealing with Apple's custom synchronised GPT/MBR. More modern Macs will boot via the standard EFI mechanisms, but there's a range of problems that can be caused that way. Fedora 17 is the first Linux distribution to ship install media that will EFI boot a Mac when either written to optical media or a USB stick[3]. Put the install media in your system and then either select it in the OS X Startup Disk preferences menu and reboot, or reboot and hold down the alt key. In the latter case there'll be a nice Fedora logo. Click on it and it'll boot.

The biggest difference between Apple hardware and anyone else is that we'd normally put the bootloader in a FAT partition that's shared with any other installed operating systems. That does actually work on Apples, but then you run into the earlier point I mentioned. The Apple startup picker that you get by holding down the alt key doesn't pay any attention to the standard EFI boot variables, so it won't show a FAT partition merely because it's got an EFI bootloader on it. The same is true of the OS X Startup Disk preferences. The best way to get a drive to appear in the menu is to make it look like an OS X drive.

This was problematic in a few ways, due to the requirement for an OS X drive to be HFS+. The first was that we didn't have any support for that in our installer, so work had to be done there. The second was that the state of HFS+ was woefully poor in Linux[4]. Linux will refuse to write to an HFS+ filesystem if it hasn't been cleanly unmounted or fscked, and since we can't rely on everyone always shutting their machine down cleanly that means a working fsck.hfsplus. In theory we were shipping one of those. In practice, it reliably segfaulted on 64-bit systems[5]. So I had to package the latest version of Apple's code, and doing that involved dealing with the fact that Apple now use blocks almost as much as Grub 2 uses nested functions, and that meant using Clang and that meant dealing with a bug where Clang segfaulted if it had been built with gcc 4.7[6], but finally once all of those yaks had been shaven we could trust our filesystem.

Of course, more problems existed. You can't just drop a bootloader onto an HFS+ partition and expect it to work. You need to write its inode value into the superblock. Trivial, except that if you do this from userspace then the kernel kindly overwrites your update when you unmount the disk and it updates the superblock. That required a mechanism for updating that data via the kernel, which meant adding an ioctl. This would have been fine, except the OS X Startup Disk preference looks for a bootloader in a location other than where Fedora installs it. Changing our bootloader install path wasn't a great option, so the easiest thing to do was just to link them together. Except HFS+ doesn't really support hardlinks. When you hardlink something the original file gets moved into a magic directory in the filesystem root and the links are special files that refer to it. And it turns out that it's not actually the inode that the firmware wants when finding the bootloader, it's the catalogue ID, and these aren't the same when hardlinks are involved. So, another kernel patch.

All that was left for the boot partition then was adding an icon and a drive label. We already had code for generating the icon, and the drive label wasn't that difficult. Hurrah!

Ok, so we can construct a filesystem that (a) appears in the bootpicker, and (b) appears in the OS X Startup Disk preferences. We can even put a bootloader on it. This led to the next problem. The bootloader started without any trouble. But the bootloader couldn't read any files off the boot partition, including its configuration. This should have been obvious with hindsight - the problem was simply that grub legacy[7] doesn't support HFS+. Writing an HFS+ driver seemed like an excessive amount of work, especially since the firmware already supported reading HFS+, so instead I wrote a simple grub filesystem driver that uses the UEFI interfaces to read files.

A working bootloader! One more problem there. grub looks in its startup directory to find its configuration file. We have two "copies" of grub hardlinked to each other, each looking in a different directory for configuration. Hardlinking the config files together worked fine, except that most tools that update config files have this irritating habit of writing to a temporary file and moving that over the original, thus breaking the hardlink. Easily solved by using a symlink instead, except that the UEFI filesystem semantics don't really support symlinks because UEFI only really envisaged using FAT. If you use Apple's UEFI HFS+ driver to open a symlink, you get a short file containing the target path of the symlink. Rather less than ideal, and a rather gross hack to cope with it.

All set now, other than a bug in some older Mac firmware where read would return BUFFER_TOO_SMALL without returning the real buffersize and the odd way that Apple treat CDs. Oh, and a bug in Apple's Broadcom wifi driver that could overwrite the kernel, and case-sensitivity, something that obviously isn't something you often hit on UEFI when all you usually see is FAT.

Kernel-side, we had a couple of things. Obviously there the bugs I'd mentioned in the past, but those had already been dealt with. New issues included the fact that we were frequently picking the wrong framebuffer address, especially on machines with multiple GPUs. Fixed now, along with another issue where we'd sometimes get confused by models with different GPU configurations. And at that point, most of the implementation work was done.

Of course, there was also the work of integrating this into the tools that we use to generate our install media, and I'd like to thank Will Woods, Brian Lane and Dennis Gilmore for the work they put into that, along with anyone I've forgotten. Tom Calloway handled getting the device label graphics generated right before deadline. A cast of thousands helped with testing.

So why did I mention shortcomings? First, this only works on machines with 64-bit firmware. Early 64-bit Apples still had 32-bit firmware. In theory we can support that case - in practice it's a moderate amount of writing, including some mildly awkward kernel code. But anything later than mid-2007 should have 64-bit firmware, so it's not a massive concern. Second, we seem to have fairly significant trouble with Radeon hardware on a lot of Macs. We fixed one bug there, but something's still going wrong in setup and you'll frequently end up with a black screen. And thirdly, I'm sure there's some other machines that still don't work for (as yet) undetermined reasons.

With luck we'll get these things dealt with by Fedora 18. But even with these flaws, Fedora 17 will work fine on a lot of Apple hardware, and testing it is as simple as downloading and booting a live image. Bugs go in the usual place.

[1] Note my charming belief that the Ubuntu installer would fully support this hardware via EFI in the near future. 6 years ago. It still doesn't.
[2] This can be fairly easily seen from little things like the name "Windows" being hardcoded into every UI that sees a Boot Camp drive.
[3] I cover this in more depth here
[4] To be fair, it mostly still is - there's plenty of work to be done there.
[5] Approximately nobody had noticed this, which is all kinds of unreassuring.
[6] Thanks to Kalev Lember for dealing with that
[7] Still the EFI bootloader in Fedora 17. We've already swapped Fedora 18 over to grub 2.

comment count unavailable comments

22 May 2012

Matthew Garrett: I've been a terrible person (and so have most of you)

John Scalzi recently wrote a piece on straight white male privilege. If you haven't read it already, go and do so. No rush. I'll wait.

So. Some facts:

(If you disagree with any of these then that's absolutely your right. You're wrong, but that's ok. But please do me a favour and stop reading here. Otherwise you'll just get angry and then you'll write something ill-tempered and still wrong in the comments and then I'll have to delete it and why not just save everybody the time and effort and go and eat ice cream or something instead)

I know I've said this before, but inappropriate and marginalising behaviour is rife in our community, and at all levels of our community. There's the time an open source evangelist just flat out told a woman that her experiences didn't match his so she must be an outlier. There's the time a leading kernel developer said that most rape statistics were basically made up. There's the time that I said the most useful thing Debian could do with its money would be to buy prostitutes for its developers, simultaneously sexualising the discussion, implying that Debian developers were all straight men and casting sex workers as property. These aren't the exceptions. It's endemic. Almost all of us have been part of the problem, and in doing so we've contributed to an environment that has at best driven away capable contributors. You probably don't want to know what it's done at worst.

But what people have done in the past isn't important. What's important is how we behave in the future. If you're not angry about social injustice like this then you're doing it wrong. If you're reading this then there's a pretty high probability that you're a white male. So, it's great that you're angry. You should be! As a straight white male born into a fairly well-off family, a native English speaker in an English speaking country, I have plenty of time to be angry before going back to my nice apartment and living my almost entirely discrimination-free life. So if it makes me angry, I have absolutely no way of comprehending how angry it must make the people who actually have to live with this shit on a daily basis.


(Were tampon mouse able to form and express coherent thoughts, tampon mouse would not put up with this shit)

The point isn't to be smugly self aware of our own shortcomings and the shortcomings of others. The point is to actually do something about it. If you're not already devoting some amount of your resources to improving fairness in the world, then why not? It doesn't have to be about women in technology - if you're already donating to charity or helping out at schools or engaging in local politics or any of the countless other ways an individual can help make the world a better place, large or small, then keep on doing that. But do consider that many of us have done things in the past that contributed to the alienation of an astounding number of potential community members, and if you can then please do do something to make up for it. It might be donating to groups like The Ada Initiative. It might be mentoring students for projects like the GNOME Outreach Program for Women, or working to create similar programs. Even just making our communities less toxic by pointing out unacceptable behaviour when you see it makes a huge difference.

But most importantly, be aware that it was people like me who were responsible for this problem in the first place and people like me who need to take responsibility for solving it. We can't demand the victims do that for us.

comment count unavailable comments

21 May 2012

Thomas Goirand: Unit tests for PHP: PHPUnit

PHPUnit, according to its PTS, has been in Debian since 2009. But it was orphaned, and nobody took care of it for a while. That is until few weeks ago, Luis Uribe started to work on it. Since he isn t a DD, and that I take care of, I believe, about half of the all the PHP PEAR packages in Debian, I started working with him on re-doing the work of packaging PHPUnit for Debian. Previously, the old version was quite wrong, with missing dependencies, and not really working, what a shame PHPUnit 3.6 has been in Debian SID for 3 days now. And it s working well. I m now adding runs of unit testings from upstream packages at build time (of course, only if DEB_BUILD_OPTIONS doesn t contains nocheck , as per the policy). All together, it s been quite some fun to hack this, and I m quite happy of the results, even though there s still a lot of work remaining. PHP itself is running unit tests at build time. And not just a few: more than 11000 of them. The only small issue, is that they are totally outdated. Over the time, the vardump() function has evolved, and doesn t print things the same way. One may say that it prints things in a nicer way, but as a result, many of the tests that were suppose to work, actually fails because of these differences in vardump() over time. So I started working on fixing some of the tests. It s most of the time very easy to fix, but it takes a long time to fix all these small unit tests. So far, I ve been able to fix most of what s in the tests/, Zend/tests (more than 161 tests fixed), and the beginning of ext/*/tests: for the moment: bcmath, bz2, calendar, curl, date, dba, dom, ereg, and a part of exif, which for the moment represent 214 fixed tests, and I ll try to do more fixes when I have time. I hope to send the patches upstream soon. The final goal is of course to have the build of PHP to fail if unit tests are failing as well. For the moment, unit tests do run at build time, but the build don t care of the results, which I think is stupid (it s wasting CPU cycles for no reasons, IMO). If you maintain some PEAR packages, I would welcome you to first join the PKG-PEAR team on Alioth, and team maintain your packages, switch over to pkg-php-tools and dh 8 auto-sequencer, and to follow the PKG-PHP-PEAR packaging guide lines so that we have consistency in the archive. And of course, run unit testings, by doing a build-depends on phpunit (>= 3.6). Note that unit testings in PEAR packages are tracked on the Debian wiki. This post is also a call for help, because I feel quite alone doing this work of packaging PEAR packages, which many PHP applications depend on (think about roundcube, horde, extplorer, and many more). Other teams are doing very well, like the Perl team, and there s no reason why Debian wouldn t maintain PHP libraries as well as the ones for Perl.

20 May 2012

Gregor Herrmann: RC bugs 2012/20

I was on vacations for a few days last week, therefor my list of RC bugs is a bit shorter this time. thanks again to everyone who sent patches to the BTS that I could just use.

19 May 2012

Thorsten Glaser: MirBSD goes webservice manpages and WTF

While wtf(1) always has been a bit central to MirBSD, and the acronym database has been accessible by CVSweb, what we never had was a DAU compatible (and shellsnippets compatible) lookup. This has now changed: the above link to the acronyms file is a persistent link to its latest version (well, latest when the website was last recompiled), tooltips may very well follow soon, and we ve got an online WTF lookup service.
Contributions to the acronym database are welcome, of course; just eMail them to tg mirbsd org. Not to stop there, our online HTML manpage search is also new, shiny, and should replace the !mbsdman DuckDuckGo hash-bang shortly. (Both of these services offer a DDG search as fallback. Note that DDG is an external service included herein by linking, under their request to spread it, and not affiliated with The MirOS Project. They do, however, donate some advertising money to Debian.)
For all those who didn t know: only manpages for software in the MirOS BSD base system and for the MirPorts Framework package tools are listed, not for third-party applications installable using ports or, recently, pkgsrc . Still, if you want to have a peek at a modern classic BSD s documentation, you re welcome. (Not to mention content like re_format(7) and style(9) and that some of our documentation is much more legible than others.) And because writing all that perl(1) made me ill, not to mention I don t even know that language, I ve hacked a bit more in the mir make(1) and mksh(1) parts of the MirWebsite, finally implementing pointing out where in the navigation sidebar the visitor currently is. We also have exciting mksh porting news involving RT trying a larger number of ancient platforms than I dare count, me fixing bugs in Linux klibc and diving into other things, learning more about why I consider me lucky for hacking a BSD operating system sorry, I want to keep this short as it s mostly an announcement. The MirWebsite source code is, of course, also available. Improvements welcome. Except for these three CGIs, our website is fully statically precompiled, and that s a good thing. Please help in making the CGIs secure.

Andrew Pollock: [life] Maker Faire 2012 trip report

The Maker Faire is one of those awesome Bay Area things that always fills me with excitement and gets my imagination going. Zoe and I went again this year to check it out, as best we could within the time constraints we had to work within (opening time and her nap time, minus travel time). She definitely enjoyed herself. We took the Caltrain, because historically driving and parking has been a bit of a nightmare. The optimal train to get to get there before it opened (at 10am) was the 9:19 train from Mountain View, which was scheduled to get in at Hayward Park a little before 10am. It just so happened that there was a Giants game on in San Francisco today as well, and the train was absolutely packed. We only got a seat because one kind gentleman was getting off and explicitly gave his seat to us. One lesson learned: don't try and take the BOB stroller on the train. Even when collapsed, it's way too bulky. For future Caltrain outings, I'll take our City Mini stroller instead, as it folds much flatter. I also took our macpac Possum child carrier backpack, and Zoe was pretty happy to just sit in it for the bulk of the time. I think it had novelty value for her, as we haven't used it for a while. I probably could have gotten away without taking a stroller at all. I was very glad I took the backpack, as it gave her a much better vantage point for everything that was going on than she would have gotten from sitting in the stroller. There was supposed to be a free shuttle from the Hayward Park station to the Maker Faire, but there was a huge crowd waiting for it, so I decided to just walk. It didn't take too long. For the return trip, I think I exited from the wrong side of the fairgrounds, and couldn't figure out the shuttles, so I just walked to Hillsdale station. At least the return train wasn't crowded. Overall, using Caltrain to get in and out was successful. Zoe was very well behaved for the ~30 minute train ride each way. The Faire was quite a bit bigger this year, and has spilled out into the parking lot on one side. I'd heard stories that O'Reilly had quadrupled booth prices as well. Trying to abide by the program was too difficult, so we mostly just wandered through the main Expo hall and looked at various booths. I just did a full read through the website of all the exhibitors to see what I missed out on. Here's some of the stuff I saw in person, or discovered via the website: Kickstarter is really becoming huge in the maker community. There were heaps of exhibitors there with (mostly robotics) projects that were past the initial prototyping phase and were seeking funding on Kickstarter to go into mass production. Some of the talks I'd have liked to have seen: Zoe was really well behaved for the entire expedition. I don't think she really gave me any grief at all. There was a brief period where she wanted me to carry her, but I managed to negotiate her back into the stroller after not long. I think her favourite was ArcBotics, which had a robot insect that would dance and wave at her. She kept asking for it to do more dancing.

30 April 2012

Lior Kaplan: Taking a vacation from open source

In the last 6 months I ve devoted a lot of time to the open source projects I m part of. I decided to take a vacation from most of the open source stuff I do. This is mainly to balance things better and make sure I don t feel burnt out. I m not disappearing completely, but rather shifting into a lower gear and focus on the things I enjoy most regarding open source.
Filed under: Debian GNU/Linux, LibreOffice

Next.

Previous.