playing with the idea of splitting files, mapping their tree structure to the filesystem, I came to the conclusion that the opposite of the pattern could be more than useful: aggregate filesystem.

What and Why? Just simply imagine a large project with hundreds of files, where you would have to do a huge huge huge huge refactoring that would affect more than 50% of files. (renaming for example). Opening each file is out of question. You could write some sed scripts to do the job. But why? Why you would not be able to open all the files in vi or you favourite editor, first do some analysis by searching for occurrences, then mass replace, etc, etc.

The aggregate filesystem should have some configuration file that would define what is aggregated by listing the files or defining rules (regular expressions for example, globing) about what kind of files to be included (for example all files under a directory). You would end up with a huge file that would be composed by all the files (in random order). End of files of each original file would be marked with a special line, I will call it pivot line. These pivot lines would unambiguously identify the end of file. Removing such a line would mean that the content would flow to the file that follows. The pivot line would also contain the full path of the original file.

When you open an aggregate file and start to read it the aggregate fs would open all the aggregated files (or eventually define other strategies). If you would read the file, the aggregate fs would read one by one all the aggregated files. When saving an aggregated file, the aggregate fs would save each part of the content to the original file indicated by the pivot line.

Such pivot line would also help to create commands inside your editor that would have eventually affect on the original file. For example open the original file.

Such a filesystem could be implemented both in kernel and userspace with fuse.

I am doing some proof of concept for a virtual filesystem extension. I wrote the following

email to the linux filesystem mailing list.

Hello mailing list members,

I am not sure about the best name, but I am sure it is sthg. very usefull. So I will call it mobifs, hope you do not mind I am also not sure if there is sthg. like that out there, but based on my 15 years of linux experience I never met sthg. like what I would like to talk about.
What I would like to have on my linux boxes is to access data the following way:

#>cat /dev/sda1@/partition1/etc/inittab@/defaultranlevel #usecase 0

#>cat /data/xmlfiles/apsettings.xml@xml/main/entry1/subentry/value #usecase 1

#>cat /data/xmlfiles/apsettings.xml@/main/entry1/subentry/value #note @ instead of @xml #usecase 2
#>cat /data/images/linux.img/@/partition1/etc/dhcpd/dhcpd.conf@group/next-server#note twice the @  #usecase 3

Linux kernel has powerful features, however sometimes it can be disappointing when you discover that trivial details do not work or do not work the very obvious way. Such an example is the loop back device. You may mount a file as a loop back device, but you cannot access its partition as “sub-devices” like it happens with the physical discs. There are workarounds by mounting the partition knowing the start and length of it, but that might be a bit risky.

In the isync-1.0.4/src/drv_maildir.c file, around line 368 there is a flock followed by fcntl call. It seems that the second call is blocking if the maildir is on a NFS mounted folder.

I undefined the LEGACY_FLOCK macro, so now there is call anly to fcntl. This should do correct locking on modern linux kernels. There is no deadlock now, however did not test concurrent access.

Some of are asking often the “W” questions about Linux Desktop. What, Why, Where, When the Linux Desktop “is like that”, “evolved like that”, “is the future” etc.

Still bit bothered that the Linux phone project, reincarnated last time in the Neo Freerunner device, did not manage to provide a faster phone. There were hardware decisions that cannot be fixed in the already sold devices, however the software can still change.  One of the questionable decisions was to use the Xwindows infrastructure for the GUI. The most important argument was the existing collection of X software. This is in contradiction however with the fact that most of the phone applications were written from scratch. There are several other distros that do not have GUI relying on X windows, like QtMoko or Android. QtMoko (on top of QT libraries) seems to be fast, but still, applications are loading slow, as the Qt c++ libraries are fat and the bandwith from SD card to internal memory is very narrow (1MB/sec !).

If you have high bandwith, you do not bother, but when still on small phones, you come to the conclusion that it is rather funny that just showing 1/2/3/4 screens, for phone, for an agenda, for configuration etc. with some buttons it takes seconds. It was much faster on a 66Mhz computer ages ago…

I was looking for alternatives like directfb (http://directfb.org), dinX (http://dinx.sourceforge.net/), fbui (http://fbui.tk/), microwindows (http://www.microwindows.org), ggi (http://www.ggi-project.org/). It seems that all these projects started with lot of enthusiasm, but unfortunatelly due to lack of marketing power, they faild to come into the mainstream.

One of the problems to have different gui stacks is that they try to access the graphics hardware to do their job. This means that others will not have tha chance to output.

Furtunatelly, it seems that there are projects that try to solve this sharing problem:

• kgi (http://www.kgi-project.org/)
• drm http://dri.freedesktop.org/wiki/DRM

I am excited about the idea to create a WINE like compatibility layer, eventually port WINE in order to be able to run windows mobile applications on windows. To make things even faster, I would build the GUI abstraction on top of kernel fbui. I think running fbui does not exclude running xwindows on the top of the same framebuffer, as long as they share it well…

(cont of http://www.mobiphil.com/wp-admin/post.php?action=edit&post=116)

Finally I could see a linux kernel booting on my eten glofiish m800. It was not my work, I downloaded the kernel from http://build.shr-project.org/shr-unstable/images/eten-m800/ and booted with haret-0.5.2

You may find further instructions on http://gnufiish.org/trac/wiki/GettingStarted

I tried the filesystem at http://build.shr-project.org/shr-unstable/images/eten-m800/shr-shr-lite-image-glibc-ipk–20090602-eten-m800.rootfs.tar.gz by

$ cd /media/card
$ sudo tar xvjf /path/to/image

unfortunatelly did not start anything. The last message on the console was sthg. like “Press enter to “…

It is slow, but I found out the reason… However in order to avoid this slowness, I will must not use an important feature of the operating system.

Since the upgrade to 9.04, I noticed that the hard disk led was blinking long minutes. Updating software took long minutes, however downloading was quit fast. Tried to investigate with atop, tried to kill processes that appeared to access the hard disk etc. No real improvement. Often the system seemed to be freezing…

But after investigating few hours, the unexpected result came out. It was difficult to find the cause because the bad was not always happening. And finally I remarked that the difference was between rebooting and restarting from suspend! And the hdparm test hast confirmed it:

sudo hdparm -tT /dev/sda
/dev/sda:
Timing cached reads:   1978 MB in  2.00 seconds = 988.92 MB/sec
Timing buffered disk reads:  162 MB in  3.08 seconds =  52.64 MB/sec
misi@kaktusz:~$ sudo hdparm -tT /dev/sda

/dev/sda:
Timing cached reads:   1072 MB in  2.00 seconds = 536.09 MB/sec
Timing buffered disk reads:    4 MB in  5.50 seconds = 744.96 kB/sec

The funny thing is that the rest of the hard disks were behaving normally after suspend, so only the root filesystems hard disk was the evil…

So… is this a bug in kernel (2.6.28-11-generic)?

Anyway, for me the solution is to avoid suspend, shut down, and boot when needed, but wait 50000 seconds for boot

description page on http://gnufiish.org/trac/wiki/GettingStarted

Well, I knew few days after I bought openmoko that it was the worst investment in my life I am sad to read on Herald Welte’s, Slashdot, H-online that the project is half over. Well it is unclear what is the state as all the news information say different things. There is an email exchange between some of the guys involved in the project, but it is unclear what the project B means. I am confident that the project will survive!