Search Results: "ron"

18 November 2005

Gerfried Fuchs: that's what friends are for

After quite a while a new Haiku. This time it's somewhat longer, and (like mostly) due to recent happenings. I hope you like it as much as the person for whom I wrote it.
friends are there for you
they help you through thick and thin
that's what friends are for to depend on them
is just really natural
don't try to be strong show them how you feel
if they are true friends for you
they are there for you helping through bad times
is what friendship is about
so don't try to hide friends are there in good
but you find out when in bad
who is your real friend people hanging out
when you are in your good times
are nice, but real friends? so bad times are good
if you want to find it out
who is real, who's not that's what friends are for
they help you through thin and thick
friends are there for you

Erich Schubert: SELinux backports for sarge

I've been preparing SELinux backports for Debian sarge today for a public release. I've been running them on a couple of servers for quite some time already, but I decided to fully document what I did as well as uploading them to a publicly accessible location: Debian sarge SELinux backports Note that you still need a policy (e.g. the selinux-policy-default package from unstable, a CVS checkout from the NSA repository on sourceforge or the new reference policy being heavily worked upon) as well as a SELinux capable kernel (e.g. the latest 2.6.14 packages from unstable) Note that alioth is a rather "public" box, so if you don't trust it (or me) - grab the sources from a location you trust, grab the Debian .diff and mine and do an interdiff. The interdiff should be really easy to verify at least. Also check out the Backporting HOWTO I wrote documenting my efforts. I hope I'll be able to bring you detailed installation instructions sometime soon. Until then I can point you to some SElinux setup notes in the Debian wiki. My cron and init packages do have the "bad" stuff disabled when SElinux is enabled.

17 November 2005

Andreas Metzler: meme time

Hmm, I cannot resist following up Clint's and Jaldhar's "have you read geeky books"-meme. I "score" 10/20 on the first list, but only 4,5 on the second one (Stephenson _again_, Pynchon, Tolkien, Lem and "Through The Looking Glass.) BTW reading now: Chronicles of Narnia, next in queue Jasper Fforde's Something Rotten.

Ross Burton: Express Tosh

If I had known that the Daily Express front page yesterday was just so damn good I'd have bought a copy myself. With a paper bag on my head, obviously. Instead I have to make do with a small image. Diana Fund Pays Out To Gypsies And Asylum Seekers I'm still not sure that this isn't some great spoof or prank. Maybe someone broke in and changed the front page just as it went to press? What do we have here: Marvellous stuff. I can only imagine the Express has taken to being a parody of itself... NP: Individuality, Rachelle Ferrell

Martin 'Joey' Schulze: Documenting problems is bad - privately demanding is ignored

After I publically complained about how things are still working (or how they are rather not working) in the LinuxTag organisation, I am now attacked at raising my voice in public. That's quite interesting, because at the end of last month, I raised my voice in private already. However, the items I mentioned or demanded have not been approved yet. I have to admit, though, that when the press release was sent to the group, it shouldn't have been published yet. That it was, was a communication problem with a third party. However, there is still the question why the third party (who wrote it) could publish the press note before it was sent to the internal group. Something is definitively wrong when things are sent there so late in the process. As a result, a lot of people who should be happy and working hard to get LinuxTag 2006 organised are frustrated. Frustrated, because it doesn't seem to be possible to work in a team or to save LinuxTag. Frustrated, because they demand things that should be a matter of course, which seem to be more or less ignored. Frustrated, because their work is ignored. Frustrated, because I dare to make things public. To me it looks as if people only see the symptoms and complain about the symptoms instead of trying to understand the cause of the problem. However, and to make this article look a bit positive at least, I still see a small chance to get LinuxTag 2006 organised, but a lot of things have to change before. To me it is obvious that it doesn't work the way it is currently.

Kenshi Muto: ITA: skk packages

I noticed some skk packages had maintained by Kawamura-san were orphaned because he became MIA. Unfortunately I dunno why he became such a status, but his packages, especially skk is very important for me and many users. It's hard and painful for me to input Japanese without SKK backend system (I'm using ddskk on Emacs and uim-skk on X as a frontend). So I picked up skk packages from orphan sea with Junji Yamashita-san and improved some parts of them. BTW I uploaded new CUPS 1.2 snapshot, svn r4841 to experimental.

Adeodato Sim : Books

About books:

16 November 2005

Jose Carlos Garcia Sogo: Packages for Beagle 0.1.2

I am working on my own private arch repo in Beagle 0.1.2 package. It is mostly done, but I need Mono 1.1.10 packages to test it running. As far as I know, those packages are not ready, nor available in any private repository. Anyway, if you are running Beagle 0.1.1 I strongly recommend you to upgrade your kernel to 2.6.14 version, which comes with inotify enabled. It will solve part of the problems of memory leaks, though not all of them.

Steve McIntyre: Busy, busy, busy...

It's been a while since I blogged last, but I'll plead lack of time as a defence. Again... :-) Well, after a few weeks in the new job at Amino things are settling down. I'm thoroughly enjoying learning my way around a new codebase, and the people are really good and friendly too. I'm already in charge of the new cvs server at work, which somehow got a Debian installation on it rather than the Fedora that people had been expecting. How could that have happened? On the Debian front itself, I've been a little lax and feeling guilty for that. My advertised debian-cd developments are behind schedule as I haven't had the time to work on it. On the plus side, I've finally diagnosed and fixed the grave bug that was holding the new upstream version of cdrtools out of testing. Once things have migrated through, I'll then be clear to start merging in my JTE code. Then debian-cd upheavals. Yay!

Ian Murdock: Small pieces down the software stack

John Carroll:
[T]echnology across software domains should be consistent. There should be a standard, however de facto, that works everywhere. Skills should be portable across those markets, so that someone with experience in desktop software development has a decent chance of developing for handhelds. Everything should just work together, and development across all devices should be relatively straightforward to someone with experience in any one of them. Microsoft has been very good at this. […] I wonder whether the open source world can match that consistency. Granted, there are movements to make things consistent, such as the LAMP set of technologies for Linux, or the Linux Standard Base project. However, the structure of development for open source products militates against the establishment of any consistent standard. Open source development relies mostly on voluntary contributions. People don’t tend to contribute to ALL open source products (that would be impossible). Rather, they concentrate mostly on the products that interest them. This results in a developer version of tunnel vision. Since all that matters is the creation of the handful of products to which the volunteer contributes, what matters is the interests of contributors to a single project, not the interests of technology which should span ALL products.
Great points, though I clearly disagree that the open source community is fundamentally unable to match Microsoft on providing a consistent environment. It’s going to take some work on our part though. One of the reasons Microsoft has historically been so successful is its unique ability to integrate disparate technologies into cohesive wholes, as well as to leave the mechanisms they use to do this just open enough that others can integrate with them to a degree but never so open that they can do so better than Microsoft can. Of course, Microsoft can do this because they develop, own, and control each of the pieces and the interfaces between them. Other platforms (Linux, Java, UNIX, even the Web to a certain extent) are comparative mishmashes for the exact reasons John describes, namely that every project is developed independently, and that there’s comparatively little thought put into how the pieces interact. The only parties that do think about these issues, the Linux distributors, tend to do so after the fact, and, of course, they have no direct control over the projects that produce the pieces to push any integration improvements they might make upstream (in the general case anyway). Furthermore, once multiple solutions in a given problem domain emerge, it’s not always possible to generalize the interfaces when the projects behind them don’t agree with each other on the “right solution”. In other words, because it’s an after-the-fact thing, “not invented here” and general inertia come into play. So, while the technical aspect of the problem is important, namely the interfaces between components (APIs at the source level and ABIs at the binary level), there’s a social aspect here too. We need to encourage the kind of competition at the implementation level that results in technical excellence while fostering a sense of cooperation at the interface level to ensure that, collectively, the various implementations fit seamlessly into a larger, consistent environment. In other words, we don’t want to get in the way of open source project and Linux distro innovation, but we do want to encourage open source projects and Linux distros to innovate in a collaborative fashion so the technology that ultimately wins in the marketplace can be standardized with as few legacy issues as possible (or, in the case where multiple best practices emerge, for legacy reasons or otherwise, we want to collaboratively define a uniform interface, i.e., cooperate on interface, compete on implementation, etc.). That’s the only way we’re going to get there.

Erich Schubert: Effects of being on the first page in Google

A few days ago, I made it to place #10 on Google for a very generic term. With my "ancient" personal homepage. This made my page visitors skyrocket from around 800 to 1300 unique visitors a day (well, I only have a two day sample with the high value). Impressive. At the same time, the number of emails and comments in my guestbook has doubled, too. My google pagerank is still just 5 for that page; my front page has 6. But the pagerank seems to be quite off often anyway... Just today I received an offer of approx. $ 45 a month for a link banner on my page... At the same time, I havn't really updated the page for more than 2 years. I've been thinking about a redesign for four years, and I still havn't come up with a design I'm really happy with... :-(

Horms: Back from Korea

I made it back from Korea in once piece (several weeks ago), however, sadly, my camera did not. Well, its in once piece, but one not working piece. I took it back to the shop for repair under warranty, they called to tell me it was fixed. But alas when I went to pick it up, it was still not working - though in a slightly different way. I think its an electronics failure. I hope it gets fixed soon so I can take some new snaps. Fortunately Dave's attempts at taking photos were more successful than mine. As an added bonus, his trip with Soyong was around 2 weeks, whereas Chiz and I only dropped in for 2 days. You can read all about it on his blog [Oct] [Nov] which also has links to lots of awesome photos. In semi-related news, by brother sent me a copy of Lee Frost's "The Complete Guide to Night and Low-Light Photography". Mmm, wish I had my camera back...

Anthony Towns: Hacking dak

Who can resist a good rhyme? Or a bad one? So this round of dak hacking turned out to make the AJ Market scheme another notch more confusing – hence the delay in blogging, and the teaser in my last post. The issue leading to the confusion is that the major item on the list to start hacking on was SCC, which unlike the projects I’ve undertaken so far, is more than a day’s hacking. In fact, due to the need to give mirrors a chance to adapt to the new system between it being implemented and actually used, it’s actually more of a multi-week task. And doing it as a one-day-a-week project would extend that into a multi-month task afaics. I guess that’s still better than never, but obviously it’s worth looking into alternatives. Naturally, then, the first phase of a longer project like this is threefold. We’ll call it “the three P’s”. Planning My theory at this point was to come up with a plan for what to do, try figuring out how much work it’d take, and then see what sort of financial arrangements might be plausible – not involving me cutting a few weeks out of my life for spare change, but without making the whole thing an unleapable chasm from what the AJ Market’s currently managing either. I figured writing it up as a semi-formal proposal makes most sense:
Summary Implementation of the outstanding mirror split proposal for the Debian archive to allow new architectures, particularly amd64, to be included in the archive. Benefit In spite (or perhaps because) of its simplicity, this project has been languishing for over two years, and is not currently being worked on; so at present it’s not even possible to estimate when it would otherwise be completed. It is most notably preventing amd64 from being integrated into the normal Debian development environment, causing derived distributions to maintain amd64 specific patches themselves. In the longer term, reducing the constraints imposed on the archive size may allow the introduction of additional suites, such as backports or volatile, as well as additional architectures; though significant further discussion on this would be needed. Background Since at least mid-2003 the Debian archive has been closed to new architectures due to the already large amount of space and bandwidth required to become a Debian mirror. At present, the archive uses some 158GiB of disk, and about 1GiB per day; additional architectures are expected to require approximately an additional 10GiB each, and there are likely around half a dozen architectures that will be considered for addition once the moratorium on new architectures is rescinded (incl amd64, armeb, sh variants, kfreebsd and possibly partial architectures for arch variants such as s390x and ppc64). The primary work needed to fix this involves:
  • ensuring the mirror network operates correctly when a majority of mirrors are partial; this reduces the impact on bandwidth and storage capacity
  • optimising portions of the archive maintenance software, particularly apt-ftparchive; this reduces the load on the archive server
  • providing appropriate guidelines on the qualification criteria new architectures need to meet in order to be added to the archive; this provides a limit on future increases, allowing growth to be appropriately controlled
Actual work I expect there will be six phases to the project:
  1. cleanup of the archive as it stands, and establishing a clear categorisation of its contents to define what a partial mirror by architecture or suite should officially contain
  2. providing appropriate scripts to ensure mirror sites can easily comply with the previously defined expectations for partial mirroring
  3. devise an appropriate structure for the new mirror network, that can easily incorporate existing mirrors, and coexist with the existing structure
  4. provide information on the new structure to both mirror admins and users; assist with the transition, and resolve any problems found
  5. ensure the archive management software is appropriately optimised, and that archive inclusion criteria have been debated and established
  6. add new ports that have passed the qualification requirements to the archive
In theory, a couple of days for each of those sound plausible, so making that twelve days actual work (with a couple of week’s delay in between for mirrors to have some time to adapt to the new network). On the downside, twelve days at a day a week is over three months of real time, not counting the possibility of doing other things with the one day a week, or Christmas, or the aforementioned delay for mirrors. Yick. So much for planning. Preparation So the next “p” is preparation. In this case that’s finally getting around to fix dak CVS, which has been slightly broken since May. The extent of the actual breakage was just the loss of the ChangeLog history, aiui (or at least, that was the unrecovered breakage), but the result of that was months of uncommitted changes on both ftp-master and security (and reportedly from Ubuntu’s dak installation too). The changelog for the first set of commits (not counting buildd changes from ftp-master, security changes or Ubuntu changes that haven’t made it to ftp-master) looks like:
        * tiffani: new script to do patches to Packages, Sources and Contents
        files for quicker downloads.
        * ziyi: update to authenticate tiffani generated files
        * dak: new script to provide a single binary with less arbitrary names
        for access to dak functionality.
        * cindy: script implemented
        * saffron: cope with suites that don't have a Priority specified
        * heidi: use get_suite_id()
        * denise: don't hardcode stable and unstable, or limit udebs to unstable
        * denise: remove override munging for testing (now done by cindy)
        * helena: expanded help, added new, sort and age options, and fancy headers
        * jennifer: require description, add a reject for missing dsc file
        * jennifer: change lock file
        * kelly: propogation support
        * lisa: honour accepted lock, use mtime not ctime, add override type_id
        * madison: don't say "dep-retry"
        * melanie: bug fix in output (missing %)
        * natalie: cope with maintainer_override == None; add type_id for overrides
        * nina: use mtime, not ctime
        * katie.py: propogation bug fixes
        * logging.py: add debugging support, use   as the logfile separator
        * katie.conf: updated signing key (4F368D5D)
        * katie.conf: changed lockfile to dinstall.lock
        * katie.conf: added Lisa::AcceptedLockFile, Dir::Lock
        * katie.conf: added tiffani, cindy support
        * katie.conf: updated to match 3.0r6 release
        * katie.conf: updated to match sarge's release
        * apt.conf: update for sarge's release
        * apt.conf.stable: update for sarge's release
        * apt.conf: bump daily max Contents change to 25MB from 12MB
        * cron.daily: add accepted lock and invoke cindy  
        * cron.daily: add daily.lock
        * cron.daily: invoke tiffani
        * cron.daily: rebuild accepted buildd stuff
        * cron.daily: save rene-daily output on the web site
        * cron.daily: disable billie
        * cron.daily: add stats pr0n
        * cron.hourly: invoke helena
        * pseudo-packages.maintainers,.descriptions: miscellaneous updates
        * vars: add lockdir, add etch to copyoverrides
        * Makefile: add -Ipostgresql/server to CXXFLAGS
        * docs/: added README.quotes
        * docs/: added manpages for alicia, catherine, charisma, cindy, heidi,
        julia, katie, kelly, lisa, madison, melanie, natalie, rhona.
        * TODO: correct spelling of "conflicts"
Ugh. Still, that’s enough to start work. And the final “P”? Come on, be honest with yourself, you know what it’s going to be. Procrastination Okay, that’s not entirely fair; the irrelevant bit of work was actually on to TODO list before SCC (mostly because it was something that I could get done reasonably quickly) and in fact was this line of the above changelog:
        * dak: new script to provide a single binary with less arbitrary names
        for access to dak functionality.
All the various model/actress names have been getting more than a little confusing recently, with almost forty in the dak suite, and another two dozen or so in use elsewhere – and then there’s the fact that the whole hot babes thing is both a bit offensive, and getting a bit old. OTOH, you need something to rename them to. We ended up deciding on the “version control solution” and introducing a “dak” command that’d launch all the different little bits of functionality depending on arguments, in the same way cvs, svn, tla, bzr, darcs etc do. The implementation’s kinda neat: we have a list of commands (like “ls”) and their description (“Show which suites packages are in”), along with the python module and function they’re in (“madison”, “main()”). That let’s us not actually have to change any of the other scripts immediately, and lets “dak ls foo” work the same as “madison foo”. It also means that down the track we don’t need to have separate modules for each subcommand, and that we can rename modules and functions without affecting the user interface. Of course it also means that all the internal scripts haven’t changed to use the new names yet, leaving the new interface a bit underused, but hey, “dak ls” at least manages to be one character shorter than “madison”, so that’s a win! To be continued…

15 November 2005

Jonathan McDowell: No more hardware today, please.

So, today has been a day of hardware. Some good, some bad. First, the good. Take one Via EPIA-M motherboard, add a helping of LinuxBIOS and Etherboot and let simmer for a few hours on a low heat. Then add a sprinkling of Phil Hands' d-i preseeding for the final garnish. Tweak to suit your tastes and lo and behold. A neat little motherboard that does proper serial console, boots d-i over the network via tftp and does a completely automated Debian install. Of course, it's not quite that easy. LinuxBIOS requires a few out of tree patches that are still under discussion. The latest version of Etherboot (5.4.1) doesn't seem to work (lots of rubbish on the serial console and no boot), but the version that does (5.2.6) requires a backport of the latest via-rhine driver to avoid leaving the network card in a state that Linux isn't happy with. And Phil's documentation could do with some updating (which I should really email him about). Oh, and add to that the fact that numerous things seem to assume that there is a PC BIOS and that it will support standard interrupts. Yeah, like that's going to happen. Still, I seem to have almost got there and it's quite funky to watch it all happen automatically. Kudos to the d-i team for the ease with which you can preseed. Flush with success I moved on to the next challenge; scanning some forms before posting them off. Nice and easy, normally. If it weren't for the fact that the machine with the SCSI card for the scanner just happens to be the one I stole for the above, and that the new case it's in doesn't allow any PCI cards. Bah. So, find a spare machine, get it into a state where I can actually drive the scanner, scan away. Took far too long. I really need to get it hooked up to my main machine, but there isn't enough desk space to have it close enough for the cables I've got. Perhaps I should crack and buy a USB scanner. I don't really need high quality, just something as an alternative to photocopying. After that trial I've moved on to upgrading my PVR box; I got a new 320GB HD today to replace the 40GB that I'd been using - it was getting to annoying to have to either watch or syphon off various series that I'm recording. While I had the box open I decided to upgrade the motherboard to something that might support wake-on-lan, so this turned into a bigger job than it should have been. :( I'm currently waiting for the data to copy across before trying to stick it back together. Bah. Don't suppose anyone has an S370 P-III better than 667MHz and no better than 1GHz they want to part with cheaply? I'm currently running a Celeron 800MHz (which I think is a slight step up from the previous PIII-667), but a little more oompfh would help with streaming over the network. I'd just upgrade to something modern, but I suspect the extra cost of silent cooling would be a killer.

Steve Kemp: Things I have never written: #3

A secure Network Server
Ironic.

Steve Kemp: Things I have never written : #2

KDE
I have never once written anything using Qt. Why not? I have no real dislike of the toolkit, license, or implementation language. It just hasn’t ever been necessary or appropriate for me to use it. Generally speaking I only dabble with coding online applications in Perl/PHP (Perl is my preference, sometimes I get suckered into using PHP). Any software which I’ve needed to write with a GUI usually ends up being coded using the raw X11 libraries (xlib, etc). A few times I’ve needed to have something be stable, sharable, and GUI-driven and xlib didn’t cut it I’ve chosen to use the GTK libraries. Mostly that has been down to three reasons:
  • Finding small examples of code is very simple; as it is well-used.
    • By contrast many Qt applications are larger pieces of code. Finding examples using the functions you’re interested in is harder.
  • I love C++, but generally I develop in Perl, or C.
  • I don’t have to worry about the moc preprocessor, writing Makefiles, etc.
I’m sure that sometime in the future I will experiment with Qt, and possibly even install KDE to try it out. But it won’t be soon. (I think that desktop environments are a good thing, and can be attractive, productive, and useful. However I’ve only used Gnome briefly and tend to stick with the more lightweight IceWM environment). Once upon a time I did install and tinker with KDevelop, but nothing much came of it. When I lost my desktop machine due to hardware failure I didn’t feel the need to re-install it. Instead I stuck to using GNU Emacs + Vim for editing code.
Right now I’ve written that I shall go back to shaving my head. To make me look more like my avatar.

Steve Kemp: Things I have never written #1

Coding Mistakes
I broke my debian administration website yesterday. Predictably enough I’d woken up around 9AM and thought that it would be a good time to make significant refactering changes. Tested them on my laptop, committed them to CVS, then updated the live site. Had a quick play to make sure nothing had obviously broken - but didn’t try to leave a comment on an article. Went to sleep and woke up around 4pm to find 15 emails telling me things were broken. Most mails on the site in a single day! Should be fixed now. But I’ll never again make changes before lunchtime, I’m just not good with the whole sleepy-coding thing.
Things I have never coded: 1
Inspired by Joey Hess’s “Ten years of free software”. Things I have never coded part 1. I have never coded a text editor. *shock* In the past I have written simple wrappers around the various text controls in different environments - for example under Windows I once coded a tabbed text editor called MyNotepad, which featured a novel dockable tree-control to the side which allowed navigation and loading of files easily. When I first started working with Java I coded a similar thing, but with the ability to load external Java .class files as plugins. This editor was called Rosetta, inspired by the band Rosetta Stone (who were in turn inspired by the actual Rosetta stone ) At times I think about text editors. I use them daily, obviously, and I love working with some more than others. My editor is usually GNU Emacs but I’m also partial to Vim. I will use both happily; although neither is pleasant without my personal customizations. Simple text editors are a traditional project for coders, and freshmeat is littered with their discared corpses. Probably the only reason I’ve not started - that and apathy. My ideal editor would be:
  • Both curses and x11 based.
  • Scriptable (Lua is love?)
  • Extensible.
  • Portable between (at least) GNU/Linux and Solaris.
  • Modeless.

Steve Kemp: Lua annoyance

Lua Directory Handling
Arrrgggghhhhh!!!! OK maybe lua is not love. I just realised that Lua has no concept of directory handling (opendir, readdir, etc). Indeed it isn’t possible to tell whether something is a directory or a file. So I added some more primitives to the Lua socket extension library. Most usefully a readdir call. This means the sample webserver can now serve directory contents if index.html isn’t found. It can also now fall back to serving a “default virtual host” if the requested one doesn’t exist. The webserver code is now very stable and complete. The only omission is CGI handling, but I’m not going to bother unless prompted strongly. I’ve added some simple examples to the documentation and I think things are looking good. The Debian package has been downloaded a few times, but no real feedback - feel free to share, don’t be shy!

Steve Kemp: Advogato + Syndication

Advogato
Randomly clicking around Advogato today I accidently tried to login. Rather than seeing “Person not Found” which is all I’ve seen since my account(s) were removed I now get “incorrect password”. It looks like my primary, and replacement accounts at Advogato are back. At the time those accounts were removed I setup this blog so that I could still remain syndicated upon Planet Debian. It would be nice to have the Advogato account(s) back, but I could live without them. (Indeed mailing Raph at his acm.org address bounced so I may will have to)
Syndication
For my own notes. This blog appears at: Stalker-tastic. Of course my daily life goes entirely elsewhere - but that contains rudeness, angst, & etc. As you would expect from LiveJournal ;)

14 November 2005

Wouter Verhelst: Automatic networking

A long time ago, I wrote:
In these days of VPN, IPsec, dynamic routing, tunnels, IPv6, and autoconfiguration protocols, one would expect that it would be possible to configure a laptop to find all kinds of hosts automatically, both for those that are network-specific (proxy servers, NNTP-servers), and for those that are not (mail servers, version control systems, ...).
I then went on to say that I could not, at the time, expect my laptop to find those networks by itself; every time I logged on to some network, I had to set up at least two SSH tunnels. I received a lot of feedback to that post, and I now do have my laptop set up so that it configures itself automatically if necessary. Well, almost; see below. This is what I've done: I don't use ifupdown on my laptop anymore. The package is installed and configures my lo interface, but that's it—nothing else. Instead, I'm using whereami to configure my network cards. Whereami is an excellent piece of software that is configured through two configuration files: detect.conf and whereami.conf. The former has a pretty peculiar syntaxis, which you'll need to get used to at first; but it's very powerful. There are a few things you can do in detect.conf:
  1. Run tests. A test will check whether a condition is true, and set a location based on the result. An example of a test could be
    testmii eth0 lan
    
    which checks whether the MII detects a cable (testmii) on eth0, and will set the lan location if that is true. Tests are the raison d' tre of detect.conf; the point is to run as many relevant tests as possible, to get as much information as possible about the location where you are; that way, you can configure the system later on from whereami.conf (see below). There's other things like testdhcp (check for the presence and/or the returned IP address of a DHCP server), testap (test for the presence of an Access Point), testmodule (check whether something loaded a given kernel module), or even testarp if you're desperate (to test whether a node with a given MAC address lives on the network).
  2. Checking locations. For instance, you might want to run testdhcp on eth0 only if the location lan is set already. This way, you don't get timeouts if you're on the train or anything. Checking locations is done with if <location> ... elif <location> ... else ... fi. Which is to say, you get a multi-line block of if structures, in which you can then run other tests conditionally. I'm just too lazy to write it out here :-)
    Unfortunately, it is not possible to nest if structures in detect.conf; but I don't think it's actually necessary for the detection (it might be nice for whereami.conf later on, but there the issues can be worked around).
  3. There's also the possibility to do things like setting environment variables, default locations, and some similar housekeeping things.
It is possible to set more than one location from detect.conf; for example, right now my laptop claims it's at werk,dhcp,lan. At home, it detects it's at thuis,dhcp,lan—unless I use my wireless interface, in which case it detects it's at zd1211,thuis,wlan,dhcp,wdhcp After whereami finished the tests in detect.conf, your network should be working (provided you have a network cable plugged in, or are in the vicinity of an AP that you can connect to). Next, it will process whereami.conf. The genius of whereami probably lies in whereami.conf: this is a simple shellscript, but every line can be preceded by one of +, -, or =, followed by a location. For example, I have (amongst other things) this set up in my whereami.conf:
+lan ln -sf /etc/news/leafnode/config.generic /etc/news/leafnode/config
+werk ln -sf /etc/news/leafnode/config.werk /etc/news/leafnode/config
+thuis ln -sf /etc/news/leafnode/config.thuis /etc/news/leafnode/config
Whereami will check this file for any lines that start with '+' followed by a location it's going to, or '-' followed by a location it's leaving from, or '=' followed by a location it's either leaving from, going to, or staying at. It then removes the +/-/= plus the location, and dumps the rest of the line to a file; that file is then ran as a shell script. In other words, the above code will overwrite my /etc/news/leafnode/config with an appropriate configuration, depending on what network I'm entering. I don't have to reconfigure NNTP servers anymore. Nor do I need to set up any tunnels—whereami does all of this for me, and more. Next, since a few weeks, I've also added ifplugd. Previously, when I would get my laptop to resume from swsusp, I would need to manually run whereami afterwards; with ifplugd, this is no longer necessary—I just removed the ifupdown script in /etc/ifplugd/action.d, and replaced it with a whereami script that I quickly wrote myself (not as if it's hard, obviously). There's just one thing left: the proxy server. There are just way too many programs that one needs to configure to use a proxy server (or not) in Linux; and though it's possible to configure a proxy server by letting firefox "detect" it, I have no clue how that's done. Additionally, programs that use proxy servers through environment variables can not be reconfigured, unless one logs off and on again. I guess I'm looking for something that will do transparent proxying if there's a proxy server on the network, or just forward the requests to the remote server if not. But that's for another time.

Next.

Previous.