Pieter was the Wikidot front-man for its community and organized good workflow for many community and internal projects. We learned how to talk to the community, how to solve problems and how to concentrate on important things. And we're going to keep being good at it.

With the addition of data forms Wikidot becomes one of the most interesting wiki platfarms (platform + farm) on the Earth. Using ListPages, _templates and forms we allow (almost) regular folks to create applications like CMS for their co-workers, clients or friends. Things usually done by programmers are now available for smart guys without need to find proper hosting, web framework or writing a line of computer code.

What I find most interesting in building applications on Wikidot is that the platform itself is quite bullet-proof. I mean when you forget to put semicolon at the end of some line, you don't get your application crashing because of syntax error. Moreover when making application you get storage with history and e-mail notifications about changes for free, which makes your data quite safe. In case someone destroys your site (which you are informed by e-mail), you can just revert the right version).

But Wikidot applications is not the most important thing Wikidot is used for. Many sites on Wikidot are just plain wiki sites with links to store and share knowledge of certain groups. They don't use advanced features like modules, includes, templates. They usually edit and save :-) from time to time uploading some file or image. What we want to do is to review all common operations people do most often and (really really) simplify them. Sophisticated applications are worth nothing if basic usage of service is not easy.

We want to introduce features people will appreciate, like [[html]] blocks for embedding completely custom HTML, like this:

 [[html]] <h1>Custom HTML</h1> <p>Something else</p> <img src="anything.png" alt="hello ;-)"/> [[/html]] 

This code will just inject the HTML (including JavaScript) into the page in that place. Seems easy to do, but in fact, to make it safe for your site, we needed to implement this as a frame, that autoresizes to keep the content fit inside.

We also want to introduce [[block]] syntax for sandboxing wiki texts, for example:

 [[block]] What put inside is parsed and rendered independently, so even if you put some random [[/div]]s or other nasty things, the page outside will be rendered nicely. [[/block]] 

This will be useful for site designers to use in template pages, like this:

 [[table]] [[row]] [[cell]] [[block]] %%content%% [[/block]] [[/cell]] [[cell]] some other things. [[/cell]] [[/row]] [[/table]] 

Putting %%content%% in block tags you make sure user won't break the original layout (the table). Without block, user could put [[/cell]] inside of his text and thus break the layout.

To let our users know what happens on their sites, we want to make live feeds of activity available for most common start-places on the web — iGoogle, NetVibes, Facebook and Twitter. Most important news from YOUR sites will be next to other things you start your day from.

We have a bunch of other fresh ideas, which we'll be sharing on blog.wikidot.com.

by Gabrys

 $ xmodmap - remove Lock = Caps_Lock keycode 0x42 = Tab <hit Ctrl-D now> 

This works till you logout. If it does work, you can make this persistent by adding those two lines to your empty or missing ~/.Xmodmap file:

 remove Lock = Caps_Lock keycode 0x42 = Tab 

If this doesn't work for you, it's possible your window manager doesn't take care of this file, but if you have a way to execute commands at each start of GNOME/KDE/whatever, just add the following command to those run it startup sequence:

 xmodmap ~/.Xmodmap 

by Gabrys

Oto wynik:

Poza tym co widać, zmiany dotyczą użytego fonta, wyglądu komentarzy i forum, uproszczenia okienka nowego komentarza, ustalenia pozycji tła (żeby przewijanie przewijało samą treść, a nie tło) i dodanie lekkiego prześwitywania tła, żeby było bardziej sexy.

Temat jest hostowany pod adresem: http://themes.wikidot.com/orange-black-improved.

A wszystko po to, żeby nadać naszej nowej stronce: http://parapetowa.wikidot.com/ ładnego wyglądu. A na stronce oprócz informacji co można nam kupić z okazji zbliżającej się parapetówy (jeszcze dokładnie nie wiadomo kiedy) uruchomiliśmy też bloga, gdzie pisać będziemy (a przynajmniej ja) o trudzie przystosowania mieszkania do wymagających lokatorów (czyli nas). Link do bloga:

http://parapetowa.wikidot.com/blog

Serdecznie zapraszamy!

by Gabrys

Przede wszystkim, z rana czytając o ostatnio modnej ustawie anty-hazardowej, zauważyłem, że nie tylko hazard (a i to nie wiem po jaką cholerę) próbuje ona ukrócić. Komentarze pod wpisem na blogu vagla.pl zdają się sugerować, że propozycja ustawy jest niezgodna z Konstytucją, regulacjami Unii Europejskiej i Kartą Praw Człowieka, a wszystko przez to, że nakazuje dostawcom internetu blokować ustalane odgórnie strony internetowe. Centralnym miejscem będzie specjalny Rejestr, do którego będą dopisywane strony o wymienionym w propozycji ustawy charakterze. Dopisywanie ma się odbywać na żądanie kilku organów państwa, a egzekucja tego żądania ma się odbywać natychmiastowo. Dostawcy internetu będą musieli blokować strony z tego rejestru swoim klientom.

Zapraszam do przeczytania komentarzy (zarówno prawników, "techników" jak i nietechnicznych, ale zdrowo myślących ludzi) pod następującym adresem:

http://prawo.vagla.pl/node/8752

Komentarze przedstawiają wątpliwości natury technicznej (techniki blokowania będą albo nieskuteczne albo bardzo drogie) jak i prawnej. Znajdziemy również sugestię, że ten rejestr stanie się pierwszym źródłem informacji wśród szukających w Internecie pornografii dziecięcej.

Pomijając jednak te "drobne" aspekty, sprawę należy postawić zupełnie inaczej. Czy uprawnione jest w ogóle myślenie o tym, żeby blokować dostęp do części internetu ludziom przybywającym na terenie Polski? Czy zamiast dodawać mechanizmy mające niby uchronić Polaków przed naciągaczami i pedofilami, nie powinniśmy poprawić tych mechanizmów, które już istnieją? Moim zdaniem zamiast żądać dodania strony do Rejestru, odpowiedni urząd powinien złożyć doniesienie o popełnieniu przestępstwa i zostawić prokuraturze i sądom szybkie załatwienie tej sprawy (włącznie z żądaniem zdjęcia jej z sieci). Prokuratura i sądy działają za wolno? No właśnie to jest problem, który należy rozwiązać zamiast zajmować się jakimiś głupimi pomysłami blokowania Internetu!

Inny komentator podaje również jako problem wymuszenie stosowania takiego rejestru. O ile rejestry SPAM-u, malware'u i innych nieporządnych stron internetowych (wliczając w to zawierające "nielegalną" pornografię, np. dziecięcą) istnieją, ich używanie jest zupełnie dobrowolne. Jeśli dbam o swoje bezpieczeństwo w sieci, mogę takiego filtra użyć, będąc świadomym, że może mi to ograniczyć dostęp do niektórych serwisów (do których mogę się dostać "omijając" filtr na własne życzenie). Propozycja ustawy jest bezlitosna, dostawcy internetu mają blokować pod rygorem kary pieniężnej.

Chwila rozrywki

Korzystając z chwilowego braku cenzury w Internecie chciałbym podzielić się filmikiem zaczerpniętym ze strony failblog.org, która prezentuje wypadek rowerzysty.

UWAGA: TREŚĆ DRASTYCZNA (chociaż wydaje mi się, że uczestnik wypadku nie odniósł dużych obrażeń)

I jeszcze jedno, a co!

I jeszcze powiększanie biustu po chińsku (trzeba przyznać, że bardzo pomysłowe, od razu przypomniał mi się Abracada Bra Mossa z IT Crowd):

by Gabrys

But from time to time you just simply rm -Rf ~ and your all precious data is totally out of luck. Backups you say, don't you?

So let's think how do you do backups. cp /home/quake /my/distant/location ? On my 24 GB home directory? It would take hours. cp /home/quake /home/backups/quake/date ? Better, this will take a few minutes, but wait, I have like 120 GB of disk space, which means I can have no more than 5 backups.

What to do with this? There are two posibilities. Either you minimize data to backup to only backup important data (but figuring out what data is important may take some time and be inappropriate) or move to smarter solution, like incremental backups. Or snapshots.

Having brtfs as the filesystem for my home directory, I chose to make a snapshot of it each hour. It takes between 0 and 1 second to complete and uses almost no disk space. Why? Btrfs is copy-on-write filesystems, which means cloning a filesystems is instant as it only makes it available under two locations. And then modifying one of the two makes a real copy of the modified fragment of it and changes that copy.

OK. How to do it.

First create a btrfs filesystem (you'll need a recent kernel and btrfs-utils):

 # mkfs.btrfs /dev/sda7 

(sda7 is partition for my /home directory)

Then mount it somewhere else than /home, let's use /vol as an example:

 # mount /dev/sda7 /vol 

Create some volumes on that filesystem: home, quake, snapshots:

 # btrfsctl -S home /vol # btrfsctl -S quake /vol # btrfsctl -S snapshots /vol 

The volumes are accessible as the subdirectories of /vol:

 # ls -la /vol drwx------ 1 root root 36 1970-01-01 01:00 . drwxr-xr-x 24 root root 4096 2009-10-25 15:04 .. drwx------ 1 root root 20 2009-10-25 15:51 home drwx------ 1 root root 11488 2009-10-25 16:17 quake drwx------ 1 root root 76 2009-10-25 15:40 snapshots 

But you can mount then separately:

 # mount /dev/sda7 /home -o subvolume=home # mkdir /home/quake # mount /dev/sda7 /home/quake -o subvolume=quake 

Fix permissions:

 # chown quake:quake /home/quake /vol/quake /vol/snapshots # chmod 0755 /home/ /home/quake 

Now you're ready to do snapshots. Now populate the /home/quake directory:

 $ mkdir /home/quake/abcd $ mkdir /home/quake/dddd $ mkdir /home/quake/abcd/eeee $ echo testtest > /home/quake/testfile 

Aaaaaand, make snapshots!

 $ btrfs -s /vol/snapshots/quake-`date +%Y%m%d-%H%M` /vol/quake 

I figured out, that it's quite important to point to /vol/quake and not /home/quake. At first it seams that it's totally the same, but on /home/quake there can be some other filesystems mounted (like .gvfs for GNOME virtual file systems) and /vol/quake contains "pure data". When doing snapshots of /home/quake with filesystems mounted under it, the filesystems freezes for me (btrfs is still experimental, they say). So as noted above, it's better to snapshot pure data directory.

Now, the /vol/snapshots/quake-20091025-1653 (or whatever your date is) and /vol/quake should list the same files and the operation of "cloning" should be just instant no matter how much data you have. But now modifying the contents of /vol/quake should not change anything in /vol/snapshots/quake-20091025-1653 (but of course should in /home/quake).

Also the snapshot doesn't really take any disk space as long as you keep the /vol/quake directory unchanged. Once you change some file from /vol/quake, it needs to really keep two copies of it, so this is when additional space is allocated.

To sum up let's have a table listing possibilities to have the same contents in two directories:

More notes on btrfs and snapshotting:

• What can be done with btrfs-bcp on directories level can be done with snapshots on volumes level (as described in this post)
• Snapshots in btrfs are not removable yet. You can clear them and reclaim the space taken by saved difference from the starting point. Still a few bytes is taken by having the directory that is not removable. Deleting snapshots is to be implemented in stable version of btrfs.

by Gabrys

Po pierwsze obiecałem, że napiszę coś na blogasku, jeśli będzie mi się dzisiaj podobać.

Po drugie, muszę oddać hołd mojemu dziewczęciu — Marcie.

Marto, jesteś bardzo dobrze przewidującą osobą. Przewidziałaś dwa wydarzenia w Californication (na dwa strzały — 100% skuteczności).

Poza tym, lepiej znasz kolekcję moich płyt niż ja. Tak, mam w niej płytę Rapid Eye Movement naszego kochanego Riverside'u.

Cieszę się, że jesteśmy razem.

by Gabrys

Introduction

I wanted to benchmark the following filesystems:

• ext2, ext3
• ext4
• xfs
• reiserfs, reiser4
• nilfs
• btrfs
• zfs (via fuse)

NILFS2 haven't managed to even finish the Bonnie++ test. This means this filesystem is not yet ready to use (but promises very nice features). Other filesystem that has not been benchmarked is reiser4, because the Ubuntu kernel doesn't have support for it. I would need to patch it and I wasn't happy about it.

Images shown here show results of the standard Bonnie++ tests. Command to do them was:

 bonnie -d /dir/on/ssd/partition -n 200:200 

The -n parameter was tuned so that for each test some values were returned. With default setting I got many values "++++" indicating test was performed so fast, that Bonnie++ was not able to calculate the performance.

Explanation of test names can be found in bonnie++ documentation.

Before each test, filesystem was created on the prepared partition (25 GB) and some (the same for each test) data was copied to it (about 10 GB) to simulate "used" filesystem.

As it appeared I was not able to disable write-caching with running hdparm -W0 /dev/sda. Instead it stated

 /dev/sda: setting drive write-caching to 0 (off) write-caching = 1 (on) 

Possible write-caching is good thing though (and by default enabled), so I have no problem with that.

All tests were run twice, but the results was nearly the same, so I just removed the second results for each filesystem.

For each test, bigger is better with value being thousands operations per second.

The best filesystem

As some suggest, the preferred I/O-scheduler for SSD disk is "noop", which means there's no IO scheduling in kernel, so we rely on scheduling logic in the hardware (which for various reasons is believed to be good in SSD disks) and profit from no software overhead of queuing.

Let's then compare how well filesystems perform with this scheduler chosen:

This benchmark was performed for all filesystems but NILFS2 and reiser4.

Random seeks

When it comes to random seeks (very important for low-latency systems), the best is ext4 with reiserfs and xfs having almost the same result. Btrfs is next (10% slower), then ext3, ext2 and zfs at the end being 6 time worse than the best.

Creation and deletion of files

Ext4 is the fastest in creating files (both sequentially and randomly) while btrfs is the fastest in deleting files, which small exception of ext2 being 7 times faster than everything in sequentially deleting files. On the other hand it's ability to delete files in random fashion is pretty bad. Comparing only btrfs and ext4, both are fast, the difference is about 10% to the one or the other side. Ext3 performs pretty well in this test, reiserfs reaches about half the performance of ext4/btrfs, while xfs and zfs are really slow.

Read/write

Reading and writing of data is pretty equal through filesystems in terms of benchmark results. The worst results has zfs and ext2 (especially in random read, which is vital in modern use of computers).

As per-character reading/writing is not so important, let's concentrate on the rest of tests. As you can see, btrfs is clearly the best, having first place in 3/5 tests being really close to first in the following two. Reiserfs and ext4 perform really well in this area.

Semi-summary

At this point it's clear that when it comes to performance on SSD disk we have two filesystems to consider the best: btrfs and ext4. Reiserfs is slightly worse, but the most mature from them. Xfs and ext3 are just OK, but don't perform equally good in all tests, while ext2 and zfs (on fuse) being not an option at all.

Let's then compare the features of the three:

So it seems, btrfs is full of new features compared to (old) reiserfs and (new) ext4 with only small performance penalty in some areas, while even being faster in some.

The rest tests presented only cover ext4, reiserfs and btrfs filesystems.

What is the best scheduler, then?

Having chosen the best filesystems, let's see, which scheduler works best.

ext4

Comparison of schedulers performance for ext4 filesystem:

As we see, cfq is the best in 5 tests, significantly worse in two (random creation of files and random seeks) and nearly as good as best in the rest. Deadline and noop perform pretty the same (with noop being better at creating files randomly and deadline being better at creating files sequentially).

reiserfs

Schedulers performance for reiserfs filesystem:

For reiserfs, again, cfq does its work really well with only random reads being significantly slower than deadline and noop schedulers.

btrfs

Let's now see what scheduler will be best for btrfs filesystem:

This time not cfq, but deadline scheduler is the man! In random seeks, where cfq is generally worse, this time it's worse by about 30% than the best: deadline scheduler. Only in one test deadline is worse than noop, but this is only slight difference. Cfq is only slightly better in 4 tests, but in the rest, deadline is better.

Ultimate comparison of btrfs, reiserfs and ext4

When we know which scheduler will run best with certain filesystems, let's compare Bonnie++ results for the perfect tandems:

• btrfs with deadline scheduler on underlying disk
• ext4 with cfq
• reiserfs with cfq

Random seeks

Choosing cfq scheduler on any of the tested filesystems degraded random seek performance. This is why btrfs with deadline scheduler is better than its competitors.

Creation and deletion of files

This time, without ext2 having so high bar, you can see the differences in creating and deleting files on the three filesystems I tested. Btrfs is much (about 2 times) faster than ext4 in deleting files, while ext4 is a bit faster in creating files randomly, and significantly faster (about 50%) in creating files sequentially. Reiserfs is about 2 times slower than the slower filesystem in each test.

Read/write

In read/write tests btrfs, ext4 and reiserfs perform almost equally well, with btrfs being slightly better than the latter two filesystems.

Summary

Ext4 and btrfs filesystems perform really well on SSD disks making the users really happy about the speed they get from normal computer use.

With ext4 being the default filesystem for Ubuntu 9.10, having SSD disk, you'll notice that it boots really fast:

• from Grub to GDM in 8 seconds
• from GDM to GNOME in 5 seconds
• OpenOffice launches the first time in 2-3 seconds (second time is 0 seconds)

With btrfs being equally fast (or even faster) than ext4 it's amazing what features it delivers:

• snapshots (you can make a snapshot of filesystem and then roll back to it, or just explore historical version files)
• compression
• mirroring/stripping — things usually done on block-device level now incorporated into filesystem
• nice internal structures and algorithms (copy on write, B-trees, …)
• integrated volume management

On the second hand, btrfs as of version 0.19 has still experimental disk format, which means it can be non-compatible with future kernels, but usually kernel developers create code that either preserve the old format or converts the filesystem to new one on the first mount (and then it's not possible to mount such a partition from an older kernel). Also if I understand well, the biggest changes from 0.18 to 1.0 were just applied in 0.19, so probably this will be the final format of btrfs partitions.

It's clear, that btrfs is the Linux answer to Sun's ZFS, which due to incompatible license can't be incorporated into the kernel (this is why we only have FUSE port available).

Having all this said, it's time for me to migrate my /home (and maybe the system partition too) to btrfs!

You can download raw benchmark data in ODS format.

by Gabrys

Szanowni Państwo,

chciałbym zgłosić reklamację dotyczącą pracy informacji telefonicznej PKS Bydgoszcz.

Dnia 30 września 2009 pomiędzy godziną 23:40 a 23:55 znajdując się na dworcu autobusowym w Bydgoszczy, wykonaliśmy z telefonu komórkowego połączenie do informacji — nr *720-84-00. Zapytanie dotyczyło najwcześniejszego połączenia z dworca w Bydgoszczy do Torunia. Mężczyzna poinformował nas, że najbliższe takie połączenie będzie dopiero po godzinie szóstej dnia następnego, co było nieprawdą. Nabliższe połączenie z owego dworca było bowiem o godzinie 23:55 (wykonywane przez PKS Mława, ze stanowiska nr 12 na dworcu autobusowym w Bydgoszczy), a następne o godzinie 01:40 (do Łodzi przez Toruń, ze stanowiska nr 11 na dworcu autobusowym w Bydgoszczy).

Połączenie telefoniczne kosztowało 5 złotych, o którym to koszcie nie było żadnej informacji na naklejce na szybie na wejściu do budynku dworca. Takiej informacji nie ma różnież na stronie internetowej PKS Bydgoszcz pod adresem: http://www.pks.bydgoszcz.pl/kontakt.php .

Koszty poniesione w wyniku wprowadzenia w błąd, to 5 złotych (czyli koszt telefonu na informację), zszargane nerwy i stanie na chłodzie przez ponad godzinę. Koszty mogły być znacznie większe, gdybyśmy na podstawie przekazanych informacji zdecydowali się nocować w Bydgoszczy lub wynająć inny środek transportu.

Aby sprawę zakończyć polubownie, proponuję zwrot kosztów poniesionych na wykonanie połączenia, oraz wyciągnięcie konsekwencji co do osoby, która wprowadziła nas, czym wpłynęła na znaczne pogorszenie postrzegania przez nas Firmy.

W sprawie zwrotu poniesionych kosztów (podamy numer konta), proszę skontaktować się na podany w formularzu kontaktowym adres e-mail.

Treść zażalenia będzie dostępna również pod adresem: http://piotr.gabryjeluk.pl/dev:informacja-pks do czasu uzyskania odpowiedzi, która będzie objawem zajęcia się tą sprawą.

Z góry dziękuję za pozytywne rozpatrzenie wniosku.

by Gabrys

Maintaining Wikidot is a bit more complex, because, files uploaded to sites are located in web, side to side with some static Wikidot php and javascript files. Also for historical reasons, there are web/files--common and web/files--local directories, which maps to /common--* and /local--* URLs and in fact, the files--local is never served directly by the web server (need to check permissions first).

Also some time ago, we made static files versioned, so that we can apply more aggressive HTTP caching to them (reducing average page load time) and still be able to fix bugs on them without waiting a few days till the cache expire. In current model, URL to static file contains version hash, this may be for example: http://static.wikidot.com/v--b44e0ce810ee/common--javascript/WIKIDOT.js (notice the b44e0ce810ee). The whole static.wikidot.com is now hosted on Amazon's CloudFront, which means you get static Wikidot files from a server nearby your location and not always from USA.

This all become quite complicated, so we decided to make things really clear and simple in the source code. The primary rule: make the source code (updatable from git) separate from files uploaded by users and generated by Wikidot. Second rule: make files that are automatically generated during installation (not in the runtime) separate from persistent files (like the uploaded by users) and from source code.

And at the end there needs to be some place for logs and a place for temporary data (we need this to generate some random cool stuff, but after generating them, files are deleted).

So we end up with something like this:

• WIKIDOT_ROOT
  • data/
    • avatars/ — user avatars
    • sites/ — site files (both generated thumbnails and uploaded files)
  • generated/
    • static/ — generated static files. This dir can be server directly by a fast non-PHP webserver for static.wikidot.com in case we don't want CloudFront anymore
  • tmp/ — temporary files including Smarty compiled versions of templates. Content of this dir can be safely removed
  • logs/ — Wikidot logs
  • everything else — comes from git and is unchangeable by application

Application needs write-access to data, tmp and logs. Generated dir needs write access to one installing or upgrading application.

Wikidot persistent data is now ONLY database and data/ directory, so it's easy to backup and restore the application (if you have enough time to make full backup of this).

There is still one exception to this nice schema which is php/db/base directory, which is autogenerated during installation from XML database definition files, but the cleaning is not over, I still work on this.

Nice thing about this work is that it does not need a lot of code changing, because directory paths are usually stored in one (max two) places in application, so this kind of totally reorganizing directory structure does not break things. As such, it is very very worth doing it. In the end we get clean internal structure of files and it's clear which files you can safely remove, which you can restore from git (and thus you can experiment a little on them — in case of crash, just re-download application), which are "state" of the Wikidot and where to look for logs.

This all is also very important, because we aim to make current Wikidot.com source open and as such we want it to be a nice code.

by Gabrys

During last 20 years, file system (and kernel-side logic like write schedulers and disk buffers) were made to optimize use of hard disks — magnetic hard disks. The disks are now quite fast when you read or write 1 GB file from them, but when you need to read 2000 small files that are located in different physical locations of the disk, their performance degrades.

Rotating disks

For the years, many developed systems (both software and hardware) to make as little disk seeks as possible. I've heard there are optimizations in kernel like: if you need to read a block that is 20 sectors after current position, don't seek, read the 19 useless sectors, and then read the meaningful one. I don't know if this is true and if yes, is this optimization of Linux kernel or some particular file system.

Solid State Drives

OK, so the file systems out there perform really well on rotating magnetic disk drives. So what about the solid state non-rotating disks. Are the previously talked optimizations good for them too? No. Solid state drives are not as fast as magnetic disks for sequential reads and writes, but they are much much better in random access to data. The seek time is approximately 0 (actually much less than 0.1 ms, when magnetic disks have the seek time about 5 ms).

SSD + File Systems?

On the other hand, there are quite a few new file systems that are meant to be run on SSD disks or at least are SSD-aware. I'm talking about NILFS2 and btrfs. Unfortunately neither of them is stable in the sense of on-disk data format. This means that partitions created with current version of NILFS or btrfs may not be readable by future versions of these file systems. Thus it's not too nice to have important data on them.

Looking for a benchmark

So this is time when I have my expensive SSD in my hand and face serious problem of choosing the right file system to keep my data secure and fast to access. I searched for some benchmarks to compare the results of different file systems, both the old XFS, ReiserFS, ext2/3, the new ext4 and SSD-optimized btrfs and NILFS2. The number of benchmarks of these filesystems on SSD drives I found is 0. So time to make my own benchmark.

My benchmark

I want to benchmark the following file systems:

• ext2, ext3
• ext4
• xfs
• reiserfs, reiser4
• nilfs
• btrfs
• zfs (via fuse)

I will use my new OCZ Agility 120 GB SSD disk for this.

As this option is used even for magnetic disks, I will append noatime to mount options for every file system I check.

Also, I will try the following tweaks as suggested by random sites:

• using noop scheduler for disk IO: echo noop > /sys/block/sdb/queue/scheduler
• turning on and off write-back caching: hdparm -W1 /dev/sda, hdparm -W0 /dev/sda
• discourage swapping (so that app data is kept in RAM and is not replaced with disk buffers, reading from SSD is damn fast anyway): sysctl -w vm.swappiness=1

For each setting, I'll make a test with bonnie++. I'll try to make nice graphs out of the data.

If you want me to test more settings or file systems or have some suggestion about the benchmarking tools, feel free to leave a comment.

UPDATE: I will also perform one more test: time of launching Firefox, Claws Mail and Pidgin from encfs-encrypted .mozilla, .purple and .claws-mail directories with different underlying file systems. This is very common task for me (they all start automatically after logging in).

by Gabrys

Dzwonię czym prędzej do Netii, aby zgłosić mój problem, ale wpierw muszę zaktualizować swoje dane (które nie zmieniły się od początku trwania umowy). Więc podaję swój numer komórkowy i e-mail i już, już prawie szczęśliwy, że mogę opowiedzieć na czym polega problem zaczynam, aby dowiedzieć się, że:

• działa panu internet, a jakaś strona nie, to nie nasz problem
• pewnie ma pan wirusy (a może bakterie?)
• rozmawiam z osobą, która WIE co to jest PING, TRACEPATH i ROUTER, ale nie potrafi odpowiedzieć na prośbę:

Czy mógłbym prosić, aby powiedziała mi Pani do jakiego adresu IP rozwiązuje się nazwa hetzner.de

(Odpowiedzią na to pytanie było: ale Pan nie ma stałego IP i dlatego Pana nie widzę)

Poprosiłem, aby kobieta zapingowała adres, który mi nie działa i niby jej działa. No to może faktycznie problem u mnie jakiś. Zrestartuję swój router i zobaczymy.

Poprosiłem w międzyczasie Slafsa, który jeden z serwerów w firmie ma podpięty do internetu przez Netię, ażeby zapingował dla mnie hetzner.de i również nie dostał odpowiedzi, a tracepath zatrzymał się na tym samym hopie.

Zadzwoniłem zatem drugi raz na infolinię. Tym razem odebrał mężczyzna. O niebo wolę rozmawiać o takich rzeczach z przedstawicielami tej samej płci. Przedstawiłem mu problem przekazując jak najmniej szczegółów. Zapytał jaki komunikat otrzymuję gdy próbuję otworzyć tę stronę. Powiedziałem, że próbuję zapingować ten serwer (co działa z internetu TPSA) i nie dostaję odpowiedzi, a gdy uruchamiam tracepath, to pakiet zatrzymuje się na konkretnym routerze. Dodałem, że problem dotyczy również innych serwerów w tej serwerowni i usłyszałem klarowne i oczekiwane:

Rozumiem

To było mocne. Kwintesencja męskiej komunikacji w jednym słowie. Po chwili dodał, że sprawdzi i pochwili wrócił do telefonu i powiedział, że jest problem (!), że wystawi zgłoszenie i sprawdzą, czy jest to problem masowy. Hurra!

Będę mógł się podłączyć do jabberpl.org, żeby zalogować się do jabbera (jednego z kilku kont). Będę mógł sprawdzić pocztę nie korzystając z proxy SOCKS. Będę mógł zobaczyć stronę hetzner.de!

Może to nieuczciwe, ale uważam, że kobiety nie powinny rozmawiać z klientami takimi jak ja. Następnym razem jak odbierze kobieta odkładam słuchawkę i próbuję natrafić na faceta :).

Jeszcze naszła mnie refleksja, że dobrze byłoby widzieć aktualne problemy, które są znane pracownikom Netii i nad którymi pracują. Dobrym przykładem jest tutaj strona toruńskiego dostawcy internetu:

http://www.man.torun.pl/index.php?mod=tickets

Gdyby takie zestawienie było dostępne na stronach Netii, mógłbym śledzić na bieżąco rozwój wydarzeń. Scenariusz wydarzeń od rana mógłby wyglądać wtedy tak:

• nie działa mi poczta
• patrzę na stronach Netii, czy jest jakiś błąd
• nie ma błędu, to sobie patrzę, czy to mój problem
• nie jest to mój problem, więc dzwonię do Netii i zgłaszam
• w Netii aktualizują tę stronę jeśli uznają, że to faktycznie jest ich problem
• widzę, że to zrobili, czyli pracują nad tym (przynajmniej tak sobie myślę)
• za jakiś czas jest aktualizacja, że wymienili router gdzieś tam i, że będzie działać za godzinę
• za godzinę działa, problem na stronie przechodzi do archiwum

Tutaj pojawia się wniosek taki sam jak z naszego ostatniego zepsucia się Wikidota:

• Ludzie nie są bardzo wkurzeni, że coś od czasu do czasu nie działa. Awarie się zdarzają
• Ludzie są wkurzeni, jak nie wiedzą dlaczego coś nie działa
• Ludzie są wkurzeni, gdy wiedzą, że jest awaria, a nikt nie chce im tego przyznać

Jak poradziliśmy sobie z tym w przypadku Wikidota? Gdy usługa nie działała, uruchomiliśmy statyczną stronę HTML z opisem awarii (dość szczegółowym) i postępów w jej usuwaniu. Po awarii napisaliśmy co zrobimy, gdy zdarzy się coś podobnego w przyszłości. Ludzie szczęśliwi, bo wiedzą, że potrafimy rozwiązywać poważne problemy, więdzą, że nawet jak będzie awaria, to ich dane są bezpieczne, więdzą, że Wikidot nie zniknie ot tak pewnego dnia. Trochę są smutni, że dzisiaj Wikidot nie działa, ale się cieszą, że będzie działał jutro.

I jeszcze mała ciekawostka:

IPv6 został opracowany w Bydgoszczy

by Gabrys

Wikidot was down for about 12 hours and the time it was down was full of work for us. We got a few things that could be broken starting from recent changes of the Wikidot software, hardware failure, high load-related kernel bugs or limitations to connection number or maximum possible number or file descriptors.

The problem is Wikidot kind of worked, so some people had their sites loading, some other not and getting "500" errors. We didn't want to stop it, but at some point Wikidot was completely unusable. We switched the database to the other machine, but this was not the solution, then we switched all Wikidot traffic to the machine, still no good, we switched the software to some previous version, but this still seemed bad.

Finally we worked out, there was a site, that had so big traffic, that it killed anything else (and itself as well). When we temporarily disabled it, the whole Wikidot started to work nicely again. Then Michał made some improvements for the high traffic site serving and the situation is stable again.

In the middle of everything, we had huge problems with our hosting company and their service called Portable IP addresses. It seems that switching DNS is much more reliable that using Portable IPs that took hours to switch (and were supposed to take seconds to switch)! DNS switching time was 15 minutes.

We learned a lot from the situation. Hardware upgrade postponed from really long time needs to be done quite quickly. We need more servers, to see which element breaks. For example if database server has high load, we know we need to tune database settings. If we have all on one massive server and one brick on it crashes, it usually causes all the server overloaded and this causes other bricks to crash as well, so it's hard too tell what the real problem is.

Another thing is that we see our users want information on what happens. It's bad when Wikidot crashes, but it's even worse, when it crashes and they have no information about this.

So, the next time a similar disaster happens we'll update on each technical detail possible, to let you know, that we know it's broken and we work hard to fix it. Other thing is, we plan having more fail-over servers in case something dies.

Thank you all for using Wikidot, it's a great pleasure working (and fixing things) for you!

by Gabrys

Ludzie są albo niemili, albo nieszczerzy.

Oraz:

Jedynacy nie czują potrzeby posiadania kont użytkowników na komputerze.

by Gabrys

• Syck (native C library bindings to PHP)
• Symphony YAML (pure PHP)
• Spyc (pure PHP again)

This is the comparison.

What the hell is YAML

Have you heard about XML or JSON? YAML is similarly to JSON and XML a way to store (read and write) structured data like arrays (a.k.a. lists), dictionaries (a.k.a. hash maps) and atomic values like strings and numbers. The structures can be nested, to form a definition of near-real-life objects, for example:

 --- Piotr Gabryjeluk: company: Wikidot Inc. university: Nicolaus Copernicus University, Toruń, Poland lives_in: Toruń, Poland hobbies: - basketball - playing the guitar 

Which translates to PHP:

 <?php $data = array('Piotr Gabryjeluk' => array( 'company' => 'Wikidot Inc.', 'university' => 'Nicolaus Copernicus University, Toruń, Poland', 'lives_in' => 'Toruń, Poland', 'hobbies' => array('basketball', 'playing the guitar') )); 

So you see YAML is quite nice even when you need to write it yourself.

YAML has its specification (see http://yaml.org), so once we have standard YAML parser and standard YAML dumper we can send arrays from one machine to another and the result should be the same array as was sent.

PHP

So let's see what are the choices if you want to play with YAML in PHP.

Syck

This is the fastest and the most complete YAML dumper and loader library available. This is binding to C library and this is available in PEAR. It is also available as regular package in Ubuntu repository, so install it by simple:

 aptitude install php5-syck 

In some shared hosting environment this could be a problem, so you need a pure PHP solution.

Spyc

This was the first PHP YAML implementation I saw. It is both dumper and loader and it seemed to work fine, but then I found some bugs, that stopped me from using it as the base and only YAML loader and dumper for Wikidot.

This one has really nice thing, which is nice when you want your users to enter YAML to define things (like we do for forms). It is quite forgiving when it comes to the syntax and ignores things that don't fit and still parses the rest.

Unfortunately as I stated before Spyc dumper so, when you first dump an array and then load it with Spyc you get something different (for example multiple new-lines are treated as one). Not good. Also as a loader it does not fully understand the full YAML specification (which is quite huge BTW).

Symphony YAML

This one is pure-PHP as well, so you don't need special rights, to use it on a PHP-enabled machine.

It's loader does not understand full YAML specification, so for example you can't load documents dumped by Syck. Dumper is good.

Summary

Verdict: loader

Syck is the winner in loading YAML. If you cannot use Syck, use Symphony YAML. If you need to parse user input (which should be human readable/writable similar to YAML), use Spyc.

Actually, this is nice combination for loading:

 <?php try { // if syck is available use it if (extension_loaded('syck')) { return syck_load($string); } // if not, use the symfony YAML parser $yaml = new sfYamlParser(); return $yaml->parse($string); } catch (Exception $e) { // if YAML document is not correct, return Spyc::YAMLLoadString($string); } 

This way, you have the fastest library used if possible, then the best pure-PHP, and if it fails in a way, that document was badly written (by human being for example), you fall-back to Spyc.

Verdict: dumper

In my opinion Symphony YAML dumper is the best from the three in terms of usability, portability and interoperability, because its output can be read by both itself and Spyc.

However, if you dump YAML often, use (hell faster) Syck for both loading and dumping. The generated YAML won't be readable by Symphony YAML or Spyc, but this is because they don't follow the specification (so not Syck's problem in fact).

Also note, that any valid JSON dumper output is readable by standard YAML 1.2 loaders, because JSON is a subset of YAML 1.2. So if using for data exchange (and not for talking to human) any fast JSON dumper can be used.

by Gabrys

Brussels

Last month was full of adventures. It started 1st of July with me going to Brussels meat our friend to talk about wikipedia-like site about art. We're going to help this man build the most complete site about art using Wikidot software!

BTW, this was my first flight in lifetime. Quite a strange feeling, but generally fine.

Forms

I was working on some nice technical and UI improvements to Wikidot, that is crucial for the art site (but really really nice for Wikidot as well, like forms for editing, entering and viewing structured data to wiki pages).

Search issues

That week was also spent on some massive Wikidot.com search engine tweaks. A stupid one-line bug, which was not exporting proper LC_ALL environmental variable in indexing script, caused many sites that used Asian or East-European languages to be not indexed (most notably the great ИСТОРИЈСКА БИБЛИОТЕКА). At first we though that we can re-index the broken sites, but our re-indexing mechanism was way too slow (would last for weeks for all broken sites).

Pieter then challenged me. He said he can index whole Wikidot in 6 hours. I thought it's not even possible, but then I started to work on that and I managed to index the whole Wikidot in less than 2 hours without indexing tags at first. Then with tags, it took 2 hours and 10 minutes or so. That was damn fast!

Inspired by this and an accident of disk full error on /var partition of our webserver (but this is why we keep user-uploaded files and other important things on separate disks), I also rewrote the incremental indexer, to work in similar way to the whole-Wikidot-re-indexer.

search-api reindex

If you care about some technical details:

• all search operations are issued with use of search-api, a separate program that can:
  • re-index whole Wikidot
  • queue indexing page/thread
  • queue deleting page/thread
  • queue re-indexing site
  • flush queue
• search-api is written in Python
• search-api uses PyLucene - a native Java Lucene library binded to CPython objects with PyJCC. Compiled with GNU Java Compiler to native code (like C programs), this binding has improved performance over using Lucene with Sun's Java.
• before rewriting it to only-Python, search-api was written in BASH and was a wrapper to:
  • java -jar searchApiHelper.jar search "phrase-to-search"
  • php search-api-helper.php flush
• search-api also takes care of file locking to assure that
  • only one process tries to modify the index
  • items are added to queue one-after-another
  • when doing some big index modification (read: full re-index) queue is not flushed (so that after the re-index all changes are applied to new index)
  • when flushing queue takes more time, and cron tries to run more flushing processes, they simply end (so only one process flushes the queue at a time)

Union of Rock Festival

Just after week spent in Brussels in nice hotel I went to Węgorzewo, Mazury (Poland biggest lakes distinct) to have fun on rock music festival. Unfortunately, the music level was not very impressive, so I mainly enjoyed the atmosphere on the camping area.

The weather was not great. It was wet everywhere, the ground was covered in 20 centimeters of mud and it was hard to walk around without getting dirty. But during the first day of being there, I learned to do that.

Improved workflow at Wikidot

Some of you noticed, that recently we started to work more efficiently, but this is not quite true. In fact we work as efficiently as before, but we are better organized, and have better priorities on tasks. Also we keep track of what we do, so we can then tell what we've done. So for us, this is a little more work of "documenting" our work (so maybe we work even less efficiently than before?), but for the outside world, we make more noise (in a positive meaning) around that. So basically, people know what we do, what we are going to do, when they can expect changes and most importantly, they understand why some feature request is being postponed. This is (and was) because we have more important things to do, but before they couldn't tell it.

Squark turned into a professional project manager, that manages our time. pieterh decided to talk to the Community and listen to their complaints (he reads or at least skims every post on Community forums). He tells Łukasz what needs to be done, Łukasz knows when we will have time to do this. This way communication inside Wikidot improved. Also we (michal frackowiak and me) no longer look on Community forums (some of you may regret), but this allows us to concentrate on our work.

The work continues

As I mentioned before, we want to introduce a great feature to Wikidot, which is forms. But the implementation now concentrates on the open source version of Wikidot software (once it's ready, working and tested we'll copy the feature to the Wikidot.com service).

aptitude install wikidot

As forms is a huge change, I started to prepare a good ground for it and closed most important bugs in Wikidot open source and I'm about to start making Ubuntu packages for it to allow even-simpler installation on Debian-based systems. Now the installation involves only 6 child-easy steps and in fact can be done by copying&pasting a few commands.

Yesterday's party

Yesterday I went to met some old-school-times friends in the heart of the city. It was meant to be a meeting for "a beer or two" but evolved into beer and dancing till morning. That was first time I get a morning bus (not even the first) to my home just after partying.

It was such a great fun and great folks I met.

Summary

I hope with this long blog post (but divided into friendly sections ;) ) I recompensed long period of not-posting anything here.

by Gabrys

Zgrałem sobie piosenki na komputer i na oggówkę¹ i zacząłem słuchać na dzień przed podróżą w łóżku przed snem.

Dobre ciężkie riffy, melodyczne fragmenty i nagle, błeee, co to? Jakiś okropny wokal, bez emocji i wyrazu, za chwilę dźwięk klasycznej gitary. Totalne dno. Masakra.

Powracam do krążka w czasie podróży. Nie mogę wytrzymać, zmieniam utwory. W końcu słucham innego albumu.

W pracy słucham tej muzyki w tle. Wychwytuję ciekawe fragmenty. 5 minut, 10 minut i znowu jakieś dno.

Jeśli chodzi o krążek, jego poziom jest równy — każda piosenka jest równie beznadziejna. Jeśli chodzi o piosenki: praktycznie każda jest nierówna. Zaczyna się fajnie, mięsiście, męsko, mocno, metalowo, z wyrazem i potem ni stąd ni zowąd pojawia się jakiś popowy szajs.

Żal mi tych dobrych fragmentów porozsiewanych po sześciu piosenkach, bo wciąż Dream Theater to dobry zespół i te powiedzmy 20 minut mogłoby się złożyć na jedną dobrą piosenkę, dla której warto byłoby kupić album (podobnie jak utwór A Change of Seasons sprawia, że warto kupić album A Change of Seasons). A w związku z tym fatalnym przemieszaniem "good shit" with "just shit" ta płyta nie jest warta zakupu.

Dream Theater: duży minus dla Was. Mam nadzieję, że na koncercie nie będziecie próbować promować tej płyty, bo to nie ma żadnego sensu.

PS: duży minus również dla sekcji wokalnej. Nie odnalazłem na całym albumie ani minuty ciekawego, żywego i ekspresyjnego wokalu, jakiego pełna jest każda inna płyta zespołu.

by Gabrys

This work was done, because searching the whole Wikidot database was far from being fast. At first we used Google Custom Search Engine to solve the problem, but we wanted to be independent from it. Also we wanted to include search results that are accessible by the person that searches but not by search engines (like private sites).

This worked really good. The only problem was long time spent to display the results. It was like 20 seconds, which was far better than when using previous search, but much worse than Google. This was strange, because from previous tests, we calculated the average search time should be about a second or two.

It started to be clear, when we noticed that only 20-30 searches per day are performed. The index is quite big, and it needs to be cached in RAM to work with sufficient performance.

Today I did more tests under heavy load and it seams Lucene can handle big number of queries. When users search often, the index is partially or even fully cached by the filesystem and searches are really quick!

But our main problem to solve today was slow local search a.k.a. "search this site". Moreover many concurrent queries were degrading database performance (not only for searching), so we decided to enable Lucene for local searches as well.

I must say it works really nice, fast and has a nice set of syntax tricks you can do with it, for example you can search for pages with something in tags. Just search for youtube tags:embed. This would search for pages matching youtube (in tags, title or content) and with embed in tags. If no such pages are found, partial matches are also returned, like: pages matching youtube (but with no embed in tags) or pages with embed in tags, (but not matching youtube).

To sum up, new search is faster, gives more accurate results, saves the database performance (which was the main goal) and allows nicer syntax than the old one.

by Gabrys

At Wikidot we use PHP5 as FastCGI backend to Lighttpd light-and-fast webserver. It works like this:

• there are a few hundreds of php5-cgi processes (name is cgi, but they also support FastCGI mode) running and waiting to be used
• lighttpd (only one needed!) process manages the network connections to all the clients and once the request is ready serves a static file or forwards the request to one of PHP backends processes.

We used to use internal Lighttpd FastCGI process manager, meaning the lighttpd processes actually used to start the PHPs.

Problems

We encountered some known problems of 500 (server side) errors appearing after some random time, especially under a high traffic. The typical message appearing at the Lighttpd's error.log was:

 <some date>: (mod_fastcgi.c.2494) unexpected end-of-file (perhaps the fastcgi process died): pid: ... 

There are plenty of reports on this in both Lighttpd's and PHP's forums, bug trackers and even some blogs.

Workarounds

We managed to write some hacky scripts that detected the situation and restarted the backends when needed. The reaction was so quick, that almost no-one noticed the error, but damn, this is not how WE solve problems.

A blind try

We decided to give spawn-fcgi a shot. What is it? It is a program that spawns FastCGI backends (independently from Lighttpd server). Why trying it? I've read somewhere, that it works more reliably than the internal Lighttpd spawner. What's interesting is that this program comes from lighttpd package, so we're in family anyway. It's mainly intended to run the FastCGI backends from different user than the webserver user or to run them on different machine(s) than the webserver machine. This can be used naturally for some smart load-balancing.

The only problem of this solution we encountered was internal limit of number of processes to spawn by a single process which was 256 (hardcoded, fixed in next versions). But at the same time, we decided to build a few FastCGI bridges (each spawning ~200 PHPs) anyway so that was no longer a problem for us.

What was quite surprising (but honestly, I deeply believed in this), our problems with 500 server errors and PHP disappeared. This configuration works for about 2 weeks now with absolutely no hacky scripts involved and no restarting needed. Cool.

Why I wrote this

I wrote this short note just for the record and to let other people know, that using spawn-fcgi instead of the internal Lighttpd's FastCGI spawner might solve their problems with PHP (FastCGI) and 500 internal server errors.

Hope this helps someone.

by Gabrys

During last time, I though it would be nice to have at least two things. One is a total revolution and probably won't be ready in near time, but second is quite easily implementable.

Events and PUSH

The first thing is to have a totally event-driven Linux and web services built on top of that. What does it mean? Every system event — file created, TCP connection set up, terminal window popped out, AC adapter plugged in, IM contact went on-line, … should be broadcasted to every application that registered for this event.

There should be two kind of events — synchronous and asynchronous. Synchronous means that each event listener can stop event (or delay it). For example messenger client can listen for suspend event, react by disconnecting you from IM networks and then let the suspend continue. Asynchronous are just some signals that are informational only, that are not to be interrupted — like "new wifi network detected".

What to build on top of that? Imagine the following scheme:

• file is created in /home/ directory signal is immediately send
• signal is caught by an application that calculates disk usage. Disk usage changes to 98%. Signal is immediately broadcasted
• the signal is caught by "low-space-notifier" application, that immediately sends you an email
• email is received and put into your INBOX
• if you have your mail client connected to mail server, you get the notification about the new mail immediately
• mail client shows you a nice notification about disk usage going to 98% on some other machine.

parsing everything including sending email and other things is less than 5 seconds. So you get the message "just as it's sent".

Some of the concepts in the example are already implemented, like inotify for file changes, IMAP push mode, but the problem is that in each case, this is solved individually, and what I would want is a UNIVERSAL and FAST solution for all event-driven computing.

On the other hand we (now) have polling. So Linux polls the CD drive for new disks every 2 seconds, mail client poll server each minute, RSS aggregators ask servers about news every 15 minutes and so.

The problem comes if you want to forward a message using polling. For example I have a mail account on some server and I want some messages to be forwarded to other server. Polling the first mailbox each 1 minute and doing processing mails makes the mail appear in the second mailbox 1 minute later (in the worst case). If I poll for mails in the second mailbox as well, the message is delayed for 2 minutes. If I want to pass the message to next mailboxes, the distribution time raises.

The solution for that is to poll services very very often (like every 10 seconds). 10 seconds multiplied by 4-5 mailboxes (in chain) is like 1 minute delay, which is in most cases acceptable. But this is just not needed to ask server for new messages each 10 seconds! How much much better would be to ask server, to notify about the message just as they come!

All problems with polling are just about "what polling time is OK". Polling to often means additional server work for answering "no, nothing new yet", and polling to rarely means outdated information. Either way polling is bad. And as it may seem inefficient to send messages as they come, it can be much more efficient than dealing with clients asking for new messages each 10 seconds.

This is first dream. Event-driven world, that delivers messages as fast as it can (not a new idea, it is used in old SMTP for example).

FsDb

The second dream is having a filesystem as powerful as a database. Why?

• There are good tools to deal with filesystems: ls, mv, rm, cp, ln
• You can serve filesystems with WWW, FTP, SAMBA, NFS servers
• Files are supported nicely in all programming languages I know

What database features I would like to have in filesystems:

1. Automatic backlinks. In database I have cars that belong to user:

 CREATE TABLE Car ( name: STRING; year: INT; user_id: FOREIGN KEY (User); ); 

but I can use that relation to User in the reverse:

 SELECT * FROM Car WHERE user_id = 7; 

where 7 is my user_id. This works fast (even having millions of cars). If I have it in filesystem:

 $ ls cars/porsche -l name year user -> ../users/gabrys 

I can do something like:

 $ cd cars $ for car in *; do ls -l $car | grep 'user -> ../users/gabrys' 1>/dev/null && echo $car; done porsche 

but this is counter-effective. It just goes through ALL cars and see if they have user linking to users/gabrys.

2. sorting/grouping by given field/property
3. paging (page 3, 10 items per page)
4. searching
5. full text searching — this is rarely used in databases as it's always better idea to have separate application for that, like Lucene, so this is not to be needed in the filesystem.

How to do this

I believe all (or nearly all) of this can be done having a simple fs as the backend and doing additional integrity tasks after given operations. Most notably, when you link from car to user:

 $ ln -s ../users/gabrys cars/porsche/owner 

There should be also something like this done automatically:

 $ ln -s ../cars/porsche users/gabrys/cars/ 

Then listing Gabrys' cars would be:

 $ ls users/gabrys/cars 

And this would list links to the cars that have links to gabrys. So it's just automatic backlink mechanism. It's just that easy, and that powerful.

Other things that make this nice is that you can easily back up the "database" (by having a special snapshot-enabled filesystem as a backend), NFS-mount it, replicate, rsync, encrypt, split to different hosts and easily debug with standard filesystem tools. Also there would be no big magic in that, so everyone could work with it.

The problem yet to think of is how to define the schema of data to be stored in the "database". But maybe the schema is even not needed by having a few conventions of special directories for example (like .backlinks directory storing backlinks, .fields directory storing field values and that kind of stuff).

Wish me luck with exams!

by Gabrys

They are called Forget-Me-Not.

They are effect of a great design and many hours of work. The great look comes from wire-wrapping — a technique hard enough to not be used by many artists. Also what counts is very high precision, which makes earrings look gorgeous.

Carefully chosen color of the nacre makes them just perfect.

If you want to buy them, contact me at lp.kooltsal|rtoip#lp.kooltsal|rtoip (or leave comment on this page). I can prepare them and send to EU or even US. Payment with PayPal or international bank transfer. Including posting to EU, price would be €20 (20 Euro).

See the whole collection on this site (in Polish language).

UPDATE: I forgot to mention about dimensions of them. The total length (height) of them (including hooks) is 50 mm. Also we decided to even lower the price to 15 Euro including shipping to EU just to make your decision easier!

This is a great opportunity. No-one else has earrings like this, guarantied!

UPDATE: earrings are sold. Look at similar ones at the following link biżuteria wire wrapping.

by Gabrys