Search Results: "will"

9 October 2012

David Welton: Fast, Light and Asynchronous

I am a big fan of Ruby on Rails: it does a lot of things, and it does most of them pretty well. When starting a new web project, it's the first thing I would reach for: most of the time, your problem is going to be figuring out a good product/market fit, or whipping up some internal tool without wasting a lot of programmer time. Once you've got a firm grasp of the problem, then maybe you can consider optimizing. Who cares if you do something that no one wants really really fast? However, Ruby on Rails is not beautiful in terms of being particularly fast or lightweight. No complaints from me: most of the time, I'm happy to have something that does so much for me, leaving me to work on the actual problem at hand. Once in a while, though, you do need fast and relatively lightweight, and that space has been getting more interesting over the past few years, at least in terms of the web. First of all, technologies like "Comet", utilizing web sockets or some other always-on connection are becoming more common, where a socket with the server remains open in order to quickly exchange data from the server to the client - and back. That seems to be a poor fit for something like Rails, where it can tie up a lot of resources if one isn't careful. And while computing costs continue to decline, no one minds getting more for less in terms of what their server can do. Furthermore, with frameworks like Backbone.js, pushing more and more code to the client, the server can afford to be a bit simpler and do less, so it may as well be snappy to boot. Java has long been fairly popular for "heavy lifting" types of applications, partially because it does end up being reasonably fast. But it's not something I've ever had much fun using and is usually kind of wordy, and makes you feel like you need a crew of people in Palo Alto, one in Bangalore, and one in Stockholm just to churn out all the code. And it certainly is no lightweight in terms of memory either. So... while it can certainly do pretty much anything you need, I don't see it as being the strongest player when someone needs "real time web" code, and needs it to be reasonably light weight. Ruby, outside of standard Rails stuff like Passenger, seems to offer some interesting possibilities for this kind of work, like Reel but they don't seem to have the traction other solutions do. Python is in a similar situation: the Twisted framework has been around for a while, and while it has some success stories, never seems to have really 'caught fire'. Neither of these languages was built for "concurrency" from the ground up, and that seems to have, to date, inhibited people from using them extensively for this kind of job. My gut feeling is that the need for speed and "concurrency" (or at least handling a lot of concurrent users) will drive adoption of languages heretofore not so popular on the server. Let's have a look at them. Erlang: This is by no means a new language, having been developed in Ericsson in the late 1980ies; and it implements several interesting concepts. First and foremost, concurrency is handled in the form of many small "processes", which are not actually Unix processes at all, but processes internal to the Erlang VM. The Erlang system contains a scheduler that allocates resources to all of these processes, so even if one of them dies or behaves badly, it's not a problem: the system as a whole can continue to function well. The way Erlang is built, the scheduler is preemptive: the internal "processes" don't need to yield to let other processes run. Beyond the scheduler and simple processes, Erlang gives you the tools to create elaborate trees of supervisors and workers that are quite robust to failures in any one portion of the system, as well as giving you the tools to set up a system to run on multiple, distributed computers. This kind of thinking is necessary when you write applications, such as phone switches, where downtime is really, really not ok. Erlang processes comunicate almost exclusively via message passing, meaning that state is not shared. Altogether, this makes for a fast, rock solid system that can easily handle thousands of concurrent connections without breaking a sweat. The computing world being what it is though, Erlang is likely to be more of a Lisp or Smalltalk: it's a trailblazer that did many things years before their time in other languages, but I don't see it as ever quite catching on amongst 'the masses'. It has a wonky syntax, it's a functional programming language, and because it is used in environments where too much experimentation is not good, it does not have a lot of room to break with its own past and innovate in terms of the language itself: it's slow to change and improve, even where the need to is clearly perceived. Node.js: is the opposite, in some ways: being based on Javascript, it draws on a huge number of potential programmers - orders of magnitude more than Erlang. And thanks to design decisions enforcing the use of asynchronous code and callbacks for anything that could block, it deals quite well with concurrent connections, even if the language and libraries don't really give you much in terms of "true" concurrency. This is a simple model that works pretty well, even if, theoretically, all it would take is one "while (1)" loop in a callback to block the entire system. In practice, this doesn't seem to be a big problem, though. More of a problem is writing maintainable code, when everything is a callback. Keeping the network of callbacks straight can be a bit of a chore, and is probably not an optimal model in terms of programmer productivity. That said, people seem to do make due with it, although Node is young enough that we haven't seem projects that are 5 or 6 years old and maintained by people who didn't write them. One of the advantages of being such a popular language is that lots of people have a strong interest in seeing Javascript being very, very performant. That need begat the V8 Javascript engine, from Google, which they were kind enough to release as free software. So one of the advantages that Node has is that the underlying implementation is extremely fast for a dynamic language. For many people who know Javascript, picking up Node.js is also an easy choice, even though people used to browser side programming with Javascript will have to adjust their way of thinking to succesfully tackle server projects. Go language: this is an interesting one, written by some luminaries who work at Google. It can best be described as something akin to C with some updated features, such as garbage collection, that make it more suitable for working on large projects, where things like memory leaks are going to make life very frustrating. It has the feel of a "real language, for real programmers" in that it doesn't stray far too far from what people are used to - it's not going to cause the "what the hell is this?!" reactions that Erlang might in more close-minded circles. Between the big company backing it, and the approachable syntax and concepts, Go looks like it has a good shot at the mainstream. Where it gets interesting is their concurrency model, which is apparently based on something called "communicating sequential processes" which, superficially at least, looks like it has some things in common with Erlang's "actor model" of concurrency. Under the hood, Go apparently hives off its "goroutines" to different OS level threads, but does not have a preemptive scheduler like Erlang: http://code.google.com/p/go/issues/detail?id=543 - although according to this, they may change that in the future. I'm not enough of a computer science guy to comment much on the details of CSP vs Actors, but both seem like valid models with strengths compared to trying to keep threads straight, which always seems to be a source of problems for programmers. Conclusions So, what's actually going to happen? I see Node.js as the clear front runner. It takes a worse-is-better approach that seems to work well enough as people get started. If they encounter difficulties later, they can always rewrite in something else, if needs be, but by "luring people in", Node.js has gathered a large group of users who continue, in turn, to churn out more code for use with the system, making it more attractive to new users. Programming languages are not winner-take-all markets though, so perhaps there is room for a few more languages to have decent followings in this space. Hopefully the competition will lead to ever better tools for those of us utilizing them! What do you think?

Stefano Zacchiroli: bits from the DPL for September 2012

Just posted to d-d-a, bits from the DPL for Septemer 2012.
Heya,
here is the periodic report of DPL activities, this time related to September 2012 (posted here with some delay, as I've been traveling oversea on behalf of Debian for the past few days). Help needed: Google Code-In The Google Code-In (GCI) initiative is about to start again. We don't have a great track record of participating into it, and that's a pity. The initiative revolves around small tasks that other Free Software projects have come to call "easy hacks", showing how effective they're in attracting new volunteers. To participate, we need both mentors and admins. If you're interested see Ana's call for help and please volunteer on the soc-coordination list. Related to this, you've probably seen the report of our participation in GSoC 2012. I'd like to thank all students, mentors, and admins for a very well organized edition. Logo relicensing & other assets The DFSG-relicensing of the Debian logo, which I've mentioned in recent updates, has now happened. The so called Debian "Open Use" logo, in both variants (with and without "Debian") is now dually licensed under LGPL3+ / CC-BY-SA 3.0. The change has been made effective with a resolution of the SPI Board of Directors. Note that the so called "official" logo, which we seem to use very little, is still released under the terms of a non-free license. Discussion is ongoing on -project to stop promoting it. If you're using it or if you've arguments in favor of against that, please participate in the discussion. I've got from SFLC an updated draft of the new proposed trademark policy, implementing most of the changes requested during related August discussions on -project. I'll post it for review there shortly. The Japanese Trademark Office (JPO) has sent us the final confirmation that trademark transfer request (from individuals Debian contributors in the area to SPI) has happened. We've paid the needed fee of 457 CHF to conclude the transaction. We finally settled a domain transfer agreement with the current owner of the debian.eu. Technically, the domain will be transferred to FFIS in the coming weeks. Core teams (non-)news Quite some core teams are in the process of changing their formations these weeks, but most are still pending proper delegation (or equivalent). So here are just a few "teasers": I hope to finalize all the pending tasks above this month. Future events I've spent quite some time to plan my participation in events I'll be attending during October on behalf of Debian, such as the ACM Reflections conference in Urbana-Champaign (at the time of writing, this has already happened), the Ubuntu Developer Summit in Copenhagen, and the LinuxDay event in Turin. Cheers.
PS the day-to-day activity log for September 2012 is available at the usual place master:/srv/leader/news/bits-from-the-DPL.txt.201209

Christian Perrier: Bug #690000

(doh, I nearly had it. I just got #690019, #690020 and #690022 for l10n stuff) Bartek Krawczyk reported Debian bug #690000 on Monday October 8th, against guake. And my friend Sylvestre Ledru, the package maintainer, now has to fix it instead of trying to promote the use of Scilab over proprietary alternatives in the French aerospace research organizations..:-) Bug #680000 was reported as of July 2nd: 3 months and 8 days for 10,000 bugs. This is a VERY significant drop in the bug reporting rate in Debian. Last time, I wrote: "How will the wheezy freeze affect this? We'll see in two months!". We have the answer: the wheezy freeze triggerred an important drop in bug reporting rate in Debian. My general feeling is somehow different: for whatever reason, I feel like the *overall* activity in the project has dropped significantly. I seem to have less mails to read, less bugs reported against my packages, even less heated discussions here and there, as well as several very quiet channels on IRC. Am I pessimistic when feeling that the overall momentum is sliding out of Debian? Maybe I am, so, folks, please make me optimistic and move you fingers out of the place where they are and help releasing that damn penguin. Apart from that, our next milestone (apart from the wheezy release!) will be bug #700000. Remember the bet?. It looks like the probability of Kartik Mistry winning it is now away (he bet for Now 8th 2012) and the best position is hel by David Pr vot (he bet for December 12th). On the other hand, my own chances are increasing if the bug rate drop is confirmed and if bug #700000 is reported in more than 3 months (I bet for February 14th 2013, guess why?). We'll see that in a few weeks!

8 October 2012

Eddy Petrișor: HOWTO fix git-buildpackage signs with wrong signature

If you have two or more available gpg keys that can be used for the same identity (e.g.: 'John Doe <john@doe.com>') that you might use to add entries to changelogs of packages, you might end up in situations where git-buildpackage or other similar tool might want to sign packages with the wrong key.

It seems debsign (the tool that actually does the signing) just picks up the first key that is still valid (I also have a revoked key) and matches the used identity.

There are many ways to fix this, but the one that will work for most cases is to run this command:

echo 'DEBSIGN_KEYID=0x0123ABCD' >> ~/.devscripts

Of course, you should replace 0x0123ABCD with the keyid which you prefer.

This will create a ~/.devscripts file (if it didn't exist) which will contain the DEBSIGN_KEY variable with the desired value. This file will be sourced by debsign before doing its actual work, so it will do the right thing when ran.

There are also git-buildpackage specific fixes like defining builder in the [DEFAULT] section of ~/.gbp.conf and passing '-k0x0123ABCD' to debuild something like:

[DEFAULT]
builder = debuild -i -I -k1234ABCD
...

But that probably gets ugly if you use a custom builder.


P.S.: I have just deleted my old key 0xDD1F1F9F since I won't be using it anymore. I don't remember where I put the revocation certificate, but I'll revoke the key, once and if I find the revocation certificate. Otherwise, it will expire in July, next year.

From now on, I am going to use only the key 0xE3E083A1 to which I even added a photo and some newer identities and updated with a few signatures I got during DebConf 9.

Rudy Godoy: MySQL data enconding conversion latin1 utf8

I was about to post a different story but things turned out differently, for good. Now I ll post tips that may save the day in the event of encoding issues when dealing with MySQL table data. Hopefully you find it useful. Say you have a MySQL table that has collation set to latin1 but you have utf8-encoded data stored. This happened when importing a dump, or because of Murphy s law. When querying the data from your application or from mysql s tools you get awful results for non-ascii characters such tildes. Changing the table s collation definition will only work for new columns and records. Altering the collation for the said column would make things worse. So what to do? Fortunately MySQL offers a nice way to save the day. You can use a transition conversion and then set the table encoding back to utf8, so it pairs accordingly with the encoding type for the data it has stored. ALTER TABLE table_name CHANGE column_name column_name BLOB; Issuing the previous command will make the table change it s type to BLOB. Why? Because by doing it the stored data is kept untouched. This is important. If you use the CONVERT or MODIFY commands the data will be converted by MySQL. We don t want that since the data is already in the encoding type we want. You can note that column_name is repeated twice, this is because the CHANGE command copies the data and we want the resulting column to have the same name. Now, we have to put the data back on the encoding we want, so everything is under control again. This is done by issuing the following command. ALTER TABLE table_name CHANGE column_name column_name COLUMN_TYPE CHARACTER SET utf8; COLUMN_TYPE depends on the content s column type. For instance, for a TEXT column it should be. ALTER TABLE table_name CHANGE column_name column_name TEXT CHARACTER SET utf8; It works for VARCHAR, LONGTEXT and other data types that are used to store characters.

Craig Small: NTP control messages

I have had an opportunity to rework some code to query NTP servers directly in python rather than running ntpq -pn and scraping the result. The over-the-wire protocol format is reasonably straight forward and my little module is now passing all of its nosetests which is wonderful. While its only a single table, ntpq actually does multiple requests to get its results. NTP control messages are all mode 6 which tells the client and server its not time sort of things, but more about queries. A control packet has a sequence number which the server responds with so you can line up your requests with responses. For large responses, the more, offset and count fields work together to knit up a large block of data. The first packet of the response will have the offset field of 0. The count is the size of the data payload in bytes. If the response is too big, the more bit will be set to 1 to say there is more coming. The second packet will have an offset that is the same value as the previous packets count value, so you can stitch them together. The first query is a READSTAT which uses opcode 1. This returns a list of 4 byte responses with the association ID taking the first two bytes and the peer status taking the second. If you look at the output of ntpq you will notice a character in the first column which is the peer selection. The important one for us is asterix, which equates to 110 in the lower 3 bits of the first status byte. This is the system peer which is the main one. There may be others, up to 2, (usually symbol +) which are compared to the system peer. ntpq doesn t really care about the different peers and just displays the status but I want to know what peer the server is synchronised to. Next we need more details about the system peer (or all peers in ntpq). To do this a READVAR or opcode 2 is sent to the server. The association ID is set to the association or peer we are interested in. The response for my setup is sent over two packets which need to be reassembled and it is all in plain ascii which is a comma-separated list with a key=value pair. I use the following python line to split it up.
self.assoc_data.update(dict([tuple(ad.strip().split("=")) for ad in data[header_len:].split(",") if ad.find("=") &gt; -1]))
I m sure people that know python better than I will say I am doing it wrong (it looks a bit klunky to me too) but it does work. From that I can query the various values that are returned by the server about its peers, including the source of its clock.

Jonathan McDowell: KVM + usbmon + Wireshark == win

(This is something I did a few months ago, and I really should have noted down all the details then so I covered everything. However hopefully these notes will remind me enough next time.) When I first wanted to reverse engineer a USB device that only had Windows drivers the "easy" option was to take a Windows machine, install usbsnoop on it and capture the traffic as a bunch of verbose text files. It was a cumbersome procedure. Recently I wanted to do a firmware upgrade of a ZTE 3G modem dongle, partly to provider unlock it and partly to try and enable some voice functionality. I was also hoping to sniff the traffic to see how to drive the voice side of things. These days I don't have a dedicated Windows box, but I do have a Windows 7 KVM virtual machine. I hadn't yet used the USB support in this, but I thought I'd see what it was capable of. Firstly I had to explicitly enable USB2 - the device wasn't happy with the default USB1 only stack that KVM enabled. That involved passing -usb -device usb-ehci,id=ehci to KVM. I also told KVM to grab all the ZTE devices with -device usb-host,bus=ehci.0,vendorid=0x19d2. I dropped a udev rules file into /etc/udev/rules.d to ensure any device nodes created belonged to my normal user. This gave me a Windows setup that could see the USB dongle and install the appropriate drivers. It was also happy to do the firmware update (along with various device resets on the way as it changed USB ID - this is why I needed the udev rule, to ensure every time the device re-appeared it would be seen by the KVM instance without manual intervention). After that was complete I investigated usbmon. modprobe usbmon created the appropriate /dev/usbmon<n> files and I chowned the appropriate bus to my normal user. Once this was done I was able to start Wireshark which rather nicely has full USB decoding support. Firing up the custom app in the Windows KVM guest I could see the traffic going back and forth to each of the device endpoints and work out what was going on. All of this was much more flexible than using a standalone Windows box. Once I figured out that I needed to explicitly enable USB2 I was quite pleased with how simple USB access under KVM was. I also used lvm to create a snapshot of the Windows guest so at the end I could roll back all of the drivers I'd installed for the dongle. And being able to use Wireshark instead of trawling through dense text files helped a lot in seeing the command stream.

7 October 2012

Matthew Garrett: Handling UEFI Secure Boot in smaller distributions

The plan for supporting UEFI Secure Boot in Fedora is still pretty much as originally planned, but it's dependent upon building a binary which has the Fedora key embedded, and then getting that binary signed by Microsoft. Easy enough for us to do, but not necessarily practical for smaller distributions. There's a few possible solutions for them.


I've taken Suse's code for key management and merged it into my own shim tree with a few changes. The significant difference is a second stage bootloader signed with an untrusted key will cause a UI to appear, rather than simply refusing to boot. This will permit the user to then navigate the available filesystems, choose a key and indicate that they want to enrol it. From then on, the bootloader will trust binaries signed with that key.

Distributions are then able to take an existing signed copy of shim and put it on their install media, along with a file containing their key. If a user attempts to boot then the boot will fail because the second stage bootloader isn't signed with a trusted key, but the user can then use the navigator and select the distribution's key file. After providing confirmation and rebooting, the second stage bootloader's signature will now be recognised and the installer will boot.

This has the advantage over the first two options that the UI is consistent, making it easier to document the install process. The primary disadvantage is that the distribution won't be able to rebuild shim and will have to ship a pre-compiled binary. This may well be unacceptable to distributions like Debian, but should still provide a viable approach for other distributions who are either unwilling or unable to deal with Microsoft themselves.

comment count unavailable comments

Charles Plessy: Gathering metadata with Umegaya.

A Debian package contains some metadata about the packaged program. For instance, its homepage URL is stored in the source package control file (debian/control) and propagated through the Debian source control file (.dsc). The problem with this approach is that to update the metadata, one has to update the whole package. Today, thousands of Debian source packages are developed in a version control system, most often Subversion or Git. The repository's URL is also propagated through the control files mentioned above. It is then possible to monitor the main branch to detect and propagate changes without needing to upload to the Debian archive. In 2009, I proposed to centralise metadata about Upstream in a YAML-formatted file, debian/upstream. We are now using it in the Debian Med project to propagate bibliographic references about the manuscripts describing the packaged programs. The references can be seen on our web sentinels for our metapackages. The data transits through the Ultimate Debian Database (UDD). Let's imagine that the concept gains success and that thousands of packages provide a debian/upstream file. How can we avoid thousands of daily requests on Alioth to keep the database up to date ? I am developing a system called Umegaya, for Umegaya is a MEtadata GAtherer using YAml. Umegaya provides a web interface with a simple URL structure to retrieve data. For instance, http://upstream-metadata.debian.net/emboss/reference-year returns 2000, the year where the first scientific article describing EMBOSS was published. If at the time of retrieval, the previous update was older than one hour, the system will read the package's debian/upstream file again. It is therefore by reading the data that it is kept up to date. Conversely, to update the database after modifying debian/upstream, one just has to access it. Umegaya is still a draft, and many things may change. But the service is already up for more than a year at the address upstream-metadata.debian.net. It is used to fill the Subversion repository called packages-metadata, with gathers the debian/upstream, debian/control and debian/copyright files from recently uploaded packages (since a few months). One can see there that among the 3,646 copyright files, 1,218 declare themselves conformant to the machine-readable format 1.0. Because I like a lot the principle package what you use, use what you package, umegaya entered the Debian archive a few days ago.

Dominique Dumont: Dpkg source editor/checker is going native

Hello As Config::Model was becoming too big with too many dependencies, I ve moved all Debian stuff from Config::Model repository into a separate Debian repository. If you install only libconfig-model-perl 2.026-1 (from experimental), the command cme check dpkg will not work. You must also install libconfig-model-dpkg-perl to get it back. libconfig-model-dpkg-perl is currently in experimental. libconfig-model-dpkg-perl repository is hosted on Alioth in debian perl-packaging team and is a Debian native package. Nevertheless, it will be uploaded to CPAN. (just like dh-make-perl).
All people involved in packaging are welcome to hack it or suggest improvements I ll upload both packages into unstable once the dust settles. All the best
Tagged: config-model, debian, dpkg, Perl

6 October 2012

Matthew Garrett: The importance of trustworthy power structures

Direct harassment and overt sexism are certainly a significant part of why the gender ratios in the Linux community[1] are so skewed, but they're not the whole story. Part of feeling comfortable with a community is the knowledge that those in positions of power can be relied upon to engage in appropriate action when undesirable situations arise - no matter how compelling your code of conduct, no matter how detailed your diversity policy, if someone contravenes them and nothing happens, those documents are worthless and your community is unwelcoming. You can't rely on enforcement unless the community can trust its leadership.

Setting a good example in terms of behaviour is obviously vital, but it's not sufficient. Leaders who engage in sexist behaviour or who harass community members are clearly untrustworthy and undermine any attempts the rest of the community may be making. Failing to step in when they see examples of unacceptable behaviour is as bad. But less obvious is that it's possible to destroy that community trust without clearly contravening those community standards.

An example of this is Todd Akin, a candidate for the upcoming US Senate elections. In August he justified his support for making abortion illegal even in cases of rape, on the basis that women can't become pregnant through being victims of "legitimate rape". Of course, this had little to do with his fiscal or wider social policies, positions that are more directly relevant to most of his potential constituents, and in an election year that's primarily about the economy and healthcare it might be expected that a single issue would have little effect on the election standings. Instead, there was a huge uproar and a previously safe victory has now turned into a real chance of a loss.

Why? A significant part of it is because many people now have difficulty believing that they can trust him to represent them. If he understands women so little that he's willing to make entirely spurious justifications for his positions, how could any woman trust him to consider any other problems they may face? If he's willing to use fake science to back himself up, how could anyone trust him to consider any issue involving science? Through a single statement to a journalist he demonstrated to many that he was unsuited to be their representative in government. Many people who would otherwise have voted for him simply don't feel that they can rely on him to be there for them. Whether he wins his election or not, that distrust is going to remain and it's going to compromise his ability to work with his constituents.

It's the same in technical communities. If a member of a project's technical leadership frequently and loudly expresses their disdain for Python coders, anyone advocating for increased use of Python in that project is unlikely to feel that they can get unbiased opinions from that leader. If the project as a whole is uninterested in adopting Python then that's probably for the best, but if the rest of the project is open to using Python then there's a problem. People working with Python are less likely to join the project, and perhaps the project will lose out as a result.

But it's worth remembering that technical communities are still communities. If a member of a project's technical leadership vociferously argues that slavery benefited minority groups in the long run, members of those minority groups are going to feel that they're not going to be well represented by that leader. If they blog about how homosexuality is a lifestyle choice then homosexuals are unlikely to flock to the project. Likewise, if they downplay the prevalence or impact of rape, women are going to feel marginalised and find something better to do with their time.

It's impossible to separate these things. No matter how technically competent a community leader is, no matter how much code review they perform or how much mentorship they provide, if they're expressing unacceptable social opinions then they're diminishing the community. People I know and respect have left technical communities simply because people in positions of responsibility have engaged in this kind of behaviour without it causing them any problems.

We shouldn't be willing to give people a pass simply because they aren't actually groping anyone or because they're not members of the KKK. Those who drive people away from the community on the basis of race, gender or sexual orientation deserve vocal condemnation, and if they're unwilling to change their behaviour then the community should instead act to drive them away.

We're pretty bad at that in the Linux world at the moment. Too many people have behaved in this way and are left with positions of power or responsibility. There's no easy solution to the problem, but the Ada Initiative is continuing to work to improve awareness and work with communities to reduce the alienation that results from this kind of behaviour. If you want this to be anything other than a straight white male dominated community, you should give them money.

[1] (and computing in general, though to a lesser extent)

comment count unavailable comments

Tim Retout: Wedding

Today, Kate and I got married! Thank you to everyone who sent best wishes. A big wedding party will follow in the next 18 months or so (when we've saved some money!), to which many more people will be invited. This was the minimum viable subset of wedding - we got the product to market early, and both stakeholders are very satisfied. We had dinner at the Caribbean restaurant in town which is always busy - turns out there's a reason for that. They do these one-pot meals in enamel dishes, which tasted amazing. It is a strange new feeling to be a husband. :)

Christian Perrier: [life] Running update

It's been some time since I didn't write in this blog about my running activities. So let's make an update for my international friends. If you don't care about running, you can move to the next post in your feed reader..:-) After a quite busy running activity during DebConf 12 in Nicaragua, as well as during the touristic trip we did afterwards, I went back to my "regular" schedule. Main objectives in September-December are roughly the following: During August, I broke my monthly distance record by running nearly 300km in one month, even achieving 100km in only 5 days, around 24th. That was one of my goals: improve my overall resistance to run repetitions, which is one of the keys for ultra-running. These were achieved with many runs to/back work, with up to 13km in the morning and the same in the evening. Yes, running 26km at about 11km/h (and with some ups and downs in the woods to make it even worse) on a day where one has a normal work activity is quite a challenge. September has been more focused on marathon preparation. This time, no complicated plan with interval running as the month was also a very busy work month, where fitting training sessions during the day would be hard. So, I made an easy plan : run a half-marathon every Sunday and run part of my work-home commute every day (So, 3km run to the train station, 30mn train ride, then 4km run to my work place, then shower....and the same back after work). Out of the 5 half-marathons I ran during these 5 Sundays, two of them were official ones. On the first one, I finally managed to break my personal best on half, with 1h37'14". Only a 14 seconds improvement, but that one is certainly one of my best among personal bests....even better than 3h38'45" on marathon.. All other half-marathons were run at marathon speed, so targeting 5'06"/km, which will be my planned pace on October 21st. The one I ran on Sept. 16th, which was the other official race I ran was finally done quite significantly faster than this. First of all, because I had hard times to run "only" at 5'06"/km because of other runners emulation. And also, because I ran the last 3 kilometers up to nearly 14km/h (so, down to 4'15"/km), just for fun, because I could do it..:-) With all this preparation, I think that I now manage to very well manage my marathon speed. I'll probably do a final test tomorrow by trying to keep running at this speed for 3 rounds of my favourite "Maurepas Marathon" circuit, which is just exactly 1/4 of a marathon. More "funnily", I also did something I never did before during this really crazy month : simply said, I came back from work by running. All the way long. Through woods, forests, along some lakes and finally in the country. 42 kilometers (yes, a marathon). After a work day. Starting at 5:45pm and arriving home after 4h50 minutes. With 2 hours of heavy rain. With 2.5 hours running in the dark (with my headlamp of course). All alone. That was a crazy bet to do....but really great fun achieving this : the GPS trace is here. Really something I have to do again..:-) So, well, now I'm more or less prepared and having fun is just a matter for time..:-). I'll keep you guys posted with those and, guess what? I'm already picking my target races for next year..:-)

Andrea Veri: SSH Tunneling for VNC

Logging in into a Linux machine and executing the hundreds commands available is just one of the most common usages of OpenSSH. Another interesting and very useful usage is tunneling some specific (or even all) traffic from your local machine to an external machine you have access to. Today we ll analyze how to access a certain virtual machine s console by tunneling the relevant VNC port locally and accessing it through your favorite VNC client. The scenario:
  1. Machine A is our main virtualization machine and hosts several virtual machines. (VMs)
  2. Each VM has its own VNC port assigned. (usually the port range goes from 5900 to 5910 or even more if the hosted VMs are more than 10)
  3. We ll be using libvirt, thus virsh.
We first need to find out which port got assigned to the VM we want to have console access to:
sudo virsh
virsh # list
Id   Name   Status
----------------------------------------------------
5    foo    running
6    bar    running
7    foobar running
virsh # vncdisplay foobar
:3
We, then, create a tunnel which redirects all the traffic from the main virtualization machine s port to the port we gonna specify in the next command:
ssh -f -N -L 5910:localhost:5903 user@machine-A.com
A few details about the previous command:
  1. -N tells SSH to not execute any command after logging in.
  2. -f tells SSH to hide into the background just before the command gets executed.
  3. -L enables the port forwarding between the local (client) host and the host on the remote side.
And why did I choose respectively port 5903 and 5910? While you can adjust port 5910 with your own choice (that will just move the tunneled traffic from port 5910 to your favorite port), that won t work as expected with port 5903 since each VNC port is binded to the number of display virsh assigned to it. (for example, the bar VM may be running on display 5, thus its vncdisplay port will be 5905) When done, fire up your favorite VNC client and create a new connection with the following details:
Protocol: VNC - Virtual Network Computing
Server: localhost - 127.0.0.1
Port: 5910
The connection will load and you ll be put in front of your foobar VM console.

Andrea Veri: SSH Tunneling for VNC

Logging in into a Linux machine and executing the hundreds commands available is just one of the most common usages of OpenSSH. Another interesting and very useful usage is tunneling some specific (or even all) traffic from your local machine to an external machine you have access to. Today we ll analyze how to access a certain virtual machine s console by tunneling the relevant VNC port locally and accessing it through your favorite VNC client. The scenario:
  1. Machine A is our main virtualization machine and hosts several virtual machines. (VMs)
  2. Each VM has its own VNC port assigned. (usually the port range goes from 5900 to 5910 or even more if the hosted VMs are more than 10)
  3. We ll be using libvirt, thus virsh.
We first need to find out which port got assigned to the VM we want to have console access to:
sudo virsh
virsh # list
Id   Name   Status
----------------------------------------------------
5    foo    running
6    bar    running
7    foobar running
virsh # vncdisplay foobar
:3
We, then, create a tunnel which redirects all the traffic from the main virtualization machine s port to the port we gonna specify in the next command:
ssh -f -N -L 5910:localhost:5903 user@machine-A.com
A few details about the previous command:
  1. -N tells SSH to not execute any command after logging in.
  2. -f tells SSH to hide into the background just before the command gets executed.
  3. -L enables the port forwarding between the local (client) host and the host on the remote side.
And why did I choose respectively port 5903 and 5910? While you can adjust port 5910 with your own choice (that will just move the tunneled traffic from port 5910 to your favorite port), that won t work as expected with port 5903 since each VNC port is binded to the number of display virsh assigned to it. (for example, the bar VM may be running on display 5, thus its vncdisplay port will be 5905) When done, fire up your favorite VNC client and create a new connection with the following details:
Protocol: VNC - Virtual Network Computing
Server: localhost - 127.0.0.1
Port: 5910
The connection will load and you ll be put in front of your foobar VM console.

Timo Jyrinki: Light-weight security, Grub2 password setup problems 1.99 vs 2.00

I believe I'm not the only one who thinks that use case oriented Grub2 documentation is hard to find, and a lot of the documentation is obsolete or wrong. My main cause for writing this blog post is a currently unanswered question regarding 2.00, but meanwhile it seems months have passed and still most 1.99 documentation is wrong as well, which might be interesting to some.

The aim is to prevent grub entries from being edited, while not restricting actual booting. This protection is meant for computers not having any confidential stuff, but just wanting to do some light weight security with the assumption that the computer isn't physically opened.

Common setup

You will obviously want to disable any automatically generated root access giving entries, by for example uncommenting GRUB_DISABLE_RECOVERY="true" in /etc/default/grub on Debian or Ubuntu. Also you would disable allowing any external boot devices to be used in BIOS/EFI/coreboot, which you would also have protected with a password. And that often means you need to also disable USB legacy support, since some BIOSes tend to offer all USB devices as bootable without password otherwise (note that I guess that could also cause problems accessing setup on desktop computers if your only keyboard is USB).

1.99

So to first fix the false instructions in various places - no, setting the superuser in 00_header as instructed is not enough. It might be, but does not apply if eg. old kernels are put into submenu (Ubuntu bug 718670, Fedora bug 836259). The protection from editing does not apply there. And if you remove all but one kernel so that there is no submenu, a submenu will be automatically created when there is a new kernel installed via security updates. I didn't need the submenu feature anyway, so I used to comment out the following lines in /etc/grub.d/10_linux:

#if [ "$list" ] && ! $in_submenu; then
#echo "submenu \"Previous Linux versions\" "
#in_submenu=:
#fi
...
#if $in_submenu; then
# echo " "
#fi

I hope that was useful. I can imagine it causing a couple of family battles if the commonly instructed setup was the only protection used and there's for example a case of two computer savvy siblings that are eager to get to each others' computers...

2.00 & The Question

The problem with 2.00 is that the superusers setup yields a non-bootable system, ie. password is required for booting. But Google wasn't smiling at me today! Terrible. Can you help me (and others) with 2.00? The aim would be to have a 1.99-like setup where superuser password protects all entries from editing, but booting is fine without any passwords.

Update: Thanks, problem solved, see comments! Find the following line in /etc/grub.d/10_linux:

echo "menuentry '$(echo "$os" grub_quote)' $ CLASS \$menuentry_id_option 'gnulinux-simple-$boot_device_id' " sed "s/^/$submenu_indentation/"

And add --unrestricted there. Don't mix the line with the another menuentry line two lines earlier. The submenu problem doesn't exist anymore in 2.00.

5 October 2012

Keith Packard: fd-passing

FD passing for DRI.Next Using the DMA-BUF interfaces to pass DRI objects between the client and server, as discussed in my previous blog posting on DRI-Next, requires that we successfully pass file descriptors over the X protocol socket. Rumor has it that this has been tried and found to be difficult, and so I decided to do a bit of experimentation to see how this could be made to work within the existing X implementation. (All of the examples shown here are licensed under the GPL, version 2 and are available from git://keithp.com/git/fdpassing) Basics of FD passing The kernel internals that support FD passing are actually quite simple POSIX already require that two processes be able to share the same underlying reference to a file because of the semantics of the fork(2) call. Adding some ability to share arbitrary file descriptors between two processes then is far more about how you ask the kernel than the actual file descriptor sharing operation. In Linux, file descriptors can be passed through local network sockets. The sender constructs a mystic-looking sendmsg(2) call, placing the file descriptor in the control field of that operation. The kernel pulls the file descriptor out of the control field, allocates a file descriptor in the target process which references the same file object and then sticks the file descriptor in a queue for the receiving process to fetch. The receiver then constructs a matching call to recvmsg that provides a place for the kernel to stick the new file descriptor. A helper API for testing I first write a stand-alone program that created a socketpair, forked and then passed an fd from the parent to the child. Once that was working, I decided that some short helper functions would make further testing a whole lot easier. Here s a function that writes some data and an optional file descriptor:
ssize_t
sock_fd_write(int sock, void *buf, ssize_t buflen, int fd)
 
    ssize_t     size;
    struct msghdr   msg;
    struct iovec    iov;
    union  
        struct cmsghdr  cmsghdr;
        char        control[CMSG_SPACE(sizeof (int))];
      cmsgu;
    struct cmsghdr  *cmsg;
    iov.iov_base = buf;
    iov.iov_len = buflen;
    msg.msg_name = NULL;
    msg.msg_namelen = 0;
    msg.msg_iov = &iov;
    msg.msg_iovlen = 1;
    if (fd != -1)  
        msg.msg_control = cmsgu.control;
        msg.msg_controllen = sizeof(cmsgu.control);
        cmsg = CMSG_FIRSTHDR(&msg);
        cmsg->cmsg_len = CMSG_LEN(sizeof (int));
        cmsg->cmsg_level = SOL_SOCKET;
        cmsg->cmsg_type = SCM_RIGHTS;
        printf ("passing fd %d\n", fd);
        *((int *) CMSG_DATA(cmsg)) = fd;
      else  
        msg.msg_control = NULL;
        msg.msg_controllen = 0;
        printf ("not passing fd\n");
     
    size = sendmsg(sock, &msg, 0);
    if (size < 0)
        perror ("sendmsg");
    return size;
 
And here s the matching receiver function:
ssize_t
sock_fd_read(int sock, void *buf, ssize_t bufsize, int *fd)
 
    ssize_t     size;
    if (fd)  
        struct msghdr   msg;
        struct iovec    iov;
        union  
            struct cmsghdr  cmsghdr;
            char        control[CMSG_SPACE(sizeof (int))];
          cmsgu;
        struct cmsghdr  *cmsg;
        iov.iov_base = buf;
        iov.iov_len = bufsize;
        msg.msg_name = NULL;
        msg.msg_namelen = 0;
        msg.msg_iov = &iov;
        msg.msg_iovlen = 1;
        msg.msg_control = cmsgu.control;
        msg.msg_controllen = sizeof(cmsgu.control);
        size = recvmsg (sock, &msg, 0);
        if (size < 0)  
            perror ("recvmsg");
            exit(1);
         
        cmsg = CMSG_FIRSTHDR(&msg);
        if (cmsg && cmsg->cmsg_len == CMSG_LEN(sizeof(int)))  
            if (cmsg->cmsg_level != SOL_SOCKET)  
                fprintf (stderr, "invalid cmsg_level %d\n",
                     cmsg->cmsg_level);
                exit(1);
             
            if (cmsg->cmsg_type != SCM_RIGHTS)  
                fprintf (stderr, "invalid cmsg_type %d\n",
                     cmsg->cmsg_type);
                exit(1);
             
            *fd = *((int *) CMSG_DATA(cmsg));
            printf ("received fd %d\n", *fd);
          else
            *fd = -1;
      else  
        size = read (sock, buf, bufsize);
        if (size < 0)  
            perror("read");
            exit(1);
         
     
    return size;
 
With these two functions, I rewrote the simple example as follows:
void
child(int sock)
 
    int fd;
    char    buf[16];
    ssize_t size;
    sleep(1);
    for (;;)  
        size = sock_fd_read(sock, buf, sizeof(buf), &fd);
        if (size <= 0)
            break;
        printf ("read %d\n", size);
        if (fd != -1)  
            write(fd, "hello, world\n", 13);
            close(fd);
         
     
 
void
parent(int sock)
 
    ssize_t size;
    int i;
    int fd;
    fd = 1;
    size = sock_fd_write(sock, "1", 1, 1);
    printf ("wrote %d\n", size);
 
int
main(int argc, char **argv)
 
    int sv[2];
    int pid;
    if (socketpair(AF_LOCAL, SOCK_STREAM, 0, sv) < 0)  
        perror("socketpair");
        exit(1);
     
    switch ((pid = fork()))  
    case 0:
        close(sv[0]);
        child(sv[1]);
        break;
    case -1:
        perror("fork");
        exit(1);
    default:
        close(sv[1]);
        parent(sv[0]);
        break;
     
    return 0;
 
Experimenting with multiple writes I wanted to know what would happen if multiple writes were made, some with file descriptors and some without. So I changed the simple example parent function to look like:
void
parent(int sock)
 
    ssize_t size;
    int i;
    int fd;
    fd = 1;
    size = sock_fd_write(sock, "1", 1, -1);
    printf ("wrote %d without fd\n", size);
    size = sock_fd_write(sock, "1", 1, 1);
    printf ("wrote %d with fd\n", size);
    size = sock_fd_write(sock, "1", 1, -1);
    printf ("wrote %d without fd\n", size);
 
When run, this demonstrates that the reader gets two bytes in the first read along with a file descriptor followed by one byte in a second read, without a file descriptor. This demonstrates that a file descriptor message forms a barrier within the socket; multiple messages will be merged together, but not past a message containing a file descriptor. Reading without accepting a file descriptor What happens when the reader isn t expecting a file descriptor? Does it just get lost? Does the reader not get the message until it asks for the file descriptor? What about the boundary issue described above? Here s my test case:
void
child(int sock)
 
    int fd;
    char    buf[16];
    ssize_t size;
    sleep(1);
    size = sock_fd_read(sock, buf, sizeof(buf), NULL);
    if (size <= 0)
        return;
    printf ("read %d\n", size);
    size = sock_fd_read(sock, buf, sizeof(buf), &fd);
    if (size <= 0)
        return;
    printf ("read %d\n", size);
    if (fd != -1)  
        write(fd, "hello, world\n", 13);
        close(fd);
     
 
void
parent(int sock)
 
    ssize_t size;
    int i;
    int fd;
    fd = 1;
    size = sock_fd_write(sock, "1", 1, 1);
    printf ("wrote %d without fd\n", size);
    size = sock_fd_write(sock, "1", 1, 2);
    printf ("wrote %d with fd\n", size);
 
This shows that the first passed file descriptor is picked up by the first sockfdread call, but the file descriptor is closed. The second file descriptor passed is picked up by the second sockfdread call. Zero-length writes Can a file descriptor be passed without sending any data?
void
parent(int sock)
 
    ssize_t size;
    int i;
    int fd;
    fd = 1;
    size = sock_fd_write(sock, "1", 1, -1);
    printf ("wrote %d without fd\n", size);
    size = sock_fd_write(sock, NULL, 0, 1);
    printf ("wrote %d with fd\n", size);
    size = sock_fd_write(sock, "1", 1, -1);
    printf ("wrote %d without fd\n", size);
 
And the answer is clearly no the file descriptor is not passed when no data are included in the write. A summary of results
  1. read and recvmsg don t merge data across a file descriptor message boundary.
  2. failing to accept an fd in the receiver results in the fd being closed by the kernel.
  3. a file descriptor must be accompanied by some data.
Make X pass file descriptors I d like to get X to pass a file descriptor without completely rewriting the internals of both the library and the X server. Ideally, without making any changes to the existing code paths for regular request processing at all. On the sending side, this seems pretty straightforward we just need to get the X connection file descriptor and call sendmsg directly, passing the desired file descriptor along. In XCB, this could be done by using the xcbtakesocket interface to temporarily hijack the protocol as Xlib does. It s the receiving side where things are messier. Because a bare read will discard any delivered file descriptor, we must make sure to use recvmsg whenever we want to actually capture the file descriptor. Kludge X server fd receiving Because a passed fd creates a barrier in the bytestream, when the X server reads requests from a client, the read will stop sending data after the message with the file descriptor is consumed. Of course, this process consumes the passed file descriptor, and if that call isn t made with recvmsg set up to receive it, the fd will be lost. As a simple kludge, if we pass a meaningless fd with the X request and then the real fd with a following XNoOperation request, the existing request reading code will get the request, discard the meaningless fd and then stop reading at that point due to the barrier. Once into the request processing code, recvmsg can be called to get the real file descriptor and the associated XNoOperation request. I wrote a test for this that demonstrates how this works:
static void
child(int sock)
 
    uint8_t xreq[1024];
    uint8_t xnop[4];
    uint8_t req;
    int i, reqlen;
    ssize_t size, fdsize;
    int fd = -1, *fdp;
    int j;
    sleep (1);
    for (j = 0;; j++)  
        size = sock_fd_read(sock, xreq, sizeof (xreq), NULL);
        printf ("got %d\n", size);
        if (size == 0)
            break;
        i = 0;
        while (i < size)  
            req = xreq[i];
            reqlen = xreq[i+1];
            i += reqlen;
            switch (req)  
            case 0:
                break;
            case 1:
                if (i != size)  
                    fprintf (stderr, "Got fd req, but not at end of input %d < %d\n",
                         i, size);
                 
                fdsize = sock_fd_read(sock, xnop, sizeof (xnop), &fd);
                if (fd == -1)  
                    fprintf (stderr, "no fd received\n");
                  else  
                    FILE    *f = fdopen (fd, "w");
                    fprintf(f, "hello %d\n", j);
                    fflush(f);
                    fclose(f);
                    close(fd);
                    fd = -1;
                 
                break;
            case 2:
                fprintf (stderr, "Unexpected FD passing req\n");
                break;
             
         
     
 
int
tmp_file(int j)  
    char    name[64];
    sprintf (name, "tmp-file-%d", j);
    return creat(name, 0666);
 
static void
parent(int sock)
 
    uint8_t xreq[32];
    uint8_t xnop[4];
    int i, j;
    int fd;
    for (j = 0; j < 4; j++)  
        /* Write a bunch of regular requests */
        for (i = 0; i < 8; i++)  
            xreq[0] = 0;
            xreq[1] = sizeof (xreq);
            sock_fd_write(sock, xreq, sizeof (xreq), -1);
         
        /* Write our 'pass an fd' request with a 'useless' FD to block the receiver */
        xreq[0] = 1;
        xreq[1] = sizeof(xreq);
        sock_fd_write(sock, xreq, sizeof (xreq), 1);
        /* Pass an fd */
        xnop[0] = 2;
        xnop[1] = sizeof (xnop);
        fd = tmp_file(j);
        sock_fd_write(sock, xnop, sizeof (xnop), fd);
        close(fd);
     
 
Fixing XCB to receive file descriptors Multiple threads may be trying to get replies and events back from the X server at the same time, which means the kludge of having the real fd follow the message will likely lead to the wrong thread getting the file descriptor. Instead, I suspect the best plan will be to fix XCB to internally capture passed file descriptors and save them with the associated reply. Because the file descriptor message will form a barrier in the read stream, xcb can associate any received file descriptor with the last reply in the read data. The X server would then send the reply with an explicit sendmsg call to pass both reply and file descriptor together. Next steps The next thing to do is code up a simple fd passing extension and try to get it working, passing descriptors back and forth to the X server. Once that works, design of the rest of the DRM-Next extension should be pretty straightforward.

4 October 2012

Rapha&#235;l Hertzog: My Debian Activities in September 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 (1086.48 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg I am subscribed to Launchpad s dpkg bug tracker and I was getting annoyed with the amount of noise I got under the form of bug reports that look like package foo failed to install/upgrade: package foo is already installed and configured . Those reports are a combination of a bug in APT and of random other failures (often hardware related like corrupted .deb files, or I/O errors, but sometimes also real problems in other packages) but they always end up assigned on dpkg (because dpkg is outputting an error message complaining about APT s decision to configure something that doesn t have to be configured). I simply don t have the time required to manually process and inspect all those reports, so I decided to filter them at the apport level with a new Ubuntu bug pattern that indicates that those reports are a duplicate of LP#541595. Thanks to this, the dpkg bug count quickly went down from 130 to about 80. Packaging I sponsored a new upstream version of ledgersmb. I quickly updated WordPress to version 3.4.2 since it contains security relevant fixes. I also pushed a small update of nautilus-dropbox fixing #686863 because upstream renamed the binary package that they hand out on their website from nautilus-dropbox to dropbox. Their dropbox package only conflicts with old versions of nautilus-dropbox and not with the version that Debian is shipping and thus I had to add a Conflicts on our side to forbid co-installation of both packages. Testing wheezy s installation I bought a new laptop (Lenovo Thinkpad X230) and used this as an excuse to test Wheezy s installation process. It worked mostly fine except for two things:
  1. First I noticed that it would not accept my passphrase for my encrypted partition during early boot this turned out to be already reported as #619711 but was no longer getting any attention from the package maintainer. After some IRC discussion with Julien Cristau, we prodded Michael Prokop who had apparently already offered to take care of this issue. I tested his updated package and the result got quickly uploaded.
  2. I had weird networking problems that turned out to be related to the lack of the loopback network (i.e. on localhost). This was the result of a broken /etc/network/interfaces: it had been incorrectly modified by NetworkManager. I reported this in #688355. This issue affects people with IPv6 enabled networks.
Debian France There s a resurgence of activity in Debian France. Sylvestre Ledru is leading the organization of a mini-debconf in Paris on November 24-25th. And Tanguy Ortolo is now taking care of some merchandising (Polo shirts, to change from the usual T-Shirt). I might give a talk during this mini-debconf, possibly about multi-arch. Misc It s been a few months that I noticed a 2 second lag of gnome-shell everytime that smuxi (my IRC client) sent a notification. It s very annoying, you have the impression that the entire machine freezes. So I contacted Mirco Bauer on #smuxi and we investigated a bit. It turns out that smuxi is using an old version of the notification protocol where the picture is sent as a bytestream leading to huge dbus messages. This is clearly sub-optimal so smuxi will be fixed to be able to send the path of the picture instead of the picture itself. On the other hand, it s really a bug of gnome-shell that it freezes during the time it takes to handle the bigger-than-usual dbus message. So I also filed a bug on GNOME Shell (Bugzilla #683829) to get this fixed. Librement: funding free software work I started a new project with the goal of helping free software developers to fund their free software work. It s still mostly vaporware for now but I have a public code repository, a nice logo and lots of ideas. If the topic is of interest to you, and you d like to be involved, feel free to get in touch. Otherwise stay tuned. Thanks See you next month for a new summary of my activities.

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

3 October 2012

Alberto Garc a: IndustryPack, QEMU and LinuxCon

IndustryPack drivers for Linux In the past months we have been working at Igalia to give Linux support to IndustryPack devices. IndustryPack modules are small boards ( mezzanine ) that are attached to a carrier board, which serves as a bridge between them and the host bus (PCI, VME, ). We wrote the drivers for the TEWS TPCI200 PCI carrier and the GE IP-OCTAL-232 module.
TEWS TPCI200
GE IP-OCTAL-232
My mate Samuel was the lead developer of the kernel drivers. He published some details about this work in his blog some time ago. The drivers are available in latest Linux release (3.6 as of this writing) but if you want the bleeding-edge version you can get it from here (make sure to use the staging-next branch). IndustryPack emulation for QEMU Along with Samuel s work on the kernel driver, I have been working to add emulation of the aformentioned IndustryPack devices to QEMU. The work consists on three parts: I decided to split the emulation like this to be as close as possible to how the hardware works and to make it easier to reuse the code to implement other IndustryPack devices. The emulation is functional and can be used with the existing Linux driver. Just make sure to enable CONFIG_IPACK_BUS, CONFIG_BOARD_TPCI200 and CONFIG_SERIAL_IPOCTAL in the kernel configuration. I submitted the code to QEMU, but it hasn t been integrated yet, so if you want to test it you ll need to patch it yourself: get the QEMU source code and apply the TPCI200 patch and the IP-Octal 232 patch. Those patches have been tested with QEMU 1.2.0. And here s how you run QEMU with support for these devices:
$ qemu -device tpci200 -device ipoctal
The IP-Octal board implements eight RS-232 serial ports. Each one of those can be redirected to a character device in the host using the functionality provided by QEMU. The serial0 to serial7 parameters can be used to specify each one of the redirections. Example:
$ qemu -device tpci200 -device ipoctal,serial0=pty
With this, the first serial port of the IP-Octal board ( /dev/ipoctal.0.0.0 on the guest) will be redirected to a newly-allocated pty on the host. LinuxCon Europe Having virtual hardware allows us to test and debug the Linux driver more easily. In November I ll be in Barcelona with the rest of the Igalia OS team for LinuxCon Europe and the KVM Forum. I will be talking about how to use QEMU to improve the robustness of device drivers and speed up their development.. Some other Igalians will also be there, including Juan Su rez who will be talking about the Grilo multimedia framework. See you in Barcelona!

Stefano Zacchiroli: put some Debian salt in the Ubuntu charity marathon

Fellow geeks of the Canonical community team will be doing something pretty weird this week. They're fund-raising for charity, for causes ranging from environment to autism, from homeless support to kids education, from poverty fight to water supplies. But that's not weird. What's weird is that the fund-raising will culminate in a 24-hour work marathon stream live, which will kick off tomorrow (Thursday) at 10:00 UTC. As I like charity, and as I like contributing to Free Software, I gladly accepted to rely here a challenge to the Debian community by one of the marathon "horsemen", Michael Hall: Raising the stakes, Nick Skaggs has decided to propose a similar challenge: Wanna take the challenge? And how about the other 4 horsemen? No challenges to the Debian community? Feel free to leave a comment and I'll raise the stakes even more, updating the list above. Update 4/10/2012, 13:35 +0200: Daniel Holbach added his own challenge to the Debian community:

Next.

Previous.