Pepsi Max

Pepsi One

jumper

sweater

petticoat

jumper (many sniggers when you refer to "putting on your jumper")

entree

appetizer

main course

entree (ordering entree-sized dishes will not have the desired result)

I've already fielded enquiries from two people who have found my blog via Google, and given the 10,500 visas a year being issued, there's only going to be more, so in the interests of not spending too much time answering questions individually, I'm going to write a detailed account of things. Disclaimer: This article is not a replacement for doing your own homework. I expressly disclaim any responsibility for you getting your visa application denied, being cavity searched when you attempt to enter the US, or being sent to Guantanamo Bay. In particular, this information is subject to change, and as I'm not applying for a new visa every day, I'm not going to know about the changes. If you find something here that is blatantly wrong, or out of date, please let me know, but at the moment, I'm writing about my experiences. I'm undecided about maintaining a website devoted to capturing the state of the art in E-3 visa applications. If in doubt, spend the money (and I do mean spend, it's not a cheap phone call) and call the information line - 1902 941 641 - to speak to a human being, and ask all the questions. Resources

• The Australian Government's Department of Foreign Affairs and Trade's page on E-3 visas
• The US Consulate's E-3 visa page
• The US Consulate's page on applying for a non-immigrant visa

What's the process? Your potential employer (sponsor) needs to file a Labor Condition Application (see the form here). At present, this form hasn't been brought up to date with respect to E-3 visas, it's the same form used for H1-B visas. Your employer needs to have written at the top of each page "E-3 - Australia - to be processed". This bit of handwriting is apparently key. You need to have the signed LCA in your hot little hand before you roll up at the US Consulate to apply for your visa. As for how long these take to be processed by the Department of Labor, the FAQ says a week for postal applications. From my experience, and the experience of a couple of other people I've spoken to, it takes anything up to about four weeks. Generally speaking, you do not have to concern yourself with the LCA process, unless for some reason, you're sweating on the LCA so you can apply for your visa. My personal opinion is that the whole process is so long, bureaucratic and unpredictable, that you really don't want to be making any firm plans based on any assumptions on when you think anything is going to happen. Start your planning from when you have been issued your visa, not when you expect you will be issued your visa. Once the LCA has been issued, your sponsor will send it to you along with a wad of paperwork, most of which you just take with you to the consulate. You can make an appointment online. Paperwork-wise, you need to take a completed DS-156 and a DS-157 if you are male between 16 and 45. These forms are available here. You can make an appointment online, the links to make an appointment at each of the US Consulates are also here. I found that the lead time to an appointment was around a month, so if you know the LCA application has been made, you can probably make the booking at the Consulate, so as to try and parallelise things a little bit. What do you need to take to the interview? You need to take your completed DS-156 and DS-157 forms. You need one for each person. So if you are the principal (i.e. the person being hired), you need a DS-156 for yourself, and your spouse, and whichever of you is male needs a DS-157. Bring the sponsor's offer letter too. You need a receipt for a non-refundable visa application fee. You need one receipt per person applying for a visa. You get these receipts by paying $130 per person at any Australia Post outlet. As the visa is non-immigrant, you need to be able show some sort of ongoing connection with Australia. If you own property here, and are planning to continue owning it while in the US, bring a rates notice. I don't know what else is useful to demonstrate an ongoing connection. Also bring a bank statement, as you need to demonstrate an ability to support yourself while in the US. Bring birth certificates and marriage certificates. Also bring a copy of your University transcript, and any assessments that your employer may have had done that state that you hold the equivalent of a US degree. I'm not sure how hard and fast the whole degree thing is. I have an incomplete degree and about 10 years of work experience. This was sufficient. I don't know how you'd go with absolutely no degree and lots of work experience. Finally, you need to bring two US-sized passport photos. These are 5cm x 5cm, which are not what your average passport photo is like if you go somewhere and ask for a passport photo. Processing takes about 3 days, although you get an indication on the day as to whether you are successful or not. If you don't want to come back to collect your passport with the visa in it, you need to leave sufficient stamped, self-addressed envelopes so that the Consulate can mail the passports back to you. It's a bit hazy as to what constitutes 3 days, but assume 3 full working days, plus whatever time it takes for the postage, so up to 5 working days. Good luck with your visa application. Let me know how it goes, and if this has been of assistance.

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?

So, as of sometime this morning, most of our worldly possessions were (in cartons) loaded into a shipping container bound for the US. Unfortunately, I don't finish work until Wednesday, so my lovely wife was charged with supervising the packers yesterday and today. My one word of advice with respect to packers is to be extremely careful, and assume that they will assume nothing. If you don't want something packed, don't leave it unsupervised or anywhere where it may be packed. My electric toothbrush was left unattended for slightly too long, and is in a carton somewhere. As was half of the bike rack until we raided a few cartons last night and rescued it. Obviously literacy doesn't rate very highly as a requirement to be a packer either. We had "stools" spelt as "stulls" and "wine rack" spelt as "win race" on some of the items packed. I'd also never seen a couch bubble-wrapped until yesterday. Pretty much no item was left exposed. Everything is either in a carton or bubble-wrapped with funked brown-paper-backed, branded bubble wrap.

I received a bugreport 342156, and I went for a search on why this program seems to be working without a problem.For the case of delete[] of void*, void* actually has a destructor defined, _ZdlPv in libstdc++.A desctructor of a void* will call free, after checking if the pointer is non-NULL, as in plain C: if(a) free(a); .g++ will warn you if you use this construct, but it will function, in practice.However, this topic apparently is a popular onecovered in a few articles, such as this one which tells you it's a sin to mix malloc/free new/delete.Unless you are bored enough to be able to follow compiler intrinsics to the minor details, it's better to keep away from such practice.

This is old news by now, but still interesting IMHO. Jonathan Brossard has posted an article on BugTraq which gives a pretty good introduction to the inner workings of the BIOS (with lots of links to more detailed resources) as well as known vulnerabilities of the BIOS password mechanism. The most interesting part is when he explains that the BIOS doesn't seem to erase its own keyboard buffer before it hands over control to the operating system. Also, current OSes (Linux, Windows, *BSD, etc.) don't seem to clear that buffer either. This may not sound dangerous, but it actually allows anyone who can read the contents of your RAM, starting from address 0x041e, to view the keyboard buffer contents. And this buffer contains the BIOS password you type in when booting your machine (if you set/use a BIOS password, of course). This one-liner (executed as root) should let you view your password as plain text:

dd if=/dev/mem bs=512 skip=2 count=1 hexdump -C head
(Only every second character belongs to the password, the rest are key scan codes, I think). I also noticed that this same buffer also contains your LILO password, too! The same is probably true for passwords of other boot loaders such as GRUB, but I didn't test that. Yes, reading this part of the RAM usually requires root privileges in Unix-like OSes, but as the security problem is OS-independant other OSes (e.g. DOS, or older Windows versions) might be directly affected. But even on more secure OSes this plain-text storage of the BIOS/boot loader passwords might be a problem. Combine this with some Firewire insecurities and attackers with physical access to your machine (e.g. your unattended laptop, while you are on the toilet) might be able to read your BIOS/LILO passwords even though you locked your machine. I haven't yet tried this, but I'm pretty sure it's possible. Please post the results here if you try this. (via Stefan 'Sec' Zehl) Update 2006-01-09: It seems that when you use software suspend (swsuspend2) the RAM area can/will also contain your root password! Thanks nelson for reporting.

More nice hardware running Debian. With rwhitby's help I've gotten Debian (little endian arm) installed on a nslu2 (donated by the nsul2-linux group, retails about $100). Tiny little box with USB, lots of nice applications. For those who are counting, that makes 10 computers running linux (7 Debian + 3 openwrt; 3 x86 + 3 mipsel + 3 arm + 1 armeb) here at the oh so rustic and old-timey farm. I hope d-i will support the nslu2 soon..

I think tomorrow I'll reconfigure Blosxom's idea of what timezone my posts are in from Australia/Canberra to US/Pacific. Carnage and mayhem will undoubtedly follow on the odd few Planet's that I am aware of being aggregated by.

This blog has been semi-offline for at least a few hours. Sorry about that. Through an interesting (at least to me) series of events, I discovered that my custom “popularity” hack/plugin was out of control. It started earlier today when one of the the RAID discs on this server gave a SMART error. I’ve never been able to really judge whether SMART errors are “for real” or not—sometimes I’ve had a disc with a serious SMART error that, after another test, will run fine for another year or two without incident. In any case, I wasn’t so worried, since this system is running RAID-5, so a single disc failing, even catastrophically, doesn’t result in any data loss or downtime. I decided to take the disc out of the RAID and run some SMART tests on it. I marked it with mdadm as FAILed (mdadm —fail) and then removed it. Strangely, the disc first passed a short test with no problems, but then ceased to be recognized as having SMART capabilities at all. I’ve had that problem before and never figured it out—the SMART capabilities seem to come back eventually. Not knowing what best to do, I just put the drive back into the RAID to see what would happen. Since the disc had already been marked as FAILed, the reconstruction started from scratch. Although I’ve got a pretty good (2Ghz) CPU and plenty (2G) of RAM, kblockd and md0_raid5 are using up most CPU cycles and everything has slowed down significantly. Reconstruction seems to be proceeding fine, just slowly—it will take 24-36 hours at the current rate. Presumably it would be much faster in single user mode, but I can’t take this server offline. In the meantime, I noticed that my blog had stopped responding entirely, while other blosxom blogs served from this same server were fine (maybe a little more latency than usual). So I started parsing through the differences in my blosxom installation and everyone else’s to see what could possibly be slowing things down so much as to time out the blog. Eventually I identified the culprit: my custom-made “popularity” plugin, which reports the most popular entries on this blog and the number of hits they have received. I hacked it together several years ago. I think at the time I just wanted to see if it would work, with the plan to come back later and fix it. I guess I forgot the “fix it” part. My popularity plugin creates a log file that it reads in each time the blog is accessed, and then appends to that file. Over the years, that file has grown to 17 megabytes. Although this is a huge waste of system resources, I didn’t notice it when the system was running at full speed. With the reduced performance from the RAID reconstruction, however, this meant that my blog never finished loading at all. If you made it this far, you certainly deserve some sort of geek admin award. Congratulations. I deserve some sort of stupid admin award, myself. P.S. Apparently I must have forgotten to check my horoscope today. The laundry machine flooded the basement when I didn’t check the sink into which the laundry machines empties. I should probably avoid sharp objects for the rest of the day.

Jamie recently created a drupal site for cheese aficionados. So far the main feature is the blog, but it’s coming along quite nicely. Jamie has had some pretty hair-raising cheesemaking experiences, including a near death brush with mozzarella (photos). Curdnerds is clearly ready for the world. The question is whether the world is ready for Curdnerds. Time will tell.

The latest release of gnome-control-center contains an updated version of gnome-keyboard-properties which is even more hostile to a customised keyboard configuration. The fundamental problem has not changed: I need to customise the standard keyboard layout configured in x.org (so far I have been using xmodmap), but GNOME will override any change done in ~/.xsession. With the precedent version I was able to remove all configured layouts from the dialog (at the price of an annoying warning dialog at every login: #245460), but the new one helpfully forces me to have at least one valid layout. So, what can I do to make my keyboard configuration GNOME-compatible? Bonus points if you know how to do this without root privileges (editing the xkb database is not a valid answer).

I have a local hack that makes docdiff a bit more whizzy than it is.I embed ctrl-A to the current location in emacs buffer, hand it over to docdiff, and docdiff will change that to an HTML anchor.That way, I can jump to the current editing location when the target docdiff is quite large.Here is the patch with an accompanying elisp.

fEnIo learnt an important lesson about the kernel firmware loader: it (usually) does not work as expected for non-modular drivers. The reason is that the request_firmware() interface is synchronous. Since it's usually called in the initialisation section of drivers, the userspace firmware loader is not available yet if the calling driver is built-in in the kernel. The request_firmware_nowait() asynchronous interface was designed to replace it, but most drivers have not been ported yet. When a driver calls request_firmware(), a uevent is sent by the kernel to udev over a netlink(7) socket, requesting that a specific file is uploaded. udevd runs /lib/udev/firmware.agent, a simple shell script which will look for the $FIRMWARE file in a few directories and then copy it to the designated place in the driver $DEVPATH in sysfs. If the driver is initialised before userspace is started then the loader will not be available, and the request will fail. A possible solution is to run udev in the early userspace environment (initramfs), but just compiling the driver as a module is usually simpler.

For many years already (probably since I have been a productive member of the society, or at least pretended so), I have been an early riser, unlike most people in the community. Today, I seldom stay awake after 12AM, and wake up shortly before 7. Some months ago, I think I was an hour or two more sleepful, but since I picked up morning excercise... Well :)
But it worries me to see people in Debian following a trend to change for this more human-like lifestyle - I interact with many Europeans, and it's nice for me to have them online during the same period I am online - +- 9AM to 8PM.
If more Debianers start waking up and going to sleep early, it will affect my interactions! Please, stay up late!

I had a bunch of old packages in my ~/debian/nbd/ directory, that didn't serve much purpose anymore, so I wanted to clean them out.

wouter@grep.be:~/debian/nbd$ rm -Rf *

After that finished, I realized that this directory also contained my CVS checkouts of the NBD upstream CVS. And one of those checkouts contained quite a lot of uncommitted code. Whoops. So, what do you do then? Stop writing to disk immediately. Pull the plug. Except this is a laptop, so, push the power button until you don't see anything anymore; and next, try to read the lost file from a different installation. That "different installation" was an easy one. I've always had a second, minor, 'play' partition on my laptop, that I use to try out all sorts of operating systems. I've used it to run Debian stable, Ubuntu, MacOS X. It currently contains Gentoo; I intend to try out FreeBSD for PowerPC some time. But the fact that it already had Gentoo meant I could use that one to run debugfs on the (not mounted) file system, and try to find my files back. Except that I'd never done that before, and I didn't know where to start. And since my gentoo installation isn't set up entirely right, I couldn't get networking to work okay, thus, no help through IRC. My first guess was to check the ext3 journal. There's a command to dump any random inode to disk in hex format (dump <inode number>, with the square brackets), so that should help. I thought. Hah I spent two hours looking at kernel code, trying to find out what the on-disk format of the ext3 journal is (which, as it turns out, isn't part of the ext3 driver; it is a totally different driver, called jbd), only to find out that it wouldn't help me; a journal obviously only contains information on the new data it's going to write, not on the old data it's overwriting. And seen how removing a file means you overwrite a directory inode block with newer information that does not contain the reference to the removed file anymore, that wasn't helpful. At least I learned what the ext3 journal's on-disk format is. Might be useful in the future. My next move was looking at debugfs again. Found that it has some command called dump_unused, which will dump the raw data of any blocks that are not allocated, provided that raw data isn't just zeroes. That's a lot of blocks; bzip2'ed, I had already 1.5G before I killed it. Fortunately, an easy 'bzgrep' told me that the file was, indeed, in there somewhere. I did a commit now. Just to be sure :-)