Search Results: "cas"

20 November 2005

Matthew Palmer: The Fun Never Stops With Ruby

Well, there's nothing like posting a really rubbish program to your blog to find out the right way to do it. Firstly, Philipp Kern has come up with another, even shorter version than his version I posted in the update to my original Ruby post, this time blowing me away with the strangeness of explicit casts in Ruby. Apparently, casting an input stream to an array produces an array with one-line-per-element, as in this example:
 STDIN.to_a.sort_by rand .each l puts l 
As Philipp warns, however: "Ruby is full of fun and power; one must watch out that the scripts remain readable". For a fairly toy example, this solution is still fairly readable, however I can see hair growing on this thing if your program grows large. Next, Pierre-Charles David showed his qualifications for becoming a co-author of the next edition of the Pickaxe (AKA "Programming Ruby: The Pragmatic Programmers' Guide"), with his example and explanation. He's kindly given permission for me to reproduce his e-mail in it's entireity, since it's too good to chop up:
Here is the shortest and most readable version of your "randomize stdin" script I can think of:
  #!/usr/bin/env ruby
  print ARGF.readlines.sort_by   rand  
 
ARGF is a special variable representing either stdin or, in the case where file names are passed on the command line, the content of these files (think of Perl's <>). ARGF behaves like an IO object (although I think it is not one). In particular, it responds to the #readlines method which splits the receiver's content into lines and returns an array. In other words,
  lines = ARGF.readlines
 
is the idiomatic way of doing
  lines = []
  while line = gets() do
    lines << line
  end
 
in your example. The next part (sort_by) uses a new form of the sort method, which I think is not documented in the Pickaxe. It implements the Schwartzian transform technique. In essence, a random number is associated to each element of the array, which are then sorted based on this index. As a general style remark, note that although Ruby supports "while" and "for x in y" loops, they are rarely used, in favor of iterators and/or higher order methods. For example, to gather all the input lines in an array without using readlines, one might write
  lines = Array.new
  ARGF.each_line    l  lines << l  
 
or
  lines = ARGF.inject([])    lines, l  lines << l  
 
Hope it helps, and welcome to Ruby!
Pierre, your explanation definitely helped, and I hope it helps others too. The third person to help me out is Decklin Foster, through a post in his blog. What particularly caught me about his solution was the neat demonstration of another feature of Ruby which I think I will really learn to love: the ability to dynamically add methods to an existing class. "Aiee!" I hear all the purists scream -- and I can see the potential for severe misuse, too. But, since every good idea seems to get deeply perverted, we may as well have some real useful features to pervert while we're at it. Decklin has the clever idea of adding methods to the Array class that shuffle the elements of the array in a random fashion. His code is beautiful in it's simplicity:
 class Array
    def swap!(a, b)
        self[a], self[b] = self[b], self[a]
        self
    end
    def shuffle!
        each_index do  i 
            j = i + rand(length - i)
            swap!(i, j)
        end
        self
    end
 end
He then goes on to rewrite my bumbling example in probably the most comprehensible manner I've yet seen:
 STDIN.readlines.shuffle!.each    line  puts line  
Decklin writes, "Now that is cool.". I couldn't have put it better myself. My thanks to Philipp, Pierre-Charles, and Decklin, for helping me along the Ruby path. So, two new Ruby Rules for me to live by: Hmm, is it possible that Ruby is nothing more than Functional Programming by Stealth? Aiee!

Jordi Mallach: Hard drive failure

On Thursday, I went up to my father's house to pick up my desktop, now that I finally have Internet access at home so I can have permanent access to it from a more convenient place. While I was there, I decided it'd be a good idea to do an upgrade on my dad's box. While I was doing this, the nfs share of the Debian mirror in the home server that serves this blog stopped working, and I couldn't ssh in, although the console and ICMP appeared to work. Having no monitor attached to that box, I decided to reboot it and resolve the problem in a lame way. Had I known my primary hard drive had decided enough is enough, I would have looked for a monitor instead. After reboot, the server started doing a very loud and scary noise, which was not new to me. When the BIOS tried to probe the disk, it would not start up and would instead whine like that. When this happened in the past, switching the box for a few minutes and trying again was enough. Not this time, though, it looked like it was the end. Horrified by the fact that I had no really useful backup of /etc and /home, I tried over and over to get it working. I plugged the HD into another old AT box (which once served as my GNU Hurd playground), but I still got those scary noises. At least I knew it had nothing to do with the mother board. As it was getting late, I decided to take the HD with me, and another Maxtor of the same size (but not exact model) with me, to have a look in office the next day. I thought I'd have to restort to try to transplant the logic board from the good one to the faulty disk, but before that, I realised I could try mounting it in a USB cage. For some reason or another, this worked, and I quickly saved thetwo partitions it contained with no read errors. After this, I realised I had not done the copy as root, so I had lost all my ownerships. I plugged the disk again, and re-rsynced. It still worked. Alleviated, I went back home, copied the data to another old disk, and I don't remember why, I tried mounting the faulty disk again. I got scary noises even using the USB case, and no other tries have been successful, so I think it's completely dead now, just before my final mount which saved the data. The box is now back online, using a Seagate disk I had stored in a drawer and with no notes on it about it having any kind of problem. I suspect I will need to do real backups now, because the drive isn't as safe as it looked...
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58   DriveReady SeekComplete DataRequest  
hda: drive not ready for command
hda: status timeout: status=0xd0   Busy  
hda: drive not ready for command
ide0: reset: success
My little P150 needs a 6GB drive. I'll have to find one somewhere.

Andrew Pollock: [life] Hello America!

Where do I start? It's been an eventful couple of days... The flight to LA was uneventful. Qantas is certainly orders of magnitude more pleasant to fly with than United, even though we were seated in a bulkhead area. I had a 13-month old baby seated next to me (no, Mikal was on the other side), and he was about as well behaved as you could possibly ask a 13-month old baby to behave. Mikal also behaved himself. I had the intention of trying to get something approximating 8 hours sleep, as we arrived at LAX at 7am local time, but I only managed about 4 hours. I did spend about 8 hours with a mask on and my brain in idle, so I arrived at LAX being mostly coherent. Entering the US via LAX was a much less traumatic experience than I was expecting. The E-3 visa was accepted fine, and I now have an I-94 stapled into my passport. Quarantine involved getting looked up and down by a guy in a booth, who waved me through. We had 3 hours to spare (or about 2 by the time we cleared all the immigration/customs queues) and then hopped on a 50 minute American Airlines flight to San Francisco, hired a car and drove to Santa Clara. The accommodation we're staying in for a month is very spiffy indeed. It's a largish gated community of units. Mine's got a ground floor entry, but everything else (except the garage) is upstairs. When Sarah gets here, we'll put up some photos. The weather is lovely as well. Our first outing was to the Social Security office to attempt to get social security numbers. This wasn't as successful as I'd hoped, as we were too freshly in the country to show up on their systems, so we left with letters saying we'd get one within four weeks, when our details had been verified. Yesterday evening, we went for a general recce of the surrounding area, and checked out a supermarket. That was less disconcerting than I expected, although I don't think it was a terribly huge supermarket. Having a GPS certainly raises one's confidence when navigating significantly. Last night I discovered that all the keys in my apartment were not created equal, and that the two loose in the lock box on the front door were the only two that opened the unit, and the two sets on key rings on the coffee table only opened the amenities and my mailbox. So I got to spend a bit of time sitting on my front doorstep until the nice man from Synergy Relocations came out to let me in (except his key didn't work either, so he got to make conversation with a legal alien while we waited for someone else to come out with a key). Today, we drove around to see a shopping mall, and the first set of shops we found happened to be around the corner from an enormous (by my standards) apartment complex, which had some signage implying that it had vacancies, so we decided to get the low down on how renting worked before we did our rental tours. Casey drove us around in a golf buggy and gave a tour of what two different floor plans looked liked. It seems that in this part, it's standard for an apartment to include the refrigerator, dishwasher, microwave, washing machine and clothes dryer, which is good to know. Let me just say that if this is what living in an apartment complex is like, it's more like living in a resort. The place had pools everywhere, tennis courts, two gyms, a community centre, it was just unreal. It was also cheaper than I was expecting. We then went to a massive shopping mall to do some window shopping. Discovered Wetzel's Pretzels. Hope they're not too fattening... Tomorrow, I'm going to avail myself to the complex's gym, and generally get ready for the week ahead. Future posts will be in a new category, which I won't be feeding to Planet Debian as not to bore people. I will inflict Planet Linux Australia readers with them until someone asks me to stop. If you'd like a custom feed that excludes my American adventures, please let me know. I wonder if adjusting Blosxom's idea of timezone buggers up existing posts and aggregators like Planet in general?

19 November 2005

Todd Troxell: dumb asses

Found this under heading "What is a statement of verifiable fact" while browsing EFF's Legal Guide for Bloggers
A statement of verifiable fact is a statement that conveys a provably false factual assertion, such as someone has committed murder or has cheated on his spouse. To illustrate this point, consider the following excerpt from a court (Vogel v. Felice) considering the alleged defamatory statement that plaintiffs were the top-ranking 'Dumb Asses' on defendant's list of "Top Ten Dumb Asses":

A statement that the plaintiff is a "Dumb Ass," even first among "Dumb Asses," communicates no factual proposition susceptible of proof or refutation. It is true that "dumb" by itself can convey the relatively concrete meaning "lacking in intelligence." Even so, depending on context, it may convey a lack less of objectively assayable mental function than of such imponderable and debatable virtues as judgment or wisdom. Here defendant did not use "dumb" in isolation, but as part of the idiomatic phrase, "dumb ass." When applied to a whole human being, the term "ass" is a general expression of contempt essentially devoid of factual content. Adding the word "dumb" merely converts "contemptible person" to "contemptible fool." Plaintiffs were justifiably insulted by this epithet, but they failed entirely to show how it could be found to convey a provable factual proposition. ... If the meaning conveyed cannot by its nature be proved false, it cannot support a libel claim.

18 November 2005

David Welton: Ruby the Rival, Tk, "mini-lang"

I saw Ruby the Rival via an article on Lambda the Ultimate, and of course it tickled my interest in the diffusion, rise, and decline of programming languages. The guys they picked to interview have pretty good commentary - I found it thoughtful and insightful. Robert Cooper's comments to the effect that you should do the easy things first and make the complex stuff available are spot on. Simple stuff has got to be simple in order for the language and its libraries and applications to scale down, and without scaling down, you leave yourself vulnerable to someone who is willing and able to get people started with something easier than what you're offering. Bill Venners points out that the Rails folks have done a very good job of marketing what they've done. Agreed. It's been hard to see the opposite effect in the Tcl community, which has some really good technology that has been sold very poorly. Speaking of which, James Duncan Davidson says Ruby doesn't have a "compelling" gui toolkit. It has Tk though, and if they do their homework, will soon have Tile. And that's not bad... maybe it's not the glitziest thing out there, so I could see why it might not appeal to a Mac guy, but on the other hand, there are countless very compelling desktop apps waiting to be written that are interesting to people for what they do, not just because they are slick looking. And frankly, it's not like Java is that hot in the gui space in any case... Mini-Language Only tangentially related to the above, I found this while looking at ofbiz, which looks to be a pretty good system for what it does. However, the "scripting language" doesn't really make sense to my way of doing things. Look at the example towards the end: http://www.ofbiz.org/docs/minilang.html That seems like an awful lot of verbosity for something that doesn't absolutely need to be edited by a computer.

David Nusinow: Yay and Boo

In case you didn't see it already, Xorg 6.9 RC2 is in experimental. I also got to meet jordi and hacim, which was unsurprisingly awesome. I've been fighting all night with my new prism54-based card to try and get the firmware working on my "new" G3. I really don't want to have to snake an ethernet cable through the house, but I may have to for a little while. Thirmware.

Hanna Wallach: book and volume

Wow. Over 2 months and not a single blog post. Not intentional, but sometimes you have to do what you have to do. (Which in my case has been 10,000 lines of C++ and a workshop paper.) So, what’s new? Lots really, and I will write more as I wait for my 10,000 lines of C++ to run over the next few weeks, but for now, I’ll just mention the following: yesterday, Nick released Book and Volume, his latest piece of interactive fiction. I played it over a period of several months in my official role as “beta tester” and have the honour of being one of only four people to have (at this point in time) completed the game. It’s great. It’s immensely satisfying and very funny, offering a unique take on the life of a stressed system administrator and the corporate nature of American culture. You can read more about the piece on Grand Text Auto and on Nick’s site, which also contains instructions for installing an appropriate interpreter (apt-get install frotz, for the Debian kids) and a link to the the game itself. For now, however, I shall leave you with the opening paragraphs:
Your pager tickles you awake. Upstairs in the house of your childhood, in your room, and it must be time for school because—no, it’s the weekend, you remember, but your alarm is going off anyway. You should have been awake already. You’re going to miss the bus. Your mother climbs in the window. You’re dreaming. You’re a grown-up: It opens to you again, a sluggish window summoned by a mouse click. Waking up now in your own apartment, your new apartment. Your pager is buzzing and vibrating both, serious. It is in fact the weekend, but you’re not in elementary school. No one is crawling in through the window. You’re a system administrator for nWare. Waking up urgently, here in nTopia.

17 November 2005

John Goerzen: Kansas Weather: For People That Bore Easily

Last night, I figure we had every major type of precipitation: hail, rain, freezing rain, sleet, and snow, in that order, plus 50MPH winds. All in the space of a few hours. The wind continued. Terah told me, "you know you live in Kansas when the forecast says 'winds at only 20MPH tomorrow', and you're relieved!" Yup. Never dull here.

Uwe Hermann: Kitty - a podcast / video podcast / vlog client for KDE

I have ITP'd the podcast / vlog client Kitty, yesterday. I had a look at various vlog clients recently and Kitty seems to be really nice. A Debian package should be available in a few days, I already have a test-version running on my local box...

16 November 2005

Antti-Juhani Kaijanaho: The Finnish lay judge system

This essay is part of my Finnish criminal court series. See the introductory essay for more information and an overview of the Finnish criminal court system. There are no juries in Finnish criminal courts. Instead, there are lay judges, trusted lay people who actively take part in deciding criminal cases and can in some cases completely override the legally trained judge's opinion. See more ...

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.

Ian Murdock: No pressure

Claire Giordano: “[N]o matter what the result, this project [OpenSolaris] will be written up as business school case study. I don’t know whether it will be a positive case study, or a negative one… But it WILL be a case study!”

Martin 'Joey' Schulze: The Innovation Factor of Patents

The Science and Intellectual Property in the Public Interest project of the American Association for the Advancement of Science has conducted a survey on about 1,100 AAAS members to determine what effects patenting has had on research conducted by scientists in academia, industry, government, and nonprofit organisations. In the past, the patent lobby has often claimed that patenting is a means to foster development and save investments during research and development by not allowing competitors to use the same technique without paying licensing fees. The results of this survey were quite surprising because this exactly claim could not be validated. Industry scientists reported having more difficulty in accessing patented technologies than academic scientists. Bioscience scientists working in industry reported about problems that their research had been affected by these difficulties. Historically, academic scientists share the results of their research via papers, journal publications and conferences. They also get a lot of input by others at such occurrences. The commercial value of their research is also not always sufficiently obvious, but in the case of basic technologies or insight essential. This is not compatible with the patent system, it seems.

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: Name Overload

Name Overload?
First there was Debian Planet then along came the Planet Debian, unfortunate naming collision, but something we could mostly get used to and understand. If you’re not confused yet: well done. You soon will be: Guess which site that is? A third completely new name comprised of the two words “Debian” & “Planet”. WTF? Think that was fun? Lets try again. Stick with me: First there was Debian Help - now there’s another new site which is comprised of the two words “Debian” & “Help”: *Ugh* Now I’m personally of the opinion that competition is a good thing, but please people - can we all just get along without confusing our users/visitors? I’ll sidestep the whole trademark issue, in case my site is in trouble too ;)

Steve Kemp: GNUMP3d + apt

Security Updates
A new version of GNUMP3d is out. This is primarily a security update. Install it now if you use it publically. (Local mirror in case you’re running from source and the gnump3d.org site hasn’t updated yet)
Apt Updates
I’ve updated my personal APT repository. This now uses reprepro to create/update/manage it. The reprepro tool is utterly wonderful. (Although I used the backported Sarge version, rather than the older one). Expect an article on the Debian Administration website shortly. Now I have an “incoming” directory I can upload new package builds to, and have them magically migrate into the relevent section. The other significant change is that now I can host packages with Arch: All, as well as i386. This is useful as I distribute several perl scripts/libraries which were previously unavailable to non-x86 users. Talking of which I still have to finish my review of The Debian System written by Martin Kraft - I’ve been sitting on that for too long. (Summary: Great Book, buy it if you can’t get one donated to review ;) ).

David Pashley: Minimising service downtime during upgrades

Having just mistakenly performed a large upgrade including powerdns, I'm wondering if there isn't something we can do to minimise the amount of time we stop a service between pre-inst and post-inst. Could we have something like a post-unpack maintainer script or a flag telling dpkg that the package contains a daemon and to minimise the time between the maintainer scripts where possible. Yes I should read the list archives, but I'm about to go out. Must remember to check when I get back. Edit: Adeodato Sim pointed out that in most cases daemons should just do a restart in the postinst, unless changing files on disk is a problem. Need to investigate if this is an issue for pdns-server and fix it.

Jordi Mallach: Not that Cambridge

As predicted, the morning was not productive at all. At one point I slightly became concious and saw sladen fetching his bike, opening the door and saying me "Back in two hours!". We didn't know anything about him until 24 hours later. As we started waking up, we tried to think of a plan for the day. The morning was gone, though. Clint took us to a restaurant two blocks away for breakfast, or actually brunch, because that was the only food in many hours. I ate some "pancakes" with banana in them, and barely could finish them; they are very filling. We went to the promenade for a last look at the Manhattan skyline and took some pictures while we tried to figure out what to do.


A last view over Manhattan Mako was developing a plan in secret, though, which involved micah and his car. Micah found out soon after. We went back to Clint's, expecting to find sladen somewhere, but we didn't. I packed my things, and when we really needed to go, we resolved to put his things in the entrance so he could find then and do whatever he wanted on his return. We went on the Metro to Union Square, where, hear this helix, I saw TONS of raperos doing their break-dance thing (ok, maybe not tons, but I did see them). And two blocks away, we arrived to the most incredible book store. Mako has blogged many times about buying very rare books at the Strand for ridiculous prices, but this was totally unexpected. The Strand is huge. On the outside, there's carts with hundreds of second-hand books, all for one dollar. Mako used to go there and browse the books to find interesting stuff. The Acetarium is full of them! Most of the dollar books are total crap though. A very high percent talk about god, religion, "our troops" and stuff like that. Mentally filtering what might be good and what is not is not easy when you haven't done it before. Mako started scanning the shelves as soon as we arrived, and every now and them he'd pick some totally stupid title. I was on my own shelf, missing many good stuff, while mika, Clint and mako did their own. Clint found quite a few titles, but mako didn't find anything good. I got lucky though, and found the precious book of the day: The Spanish Anarchists. The heroic years 1868-1936, by Murray Bookchin. Although old, it was in very good condition, and mako immediately asked if I was taking it. :) I won! The inside of the Strand was incredible too. Three very big floors packed with books, plus the half-priced "reviewer's copies" at the basement. I was totally overwhelmed by the amount of books I'd be interested in buying, and the limited weigh I should be carrying back, so I did my best not to look too carefully. For a few hours, I didn't have a too clear idea of what mako's plans were. At some point, micah phoned him and we rushed to the PATH, the train that goes to New Jersey. Apparently we were meeting micah at Newark, but I still didn't know why we had to go there. During our ride, I could see how pleasant New Jersey is to the human eye. Miles and miles of heavy industries. I'm pretty sure it's the ugliest place I've ever seen. What I couldn't see, and I'm still disappointed, is any of the viciously arrogant rats of the New York metro system. Mako had told me about how they look at you, like saying "if you come down here, you'll be left with 9 fingers", and the incredible number of them on the tracks. Unfortunately I couldn't see any. I blame Michael Bloomberg. At Newark, micah appeared in his car, and we all hopped into it. We apparently were going by car to Boston... including Clint. I was puzzled, as he had to work on Monday, but he'd said that he'd simply "come back". There was a problem though, mako had dilinger's keys, and he was going back to NYC from Boston, and we didn't have time to get to Boston before he left, so we had to find a way of leaving the keys in NYC so he could get into his appartment. Finally, mako resolved that Clint would be left in a cold street, in a rough area of NYC, and he would handle the keys problem. I still didn't understand what was going on. We headed North, and I quickly fell asleep on mika's nap. I'm getting old. When the car stopped again and I suddenly woke up, I looked ahead and... HORROR! We were at the door of a McDonads. WTF WAS GOING ON? So it seems that when you're on the road, there's no much other choice than shit food. After a quick discussion with mako about how badly those burgers taste, I quickly went back to sleep, until we were in Boston. It took a while to find a parking spot, because all of them "permit only". It's impossible to park if you come from somewhere else. I was finally at the Acetarium, a very cool flat in Cambridge, 15 minutes away from the MIT. It was 3:30 in the morning. The day after, we woke up pretty late, and as I opened my laptop and found a privmsg from sladen, he was was knocking at the door. This man has an incredible ability to disappear and reappear when he's most unexpected. Apparently he managed to grab his stuff in NYC, fetch the bus and arrive at 2 in Boston, meeting dilinger at the station, and mako as he went out to MIT. micah and I went to explore Boston, but never managed. We consumed a few hours when trying to ship some equipment to micah's colo, and then trying to find food. When we were ready to go, micah got a very badly timed call, which made him go back to the Acetarium: a server at work was dying or dead. At one point, it was late enough that going to Boston wasn't worth it, so we went to visit the Media Lab instead. On our way there, micah and I kept chatting about this and that, and found out how small the internet is. We both know a bunch of common people from uncommon places like Per , from our involvement in social projects in the net like Indymedia and Sindominio.net. The MIT is incredible, specially the Stata Center by Frank Gehry. We wandered around as we only got voice mail from mako, until an hour later we found we was like 20 metres away from us. He gave us a tour through the Media lab, and it was incredible. I had never seen something like that. Every lab was colourful and fun, and very cool developments were going on everywhere. I also saw the coolest mame box ever, with an arcade case and everything.


The Stata Center, right next to the Media Lab After the tour, micah and I headed back, while sladen stayed to have a look at one of mako's projects. When we got back to the flat, there were a few people already there for mika's sushi party, and I rolled my first sushi rolls, which was fun. A bunch of Debian people joined us, including zufus and gravity, and had a great chat with them. The party ended way too late and after too many beers. sladen used his secret disappearing abilities, and a few colleagues from mako crashed, so there was a bit of overbooking. Mako's solution was simple. mika, him and I could share their bed. I can't say I have slept too much, because mako would keep pulling the blanket and leave me out in the cold, and I was trying not to squish mika. But it went ok, although we discovered too late that mika was hot while I was cold, and we swapped our places too late. Today, we'll go find the Freedom Trail and walk a bit around it, meet gravity and zufus for lunch, and I will sadly have to go back to Cambridge, quickly pack and head to the airport to catch my plane. My hours in North America are expiring.

Norbert Tretkowski: Broken alpha systems after udev upgrade

Alpha systems running testing/unstable with a Debian kernel could be in trouble after upgrading to udev >= 0.073-1, the system won't boot anymore. That's not a bug in udev, but a problem in the Debian kernel configuration on alpha. From the release notes of udev 0.073: Fixed bug in udevd, if inotify is not available. We depend on netlink uevents now, kernels without that event source will not work with that version of udev anymore. In short, kernels using udev >= 0.073 must have CONFIG_KOBJECT_UEVENT enabled, which wasn't the case in the Debian kernels for alpha until 2.6.14-3, which I uploaded to unstable yesterday in the evening. Thanks a lot to Uwe Schindler for his bugreport with the correct solution.

Next.

Previous.