• VigiPac: dead and reborn

    A bit more than year ago, jvprat (a classmate) and I started to develop VigiPac, a three-dimensional Pacman-clone with multiplayer support. It was registered on Sourceforge.net soon after to make it available to the public.Since then the project had been completely inactive because we had no time to spend on it. So... this weekend, while I was doing some cleanup, I talked to him and decided to "officially" shut the project down. I put an announcement on the site's news telling that the project was discontinued and made the sources easily available (i.e., bypassing Monotone).However, the day after we put the announcement he regained interest in the project and started hacking on the sources again. So far he has uploaded them to the Subversion repository and made some new changes. I don't know if he will have much more time to work on it nowadays because the new semester at university has just started. But, if he does have time, we will probably see good results. I hope he'll keep us informed either through his blog or through the game's news page.From my side I do not have much interest in continuing developing Vigipac (the lack of DRI under NetBSD is one of the most important reasons) but I'll closely look at any changes.In the meanwhile, I'll continue working on my "secrets manager" and possibly publish it in the following days. It already has a name (which I reserve for the announcement), a test suite, a manual page and useful functionality (to me, that is). Stay tuned! [Continue reading]

  • Managing passwords and keys

    Once upon a time I used a single password everywhere except on few, few exceptions (my system account or SSH key, for example). After some time I realized that that wasn't very clever because a break-in in any of my online accounts could open them all for attack. Not to mention that this was also problematic due to different sites having different password policies and having different trust levels: you surely do not want to share the same password between your mailing list subscriptions — which very often travels in plain text form — and your GPG passphrase!Since then I have been using a unique complex password for each account... which has turned up to be a more-or-less unmanageable approach given the number of accounts I have. To make this approach less painful, I wrote all the passwords in a GPG-ciphered text file. I then created a pair of dirty scripts to view and edit that safe file, but I have to confess that they are very ugly and are currently broken for a number of reasons. Also, keeping that file on the hard disk was not something I was very keen on; yes, I have a backup, but it is sooo outdated...However, using such simple ciphered file has its advantages. I can trivially access it from any OS, I do not rely on any password manager utility and I do not need to trust its code to not disclose information. So what have I done?I've created a little shell script that allows me to consult and modify the passwords database easily; yes, simply put, it is "yet another password manager". However, and as I wouldn't like at all to lose my private SSH/GPG keys, the "secret" database also serves as a repository for these keys.The idea is to keep all this critical, non-recoverable data in a central place, making backups trivial. For example, I'm planning to stick the script alongside with this sensible data in a little pen drive (or floppy disk) so that it can be stored in a safe place. This way, I will not have that data in the hard disk: it will only be available when I really need it by plugging the pen drive and simply executing the script within it.Consider the following:$ mount /safestore$ /safestore/safestore query some-site... enter your GPG passphrase ...... your user-name/password is shown ...$ unmount /safestoreThe above commands could be used to request the user-name and password for some-site.Or this (assuming the disk is already mounted):$ /safestore/safestore syncWhich could synchronize the GPG database in the home directory with the one in the external drive.And what about creating a SSH key and installing it on your home directory?$ /safestore/safestore ssh-keygen... answer some questions ...$ /safestore/safestore ssh-keyinstall key-nameOf course, losing that pen drive could be a very serious issue... but you already have a backup copy of your keys somewhere, right? Also, if the GPG key has a strong passphrase and considering that someone had interest to crack it, you'd have enough time to regenerate your keys, revoke the old ones and update your passwords before he'd get any data out of the ciphered drive.I'm curious to know how people manages this stuff themselves. At the moment I am not planning to publish the script because it is very customized to my needs but I may easily change my mind if there is interest in it. [Continue reading]

  • C++ code in the kernel

    I have always been fond of the idea of having an operating system kernel written entirely in C++ so that it had a clean class hierarchy, exception-based error control, etc. I know this is very difficult to achieve due to the inherent complexity of C++ and its runtime, but not impossible if appropriate care is taken.C++ for Kernel Mode Drivers is an article I just found that talks about using C++ in driver code for the Windows OS. It explains in great detail why using C++ is difficult and discouraged in such scenario. Without paying much attention to Windows-specific details, it is a good read no matter which OS you develop for. [Continue reading]

  • FAT versions

    FAT12, FAT16 and FAT32 are all different versions of the FAT file system. As far as I know, the FAT was originally designed to work on floppy disks, on which it does a decent job. Soon after, it was adapted to work on hard disks (bigger capacity) and hence FAT16 was born. Much later, and due to the introduction of bigger disks — which means something over 500MB — FAT32 was created.In order to understand what the number attached to the name means, we first need to outline how FAT internally works. FAT divides the disk area targetted to user data into clusters; you can imagine this area as a linear succession of sectors. A cluster is then defined as the agrupation of a set of consecutive sectors and is the minimum addressable block by FAT.Each of these cluster is identified by a number; let's call this number the CID (Cluster IDentifier) for the scope of this post. This obviously drives us to the question: how big can the CID be? Well, it depends on the FAT version. This is exactly what the number after the name specifies: the number of bits reserved to address the CIDs.If we do some numbers, FAT12 can have a maximum of 212 = 4096 clusters, more than enough for a floppy disk in which a cluster is a single sector. Now consider a 100MB disk; if we used FAT12 on such a disk, each cluster could be 100MB/4096 = 25KB long approximately, which introduces a lot of fragmentation for small files (think about the average file size when 100MB disks were considered big). But not only that: 12 bits, or 3 bytes, is an odd number to do arithmetic manipulations in a 16-bit computer (the 8086), introducing a computation penalty on every I/O operation. Hence, FAT16 was born, providing 16 bits to addess CIDs.The birth of FAT32 is similar to the FAT16's one. With bigger disks appearing between 1995 and 2000, 216 = 65536 clusters were not enough to address them in a fine-grained fashion: few clusters introduced way too much fragmentation. For example, a 4GB disk could gave 4GB/65536 = 64KB long clusters, a number that drives to a lot of wasted space. FAT32 was therefore created, which increasing the CID address space to 32 bits. FAT32 also introduced some improvements to the file system such as the ability to place the FATs and the root directory anywhere on the file system (not restricted to the beginning).To sum it up, there is the Long File Name (LFN) extension. This was introduced with Windows 95 and extends the traditional FAT file system so as to allow 255-character long file names preserving the compatibility with the 8.3 naming scheme.For more information check out the Wikipedia's FAT article. [Continue reading]

  • Samba performance under Mac OS X

    I have a NetBSD/i386 3.0 file server at home running Samba 3.x. Read and write access from NetBSD and Windows XP clients is fast (although, under the NetBSD clients, NFS performance wins).Unfortunately, reading large files from Mac OS X is incredibly slow. Adding the following to /etc/sysctl.conf solves this annoying problem:net.inet.tcp.delayed_ack=0This configuration file does not exist in a default installation so simply create it from scratch. rc(8) takes care of it automatically. [Continue reading]

  • Calling the BIOS from within the kernel

    NetBSD/i386's bioscall(9) trampoline is one of those interesting and tricky things you come across from time to time when reading kernel code. This apparently simple kernel function lets the caller execute BIOS functions and retrieve their results.The BIOS (Basic Input/Output System) is the PCs "firmware". It initializes the hardware, starts the boot process (in a primitive way) and provides a set of utility functions in the form of software interrupts. These interrupts can be used by applications to do tasks such as reading disk sectors, gathering information about the hardware or switching the video mode, among many other things. This "library" is what concerns us now.x86 processors start their operation in real mode (MMU-less, 16-bit addressing) for compatibility reasons with the 8086. As the BIOS contains the very first code executed by the system, it has to be callable from real mode. The BIOS cannot either switch to protected mode due to compatibility reasons again: all the boot code is real mode code (not to mention some legacy OSes such as DOS). This means that all the functions it offers to applications were designed to be called from real mode and with 16-bit addressing. (N.B. I'm not sure if this is completely true; the BIOS could provide 32-bit functions to be executed in protected mode, but anyway this is not what we are interested in now.)Sometimes, these functions can be a very useful resource for the operating system, specially before it has set up its own device drivers. But... virtually all OS kernels now work in protected mode with 32-bit addressing. In such configuration, it's impossible to call real mode code because of its 16-bit addressing and its direct access to the hardware.So is it impossible to use those functions once the kernel has started? Of course not. But only if the kernel has not thrashed important memory regions nor put the hardware in an unknown status to the BIOS. (That is, the subset of available operations once the switch has happened is quite limited.)Assuming everything is OK, the kernel can switch back to real mode (non-trivial), issue the call to the BIOS function, grab the results, return to protected mode and feed those results (if any) to the caller. And you guessed right, this is what bioscall(9) does in an automated way. The manual page contains some more details and sample codes.By the way, the EFI (Extensible Firmware Interface) is Intel's replacement for the BIOS. All these compatibility issues should be gone, something that is certainly good to make the i386 platform better and free it from obsolete design issues. [Continue reading]

  • Toying with KDE

    Some days ago I was "forced" to remove all packages in my workstation due to massive revision bumps in pkgsrc. Since I had to install an environment for X, I decided to give KDE 3.5.1 a try.The thing is that I hadn't used KDE seriously since I switched to GNOME 2.6 (ouch, that was two years ago... time passes really fast). Of course I installed it several times in this period and tried to use it, but I stopped the evaluation after a 5-minute ride. I didn't feel comfortable because I wasn't used to it and, to make things "worse", I could quickly escape to GNOME as it was installed alongside it, ready to be used again.But... you know what? I'm discovering some impressive things in KDE. Overall, I like it very much, up to the point of maybe not switching back (with the exception of Mac OS X on the laptop, that is.) Let's see some of the things I've "discovered":The audiocd kioslave: kioslaves are extensions for KDE's IO library, much like the methods for gnome-vfs. KDE has kioslaves for everything, but the audiocd one is impressive: it represents an audio CD as a virtual set of files in different formats, being OGG and MP3 among them. These files either represent a single track or the whole CD. Their names are guessed using the CDDB database. And you guessed right: ripping and encoding a CD is as easy as dragging and dropping those virtual files wherever you want!File properties: Right clicking on a file and choosing properties shows the standard settings tabs, but also shows some that are specific to that file type. I found this useful to correct the tags in the OGG files I had ripped. (I don't know if GNOME currently has this; couldn't tell for sure.)Consistency: Many typical options are in common places, no matter the application you are in. All common keybindings can be configured in a central place so that they affect all programs. OK, I know many GNOME utilities also have this integration in but this had to be mentioned.Konqueror: I wish it could use Gecko as its rendering widget (I think it can, but don't know how) because, unfortunately, KHTML fails to render correctly some pages I visit often. Anyway, it makes an excellent browser and a handy file manager. Its address bar supports many shortcuts to quickly access several search systems.K3B: At last, a decent CD and DVD burner for Unix systems. I know it has been around for a long while but it didn't work under NetBSD until very recently, so I couldn't use it.Amarok: Neat music player. It's visually attractive and easy to manage. I like the way it can be globally controlled with keybindings and how simple it is to fetch lyrics.Digikam: Good picture manager. Despite I tried an outdated version (0.7.0), it is still quite nice. Haven't had time to analyze it in detail yet, though.Almost everything works. Kudos to Mark Davies (markd@) for his excellent work in porting KDE to NetBSD.As a drawback, I still find KDE's interface too cluttered for my tastes. But I think I can live with this, specially because the interface can be simplified with some tuning effort. Not to mention that KDE 4 promises to be focused on usability... really looking forward to it! [Continue reading]

  • The RAII model

    Resource Acquisition Is Initialization (RAII) is a programming idiom that attempts to prevent the risk of leaking memory and other resources. It is only applicable to languages that have predictable object destroyment, and among these is C++ (an object's destroyer method is always called when it goes out of scope).The basic idea behind RAII is to wrap any resource subject to be leaked in a thin class. This class acquires the resource during its construction and releases it upon destroyment, thus hiding all the internal details from the user. This way, these resources are always released, no matter if the function has multiple exit points or throws an exception, because the destroyer will be automatically called for existing objects.If you have ever written C++ code, you have probably already used RAII without knowing it. In fact, I just learned today that this technique has a name, while I've been using it for a long time :-)I suggest you to read this article from Jon Hanna; it discusses this topic in great detail. [Continue reading]

  • SoC: Introductory article to tmpfs

    Dr. Dobb's Journal is running a set of mini-articles promoting Summer of Code projects. Next month's issue includes the tmpfs' introductory article, written by me and William Studenmund, the project's mentor.Looks like you have to register to access the full article; previous issues used to have them publically available. Personally, I'm going to wait for the printed version :-) [Continue reading]

  • Rewriting from scratch

    Let's face it. If you are a software developer, you have certainly felt some time that code developed by others was a real mess and that you could do a much better job rewriting it from scratch (specially without actually understanding the "messy" code in detail). Big mistake.I'm not going to explain here why because the Things You Should Never Do, Part I article from Joel on Software talks about this in great detail. Certainly worth to read. [Continue reading]

  • Automatic mouse button repeating

    The trackball I bought has two little buttons that replace the typical (and useful!) wheel. One (button 3) is used to scroll down and the other (button 4) to scroll up. These are the events that a wheel generally generates every time you move it in either direction.Unfortunately, if you press and hold one of these special buttons, the trackball only sends a single press event. So, if you want to scroll a document up or down, you have to repeatedly click buttons 4 and 3 respectively, which is highly annoying: you end up going to the scroll bar and using it rather than the two buttons.The Windows and Mac OS X drivers solve this by generating press and release events periodically for those buttons while they are pressed. This way, the application sees as if you had clicked them multiple times. Very comfortable.I didn't mention NetBSD in the previous paragraph because it doesn't support this feature. That is, it handles those buttons as two extra regular buttons (in fact, they are from the hardware's point of view). And no, neither Linux, XFree86 nor X.Org provide options to simulate the expected behavior as far as I can tell.So, what did I do? Add support to NetBSD's mouse driver (wsmouse) to simulate automatic button repeating. This way, I can use the trackball to its full power — hey, I got that model precisely because those two buttons!This new feature is customizable through a set of nodes exposed by wsconsctl(8), as seen below:# wsconsctl -m -a | grep repeatrepeat.buttons=3 4repeat.delay.first=200repeat.delay.decrement=25repeat.delay.minimum=50repeat.buttons indicates which buttons are subject to automatic event repeating. The other three variables indicate the delays used to control how often events are sent. Three are needed because they the feature supports acceleration. That is, the first time you click a button, it will take 200ms until the first repeated event is sent. The second event will be sent after 175ms; the third after 150ms and so on until the events are separated 50ms each other (the minimum). Useful to scroll large documents. [Continue reading]

  • NetBSD is now Multiboot-compliant

    Since there were no comments after my request for review for the patch that makes NetBSD be Multiboot-compliant, I have commited it to the tree. This feature is enabled as a default on i386's GENERIC and GENERIC_LAPTOP kernels; for others, you need to add options MULTIBOOT to their configuration file.Please note that regular GRUB builds will not boot these new kernels properly. This is because of a bug in GRUB Legacy. You either need to install grub-0.97nb4 from pkgsrc or manually apply this patch to the GRUB sources.See multiboot(8) for more information.Edit (Feb 6th, 21:06): Some typos fixed based on comments from Reinhard von der Lippe. Does anyone remember seeing this happening (the post update) a couple of days ago? If you use an aggregator, you should have seen an update to the post that looked very similar to this. (More details on the comments.) [Continue reading]

  • Got the trackball

    A couple of days ago I received the Logitech Marble Mouse I had ordered, which means that I've now got the perfect input devices :-) [Continue reading]