My new work machine arrived last week, a Dell Latitude D820. Let's take a look at the adventures of setting it up for work (Windows, Linux, Windows running on linux (thanks to Xen), and assorted other fu).
Why the Dell?
There were several machines the specs of which appealed (although not that many when your specs for a laptop include a resolution of at least 1600 pixels screen-width, a hypervisor-CPU, and at least 2GB of RAM, among other things). I'm not entirely specs-driven though — before I ever get that far, the UI needs to be right. First and foremost, the display needs to be right — none of those mirror-shades displays they put in the Sony Vaios for a while. The keyboard is another matter, although I'm prepared to compromise to a degree since I expect to work with an external keyboard most of the time. A close contender was the big AlienTech machine (somewhat ironically, AT is owned by Dell), more a stationary machine at 17" than a portable one, it's true, but think of the large display you'd get. In the end though, I've worked on the D810, and on the Inspiron 8200, and I knew I was happy with the Dell displays, and I simply decided to take no chances. (A bit similar to my answers to, What linux should I pick? (If you were a guru, you wouldn't have to ask me, so since you're not, pick whatever your local guru has, so you can get support.) and Yeah, but which distribution is the best? (They're all broken. Find one that's broken in the parts you're not using anyway.) — that is, tinged by a healthy pragmatism. Those who know me however (or have read some previous articles) will know that even if something works, I still like to know why. This week, that luxury was not always available to me, for lack of time, so I'm afraid it works was good enough in some cases, making this write-up more of a log and less of a how-to. I wish it weren't so.
So, what is it like?
It lost 1/2 cm in height from the D810. The media bay is the same (and it's still on the right hand side, where most people mouse, duh), the main battery isn't. The case's colour scheme has changed, and the speakers are the crap you'd expect from a laptop (which wouldn't be worthy of note but for the stark contrast to the D810's celestial choir) — sound worked out of the box, at least. The joystick seems a little nicer on the D820, but that's a subjective first impression. It also seems a bit lighter than both of the other machines, which is always a plus, "especially when you're a girl." The display is just lovely. Many people asked me, Won't things be just too small, at 1920x1200 pixels on a 15" display? Well, you pick bigger fonts, obviously, and man, are they ever crisp! At 145 DPI, fonts look ever so nice. I'll readily admit that I dread the time when I first visit a webshop that doesn't have mid-resolution images of its merchandise — only then do I expect "things to be too small." Other than that it's nice though — contents of web-browsers, terminals, and text-editors — anything that you look at for a prolonged time — are nice, large, and crisp. Menu-text, panels, displays like gkrellm, anything that you look at only briefly or just need a general idea of, are small, and don't use as much screen estate as they used to do. So, on the main applications, you do not gain screen estate (you use larger fonts, so you get more pixels to the same-size app, but the window will likely be the same size you use on any other display — you gain crispness, not screen estate), but you gain readability. On the other applications, you actually gain a little screen estate. Not that much, admittedly, so if you do it, do it for the lovelier fonts, I suppose.
Ah, the fun we had. Windows came preinstalled, but I reinstalled that after putting Linux on the box, both to verify the Windows media that came with the machine, and because the linux install failed to properly resize the Windows partition (and I'd neglected to order with correct partitioning). This wiped the partition table entirely at one point, but I managed to bring it back without losing actual data — that would come later. This left me with a 20 GB Windows partition, 2 GB of swap (also for suspend-to-disk), a generous 2 GB encrypted partition for my setup and passwords, and the rest taken up by linux.
What was that about encryption?
My keys and passwords live on an encrypted partition that needs to be unlocked at boot-up. My linux is a SuSE, so all I can say here is that yast set it up for me, and it worked out of the box. I have directories for everything that lives on there, with symlinks (/home/azundris/.ssh symlinks to /crypt/azundris/.ssh, /etc/foo/bar symlinks to /crypt/etc/foo/bar). If you do something like that, note that some programs do not like symlinked configurations and need some fiddling with (export FETCHMAILHOME=/crypt/azundris/fetchmailrc etc.).
Ah, that's the sexy bit, isn't it? Running Windows on your linux without VMWare. If you haven't been keeping up, yes, Xen used to paravirtualize, meaning, it needed specifically modified guest OSs to work, but nowadays, it supports hardware virtual machines (HVM, not to be confused with HMV), meaning, pretty much any guest operating system will do. Including in my case Windows XP. As long as your hardware supports virtualization (the latest Intel and AMD CPUs do), that is. This is a feature that is usually disabled in the machine's BIOS, so enabling it is your first stop. Then, you install and boot a special Xen kernel.
You can then create virtual machines; paravirtualised ones or, in our case, HVMs.
You also have the choice of getting a viewport on your guest OS via SDL or via VNC. SDL is a little faster, but if you close the viewport, the guest goes. VNC lets you close the viewport, or open several of them, or open them from another machine, and makes the experience a lot more like screen for terminal sessions. The rub?
In SDL, the mouse would reset to the right border of the guest window every couple of seconds. Whether this is the long-standing SDL issue I vaguely seem to remember or the problem with some guests taking a shortcut with interrupt handling that doesn't quite work in the HVM that is noted in the Novell bugzilla I didn't have time to investigate; the latter however is supposedly more prevalent with certain hardware, so you might not even run into the issue on other hardware for all I know.
The VNC on the other hand suffered from the problem that the guest OS's mouse-pointer would move with about 2/3 of the X cursor's speed. Which of course means that your X cursor will leave the guest window before the guest cursor ever reaches the guest screen's border. And once the X cursor leaves the guest window, the guest no longer gets mouse events. Meaning in real terms that you never reach, say, Windows' start menu. The immediate work-around is pressing the left Control and Alt keys so you can reposition the X mouse without moving the Windows mouse. That's awkward enough, but its enough to install the real work-around, which is installing a graphics tablet driver. (The issue being that the standard emulation emulates a PS2-mouse (no matter what physical mouse you have), which uses deltas rather than absolute positioning, and it desyncs pretty quickly. The graphics tablet uses absolute positioning.) This is actually in the manual, as long as you have a sufficiently new one. :-/ Proceed as described, and you have a working mouse in the VNC guest.
Net for the guest is bridged and worked out of the box for me. I believe sound is under development, but didn't check, since I don't expect to spend time in the Windows installation outside of work. Windows still insists on believing my international 105-key is a US 101/102-key keyboard which leads to some annoyance, but I haven't had time to fix that yet. Otherwise, it works nicely.
As a side-note, if creating VMs with yast, it seems like you have to make the SDL/VNC choice at creation time, and then be stuck with it. Not so. You can edit the VM setup file at any time (in /etc/xen/vm on SuSE); they will become effective next time you start the VM.
Lastly, you have the choice between installing the guest into a virtual disk (that is, it looks like a hard-drive to Windows or whatever guest, but like a file to the linux), or a physical partition. The vdisk worked nicely for me, I expect installing to block device to be painless as well, but had no luck so far booting the already-present Windows from the primary partition (which you need to umount first in linux by the way — I found it easiest to comment out the relevant line in /etc/fstab). It pretends to be booting, but just sits there. I haven't had time to investigate yet; there may be updates on this unless I decide that I'm fine with the disk image solution. (The appeal of the physical partition being that I could presumably also boot into Windows, should the need arise, like if I should need sound for once after all.)
I killed at least two hours on this before realising both worked out of the box. More precisely, so you don't think I'm a complete moron, they work out of the box iff you use a non-Xen kernel (in my case, the SMP kernel). They simply did not work under Xen.
Worked after installing not just the driver, but the firmware also. (apt get ipw-firmware) Note that there's a switch on the left of the laptop that lets you disable all wireless communication, as long as that's off, don't expect anything to work. : )
With the drivers installed and bluetooth set up, I still had to enable the device manually (hciconfig hci0 up) before being able to do anything with it (before kbluetooth sees it, for one thing, and before I could use hcitool scan etc.). I can see other bt devices, but I haven't been able to OBEX-transfer yet, will probably investigate. (BT and gnome-obex-server / gnome-obex-send worked pretty much out of the box on my desktop machine, all it took was was the yast setup). I know many people had trouble with BT on this deck, and some didn't, so I haven't given up on it, but it's not exactly a priority either.
Lineak sees volume-up, volume-down, and pause. Fn-Esc (Stand-by) works. I don't see the others (battery etc.) yet, but it doesn't particularly bother me at this point.
More pain to share?
Aside from losing the partition-table (see above), I saw some minor reiser3.6 corruption along the way, which I'd only seen twice before (once on a machine where the RAM had gone bad, and once on one where the nVidia-drivers made the graphics card to bad things). I presume this happened at the one point where X came down hard; I lost permissions on about a dozen files that way. Lost permissions as in, I couldn't even list their names while being able to with the other files in that directory. reiserfsck --rebuild-tree brought back the file-system, and re-installing the affected packages ended those troubles.
For "some reason," the GNOME-browser galeon also stopped working. So did the related epiphany browser, which I managed to get to work with some "clever" updating. galeon however would stay dead. Since galeon isn't exactly under active development anymore and I resented the eternal upgrade pains (galeon needs a matching mozilla/seamonkey, and that sounds simpler than it is, regularly resulting in rebuilding the whole lot), I figured I'd bite the bullet and switch to KDE entirely, for laughs (still not sure the laugh isn't on me, but we'll get to that in a moment). Transferring the bookmarks was easier than I expected (galeon has an export feature, alternatively, konqueror has an import feature); the passwords are stored by the Mozilla component and consequently can be displayed using either Mozilla/seamonkey or firefox with a suitable FF-extension. There, that was easy enough, but I'll miss galeon. And I almost feel a little guilty for leaving it behind.
KDE, though? Sometimes, KDE outright ignores what I set in kcontrol. Likewise, if I create several panels of the same type, there seems no way to set them up individually? kcontrol isn't as byzantine as it used to be, but it's still not exactly clearly arranged.
I've also switched from xmms to amarok because I liked the amarok-display in the universal sidebar for a little while (since destalled; I ended up accidentally opening the sidebar a lot of the time and found that you can also open the display within konqueror so if amarok temporarily freezes, konquie does too, true to the spirit of desktop integration), but it seems much less responsive a lot of the time. Also I get weirdness like, I close the window, it opens again, I close it a second time, it remains closed.
Lastly, I'm trying to run screen from within konsole at the moment. apt didn't have Eterm. There's an Eterm RPM on eterm.org, but apparently, no libast? So, loving Eterm, I got it from CVS (that's enlightenment-CVS, not Eterm-CVS, mind you), and built it from source, but then, it having been a long night, I just got frustrated with setting up the fonts for the new display. It's the naughties, the new millenium, I'm just not sure I can be bothered with xfontsel anymore (which I've hated forever). I have to speak to KainX sometime, Kundalini wants his Eterm back. Be a shame to give it up over something like this.
Speaking of which, setting up the fonts for xemacs was, perhaps unsurprisingly, also the expected bit of an annoyance.
What's with the article's title, though?
If you have to ask … no, seriously. One of my previous machines, a Sun Ultra 5, was called sin. Mostly because it seemed a cool name that worked in the context of my naming scheme. (It also would turn out that it was slow as sin, and so the next machine was salvation from the sin's slowness.) Since this machine is a Dell, I figured I'd recycle the long-gone Sun's name though. (Sin Dell, get it? If you don't, you've probably never played Mortal Kombat, which I guess is entirely forgiveable.)
That's all, folks! — or at least all I can remember off the top of my head. Haven't used the card-reader or the firewire yet; not sure I expect to. My USB-mice worked out of the box, unsurprisingly. Oh, and for all the ports the Dell does have, it doesn't have PS/2, so I need to replace my beloved logitech ergo-keyboard (that sexy black-and-white deal); possibly with the SafeType upright keyboard while I'm at it. Stay tuned!
Intel Core Duo 2, two cores like so:
model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz
stepping : 6
cpu MHz : 1995.055
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr
bogomips : 4989.53
With a better /etc/bluetooth/hcid.conf I was able to transfer to the pone. Furthermore to browse the phone and download its contents (pull from laptop, rather than push from phone), my phone insists on a PIN, so that needs to be enabled in the laptop's conf, as well.
Looking down towards my hands for hours gives me a massive backache, so I stopped by the local store and got a Samsung SyncMaster 204B (20.1", 4:3, 1600x1200). It works nicely in the either/or mode, clone-mode would have required another 1920x1200 display. I'm not sure Xinerama or such is supported, but then it doesn't seem to matter much for my use case. Oh, and I have the D820 with the Intel graphics adapter.
(I also got a PS/2 -> USB adapter to connect my legacy keyboard, but that doesn't seem to work, not with the laptop, not with the desktop, with neither of two keyboards I tried.)
The PS/2->USB adapter was broken; getting a new one fixed it. Slight gotcha: I tried my wireless PS/2 with the new adapter in the shop, and it worked. At home, it didn't. Standard keyboard worked. The trick: I had also plugged in my USB mouse (both in the USB-boards of the right-hand hub). Plugging in the adapter with the wireless keyboard in the back and the mouse on the side (or vice versa) so they'd end up on different hubs fixed it; guess the transmitter needs a lot of energy.
Unfortunately, I don't remember which way around I migrated the bookmarks (galeon export, or konqueror import), but whichever one I used is broken inasmuch I get, say, %26 instead of & in URLs, which breaks them for me in konquie. So if you migrate from galeon and have parametrised URLs, I suggest you check them in the target browser right away. Oh, and you seem to lose your shortcuts (no surprise really since konquie handles them differently, which I'm not convinced is a good thing -- I like having the nickname right with the URL, especially when the URL isn't even parametrised (like having "home" as a shortcut for your homepage, say)). (Speaking of KDE, last annoyance is the kicker panel randomly ignoring transparency settings . I'm sorry, but setup with kcontrol has been totally erratic so far, and KDE underwhelming. Project with so much manpower, you'd think they get basic things right after so much time.)
As it transpires, xemacs DOESN'T HAVE to suck font-wise anymore. You just need to grab one built with Xft (or build one yourself, see http://clemens.endorphin.org/weblog/archives/2006-02.shtml#e2006-02-17T08_56_05.txt ), and you'll get anti-aliased fonts, and setup becomes a matter of, say,
(if (featurep 'xft)
(set-face-font 'default "Dejavu Sans Mono-18"))
Yes, I use some bigass fonts. No, I'm not half-blind. Now move on.
I just upgraded to the openSUSE 10.3 package (xemacs-18.104.22.16870807-29). Since SuSE do their own font magic, we'll have to do something like the following lest only about half the fonts are affected if you change the base-size:
Now that's an intertesting thing to see. Finally I find someone who is really interested in having a desktop system crammed into a laptop case. Now I wonder if you are representative for the average customer as I'm looking for something completely different. Graphics power? What for? If I can playback a DivX file that's way enough. CPU power? Ditto. The applications that I'm using don't need more than a 1GHz - memory would be more interesting. I'd rather have a simple device without optical media and low power CPU/GPU but therefore 6hours power than a gaming station which shuts down after running on the battery for two hours and blasting most voltage into the fans that try to cool down 3Dgfx and multicore CPU. But that's just me, I'm afraid.
This is pretty much the system you describe -- it's the 2nd smallest CPU and the smallest graphics card I could get for this machine. Getting 2GB RAM and a moderately fast disk were more important (4GB RAM were available). The DVD-RW lives in the media bay when I need it; usually, its place is taken by a secondary battery (2 batteries, no drives but the hard drive). The only requirement for the CPU was for it to feature virtualisation. I really don't see the two as mutually exclusive -- it's a replacement for a desktop machine; if I'm at home, it gets a big panel and a decent keyboard. While travelling, I at least get a display with a decent resolution. It certainly isn't a gaming machine. But it's no PDA either.
If lm-sensors' "sensors-detect" finds nothing (or finds eeprom and i2c-i801 only, with "sensors" then finding no sensors), you probably don't have a recent enough sensor-detect. Otherwise it should request the coretemp module for your CPU, which in turn probably isn't in your kernel yet. ;-/
The coretemp patch works against 22.214.171.124-34 (XEN) btw. A reasonably new sensors-detect will then write the setup, and after inserting the kernel modules, sensors should give the temperatures. To see them from gkrellm, I had to call it like so:
I got lirc to work with the built-in IR sensor. Do do that, you need to enable th IrDA in the BIOS, then load the kernel module lirc_sir (which in turn loads lirc_dev), telling it to use the port (address/interrupt) you chose in the BIOS. This is possible at compile-time, or run-time. That should give you /dev/lirc; you can then copy a suitable infrared remote-control setup from the lirc package to /etc/lird.conf or create one with irrecord. xmode2 will show you whether you get signal at all. Since the cone is very limited, it's probably not worth doing for remote controls anyway though; might be worth it for IrDA devices. (If irkick doesn't work btw, check permissions on /dev/lircd, must be rw- for the irkick user. Alternatively, use any of the programs that come with lirc.)
I have been able to trigger bugs (or A bug) in the Xen kernel that effectively locked it up on several occasions; thus, I switched back to the default kernel. The issue went away. Also, under Xen, konqueror and later beryl (anything X that eventually uses a lot of CPU over time?) would at some random point get really really slow, and stay slow until restarted -- so slow in fact that I could see individual pixels drawn for konqueror. This too has yet to occur with the default kernel.
And since this seems to be my week of gripes: why o why is the stupid Fn key that you only need twice a day on they main keyboard, and menu (which I also only need about twice a day) is not? More precisely, the Fn just feels wrong there, I keep getting it confused with the Super key. :-/ Also, there is in fact enough space so the menu key could have gone between AltGr and Control where it belongs. Who designs this shit? If your excuse is that then people would get confused, what with the right Control key being right next to the cursor keys, think again -- that didn't keep you from sticking Control (left), Fn, Super, and Alt in a gapless row, did it now? Hmf.
My deck has the intel 945, that always worked for me, EXCEPT after the recent upgrade, now xorg.conf needs the hotfix of 'Option "NoAccel" "true"'; that's X 7.4, (II) Module intel: vendor="X.Org Foundation"; compiled for 1.5.2, module version = 2.5.0; Module class: X.Org; Video Driver; ABI class: X.Org; Video Driver, version 4.1