Search Results: "ron"

10 April 2012

MJ Ray: DLT is better than CAPTCHA

Stop using CAPTCHAs. It s time to switch to DLT: Design, Limit and Trapdoor.
[a certain website] has the evil bad wrong Google reCaptcha on the edit page to stop disabled users, so screw it. Google s reCaptcha seems to be spreading again, obstructing more people when accessing more websites. Is there a reason for that? The re in reCaptcha stands for replace with real anti-spam, please!
I wrote the above about two years ago and it s not getting any better. I ve written similar things over the last ten years, as have many others, and I ve always sought to avoid using physical ability tests as a way to cut down spammers. Why do people keep reaching for the reCaptcha non-captcha or things that use similar bad eyetests like Mollom? So most online messages may be spam, but those physical ability tests do nothing to test for spam. They re trying to detect computer submissions (the TCHA in CAPTCHA is meant to be Telling Computers and Humans Apart), but that s really bad when the computer is helping someone with a disability to access the internet. People from the home of the CAPTCHA describe access for sight and hearing-impaired users as an important open problem for the project (Luis von Ahn, Manuel Blum and John Langford. Telling Humans and Computers Apart Automatically. In Communications of the ACM). Until that problem is closed, CAPTCHAs should be considered defective and removed whenever possible. What webmasters should do instead is DLT:
  1. Design it well: Set up sites so the spammers cannot get a quick win in the first place. Configure permissions and things like that so people have to do some work before they are trusted to post links. This is similar to the basic theory behind my Open Activism paper Fighting in the Shadows. This is much easier to do if the system is Free and Open Source Software (FOSS), too.
  2. Limit the damage: include rate limits to stop one person causing you lots of work: even with computer-assistance, few people need to post 10 forum messages every minute. Join up in co-operative anti-spam networks like blogspam.net so if they hurt you, others can see them coming. Again, it s easier to hook into a network if you re using FOSS.
  3. Trapdoor: keep a way for people to contact you if they are really blocked by your design decisions and limitation and keep a way to exempt them from the limits if needed. Make it welcoming because disabled users are tired of reporting barriers to webmasters who don t care and will never fix the web. A good multi-step eyetest-free contact form is a basic way to do this.
Have you tried this? Have your experiences been as good as our co-op s? Are there sites you don t think it would work for? A comments form is on the original of this article, as ever.

Dirk Eddelbuettel: RcppDE 0.1.1

The RcppDE package required a bug-fix release. One of the tests compared results to those from the DEoptim package this is based upon, and these are no longer equal, leading the tests to fail. While I was at it, I finally committed a few more things that had piled up. Below are the corresponding ChangeLog entries
2012-04-08  Dirk Eddelbuettel  <edd>
        * DESCRIPTION: Release 0.1.1
        * tests/compTest.R: With the just-release DEoptim 2.2.0, results are
        no longer identical so we commented-out the stopifnot() comparison to
        not break any automated tests (as requested by the CRAN maintainers)
        * .Rbuildignore: Added a few more files which R CMD check does not
        want to see in the tarball
2011-03-07  Dirk Eddelbuettel  <edd>
        * src/evaluate.h: Also reflect '...' argument from R function we pass
        in, with thanks to Josh Ulrich for the one-line patch
        * R/DEoptim.R: No longer pass environment 'env' down
        * man/DEoptim.Rd: No longer document now unused 'env'
        * src/deoptim.cpp: Minor tweak to RcppArmadillo object creation

9 April 2012

M nica Ram rez Arceda: From non-DD to DD

Two weeks ago I became a Debian Developer. I must say this made me very very happy! In fact, I still can't believe it But what makes me really happy is to continue collaborating in this great community. When you change your status from non-DD to DD, you must do some changes in your configurations. I've written a recipe about this called Non-DD to DD steps, maybe it can be useful for future incoming DDs. If someone detects an error, please tell me, I'll be glad of fixing it. Besides this, I don't want to finish this post without thanking publicly everybody that has given me a helping hand. First of all I want to thank ana, my tireless mentor and main sponsor, and mentors list as well as mentors IRC channel, for being always there. Also, I want to thank hauke, who uploaded my first little contribution and encouraged me a lot, francesca, with who I had the pleasure to work a little bit on past IRC trainig sessions, all people who have encouraged me (including greoga, rmayorga, asheesh, jordi, anibal and Debian Women Team), hyperair for helping me on packaging, lucas for clarifying my doubts about QA massive bugs filing, all members of OpenStreetMap Team for their help, lfaraone, my AM, and finally but not less important I thank all people I met in Debconf11 that make me find out that Debian is greater than I thought (agi, frequena, gunnar, vicho, tincho, sanvila, enrico and more!). I'm sure I'm forgetting someone yes, you! But I'm sure you'll forgive me, you know, memory is not my best quality ;-) Thanks!!!

Soeren Sonnenburg: Shogun Student Applications Statistics for Google Summer of Code 2012

A few weeks have passed since SHOGUN has been accepted for Google Summer of Code 2012. Student application deadline was Easter Friday (April 6) and shogun received 48 proposals from 38 students. Some more detailed stats can be found in the figure below. This is a drastic drop compared with last year (about 60 students submitted 70 proposals). However, this drop can easily be explained: To even apply we required a small patch, which is a big hurdle.
  1. One has to get shogun to compile (possibly only easy under debian; for cygwin/MacOSX you have to invest quite some time to even get all of its dependencies).
  2. One has to become familiar with git, github and learn how to issue a pull request.
  3. And finally understand enough of machine learning, shogun's source code to be able to fix a bug or implement some baseline machine learning method
Nevertheless, about a dozen of proposals didn't come with a patch (even though written on the instructions page that this is required) - an easy reject. In the end the quality of proposals increased a lot and we have many very strong candidates this year. Now we will have to wait to see how many slots we will receive before we can finally start the fun :-)

Christian Perrier: QA on D-I translations

Today, I did a big bunch of QA fixes on Debian Installer translations. The D-I "spellchecker", written years ago by Davide Viti, is still functional and very helpful to spot obvious mistakes. You can find its results here. Feel free to check your own language, particularly for "unknown words" (wrt aspell spellcheckers). There are many false positives (the spellcheck has the concept of exceptions for this, which explains why French has 0 errors...), but the spellchecker can already spot many typos and minor spelling errors. It also spots wrongly written variables, unbalanced quotes and parenthesis and a few other minor things.

Craig Sanders: getting the terminal size in python

I m finally getting around to making myself learn python as more than just a read-only language. Working with Openstack kind of requires it. So far, I like it. Much more than I thought I would as an unrepentant sh and perl using systems geek. And getting over my distaste for the white-space issue is also proving to be much easier than I thought it would (although I still think that block-delimiters like make the code easier to read PyHeresy, I know) While hacking the /usr/bin/glance command to have less ugly output, and adding a csv option to list the image index in a usefully parseable format, I needed to figure out how to get the terminal size (height,width). This, cobbled together from various google search results, seems to work. It s probably not strictly-correct python idiom, and there s probably a better way of doing it. Comments and critique are welcome.
def get_terminal_size(fd=1):
    """
    Returns height and width of current terminal. First tries to get
    size via termios.TIOCGWINSZ, then from environment. Defaults to 25
    lines x 80 columns if both methods fail.
 
    :param fd: file descriptor (default: 1=stdout)
    """
    try:
        import fcntl, termios, struct
        hw = struct.unpack('hh', fcntl.ioctl(fd, termios.TIOCGWINSZ, '1234'))
    except:
        try:
            hw = (os.environ['LINES'], os.environ['COLUMNS'])
        except:  
            hw = (25, 80)
 
    return hw
 
def get_terminal_height(fd=1):
    """
    Returns height of terminal if it is a tty, 999 otherwise
 
    :param fd: file descriptor (default: 1=stdout)
    """
    if os.isatty(fd):
        height = get_terminal_size(fd)[0]
    else:
        height = 999
 
    return height
 
def get_terminal_width(fd=1):
    """
    Returns width of terminal if it is a tty, 999 otherwise
 
    :param fd: file descriptor (default: 1=stdout)
    """
    if os.isatty(fd):
        width = get_terminal_size(fd)[1]
    else:
        width = 999
 
    return width
getting the terminal size in python is a post from: Errata

8 April 2012

John Goerzen: 26 Hours At The Creek

I m back from one of the best experiences a father can have a whole day with two happy boys. I took Jacob (5) and Oliver (2) camping with me out by our creek. This was the first time we d camped there, and also the first time I d taken the boys camping without Terah along. So there were some unknowns, but it worked out great. When we got out there, I started to get the tents set up. The boys were interested, but pretty soon invented some games. A large nearby tree with plenty of low branches on its trunk became their locomotive, and certain sticks made the train go forward or backward, whistle, or ding its bell. This was good for quite some entertainment. Another nearby tree, near the bank of the creek, had some erosion near it. Combined with its roots, this made some natural steps. Jacob named some the enter steps and others the exit steps , and I sure heard about it if I walked the wrong way on the exit steps. We then gathered up sticks and the things we needed to build a campfire. We cooked up brats and zucchini. Although it was later than usual for supper, they loved it just the same. After that, we made smores for dessert another thing they loved. Then, one of the big highlights: sleeping in tents and sleeping bags. I had showed them the sleeping bags earlier, and they were excited to try them out. Morning was beautiful when the sun came out, it was shining right on the heavy dew on the ground, making the grass shine brightly. It s not every day that they get to start their morning slowly waking up by a warm fire. They were content to sit for quite awhile while I got things going for breakfast. It was chilly outside, so I helped them change clothes by the fire where. I then cooked them some scrambled eggs which, despite the lack of salt and pepper, seemed so much better than normal to the boys and then we went exploring. I took them to some areas with erosion, which Jacob called the big holes in the ground. It s really quite beautiful in spring, which this cellphone photo completely fails to capture. The boys loved climbing up and down these areas, some of which were quite tall. They discovered different kinds of rock on the way up and down, and with my help avoided discovering too much of the mud at the bottom. We hiked back to our camping spot through grass almost as tall as Oliver much to his delight and then after warming up by the fire for a bit, went off in the other direction. There is a grove of trees by the creek over there, which surprise became another train. Here are the boys explaining how it works. <iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="https://www.youtube.com/embed/43EcEK8F_ic?rel=0" width="560"></iframe> They helped pack things back up, too. Actually, it took some convincing to get Jacob to not pull up all the stakes for the tent before I was ready for them. Things didn t go perfectly, but then, they never do, and that was OK with everyone. Camping is an adventure, and it wouldn t be an adventure if you knew every detail beforehand. It is rare in life to be able to think that I have enough time to do anything the boys might want to do. Spend half an hour pretending a tree is a train sure, no problem. Today Oliver asked to go camping again, and was a bit disappointed when I didn t agree to go camping again right this minute, today. Jacob said, we had an EXCELLENT time and gave me hugs thinking about it. I have a lot of happy memories about the creek. We camped at the same spot where I went fishing or camped as a child. There have been family gatherings and even a birthday party out there. The boys and I have enjoyed a hike or a wagon ride to the area, but as I learned, nothing could possibly match the excitement of camping there. It is wonderful to add another happy memory of a time at the creek. And it s even better to see another generation of Goerzens discover that there s a lot of fun to be had down by the creek.

7 April 2012

Ritesh Raj Sarraf: Apport for Debian

apport just cleared the new queue and is now available in experimental. For those who do not know what apport is:

Debugging program crashes without any automated tools has been pretty time consuming and hard for both developers and users. Many program crashes remain unreported or unfixed because:

  • Many crashes are not easily reproducible.
  • End users do not know how to prepare a report that is really useful for developers, like building a package with debug symbols, operating gdb, etc.

  • A considerable part of bug triage is spent with collecting relevant information about the crash itself, package versions, hardware architecture, operating system version, etc.
  • There is no easy frontend which allow users to submit detailed problem reports.
  • Existing solutions like bug-buddy or krash are specific to a particular desktop environment, are nontrivial to adapt to the needs of a distribution developer, do not work for crashes of background servers (like a database or an email server), and do not integrate well with existing debug packages that a distribution might provide.

Apport is a system which

  • intercepts crashes right when they happen the first time,
  • gathers potentially useful information about the crash and the OS environment,
  • can be automatically invoked for unhandled exceptions in other programming languages (e. g. in Ubuntu this is done for Python),
  • can be automatically invoked for other problems that can be automatically detected (e. g. Ubuntu automatically detects and reports package installation/upgrade failures from update-manager),
  • presents a UI that informs the user about the crash and instructs them on how to proceed,
  • and is able to file non-crash bug reports about software, so that developers still get information about package versions, OS version etc.
At this moment, it is quite broken. The crashes are not intercepted by update-notifier on my box. With it now in experimental, my intent is to slowly integrate it well with all dependent tools for Debian. It won't be ready for the Wheezy release, but hopefully for the one after that.On the Ubuntu side, Canonical hosts a retracing service that takes user reported core dumps and generates a usable backtrace. For Debian, my plan is to have a chroot kind interface, where in the user could opt-in to download all debug packages to generate a valid backtrace. This could go as the debian backend for apport in the future. On the bug reporting side, afaik, we do not have a web interface to lodge bugs. To report bugs (minus the core dumps), we will want a backend to submit it over email. The current apport report gathering tool is pretty good (if compared to other tools like reportbug), so here the low hanging fruit would be to just take the report and feed in email to our BTS server. For the eyes:Apport on Debian

Bastian Blank: Booting Debian via AoE (ATA over Ethernet) and PXE

AoE is one of the protocols supported by Linux to access storage via network. It uses plain Ethernet for communication and includes a discovery mechanism to find all available targets. I use it to provide disk space to VMs running on different machines. Next step is to boot via AoE. It is no real problem to use AoE in running systems. However with some help it is even possible to actually boot disk-less machines via AoE. The PXE implementation iPXE provides the AoE support to actually boot from. I will describe the necessary parts.
Setup vblade The AoE target used it vblade. vblade needs access to raw sockets. As I prefer to not have run anything as root if it is not necessary, I use filesystem capabilities to allow it access to the network.
setcap cap_net_raw+ep /usr/sbin/vblade
vblade gets the mac address of the initiator, the shelf and slot number, the network device and the block device.
/usr/sbin/vblade -m $mac 0 0 eth0 $dev
Setup a tftp server and iPXE
apt-get install atftpd ipxe
ln -s /usr/lib/ipxe/undionly.kpxe /var/lib/tftpboot
Setup ISC dhcpd The dhcp server needs to be configured. It needs to hand out two distinct parameter sets. The first is used to chain-load iPXE into the normal PXE stack. The second is for iPXE and sets the root path to the AoE device. They are selected on the iPXE marker in the request.
if exists user-class and option user-class = "iPXE"  
  filename "";
  option root-path "aoe:e0.0";
  else  
  filename "undionly.kpxe";
 
Support AoE via initramfs-tools The initramfs needs to initialize AoE support. It needs to enable the network device used for communication with the AoE server and wait until it is up. After that it needs to load the aoe module and run aoe-discover. We should have all devices now. The root device can now be used like any other normal device. After the AoE device is initialized, it can be found via UUID and all the other ways. So no further modifications are necessary over the usage of local disks. The initramfs finds the device as usual and boots from it. The initramfs support is still a prototyp, but seems to work. For initramfs-tools it needs a hook to include all necessary stuff in the initramfs and a script to actually do the work. Both are shown here. /etc/initramfs-tools/hooks/aoe:
#!/bin/sh
case $1 in
prereqs)
  echo "udev"
  exit 0
  ;;
esac
. /usr/share/initramfs-tools/hook-functions
copy_exec /sbin/aoe-discover
manual_add_modules aoe
/etc/initramfs-tools/scripts/local-top/aoe:
#!/bin/sh
case $1 in
prereqs)
  echo "udev"
  exit 0
  ;;
esac
ifconfig eth0 up
sleep 10
modprobe aoe
aoe-discover
udevadm settle --timeout=30
Problems Not all parts of this works 100%. Some parts works not for all hardware.
  • My old notebook is not able to run Linux with this setup. grub loads the kernel via AoE and nothing comes later.
  • The network may need more time. Especially in large environments with spanning tree enabled, it may need half a minute until any packets will flow.
Some of the problems can be addressed later. Some can't.

6 April 2012

Rapha&#235;l Hertzog: People Behind Debian: Francesca Ciceri, Member of the Debian Press & Publicity Teams

Francesca Ciceri, photo by Andrew McMillan, CC-BY-SA 2.0

I met Francesca in Debconf 11 in Banja Luka. If I recall correctly, it s Enrico Zini who introduced me to her, because she was the madamezou (her IRC nickname) who started to get involved in the publicity team. Since then and despite having a bachelor thesis to complete she got way more involved and even gained official responsibilities in the project. Before starting with the interview, I wanted to mention that Francesca is drafting a diversity statement for Debian I was expecting the discussions to go nowhere but she listened to all objections and managed to improve the text and build a consensus around it. Thank you for this and keep up the good work, Francesca! Rapha l: Who are you? Francesca: My name is Francesca, I m 30 and I studied Social Sciences. Currently I live in Italy but I m planning to go abroad (not a lot of jobs here for geeky social scientists). Apart for Debian and FLOSS world in general, I have unrestrained passions for chocolate; zombie movies; sci-fi; zombie books; knitting sewing crafting and DIY in general; zombie videogames; bicycles; pulling apart objects to look inside them; splatter B movies, David Foster Wallace s books, playing trumpet, and did I already mentioned zombies? Days are too short for all this stuff, but I try to do my best. Raphael: How did you start contributing to Debian? Francesca: Some years ago I was stuck in bed for literally some months, due to a grave series of migraine attacks. I wasn t able to do anything: no social life, no books or television. So, I decided to turn on the laptop and do something constructive with it: I was already a Debian user and it seemed quite logical to me to try to give back to the community. I am not a coder and I ve not studied Computer Science, so my first step was to join an Italian Debian on-line community (Debianizzati) and help with tutorials, users support, wiki management. In a couple of months I learnt many things: helping other users with their problems forces you to do lots of research! My first contributions to the Debian project were mostly translations of the main website. Translators are the perfect typos spotters: they work so precisely on the text to be translated that they finish to do a great QA job. This is how I ve started to contribute to the Debian website: with very simple things, fixing typos or wrong links or misplaced wml tags. I still remember my first commit to the website: the idea was to undercase some tags, but it ended up that I misplaced some of them and in addition I fixed them only in the English page and not on the translations as well. When after a couple of minutes, K re Thor Olsen a long time contributor of the team and now webmaster reverted my commit, I felt so stupid and full of shame. But, to my great surprise, no one treated me like an idiot for that error: Gerfried Fuchs, one of the guru of the team, replies me in a really helpful and polite way explaining what I did wrong and how to do things correctly. I think this episode was a turning point in my Debian life: there s this idea that Debian Developers are just a bunch of arrogant assholes and maybe it was true in the past, but for my experience they are not. Well, at least the ones I met and work with ;) .
To my great surprise, no one treated me like an idiot for that error.
Since then, I joined the WWW team and helped them apply the shiny new design provided by Kalle S derman. A lot of work was done during the week immediately before the release of the new website. Oh that was a week! We worked night and day to have the new design ready for February 6th, and it was fantastic when we finally published it, simultaneously with the release of Squeeze. At the same time, I started to contribute more actively to the Debian Publicity team, not only translating news but also writing them. It can sound scary for a non native English speaker to write something from scratch in English, but you have to keep in mind that your text will be reviewed by native speakers before being published. And we have some fantastic reviewers in the English localisation team: particularly Justin B Rye, who is tireless in his effort and more recently Moray Allan. I think I m particularly lucky to work with all these people: there s a special mood in both Publicity and WWW team, which makes you feel happy to do things and at the same time pushes you to do more just because it s fun to work with them sharing jokes, ideas, rants, patches and hugs. Rapha l: I believe that you have been trough the new member process very quickly. You re now a Non-Uploading Debian Developer. How was the experience and what does this mean to you? Francesca: Becoming a Debian Developer was not so obvious for me, because I didn t need to be a DD for the work I do in Debian. For instance, I don t maintain packages, so I had no reasons to want to become a DD in order to have uploading rights. For a while I didn t really feel the necessity of being a DD. Luckily, some people started to pester me about it, asking me to apply for the NM process. I remember Martin Zobel-Helas doing this for an entire week every single day, and Gerfried Fuchs doing it as well. Suddenly, I realized that people I worked with felt that I deserved the DD status and that I simply had thought I didn t. As a non coder and a woman, there probably was a bit of impostor syndrome involved. Having people encouraging me, gave me more confidence and the desire to finally become a DD. And so I did. The process for non uploading DD is identical to the one to become an uploading DD, with one exception: in the second part of the process (named Tasks and Skills) instead of questions about how to create and maintain packages, there are questions about the non packaging work you usually do in Debian. The general resolution which created the possibility to become a non uploading DD gave us a chance to recognize the great effort of Debian contributors who work in various area (translations, documentation, artworks, etc.) that were not always considered as important as packaging efforts. And this is great because if you are a regular contributor, if you love Debian and you are committed to the project, there are no reasons to not be an official member of it. With regards to this, I like the metaphor used by Meike Reichle in her recent talk about the Debian Women Project (video recording here):
a Debian Developer status is a lot like a citizenship in a country that you re living in. If you live in a country and you don t have citizenship, you can find a job, buy a house, have a family [...] but if this country at any point in time decides to go into a direction that you don t like, there s nothing you can do about it. You are not in the position to make any change or to make any effect on that country: you just live there, but there s no way that you can excercise influence on the people who run this country.
Rapha l: You recently joined the Debian Press Team. What does it involve and how are you managing this new responsibility? Francesca: The Press Team is basically the armed wing of the Publicity Team: it handles announcements that need to be kept private until the release, moderate the debian-announce and debian-news mailing list and maintain contacts with press people from outside the project. The real job, so, is done within the Publicity Team. The most important part of our work is to write announcements and the newsletter: while the newsletter is published bi-weekly, the announcements need to be write in a shorter timeframe. Localization is really important in spreading Debian word, so we work closely with translators: both announcements and DPN are usually translated in four or five different languages. The publicity work could be stressful, as we have strict deadlines, we need to take quick decisions and often do last-minute changes. Personally, I like it: I work better under pressure. But I know that is sometimes difficult for contributors to accept that we can t debate endlessly on details, we have just to go on and do our best in a given timeframe.
The publicity work could be stressful, as we have strict deadlines, [ ]. Personally, I like it.
Raphael: You re one of the main editor behind the Debian Project News. What s the role and scope of this newsletter? Francesca: Debian Project News is our beloved newsletter, direct successor of the Debian Weekly News founded by Joey Hess in 1999 and later kept alive by Martin Schulze. In 2007, Debian Weekly News was discontinued but in 2008 the project was revived by Alexander Reichle Schmehl. The idea behind DPN is to provide our users an overview of what is happening inside and outside the project. As the core team of editors is formed by three people, the main problem is to be able to collect enough news from various sources: in this sense we are always glad when someone points us to interesting blogposts, mails and articles. DPN is also a good chance for non coders to contribute to Debian: propose news, write paragraphs and review the draft before the publication are quite easy tasks but very useful. English native speakers can do a proofread (as no one of the main editors is a native speaker) while others can always translate DPN in their native language. People who want to help us can take a look at our wiki page.
DPN is also a good chance for non coders to contribute to Debian.
Just yesterday I realized that since January we don t miss or delay an issue: so I d like to thank the fantastic team of editors, reviewers and translators who made it possible. The team is now working on another way of spreading Debian s message: a long-time project is finally becoming real. Stay tuned, surprise arriving! Raphael: You re trying to organize IRC training sessions but that doesn t seem to take off in Debian, while it s quite common in the Ubuntu community. How do you explain that? Francesca: I m not sure about it: both Debian users and contributors seemed to appreciate this initiative in the past. I was quite surprised by the amount of Debian members present during the various sessions and by the amount of interesting questions asked by the users. So the only reason I can think about is that I need to put more enthusiasm in convincing the teams to do it: they need more encouragement (or to be pestered more!). I, for myself, think that IRC training sessions are a great way to promote our work, to share our best practice, to talk about our project to a wider audience. And I ll sure try to organize more of them. Help, suggestions, ideas are really welcome! Raphael: If you could spend all your time on Debian, what would you work on? Francesca: There is a project I d like to give more love, but I always end up without the time to do it: the debian-community.org project. Back in 2007, Holger Levsen founded it with the aim of reducing the gap between Debian contributors and Debian users, giving all an opportunity to contribute, share ideas and more. The project was discontinued and I d really like to revive it: in these years various things have changed, but I think that the core idea of having a node to connect existing local communities is still good and doable. In Debian we don t have the wide and well articulated local infrastructure present in other distributions (Ubuntu, particularly, but also Fedora): even if I don t like too centralized structures, I think that a better connection between the project and local groups of users and on-line communities would be a step forward for the project. Being part of the Events Team, I m aware of how much we need to improve our communication with local groups. An example is the events organization: sometimes, Publicity and Events teams even don t know about regional Debian related events (like booth at conferences, workshops, talks, install parties, etc) and this is a shame because we could offer a lot of help in organizing and promoting local events. What we lack is better communication. And debian-community.org project could give us exactly this. Could be a cluster of local groups, a platform for events organization and even a useful resource for newbies who want to find a local group near them. I started some effort in this sense, sending a proposal about it, working on a census of Debian local groups. Any help is appreciated! I m really curious to see how many Debian communities (from all around the world and the web) are out there, and I d love to have members from these communities better connected with the Debian Project. Raphael: What s the biggest problem of Debian? Probably the bikeshedding feticism of almost all of us. It s the other side of the coin of Debian s commitment to technical excellence and our perfectionism, but sometimes it leads just to endless discussions about details, and it is a blocker for various initiatives. In Debian, you have to be really patient and in a way stubborn to push some changes. This is frustrating sometimes. On the other hand, I really appreciate how people take some times to think to each proposals, give some feedback and discuss about it: the process could be annoying, indeed, but the result is often an improvement of the initial proposal. Raphael: Is there someone in Debian that you admire for their contributions? Most of my teammates are simply brilliant and adorable and hard-working. But I have to admit that I particularly admire David Pr vot: beside being a webmaster he does a lot of things, from French translations to DPN editing. All his contributions have a great quality and he s able to push you always further in doing things and doing them better. He is a good example of how I d like to be as contributor: smart, tireless, friendly.
Thank you to Francesca for the time spent answering my questions. I hope you enjoyed reading her answers as I did. Note that older interviews are indexed on wiki.debian.org/PeopleBehindDebian.

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, Google+, Twitter and Facebook.

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

5 April 2012

Michal &#268;iha&#345;: Why weblate?

I still get lot of questions why I wrote Weblate instead of staying with some existing solution. Most of the reasons were already addressed in previous posts, where I looked for Pootle alternative or announced Weblate, but still it might be worth to summarize reasons once more. Git integration None of existing tools integrate with distribute version control, while I find this integration somewhat obvious and necessary. Having translation system as one of remote branches makes things really easy to handle for developers. Merging translations is nothing more than git merge. Attribution to translator I think it's fair to request that translator gets appropriate attribution for his contribution. Once we rely on Git, it is quite obvious that he will be author for Git commit doing changes. This way you can find author purely with Git and don't need to look for other tools. Handling of several branches In phpMyAdmin we heavily use branches to maintain stable releases. On the other side we want to be able to push translations to both stable and testing branches without translators having to do the work twice. Weblate does automatically push changes to all branches. Well this is not limited to branches but to subprojects as they don't have to be only branches, they can be also just related projects like with Gammu and Wammu. Displaying context Most of tools I tried fail to provide way to show related source code even when Gettext po files contain such references. With Weblate this is just matter of configuring URL of viewer, what nicely integrates with existing services like Github. Sane merging of uploaded translations With Pootle, it is possible to upload incomplete po file and it will luckily take it and replace existing one. This is quite dangerous as you would not notice it is incomplete unless you do some translation validation before release. Weblate does merge uploaded translations unit by unit, what makes it slower, but generates minimal diff and works also across branches. Consistency checks There are always things which can go easily wrong in the translation like format strings and translation tool should catch these as early as possible. Weblate semi-enforces checks - if check has failed, you will be redirected back to previous translation to possibly correct it (or mark check for ignoring). At current state checks are not as good as I would like to, but they are completely modular and can be easily extended and improved. Bonus points While working on Weblate I realized that some things could be done even better than I originally anticipated. For example with Github web hooks, it is possible to receive notifications on upstream repository updates and merge changes as they appear, leaving to really live translation process. Git allows to write custom merge drivers and this can be utilized for less merge conflicts on po files (they are usually caused by timestamps in headers), so that's another handy you get with Weblate. Of course there is much more built in, just check the documentation.

Filed under: English Weblate 3 comments Flattr this!

Dominique Dumont: My activities during Perl/QA hackathon in Paris

Hello Last week-end, I ve participated Perl/QA hackathon in Paris. Here s a short summary of the main activities during this week-end. I was not in the best of shape due to a nasty (biological) bug that wore me down before the hackathon. First of all, I discussed with rjbs about the bunch of debian patches I ve written for Software::License. These patches (and hacks) are used in Debian to provide licenses summaries in Debian::Dpkg::Copyright model to help write Debian copyright files. License management is boring but necessary. cme and Software::License help in making this task slightly less boring. Ricardo kindly suggested some modifications and agreed to include my patches. I implemented these modifications directly during the hackathon. The other tasks during this week-end were (not necessarily in that order): Many thanks to FreeSide who sponsored my travel, to the hackathons organisers and to all the participants for their welcome. All the best

Jon Dowland: Greg Bear Hull Zero Three

In (roughly) 2008 I read "Blood Music" my first Greg Bear novel and devoured it in a weekend, in only two or three reading sessions. That happens very rarely, and when it does I often wonder whether it's the quality of the writing or some combination of that and your personal moods and tastes at the time that is responsible. My next Bear was "Darwin's Radio" in mid-2010 which, whilst good, did not provoke the same feverish read. I might write short reviews for both at some point in the future, but right now I can't remember either well enough to do so. In the last few weeks I read "Hull Zero Three" which was quite a different beast. The novel first captured my attention due to the unusual way it was promoted: via a video, which was created using a modified Quake 2 engine. It wasn't a great video but the novelty made it interesting. The story begins with a first-person narrator waking up from a sort-of hyper sleep on a generation starship that has clearly had some serious problems. He has to run to escape danger before he has an opportunity to figure out exactly what has happened and what he is running from, or to. Something has gone horribly wrong on the ship: it's nowhere near where it should be going and nobody should be awake. The narrator's memory is fractured, fabricated and unreliable; the ship is hostile, and whilst it's mechanical, it cyclically changes and re-arranges it's hulls in an almost organic way. He is joined by a rotating cast of similarly confused refugees of varying shapes and sizes. Language and cultural barriers serve to further magnify the sense of alienation that you experience on behalf of the story teller. The troupe are persued through the corridors by a collection of lethally efficient killer "things", contrasting with the background by being organic in nature but mechanical in behaviour and appearance. The scale of the ship is necessarily massive, and Bear does an impressive job of capturing the awe you might feel when considering it. Three huge, cigar-shaped hulls, joined by "spars" to an enormous chunk of ice captured from the Oort cloud on exodus from the solar system. The ice serves as a mixture of "fuel" for the biological ship systems and as part of a shield system for the hulls from cosmic rays. However, in part due to the narrator's confusion, it was hard to follow the very abstract descriptions of the environment in the earlier stages of the story. I found myself re-reading passages to try and understand the comparisons being offered and scales presented. In common with the two earlier Bears I've read, 'body horror' features prominently in this story. It feels like a "Dead Space" or "Resident Evil" in space in a hard SF novel which seriously attempt to capture real speculative science. Like "Blood Music", I found myself compelled to read "Hull Zero Three" at every available opportunity. I finished it off in a very enjoyable reading session outdoors in the spring sunshine. It was an enjoyable read, well written but not beyond criticism, with some interesting takes on well-worn themes. Very reminiscent of the movie "Pandorum" (which was a surprisingly good movie).

3 April 2012

Axel Beckert: Tools for CLI Road Warriors: Hidden Terminals

Some networks have no connection to the outside except that they allow surfing through an HTTP(S) proxy. Sometimes you are happy and the HTTPS port (443) is unrestricted. The following server-side tools allow you to exploit these weaknesses and get you a shell on your server. sslh sslh is an SSH/SSL multiplexor. If a client connects to sslh, it checks if the clients speaks the SSH or the SSL protocol and then passes the connection to the according real port of SSL or some SSL enabled service, e.g. an HTTPS, OpenVPN, Tinc or XMPP server. That way it s possible to connect to one of these services and SSH on the same port. The usual scenario where this daemon is useful are firewalls which block SSH, force HTTP to go through a proxy, but allow HTTPS connections without restriction. In that case you let sslh listen on the HTTPS port (443) and to move the real HTTPS server (e.g. Apache) to listen on either a different port number (e.g. 442, 444 or 8443) or on another IP address, e.g. on localhost, port 443. On an Debian or Ubuntu based Apache HTTPS server, you just have to do the following to run Apache on port 442 and sslh on port 443 instead:
  1. apt-get install sslh as root.
  2. Edit /etc/default/sslh, change RUN=no to RUN=yes and --ssl 127.0.0.1:443 to --ssl 127.0.0.1:442.
  3. Edit /etc/apache2/ports.conf and all files in /etc/apache2/sites-available/ which contain a reference to port 443 (which is only /etc/apache2/sites-available/default-ssl.conf in the default configuration) and change all occurrences of 443 to 442.
  4. service apache2 restart
  5. service sslh start
Now you should be able to ssh to your server on port 443 (ssh -p 443 your.server.example.org) while still being able to surf to https://your.server.example.org/. sslh works as threaded or as preforking daemon, or via inetd. It also honors tcpwrapper configurations for sshd in /etc/hosts.allow and /etc/hosts.deny. sslh is available as port or package at least in Gentoo, in FreeBSD, in Debian and in Ubuntu. AjaxTerm A completely different approach takes AjaxTerm. It provides a terminal inside a web browser with login and ssh being its server-side backend. Properly safe-guarded by HTTPS plus maybe HTTP based authentication this can be an interesting emergency alternative to the more common but also more often blocked remote login mechanisms. AjaxTerm is available as package at least in Debian and in Ubuntu.

Happily I never were forced to use either of them myself. :-)

2 April 2012

Gerfried Fuchs: Squeeze RCs's Squashing 2012 #2

This is the third summary of my squeeze RC bug squashing. If you take a look at the bug graph you will notice that the blue line went up a bit over a two week's period. I would like to claim that confirming the samhain RC bug 618728 did cost me the time (I actually gave it the time to finish), but the real reason was that I was looking at other stuff. I came back with a vengeance though, so here is the list of the bugs squashed for squeeze since the last report: Current stats: 119 bugs in 93 days, still got the margin up by five more bugs. :) Enjoy!

/debian permanent link Comments: 0 Flattr this

1 April 2012

Rapha&#235;l Hertzog: My Debian Activities in March 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 (227.83 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg Thanks to Guillem, dpkg with multiarch support is now available in Debian sid. The road has been bumpy, and it has again been delayed multiple times even after Guillem announced it on debian-devel-announce. Finally, the upload happened on March 19th. I did not appreciate his announce because it was not coordinated at all, and had I been involved from the start, we could have drafted it in a way that sounded less scary for people. In the end, I provided a script so that people can verify whether they were affected by one of the potential problems that Guillem pointed out. While real, most of them are rather unlikely for typical multiarch usage. Bernhard R. Link submitted a patch to add a new status command to dpkg-buildflags. This command would print all the information required to understand which flags are activated and why. It would typically be called during the build process by debian/rules to keep a trace of the build flags configuration. The goal is to help debugging and also to make it possible to extract that information automatically from build logs. I reviewed his patch and we made several iterations, it s mostly ready to be merged but there s one detail where Bernhard and I disagree and I solicited Guillem s opinion to try to take a decision. Unfortunately neither Guillem nor anyone else chimed in. On request of Alexander Wirt, I uploaded a new backport of dpkg where I dropped the DEB_HOST_MULTIARCH variable from dpkg-architecture to ensure multi-arch is never accidentally enabled in other backports. One last thing that I did not mention publicly at all yet, is that I contacted Lennart Poettering to suggest an improvement to the /etc/os-release file that he s trying to standardize across distributions. It occurred to me that this file could also replace our /etc/dpkg/origins/default file (and not only /etc/debian_version) provided that it could store ancestry information. After some discussions, he documented new official fields for that file (ID_LIKE, HOME_URL, SUPPORT_URL, BUG_REPORT_URL). Next step for me is to improve dpkg-vendor to support this file (as a fallback or as default, I don t know yet). Packaging I packaged quilt 0.60 (we re now down to 9 Debian-specific patches, from a whopping 26 in version 0.48!) and zim 0.55. In prevision of the next upstream version of Publican, I asked the Perl team to package a few Perl modules that Publican now requires. Less than two weeks after, all of them were in Debian Unstable. Congrats and many thanks to the Perl team (and Salvatore Bonaccorso in particular, which I happen to know because we were on the same plane during last Debconf!). On a side note, being the maintainer of nautilus-dropbox became progressively less fun over the last months, in particular because the upstream authors tried to override some of the (IMO correct) packaging decisions that I made and got in touch with Ubuntu community managers to try to have their way. Last but not least, I keep getting duplicates of a bug that is not in my package but in the official package and that Dropbox did not respond to my query. Book update The translation is finished and we re now reviewing the whole book. It takes a bit more time than expected because we re trying to harmonize the style and because it s difficult to coordinate the work of several volunteer reviewers. The book cover is now almost finalized (click on it to view it in higher definitions): We also made some progress on the interior design for the paperback. Unfortunately, I have nothing to show you yet. But it will be very nice and made with just a LaTeX stylesheet tailored for use with dblatex. The liberation fundraising slowed down with only 41 new supporters this month but it made a nice bump anyway thanks to a generous donation of 1000 EUR by Offensive security, the company behind Backtrack Linux. They will soon communicate on this, hopefully it will boost the operation. It would be really nice if we managed to raise the remaining 3000 EUR in the few weeks left until the official release of the book! The work on my book dominated the month and explains my relative inactivity on other fronts. I worked much more than usual, and my wife keeps telling me that I look tired and that I should go in bed earlier but I see the end of the tunnel: if everything goes well, the book should be released in a few weeks and I will be able to switch back to a saner lifestyle. Thanks See you next month for a new summary of my activities.

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

Jamie McClelland: Property is Theft

I've recently been making my way through the Proudhon Reader, a collection of writings by Pierre-Joseph Proudhon recently published by AK Press. Proudhon, known as the father of Anarchism is most famous for his declaration: "Property is theft." The simple declaration is based on pages of explanation which, simplistically, can be boiled down to the idea that workers should all equally share in the fruits of their labor. While Proudhon's influence on Marx is hotly debated, this idea is fundamental to Marx's idea around the alienation of labor. If we are working to produce a product that is then owned by the proprietor, rather than the worker, we are alienated from our labor. Many May First/People Link members, such as Palante Tech, Openflows, Union Web Services, and Agaric Design are all committed to fighting this alienation by organizing as worker-run cooperatives. Nobody is the boss, all workers share in all profits. However, Proudhon got me thinking about free software shops that aren't worker-run cooperatives. If you are employed by a for-profit corporation as a worker and your only job is to write code that is released under a free software license, are you alienated from your labor in the Marxist sense? The fruits of your labor might be owned by your company, but they are freely licensed to the world (which, of course, includes you). There is still surplus value accrued to your company (if you do good work for your company, you will be contributing to their reputation from which they will profit). However, if you are primarily writing code, the vast majority of your labor is producing a product that you are fundamentally not alienated from. Proudhon, while sprinkling the word revolution throughout his writings, was notably not particularly revolutionary in his calls for action. He was reformist. Rather than calling for a direct confrontation with capitalism, he called for worker-run collectives to be formed throughout the world to make capitalism irrelevant. While many people point to corporate use of free software as an argument for why free software and capitalism are perfectly compatible, the truth may be more complicated. Fundamentally, and in a non-confrontational way, free software seems to undermine one of the basic tenants of capitalist: worker alienation. Now we just need to work on all the other ways corporate work places are alienating...

Kai Wasserb ch: kvpm in Debian now

Just a short announcement: kvpm (short for "KDE volume and partition manager") is now a part of Debian's unstable distribution, Sid, and should enter testing (Wheezy) soon. The big thank you for this goes to Benjamin, upstream author of kvpm who has become also the Debian Maintainer of his software! The story behind packaging kvpm started with Benjamin writing an e-mail to pkg-kde-extras, in which he asked for inclusion of kvpm into Debian. After an initial answer by myself about filing a RFP bug, in case he wouldn't like to package kvpm himself, a discussion in private ensued. There I explained that Debian is a do-ocracy, where things get packaged if some maintainer uses something herself or if the requesting party does the work. Benjamin took up the challenge and packaged kvpm, I helped only with feedback and finally sponsoring the upload. Why do I tell this story? Because I hope it encourages other people to do the same as Benjamin did: package the software they'd like to see become a part of Debian. We, the Debian Developers around the world, are more than happy to assist you. Just ask us (e.g. by e-mail or through IRC (#debian-mentors)).

30 March 2012

Joey Hess: podcasts that don't suck

My public radio station is engaged in a most obnoxious spring pledge drive. Good time to listen to podcasts. Here are the ones I'm currently liking.

Russell Coker: The Security Benefits of Automation

Some Random WTFs The Daily WTF is an educational and amusing site that recounts anecdotes about failed computer projects. One of their stories titled Remotely Incompetent concerns someone who breaks networking on a server and is then granted administrative access to someone else s server by the Data Center staff [1]! In one of the discussions about that I saw people make various claims about Data Center security, such as claiming that having their own locked room helps. My experience indicates that such things don t do much good, I have often been granted access to server rooms without appropriate checks. My experience is that security guards on site generally don t directly do any good. I once had a guard hold a door for me when I was removing a server from a DC without even bothering to ask for ID! On another occasion in the Netherlands I had a security guard who didn t speak English unlock the wrong server room for me, I used hand gestures to inform him that I needed access to the room with the big computers and he gave me the access I needed! It seems that the benefit of security guards is solely based on scaring people who don t have the confidence needed to bluff their way in. Preventing children from thieving is a good thing, On another occasion I showed ID and signed in for access to a DC owned by my employer and I used my security key to go through a locked door with a sign that promised many bad consequences if I failed to lock the door behind me. Then I discovered that the back door was wide open for the benefit of some electricians who were working in the building. Presumably the electricians who had no security training were expected to act as ad-hoc security guards if someone tried to enter through the back door presumably they would not have been good at it. When a company uses part of their own office for a server room then many of these problems disappear. But a common issue in such ad-hoc DCs is the lack of planning and procedures, I have lost count of the number of times I ve seen doors (and even windows) propped open to allow ventilation because there were too many servers for the air-conditioning to cope. The most ironic example of this is the company that had a walk-in safe (think of a small bank vault with concrete walls and thick solid steel door) used for storing servers but with it s door propped open to allow cooling. The advantage of a serious hosting company is that they will have procedures for cooling etc and will be very unlikely to do strange and silly things. Having a locked room in a DC makes some sense, but if security guards have the master keys and are allowed to use them then it might not do much good. The one time I locked my keys in such a room I had a guard let me in without verifying my ID or the claim that there were actually keys locked in the room. Presumably anyone could just claim to have forgotten their keys and get the door unlocked just like a cheap hotel. Locking a rack sounds like a good idea, but the racks I ve seen have had locks which are quite easy to pick. On the one occasion when I had to pick a lock on a rack (due to keys being too difficult to manage for the relevant people) the security guards didn t investigate, so either the security cameras were not supervised or they just didn t care about people picking locks in a shared server room. Also if you allow people to do things freely in a shared server room they could install devices to monitor network traffic. A locked cage in a server room should work well. In the one case where I worked for a company that used such a cage I found it to mostly work well apart from the few weeks when the lock was broken. One company that I worked for had scales before the door between a server room and the car-park to prevent people from stealing heavy servers. Of course that wouldn t stop people stealing hard drives full of data which is worth more than the servers! Also an over-weight colleague had to have the scales disabled for him (as they were based on absolute mass not unexpected changes in an individual s mass) which presumably means that any skinny employee could steal a 2RU server and still be below the mass threshold. How to Solve some of these Problems Computers are subject to all manner of security problems. But they tend not to do arbitrary things for no apparent reason and they will never give in to someone who is charming, attractive, or aggressive unlike humans. I have servers running on Hetzner, Linode, and the Rackspace Cloud. I am always concerned about possible security compromises. But I am not worried about someone climbing in a window of a server room or convincing a security guard to let them in through the door. All three of those hosting companies have the vast majority of interactions automated. I can change many aspects of the servers without involving ANY human interaction. Out of the three of those companies I have had some human interaction with Hetzner (who provide managed servers) when a hard drive needed to be replaced obviously replacing a disk in the wrong server would have been a significant system integrity issue even though everyone would be running RAID-1 and if Hetzner improperly disposed of the broken disk then there could be security issues but this is an unlikely mistake in the face of a rare occurrence. With Linode and the Rackspace Cloud (and the previous Slicehost hosting that was purchased by Rackspace) the most common interactions I have with employees of those companies are when my clients don t pay their bills on time and that s an administrative not a technical issue. When I do have to contact the support people about a technical issue it s usually something that s not immediately connected to the virtual server (EG a loss of routing to the DC). It seems most likely that there are a fairly small number of people who are allowed in the DCs for companies like Hetzner, Linode, and Rackspace. Those people would probably be recognised by the security guards and their work would be restricted to replacing failing hardware and not involve granting access requests. There are some unusual requests that they can process (EG one of my clients recently transferred a virtual server between business units) but even in those cases the administrative software controls who gets access. This is much better than just handing hardware access to what seems to be the correct physical server to a client. If you have software running a few computers and operating correctly then you can probably scale it up to run thousands of computers and have it still work correctly. But if you have a team of people controlling access requests and want to scale it up significantly then there are huge problems in hiring skilled people and training them correctly. There is a real risk of security flaws in such administrative software, if someone managed to exploit the automated management system for one of those three companies then they could probably gain access to the private data of any of their customers. But the risk of this seems a lot less than the risk of general incompetence among humans who perform routine and boring tasks which have the potential for great errors. Related posts:
  1. The Security Benefits of Being Unimportant A recent news item is the hacking of the Yahoo...
  2. Security Lessons from a Ferry On Saturday I traveled from Victoria to Tasmania via the...
  3. Public Security Cameras There is ongoing debate about the issue of security cameras,...

Next.

Previous.