Search Results: "spa"

1 June 2010

Chris Lamb: Appending the request URL to SQL statements in Django

import sys
from django.http import HttpRequest
from django.db.backends import BaseDatabaseWrapper, util
class URLCursor(util.CursorDebugWrapper):
    def execute(self, sql, *args):
        f = sys._getframe()
        while f:
            request = f.f_locals.get('request')
            if isinstance(request, HttpRequest):
                sql += ' -- %s' % repr(request.path)[2:-1].replace('%', '%%')
                break
            f = f.f_back
        return self.cursor.execute(sql, *args)
fn = BaseDatabaseWrapper.cursor
BaseDatabaseWrapper.cursor = lambda self: URLCursor(fn(self), self)
Now your SQL statements look like: 
SELECT "auth_user"."id", [..] WHERE "auth_user"."id" = 1 -- /login
This allows you to quickly go from a misbehaving query in your production environment to the view that is executing it.

MJ Ray: Hello Oslo, This is Emacs Calling

The Eurovision Song Contest has been and gone with a better-than-usual winner and much of the snarkiness was on microblog sites like identi.ca this year. Search for #ESC, #eurovision or incomprehensibly-to-me #eurovison (no second i is it spelt like that in some language, or can thousands not spell?). Anyway, enough of the title, on with the message I ve been irritated by my linphone SIP internet phone (Skype without lock-in, with standards) taking up my screen space for a while. I ve been meaning to upgrade to one of the recent versions that includes the linphonecsh shell and write some client that only displays windows when it s needed, but I ve been writing programs for work so much that I ve not even found time to write blog posts recently, much less fun code, so that s not happened. So I m quite happy to find linphone.el for my GNU Emacs text editor and find it mostly works. I changed one line at the end to (define-key global-map [menu-bar tools linphone] '("Linphone" . linphone)) to put it on the tools menu, but other than that, it just worked. Well, the Mute doesn t, but that s probably my phone headset being a different ALSA device. I don t care: I use the hardware mute button. In previous times, I would have added the link to the venerable EmacsWiki too, but it 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! Anyway, now I m controlling phone calls from Emacs. Whatever next? Voice recognition, M-x doctor and a speech synth?

Julien Danjou: Thoughts and rambling on the X protocol

Two years ago, while working on awesome, I joined the Freedesktop initiative to work on XCB. I had to learn the arcane of the X11 protocol and all the mysterious and old world that goes with it. Now that I've swum all this months in this mud, I just feel like I need to share my thoughts about what become a mess over the decades. When I was unborn

the Toto band were releasing their song "Africa" and some smart guys were working on a windowing system: the X Window System (this is its full name) which therefore has a (too) long history. The latest version of its protocol, the 11th one, has been designed in the 80's. You can learn more about the history in the Wikipedia article about X. In 2010, we still listen disco music and we still use various protocols designed in the 80's and even before X. Music have evolved, protocols have evolved, and so did X11. The problem is that X11 did not evolve that well. The guys at MIT-and-some other-places-with-very-smart-people-in-it created X version 1 in 1984, and updated it until X version 11 (the one we're still using) in 1987. Eleven version in 3 years, that was following the "release early, release often" model. But I don't know why, it just stopped to happen for the last 23 years1. I don't know what changes have been made in the first 11 major versions of the X protocol, but I'm rather sure we should have deserve a couple of major version updates this last 2 decades. In my humble opinion, X11 was not designed to live 23 years. But hey, I'm not blaming anyone here: I was 4 years old and playing Lego when they released this latest version of the X protocol, so there is little chance I'd have done something better.

1. That's not totally true: they added (and then deprecated) many extensions. We won't fix. We'll work-around.

That is probably one of the guideline of the X protocol for the last years. And don't misread me: I'm not bashing anyone thereafter. Since the X11 protocol was aging, the X guys started to add extensions. They added tons of them over the years. This, in application of one of the early principles of X:

It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.

All of them with no exception were added because, bad luck, the X11 protocol did not anticipated the things that happened in the last 23 years, like video, OpenGL, multiple monitors, or the pleasure to draw oval windows. Some of this extensions are still in use, while some of them have been dropped. While this is not a bad thing to extends the protocol, it seems like a bad thing to try to fix the protocol with for example the XFixes extension, even with all the good intentions Keith Packard might have in his greatness. Actually it's even worst than you think

The X11 protocol (without extensions) defines about 120 types of requests: create a window, move a window, etc. Nowadays, there's at least 25 % of them which are useless: usage of server-side font, or the drawing of squares and polygon, are unused by any modern application or toolkit. All of this is superseded by requests from extensions, like the XRender one. The handling of multiple monitors displays has totally been screwed up. X11 has been designed to work in Zaphod mode (independent monitors). But Xinerama, and nowadays XRandR have replaced it up: recent X servers (released after ~2007) does not support Zaphod mode anymore, even if it's a core piece of the X11 protocol. Worst: on many requests, there's limitation or design flaws, like described in this document: Why X Is Not Our Ideal Window System by DEC researchers. We'll add more broken standard on top of that

Following its early principle, X does not define policies but only mechanisms, which seems like a good thing, Consequently, people started writing specifications to determine a number of stuff and dogmas: ICCCM. That was 22 years ago in 1988. It's useless to add that many things in this specification are now obsolete, useless, or that it misses many modern stuff. I was not the only one to think that. The people from what will be the major desktop environments, KDE and GNOME, saw that too in the 90's while I was learning to count. So they wrote EWMH, another standard that comes on top of ICCCM and extends it with nifty features like maximization, full screen mode, etc. The problem is that this standard has also been written by narrow-minded people who at that time, were working on GNOME or KDE (and maybe others). This desktop environments were having and still have some strong concepts of how should work a desktop: "it should have work-spaces", "a window is only on one workspace", "we only see a workspace at a time", "you do not have multiple screens", etc. Dude, we don't care: we have toolkits!

This vision of how the desktop should work have now been written in marble in all applications and libraries implementing EWMH, like GTK+ or Qt. Nowadays, everybody forgot about all of this standards. Toolkits have implemented this, circumvented the X11 protocol limitation and flaws, and nobody wants to look back. Like all standards, obviously some people implemented them badly. This had some side effects, like OpenOffice acting like a pager. We don't look back? Worst, we forgot where we came from!

With all these layers of bad designed standards, the desktop continued to evolve for more than a decade. They continued to add more standard, the more recent ones being based on D-Bus like the Desktop Notification Specification or the latest Status Notifier Specification developed by KDE. The Status Notifier is a new implementation of the good old system tray based on XEmbed, using D-Bus instead of the X11 mechanisms, and adding the possibility to show the system tray with something else than icons. This specification draft saw an important issue and design flaw raised by Wolfgang Draxinger in this thread on the XDG mailing-list. What Wolfgang points out, is that X is network-oriented, and D-Bus is not. Therefore, making the Status Notifier specification to use D-Bus to pass system tray messages around is a bad idea, since running a X application from host A on host B will draw the system tray on the wrong host! Apparently, reading the thread, this does not fear some of the KDE people:

of course this is a bizarre corner case not worth much thought. at least that's what you'll think until you actually run into it yourself (be it because you are testing something or because you are setting up some weird kiosk environment).

What Oswald describes as a corner case is an actual common use case for many of us. Of course, YMMV. From my point of view, this is a step back in the wrong direction. But we can conclude that the network part of X is now worthless, to at least KDE. I used to believe in XCB

When I joined Freedesktop, it was to work on XCB, the X C Binding. XCB is a nice, clean, 21st century technology based API to play with the X11 protocol. Its code is auto generated based on XML file describing the protocol. In comparison, Xlib is 80's obfuscated code with almost no comments and hard-coded things. Only a few people can understand some of its corner like its i18n or XKB implementations. And all its code is synchronous. For people not knowing it yet, X is a network protocol where you send request (like a GET in HTTP) and then get a response. Xlib forces the application to wait for the reply to its request, so the application is blocked until the X server sends the reply to the request. XCB on the other hand does not block and allows the application to send a batch of requests, do some other stuff in the mean time, and then gets the replies. It's like your Web browser would send one request at a time to a Web server, and would wait until you downloaded all the images one by one to display the page. In cases where X and all its clients are on the same host, the latency is small and not really visible, therefore the gain for XCB to be asynchronous is small. On slow network however, the gain can be huge, as proved in the rewrite of xlsclients with XCB by Peter Harris. One of the long standing goal of the XCB folks is to kick-out Xlib, to increase speed and hides latency in X11 applications. That requires to port many libraries, because almost none of them (Cairo being an exception) supports XCB. From where I stand, I don't really see if the work is worth it now. The desktop world is trusted by GNOME and KDE, meaning GTK+ and Qt. It seems none of this toolkits are interested to work on XCB, neither on the X protocol. They probably put hard effort in bypassing X limitation and flaws, and they now sit on top of crap of workarounds and broken-by-design-standard implementation. It seems to me they don't want to go back in the layers and improves things. They're too high to go back down and they don't see what the gain would be. Enlightenment with its EFL was the first toolkit to have an XCB back-end with the work of Vincent Torri. Unfortunately, the back-end is not maintained and nobody cares about it. Last time I tried it, it did not compile at all. X12 ?

There's a page called X12 on the Freedesktop wiki, listing all the things that should be fixed some days. Unfortunately, the list continues to grow up an no one talks about working on X12. On the other hand, there's a handset of people trying to work when they will have time on XKB2, the second version of the "let's-try-to-fix-up-the keyboard-part-of-the-protocol-we-wrote-23-years-ago-a-second-time" extension. To me, it does not seem X12 will happen in the next decade neither. Alternative ?

Do we got alternative to X ? There's Wayland, but it's far from being usable. There's DirectFB, but that's not very portable. None seems candidate to replace X some days to me. Anyhow, none of the main toolkits around support this alternative. GTK+ once supported DirectFB, but as far as I know, it is not supported nor works nowadays, as stated by Josselin Mouette. This is why recent versions of the Debian installer have migrated to X for the graphic part, thanks to Cyril Brulebois work. Conclusion

XCB has been around for more than half-a-decade, and very few people showed interested in it. As far as I can see, nobody is interested to use the X protocol and everybody tries to encapsulate it in some higher-level API as soon as possible to stop seeing it. This leads to poorly written application and toolkits, with a lot of ugly hack. All of that also means that starting to write applications and graphical toolkits based on XCB would be a very interesting project, but that would lead to spend too much time learning to circumvent the X protocol flaws, things that have been done in years by predecessors like Qt and GTK+. Major toolkits implementations have almost nothing to win in going back in the dark water of X. I guess most of their folks prefer to work on shiny 3D effects based on your GPS location, rather than redefining better basis for everyone. The manpower available in the X world is very small. Debian lacking of X maintainers is just the summit of that. There is very smart and very competent and skilled guys in the X world, as you can see by simply reading blog posts on Planet Freedesktop for example (me excluded). Unfortunately, there's not enough of them to cover all the things involved in X: input devices, graphics devices, new protocol extension specification and so on. The X server is really late, and it seems most of the developers prefers to work on the server itself than on the protocol behalf. Which is understandable. I'm curious to see where all of that will lead in the upcoming years. I've been walking in the X world hallways for about 3 years now, and I feel desktop alternatives to KDE and GNOME will all die sooner or later. The time were you could choose between a dozen "modern" window managers has passed away. After all, maybe that is simply Darwinism applied to computer software.

31 May 2010

Neil Williams: multistrap 2.1.5

multistrap is gaining some important functionality. When preparing a root filesystem for a new product, the sources used to generate the system need to be made available. So, multistrap has an option to retain the sources and 2.1.5 adds the functionality of downloading the source packages to go alongside the binaries that are downloaded to make the system itself, into a directory outside the final system.

Equally, 2.1.5 includes the idea (contributed by Rodolfo Giometti) of not listing deb-src entries inside the final filesystem - a useful idea to save space on systems where there is no likelihood of sources actually being downloaded "on-device".

Also in 2.1.5, is a handler for device tables. udev is one thing but when creating new systems from scratch, some devices still need to be created with mknod. MAKEDEV is too general, creating dozens of nodes when maybe only a handful are needed yet also omitting device nodes that actually are needed. So, /usr/share/multistrap/device-table.pl can parse a mini device table file (a tab-separated-value file), creating directories, symlinks and device nodes in a specified directory.

The aim is to combine the entire generation of a bootable root filesystem in a single call to multistrap - to which two further steps are necessary.
  1. Packing up into a tarball at the end

  2. Running a customised script outside the eventual filesystem, passing it the location and architecture of the filesystem.


Both are in 2.1.5 - the config script can be used to pre-seed debconf questions, write out custom configuration changes, run the device table parser and various other tasks.

As with earlier versions, multistrap supports creating package building chroots (including cross-building chroots) and, to go alongside this functionality, pdebuild-cross has now entered unstable. pdebuild-cross is a set of hooks for pbuilder to support cross-building inside a pbuilder chroot created by multistrap.

I'm hoping to be able to cover more about these issues at DebConf10.

If debootstrap is not doing what you need, multistrap is probably the answer - and if it doesn't quite do what you need yet, ask.

Marco Túlio Gontijo e Silva: Summer of Code weekly report #3

My project This week I followed an advice of my mentor, Simon Marlow, and started to play with the code including print statements in interesting places in order to understand it s flow. It s indeed much better than just reading the source code and the documentation on the wiki. As usual, I had a lot of doubts about some parts of the code, and noted them down. But now, I m seeing that I m resolving most of them just by playing more with the code, without need to ask in the mailing list. There are still some left, and I m planning to send them to the list in a next oportunity. The first thing I noticed was the high number of objects, from my perspective, that are created and collected in: main = return () I measured how much times evacuate() was called. This function moves an object to the next generation of the Garbage Collector. It s called 775 times, in 1 call to GarbageCollect(), with 479 different objects (with different pointers to their Info Tables). Also, there were pinned objects and large objects in this count. This was surprising to me. I also made a small draw of the memory allocation in lines using diagrams. The draw: The source code: import Prelude hiding (tan)
import Control.Monad
import Data.Colour.RGBSpace
import Data.List
import Graphics.Rendering.Diagrams
import System.Random objectMaxLength :: Double
objectMaxLength = 50 objectMinLength :: Double
objectMinLength = 10 nObjects :: Int
nObjects = 10 main :: IO ()
main
= do
objects <- replicateM nObjects $ randomRIO (objectMinLength, objectMaxLength)
let objects = [18,50,12,46,16,41,14,30,49,23]
renderAs PNG "mem.png" Auto
$ vsep
10
[text 40 "(1)" <> continuous objects
, text 40 "(2)" <> lineByLine objects
, text 40 "(3)" <> allocated] continuous :: [Double] -> Diagram
continuous = memory colors lineByLine :: [Double] -> Diagram
lineByLine = memory (intersperse white colors ++ [white]) . objectsLine allocated :: Diagram
allocated
= memory
(intersperse white colors ++ [white])
[18, 82, 50, 0, 12, 0, 46, 0, 16, 0, 41, 35, 14, 0, 30, 0, 49, 7, 23] objectsLine :: [Double] -> [Double]
objectsLine [] = []
objectsLine (x : xs) = x : objectMaxLength x : objectsLine xs memory :: Color color => [color] -> [Double] -> Diagram
memory colours objects
= unionA
top
left
[hcat
$ map (uncurry fc)
$ zip (cycle colours)
$ map (lw 0 . flip rect objectMaxLength) objects
, lines_] lines_ :: Diagram
lines_ = hcat $ replicate nObjects $ rect objectMaxLength 50 colors :: (Ord colour, Floating colour) => [Colour colour]
colors
= [red, green, blue, yellow, magenta, cyan
, darkred, darkgreen, darkblue, darkmagenta, darkcyan]

Piotr Galiszewski: The end of the first mockups iteration

Last week was very busy for me. Unfortunately, I spent most of my time no my study duties. An exam session is fast approaching, so in next 3 weeks the situation will not be better. But as I promised, during second part of week, I am working full time on my project.

So, here are missing mockups of future Aptitude Qt GUI:

Changes Preview tab:

Only one "Preview Tab" can be opened at the same time. Changes will be live updated here.

Resolver:

Perform Changes tab:


This time I am not too innovative. I think that current Aptitude GTK design for this tabs is quite intuitive and good-looking, so I have added only minor tweaks.

To sum up mockups topic, below are links to all presented mockups (with some comments which raises during my recent private discussions). Now, I am open for any suggestions and comments about current design. At the end of next week, second iteration will be presented. Depending of the level of required changes there could be third iteration, before sending mockups to Piotr "Patpi" Pe zowski, who is the person behind Kadu Usability Project. I am glad that he agreed to spend his spare time and help me with this task :)

Packages tab:

This tab in second iteration will have only small changes. I was told that will be nice to select multiple categories at the same time. I agree, so categories list will support multi selection. There will be also an option in configuration window (There is no mockup now. Currently, I do not know what option will be configurable and it is not the most important thing at this stage. The window will be patterned upon KDE configuration windows) to move this list on the right side of this tab.

It will be possible to have multiple "Packages tabs" opened at the same time. It will not be allowed to close first "Package Tab". Ctrl + T shortcut, action in main menu and toolbar (I have forgotten about toolbar in this iteration - maybe it is not necessary?) will open new tab. There will be also an option that each text search will do this. I will try to add shortcuts wherever is it possible to allow using the GUI without mouse.

"Show changes" button will be change to "Resolve dependencies" when necessary.

Updates widget:

Most of the comments from "Packages tab" apply here too. In the table showing updates will be also "Current Version" column.


Package Informations tab:

Only one clarification: multiple "Packages Informations" tabs for the same package will not be allowed.

I am looking forward to read any comments regarding presented design. Please leave comment below this post or contact me directly (see About Me page).

On Monday/Tuesday I will write first weekly report.

Cheers.

Piotr Galiszewski: Hello Word

Hello Planet Debian readers!

I've never thought that such a thing can ever happen, but I've started blogging ;) So now it is time to introduce myself.

My name is Piotr Galiszewski and I am second year student of computer science at AGH - University of Science and Technology in Krakow (Poland). I have been GNU/Linux user for about 5 years (mostly Debian based distributions).

Thanks for Debian and Google, this summer I will be working on creating Qt-based user interface for aptitude as my Google Summer of Code project. I hope that my mentors Sune Vuorela and Daniel Barrows will be patient with me ;) I am sure I will learn a lot from them. Please look at abstract of my project made by Debian GSoC administrator Obey Arthur Liu:
Qt GUI for aptitude. Currently, KDE users need to use Aptitude via the console interface, or install the newly developed GTK frontend, which does not fit well into KDE desktop. Making Qt frontend to Aptitude would solve this problem and bring an advanced and fully Debian-compliant graphical package manager to KDE.
As I wrote in my proposal I will split my work into three main parts:
  1. writing low level classes which will abstract aptitude signals and slots (which uses sigc++) into Qt slots and signals.
  2. creating and evaluating GUI mockups
  3. implementing GUI on top of classes from the first point
Point 1 and 2 will be made simultaneously and will take all May and half of June. Low level classes should implement all necessary functions for further use in GUI. This classes allow me to avoid direct usage of none Qt code in GUI classes and also give much more time to prepare completed and usability-wise mockups. Every mockups version will be presented and discussed on this blog. First version should be ready in next few days and updates will appear each week (or to weeks).
After finishing this two steps I will start coding GUI. With mockups and finished low level classes this should not be complicated (Yeah, I know that this is only my dream).

Full text of my proposal (including more precise time-line) can be found at Debian wiki.

Currently, project is slightly behind the schedule . It is caused by changes in my studies plan. The Juwanalia students' festival took place earlier, and yesterday it finished. But my first exam will take place one week later on 18 May, so I will have more time to catch up with time-line.

This project is my first direct contribution to Debian, but not first involvement in free software movement. I've been Kadu Instant Messenger developer for more then two year. In last two years I have been second most active developer with more than 700 commits in master branch. During GSoC period my Kadu activities will be limited. If time allows me to do this, I will be still contributing to Kadu. I still can be found at Kadu forum or #kadu channel on irc.freenode.net. I will also continue reviewing patches and fixing low time-consuming bugs.

My plans for the next few days:
If you have any thoughts about this project, please add comment to this post or contact me directly. I will be glad to read all yours opinions

Cheers

PS. As you can see English is not my mother tongue, so please forgive me my mistakes

30 May 2010

Erich Schubert: Wikipedia contributors are one of a kind

The last weeks, I've occasionally been contributing to Wikipedia. I must say, Wikipedia is a really odd world of its own. Another thing I found quite surprising is the difference between the English and the German Wikipedia.Some things I noticed: So on overall: keep away from Wikipedia contributors, they're all maniacs. And often, don't bother to read a Wikipedia article if you can get an appropriate textbook. The Wikipedia article will just try to sell you a dozen textbooks anyway; you'll also have to read them to check the validity.It is a pity, that despite its size and "eyeballs", Wikipedia so far seems to have not attracted much attention by actual "domain experts", but it seems that it is largely filled by bureocrats, zealots and promoters. (That don't have any real work to do?)There are many things wrong here, that have been pointed out by many others, too. I'm not going to rescue the Wikipedia world, either. And yes, I am aware that you can discuss in Wikipedia, too. I fear that Wikipedia will go the DMOZ road. There was a time that DMOZ was doing quite well. Nowadays, large parts of DMOZ are dead. For two main reasons: it's hard to get in, and the backlog is way too large. If you get into DMOZ for a larger category, you'll be faced with thousands of pending link submissions, where for a large part you don't feel qualified to judge on appropriateness or rewrite their description in a neural manner. I have the impression that the same is happening for Wikipedia: on one hand, users that join are often kicked badly for many of their first contributions and will just leave again. At the same time, many of the old articles are in desparate need for attention, but nobody of the established users is willing to spend the days of cleanup/rewriting needed to get the article into a useful shape again. And a new user will never dare to discard most of the existing article; they usually just add or modify single paragraphs to see what happens. So Wikipedia might be hitting some kind of barrier.Still, I have to admit that I frequently use Wikipedia to look up things. Usually because it just comes up first in Google. I then often follow links to better resources, such as MathWorld. And I wish, Google would have taken me there right away ...And don't assume I'd know how to run things better. I'd sure propose to spend more time at fixing existing articles instead of attacking new contributions that much (you'll lose contributors this way). But I also see the need for fighting spam (although you should also remove old spam ...). But I don't know if there is a solution that will actually attract domain experts to re-write all the badly written and inaccurate articles that don't have their personal zealot to patrol them.P.S. Sorry, no comments on my blog. This isn't Facebook. Instead of commenting on my blog, how about working on Wikipedias backlog instead?P.S. Another example is the German Wikipedia story surrounding Fefe's blog. Many here at the open source communities will know fefe for his work on Dietlibc, libowfat and similar highly respected open source projects. His blog has been famous for being high-quality in security, privacy topics, politics and media critics. Some of his fans (likely) started a Wikipedia page on his blog. There have been at least two huge discussions about deleting the Wikipedia page. "sock puppets" and all such things have been brought up, while Fefe himself was amused. The discussions around deleting the blogs page on Wikipedia made it all the way to the print newspapers. As I said, I'm not actually bringing up new critique on Wikipedia. It's an ongoing problem for years now.[Insert random Deletionism rant against Wikipedia]

29 May 2010

Bernd Zeimetz: installing debian on the guruplug server plus

Yesterday finally my GuruPlug Server Plus arrived. Took longer than expected, but as it seems Globalscale had some issues with the power supplies and they were replaced before shipping the GuruPlugs. GuruPlug Server Plus and JTAG Board

The GuruPlug Basically the GuruPlugs are an enhanced version of the well known SheevaPlugs, the biggest difference is probably the need for an external JTAG/UART<>RS232 board to access the serial console. Good thing is that the board comes with a normal JTAG connector and an additional RS232 connector and 2.5V DC power outlet, so it will be useful for other devices, too. Globalscale could have chosen different connectors with less wiggly cables, though. As I was not able to find a useful howto about installing Debian on the Guruplug, I've written down what I did to install Debian unstable on a micro SD card using the Debian installer for the GuruPlug. I did not have a look who modified the Debian installer to work on the plug, but thanks for that! The instructions below are based on Martin Michlmayer's awesome SheevaPlug documentation, the hints from oinkzwurgl.org/guruplug and various forum posts in the plugforum.

Preparations Please note that I'm not resposible for whatever you're doing with your plug. If you follow this tutorial and end up with a brick, it is your fault, not mine. To install the GuruPlug you need the JTAG Board. Connect the UART port to the GuruPlug and the JTAG board to your computer, it should show up as FTDI (thanks for using good chips!) USB<>Serial converter. Serial port settings are 115200, 8-N-1, no hw/sw flow control. The other thing you should prepare is a working tftpd, I'm using aftpd. 
apt-get install aftpd
Recent versions share files from /srv/tftp/, in case you're running Lenny /var/lib/tftpboot/ should be the place to drop your files. When everything is connected properly the boot process should show up in minicom, make sure to press some key to enter uBoot. The first thing you should do is to save the original uBoot environment in case you want to restore the factory settings later. Run 
printenv
and save the output somewhere.

Upgrading uBoot Unfortunately the uBoot version on the GuruPlug is pretty old and seems to have some issues in booting from USB devices, so the first thing you should do is to upgrade it. You might want to investigate if there is even a better, more recent uBoot version available somewhere, or build one on your own, but I didn't bother and took the uBoot.guruplug.bin from here. The main issue with that is that booting from USB still seems to be buggy (even for FAT partitions) and that ext2load is still not supported. Otherwise it works well :-). I'm mainly following Martin Michlmayer's tutorial again. Download the uBoot.guruplug.bin and drop it into the tftpd directory. Make sure you always set the plug's IP address (ipaddr) and your server's IP address (serverip) properly. I'll use 192.168.121.253 for the plug and 192.168.121.2 for the server in all examples, make sure to change that for your own needs. Stop if something goes wrong, especially when the tftp download failed. 
setenv ipaddr 192.168.121.253
setenv serverip 192.168.121.2
tftp 0x6400000 uBoot.guruplug.bin
nand erase 0x00000000 0x0100000
nand write 0x6400000 0x0000000 0x80000
reset
Enter uBoot again after the reset.

Preparing the installer Download uImage and uInitrd to your tftpd directory. Although I've heard that setting mainlineLinux/arcNumber in the uBoot environment is not necessary anymore for very recent kernel, lets set them to make sure the Debian kernel works: 
setenv mainlineLinux yes
setenv arcNumber 2097
saveenv
reset
Again, enter uBoot after the reset.

Running the installer Run the following in the uBoot console: 
setenv ipaddr 192.168.121.253
setenv serverip 192.168.121.2
tftpboot 0x01100000 uInitrd
tftpboot 0x00800000 uImage
setenv bootargs console=ttyS0,115200n8 base-installer/initramfs-tools/driver-policy=most
bootm 0x00800000 0x01100000
You should see the installer starting now. You might want to follow the following hints:
  • Before configuring the network, go back and set the debconf priority to low, Then continue. While chosing the Debian mirror, chose sid as the Debian version to install. If you don't have sid as choice, use a different mirror. The kernel in testing does not boot on the GuruPlug, you need 2.6.32-13 from sid.
  • You might want to load the 'network console' installer component and continue via ssh. Makes things fater and colourful.
  • Suggested partitioning: I've installed Debian to an 8GB micro SDcard. The SDcard reader is connected via USB and shows up as /dev/sdb (/dev/sda should be the internal NAND and not shown by the installer). I've used 150MB ext2 for /boot and the rest of the space for /, using ext4. You might want to use the noatime option on both filesystems to avoid unnecessary write access to the SDcard. You might choose to add a swap partition, but SDcards are so slow, so I've skipped that.
When you continue the installation, you will hit the following problem:
  • The installer might fail on 'Make the system bootable' (not sure if it does for you, it did so with the kernel from testing).
  • The uBoot is not able to boot from your /boot anyway. USB support is buggy and ext2load missing.
We'll work around these issues by writing the kernel and initrd into the plug's NAND. To do so, enter a shell in the installer and chroot into the install target. We'll then create the necessary uImage.bin and uInitrd and scp them to our tftpd directory: 
chroot /target /bin/bash
cd /boot
mkimage -n vmlinuz -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -d /boot/vmlinuz uImage.bin
mkimage -n 'vmlinuz initrd' -A arm -O linux -T ramdisk -C gzip -d /boot/initrd.img uInitrd
scp uI* root@192.168.121.2:/srv/tftp
Now leave the shell, finish the installation and reboot, enter uBoot again.

Make the plug bootable To write kernel and initrd to the NAND memory, we have to transfer it via tftp first, then erase the NAND area we want to write to and then write it to the NAND. The values I've chosen here should be fine for the current Debian kernel, but you might need to change the necessary size for the initrd. To do so have a look at the output while transferring the initrd - the transferred bytes are displayed. They have to fit into the amount of bytes you write (the last option to nand write.e). 
setenv ipaddr 192.168.121.253
setenv serverip 192.168.121.2
tftp 0x6400000 uImage.bin
nand erase 0x100000 0x400000
nand write.e 0x6400000 0x100000 0x400000
tftp 0x6400000 uInitrd
nand erase 0x500000 0x1fb00000
nand write.e 0x6400000 0x500000 0x600000
Now we need to set the necessary boot options. Make sure to change the root device if you've chosen a different layout from that I've suggested above, or if you're not using a SDcard. 
setenv bootargs_debian 'console=ttyS0,115200 root=/dev/sdb2'
setenv bootcmd_nand 'nand start; nand read.e 0x00800000 0x100000 0x400000; nand read.e 0x01100000 0x500000 0x600000'
setenv bootcmd 'setenv bootargs $(bootargs_debian); run bootcmd_nand; bootm 0x00800000 0x01100000'
saveenv
run bootcmd

Finish Your GuruPlug should boot your new Debian installation now. Have fun! I'll try to keep the howto updated for changes in uBoot and the installer, but I might not have the time to so quickly. Patches and comments are welcome!. 
root@guruplug:~# uname -a
Linux guruplug 2.6.32-5-kirkwood #1 Fri May 21 05:44:29 UTC 2010 armv5tel GNU/Linux
root@guruplug:~# cat /proc/cpuinfo 
Processor   : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS    : 1192.75
Features    : swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part    : 0x131
CPU revision    : 1
Hardware    : Marvell GuruPlug Reference Board
Revision    : 0000
Serial      : 0000000000000000
root@guruplug:~#

Russell Coker: Logging in as Root

Martin Meredith wrote a blog post about logging in as root and the people who so strongly advocate against it [1]. The question is whether you should ssh directly to the root account on a remote server or whether you should ssh to a non-root account and use sudo or su to gain administrative privileges. Does sudo/su make your system more secure? Some years ago the administrator of a SE Linux Play Machine used the same home directory for play users to login as for administrative logins as for his own logins he used newrole to gain administrative access (like su or sudo but for SE Linux). His machine was owned by one of his friends who created a shell function named newrole in one of his login scripts that used netcat to send the administrative password out over the net. He didn t immediately realise that this was a problem until his friend changed the password and locked him out! This is one example of a system being 0wned due to having the double-authentication of course if he had logged in directly with administrative privs while using the same home directory that the attacker could write to then he would still have lost but the attacker would have had to do a little more work. When you login you have lots of shell scripts run on your behalf which have the ability to totally control your environment, if someone has taken over those scripts then they can control everything you see, when you think you run sudo or something they can get the password. When you ssh in to a server your security relies on the security of the client end-point, the encryption of the ssh protocol (including keeping all keys secure to prevent MITM attacks), and the integrity of all the programs that are executed before you have control of the remote system. One benefit for using sshd to spawn a session without full privileges is in the case where you fear an exploit against sshd and are running SE Linux or some other security system that goes way beyond Unix permissions. It is possible to configure SE Linux in the strict configuration to deny administrative rights to any shell that is launched directly by the sshd. Therefore someone who cracks sshd could only wait until an administrator logs in and runs newrole and they wouldn t be able to immediately take over the system. If the sysadmin suspected that a sshd compromise is possible then a sysadmin could login through some other method (maybe visit the server and login at the console) to upgrade the sshd. This is however a very unusual scenario and I suspect that most people who advocate using sudo exclusively don t use a SE Linux strict configuration. Does su/sudo improve auditing? If you have multiple people with root access to one system it can be difficult to determine who did what. If you force everyone to use su or sudo then you will have a record of which Unix account was used to start the root session. Of course if multiple people start root shells via su and leave them running then it can be difficult to determine which of the people who had such shells running made the mistake but at least that reduces the list of suspects. If you put PermitUserEnvironment yes in /etc/ssh/sshd_config then you have the option of setting environment variables by ssh authorized_keys entries, so you could have an entry such as the following: environment= ORIG_USER=john@example.com ssh-rsa AAAAB3Nz[...]/w== john@example.com Then you could have the .bashrc file (or a similar file for your favorite shell) have code such as the following to log the relevant data to syslogd:
if [ "$SSH_TTY" = "" ]; then
logger -p auth.info "user $ORIG_USER ran command \"$BASH_EXECUTION_STRING\" as root"
else
logger -p auth.info "user $ORIG_USER logged in as root on tty $(tty)"
fi I think that forcing the use of su or sudo might improve the ability to track other sysadmins if the system is not well configured. But it seems obvious that the same level of tracking can be implemented in other ways with a small amount of effort. It took me about 30 minutes to devise the above shell code and configuration options, it should take people who read this blog post about 5 minutes to implement it (or maybe 10 minutes if they use a different shell or have some other combination of Bash configuration that results in non-obvious use of initialisation scripts (EG if you have a .bash_profile file then .bashrc may not be executed). Once you have the above infrastructure for logging root login sessions it wouldn t be difficult to run a little script that asks the sysadmin what is the purpose for your root login and logs what they type. If several sysadmins are logged in at the same time and one of them describes the purpose of their login as to reconfigure LDAP then you know who to talk to if your LDAP server stops working! Should you run commands with minimum privilege? It s generally regarded that running each command with the minimum privilege is a good idea. But if the only reason you login to a server is to do root tasks (restarting daemons, writing to files that are owned by root, etc) then there really isn t a lot of potential for achieving anything by doing so. If you need to use a client for a particular service (EG a web browser to test the functionality of a web server or proxy server) then you can login to a different account for that purpose the typical sysadmin desktop has a dozen xterms open at once, using one for root access to do the work and another for non-root access to do the testing is probably a good option. Can root be used for local access? Linux Journal has an article about the distribution that used to be known as Lindows (later Linspire) which used root as the default login for desktop use [2]. It suggests using a non-root account because If someone can trick you into running a program or if a virus somehow runs while you are logged in, that program then has the ability to do anything at all of course someone could trick you into running a program or virus that attempts to run sudo (to see if you enabled it without password checks) and if that doesn t work waits until you run sudo and sniffs the password (using pty interception or X event sniffing). The article does correctly note that you can easily accidentally damage your system as root. Given that the skills of typical Linux desktop users are significantly less than those of typical system administrators it seems reasonable to assume that certain risks of mistake which are significant for desktop users aren t a big deal with skilled sysadmins. I think that it was a bad decision by the Lindows people to use root for everything due to the risk of errors. If you make a mistake on a desktop system as non-root then if your home directory was backed up recently and you use IMAP or caching IMAP for email access then you probably won t lose much of note. But if you make a serious mistake as root then the minimum damage is being forced to do a complete reinstall, which is time consuming and annoying even if you have the installation media handy and your Internet connection has enough quota for the month to complete the process. Finally there are some services that seek out people who use the root account for desktop use. Debian has some support channels on IRC [3] and I decided to use the root account from my SE Linux Play Machine [4] to see how they go. #debian has banned strings matching root. #linpeople didn t like me because Deopped you on channel #linpeople because it is registered with channel services . #linuxhelp and #help let me in, but nothing seemed to be happening in those channels. Last time I tried this experiment I had a minor debate with someone who repeated a mantra about not using root and didn t show any interest in reading my explanation of why root:user_r:user_t is safe for IRC. I can t imagine that good the #debian people expect to gain from denying people the ability to access that channel with an IRC client that reports itself to be running as root. Doing so precludes the possibility of educating them if you think that they are doing something wrong (such as running a distribution like Lindows/Linspire). Conclusion I routinely ssh directly to servers as root. I ve been doing so for as long as ssh has been around and I used to telnet to systems as root before that. Logging in to a server as root without encryption is in most cases a really bad idea, but before ssh was invented it was the only option that was available. For the vast majority of server deployments I think that there is no good reason to avoid sshing directly as root.

28 May 2010

Russell Coker: Brother MFC-9120CN Color LASER Printer

I have just bought a Brother MFC-9120CN Multi-Function Color LED LASER Printer for a relative. It was a replacement for the Lexmark printer which turned out not to support Linux properly [1]. This printer cost about $545. I bought it from OfficeWorks [2] under their price-matching deal. If you find a better price anywhere else they will beat it by 5%. I went to StaticIce.com.au and found the cheapest online store in Australia that sold the printer and then took the URL of the online store to OfficeWorks on a USB stick. After they verified the price they sold me the printer for 5% less than the online cost plus the delivery cost, which saved my relative a little more than $50. Craig Sanders had convinced me to choose a LASER printer because the toner doesn t have a short shelf-life unlike the ink for ink-jet printers. My parents have been using a LASER printer for more than 12 years and each toner cartridge lasts at least 4 years which is a much better result than all the ink-jet printers I ve supported which tend to regularly need more expensive ink. I guess I ll find out over the next few years whether this printer lives up to the general reputation of LASER printers in this regard. The LED printers use LEDs for the LASER light, this apparently makes them more reliable and efficient but means that they tend to have a lower resolution, and often the horizontal and vertical resolutions are not equal. The printer I got is listed as 600*2400dpi resolution but that might end up giving much the same result as a 600*600dpi printer. But 600*600dpi should be good enough for a long time anyway. A4 paper (the standard size for office paper in Australia) is 210*297mm, that is about 8.27*11.69 inches or 4961*7015 pixels at 600dpi. Even if we assume that 10% of the width and height is wasted on margins that would take a 28 megapixel camera to produce a picture that can actually use 600dpi for the most common case where high quality is needed for home use printing a single photo on an A4 sheet. The printer ships with 64M of RAM which was not enough to print some pictures that I sent it, it has a slot for a 144pin SO-DIMM (laptop RAM) for memory expansion, it can take one SO-DIMM of up to 512M capacity that is at least PC-100. I ve got a spare 256M PC-133 memory module that I will install in it, hopefully that will be enough to print pictures. Buying PC-100/PC-133 RAM nowadays probably isn t going to be easy, particularly not 512M modules as many of the laptops which used PC-100/PC-133 RAM didn t support that capacity (I believe that my ancient Thinkpads which used such memory didn t support 512M modules). The requirement was for a printer that could print photos in reasonable quality, could make photo-copies, and ideally work as a scanner. I got CUPS to talk to it without much effort, I just installed a PPD file from the Brother Solutions Center web site [3] and it just worked. It occurred to me later that I should have tried configuring it before installing the PPD file maybe the version of CUPS in Debian/Squeeze supports the Brother printer natively. So the current state of the printer is that it prints documents very well, it doesn t print photos but that should be solved when I add more RAM, and I just have to try and get scanning to work. Everyone is happy! The only down-side is that the printer is huge. It takes a lot of desk space to run it (they will need a new desk in their computer room), and when it s in it s box it s much larger than most things that you will normally transport by car. Update: I ve installed a 256M PC-133 SO-DIMM and can now print full color pictures. Thanks for Rodney Brown for giving me some Thinkpad parts which included RAM.

27 May 2010

Petter Reinholdtsen: Parallellized boot seem to hold up well in Debian/testing

A few days ago, parallel booting was enabled in Debian/testing. The feature seem to hold up pretty well, but three fairly serious issues are known and should be solved: All in all not many surprising issues, and all of them seem solvable before Squeeze is released. In addition to these there are some packages with bugs in their dependencies and run level settings, which I expect will be fixed in a reasonable time span. If you report any problems with dependencies in init.d scripts to the BTS, please usertag the report to get it to show up at the list of usertagged bugs related to this. Update: Correct bug number to file-rc issue.

Rapha&#235;l Hertzog: Rewriting update-alternatives in C

Among the goals listed in dpkg s roadmap, there s the C rewrite of the remaining perl scripts provided by the dpkg binary package (dpkg-dev is not concerned, it will remain a collection of perl scripts). Of the remaining scripts, update-alternatives was the largest piece of code (~1100 lines of perl) and I started converting it to C a few weeks ago (based on preliminary work of Guillem). It s now 2200 lines of C Thanks to the relatively extensive test-suite that I wrote last year, I m relatively confident that this new update-alternatives won t break your system. That said, it still needs some real-life usage to ensure everything is really ok (and users actively trying to break it are even better). Thus I would be glad if you could try it out ( binary package for i386 or .dsc) and report back to debian-dpkg@lists.debian.org. The rewrite of the 2 other remaining scripts is almost completed in a branch of Guillem. Hopefully this can be our last project completed in time for Squeeze as far as dpkg goes. It would be a great achievement for people that would like to use dpkg in embedded environments and avoid perl due to its size. Note: nobody sponsored that work. But it s not too late :-) Partagez cet article / Share This

26 May 2010

Nico Golde: fail2ban + dns = fail

fail2ban is used by many people to prevent certain types of DoS attacks. I use it myself to reduce trackback spam a little bit.

While this tool becomes quite handy in such situations it is also not generally recommend because you can shoot yourself in the foot. If one of the used filters has a bug and results in incorrect parsing your fail2ban installation might end up banning arbitrary IP addresses or even your own IP range (not even mentioning IP spoofing).
There existed at least two bugs of this kind to my knowledge and since regex might not always be easy I'm sure there will be more in the future.

Since I didn't want to look for a specific regex bug in one of the filters I thought about IP spoofing again and looked at fail2bans filters. What I needed was a filter processing log entries of a service listening on a UDP socket as TCP/IP spoofing over the internet doesn't really work well these days. Finding such a filter would mean an instant win situation. To my surprise there is such a filter: config/filter.d/named.conf

This filter is used to parse log entries consisting of denied DNS queries produced by bind. Interestingly there is even an article at debian-administration describing how to setup fail2ban to mitigate a DNS DDoS attack. This is of course a bad idea and I have no idea why this filter is shipped in a default fail2ban installation. DoSing abritary IP addresses with this filter in use becomes as easy as firing up scapy and querying the server with a forged source IP:

>>> send(IP(dst="81.169.172.197",src="xx.46.63.71")/UDP()/DNS(rd=1,qd=DNSQR(qname="foao.modprobe.de")))
.
Sent 1 packets.

This ends up as:
May 26 22:32:22 modprobe named[30245]: client xx.46.63.71#53: query 'foao.modprobe.de/A/IN' denied

in the bind logs which in turn results in:
2010-05-26 22:32:05,551 fail2ban.actions: WARNING [named-refused] Ban xx.46.63.71

In this example the spoofed IP was xx.46.63.71 which is not under my control.

Mission statement: don't use fail2ban unless you really want to shoot yourself in the foot or know pretty well what you're doing :-)

25 May 2010

Gunnar Wolf: One more fatal accident in my usual environment

I was about to close down a good day of hard work, a heavy but useful day... I had even decided to take some time off to listen to some good music, and was heading off to bed on a good mood... Until I decided to read my contacts' latest rants. And I found very sad news - again. A ten year old kid was killed while cycling in Calle Nezahualpilli, Colonia Ajusco. I happen to know quite well that precise area - I lived very close to that street for some months in 2008. I eat in a small restaurant (what we call either a cocina econ mica, comida corrida or fondita) on that street. One of my usual bycicle workshops is also on that street - In fact, I wanted to go today, as both of my bikes' rear tires are flat, but had no time to make it. Anyway... Colonia Ajusco and Colonia Santo Domingo ("colonia" is basically... a neighbourhood in es_MX) are two very popular, economically depressed areas, just North-East of the University. Probably hundreds or thousands of students live in rented rooms in the area, as UNAM with its 300,000 students does not have any dorms (due to political reasons leading all the way back to the 1960s). Santo Domingo and Ajusco are also the part where Mexico City's main valley finishes. The hills begin, not too abruptly (we have a ~150m difference in the ~2Km spanned by both colonias). And... When I lived there, I was amazed at the amount of people moving by bike. The streets are too slow for motorized transit to properly flow, and it's often annoying to have to cross the region. It is mostly safe for cyclists. Anyway, this kid was having a good time on the street, and was killed by a microbus driver fighting his fellow over more clients. The driver, yes, was caught (by his passengers and other bystanders, according to the note), and did not run away as they often do in cases such as this one. Still, the kid died almost instantly, so catching the driver serves very little consolation. This Friday we will have BiciUNAMonos second monthly meeting. It is too soon, and I don't think we will end up going there. But I do feel this accident falls squarely inside UNAM user's territory. We cannot ignore it just because it happened outside our University's gates.

24 May 2010

Axel Beckert: Perfect Team: autossh and GNU Screen

SSH is definitely one of my most often used tools, not only for system administration at work but also on the road with my netbook, an EeePC 701 running Debian Sid. On the road, it often happens that I have a flaky WLAN or UMTS connection, so I often have to kill (via <Enter>~.) and reconnect my SSH session due to a changed IP address or so. First step against problems arising from using SSH over unreliable network connections is of course GNU Screen. Second step is use SSH keys and ssh-agent to not needing to type the password on every reconnect. But it s still very annoying to kill the SSH connection and call ssh again manually. For luck there is autossh, a wrapper around SSH which regularily checks via two tunnels connect to each other on the remote side if the connection is still alive, and if not, it kills the ssh and starts a new one with the same parameters (i.e. tunnels, port forwardings, commands to call, etc.). It s quite obvious that this is perfect to be combined with screen s -R and -d options (Reattach if a detached screen is around, else start a new screen; detach a currently attached screen), so I found myself very often typing (or fetching it from the commandline history :-): 
autossh -t sym.noone.org 'screen -Rd'
-t is necessary to allocate a terminal device on the remote machine which is not done by default if you directly call a command via ssh. In comparision to OpenSSH, autossh needs the single quotes, because otherwise it would parse -Rd as options to parse to ssh and bail out. That s not a real problem, but when you re used to just type ssh -t sym.noone.org screen -Rd without any quotes, you ll run into this then and when. Update, 25-May-2010, 14:55: As Carsten Hey points out, autossh also supports the -- option to declare that all following options and parameters must be passed to ssh itself. (End of Update) Typing that often and mistyping it then and when cries for an shell alias or an shell function. So I came up with the following shell function: 
asc()  
    autossh -x -a -t "$@" 'screen -RdU'
I used a function instead of an alias in case of autossh will in future regard all parameters given after the command as part of the command as ssh does. The additional options -x and -a disable X and SSH Agent forwarding which both don t work if you reattach to an already running screen. And if you re using Zsh as I do, you can even add some more format string magic to set the window title more or less to the expanded alias, eh, function: 
function asc()  
    # Set the title to something more obvious, e.g. the expanded
    # alias, eh, function
    print -Pn "\e]0;%n@%m: autossh -t $* 'screen -RdU'\a";
    autossh -x -a -t "$@" 'screen -RdU'
 
compdef asc=ssh
Update, 25-May-2010, 14:59: As Hauke points out in a comment, Zsh users should also declare that asc should have the same tab completion as ssh itself. The example above has been updated accordingly. (End of Update) In the meanwhile on the EeePC I use asc on the commandline more often than ssh itself. And I nearly no more type autossh. (The most common exception here is autossh hostname tail -F /path/to/some/logfile.) Using that function you can also add common ssh options for tunneling, etc. I use it most often like this: 
asc -D 1080 sym.noone.org
This opens a SOCKS proxy on localhost, port 1080 and that way I can surf via the host I m connecting to by SSH. There s one small drawback though: You didn t expect that I can just invent some new three letter command without a namespace clash, did you? There is a free game called Advanced Strategic Command whose binary (and Debian package) is named asc, too. If you have that game installed, you can always call it using its full path, e.g. /usr/games/asc on Debian. P.S.: My whole grml based .zshrc is also available via git at git.noone.org as well as on github.

Christine Spang: Christine Spang: out with the old, in with the new(er)

I just replaced my aging 2004-era PC with wait for it a 2005-era PC. A friend is moving across the country so I'm taking it off his hands. Swapping hardware between Freyja and Earlgrey The differences between the two are more than just the year of time, though: one was hand-built from parts, while the other was a commodity off-the-shelf Compaq. So the new machine, while not strictly faster by the clock, is 64-bit and is much more amenable to upgrades. While the added bulk is a bit annoying, the case has a lot more space in it up to 8 or so drive slots (I can't imagine ever needing that many), and 4 RAM slots which is a sure step up from the limitation of two drive slots and two RAM slots in my old machine. The most visibly shiny parts in the new desktop experience are 4G RAM versus 1G, and a nice ATI GPU. While I'm glad my OS allowed me to squeeze six years out of my main machine, I'll be happy to stop shaking my fist at Chromium for eating all my memory! The new machine will keep its old name: earlgrey.

23 May 2010

Thorsten Glaser: Cancelling bash, retrieving a command, mksh rules :

In response to a planet.d.o series (mentioned in #grml on IRC) of postings: In a sensible shell, Esc+# not only pushes it back but also re-enables the command. Try it out: l s Esc # Cursor-Up Esc # 
tg@blau:~ $ #ls
tg@blau:~ $ ls
The command sticks in the history, and is not immediately shown in the next interactive input line, which I consider a plus in most use cases. Anyway, try mksh (just a-g i it), there are a lot of goodies. I found out about Ctrl-O only a year or so ago myself I wonder why schizo didn t write about how to do it in posh tho

22 May 2010

Wouter Verhelst: Help!

Yes, there is something like an 'RFH', or 'Request For Help', in the WNPP in Debian, but I thought I'd go through this blog, first, since I believe many more people who will feel inclined to help here will read this blog. I've been maintaining the beid packages in Debian since, eh, quite a while now; and while it's not always been the package that I have spent the most time on, it's not a package that I want to give up. However, in recent times, I've had issues with the code. I've not really been able to get the 3.5.2 release to compile properly as a package, which means that for the moment, squeeze is still stuck with a 2.x release. This is a problem, since that old release isn't supported anymore upstream, and what's worse, it does not support newer-issued eID cards. So if your card is less than about two or three years old, you can't even use it anymore. For this reason, the beid packages really, really should be updated before squeeze releases. I've been trying to spend some time doing so, but real life kept intervening. And I haven't even been able to start looking for the 3.5.3 code that I'd heard rumours would exist. So, this is a request for help. If you want a more recent beid package to appear in Debian (and, by extension, Ubuntu) any time soon, and you can spare some extra time on maintaining a somewhat convoluted package, you'd be an ideal candidate for comaintainer of this package. You don't need to have any experience working on Debian, but you do need experience with build systems and Makefiles. If you don't have any experience in working on Debian, but would like to learn, this might be an interesting opportunity. If you do have experience working on Debian and are as interested as me in getting this to be up-to-date in the next Debian release, your help would be very much appreciated. Even if you only have time for a little while and would like me to take over once everything is going fine again, that's helpful. At any rate, if you want to help, contact me at wouter@debian.org. We'll work out the specifics then. Thanks in advance,

20 May 2010

Joey Hess: Presenting Kaxxt (on Ice)

 Here we have a robot  
 with a very pointy face.  
 His name is Kaxxt,  
 he lives in outer space.  
            -- Why The Lucky Stiff

Kaxxt is _why's concept of a card game to subtly introduce kids to some basics of programming, including branching, recursion and stack overflows. He introduced the concept at the end of his talk at the ART && CODE Symposium. I've adapted Kaxxt so it can be played using the Icehouse game pieces. They're a good fit, since Kaxxt is about lasers, and involves manipulating tokens to direct the lasers. Kaxxt on Ice is now open for playtesting. More...

Next.

Previous.