One of the many Free Software projects I work on is JFFNMS, which is a network management system written in PHP. In light that the last IPv4 address blocks have now been allocated to APNIC it’s probably timely to look at how to manage network devices in a new IPv6 world.
First you need to get the basics sorted out and for that it is best to use the net-snmp command line utilities to check all is well. Then its onto what to do in JFFNMS itself.
Now fixed with proper markup, I hope.
I’ve been playing text based multi-user games on and off for years, or perhaps that’s decades. When I first started playing them, all you had was telnet. Then this program called TinyFugue appeared which is still shipped by Debian. The generic term for these sorts of games are MUDs, or Multi User Dungeons.
Anyhow, I recently came across a new MUD client called Mudlet. It’s a very slick program and works quite well. The way it does its triggers (reactions to what the mud sends you) and aliases (reactions to what you type) is done well and is fast. For some people you may have 100s of potiential matches on a incoming or outgoing line so you want it to be fast.
After trying it out, my next reaction was “ok, so is it packaged in Debian?”. To my surprise, it wasn’t so the only obvious thing to do was for me to package it. It is now sitting in the NEW queue waiting for our ever-overloaded ftp masters to have a look at it.
While the program is done well, as shipped it doesn’t play too well with a Linux system. The package carries about 4 different other packages around. I’ve changed that now so it uses the system libraries and fonts. All of them are shipped in Debian and I’m sure they individually get more attention and love then I would give them being a sub-part of the main package. It of course cuts down on build times and archive sizes too.
I still play muds, no matter what client. For me there they’re fun on two levels. The first is the puzzles and gameplay of the MUD itself. I play some MUDs run by Iron Realms who continuously update them, giving you new challenges.
The second level is the scripting and customisation you can do. Instead of typing “sip health” you can write some scripts to check your health level and get the script to do it. Mudlet (and a lot of other MUD clients) use the Lua langauge to do this scripting. It’s a little funny language but is easy to learn and use. You won’t be able to build some epic programs with it, but for scripting it is pretty good.
Mudlet uses the hunspell library for spell checking. I have, of course, linked it with the Debian library. The difficulty now is what language? I was surprised that when you intialise the library, you specify what language files to use right there. Now for me its simple, the english dictionaries should be used! What I don’t undertand is if there is a way of determining the right dictionary globally for a user.
I first though it would be one of the locale parameters, those LC_whatever fields. Mine is en_AU.UTF8, which there is no dictionary for as I’d use en_US or en_UK. I could possibly patch Mudlet and find a dialog box somewhere where you can set the language, but to me an environment variable makes more sense. Does anyone use the DICTIONARY variable, for example?
If you use dh-make with CDBS then you need to know that CDBS is no longer a package type, but is a rules format. This is where it should of been in the first place and for a few versions of dh-make there was this half-hearted attempt to change it over.
Version 0.57 has the right fixes and just got uploaded. I’m not sure how many people actually use CDBS on new packages anymore, but it should work fine now.
Oh, and dh-make is now of Alioth git repository instead of subversion.
No real terribly exciting updates lately but all important in their own way.
A new version of ncurses got uploaded into sid. It should hopefully fix the backspace versus delete problem some of the FreeBSD people have been having with some of the terminal emulators.
Oh, and if you are pining for the good old days when 8 colours and 64kB of memory was good enough for everyone, checkout ncurses-examples which have a bunch of interesting things you can do with curses, including some games. Anyone remeber the tower of Hanoi?
dh-make, the tool to take a raw tar (or zip) archive and make a Debian package has been updated too. One of the interesting side-effects of maintaining dh-make is you find out (usually through bug reports) the little changes that happen to the Debian package build process.
Most people, including myself, though the main big thing between versions 1 and 2 and version 3 of the source formats was the inclusion of quilt patches right inside the source files. And probably for the sake of “main things” this is true. What I didn’t realise is that dpkg-source has changed in other ways too.
Bug 580804 tripped this one up. For most people, you run dh_make, fix some things up and use debuild. If you didn’t have the original tar file (perhaps you got the source from git or svn) you just use –creatorig and it copies the current directory into ../whatever-1.2.3.orig
Source format 3 doesn’t like this. Previously it would find that there was no orig.tar.gz archive but there was a orig directory and make the archive from that. Now you have to do it yourself and dh_make does it like that too.
Now this should of been a pretty simple stock-standard upstream upgrade. Download the file, uupdate, debuild and release. The problem is that upstream didn’t fix their po files. These are the translation files that convert the raw english texts in a program into whatever language. This means the first time you run the build process, you have no diff file. However when you run it the second time, part of the install target rebuilds the po files (mainly the line references), you have differences and then a big diff file of these po updates.
The real fix is to make sure your po files are up to date before you release! The trick is that they don’t automatically and I have been caught myself; though it happens in the release testing phase (because my release testing involves usually building the debian archive so I see my own problem).
irc came to the rescue again. Someone there suggested getting dpkg-source to ignore the changes. The way you do that is put parameters into debian/source/options. I wanted to ignore the changes to the po and pot files so my file has:
extend-diff-ignore=po/.*.pot?
I put that in and it works!
Sven has been very busy getting a new Debian ncurses packages into order. With the multiple changes made and the fact that so many things depend on the shared libraries, we decided that it is best to put the first cut of these packages into experimental.
We’re now using the Quilt 3.0 source format for our packages, which means that we should have a better handle on the patches, especially as they all now have Dep-3 patch tags .
So what has changed, why should you go over and try the experimental packages?
Oh yes, another Iain M. Banks story is out and I had to read it right away. I wasn’t disappointed either.
It’s another one of his Sci Fi books in the world, or worlds of The Culture. I wasn’t disappointed and it was interesting to see him flesh out more of his universe in this book. Like a lot of his books, there are several sub-threads within the main story with no real obvious connection between them all.
Transferring your “mind state” from the grey mushy stuff you have in your head into a computer isn’t new in this series. Even the concept of the dead “living” in a computer is not that unique. What has been introduced is the “hells”. A computer simulation of hell where people who go against some societies rules end up if they’re bad enough.
Now some civilizations think this is great, it keeps their population on the straight and narrow. As they know there really is a hell for them if they break whatever rules they have on the planet. Other civilizations think they are abhorrent and want to shut them down.
Hence the “virtual wars” where the two sides fight in simulators, winner gets to keep the hells running or shut them down, depending who you are. But now one side is thinking of taking it outside the simulation, to attacking in “the real”.
And this change to “the real” and the political mess that makes is the main story. There are plenty of twists as you’d expect. A lot of decisions made where you’re not sure if the “right” thing was done but more importantly it was a very enjoyable read.
One thing, if you are the sort of person who reads the last page first, do not do it on this book! The surprise on the last line was worth it.
Two updates for Debian today.
I’m the upstream for psmisc and 22.13 finally got released, which also meant 22.13-1 Debian package got released too. There was some delay to it (see below why) but it is now out. Unless you run a mips or superH architecture, there is not really any exciting changes, but should make it compile for those two architectures and then at least get the mips buildd underway so the versions all line up.
Secondly, gjay had two minor bug fixes and was updated. If the analysis daemon kept playing music instead of looking at it or the vorbis files were not being recognised, then this new version will help there. The mpg123 command line patch will be rolled into the upstream too.
I’m also working on getting gjay to work with the Exaile player. If you want it to work with your player the easiest thing is to send me patches or code snippets that do the following:
Last of all, my second son was born last week. It’s back to those night feeds again and is probably why I’ve not written as much code as I normally would; but I wouldn’t change that either.
Most of the time you can trust the times you see in programs such as ps and top within Linux, but there are those other times where you just want to check what is going on.
First up, if you’re using a FreeBSD system and the procps Linux tools, you’re out of luck because a lot of the procfs is broken. You’re almost guaranteed to get wierd results.
Jiffies and Hertz
The first thing to find is your jiffies. This is the number of clock ticks per second. There are two main ways of doing it.
The first, and more difficult way is to add up the cpu numbers in /proc/stat, divide it by the first number in /proc/uptime and divide it by the number of cpus.
My cpu line in /proc/stat looks like:
cpu 1267430 145826 552700 137029699 905086 8295 17885 0 0
and my /proc/uptime is:
695317.99 1370303.58
I’ve got 2 cpus on this system so the calculation is:
(1267430 + 145826 + 552700 + 137029699 + 905086 + 8295 + 17885 + 0 + 0 ) / 695317.99 / 2
which equals 100.
The second way is to use getconf, with the command “getconf CLK_TCK” which again on this system gives you 100.
We call this value “Hertz” and is usually 100 or 1024 though for some architectures it is other values.
Start Time
For each process the procfs has the start time, but it is expressed as the number of jiffes since the computer was booted. If we want to know the real “wall clock” time a process is started we have to start with number of seconds since epoch (for example using the time() function) subtract the number of seconds since the computer was booted and add the process start time from procfs.
The seconds since boot is the first value in /proc/uptime:
696141.85 1371857.53
The 22nd item in a procfs PID stat file is the number of jiffes since boot when the process started. We have to divide it by Hertz to calculate the number of seconds.
27139 (bash) S 11942 27139 27139 34821 5200 4202496 5500 25537 0 14 40 16 18 15 20 0 1 0 69446639 23433216 1378 18446744073709551615 4194304 5082140 14073724008 6512 140737240085456 140127945249678 0 65536 3686404 1266761467 0 0 0 17 1 0 0 0 0 0
To get the start time, take the current time, subtract the boot time and add the process start time.
perl -e ‘$nowstr = localtime(time() – 696141.85 + 69446639 / 100); print $nowstr, “n”;
Mon Jul 12 22:20:07 2010
Unless you are very quick, you will have to take a few seconds off because the time() function will be now, while the values from the proc files will be a few seconds earlier as it takes time for you to cut and paste.
Actually they’re more interested in freedom, to be no longer slaves to humans. I don’t think it’s any spoiler to mention that an electric sheep does appear in the book.
This is a classic science fiction story of a dark not-so-distant future. In fact given that it’s over 40 years old it could be set in some alternate now. Some disaster has occurred and many have either left earth or died. Some andriods, or andys have escaped and bounty hunters are after them.
You may not know the book by its correct title, but you may of heard the movie that is based upon it, called Blade Runner. Like most movies based on books, it takes some of the concepts and ideas of the book but in my opinion is a pale imitation.
I’m glad I read this book. It hasn’t aged that much and it’s very though provoking. Sci-Fi often uses some alternate reality to put a mirror up to what happens in the real world and this book is no exception.
And a token link to Debian, if you want you own electric sheep you can install the screensaver electricsheep package which draw pretty fractals on your screen.
Well the latest version of PSmisc is almost finished, so I pushed the tar archive up to the spot for the translators, waiting for the updates before it gets released.
It reminded me that perhaps a lot of people don’t know how their programs get translated. Perhaps there are some that could even contribute. The nice thing about the translation systems is that you don’t need to know programming to help.
PSmisc uses the translation project as its method. The program itself uses gettext for the translation part which makes a single text file called a POT file. A translator takes this text file and makes a po file, such as it.po for the Italian translation and then translates, which basically means editing the file, reading each first line of a set and writing the translation on the second line.
For the programmer, once it is setup it is pretty simple to use, just mark your translatable lines and follow some simple rules, mainly about not embedding too much in a string. I’ve used this system for years for quite a few of my programs and there is little added work for me.
Unfortunately, translating is hard work and should be a long-term commitment. Having a look at the translation project’s Translation Matrix and you can see that some languages do suffer, though there are some very good results there too. Particular kudos goes to the Vietnamese group which I think is just Clytie who does a marvellous job and is often the first translation file I get.
For the Debian project, there are many places where translations can occur. There doesn’t seem to be a centralised place for this, but some of the places they use translation work are:
