Recent blog entries for pabs3

Join the Process Identifier Preservation Society today!

Process Identifiers (PIDs) are a scarce resource. On Linux they are only 15 bits by default. The Process Identifier Preservation Society (PIPS) aims to reduce abuse and wastage of the PID space. To join the society please read the following advice.

Common issues

Several languages generally allow you to run all your code in one process. Some of the code that you might want to incorporate or use is not available in the form of ELF libraries or language specific libraries but only in the form of ELF binaries or interpreted scripts. As a result using additional PID space is sometimes unavoidable. Many languages have multiple methods of starting external processes and usually some of them waste PID space by running commands in a shell. You can avoid those methods or use the exec builtin to preserve the shell PID. It might be tempting to explicitly use shell in languages that don't allow implicit shell use but that just wastes extra PIDs.

Several languages allow you to fork one process into two, this uses an extra PID and is to be avoided unless nessecary.

Shell

Programs written in the shell languages use a lot of PIDs. Even shells that have a lot of shell builtins (like busybox sh) appear to use the PID space by forking a child process. To join PIPS you should just stop writing programs in shell or use as many builtins as possible and use exec to preserve PIDs.

Init

Several init systems are written in or use shell extensively and thus eat huge bowls of PIDs for breakfast. To join the PIPS you should switch away from sysvinit, openrc, init=/bin/sh etc.

C/C++

The common issues section applies to the C/C++ language. To join PIPS you should rewrite your code to use fork()+exec() or libpipeline instead of the system() and popen() functions.

Perl

The common issues section applies to the Perl language. To join PIPS you should rewrite your code to avoid backticks and only pass arrays to the system(), open(), open2(), open3() functions.

PHP

The common issues section applies to the PHP language. To join PIPS you should rewrite your code to use pcntl_exec() instead of backticks, exec(), system(), passthru(), shell_exec(), popen() and proc_open(). Apparently pcntl_exec() is disabled by default on Debian and pcntl_* are often unavailable so you should just not spawn processes. You could also just drop PHP already.

Python

The common issues section applies to the Python language. To join PIPS you should rewrite your code to use the subprocess module and avoid passing shell=True to the subprocess.Popen() function. The os.system(), os.popen() functions and the commands module all run their commands in a shell, wasting PID space. The popen2 module requires passing arrays instead of strings in order to avoid the command being run in a shell.

Haskell

The common issues section applies to the Haskell language. To join PIPS you should only ever pass a RawCommand to createProcess and never use the shell, system, runCommand or runInteractiveCommand functions from the System.Process and System.Cmd libraries.

OCaml

The common issues section applies to the OCaml language. To join PIPS you should rewrite your code to use fork+exec or the create_process* wrappers instead of system, open_process, open_process_in, open_process_out and open_process_full.

Go

Go allows running external processes but doesn't allow you to waste PID space by running commands in shell. Avoid explicitly running the shell though.

Rust

Rust allows running external processes but doesn't allow you to waste PID space by running commands in shell. Avoid explicitly running the shell though.

Erlang

The common issues section applies to the Erlang language. To join PIPS you should rewrite your code to use erlang:open_port({spawn_executable, ...}, ...) instead of os:cmd or the other options to erlang:open_port.

Node.js

The common issues section applies to the Node.js language. To join PIPS you should rewrite your code to use the child_process.execFile() function (or other child_process functions) instead of child_process.exec().

Julia

Julia allows running external processes but doesn't allow you to waste PID space by running commands in shell. It emulates a lot of shell features instead. Avoid explicitly running the shell though.

Dart

The common issues section applies to the Dart language. To join PIPS simply do not enable the runInShell parameter of the Process object.

PS

Let me know if I missed something in one of these languages. You should also do most of the above to avoid shell metacharacter injection attacks that usually allow arbitrary code execution. Dear language authors, don't allow running external processes in shell, kthxbye!

Syndicated 2014-02-17 03:38:47 from Advogato

OpenPGP keysigning: alternate encodings for fingerprint exchange

I think that hexadecimal is a fairly poor pre-encoding for information exchange via data to speech and speech to data engines (aka voice boxes, brains and fingers). Reading out and typing long strings of hexadecimal digits at OpenPGP keysignings is tedious and annoying.

There have been some experiments using photography and QR codes for this, which I think is pretty cool but not always practical since not everyone has a camera and QR code software installed.

An alternative to this might be to pre-encode using a different scheme that encodes to less words in English speech. Diceware is one possibility that I recently experimented with. Diceware is a password generation scheme that encodes data from a random number generator (aka some dice) using a list of 7776 words. Each word thus represents a 5 digit number in base 6. Diceware is mainly used for generating strong and easier to remember passwords. So Diceware is the coupling between a non-digital random number generator and an interesting encoding scheme.

Below are my fingerprints in Diceware and Hexadecimal form. The Diceware form is longer to type at 69 characters, 40 for hex. The Diceware form has the advantage that it is only 16 words to say while the hexadecimal form is 40. I don't know if this will be more practical than hex but I can almost remember my entire fingerprint after reading it a few times so hopefully that will translate to practical use. A rough script for encoding your fingerprint in the Diceware encoding is available but I haven't implemented the reverse yet. I would be glad if someone could check it for correctness.

  Diceware:    frame maze bear usgs deter wag prissy bush hoyt mayo upton child indy
Hexadecimal: 610B 28B5 5CFC FE45 EA1B  563B 3116 BA5E 9FFA 69A3

If you want to discuss this topic and try it out in person and attempt to understand my accent, I'll be at DebConf13 and OHM2013. Some downsides that I can think of are accents, multiple spellings and the inclusion of non-words and special characters in the wordlist. These can be solved by using a different wordlist created specifically for OpenPGP fingerprint exchange that only includes suitable words.

This post was inspired by the screenshots for RedPhone. You can comment on this post on debian-project.

Syndicated 2013-06-28 05:42:59 from Advogato

23 Feb 2013 (updated 10 Apr 2013 at 09:09 UTC) »

Inadequate software

Just 168 of the 4961 packages (3%) I have installed are inadequate. Unfortunately those packages collectively have 3440 inadequacies. How much of the software on your system has these inadequacies?

  • broken symlinks
  • missing copyright files
  • obsolete conffiles
  • Python modules not byte-compiled
  • /bin and /sbin binaries requiring /usr/lib libraries
  • undefined symbols.

You can find out today by installing Jakub Wilk's software, which is appropriately named adequate. It is now available in Debian experimental. I recommend enabling the apt hook which notifies you when software you are installing is inadequate. Other ways of being notified when you are installing inadequate software include apt-listbugs and debsecan.

If you are interested in software quality, Debian's QA activities wiki page provides a good overview of the quality assurance activities that are being worked on within the context of Debian. If you want to provide better quality software for Debian, please keep an eye on the PTS pages for software you maintain. You can also run various automated checks on your software before you make new releases or upload them to the Debian archive.

More people are needed to improve and expand upon Debian's existing quality assurance activities and infrastructure. Come join us today!

Syndicated 2013-02-23 07:07:17 (Updated 2013-04-10 09:09:33) from Advogato

Debian on mobile devices

Debian on Samsung Galaxy S

It is possible to put Debian on smartphones like the Samsung Galaxy S:

  • Find a friendly Android distro that supports your device, install it with fastboot or heimdall and play around.
  • Be sad that the proprietary bootloader doesn't support dual boot.
  • Reformat the "sdcard" as ext3 and install Debian in a chroot on it.
  • "Tether" your device via USB using the Android settings menu & add a default route with adb: adb shell ip add route default via 192.168.XXX.XXX. Then use one or other USB network script on your PC.
  • Install OpenSSH, copy some commands from the usb.rc to /etc/rc.local so that you will have a way to access your Debian system over USB.
  • Hack up the initramfs to mount the sdcard partition and then run the Debian init in the chroot instead of the Replicant init.
  • Install some sort of graphical environment such as Enlightenment and nodm.
  • Realise that the touchscreen driver is buggy, which means that udev and thus Xorg do not recognise it as an input device. Find out that the same device seems to also be supported by a different driver that is in Linux mainline. Boggle.
  • Work around the buggy touchscreen driver by using x2x (orphaned) to send your laptop input devices over SSH to Xorg running on the phone.
  • Click through the Enlightenment startup wizard, work around desktop-base not supporting E17 and install a touchscreen-friendly app like intone.
  • Marvel at the speed and flashyness of Enlightenment even though it does not use OpenGL because there are no open drivers for PowerVR devices.
  • Take a photo and blog about it to create some bzzt.
  • Get depressed about the rediculousness of all that and proceed to drinking over 9000 litres of beer.
  • Think about just using Replicant plus f-droid.

Linux mainline doesn't run on any of the mobile devices I have. It probably doesn't run on any of the mobile devices you have either. There has been some effort by the OpenMoko community to merge the gta02 kernel patches but it is not yet complete. I doubt Samsung will spend money on merging support for old devices obsoleted by more recent devices. There is Linaro but they are focused on things the hardware vendors pay them for and probably would not have the resources anyway. Therefore I would guess the timeframe for supporting the OpenMoko FreeRunner and the Samsung Galaxy S in Linux mainline is between many years and never. For better or worse, the Debian Linux kernel maintainers prefer not to include non-mainline stuff and Debian as a whole generally prefers to include one copy of each package instead of 9. The procedures I documented above are not a great way to support mobile devices at all and could break at any moment anyway. So everyone, please become a kernel developer and help merge all of the many many versions of Android Linux into Linux mainline so that you can have your favourite distribution on your devices.

Syndicated 2012-12-03 03:39:07 from Advogato

Some thoughts on using Debian

I'm currently running Debian's rolling release (aka "testing") on my main machine and have added some stuff to make that nicer.

First thing I have is configuration and package management. Since I have relatively few machines, I am using a metapackage per machine that installs some configuration files with changes that I want. The metapackages depend on packages that I need installed so that I can mark all other packages as being automatically installed. The metapackages are also useful for documenting why I have things installed. It depends on things like task-laptop from tasksel, hardware support packages, the GUI I use, games I play often and so on. My laptop does not have a CD/DVD drive so I have some metapackages to fool apt into ignoring dependencies on CD/DVD related packages I don't need. I'm building the metapackages using equivs-build and a small Makefile. I use the File: header supported by equivs-build for installing config files. I have popcon installed and enabled but I don't want it to leak the names of the metapackages so I have added a prefix to my metapackages and modified the popcon cron job to remove anything containing that prefix. I also don't want apt to ever remove the metapackages so I mark them as Important: yes and configure apt to never autoremove them.

  --- /etc/cron.daily/popularity-contest~
+++ /etc/cron.daily/popularity-contest
@@ -71,8 +71,8 @@
 # try to post the report through http POST
 if [ "$SUBMITURLS" ] && [ "yes" = "$USEHTTP" ]; then
     for URL in $SUBMITURLS ; do
-   if grep -v myprefix- $POPCON | setsid /usr/share/popularity-contest/popcon-upload \
-       -u $URL 2>/dev/null ; then
+   if setsid /usr/share/popularity-contest/popcon-upload \
+       -u $URL -f $POPCON 2>/dev/null ; then
        SUBMITTED=yes
    else
        logger -t popularity-contest "unable to submit report to $URL."
@@ -94,7 +94,7 @@
        echo "MIME-Version: 1.0"
        echo "Content-Type: text/plain"
        echo
-       grep -v myprefix- $POPCON
+       cat $POPCON
    ) | do_sendmail
    SUBMITTED=yes
     else

/etc/apt/apt.conf.d/99metapackages:

  APT::NeverAutoRemove { "^myprefix-.*";} ;

I am using Raphael Geissert's mirror redirector in order to automatically use up-to-date and hopefully non-broken mirrors. Unfortunately this often causes apt to complain about hash sum mismatches and then proceed to forget about all packages. I work around this by always running apt-get update in a loop until it succeeds.

  while ! apt-get update ; do sleep 1m; done

A lot of the time I need to install packages from outside of testing. So my sources.list contains lines for testing, unstable and experimental. I have some apt pinning so that by default I only have packages from testing but if I manually upgrade some packages to unstable or experimental, then I will get upgrades within that suite until those packages migrate down to unstable or testing. The apt pinning needs priorities between 1000 and 500 for this to work nicely. I also pin some things like lintian, debian-policy and devref to unstable/experimental since having old versions of those is not useful.

/etc/apt/sources.list:

  # testing
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free
deb http://http.debian.net/debian/ testing main contrib non-free
deb-src http://http.debian.net/debian/ testing main contrib non-free
# unstable
deb http://http.debian.net/debian/ unstable main contrib non-free
deb-src http://http.debian.net/debian/ unstable main contrib non-free
# experimental
deb http://http.debian.net/debian/ experimental main contrib non-free
deb-src http://http.debian.net/debian/ experimental main contrib non-free

/etc/apt/preferences.d/system:

  Package: *
Pin: release a=testing
Pin-Priority: 800

Package: *
Pin: release a=unstable
Pin-Priority: 700

Package: *
Pin: release a=experimental
Pin-Priority: 600

/etc/apt/preferences.d/packages:

  Package: lintian
Pin: release a=unstable
Pin-Priority: 900

Package: lintian
Pin: release a=experimental
Pin-Priority: 910

Package: debian-policy
Pin: release a=unstable
Pin-Priority: 999

Package: developers-reference
Pin: release a=unstable
Pin-Priority: 999

I have a few configuration files and a cron job to make all programs dump core files when they crash so that I can file bugs, even for random crashes that are not easy to reproduce. I enabled some kernel settings with sysctl, lifted some security limits to enable core dumps, and added a cron job to delete old core dumps and notify me of new core dumps. In my shell configuration I also turn on two glibc options to cause programs to crash when they have improper memory management. I also have a second machine I use for bug discovery where I have lots of stuff installed and everything apt pinned in the opposite way; experimental > unstable > testing. When I have time I use this machine to do testing of packages I use, classes of packages that I care about (such as games) and sometimes packages I do not use.

/etc/sysctl.d/corefiles.conf:

  fs.suid_dumpable = 1
kernel.core_uses_pid = 1
kernel.core_pattern = /var/cache/corefiles/core-%p-%u-%g-%s-%t-%h-%e

/etc/security/limits.d/corefiles.conf:

  *              soft    core            unlimited
*              hard    core            unlimited

/etc/cron.daily/corefiles:

  #!/bin/sh
mkdir -p /var/cache/corefiles
chmod 2777 /var/cache/corefiles
if [ $(find /var/cache/corefiles -mtime +100 -a ! -type d | wc -l) -gt 0 ]; then
    echo deleting:
    find /var/cache/corefiles -mtime +100 -a ! -type d
    find /var/cache/corefiles -mtime +100 -a ! -type d -print0 | xargs -0 rm -f
fi
if [ $(find /var/cache/corefiles ! -type d | wc -l) -gt 0 ] ; then
    echo still present:
    find /var/cache/corefiles ! -type d
fi

~/.bash.d/malloc:

  export MALLOC_CHECK_=2
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))

I unfortunately need some packages from contrib/non-free, so I have a cron job to let me know when I accidentally install new packages from contrib/non-free.

  @daily diffcmdoutput ~/.cache/non-free-contrib aptitude search ~i~snon-free\|~i~scontrib

I backup my dpkg package selections and debconf databases.

  @daily diffcmdoutput ~/backup/packages dpkg --get-selections
@daily diffcmdoutput ~/backup/config debconf-get-selections 2> /dev/null

I notify myself of changes to the list of new packages so that I can review them, install any useful/interesting ones and tell aptitude to forget them all.

  @daily diffcmdoutput ~/.cache/new aptitude search ~N

I notify myself of changes to the list of packages I have installed that are not up-to-date packages from testing. This helps me catch packages removed from testing/unstable/etc that I use.

  @daily diffcmdoutput ~/.cache/apt-show-versions sh -c "apt-show-versions | grep -v '/testing uptodate'"

I notify myself of packages that I maintain that are having issues migrating to testing. I considered doing the same for teams I am involved in but they aren't particularly functional teams so there would be a lot of noise.

  @daily grep-excuses 'Paul Wise'

I notify myself of RC bugs that apply to testing and are installed. The list is so long that it just makes me depressed instead of motivated to help fix RC bugs so I only notify myself of changes. Even then I rarely do anything other than delete the notifications. If you are looking for ways to help Debian, fixing RC bugs is a great choice.

  @daily diffcmdoutput ~/.cache/rcbugs rc-alert -d T --exclude-tags IP+MR

I notify myself of packages that are orphaned or need a new maintainer. There are usually so many packages in this list that it is not useful, so I only notify myself of changes to the list. I rarely adopt packages because I feel overloaded already. If you are looking for ways to help Debian, adopting packages is a good choice.

  @daily wnpp-alert --diff

One of my packages is for interacting with servers on the Internet, so I need to run tests periodically to ensure the package works. I do that with a simple Makefile but maybe I need to move to autopkgtest, need to find out if it saves data between runs first.

  @monthly cd ~/devel/debian/tests ; make

I install debsecan so that I get notified of security updates in unstable and new security issues that are not fixed yet. The way debsecan works is that it notifies about changes in security issues and updates and also includes a full list of all known unfixed issues. I generally install security updates from unstable when I see them. The list of unchanged issues is so long that it makes me wonder how many times I've been cracked already. The oldest issue goes back to 2002 but most of them are 2010 or later. The various parts of WebKit are by far the worst security offenders. I don't bother with the white-listing functionality due to the quantity of security issues and because it isn't possible to add a comment about each white-list item. If you want to get involved with the security team, reporting issues with the data in the security tracker is a good idea.

I subscribe to the ftpmaster RSS feeds for new and removed packages to keep up to date with changes in the archive.

A lot of the above applies to running systems based on Debian stable too. If you have any other thoughts about running Debian systems, please blog about them. The diffcmdoutput command used above is a simple shell script:

  #!/bin/sh
cache="$1"
shift
temp="$(mktemp "$cache"XXXXXXXXXXXXXX)"
"$@" > "$temp"
diff --unified "$cache" "$temp"
mv --force "$temp" "$cache"

Syndicated 2012-10-29 04:56:35 from Advogato

Ponds as time travel devices

I firmly believe that this pond is a time travel device:

Space invader pond

The proof is in this recording I made1. At minimum, clearly there is some sort of quantum entanglement with computer games from the 70s going on.

1. Folks may want to use this recording in free software. To the extent possible under law, I have waived all copyright and related or neighboring rights to this work. The frogs have too. An email or a link to this page would be appreciated though.

Syndicated 2012-08-30 05:37:32 from Advogato

What happens when a Debian derivative shuts down?

Over the past months we have seen the end of two Debian derivatives. In January the news came that Junta de Extremadura (Spain) were abandoning the development of LinEx and switching to Debian itself. Early in March the Debian derivatives census scripts noted that the Vanillux apt repository was down. Fabrice Quenneville then confirmed that he had to put a hold on the Vanillux project due to the cost of bandwidth and servers. In addition the future of StormOS is in doubt after Illumian was created. StormOS is a port of Debian to the OpenSolaris kernel and Illumian is similar but uses only apt/dpkg and repackages everything else.

The LinEx page in the Debian derivatives census did not reveal much information about the project that would have been useful to Debian, in particular it does not list any apt repositories. As a result it is quite hard to say what has potentially been lost. Two mails from people close to or involved in the project indicate that much of the LinEx distribution was already merged into Debian. It is probably safe to say that everything of value has been merged into Debian, including at least one of the developers involved in LinEx.

Vanillux was a small distribution with few developers according to the Google caches of their website. If we look at the patches created by the derivatives census scripts, we can see that the 5 source packages that were possibly derived from Debian source packages were simply imported from Christian Marillat's repository of non-free, patented, legally restricted and multimedia-related packages. The patches indicate that 3 source packages were forked from Debian and that 2 source packages were done from scratch. The forked packages seem to be mainly about enabling support for proprietary and patented codecs in several programs. This is a surprisingly small number of altered/differing packages, so what else could Vanillux folks have been working on? It appears that there were 12 new source packages that were not derived from Debian source packages. These appear to be mainly multimedia-related packages, one font imported from an Ubuntu PPA, some syslinux themes and a metapackage. The multimedia packages are all from Christian Marillat's repository. The Debian multimedia team is working hard on bringing multimedia related software to Debian and welcomes help with that. The font (Cantarell) is now in Debian under a different source package name. The metapackage appears to be very similar to from the ubuntu-meta source package from Ubuntu that uses germinate. So at first glance, the contribution of Vanillux to the world of Linux distributions appears to be in the area of artwork and package selection. The artwork produced is basically Vanillux branding and is thus not usable by Debian, although we would like more artists involved in Debian. The meta-package is not easily useful to Debian since we use a different mechanism for our task packages and our task packages have already been updated for the GNOME 3 transition. Still, the amount of difference between to source packages is relatively small. So, what else? Perusing the diff between the list of source packages exposed by the Packages and Sources files, I noted that a number of binary packages in the Packages files reference source packages not listed in the Sources files. When I saw picasa in that list, it occurred to me that Vanillux might have directly imported some binary packages without their corresponding source packages. Perusing their apt metadata confirms that they have imported some binary packages of non-free software directly from vendors. These include Google Desktop, Opera, Picasa and VirtualBox 3.2. The rest of the packages in the diff appear to be caused by some sort of issue with the import process from Debian and other apt repos. Most of the above could be achieved by adding some external commerical repositories to a normal Debian system or by merging some of those repositories (such as the Opera one) into Debian.

The interesting thing about the Debian derivatives census is that it allows us to perform analyses like these and figure out what patches and packages we might like to integrate into Debian. In this way we can salvage some of the value of our derivatives if they abandon ship.

If you have any ideas or code for improving the census or are running a Debian derivative, please join us at the Debian derivatives frontdesk.

Syndicated 2012-04-26 04:29:48 from Advogato

Report from the recent Debian bug squashing party in Perth

We recently held a Debian bug squashing party (BSP) in Perth, Western Australia. Over the weekend we had about 10 or so people show up to participate, learn about fixing bugs in Debian and try to fix some. The BSP co-incided with a weekend heat wave with temperatures reaching 38°C and the venue lacked air conditioning. Most of the attendees were new to Debian development but were Debian users. Our focus was on release critical bugs highlighted by rc-alert and the UDD bugs list, but we also discussed IPv6 bugs in CUPS and some bugs that were affecting UCC infrastructure. The UCC president also worked on fixing their door-locking system, replacing the broken system based on an ancient modem with an Arduino board. We managed to fix, work on or investigate 12 or more bugs. I was hoping we would get through more, but the weather and the average experience level conspired against us. After we were done on Sunday a few of us went down to the local pub to have a meal, a beer and some geeky conversation. All in all we had a good time and got some bugs fixed.

The UCC president seemed to be keen on doing another BSP, hopefully we can do another one before the freeze happens. There were a few people who missed the BSP so it would be good to give them a chance to work on some bugs.

Thanks go to the UCC folks for the venue and to PLUG folks for helping with organisation and promotion of the event.

Syndicated 2012-03-16 05:20:14 from Advogato

Debian/Ubuntu games screenshot party results

The Debian/Ubuntu games team recently organised a half-day screenshots party for creating screenshots for all the games that are available in Debian/Ubuntu.

Unfortunately, only 5 people participated in the screenshots party, I had hoped that we would get more folks turn up. Only one of those was not already involved in the games team and that one person found out via our spam on the #debian-mentors IRC channel. This means that most of our promotion of the event was ineffective. Hopefully for future games parties we can improve this, please let us know if you have any ideas about that.

We also had 7 other people on the channel during the party lurking, discussing and or working on other things, in particular Ben Armstrong was working on a games live CD.

Over the 7 hours of the party, we uploaded 100 screenshots for 40 different packages. Of the packages, 2 are available only in Debian (auralquiz, cutechess), one is available only in Ubuntu (plasma-widget-tictactoe) and the rest are available in both. I think we got quite a bit done for such a small group.

Some of us could not resist filing some bugs on packages that had issues preventing or delaying us from taking screenshots. I also suggested to one maintainer that his package (acm4) be removed from Debian, since it is obsoleted by acm and unusable.

If you want to play some games, check out goplay, which is a tool for browsing available games using debtags that displays screenshots from the games-thumbnails package, which has just been updated with the screenshots created during the party. goplay needs some more development, if you would like to help out with that, you would be most welcome.

If you are interested to see our screenshots, they are all on the screenshots.debian.net website and the packages are auralquiz, cardstories, londonlaw, cube2font, ardentryst, cutechess, pianobooster, emacs-chess, xye, flare, tmw, garden-of-coloured-lights, flight-of-the-amazon-queen, geekcode, glpeces, fofix, unknown-horizons, klickety, polygen, tictactoe, xscreensaver-screensaver-dizzy, goban-original-games, xjokes, mudlet, xabacus, xtux-client, connectagram, crystalspace, pescetti, purity-ng, qstat, slashem, sudoku, minetest, xscavenger, plasma-widget-tictactoe, xbomb, xfrisk, xpilot-ng and xsok.

Syndicated 2012-02-28 02:54:26 from Advogato

57 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!