under a Creative Commons License.
[link] 2005-09-12T22:50:31 replacing slackware with debian on a laptop: I wanted dial-up networking with Treo 650 to work in a hurry on a laptop. This laptop, like all my other (5?) boxes, runs slackware. The bluetooth instructions involved several files that I didn't want to chase down. I had achieved a BT connection, but I didn't want to spend the evening messing around with the rest of the ppp setup, so I got debian and installed that for the first time. apt-get made it a lot faster to fuss around with several combinations of kernels and drivers, but ultimately I couldn't get the wifi to work with ndiswrapper because I was missing p80211.o, which I could not build myself due to a compilation error in some unseen macro in a kernel header file. While I could start ppp connecting to the Treo, and the Treo said "Connecting...", there was never any response. So in the end, under the time constraints given (a few hours on each of 3 days) the laptop ended up less networked than it started. Kelsi is still happy that most things we installed used apt-get, which she can operate as well as I can. And, the debian 'desktop environment' set of packages gave her a bunch of gui toys that we didn't have installed on any slack boxes. So this box will probably stay debian, and I'll probably spend more time on the hardware setups. After trying "debian unstable", whatever that gives me, I'll probably put a clean kernel on, get the drivers I want, and build exactly what I built when it was slack. That should work in a predictable amount of time.
[link] 2005-09-13T00:03:57 Redfoot first impressions: eikeon, the author of Redfoot, got me started with RF in a long IRC session last night. He mentioned turning that transcript into a getting-started for RF, which could be nice. It'll be useless to me, of course, since the guide will contain answers to all my questions which have been answered. :) I've used apache and perl/cgi; then zope for a long time; and I've recently tried nevow for some tiny projects. Nevow comes with an interesting credential: the author Donovan Preston has written enough web frameworks before that, presumably, he knows all sides of the main decisions and he can focus on making a good, compact design instead of getting bogged down with making it all work (since that's second nature to him now). The zope team did other web work before, but IMO they built so much other machinery that they did need to worry about making it all work, and that any good design was going to be discovered in the good choices about what new machinery to build. As we've seen, zope's design (I only know version 2) is not known for being especially nice. The other, non-web-framework aspects to zope are pretty nice, though, which is why I continue to use it for so many years. Back to Redfoot: RF is yet another web app server. It uses Kid for templating (which I'm not yet impressed with). It's written in python. It's not very widely used yet. There is a huge number of projects in this class. The big trick with RF is that it keeps all its data in an RDF graph. User session cookie data; user account data; pages; arbitrary objects; dynamic viewers for those objects; what you would think of as "backend" code; the code for the admin shell commands, all of that stuff is stored in RDF. The code parts are cut up somehow and put on specially-annotated code nodes. Looking at the pieces of the RDF/XML that contain the server's own code keeps reminding me of literate programming, except this code isn't just cut up for clarity, it's cut up so it can be found dynamically and even loaded dynamically. eikeon made a patch to some viewer page at one point, saved his change to a web-accessible file, and I loaded the new code into my still-running server by running "redfoot load http://url/to/the/code". I could even non-destructively overlay a patch to the server code by adding my own RDF statement, if I wanted to. It's very interesting when a web server can manage its own code as easily as its own pages. As another test, I asked eikeon about making a displayer for some tagged photos in my other project (http://semfile.bigasterisk.com). Since both projects use RDF (and what respectable project wouldn't?), there was no effort required to import my whole photo set into the RF database. The image objects were immediately listed, and we added a demo page (two more rdf resources for the page and its support code) that showed the thumbnail of an image.
[link] 2005-09-29T23:34:51 strace internals: I read through the source to strace tonight, and learned the following things: the ptrace syscall is what you use to set a child process to stop at every syscall (or at every instruction, which gdb might be doing) the strace function groups, such as trace=file ("trace all system calls which take a file name as an argument"), is done by a simple table http://cvs.sourceforge.net/viewcvs.py/strace/strace/linux/syscallent.h?rev=1.38&view=auto as opposed to by analyzing argument types or something trace=file outputted more functions than its documentation claims it should; this bug was fixed in 2005/06. I see that "strace -e trace=file echo" outputs some lines without filenames on my home boxes. the output is emitted by thousands of 'tprintf' statements through the code. Adding a mode to output as XML, for example, would be about as tough as parsing the current output, which is tough enough. there is a -o !pipe_output_to_this_program feature, which I didn't notice before a companion program 'strace-graph' attempts to parse the strace output to make a tree of the processes that ran (cool!), but it appears not to be maintained and produces no interesting output on two linux distros I tried
| Unless otherwise noted, all content licensed by Drew Perttula under a Creative Commons License. |