After my last experience, you'd think I'd have learned. But nope, when my girlfriend needed a new desktop system, I enthusiastically offered to build one for her. Hey, this time it's desktop hardware, and I know desktop hardware, right? I built my last machine myself, and I've replaced a couple motherboards and done various other work on computers since then.

Well, it seems there were a few changes since my last computer. First of all, there's the whole business of heatsinks. I don't remember spending any time on the heatsink last time around. I suppose this is because it was pre-attached to the chip or because the assembly process was "place the heatsink on top of the CPU", but I don't remember which. For the Athlon 64s, the heatsinks are so ginormous that you couldn't place the CPU into its slot if it was attached to the heatsink. So there's no option but for them to ship the two separately and have the user assemble them.

Problems? Well, consider the documentation. The store sold us a supposedly complete CPU box packaged by AMD which, when I opened it, contained a stern warning not to attach the heatsink without first applying a thermal material. Contradicting this, though, was the fact that there was something that looked suspiciously like thermal material already on the heatsink, and after quite a bit of research I decided that the warning was for people who want to overclock their systems or replace the stock thermal compound. Nowhere in the documentation does it say whether the heatsink comes pre-treated with thermal compound, though, and since I have no desire to let the magic smoke out, I wasted a lot of time checking up on this.

A second problem with the documentation is that it suffers from severe Lowest Common Denominator syndrome: the installation instructions are entirely word-free. For simple purposes this might suffice, but it took me a lot of squinting and several incorrect tries to figure out WTF the diagrams were telling me to do; in fact, I didn't really figure out what to do until I found an annotated version online with actual words. AMD, there's a reason we quit using cave paintings and invented written language. Please use the stuff, it'll make the rest of us much happier.

On to the practical problems: it's apparently necessary to attach the heatsink so tightly that you need a latching mechanism the size of Wyoming to hold it onto the motherboard, and actually activating it seems to take several metric tons of force. OK, I exaggerate, but just this step (attaching the heatsink assembly to the CPU) took me at least an hour of prying at the latch mechanism to lock it down. In fact, I didn't finish until I finally gave up using my fingers and used a screwdriver to apply a good portion of my weight. Predictably, of course, the screwdriver slipped as I secured the latch, bouncing off the motherboard. More on that in a moment.

The motherboard (an Abit K8N) had better documentation than the CPU, but not by much (this is apparently a pattern with computer components that most consumers never mess with). I had to make educated guesses about the orientation of several connectors, especially some of the case connectors, and it took me at least a dozen reads to understand what I was doing wrong with the power cable.

Once I got all my initial stupidity worked out, I flipped the switch and watched some of the fans turn on and the hard drive spin up...and that was it. Nothing. Nada. No beeps. No POST. Not even a blank video signal (although the video card's fan runs just fine).

So, my best guess is that I killed the motherboard dead with my screwdriver, which means I get to go buy a replacement and install it. And, of course, disassemble all the stuff I carefully assembled already. Including the CPU assembly. And the thermal material on that probably won't be good any more, so I'll have to replace it with what's left over from when I rebuilt my laptop. And there's always the possibility that it's actually the CPU that's dead (although I can't imagine why)...in which case I could waste a lot of time and effort replacing the motherboard needlessly. Blah.

I begin to think that it might be worthwhile to pay the store to install the critical components for me, or even just buy from a real PC vendor. At least then I'd avoid wasting my time and (presumably) get my money back if they screwed up.

...moustache stays right where it's at.

Branden, hear, hear. Shave it, kill it, get rid of it. Alternatively, grow a goatee.

While ARM is a very important platform, support for it in Debian has faced a number of problems recently: there was no developer accessible machine for a long time (they're two now), buildds sometimes have a hard time keeping up, etc. Most importantly, there are not enough people actively involved in the ARM port. We need more people doing debian-installer and kernel work, and track other ARM related issues. One reason why few people are working on ARM is probably the lack of a cheap platform that can be used for development. Fortunately, this problem has now been addressed. Over the last few months, I worked (in collaboration of the NSLU2-Linux project) on debian-installer support for the Linksys NSLU2, a sub $100 device with 32 MB RAM, Ethernet (which unfortunately needs a non-free driver) and two USB ports. You can attach a USB disk and run a full Debian system on this device. While there have been some instructions on the web about how to get Debian going on the NSLU2, basic support for the device is now included in debian-installer. In other words, you can do a user-friendly installation and it will just work. Here are instructions. Future work In the future, the NSLU2-Linux people and I will add more support for other ARM based consumer devices, such as Network Attached Storage (NAS) devices (basically a hard drive with a CPU/RAM and Ethernet, sometimes also including wireless; in other words, a perfect platform for Debian). On a related note, I'm also working on getting debian-installer going on a number of MIPS based consumer devices, such as the Netgear WGT634U wireless router. However, this work has not reached the maturity of NSLU2 support yet. There is a status overview and TODO list. Acknowledgements

• The NSLU2-Linux team for doing most of the upstream work (e.g. kernel), and for donating a NSLU2 to me.
• The debian-installer team for creating such an excellent system to which new platforms can be added relatively easily.

The Latin American Free Software Install Party (FLISOL) will take place in 12 countries of the continent, including Cuba, and featuring Argentina and Colombia. In Venezuela, it’s happening in ten cities in several regions of the Country, including Los Andes, Los Llanos, the Central Region and the Paraguan Peninsula. I’m organizing the event in Caracas, which already has a webpage (in spanish) FLISOL will take place on March 25th, a Saturday, but in several cities of Venezuela we will have a two-day event. In Caracas, it will happen on Friday and Saturday. We will feature hands-on workshops and demonstrations (featuring a Debian GNU/Linux hands-on workshop), a Keysigning Party (it won’t be massive, though) and a Web Frameworks and Application Servers Forum, featuring Rails, Catalyst, J2EE, and Zope. I expected David to be in Caracas for the FLISOL, but he’s gonna travel to San Crist bal to participate in their FLISOL. I don’t expect a big attendance to the event (the Auditorium of the Science and Technology Ministry, the main sponsor, has capacity for circa 200 people) but I hope it becomes a fresh event, different from those we’re used to. This will be, also, a good preparation for the World Forum on Free Knowledge, the National Free Software Congress and the DebConf. I hope the main topic on the FLISOL will be the recent, terrible, awful, and completely disgusting Ubuntu security flaw.

It's been a little while since I wrote about Asterisk. It's about time to update the story. I've been using Asterisk at home for awhile, but now we're going to use it at work. The need We have approximately 150 internal extensions here, and they are being supported by a Nortel PBX. This PBX is being end-of-lifed, and it would cost well over $100,000 to replace it, once the cost of the two required Windows servers (!) was factored in. Not only that, but it still isn't as flexible as Asterisk. Along with that, we have a need for internal wireless phones. We have a large manufacturing area, and we have people that would like to be able to use a wireless phone anywhere on the shop floor or office areas. No single cellphone company provides a signal that is strong enough to reach everywhere in the building -- not to mention that there would be big airtime fees. So we are planning to deploy 802.11b wireless phones for this purpose. Hardware The decision was made to go ahead with Asterisk. We will be replacing all office phones with Polycom IP501 units. This means running about 90 new runs of CAT5 to people's desks. For our Asterisk server, we got a HP DL385 2U server with dual dual-core Opteron 2GHz CPUs. We've really had good luck with Linux on these DL385s, and with HP's support. We got redundant power supplies, disks, fans, etc. on that machine. The CPU on here is probably more than we need, but telephones are very important to us and we wanted to make sure that we don't have any issues down the road. We purchased two A104d quad-T1 interface cards with hardware echo cancellation. Very nice cards. The drivers have been a little troublesome. But Sangoma's tech support is awesome. They logged onto our box and I was watching as they were hacking on the kernel module right there. Tech support like that is rare. I highly recommend Sangoma. We really need only one of those cards, but they're the only component of the Asterisk server that isn't completely standard. So the second is on hand as a spare. For our analog phones, we are using two Adtran TA 750 channel banks. Each has a T1 interface and a 50-pin telco ("Amphenol") connector for a punch block. So we can run 24 channels off each of those. Our consultants (see below) suggested getting them used from Colspar Communications. We found them fully loaded with FXS cards for $250 each. We bought three -- two for production use and one for a hot spare. These are very solid and nice units. The only problem we had is that the voicemail indicator lamps (MWI lights) on our old analog phones wouldn't light up. Turns out that Asterisk with a T1 channel bank uses digital FSK lamp, whereas our older analog phones expected a certain line voltage to indicate messages waiting. After some Googling, I found add-on FSK lamps from American Science & Surplus for $1.50 each. Nice. In our other building, we have a gigabit fiber-optic link, so we purchased an AudioCodes MP124 SIP-analog gateway. It's working well so far, except it's not working with voicemail indicator lamps at all. It seems to be a firmware issue that is incompatible with Asterisk in some way. We're investigating now. For wireless phones, we're using the Hitachi IP5000. We're not terribly pleased with the quality of wifi phones in general, but this one seems pretty solid. And it doesn't crash every few minutes like the Zyxel model we tried. The Telco Our current phone system has about 23 analog lines for interaction with the outside world. We wanted to get a voice T1 with PRI channel for the Asterisk system. Our local telephone company is Sprint, and this has been the annoying part. First they tried to quote us an Internet connection. Then it took a very long time for them to even get us a quote for the voice T1. And now we have signed the contracts but are still waiting for an install date. Consultants While I had used Asterisk before, it was in a home setting. Not exactly business-critical, and not dealing with hundreds of extensions, T1 lines, and all the rest. So it seemed reasonable to get someone experienced with that sort of thing to help us out and make sure we weren't making mistakes that would cost us down the road. I posted on the asterisk-biz mailing list describing what we would like to do. I got a bunch of supplies from consultants, and we wound up selecting Asteria Solutions Group. At the beginning, we wanted some advice about server sizing, phones that work well in business settings, etc. I think that most consultants are not used to working with people that have significant Linux experience, and a good deal of Asterisk experience, already. Asteria was a little surprised with our situation at first, I think, but has been very helpful. They've educated us on the ins and outs of T1 technology, pointed us to Colspar (which saved us a ton of money on analog gateways), and helped us with some obscure questions. They were also fine to have a much smaller involvement with our project than they would probably normally have. I highly recommend them. Surprises You'll never believe just how hard it is to buy phones from Polycom. They won't sell directly to people, nor will they even list authorized retailers on their website. You have to call them, leave a message, and in a few days they'll let you know where to go. Some online retailers such as atacomm sell Polycom phones, but they're not authorized to do so, so you don't get any warranty or have the right to get firmware from Polycom. What's more, Polycom usually expects people to need configuration assistance with their phones. But I think that when I told them we need 90 IP-501s, had already configured 5 on our network, and needed no assistance, they were happy to work with us. Reactions We've deployed desk phones all over by now. So office workers have two phones on their desk right now (one from the old system, one from the new). We've heard a lot of positive comments from people about the new phones. And all the features of Asterisk -- music on hold, flexible queues, etc -- will be really helpful here. Cost Even with the cost of all new phones, new CAT5 runs and labor for that, consulting time, etc., we still expect Asterisk to be far cheaper than the latest Nortel PBX. Also... I recently wrote an article about Asterisk for Free Software Magazine. I'll let you know when/if it gets published.

In about an hour I'll finish work and leave for Cambridge. The plan is to take a train to Berlin-Schönefeld, then fly to London Standsted and take a coach from there to Cambridge, where I'll arrive somewhen between midnight and 1am and hope to find (1) King's College and (2) someone who knows who I am and where my bed is.

I usually don't suffer from travel nerves, though this trip is so far foreshadowed by a chain of unfortunate events:
Firstly I scalded my hand with hot oil last weekend and it is now in the state of getting rid of the old burned skin, exposing the tissue underneath that is not real skin but some thin algesic replacement. Ouch!
Secondly my laptop, beloved dropkick, lost its display this week. Well, not physically, but when I booted it up on Thursday the colors where heavily distorted. I tried to fix it yesterday but at some point it just stopped working alltogether. :( Background lightening still goes on and off but nothing is displayed. I am pretty frustrated by this. Not only because I had planned to use the laptop this weekend but also because I really like it and have grown kind of attached to it. Since a professional repair would probably cost almost as much as the thing is worth and I am pretty broke at the moment I'll try to get a used display and replace it myself. (Relevant hints and advice are welcome!)
Lastly, I haven't packed yet, my belt loop is ripped and the prospect of spending long waiting periods with only a book plus pen and paper as means of distraction is not too thrilling.

Anyway, still looking forward to the weekend! (<phlox>Optimism!</phlox>) I'll let you know how it went (and what further mishaps struck me) when I return. :)

Yet another thing that has been on my TODO list for quite a while: encrypted USB thumb drives and/or encrypted external USB hard drives. I have finally tried this over the weekend using loop-AES. This is very useful for securing your USB thumb drive contents in case you lose it or it gets stolen. Also, I use an external USB hard drive for backups (previously unencrypted). This is encryped now, too. Here's a quick HOWTO:

1. Get the loop-AES kernel patches, apply them, enable "AES encrypted loop device support" in "Device Drivers -> Block Devices -> Loopback device support", and recompile the kernel.
   I also enabled "loop encryption key scrubbing support" as it seems to promise higher security (can anybody confirm that?).
   If you're using the Debian kernel packages, apt-get install loop-aes-2.6-686 (or a similar package) should suffice.
2. Get a loop-aes enabled losetup, mount etc.:
   apt-get install loop-aes-utils
3. Securely delete the target partition: shred -n 1 -v /dev/sda3.
   Use -n 25 or higher if you want more security and have a few days time to wait for the thing to finish...
4. Setup the loopback device: losetup -e aes256 -C 3 -S 'seed' /dev/loop0 /dev/sda3.
   Notes:
   • I used AES-256 as cipher, but others are possible.
   • The -C 3 means "run hashed password through 3000 iterations of AES-256 before using it for loop encryption. This consumes lots of CPU cycles at loop setup/mount time but not thereafter." (see losetup(8)). This is supposed to be more secure.
   • Using -S 'seed' (replace "seed" with a secret string like "g7sN4" or something) should make brute force attacks a bit harder. Don't forget the seed!
   • You'll be asked for a passphrase > 20 characters. Choose a good one. Don't forget it!
5. Create the filesystem (I used ext3): mke2fs -j /dev/loop0
6. Detach the loopback device: losetup -d /dev/loop0
7. Add this to /etc/fstab:
   /dev/sda3 /mnt/crypted_sda3 ext3 noauto,loop=/dev/loop0,encryption=AES256,itercountk=3 0 0
8. Mount the (now encrypted) partition by supplying the seed and entering the chosen password: mount -o pseed=seed /mnt/crypted_sda3
9. Done. You can now copy stuff to /mnt/crypted_sda3 which will be encrypted automatically.

For a more detailed guide read the Encrypted-Root-Filesystem-HOWTO. A performance comparison of different ciphers is available, but in general I didn't notice too much of a slow-down because of the encryption...

I'm such a funster. It's Friday night and I've spent it fighting with consumer routers in an attempt to get my home setup sorted out a bit. And I've made some progress, but it's taken a while. My old setup was an Asus WL-500g with a USB Speedtouch attached. This was running a hacked up version of Oleg's firmware, with kernel 2.4.20 (ewwwww) and the userland Speedtouch pppoa3 driver. It's been up 253 days as I type, which is quite impressive IMO. The plan was to get something else doing the same job so that I could try and get more up to date firmware on the Asus (probably OpenWRT) and give it to my parents as a wireless access point / print server. First try was my Netgear DG834G. Unfortunately the ADSL interface on it doesn't want to sync to the line for any length of time. I don't really want to faff with it at present, so I gave up on that. I do want to try and get this sorted, as it has a native ADSL interface, but the AR7Port appears to have stagnated a bit. Next was the Netgear WGT634U. I'd built an OpenWRT image for this and tried to flash it earlier in the week, but messed it up and bricked the router. So opened it up, hooked a serial console up and managed to restore it easily enough. A little bit of frobbing and I had it recognising the Speedtouch. Result. This has a 2.6.15.1 kernel, which means in kernel driver goodness and nice and up to date. Plus OpenWRT makes it easy to add various nicities like radvd and dnsmasq. I'm currently using this solution and will keep an eye on it over the weekend before reinstalling the Asus. Of course my home network has become simplified a bit by the fact I no longer factor the NTL connection into it. That's always just been a backup thing since getting ADSL from Black Cat (mmmm, IPv6 goodness) and I've decided to finally ditch it soon. However I might want to add a modem to the WGT634U at some point - probably using a USB serial dongle I guess, as I don't think the internal ports do hardware flow control. That's a battle for another day though. I also managed to get rid of a whole load of computer junk that was working but unused, thanks to Norfolk FreeCycle. Kathy will be pleased when she comes back from London tomorrow. :)

Note to self: don't forget to shoot a picture of the Debian twins at Debconf6. Note (bis) to self: buy 300 fake mustaches, distribute them before the group photo, except to Branden. Shoot picture here as well.

It is kind of cute when you wake up, check your IRC backlog, and spurt out coffee all over your keyboard.
[micah] wow, who said branden looks like amaya?
[liw] micah, stockholm?
[micah] he's right
[micah] I thought that when i saw him in boston, with no moustache
[micah] but I didn't want him to hurt me
[dilinger] amaya should get a mustache, so we can tell them apart
/me LOLs

P.S: I have never liked Branden's moustache, so I am not very happy about getting one myself.

I couldn’t resist the temptation, and started to write yet another Scheme logging library; this has been on my TODO-list for quite some time now, but now it became more urgent, since we need a logging facility for conjure. I hope jao will be pleased to see that my branch of conjure already makes use of the new logging module . Of course, I didn’t in fact start from scratch, but had a look at the various logging libraries available; the Scheme ones being:

• The logging package in guile-lib. I couldn’t really use that code, since it’s uses GOOPS, Guile’s CLOS-like object system. Also it doesn’t support hierarchies of loggers, which I consider an important feature, since it allows flexible configuration of the logging behaviour for a software system that is contains of multiple subsystems. For example, you may want to enable debugging output in a specific subsytem, while only getting warnings and errors for everything else.
• log4scm. I don’t know what to say about that but: strange. While named in the log4X tradition initiated by log4j, a rather powerful (and complex, IMHO) logging system for Java, it seems very unflexible, and not suitable for a general-purpose logging system. Nevertheless it uses threads, a callback system for fatal logs, and SSAX to parse XML files for configuration - speak about heavyweight! Strange license, too. I will refrain from commenting further .

I also had a look at log4r and the Python logging package; both seem worthy taking as a starting point. What I’ve come up with so far has a pretty similiar model to these systems; you send a log entry that should be logged to a logger, which has zero or more handlers that are responsible for actually doing anything with the log entry, such as writing it to a port. All loggers, besides the root logger have a parent, (also a logger) which log entries are sent to, in addition to being processed by the handlers attached to the logger; the propagation to the parent can also be turned off. The logger hierarchy is established by a hierarchical namespace: The logger with the name '(conjure cc) is a child of the logger named '(conjure). This may all sound overly complicated, but getting started is very straightforward:

;; ,open spells.logging
(define log-info (make-log ‘(test) ‘info))
(configure-logger ‘())
(log-info “hello world!”)

make-log creates a logging procedure. Logging procedures take a single argument to be logged; the argument may be an arbitrary object; it is up to the handlers on how to go about formatting this object. The argument passed to the logging procedure is wrapped in a log entry, which additionally contains the log level. The name of the logger that is to be used is '(test), and 'info is the log level. If the logger '(test) doesn’t already exist, it is created on the fly with no handlers and the root logger as a parent; it can be configured later. This separation of logger creation and configuration is important: In a real application, the logging can be configured from the command line or a configuration file; you don’t want to (hard-)code it into the same module that uses the logger. (configure-logger '()) configures the root logger (which has the empty list as name) with a default configuration. configure-logger also has an optional argument in which you can provide a custom configuration, but I won’t go into this now, since this part of interface is most likely to change. The default configuration amounts to logging everything on (current-output-port). Finally, we log a simple string through the logging procedure log-info. The output looks like this:

(test: [info] hello world!)
Well, enough of this for now; if you got curious you can take peek at the code.

It has happened. Today I had the impression that my display was a bit darker than it used to be; and later it started by slight changes in brightness, then real flickering - and then only darkness remained... I can still somewhat read the display, since I've started using black-on-white two years ago when I noticed the increased readability in pure sunlight. Now I've hooked up a TFT, but it's not yet running optimal, since my laptop had a 1600x1200 TFT, while the 17" display I've attached has a physical resolution of 1280x1024 I guess. I loved my IBM ThinkPad, especially because of it's display. Compared with much more recent displays, it had an excellent viewing angle, next to no reflections on it, and stunning sharpness with it's 135 dpi. I'll miss it. And I'll definitely miss the page-left and page-right keys next to the arrow keys I've gotten addicted to for desktop switching... The laptop is now 3.5 years old, so out of warranty. More stuff had started breaking; just before end of the warranty the harddisk died and I got it replaced, the main battery doesn't charge any more and my secondary battery holds for half an hour. Bluetooth never worked for me, and doesn't show up on USB like in all the Howtos. Heck, even of one of the two USB1 ports (no USB2) falls apart - the plastic part to keep the pins from touching is broken off... So it definitely doesn't pay off to have the display fixed. They would need to fix just about anything there. What sucks most is that I had intended to buy myself a new laptop in 10 months. I'd like to get one with a Core CPU then, but I don't trust the early models... and I'll have to decide which brand to buy. I loved my A31p display, but 15" and 3.5 kg is too large and heavy for my current taste. I'd go for an IBM ThinkPad X* (and I'd love the X50 I guess) if they weren't a bit expensive... maybe I'll get a Samsung now, but I definitely would want to test the display first... can't stand some of the displays I've recently seen on Dell (don't even think of watching a DVD on them unless you are at most 2 people, and they reflect like shit.) Does anyone know if there is a sponsorship program for Linux developers to get new laptops cheaper? ;-) Or at least without having to buy a useless Windows licence? Of course I'd help writing drivers and document the installation process...

As mentioned in my last entry, Livejournal have changed their url scheme to get around a problem in mozilla. The trouble is down to the -moz-binding CSS property. I'll repost a copy of the short lived posting to the lj_dev community earlier.

Discussing the URL Change As we recently announced in [info]news, we have changed the canonical URL of most journal, community, and syndicated content. While we did offer subdomains to Paid users in the past, this is now the canonical URL that we will link and redirect to for all journals. However, all communities are located at http://community.livejournal.com/username and syndicated accounts at http://syndicated.livejournal.com/username. Due to the way certain proxy servers are configured, and the fact that the HTTP RFC prohibits it, the canonical URL for journals with a username starting with an underscore will be http://users.livejournal.com/username. We are however offering a free rename if you fall into this group. So now the technical side of all of this and why it was a required change; bear with me as its 3am my time and I'm sitting in John F. Kennedy Airport after a five hour flight. Late last week we become aware that it was possible to use the "-moz-binding" CSS attribute within Mozilla and Mozilla Firefox to execute arbitrary offsite JavaScript. As this attribute is designed to allow attaching an XBL transform and JavaScript to any node within the DOM, it is quite easy to use in a malicious fashion. We immediately altered our cleaner to strip this attribute from entries and comments, though also realized that wasn't even half the battle. As we allow custom CSS in many of our styles, as well as the ability to link to an external stylesheet in a variety of fashions, it was quite possible to take advantage of this exploit and hijack the session cookie of any user who views your journal. As we, along with many other sites, used one cookie to authenticate a user, this cookie was quite powerful if stolen. If the user had not chosen to bind their cookie to their IP address, a malicious user could steal it, login as that user, deface the account and SPAM with it, as well as modify that user's style to include the exploit thus causing this problem to spread much like a virus. Borrowing the idea from another development team within Six Apart, we decided we needed to break our cookies into three categories. One cookie would be our application management cookie, this cookie would only be accessible on www.livejournal.com where we will not display untrusted content. A second cookie will be accessible on all subdomains of livejournal.com, though it only will say if you are logged in or not; it is solely for optimization. We then will issue one cookie for each journal you visit. This cookie will be only accessible on username.livejournal.com or community.livejournal.com/username as it is limited to a single journal. This cookie will only grant you the permission to read protected entries and post in the particular journal. This means that if the journal owner steals your cookie, they will be able to do nothing more than view their journal and comment upon it as if they are you. In the end you will have n+2 cookies, with n being the number of journals you visit. Due to the fact that we cannot clean every external CSS stylesheet linked to every time we generate a journal page, this change is required. While it does not fully protect us from some new cross site scripting vulnerability that can be exploited via entries or comments, they are much easier to block, patch, and recover from quickly. With Mozilla deciding to allow the execution of arbitrary JavaScript via CSS, there is no other viable solution than the one we have undertaken. We developed a plan to phase all of this in over the next week, URL change first and then followed by the cookie change, though this morning we were made aware that this was being actively exploited. As such we took our week time line and shortened it to about twelve hours. While URLs have been changed at this time, our cookie handling change has not yet happened. This should however be expected to take place within the next day or two as well as various other cleanups and fixing bugs we've already encountered. Please feel free to let us know if you have any questions and open a support request if you find a bug or encounter a problem. Sorry all of this came with just about zero warning, but in the end we could not wait longer to fix this problem.

Thanks to Daniel Silverstone for providing me with a cache copy of the text.

Je reposte sur mon blog une r ponse que j'ai faite sur le blog de Ma tre Eolas vu sa longueur : Le probl me des transmissions de donn es est r elle. Vous parlez des 45tours ou VHS que vous ne savez sans doute plus lire, ou des livres trop vieux pour qu'ils vous int ressent. Vous avez raison, il y a des 100aines de gens comme vous (moi le premier). Mais il y a aussi des "geeks" du patrimoine qui ont tout le mat riel pour faire la conversion des VHS vieillisantes vers des divx (avec tous les filtres pour nettoyer les bandes), ou des gens qui ont fait l'acquisition num rique de leurs vieux vinyls, etc... Et on se retrouve avec une migration d'anciens contenus vers de nouveaux stockages. Le patrimoine est sauv . Surtout avec les outils comme google qui permettent de trouver tout m me s'il n'y en a qu'un seul exemplaire. Dans le cas de DRM comme ceux envisag s par DAVDSI, les seuls propri taires des versions originales non prot g es seraient les majors dans le cas de la musique par exemple. M me pas forc ment les artistes eux m me (certes, eux peuvent rejouer les morceaux -- et encore, pour une impro jazz a ne sera plus la m me par d finition -- mais leur vie est par d finition limit e). Du coup, pour que ces oeuvres perdurent, il faut faire confiance au majors pour avoir les protections n cessaires pour ne pas perdre les oeuvres. M me apr s un d p t de bilan (si si, m me Sony peut mourir un jour. Agfa l'a bien fait !). Il faut aussi leur faire confiance pour mettre dans le domaine public les oeuvres qui sont plus vieilles que la dur e l gale de la protections des droits d'auteurs (quoique gr ce Disney cette dur e tende vers l'infini ;p). Personnellement, je trouve que c'est mettre tous ses oeufs dans le m me panier, et dans un bien mauvais panier. Les majors sont dirig es par le besoin de gain imm diat, pas humanistes (et je ne dis pas ca m chament, c'est dans leur nature, c'est inscrit dans la loi du march , c'est juste un fait). Bien sur, je crois que les gens ne prennent pas trop au s rieux la perte d'un morceau de musique. Mais quid d'un film d'auteur ? ou pire ... d'un livre ! Oui un livre peut tre un contenu num rique : PDF, ebooks, ... existent depuis des ann es. Les livres de science fiction o il y a un objet electronique avec des pages (parce que il n'y a pas dire l'ergonomie d'un livre, ca ne peut que se copier, difficilement s'am liorer) dont le contenu est lu sur une puce lectronique et affich sur des pages cran souple (ca commence exister, et je crois vraiment que notre g n ration conna tra ces outils). Ca veut dire que si ces livres ont des DRM, apr s l'avoir lu, pouf, fini. Et l encore ce seront les maisons d' dition qui auront les originaux. M me les biblioth ques ne l'auront pas. elles auront juste une licence avec les diff rents diteurs avec des "ebooks readers" sp ciaux qui auront acc s tout ou partie du catalogue, moyennant license, bien sur renouveler. Et l encore, ca serait se reposer sur la bonne sant de ces diteurs et leur honn tet pour ne pas perdre tout le patrimoine culturel qu'ils ont entre les mains. etc... OUI je comprends vos arguments. Mais mon avis, un des r les de l' tat est d'assurer la transmission du patrimoine culturel (et de tout autre patrimoine en fait) de la nation (voir m me des autres en fait) qu'il gouverne. Une telle loi, si ca n'est sans doute pas la seule n cessaire pour arriver l'enfer que je d cris (quoi que ...) est un pas non n gligeable au del d'un point de non retour o la transmission du patrimoine ne POURRA PLUS tre control e par l' tat, parce que le patrimoine appartiendra des multinationales apatrides, qui ne seront plus du tout sur le sol Fran ais et ne r pondront donc plus de la juridiction de la France. Personnellement, je pense que DAVDSI a un vice bien plus profond que ce que les gens lui reprochent le plus souvent : c'est l'amorce d'un d sengagement in luctable de l' tat de taches qui lui incombent en propre. Il y a sans doute un parall le faire avec le service public... Si le service public est obligatoire, c'est parce que le tout priv am nerait les gens de la Creuse ne pas avoir le t l phone (ou bien des prix d mesur s) peine l' lectricit ou l'eau courante. Si l' tat privatise certains tablissement (EDF tant sans doute le prochain candidat) il ne renonce pas passer des contrats avec ces entreprises leur obligeant de respecter un service minimum. Ceci est possible parce que ces entreprises sont fran aises, et vivent parce que l' tat le permet. Et de toute facon, c'est sans doute l' tat qui financera le manque gagner d'EDF ou d'autres exemples (FT, la Poste, ...) sur les zones non rentables. Peut on faire la m me chose pour le patrimoine ? je pr tends que non. Je vois mal quels seraient les arguments de la France face la RIAA, Sony, Universal, ... Bien sur IANAL, et je dis sans doute un tas de b tises que vous corrigerez sans doute (ou peut- tre pas si il y en a trop). Mais tant informaticien, et voyant le mal que font les DRM notre profession (je ne fais allusion qu' des DRM sur des document PDF, et qu'on ne peut lire que sur un seul poste Windows -- DRM oblige -- et que nous ne pouvons pas imprimer. autant dire que dans ce cas on prie pour que l'ordinateur n'aie pas tre r install !!! parce que au prix du PDF en question, une start-up ne pourrait pas se permettre de le racheter ind finiment) je ne peux pas rester sans rien dire.

I've been so busy, I haven't had time to blog. Rather than putting it off any longer, I'll just dump what I can remember. Last Wednesday, Sarah arrived after her holiday in Singapore, and from all accounts, had a great time. Photos as well. Sticking with the whirlwind theme, the next day, we had a "building warming" party at work for the new building we'd moved into the week before Michael and I started. The next night we had the work Christmas party, which blew the socks off any work Christmas party I'd ever been to before, and then on Saturday night we went to a party in San Francisco that we'd been invited to. On a life in general front, I'm still waiting for a Social Security number. The lack of one makes life a bit difficult for a lot of things. It also turns out that Sarah's work permit will take about 90 days to approve, so she's going to be a lady of leisure for the next few months. I've finally been issued with a work mobile phone (or "cell phone" as they call them), and so can stop roaming and paying through the nose for the privilege. We've found somewhere to live. We take possession of a 2 bedroom townhouse (split-level) in a complex in Mountain View that is 3 miles from work on the 18th. The rent is $1725 a month, which is a bit better than we were expecting. The complex we're renting in does have shared laundries, which we'd not too keen on before getting over here, but they're quite modern and secure, and there's a laundry block close to our townhouse, so hopefully it won't be too bad. The whole place had been renovated about 5 years ago, so it's all in good condition. We could have rented a 3 bedroom apartment (single level) in the same complex for about $125 a month more, but we're trying to actually make some money while we're over here... Driving on the other side of the road becomes fairly "normal" after about a week of doing it regularly. Sarah's adapted fine. Lane placement is the hardest thing, because your body's used to being in a certain spot on the road, and it's all different sitting on the other side of the car. We've managed to open a rudimentary bank account, even with my lack of Social Security number. Unfortunately I can't get paid until I have an SSN. Upside of that is that if it doesn't happen until next year, I presumably won't have to worry about income tax for this US financial year. Downside is kind of obvious... By far one of the stranger things of everyday life here is the lighting situation in the average residence. Lamps are all the rage, to the point that light switches don't exist in some rooms (notably bedrooms). Take where we're currently living for example. There's a light switch at the bottom of the stairs, there's one at the top. There's a bank of four in the living room, two of which control lights in the kitchen, and one the hallway. The last one controls a lamp in the corner of the living room, which is connected to a power socket (or power point as we'd call it). The bedroom with the attached bathroom (en suite) has two bedside lamps, and that is the sole source of light. The bathroom attached has light switches, and the walk-in robe has a light switch. It's so weird. So walking into a darkened bedroom involves walking all the way in, and fumbling around with a lamp. It's often easier to turn on the light in the wardrobe so you can see what you're doing first. I can't think of any reason for it, except tradition. It's not like they're avoiding wiring the walls or the ceiling, because it's done partially already. The bedroom has a ceiling fan, but where in Australia, there'd be a knob on the wall near the light switch to control it, it has a little chain you yank on. To add to the strangeness, there are two switches on the wall, one of which seems to allow you to turn off the ceiling fan if it's already been switched on by pulling the chain. The townhouse we're renting has a similar lamp dependency, so we're going to be making a trip to Ikea for some lamps it would seem. That's about everything I can recollect right now... Oh, I should point out that I'm really loving it over here.