Search Results: "cas"

28 November 2006

Sven Mueller: Steve Kemp s weblog Blame it on rock and roll

Steve Kemp wrote an irssi script and accompanying utility to show facelets corresponding to IRC users, following an idea earlier mentioned by Lars Wizenius ,less than 5 hours earlier. Wow, that certainly is a neat thing. There is one problem for me though: My Debian login is “sven”, while my usual IRC nick (oh well, since I’m actually rarely on IRC, speaking of “usual” is perhaps wrong) is “incase”, since the “sven” nick was already taken on both freenode and oftc. Any idea how to work around that?

Sven Mueller: Canonical and Debian - friend or foe?

Pointed at the issues by Josselin Mouette’s post, I got aware of a list of issues posted by JP Rosevear, which is a reply to Mark Shuttleworths post to the opensuse mailinglist. Note especially point 2, which is: “Preventing the Debian GNOME maintainer from updating GNOME packages until after Ubuntu LSO had shipped because you had hired him.” If this issue is true, it’s the worst thing I ever heard of regarding Canonical. I mean it’s bad enough that points 1 (“Having a stated policy of not funding any significant new software development because the Return on Investment is not good enough”) and 3 (“Not releasing any source code for launchpad/rosetta/malone to maintain a competitive advantage”) certainly are true (even though I can’t prove and therefor don’t 100% believe the second part of #3). But unless there is a very good reason to delay the submission of the patches developed to “upstream”, Debian.
It’s bad enough that Canonical hired the most active Debian Developers, depriving Debian of much of their time, while not really supporting Debian (i.e. while not actively submitting patches to Debian). It would have been better for the community if Canonical had hired less active DDs (or even non-DDs). Sure it would have been harder to select some sufficiently qualified people for the jobs, but the total outcome whould have been better IMHO (getting time from previously uninvolved people, while keeping the existing contributors). Anyway, I really would like to know wether the mentioned point #2 is true, and if so wether any valid reason for doing so could be given before I set my opinion about this issue in stone. One thing is sure however, I’m becoming more and more critical regarding Ubuntu and Canonical over time while I once hoped that the opposite would become true for those criticizing Canonical at that time. Actually I still hope so (and thus I hope reason to become less sceptical again).
Another thing is also sure: If Canonical wants to use Debian as a base for much longer, it should make damned sure to work with Debian more actively instead of seemingly working against it (more or less openly). Update: As also pointed out in a comment below, a post by Scott James Remnant proves point 1 from the the aforementioned list and gives a further hint that point 3 might be true. More precisely it says “we have a policy of not doing our own software development, but only packaging what others have developed”, which probably means “not doing our own major software development”, since - as a comment to that post also says - Canonical did some software development, like launchpad/rosetta/malone and some other relatively small projects.

27 November 2006

Jon Dowland: Thecus

Yesterday I installed debian on my thecus n2100. Thanks to Martin Michlmayr for putting up with my neurotic questions during this process. Normally, this would take about 2 hours. Unfortunately I hit a bug in the r8169 network driver (or the hardware) which made the process excruciatingly slow: over 8 hours. I did delay the process somewhat by going for a stable installation first time through. You need to go for etch, for anyone following along at home. I have two hard discs in this box and I wanted to use RAID-1 for the root filesystem. Actually, the two discs were already in a linux RAID-1 set, with superblocks, an ext3 filesystem and some files, from when I was using the default thecus firmware. The following approach lets you setup RAID in the installer and preserve any existing data. You will need to have at least one connection to the installer running a shell, in addition to the one running the installer. When you enter the disc partitioner stage, you will need to fetch the udeb which gives you the md module. For the current thecus installer image, that's md-modules-2.6.18-3-iop32x-di_1.5_arm.udeb. wget it from a mirror (path pool/main/l/linux-kernel-di-arm-2.6) and udpkg -i it. Then restart the partitioner. To preserve the contents of the RAID-1, you might be able to select "don't wipe this partition", and just make sure nothing on it would clash with the directories that Debian will create. I didn't take this approach. Instead, you can drop one of the discs from the mirror, continue with the installation as normal, copy the data back across after, and re-add the disc to the mirror set. Before you select your filesystems in the partitioner: Now feel free to let the installer stick a new filesystem on the RAID set, and install the base system etc. Once the thing has booted: Periodically check on the rebuild status with mdadm -D /dev/md0. One other thing I would strongly advise is getting the installer's debconf priority to medium or lower before you get the base system installed, so you can skip the bootloader / flashing stage. Update: I've clarified the following paragraphs. At present, the default etch kernel is 2.6.17. The network device in the Thecus is not supported by this kernel, so you have to manually install a particular 2.6.18 kernel prior to rebooting, or you will not be able to communicate with the machine once it boots. Martin makes this very clear in his instructions. However, if you have no experience using a d-i which flashes the kernel (as appose to say, the bootloader prompts you get when doing an x86 install, for example) you may not be aware that by default, the flash stage proceeds without prompts. That means that if you do not prevent it from doing so, there will be a window between the installer flashing 2.6.17, and you manually installing 2.6.18, where the thecus will be in an unbootable state, should you suffer a power cut or similar problem. In my case, I left the base system being unpacked overnight (due to the fact the network was so slow). So, that window was several hours wide. This is only a temporary situation, as the release team plan to have 2.6.18 available for Etch, and the patches for the Thecus hardware are steadily working their way into the mainline kernel.

26 November 2006

Tollef Fog Heen: Live CD on disk

Enrico writes about putting a live CD on a removable disk. I added the support in casper for doing this almost a year ago and it has saved me lots of debugging time. Booting the live CD that way is almost as fast as booting an installed system. If you couple this with using the persistent storage support in casper, you can get the configure-on-boot support together with persistency. In a later update, slh is quited saying that xresprobe doesn't work on AMD64. This is wrong, I wrote that support based on code by Matthew Garret a little more than nine months ago. I wouldn't recommend incorporating it in new-written code, but rather use libx86.

25 November 2006

Sven Mueller: live-cd-on-removable-disk

Enrico said in live-cd-on-removable-disk: Mostly it boils down to running the xorg-creation script at every boot time. There are various tools to do that. Some are here, but there is surely more. (Enrico’s note: do we have anything in Debian that we can install and just does that?)
Well, Enrico, a tool I really grew fond of, which auto-configures X on Debian systems is xdebconfigurator, it lacks being auto-run on each system start, which I consider a feature on normal systems, but for your proposed usage (i.e. a portable USB-storage based Debian system), it would certainly be the right thing. Essentially, it never failed on me. Except for VMware virtual machines, where all it did wrong was that it proposed too high resolutions which resulted from my dual-screen Windows setup I ran VMware on. You might want to give it a try.

Biella Coleman: Play Money by Julian Dibbel

A few months ago I finished Play Money by Julian Dibbel and like his My Tiny Life before it, the writing style is simple yet sumptuous, or I guess just simply sumptuous. Like the travel writings that pre-figured anthropological writing, Dibbel takes us to a far-away exotic land (but only a click or two away) that are populated by a motley crew of wizard (or is lizard)? slayers, gold-diggers, money-makers, and virtual-world-builders. For many, these MMOGsare no strange-lands but are becoming weaved firmly and intimately into the fabric of everyday life, whether as entertainment, sociality, and or for a cadre of folks, as a source of income generation. I think the book has gotten enough coverage that I don’t need to rehearse its content in any detail but the basic story is that Julian embarks on a real world quest in the virtual land of quests to try to make enough money (to be specific make a little more than his monthly salary as a freelance writer) from trading and selling a slew of virtual objects and gold. In taking us along, he gives a compelling entry into the imaginative and morally complex world of these games. And better is that whether you know nothing about them or are a seasoned player, the book has much to offer. One of the reasons I respect Julian Dibbel is because he takes his sweeeet time to churn out a book-length manuscript. In a day and age when there is so much pressure to release quick and often, especially when writing about anything in the so-called virtual plane of existence, he waited nearly 8 years from the publication of his last book on gaming, My Tiny Life before publishing on a considerably higher-tech phenomenon. Following him on his most recent adventure, you learn that he threw himself into a variety of gaming environments persistently and consistently and did at least 3 years of research and writing (at one point in the book he confesses how excruciating writing for him, which is hard to believe as the words slip so nicely off the paper but whatever the extent of his writing angst is, he clearly spends a lot of care in crafting his sentences). And I am starting to think that if more people followed this ethic of long-term immersion, coupled with slow-brewed productive sparsity, we would get higher quality products (Yes, kinda like the Debian release cyclce). Like any good ethnographer, he gives an intimate portrait of life in these worlds of copious play where various types of real world economies have mushroomed apace with new technological developments. That is, he gives us a taste of what it is like, as he cleverly puts it to own unreality. Couched within tales of gaming gone real world economic, are hearty reflections on the place of play in social and economic life, the close resemblance and conceptual affinity between computers and games (and not just computer games, and here he does a fantastic job at explaining the Turing Test), self-doubts about writing in general and in particular about this topic, commodity fetishism, and the changing nature of capitalism in a world of ever-greater abstractions. All of this makes for an enjoyable read that if used in the classroom (which like A Tiny Life, I am sure will become standard for courses on Virtual Worlds) allows you to bring in some good supplemental material whether Edward Castranova’s Synthetic Worlds, Greg Lastowka and Dan Hunter’s The Laws of Virtual Worlds and or older heavy-hitters like Max Weber and Karl Marx. The only topic I think I would have liked to seen included is that of capitalist finance, because there are, I think, some real affinities, phenomenologically and conceptually, between finance capitalism and gaming the virtual game. Otherwise some of my favorite sections were on hackers and the object of the computer, but of course, I am biased that way. So here I leave you with a tasty morsel of something that was sumptuous to ingest: It is this endlessly repeatable collusion of freedom and determinism-the warp and woof of fixed rules and free play, of running code and variable input that sets both games and computers apart, together from the larger universe of information technologies they inhabit…. But only games share the universal machine’s game’s thoroughgoing commitment to the principle of recursion: the chained repetition of simple operations, each building on both the input of the moment and the outcomes of preceding steps. And only games, therefore, come close to capturing that precise mi of unpredictability and inevitability that makes the computer such a powerful simulator of our lived experience of the world. p. 104

24 November 2006

Benjamin Mako Hill: Support Parallel Distribution Now!

My friend James Grimmelmann, currently a Resident Fellow of the Information Society Project at Yale Law School and an Adjunct Professor at New York Law School, contacted me recently because he was concerned that it doesn't seem likely that parallel distribution language is going to make it in latest draft of the Creative Commons 3.0 licenses. The issues and arguments around parallel distribution are complex but James and I both think that the status quo represents a mistake and a lost opportunity by CC. As a result, we have written a position statement that tries to explain the issues simply, make a case for parallel distribution, and answer some of the criticism that has been leveled against the idea. Prompted by conversations with hackers from Debian (myself included), CC lawyers recommend new "parallel distribution" language at the beginning of the CC 3.0 license revision process as a way to fix unanticipated effects of the current CC anti-DRM clause. Immediate negative reactions by a number of people demoted the language to an issue for debate. While the resulting debate has been both lengthy and heated, it has not involved more than a small handful of voices or led to any firm decisions. Time is running out for the drafts of CC's 3.0 licenses and unless something changes, the status quo -- no parallel distribution -- will remain. As a result, it's extremely important that users of CC licenses try to familiarize themselves with the issue and to make their voice heard. James and I feel the lack of a parallel distribution language in the CC licenses represents a failure by CC to live up to its own ideals and to do what is in the best interest of the users of CC licenses. Please read our position statement, pass the link and article around to others, and make yourself heard either on the cc-licenses list by emailing cc-licenses@lists.ibiblio.org or by posting a response on the comments page in my wiki. Finally, as a Debian developer, it's important for me to say that I do not think that the lack of parallel distribution makes the CC licenses non-free under the DFSG -- especially in light of the recent general resolution on the GFDL which deemed the GFDL, which contains language that is extremely similar to the current CC text, DFSG free. CC should use parallel distribution language because it is the right thing to do for the free culture movement and for the users of CC works and not because it will have any effect on the inclusion of CC BY and BY-SA works in Debian. You can find the position statement at: http://wiki.mako.cc/ParallelDistribution

Enrico Zini: web-editor-improvements

Improvements to the Debtags web editor The Debtags web editor can now give random tips. It's a simple addition, but it now makes many things possible: If you do a lot of tagging work and happen to conceive some useful tip, please send it to the mailing list and I'll add it to the tips page. I also tried to tidy up the interface of the web editor as much as I could, but I have mixed feelings about it. Help us out: make a draft HTML-only prototype of how the interface could be improved, and send it to me or the list.

Lars Wirzenius: Random thought: Bzr book outline

While cleaning up my hard disk, I found the beginning of an outline for a book on Bazaar (bzr), the version control system. I wrote it one weekend this summer, when I felt I had lots of free time. I don't, and won't, for the foreseeable future. Therefore I'll dump the outline here in my web log, so that perhaps someone will be inspired to write it for me. The Bazaar distributed version control system For most of the 1990s, the free software world relied on CVS for version control. It was the best free system for the purpose. During the early 2000s, a number of new systems started getting into public knowledge. One such system is Bazaar. This is the outline for a book to explain how Bazaar is used in different kinds of scenarios. The book is not a reference manual: the software's own documentation is best suitable for that; this avoids having to constantly update the book. The book is structured as a series of case studies of common scenarios, starting with the simplest one, and getting increasingly more complicated. This approach allows the reader to quickly learn the things they need for a particular kind of situation. Introduction This chapter explains what version control systems are, and gives a summary of their history so far. It explains various basic concepts, such as centralized versus distributed, but briefly; these will be expounded on later in the book. It compares Bazaar to other well-known systems. It explains the cumbersome naming history of Bazaar. It explains how to install Bazaar by referring to the website and to the package repositories of various Linux distributions. Quick overview This chapter is intended for those with some experience with other version control systems, such as Subversion. It gives a quick run-through of the central concepts of Bazaar, and how to do common tasks on the command line. The web page project This is the first case study chapter. It explains how to use Bazaar to keep track of changes to a web site. A web site only changes linearly: only one version exists at a time. My little program This chapter explains how to use Bazaar to maintain the source code for a one-person programming project. The program has a stable version, which gets bug fixes, but no new features. There is also a development version, which gets the new features. Sometimes a bug needs to be fixed in both, and Bazaar can help with this. Additionally, sometimes it is not clear whether a new feature can be implemented cleanly, or there are several possible approach to how it can be implemented. Thus, the chapter also explains these so called feature branches. Further topics for this chapter include making releases, and using repositories to avoid excessive disk usage. Tight teamwork This chapter explains how to use Bazaar when the one-person program becomes an internal project in a company, with a well-defined set of developers. Thus, we discuss how to set up a centralized branch in a way that all the developers can commit to it. Distributed free software development This chapter concentrates on a typical successful free software project, with contributors from all over the world, and the problems that this involves. Thus, we discuss how to publish a branch for anyone to see (but not change); how to share changes (patches/bundles) between developers; how to co-ordinate the development of the whole project (at least from the version control point of view). Switching a project to Bazaar That's it. If you write it, please send me a note when it's published so that I can get a copy. Thanks.

Michael Janssen: She keeps a picture of me

This is a picture of me before I started this whole diet watching and exercising regimen. Hopefully I will be able to take regular pictures that can document my progress. This is one thing which I don't plan on doing very regularly, maybe every two or three months. Pictures have been known to be a great motivator to people on diets - they remind people how they used to look, and more importantly point out how far they have gone so far. Usually the most dramatic change is seen in the picture, even if you don't see much movement on the scale. The picture is so powerful that it is usually used alongside actual insane weight loss claims in TV commercials. Anyway, this is how I looked when I started this whole thing.

As this week's entry falls on turkey day, it may be interesting to note something which has been at the back of my mind during these “special” days in which you are urged by almost every sane diet plan to just forget the plan on that day. Many websites say that cheating on your diet may actually be good for you in the long run. While some emphasize the psychological aspects of having a day off, others actually cite scientific reasoning involving a hormone called Leptin. At any rate, the line between cheating and giving your diet a little boost is getting quite a bit blurred. So on this turkey day and days after, don't feel like you have to work out extra hard just because you're eating more.

This week I started using a new diet tracking site. This one is more closely in line with the method I used before. It's Physics Diet, and is basically an online notebook like you would keep if you were on the hacker's diet. This also calculates some more stuff that would be a little complicated to keep track of yourself, like Total Energy Expended (calories). It also has a nice CSV export which still allows me to give all of you your weekly stats. I've continued with the watching of anime while I am exercising, but am supplementing it with some podcasts and some episodes of a BBC show called QI or Quite Interesting. There is a downside to watching QI while exercising: I am laughing so hard sometimes I need to re-concentrate on the exercise so that I don't fall over. I'm sure it's not a bad thing for my calories expended in total.

This Week (Nov 17 - Nov 23):
Minimum: 335.0 (-0.5) (Nov 22)
Maximum: 339.0 (-0.5) (Nov 17)
Average: 336.8 (-0.4) (136.8 to goal)
Exercise Calories: 2719 on 6 days
Average Calories per session: 453.1

23 November 2006

Edd Dumbill: Really really getting the testing religion

Writing tests is virtuous. It's the wholemeal bread of programming. Do it, and you'll be so much fitter. Except it tastes like cardboard and gets in the way of consuming the yummy treacle sponge of programming. But now I've got the testing religion. I view the lack of tests with the disapprobation of a reformed smoker tutting and huffing at the merest suggestion of a Marlboro Light. How did this happen and how can I be sure I won't backslide? The moment of transition was the first time that a test saved me from releasing software with a bad bug in it. The theoretical knowledge of virtue was translated into the palpitating relief of not disgracing myself in public. After that happened a few more times, I found myself desperately uncomfortable with the idea of releasing anything that didn't have decent test coverage. And so a virtuous habit is formed. It's not just driven by fear. With the right tools to hand, writing tests can be a lot of fun. You don't always need to be "in the zone". If you've got a spare half hour here and there, you can use it to increase the coverage of your tests. Getting better at testing is one of the ways I've become a much more proficient Rails developer over the last year of work on Expectnation. In case it helps anybody else, I thought I'd share some of the tools and techniques that are part of making Rails testing fun and effective. Continuous testing Whenever a checkin is made to our source repository, tests are run and the results emailed to everybody working on the project. As with the "you broke the build" disincentive, you need to be kept honest by frequent running of the tests. There are a variety of tools around to help you do continuous integration with Rails, most of which have some dependence on you using Subversion for source control. In the event, I just created my own script to do what we required. Coverage reports rcov coverage barsOne of the big mental hurdles with testing is knowing how many tests you should aim for.  You can't prove a negative: even if your tests are all passing it still doesn't tell you much about the tests you haven't written that might fail! We use rcov as part of the continuous integration process, and post the results to our project web site. The pretty red and green bars give you some idea of when you're starting to get adequate test coverage, and the line-by-line breakdown is invaluable. Tainting strings One of the easiest errors to make in Rails templates is to miss the call to h(), to escape any HTML in an output string. The only real way to catch these errors is through automation. The wonderful safe_erb plugin helps you do just that. By using Ruby's tainting mechanism for strings, it throws an exception if you render any external data unescaped. One of the beneficial side effects of safe_erb is that you then become very particular about ensuring your functional tests properly cover every action in your application.  Tests such as get 'index', which before seemed mundane and redundant, are now essential, as you want to test for tainted strings. In addition to the above techniques, there are a lot of fun shiny gadgets to help you write tests, such as ZenTest, but the three things above are the ones I've found to be of significant value. I ought to conclude with words of praise for Rails. It goes out of its way to make testing an important part of the development lifecycle, and the availability of the of unit, functional and integration test functionality makes it easy to get started. Every time I teach somebody about Rails' testing features, they end up finding it very enjoyable.
Don't forget, testing can be fun!

John Goerzen: hpodder to be multithreaded... done right.

I'll be hacking on my hpodder program this weekend. hpodder is a full-featured podcast aggregator that runs on the command line, and has many features over other command-line podcatchers like bashpodder, and even over GUI tools like iPodder.

I originally envisioned hpodder to be something that I'd cron up and run in the background. But I have tended to run it in the foreground more than in the background. Some others have too, and the #1 requested hpodder feature is parallel downloads.

So I am working on that. I already have code working, in fact, that will parallelize both the hpodder update (downloading the feeds) and the hpodder download (downloading the actual episodes) commands.

Unlike ipodder, my code will make sure that no more than 1 thread will ever be downloading from a given server at a given time. ipodder had the terribly annoying habit of pointing all of its threads at a single server, thus pounding it while also providing little benefit for someone with a pipe fatter than the server's.

Before all this multithreaded stuff could be written, I needed to write my own status bar code instead of just letting curl display its own status bar. (That wouldn't work when there are 5 curls running at once)

I decided that I would write some generic status bar code, rather than something specific to hpodder. I took the apt-get status bar as an example, and whipped one up in Haskell and added it to my MissingH Haskell library.

But a status bar just begged for another feature: a generalized progress tracker. Something that could keep track of where a task (and its sub-tasks) are, calculate ETA, estimated time remaining, speed, etc. So I wrote that and made the status bar use it.

AND, a status bar begged for a generalized numeric formatter: something that could render 512 as 512, 2048 as 2K, 1048576 as 1M, etc. So I wrote that, and it's general enough that it can render into both SI and "binary" units by default (and others that users may want).

Finally, I wrote a function to take a number of seconds and render it in something friendly like 23m5s like apt uses, and shoved that in MissingH as well.

So now hpodder will have a status bar, and any other Haskell program can use the same status bar code in minutes because it's all generic. Or if someone just needs to render a number in megabytes, they can do that.

I really enjoy it when a program needs a solution that is generic enough to put in a larger library. I try to put as much of my Haskell code in MissingH as I can, so as to make it useful to others (and my other programs).

Biella Coleman: Hay Papito, que cold it is!

So it is hard to believe that in less than a month I will be somewhere, to be exact, Puerto Rico, that will be 80 degrees warmer than it is right now. And after weekend, it will be 100-105 degrees warmer. Yep, the cold (frikken) snap has arrived to Edmonton and it is preety intimidating. So long as there is no wind, it is tolerable but so long as there is some wind, it is unbearable. And I will park myself at home if that is the case. We were going to make a big trip to the mountains this weekend but with that type of weather, that may have been the end of me. And being that I think I am the only person in Edmonton from Puerto Rico…. that would be a shame. And speaking of the RICO… WikiTravel has chosen La Isla del Encanto as the spot for the Wiki Travel Get-Together. HAY Mamita y Papito, que HOT, as one would say… Evan Prodromou a.ka. MrBad, also a Debian developer, kick started the travelpedia and is going to be lucky enough to go. I am not sure if I can make it but I hearby promise to provide a detailed “map” of where the travelpedias should venture as I know the really good goods.. And they range from the Nuyorican cafe in El Viejo San Juan to hitting a couple of beaches on the amazing island of Culebra, going to Pinones Sunday night to listen to Rumba and anyway the list goes ON AND ON… I will be inspired while baking in 86 degrees (as opposed to freezing in-20 of Edmonton) and will provide le map.

22 November 2006

Benjamin Mako Hill: Poor Santa

I think it wold be a good idea if companies did not typeset their bicycles in ways that remind people of falling.
/copyrighteous/images/santa_fell.jpg
With that said, the red and white theme is a particularly nice touch in this case.

Evan Prodromou: 1 Frimaire CCXV

I was sorry to see the announcement by Danny O'Brien of among other things Need To Know that he's been doing poorly. Danny's a stand-up guy of the old school, and although we've never been hugging friends I consider him a pal of some sort. So it's bad to hear that he's Down and Out. I hope that he gets back Up and In, and returns to his m tier of stickin' it to the Man. tags:

Aubanerie Amita June and I took a walk up to the Aubanerie on Mont-Royal to get some winter accessories. Winter in a snowy country means that you have to have a large stock of the little bits of knitted cloth that keep the ambient air from freezing the skin off of your bones: hats, gloves, scarves, woolly socks, ear muffs, long underwear. Our first winter in Montreal, I had like 1 hat, 1 pair of gloves, 1 scarf, etc. I spent maybe 30 minutes a day wandering around the house looking for one or the other of them before going outside. Given that when it's -20C outside, you just can't leave the house without any of these accessories, it was kind of a big waste of time. So now we have a common pool of wintery clothes for the household. 5-6 toques, a few scarves, a vaguely sinister basket of gloves that look like severed hands, a ton of socks, etc. Sometimes I leave the house with two toques -- one in my pocket and one on my head -- Just In Case. The Aubanerie up the street is pretty great for buying cheap-o accessories. They have some stuff at Dollarama and other $1 stores, but they tend to be either really thin, really small, or sold in separate chunks so each item costs only a dollar. The Aub has OK stuff that doesn't look too ridiculous. Amita June is getting to be quite a walker -- we didn't bring the stroller for this trip. She just toddled up the street, and although we stopped and looked at a lot of sticks and pebbles and porches, we made pretty decent time for a 15-month-old and her papa. On the way home I wore a new toque and Amita June had a new pair of mittens linked with string, as if one were the astral projection of the other. Now she's asleep -- shopping is hard work -- and papa gets to work a little more on trying to make Wikiwyg work. tags:

Mon Qu bec While searching for info on the Aubanerie on Google, I stumbled across Wiki Mon Qu bec, a Russian-language wiki about Montreal and Quebec. Fantastic. tags:

Rodrigo Gallardo: Winter

Gunnar, how can you take with such calm this horrible cold weather? I mean, 10°! In november! Yesterday’s forecasted minimum was – 1°, and it even snowed on the Ajusco. We’re supposed to be a nice tropical country. OTOH, I do commiserate with you on the christmas music.

Adam Rosi-Kessel: Netflix Should Have Standing Orders

One feature I’d like to see at Netflix: a “standing order” for films that match particular criteria. For example, I would be happy to have Netflix automatically add any Pedro Almodóvar film to my queue as soon as it enters the Netflix universe (Volver looks interesting). I also wouldn’t mind any film rated four stars by Roger Ebert to be dropped into the queue. You could even ask Netflix to add anything that its collaborative filters give a top rating based on your past preferences. Then you would just sit back and be surprised at what arrives for you. Rather than “opt-in,” the system would become “opt-out” — similar to those discount CD clubs that were popular in the 1980’s, where you had to tell them if you didn’t want the pick of the month. (I built the bulk of my CD collection in that era by taking advantage of the occasional “3 for the price 1” deals.) The difference here is that you are actually likely to want the pick of the month. A related feature would be “add all” matching a certain criteria with a single action — for example, all Hitchcock films. This is pretty much how I select films anyway. Knowing that a film is directed by Robert Bresson or Akira Kurosawa (two of my favorite directors) tells me a lot more than a plot synopsis. I’d actually rather know nothing about the film itself in advance.

Uwe Hermann: Tagesschau Video Podcast Archive?

Does anybody know about any archive of the Tagesschau Video Podcast (German TV news)? I'm collecting the videos, and I missed the shows from November 8th and November 13th, and they only provide 7 days of "backlog", after a week they seem to remove the videos (which sucks!)... Thanks in advance!

21 November 2006

Benjamin Seidenberg: How to set up an encrypted filesystem in several easy steps

Introduction: This guide will walk you through the creation of an encrypted filesystem using LUKS. LUKS is the Linux Unified Key Setup and is a standard format for linux hard disk encryption. It has a lot of interesting features such as using a key on a removable disk, keeping multiple keys, and more. This is the technology used by the Debian Installer (since etch beta3) and is quickly becoming a standard in the linux world. Who this guide is for: This guide is for anyone who wants to secure their data using an encrypted partition. While it is tailored to users of Debian, it should apply elsewhere in the linux world. This guide is intended to add an encrypted device to an existing install, if you are contemplating a fresh install, the Debian Installer will configure encrypted filesystems for you. Ready? Then let’s begin Prepare the partition (or other block device) to be used This can be a partition on disk, a logical volume in LVM or some other block device. For this example, I created a 40 GB volume in LVM. Install cryptsetup This utility provides an interface into the code in the linux kernel that handles encrypted block devices. It’s packaged for Debian in both testing and unstable, stable has an older version and I don’t know whether or not it will work in the same manner.
apt-get install cryptsetup Set up encryption on the partition: This initializes the partition for encryption and sets the initial key. People not using LVM will want a path like /dev/hdxY where hdxY is the partition on their hard drive that will be used for encryption. Important! This command will wipe out anything on that partition
cryptsetup luksFormat /dev/mapper/asimov--vol-crypto_test
WARNING!
========
This will overwrite data on /dev/mapper/asimov–vol-crypto_test irrevocably. Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.
Congratulation! You now have an encrypted block device! However, it’s not quite ready to use. Open and map the device: This opens the device (prompting for a passphrase) and maps it to a block device in /dev/mapper. This can be used like any other block device, and the encryption/decryption is transparent. The first path (/dev/mapper/asimov–vol-crypto_test) is the encrypted partition you set up earlier. The name (crypto_test) is the name of the volume, the block device will be mapped as /dev/mapper/<name>.
cryptsetup luksOpen /dev/mapper/asimov--vol-crypto_test crypto_test
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
Create the filesystem of your choice on the device: This is just like setting up any other block device. I use ext3, others may prefer different formats.
mkfs.ext3 /dev/mapper/crypto-test Add the definition to /etc/crypttab: /etc/crypttab is a list of encrypted devices that are mapped on boot. The format is <map name> <path to device> <key file> <options> Since we’re using a passphrase, we don’t have a key file.
crypto_test /dev/mapper/asimov--vol-crypto_test none luks Create a mount point: This is where the encrypted device will be mounted on your filesystem.
mkdir /mnt/crypto_test Add the device to /etc/fstab: /etc/fstab tells the computer where to mount different devices on the filesystem. The format is
<source path> <mount path> <type of filesystem> <options> <mount options options> <dump frequency> <fsck pass> More information can be found by reading man 5 fstab. You will want to add a line like this: /dev/mapper/crypto_test /mnt/crypto_test ext3 defaults 0 2 somewhere in this file. Update the initial ramdisk. The initial ramdisk is used to jumpstart the boot process and load modules for the kernel that it can’t load itself (such as drivers for block devices that contain the modules it uses). I’m not sure if this is needed or not, but I wanted to be on the safe side.
update-initramfs -u -k all Congratulations Now your encrypted filesystem is completely set up! Reboot the system and you will see it prompt you for your passphrase during the boot cycle. Once the password has entered, the encryption is completely transparent. If you want to use your encrypted filesystem before rebooting, simply type mount /path/to/mountpoint.

Steve Langasek: midterm report

This is the first of my two formal reports to the Dunc-Tank board on the release management funding experiment. Although submitted to the board some time earlier, I've delayed publishing it to the wider community until a release update could be sent out with more concrete information on timeline adjustments as Debian developers are wont to demand.
I'm supposing that I don't need to give you any more specific details on what I've been working on than what's already been posted in my blog. There has certainly been plenty to keep me busy the past three weeks, including a lot of triage work on the state of bug reports in the BTS, managing the last of the major package transitions into testing for etch, removing packages and NMUing them, and it has indeed kept me busy. Busy enough that I've been lax when it comes to talking about it, either here or in my blog. :) Has the hard work paid off? Well, http://bugs.debian.org/release-critical/ shows a sharp decline in release critical bugs affecting testing over the same time period, following the peak resulting from Dunc Bank's successful campaign of identifying latent release-critical bugs in etch. Unfortunately, we have no statistics that track the number of RC bugs closed or opened over time, which makes it hard to judge how large of a dent my own work has made in the overall bug count. It's also totally guesswork to try to judge whether Dunc-Tank has encouraged others to help with the release overall, or discouraged them from doing so. What I can say is that, even though the past month coincides both with the tail-end of the Dunc Bank mass bug filings and multiple archive-wide rebuild efforts, the bug count is moving in the right direction, and I am seeing many maintainers being responsive to bugs in their packages and a number of active NMUers. If not for the buzz-kill of Lucas Nussbaum's latest round of build failure reports :), we would be down from over 300 RC bugs to less than 200 right now, which probably represents at least twice that many RC bugs closed. In terms of how the time I'm putting into this release compares with the sarge release, I'd say it's pretty comparable. That's actually quite a positive statement about Dunc Tank's role, IMHO; getting a Debian release out is uphill all the way, and whereas the sarge release came at a time when I was in a position to work more or less full time on it without compensation, my availability this time around would have been greatly reduced, and progress would have been much more heavily dependent on individual maintainers and semi-periodic bugsquashing parties, which I'm not sure is any longer enough to offset the rate at which new RC bugs are created in the distribution by uploaders. As it stands, I do find myself trying to consciously avoid a hero complex of needing to fix every bug personally, but there are after all only so many options for getting bugs fixed for release. A lot of maintainers respond positively to gentle nudging about their RC bugs, but there are still bugs that the maintainers can't or don't fix and that no NMUers take on, which does leave it more or less up to the release managers to address -- which is why one of my tasks for this week is to try get the count of RC bugs over 20 days old down from 90 to around 20-30, as these are the bugs that really do need more attention to get them resolved. So yes, Dunc-Tank is making a positive difference. Andi and I have reviewed the status, and while we don't think we'll be able to hit the Dec 4 deadline (even if we get the bug count down immediately we're waiting on the debian-installer to release, which needs at least one more release candidate with the 2.6.18 kernel), we do believe that a release before the end of the year is very possible and I'm looking forward to starting the full freeze in the next few weeks.

Next.

Previous.