Most of the flash devices assume that fat is the only file-system. And there are plenty of electronic devices that run linux on fat. So just to know what it is to run linux on vfat, I tried it myself.
The openSUSE 11.1 installer wont allow you to partition the root as vfat. So I made 2 partitions, one ext3 and one vfat. Installed on ext3. Copied the whole partition to fat. I copied original files in place of symbolic links. Added vfat filesystem module to initrd . Modified grub boot from the fat partition with init=/bin/bash.
FAT's lack of support for posix file-permissions. was easy to overcome by mounting with all permissions to everyone, without users or noexec. It doesn't support symlinks, and special files. mknod will fail. But /dev is a tmpfs and it just copies the persistent files from /dev to the tmpfs on boot, instead of copying I created fresh device files in tmpfs. `mount` failed trying lock the file /etc/mtab. Mounting with -n worked. I guess plenty of things would fail if I try to run a proper desktop on FAT as it is.
I booted only to /bin/bash. When I tried doing a "exec init 1", it complained something like cannot remove /var/run/do_confirm. I didn't proceed further. This was a fun way to kill time while getting some insight of the booting process.
10 March 2009
03 March 2009
Perceived Code-base quality
Recently one of my friend was re-orged from a open-source product to a proprietary project. He was complaining about the quality of the code-base, especially about using hard-coded paths and the likes.
I have also worked on different code-bases of different quality. And I feel that not being very confident about the quality helps at times. For example, say if you work on Linux Kernel and believe that the kernel code is of highest quality. When a bug is filed, you won't be confident of finding the bug in the kernel code. So one would look elsewhere like the setup or other layers or the application or wont even trust the bug-submitter.
Wouldn't a bug-hunter be happy and confident if he believes that there are lots of bugs in the code-forest to be hunted. But at the same time, if one is planning to do agriculture(more code changes, features, clean-ups etc...) in the same code-forest, one would be worried that his crops may be destroyed by some of those bugs lurking out there. But a software engineer should be a farmer who enjoys hunting as well.
Farmer + Hunter+... == Software Engineer. Happy code farming^Wcoding and bug-hunting.
p.s: Yes it is easy to hunt that single bug if the code-base is clean. But a bad code-base could be a nightmare for the hunter. He would be hunting various other bugs in search of one. But don't you like the thrill?
I have also worked on different code-bases of different quality. And I feel that not being very confident about the quality helps at times. For example, say if you work on Linux Kernel and believe that the kernel code is of highest quality. When a bug is filed, you won't be confident of finding the bug in the kernel code. So one would look elsewhere like the setup or other layers or the application or wont even trust the bug-submitter.
Wouldn't a bug-hunter be happy and confident if he believes that there are lots of bugs in the code-forest to be hunted. But at the same time, if one is planning to do agriculture(more code changes, features, clean-ups etc...) in the same code-forest, one would be worried that his crops may be destroyed by some of those bugs lurking out there. But a software engineer should be a farmer who enjoys hunting as well.
Farmer + Hunter+... == Software Engineer. Happy code farming^Wcoding and bug-hunting.
p.s: Yes it is easy to hunt that single bug if the code-base is clean. But a bad code-base could be a nightmare for the hunter. He would be hunting various other bugs in search of one. But don't you like the thrill?
Subscribe to:
Posts (Atom)