I put Gutsy Gibbon on my new MacBook today. It rocks. My external (23") monitor works nearly flawlessly, and the open-source Intel drivers worked out of the box to give shiny desktop effects!
I first installed ReFIT, then I used diskutil resizeVolume under Mac OS X to resize my hard drive, and then I installed Ubuntu into the empty space. It couldn't have been simpler (now that Boot Camp is no longer free from Apple). My monitor works with the Intel drivers, and I use xrandr to configure it on-the-fly because I often move my computer. The screen still goes crazy occasionally, but it's survivable.
Anyway, I highly recommend people try it. MacBooks seem to take Ubuntu very well! I have nothing to complain about at this stage.
posted at: 04:14 | path: /unix | permanent link to this entry
I previously mentioned I was affected by a couple Debian bugs. I've managed to fix the sound one. Previously, I was using the module dmasound_pmac to do my sound. Well, that's an OSS driver, and while it still has the bug with the symbol conflict, I discovered that there's an ALSA driver that works better and seems to be better maintained.
I might as well describe OSS vs. ALSA. OSS stands for Open Sound System. It's the "legacy" Linux sound system, deprecated with the 2.6 kernel, but in general you can emulate OSS if you're using ALSA as your main sound system.
OSS is what makes /dev/dsp, the sound device that applications often open in order to play sounds. The OSS API seems to specify that the DSP can only be opened by one process at once. ALSA provides the devices in /dev/snd, and I don't think it has the same opening problem (I hear gaim noises when I'm playing music now).
Anyway, I fixed my Powerbook sound by changing from the OSS modules to the ALSA one. It's called snd_powermac and it modprobed just fine. I started Rhythmbox and it figured out that I was using ALSA without having to tell it. I then updated /etc/modules, got rid of dmasound_pmac, and added snd_powermac, and I was in good shape. Yay!
It also fixed an issue I had with Rhythmbox. I had only recently switched from AmaroK to Rhythmbox, and with the OSS driver Rhythmbox would "hiccup" when playing a song and something else wanted the CPU -- even though it was only taking 5% of CPU time, it had too much contention. Changing to the ALSA driver fixed it.
posted at: 20:25 | path: /unix | permanent link to this entry
Last month I bought a 2.5" laptop hard drive enclosure and an 80GB drive to go with it. Today I finally got working my backup solution using it. I'm using rsnapshot on my Powerbook under Linux to do the backups, and TrueCrypt to encrypt the partition that I'm backing up onto. I set it up to not only back up my home directory under Linux, but also my homedir under OSX, my Techhouse directory, and my CS system directory.
I set it up to make a snapshot on a daily, weekly, and monthly interval basis. It will try to run every day, but it will only succeed if the drive is actually mounted. That's okay; I don't actually need it that often, but there's no harm, I guess. I can also perform snapshots manually if I want. And I can carry the drive around, so that I can read my backups on any machine with TrueCrypt installed.
posted at: 16:19 | path: /unix | permanent link to this entry
I'm thinking about writing some code for Linux installers if nobody else does it first. I want to make an easy partition designer -- providing a nice task-oriented UI for picking your partition layout.
The problem I commonly see is new users being handed two choices: "partition the drive automatically" and "let me do it myself". Well, usually, if you partition automatically, you have to blow away the existing OS. (Even if you don't, you can't control the layout at all, and it's probably wrong.) Many users will be forced into the "do it myself" mode, and the UI for this is never nice -- mainly because "create a partition" and having to specify the size, fs-type and mount point is pretty bad. I'm not even going to go into the primary/extended/logical nightmare of usability.
So I propose a partitioner that is focused around partitions for specific tasks (i.e., mount points). The user is presented with a diagram of the disks, similar to existing partition programs. But instead of it saying "make your partitions now" it has a bunch of check boxes, and you can play around with checking and unchecking boxes in order to see the results updated in the diagram above it.
Each checkbox refers to a potential separate partition, and has a description, mount point, and sizing parameter. Examples:
Do you get the point? We display the actual tasks people tend to use, rather than making them make everything up, and we provide lots of nice descriptive text for reading types. The NTFS example deserves examination -- we will detect and provide a similar dialog for old ext2/3, NTFS, FAT32, HFS+, and all the other filesystems that Linux knows how to detect and mount. The resizing will be defaulted only if the existing big partition takes up too much space. We show the files so that the user can examine the filesystem and identify partitions by content.
posted at: 21:02 | path: /unix | permanent link to this entry
I've turned on subpixel font rendering on my work computer running Linux. Apparently it doesn't autodetect my LCD properly, because I think it's supposed to be on by default if you have an LCD, but I do and it isn't for me.
What's subpixel font rendering, you ask? Well, LCDs use three vertical "stripes", each a third of a pixel wide, of red, green, and blue, to render a single colored pixel. Since these stripes are laid out in a predictable order, you can effectively render with triple the horizontal resolution by addressing the individual color stripes. Read more at Gibson's page.
Anyway, if you want to find out whether you're using subpixel rendering, fire up 'xmag' and click on some text. Your text is probably anti-aliased, but is it colorful?
posted at: 19:18 | path: /unix | permanent link to this entry
I've gotten DVD playback to work under Debian Testing on my Powerbook. It was relatively easy, although I couldn't do it just with the package manager.
I had VLC installed, so I first tried to use it. I told it to open /dev/dvd, but it refused, saying it was scrambled, which I expected. I knew I would need a DVD descrambling library, and so I searched around and found that what I wanted was "libdvdcss2". Debian won't distribute it since it's illegal under the DMCA, but it's pretty easy to find on the Internet. I found this mirror from googling "libdvdcss2 powerpc". I installed libdvdcss2_1.2.3-2_powerpc.deb without a hitch, so I ran VLC again and pointed it at the disk drive, and it worked!
This isn't the end of the story -- the sound and video worked, but every few seconds the video would hiccup. And believe me, when you're watching a video, these hiccups are really distracting. It sounded like my CPU might not have been fast enough to play fullscreen DVDs with that player, or something (it works great in OSX though). I figured I could try another player called Ogle on the recommendation of a friend. There was a version of Ogle optimized for the AltiVec vector processor in my machine, in the package ogle-altivec in Debian, and I was hoping that at least the AltiVec stuff would make it go faster. I installed it and it worked perfectly. Yay!
I wanted to relate this story because it has a few morals: First, it's actually reasonable nowadays with GNU/Linux desktops to fix things that don't work "right off the bat" with a minimum of pain -- even when the package you need isn't part of the distribution, it's easy to go find a version you need on the net and install it manually (and if you don't know what package you need, reading pages online usually gives a clue). Secondly, it's a lot of convenience to be on a platform where there are plenty of free alternatives for different software tasks -- when one program to do a task doesn't work right, there are very often other programs you can install that do it better. Lastly, the DMCA is a very bad law, and I encourage you to break it -- I broke it by installing libdvdcss, but the law really shouldn't exist and is probably illegal under the First Amendment.
posted at: 20:40 | path: /unix | permanent link to this entry
On my Powerbook I'm running into two extremely annoying Debian bugs. The first is that the Mac-on-Linux modules don't work for my kernel, #325418. There are no precompiled modules, and the mol-modules-source package which is supposed to be buildable isn't. So I just don't have the modules and I can't run Mac-on-Linux.
The other one isn't so crippling, but it's still very annoying. The sound driver dmasound_pmac doesn't load on boot, because it claims to depend on both saa7134 and dmasound_core, and they both define the same symbol, so they can't both be loaded. This is #358824. In point of fact, the correct symbol is the one in dmasound_core, and to get it working, I just do:
$ sudo modprobe -r saa7134 $ sudo modprobe dmasound_core $ sudo modprobe dmasound_pmac
These must be executed in this order every time I reboot, and then the dmasound_pmac is loaded and /dev/mixer appears and everybody is happy. However, when pbbuttonsd (the daemon that controls volume and brightness with the Fn+F1-F5 keys on my Powerbook) was loaded at boot, it didn't find a mixer and refuses to control the volume. So I must also do /etc/init.d/pbbuttonsd restart in order to get my volume control back. It's a pretty annoying bug, and I'm sure it would take two seconds to fix. Oh well.
If you know of a good way to make it not automatically load saa7134 (as a band-aid until the problem is properly fixed), please tell me. I tried blacklisting it in /etc/modprobe.d (doesn't work because blacklist only affects autodetection, not modules loaded through dependency) and hacking my modules.dep (regenerated on next reboot), but I'm out of ideas.
posted at: 14:21 | path: /unix | permanent link to this entry
Holy crap, I've gotten bcm43xx (the free Broadcom wireless driver) to work on my Powerbook (g4 17" 1.5GHz) under Debian, and with WPA encryption too!
I've got an up-to-date Debian Testing (etch) with a newer kernel. I installed the linux-image-2.6.17-1-powerpc from unstable, which came with the bcm43xx driver. (Before I installed the one from unstable, I tried building and installing a custom one, but it didn't work, so I gave up on that.)
If you're upgrading from before 2.6.15 like me, your upgrade path may include "udev". I'm currently using udev, but it conflicts with hotplug... in any case, I didn't have any actual issues except for some weird looking error messages a couple times. Once I was booting under the newest kernel they went away. (But now my sound doesn't work, so I have to look into that.)
Firmware: Before I booted the kernel, I dumped the firmware for my bcm43xx into /lib/firmware. Under Debian, simply install the bcm43xx-fwcutter package. Now, if it doesn't pop up a Debconf prompting you to "extract and install the firmware," simply sudo dpkg-reconfigure bcm43xx-fwcutter and it will prompt you. Say yes, and ls /lib/firmware to make sure there's a bunch of .fw files in there.
Another package you'll need is "wireless-tools", which contains such gems as "iwconfig"; and, if you want WPA, you need wpa_supplicant. More on this after you reboot.
Now boot the new kernel. You should be seeing bcm43xx related messages in your dmesg. Mine gave a bunch of messages and said something like "Radio turned off."
Iwconfig should be installed at this point to /sbin/iwconfig. Run it. It will probably make it abundantly clear which device is the wireless one. Mine was eth2. To turn on the radio, I had to ifconfig eth2 up (these mostly need root permissions). Then my "iwlist eth2 scan" worked and showed me some SSIDs. Find the one you want and look at its channel and SSID.
Then do "iwconfig eth2 channel 6" (specify the channel from scan) and "iwconfig eth2 essid BrownCS" (specify the SSID you want).
I edited /etc/network/interfaces and added "iface eth2 inet dhcp". /etc/init.d/networking restart; ifdown eth0; ifup eth2 and I was on my way (without WPA yet though).
To get WPA: Back to /etc/network/interfaces. Modify the eth2 stanza:
iface eth2 inet dhcp
wpa-driver wext
wpa-ssid BrownCS
wpa-key-mgmt WPA-PSK
wpa-passphrase MyAwesomeWPAPassphrase
It all works. Woot!
posted at: 17:03 | path: /unix | permanent link to this entry
Several months ago, I wrote:
I've been learning about virtual memory. I guess I'll explain what I know, and if someone wants to correct me, please let me know. Okay, so, fundamentally, VM is a mapping of virtual pages to "other things" (like physical memory, devices, disks, etc.) What's a page? 4k of memory. Well, it's not always 4k, but that's a common size. The size dictates how many entries in the page table you have, because each page can be mapped to something different and it has to keep track of each page individually. What's the point of VM? There are many. Processes shouldn't be able to access the memory of other processes, and in this method each process gets its own VM address space so that you can't possibly confuse them. Also, these mappings can go to many places -- you can have two processes share the same address space; you can swap pages to disk and then bring them back when somebody needs to use them; you can (as mentioned before) make some pages actually devices like graphics memory, and so forth.
Now that I'm deep into the Virtual Memory assignment of CS169, I can talk about this more. I was basically right, though. The way we've implemented it is with "VM Areas" and page tables. VM Areas specify a range of pages that are mapped to a certain vnode (which can be null). We convert from VM Areas to page tables when we "page fault" -- which involves instructing the vnode to give us a page of RAM, or creating it out of thin air if the vnode is null. Then we save the physical page in the page table.
The hardware doesn't look at our page table structure, though; we have to fill the TLB with some page table entries. So when the hardware gets a TLB miss, it asks us to fill it, and we look at the page table, optionally handle a page fault, and write from the page table to the TLB.
One detail I missed was regarding the page table size -- if a mapping of every virtual page was stored for every process, it would be large. Instead, we take advantage of the idea that there are usually giant swathes of unmapped memory in the address space -- we use a two-level page table. The top level is called the segment table and the next is the page table. We just shift bits to get the segment and page indices, and only allocate the page tables on demand.
posted at: 14:42 | path: /unix | permanent link to this entry
So I've been taking 167/9 and working on this project called Threads. It's totally bitchy. Which isn't to say that it's not fun, 'cuz it is.
We have to modify a database application to be multithreaded. That part was pretty easy -- using a read/write lock we would lock the database, access a piece of it, then unlock it. That, however, isn't good enough. The database is stored as a bst, so we had to use fine-grained locking on individual nodes of the database in order to lock it properly. That was also annoying but fortunately not that tough to get right (or, at least, what appears to be right; I can't tell whether it is for sure).
After this is all the cancellation stuff. In case you don't know, POSIX threads have an awesome (but very complicated) feature called cancellation. If someone else wants to cause your thread to terminate, they send a "cancellation request". For cancellation requests, you can either ignore them, defer them until a cancellation point, or screw it and execute them right this second. Generally you don't want to do the latter, because chances are good that it's in a weird state (say, you've just locked a wondrous mutex) and everybody dies.
So generally you use deferral. The places you defer them to are called "cancellation points" and they're inside most syscalls that block, plus pthread_testcancel, but not pthread_mutex_lock. What happens when you get canceled? Well, it executes the cancellation stack and then terminates. The cancellation stack is a series of functions that the thread sets up that say "if we get cancelled here, execute this". It's a stack because one outer function might wrap a mutex grab with a cancellation unlock, and then some inner function might use a malloc and want to free it if the thread is canceled. Et cetera.
Anyway, this stuff isn't that hard, but it's very tricky to get right. I have been wading through some nasty bugs when my cancellation stack isn't set up right, mainly because it's very tough to figure out where the thread was when it was canceled.
posted at: 11:41 | path: /unix | permanent link to this entry
We successfully changed over to the new server for Techhouse. Previously known as th2, it has two 1 GHz Pentium processors, and we are running Linux 2.6-smp.
Everything is faster now :) -- the wiki being a highly noticeable example of this. Also, we have Debian (instead of Slackware), so things will install nicer and better.
posted at: 12:58 | path: /unix | permanent link to this entry
I've been learning about virtual memory. I guess I'll explain what I know, and if someone wants to correct me, please let me know.
Okay, so, fundamentally, VM is a mapping of virtual pages to "other things" (like physical memory, devices, disks, etc.) What's a page? 4k of memory. Well, it's not always 4k, but that's a common size. The size dictates how many entries in the page table you have, because each page can be mapped to something different and it has to keep track of each page individually.
What's the point of VM? There are many. Processes shouldn't be able to access the memory of other processes, and in this method each process gets its own VM address space so that you can't possibly confuse them. Also, these mappings can go to many places -- you can have two processes share the same address space; you can swap pages to disk and then bring them back when somebody needs to use them; you can (as mentioned before) make some pages actually devices like graphics memory, and so forth.
posted at: 01:33 | path: /unix | permanent link to this entry
I had to go through some pain to get this thing running, but it was cool.
Then the ISO kept crashing Disk Utility, so I had to burn it with cdecord. In Terminal:
sudo apt-get install cdrecord
then:
sudo cdrecord dev=IODVDServices hoary-live-powerpc.iso
finally, it was burned. I rebooted holding C until it started booting Linux.
The Linux boot took a hella long time. It went through like five "detecting..." phases, all for different things, which was kinda cool but very slow. Then it killed all processes and rebooted with a new, Live system. And of course that took pretty much the usual Linux boot time. Plus the time it took to start X and GNOME.
Anyway, while I was booting I wasn't plugged into the network (I normally use wireless with a WEP key), and I got a DHCP error. I let it boot, assuming I could fix it once I had gotten up. It started GNOME and all my other devices seemed properly detected -- trackpad, sound, usb mouse, it was in my screen resolution (1440x900), and so forth. The network still didn't work -- in fact, it only detected one device, the wired card. No wireless at all. Darn; I went over to my router and plugged the thing in, and started playing. Unfortunately it didn't react to my plugging the cable in (no dhcp). I had to run dhclient eth0 at the terminal to get it to work, but that was fine and dandy, fortunately.
I was able to use the package manager to install new software, which was cool. (everything was on a ramdisk). To mount my regular hard drive I did:
mkdir /mnt/mac
mount -t hfsplus /dev/hda3 /mnt/mac
Of course, my home directory is a FileVault disk, so I couldn't browse it, but the rest of the filesystem seemed to work fine.
I wanted to try Mac-On-Linux. Unfortunately I couldn't compile it, presumably because I think it wanted to recompile the kernel, and I didn't want to do that. I gave up after several tries.
Overall Ubuntu did a decent job, but not great -- I really wish they had included wireless drivers, or at least fix the networking in the OS so that it does DHCP if you plug something in.
Lincoln
posted at: 23:01 | path: /unix | permanent link to this entry
Slashdot today points us to OpenSolaris, where you can now download the source for DTrace, Solaris's super-cool tool for tracing pretty much anything you can think of.
The program interacts with the user using a compiled scripting language called "D". This is a C-like language designed specifically for DTrace. The difference is that there are a lot of builtins, and a lot of hooks. The whole point of dtrace is that you can hook into almost any function of the operating system or another application and execute any D code at that point. The great thing is that you don't pay for hooks you don't use -- the hooks are inserted into the executable when dtrace starts, and they are removed when it exits.
Apparently, there are like thirty thousand hooks that you can listen to. They're in a hierarchical structure, which I don't fully understand, but you can specify something like syscall::read:entry to trap on all read() syscalls.
D code runs in kernelspace, and it is error-checked at runtime so that you don't accidentally crash your kernel with a bogus dtrace script.
Anyway, I think this is really cool, and it's great that they're open sourcing it. I'm probably going to try to get Solaris so I can fool with it... but I don't know how much I will use it. I might not have time to do it, what with school and all.
posted at: 01:10 | path: /unix | permanent link to this entry