I just made public under the terms of the GPLv3 a couple of old university projects hoping they will damn help someone. Here they are: ufs (micro file system, a fat-alike user space file system with some unix extensions) and Vespasiano (small movie theater manager, done when learning sockets in Java).
Please note that they both are so bugged to be broken. Be careful :-).
What is this cool drooling puppy doing on my blog? His name is Cerberus, he came from Greek mithology and he is nothing less than the guardian of the gate to Hades, also known as Hell.
No, I haven’t joined satanism, this is just a mascotte, the mascotte for a new project I’ve been thinking on lately: a Debian based Linux distribution specialized on video surveillace, its name will obviously be Cerberus :-).
Why am I building another Linux distribution? Well, the answer is very simple: in the last two years I’ve been selling video surveillance systems build on top of Debian or Ubuntu with Motion and Vigilante. Assembling such systems requires to repeat each time a set of very specific steps such as installing the distribution with the needed packages, configuring the modprobe options for driver of the video capture card (often based on the bt878 chip), setup Motion and Vigilante, linking it all together on the user’s desktop. Most of these actions (excluding hardware probing/configuration) could be automatized, or better, saved prebuild in a proper environment.
This is where Cerberus Linux enters the game: it is meant to act like firmwares on embedded Linux devices, a main read-only partition containing the distribution with a small overlay read-write (freezable to read-only) partition containing the configuration files.
Why am I following the “embedded-firmware”-like way in place of a more common standard installation? First reason is robustness: making the system read-only prevents damage to the file system when doing hard resets (which are very common on this kind of systems, often seen as vhs recorders or table dvd players by the inexperienced users who will use them). Second reason is easy of use: you can (re)install and update the base system by rewriting the partition without caring about backups or installation process, is it just a call to dd, automatizable. Third reason: users are idiots, give them a writeable home and they will find a way to mess up the entire system, give them a writeable root file system and they will bring back the system as an ash heap claiming you sold them a broken thing.
So the roadmap so far is to build the distribution with the listed features, put a new Vigilante (based on Cluttermm/Gstreamermm) on it and maybe develop a remote web configuration system (maybe with ExtJS and Rails or Zend Framework or Webtoolkit).
Of course if you have any advice or proposal for Cerberus please contact me, any good idea will be welcomed.
One of the first problem occurred when developing the specialized video surveillance Linux distribution I’ve been working on these days is the database engine to be used to archive the list of recording files saved by Motion. As every write operation will be placed on a read-write file system layer on top of the main read-only layer (containing the whole “monolithic” distribution, something like the firmware on an embedded device) I have the need to store the whole database data in a compact manner, something like only one file and not similar to the /var/lib/mysql/ directory with its many entries.
The problem with this is that Motion only supported MySQL and PostgreSQL so I had to add the SQLite layer by myself. As a result I have published a patch on the Motion’s wiki, test it please :-).
Maybe you didn’t notice but AMD is now pushing the OpenCL standard. This is a really great news, the first step to a common GPGPU technology: who on Earth would want force himself to write the same program for three different architectures ?
Let’s face it: when a Linux user wants to chill out for a little bit and play for a few minutes there is a good chance that the game he likes doesn’t like Linux at all. There is a very small number of commercial games working natively on Linux and making other Windows games run on top of Wine or Cedega isn’t straightforward everytime (especially if you try to run new games) so unless you really like FPSes like Quake, Unreal Tournament (up to the 2004 version) or the free Nexuiz or some other small game like SuperTux or TuxRacer you would probably want to try something else.
Before VMware Workstation 6.5 there were only two ways to do this: a gaming console or a dual boot with both Linux and Windows. Buying a console is too much for someone like me who doesn’t play more than 3 hours in a month and rebooting could really piss you off as it forces you to reset your working environment (unless you configure something like suspension to disk, but that’s quite another story).
This is where the new VMware come into play as it has a really working DirectX accelerated virtualization layer, I download and tested the version 6.5.0 build-110068 and found it to be quite stable on my computer with an NVIDIA 9600GT, an Intel Core2 Quad Q6600 clocked at 3.0Ghz and 2GB of RAM.
Of course don’t expect to get native hardware performances but the results are actually above my expectations, the major bottleneck is the low amount of RAM assigned to the virtual machine: please note that with only my 2GB I had to run my host operating system (x86_64 Debian Sid) and VMware itselft (which uses RAM other than the one assigned to the virtual machine) so in the end I was unable to assign more than 900MB to the guest Windows XP. This is the main reason behind the bad performances that you will see on the Unreal Tournament 3 test video, if you look carefully you will notice that it runs smoothly in complex scenes and then it suddently freezes: that’s where it has to swap data because of the low amount of RAM.
So, here we go, here the interesting part is…
OGRE 3D demos:
Unreal Tournament 3 (keep in mind the low RAM thing explained above):
Various screenshot in this gallery:
If you liked it why don’t digg it?