idlebox.net - Timo's Weblog

idlebox.net - Timo's Weblog http://idlebox.net idlebox.net - RSS 2.0 Feed de Copyright 2007, idlebox.net Thu, 23 Oct 2008 11:25:00 +0200 Thu, 23 Oct 2008 11:25:00 +0200 tbrss@idlebox.net (Timo Bingmann) Published Flex Bison C++ Example 0.1.3 http://idlebox.net/2008/1023-Flex-Bison-C++-Example-0.1.3.blog <a href="http://idlebox.net/2007/flex-bison-cpp-example/"><img src="http://idlebox.net/2007/flex-bison-cpp-example/drawing.jpg" width="200" height="200" alt="Funny Drawing with 'C++' 'FLEX' and a Bison" /></a>Released yet another updated source code package for <a href="http://idlebox.net/2007/flex-bison-cpp-example/">Flex Bison C++ Example</a>. The example source code is released into the public domain or, at your option, under the <a class="exp" href="http://sam.zoy.org/wtfpl/">Do What The Fuck You Want To Public License (WTFPL)</a>. This bugfix release solves a subtle, severe bug, which rendered the template code useless. Even the example <code>exprtext</code> program segfaulted with any expression. Corrected a very subtle bug with the newly introduced virtual <code>yywrap()</code> function in the <a href="http://idlebox.net/2007/flex-bison-cpp-example/flex-bison-cpp-example-0.1.3/doxygen-html/classFlexLexer.html">FlexLexer</a> class. Depending on how the header was included, the class contained the virtual <code>yywrap()</code> function or not. These differing class declarations lead to very strange NULL pointer exceptions, because the different compiled objects assume different class memory layouts. Ultimately the exprtest program always segfaulted. For more information and the download package see the <a href="http://idlebox.net/2007/flex-bison-cpp-example/">Flex Bison C++ Example</a> web page. http://idlebox.net/2008/1023-Flex-Bison-C++-Example-0.1.3.blog Thu, 23 Oct 2008 11:25:00 +0200 Update Release of STX B+ Tree 0.8.3 http://idlebox.net/2008/0907-STX-B+Tree-0.8.3-Update.blog <a href="http://idlebox.net/2007/stx-btree/"><img src="http://idlebox.net/2007/stx-btree/btree-thumb-border.png" width="252" height="193" alt="Small drawing of a B+ tree" /></a>Released another updated version 0.8.3 of the <a href="http://idlebox.net/2007/stx-btree/">STX B+ Tree C++ Template Classes</a> package. The updated release fixes up issues with the root node == NULL when the tree is initially empty. Fixed crash when running <a href="http://idlebox.net/2007/stx-btree/stx-btree-0.8.3/doxygen-html/classstx_1_1btree.html#e382217f25916442745eb83520b20c12">verify()</a> on an empty btree object. Now the root node is freed when the last item is removed. Also fixed crash when attempting to copy an empty btree or when trying to remove a non-existing item from an empty btree. Also <a href="http://idlebox.net/2007/stx-btree/stx-btree-0.8.3/doxygen-html/speedtest.html">enhancing the speedtest</a> to test the hash table container implementation from <code>__gnu_cxx</code>. Extending tests by another set of runs measuring only the find/lookup functions. See the speed results web page for more information. The updated source code package is available <a href="http://idlebox.net/2007/stx-btree/">for download from this webpage</a>. Some compiled binaries of <a href="http://idlebox.net/2007/stx-btree/demo.htt">wxBTreeDemo</a> for Win32 and Linux are available on the <a href="http://idlebox.net/2007/stx-btree/demo.htt">demo download page</a>. As before, the updated main B+ tree implementation can be found in doxygen <a href="http://idlebox.net/2007/stx-btree/stx-btree-0.8.3/doxygen-html/btree_8h-source.html">stx/btree.h</a> or with plain text comments <a href="http://idlebox.net/2007/stx-btree/stx-btree-0.8.3/include/stx/btree.h.html">stx/btree.h</a>. http://idlebox.net/2008/0907-STX-B+Tree-0.8.3-Update.blog Sun, 07 Sep 2008 18:31:00 +0200 C++ Code Snippet - Print Stack Backtrace Programmatically with Demangled Function Names http://idlebox.net/2008/0901-stacktrace-demangled/ Yesterday I was tasked to analyzed an inner function of a reasonably complex software package. The inner function was called thousands of times from many different parts of the program, a simple counter print-out showed that. However I was interested in which execution paths reach this inner function and how often the different parts access the function. My straight-forward idea was to dump a stack backtrace each time the inner function is called, similar to the one printed by a debugger. However I needed some code snippet to dump the stack backtrace programmatically, without using <code>gdb</code> to halt the program each time. Stack backtraces can be saved with <a href="http://idlebox.net/2008/0901-stacktrace-demangled/backtrace.3.htt">backtrace(3)</a>, resolved into symbolic names using <a href="http://idlebox.net/2008/0901-stacktrace-demangled/backtrace.3.htt">backtrace_symbols(3)</a> and printed using <a href="http://idlebox.net/2008/0901-stacktrace-demangled/backtrace.3.htt">backtrace_symbols_fd(3)</a>. These functions are well documented and fairly easy to use. However I was debugging a C++ program, which made heavy use of templates and classes. C++ symbols names (including namespace, class and parameters) are mangled by the compiler into plain text symbols: e.g. the function <code>N::A<int>::B::func(int)</code> becomes the symbol <code>_ZN1N1AIiE1B4funcEi</code>. This makes the standard backtrace output very unreadable for C++ programs. To demangle these strings the GNU <code>libstdc++</code> library (integrated into the GNU Compiler Collection) provides a function called <a href="http://idlebox.net/2008/0901-stacktrace-demangled/cxa_demangle.htt">__cxa_demangle()</a>. Combined with <a href="http://idlebox.net/2008/0901-stacktrace-demangled/backtrace.3.htt">backtrace(3)</a> a pretty stack backtrace can be outputted. The demangling function only works for programs compiled with <code>g++</code>. The following header file contains a function <code>print_stacktrace()</code>, which uses <a href="http://idlebox.net/2008/0901-stacktrace-demangled/backtrace.3.htt">backtrace(3)</a>, <a href="http://idlebox.net/2008/0901-stacktrace-demangled/backtrace.3.htt">backtrace_symbols(3)</a> and <a href="http://idlebox.net/2008/0901-stacktrace-demangled/cxa_demangle.htt">__cxa_demangle()</a> to print a readable C++ stack backtrace. <a href="http://idlebox.net/2008/0901-stacktrace-demangled/">This blog entry continues on the next page ...</a> http://idlebox.net/2008/0901-stacktrace-demangled/ Mon, 01 Sep 2008 22:30:00 +0200 Update Release of STX B+ Tree 0.8.2 http://idlebox.net/2008/0813-STX-B+Tree-0.8.2-Update.blog <a href="http://idlebox.net/2007/stx-btree/"><img src="http://idlebox.net/2007/stx-btree/btree-thumb-border.png" width="252" height="193" alt="Small drawing of a B+ tree" /></a>Released an updated version 0.8.2 of the <a href="http://idlebox.net/2007/stx-btree/">STX B+ Tree C++ Template Classes</a> package. The updated release fixes up all issues with iterators and one harmless bad-memory access. The <a href="http://idlebox.net/2007/stx-btree/stx-btree-0.8.2/doxygen-html/classstx_1_1btree_1_1reverse__iterator.html">reverse_iterator</a> classes of the B+ tree were completely reworked. Now they are real implementations and do not use STL magic. Both <a href="http://idlebox.net/2007/stx-btree/stx-btree-0.8.2/doxygen-html/classstx_1_1btree_1_1reverse__iterator.html">reverse_iterator</a> and <a href="http://idlebox.net/2007/stx-btree/stx-btree-0.8.2/doxygen-html/classstx_1_1btree_1_1const__reverse__iterator.html">const_reverse_iterator</a> should work as expected now. Added two large test cases for iterators. Enabled public default-constructors on iterators. Also fixed a memory access bug which happens in <a href="http://idlebox.net/2007/stx-btree/stx-btree-0.8.2/doxygen-html/classstx_1_1btree.html#40e3e935186128e71b90ad2482fc73a7">erase_one_descend()</a>: <code>leaf->slotkey[leaf->slotuse - 1]</code> if <code>leaf-slotuse == 0</code>. This doesn't have any other bad effect, because the case only occurs when <code>leaf == root</code> and then the resulting <code>btree_update_lastkey</code> message is never really processed. However it still is a bad-memory access. The updated source code package including the wxBTreeDemo source is available <a href="http://idlebox.net/2007/stx-btree/">for download from this webpage</a>. Some compiled binaries of <a href="http://idlebox.net/2007/stx-btree/demo.htt">wxBTreeDemo</a> for Win32 and Linux are available on the <a href="http://idlebox.net/2007/stx-btree/demo.htt">demo download page</a>. As before, the updated main B+ tree implementation can be found in doxygen <a href="http://idlebox.net/2007/stx-btree/stx-btree-0.8.2/doxygen-html/btree_8h-source.html">stx/btree.h</a> or with plain text comments <a href="http://idlebox.net/2007/stx-btree/stx-btree-0.8.2/include/stx/btree.h.html">stx/btree.h</a>. http://idlebox.net/2008/0813-STX-B+Tree-0.8.2-Update.blog Wed, 13 Aug 2008 16:48:00 +0200 Published Flex Bison C++ Example 0.1.2 http://idlebox.net/2008/0803-Flex-Bison-C++-Example-0.1.2.blog <a href="http://idlebox.net/2007/flex-bison-cpp-example/"><img src="http://idlebox.net/2007/flex-bison-cpp-example/drawing.jpg" width="200" height="200" alt="Funny Drawing with 'C++' 'FLEX' and a Bison" /></a>Released an updated source code package for <a href="http://idlebox.net/2007/flex-bison-cpp-example/">Flex Bison C++ Example</a>. The example source code is released into the public domain or, at your option, under the <a class="exp" href="http://sam.zoy.org/wtfpl/">Do What The Fuck You Want To Public License (WTFPL)</a>. This bugfix release solves two problems there were reported to me via e-mail: The first problem were compilation errors that occured when no <code>%union</code> directive is used in the grammar: in this case the include headers order is changed around by bison and thereby breaks compilation. This was fixed by never including <a href="http://idlebox.net/2007/flex-bison-cpp-example/flex-bison-cpp-example-0.1.2/doxygen-html/parser_8h.html">parser.h</a> directly, but always using <a href="http://idlebox.net/2007/flex-bison-cpp-example/flex-bison-cpp-example-0.1.2/doxygen-html/scanner_8h.html">scanner.h</a>. And the second issue was raised because new versions of <a href="http://flex.sourceforge.net">flex</a> were released after years of stagnation. The new flex version 2.5.35 adds a virtual function <code>yywrap()</code> to the <code>yyFlexLexer</code> class. This function is automatically defined in any lexer source file generated by flex. However because I copied <a href="http://idlebox.net/2007/flex-bison-cpp-example/flex-bison-cpp-example-0.1.2/doxygen-html/FlexLexer_8h.html">FlexLexer.h</a> from an older flex distribution, the function definition throughs a "no <code>yywrap()</code> member function" compiler error. Updating the <a href="http://idlebox.net/2007/flex-bison-cpp-example/flex-bison-cpp-example-0.1.2/doxygen-html/FlexLexer_8h.html">FlexLexer.h</a> with a conditional declaration of <code>yywrap()</code> hopefully did the trick and now works on all versions. Usually this file should be taken from <code>/usr/include</code> and not from the package. However that will break compilation if flex is not installed, and a self-sufficient compilation package was a primary goal of the example. For more information and the download package see the <a href="http://idlebox.net/2007/flex-bison-cpp-example/">Flex Bison C++ Example</a> web page. http://idlebox.net/2008/0803-Flex-Bison-C++-Example-0.1.2.blog Sun, 03 Aug 2008 14:26:00 +0200 Speedtest and Comparsion of Open-Source Cryptography Libraries and Compiler Flags http://idlebox.net/2008/0714-cryptography-speedtest-comparison/ <a href="http://idlebox.net/2008/0714-cryptography-speedtest-comparison/"><img src="http://idlebox.net/2008/0714-cryptography-speedtest-comparison/p4-3200-gentoo-all-thumb.jpg" width="300" height="423" alt="Cryptograph Speedtest - All Tests: Speed by Data Length on p4-3200-gentoo" /></a><h2>Abstract</h2> There are many well-known open-source cryptography libraries available, which implement many different ciphers. So which library and which cipher(s) should one use for a new program? This comparison presents a wealth of experimentally determined speed test results to allow an educated answer to this question. The speed tests encompass eight open-source cryptography libraries of which 15 different ciphers are examined. The performance experiments were run on five different computers which had up to six different Linux distributions installed, leading to ten CPU / distribution combinations tests. Ultimately the cipher code was also compiled using four different C++ compilers with 35 different optimization flag combinations. Two different test programs were written: the first to verify cipher implementations against each other, the second to perform timed speed tests on the ciphers exported by the different libraries. A cipher speed test run is composed of both encryption and decryption of a buffer. The buffer length is varied from 16 bytes to 1 MB in size. Many of the observed results are unexpected. Blowfish turned out to be the fastest cipher. But cipher selection cannot be solely based on speed, other parameters like (perceived) strength and age are more important. However raw speed data is important for further discussion. When regarding the eight selected cryptography libraries, one would expect all libraries to contain approximately the same core cipher implementation, as all calculation results have to be equal. However the libraries' performances varies greatly. OpenSSL and Beecrypt contain implementations with highest optimization levels, but the libraries only implement few ciphers. Tomcrypt, Botan and Crypto++ implement many different ciphers with consistently good performance on all of them. The smaller Nettle library trails somewhat behind, probably due to it's age. The first real surprise of the speed comparison is the extremely slow test results measured on all ciphers implemented in libmcrypt and libgcrypt. libmcrypt's ciphers show an extremely long start-up overhead, but once it is amortized the cipher's throughput is equal to faster libraries. libgcrypt's results on the other hand are really abysmal and trail far behind all the other libraries. This does not bode well for GnuTLS's SSL performance. And libmcrypt's slow start promises bad performance for thousands of PHP applications encrypting small chunks of user data. Most of the speed test experiments were run on Gentoo Linux, which compiles all programs from source with user-defined compiler flags. This contrasts to most other Linux distributions which ship pre-compiled binary packages. To verify that previous results stay valid on other distributions the experiments were rerun in chroot-jailed installations. As expected Gentoo Linux showed the highest performance, closely followed by the newer versions of Ubuntu (hardy) and Debian (lenny). The oldest distribution in the test, Debian etch, showed nearly 15% slower speed results than Gentoo. To make the results transferable onto other computers and CPUs the speed test experiments were run on five different computers, which all had Debian etch installed. No unexpected results were observable: all results show the expected scaling with CPU speed. Most importantly no cache effects or special speed-ups were detectable. Most robust cipher was CAST5 and the one most fragile to CPU architecture was Serpent. Most interesting for applications outside the scope of cipher algorithms was the compiler and optimization flags comparison. The speed test code and cipher library Crypto++ was compiled with many different compiler / flags combinations. It was even compiled and speed measured on Windows to compare Microsoft's compiler with those available on Linux. The experimental results showed that Intel's C++ compiler produces by far the most optimized code for all ciphers tested. Second and third place goes to Microsoft Visual C++ 8.0 and <code>gcc 4.1.2</code>, which generate code which is roughly 16.5% and 17.5% slower than that generated by Intel's compiler. gcc's performance is highly dependent on the amount to optimization flags enabled: a simple <code>-O3</code> is not sufficient to produce well optimized binary code. Relative to <code>gcc 4.1.2</code> the older compiler version <code>3.4.6</code> is about 10% slower on most tests. All in all the experimental results provide some hard numbers on which to base further discussion. Hopefully some of the libraries' spotlighted deficits can be corrected or at least explained. Lastly the most concrete result: the cipher and library I will use for my planned application is Serpent from the Botan library. <a href="http://idlebox.net/2008/0714-cryptography-speedtest-comparison/">This blog entry continues on the next page ...</a> http://idlebox.net/2008/0714-cryptography-speedtest-comparison/ Mon, 14 Jul 2008 14:53:00 +0200 Kooperative LaTeX-Mitschrift zu Algebra 2 bei Prof. Herrlich http://idlebox.net/2008/0510-Algebra2-Skript.blog Nachdem ich in der letzten Woche die Prüfung zu Algebra 2 abgelegt habe, betrachte ich nun das dazugehörige Skript auch als abgeschlossen. Zu der Vorlesung im Sommersemester 2006 entstand kooperativ per Internet eine LaTeX-Mitschrift. Das gemeinsame Mitschreiben/Nach-TeXen wurde möglich durch das <a href="http://latexki.nomeata.de">LaTeX-Wikisystem latexki</a> von <a href="http://www.joachim-breitner.de">Joachim Breitner</a>. Auf dem <a href="http://mitschriebwiki.nomeata.de">Mitschrieb-Wiki</a> haben damals verschiedene Leute zusammen das LaTeX kapitelweise zusammengestellt. Ich habe ungefähr sechs Vorlesungen dazu beigetragen. Irgendwann hatte ich damals einen lokalen Branch der LaTeX Dateien mittels <a href="http://svk.bestpractical.com">SVK</a> angefangen. Dafür gab es verschiedene Gründe. Insbesondere war lokales Editieren der LaTeX-Dateien mit XEmacs sehr viel bequemer als online im Browser-Formularfeld. Außerdem war das Einbinden von externen EPS/PDF Graphiken auf dem Wiki-System leider nicht möglich. Ich hatte auch andere Vorstellungen vom optischen Seitenlayout und Schriften, welche das LaTeX-Wiki nicht akzeptierte. Der Branch ist dann permanent geworden und ich habe beim Lernen sehr, sehr viele kleine Fehler im Skript gefunden und einige kurz gefasste Stellen ergänzt. Leider ist es nicht mehr möglich die Änderungen auf das Wiki hochzuladen, da einige Neuerungen insbesondere die Graphiken nicht unterstützt werden und die ganzen anderen kleinen Änderungen nur noch schwer nachvollziehbar sind. Darum gibt es hier meine (private) Version des Mitschrieb-PDFs und des LaTeX-Quellcodes. Das fertig kompilierte Skript <a href="http://idlebox.net/2006/Algebra2/Algebra2.pdf">Algebra2.pdf</a> ist 611 kB groß. Der LaTeX-Code zum Skript ist in eine Hauptdatei und kleine Kapitel-Dateien aufgeteilt. Die folgenden Links führen zum Quellcode mit Syntaxhighlighting. <table class="smallwhite vtop"> <tr> <td> Hauptdatei: <a href="http://idlebox.net/2006/Algebra2/Algebra2.tex.html">Algebra2.tex</a> </td> <td rowspan="2"> Teil 1: <a href="http://idlebox.net/2006/Algebra2/Algebra2Par11.part.tex.html">Algebra2Par11.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par12.part.tex.html">Algebra2Par12.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par13.part.tex.html">Algebra2Par13.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par14.part.tex.html">Algebra2Par14.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par15.part.tex.html">Algebra2Par15.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par16.part.tex.html">Algebra2Par16.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par17.part.tex.html">Algebra2Par17.part.tex</a> </td> <td rowspan="2"> Teil 2: <a href="http://idlebox.net/2006/Algebra2/Algebra2Par21.part.tex.html">Algebra2Par21.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par22.part.tex.html">Algebra2Par22.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par23.part.tex.html">Algebra2Par23.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par24.part.tex.html">Algebra2Par24.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par25.part.tex.html">Algebra2Par25.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par26.part.tex.html">Algebra2Par26.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par27.part.tex.html">Algebra2Par27.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par28.part.tex.html">Algebra2Par28.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par29.part.tex.html">Algebra2Par29.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par2A.part.tex.html">Algebra2Par2A.part.tex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par2B.part.tex.html">Algebra2Par2B.part.tex</a> </td> <td rowspan="2"> Extras: <a href="http://idlebox.net/2006/Algebra2/Algebra2Par28.pic1.fig.html">Algebra2Par28.pic1.fig</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par29.pic1.fig.html">Algebra2Par29.pic1.fig</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par29.pic1.pictex.html">Algebra2Par29.pic1.pictex</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par29.pic2.gnuplot.html">Algebra2Par29.pic2.gnuplot</a> <a href="http://idlebox.net/2006/Algebra2/Algebra2Par29-pic2.pdf">Algebra2Par29-pic2.pdf</a> <a href="http://idlebox.net/2006/Algebra2/Cover-Algebra12.tex.html">Cover-Algebra12.tex</a> </td> </tr> <tr> <td> Komplett: <a href="http://idlebox.net/2006/Algebra2/Algebra2.zip">Algebra2.zip</a> </td> </tr> </table> Da ich mein <a href="http://idlebox.net/2005/1103-Algebra1-Skript.blog">altes Algebra 1 Skript</a> zusammen mit dem neuen Algebra 2 Skript zu einem kleinen Buch binden wollte, habe ich noch ein <a href="http://idlebox.net/2006/Algebra2/Cover-Algebra12.pdf">Deckblatt-PDF (Cover-Algebra12.pdf)</a> für die beiden Teile angefertigt. http://idlebox.net/2008/0510-Algebra2-Skript.blog Sat, 10 May 2008 15:59:00 +0200 Bugfix Release of STX B+ Tree 0.8.1 http://idlebox.net/2008/0125-STX-B+Tree-0.8.1-Bugfix.blog <a href="http://idlebox.net/2007/stx-btree/"><img src="http://idlebox.net/2007/stx-btree/btree-thumb-border.png" width="252" height="193" alt="Small drawing of a B+ tree" /></a>Released a bugfix version 0.8.1 of the <a href="http://idlebox.net/2007/stx-btree/">STX B+ Tree C++ Template Classes</a> package. The bug fixed is a possibly illegal memory access during <code>find()</code> function. I received a new test case via email in which valgrind detected an uninitialized memory access. By tracing it, I soon found that it happens during any <code>find(key)</code> call with a <code>key</code> that is larger than any item contained in the tree. During the <code>find()</code> function <code>find_lower()</code> is called on a leaf node and returns the slot number with the smallest or equal key. However if the queried key is larger than all keys in a leaf node or in the whole tree, <code>find_lower()</code> returns a slot number past the last valid key slot. Comparison of this invalid slot with the queried key then yields an uninitialized memory error in valgrind. The updated source code package including the wxBTreeDemo source is available <a href="http://idlebox.net/2007/stx-btree/">for download from this webpage</a>. Some compiled binaries of <a href="http://idlebox.net/2007/stx-btree/demo.htt">wxBTreeDemo</a> for Win32 and Linux are available on the <a href="http://idlebox.net/2007/stx-btree/demo.htt">demo download page</a>. As before, the updated main B+ tree implementation can be found in doxygen <a href="http://idlebox.net/2007/stx-btree/stx-btree-0.8.1-doxygen/btree_8h-source.html">stx/btree.h</a> or with plain text comments <a href="http://idlebox.net/2007/stx-btree/stx-btree-0.8.1/include/stx/btree.h.html">stx/btree.h</a>. http://idlebox.net/2008/0125-STX-B+Tree-0.8.1-Bugfix.blog Fri, 25 Jan 2008 15:48:00 +0100 Cry of Dolour by Stanislav Ossovsky - Free Fantastic Classic-Metal Music http://idlebox.net/2007/1014-Stanislav_Ossovsky-Cry_of_Dolour/ <a href="http://idlebox.nethttp://www.cryofdolour.ru/"><img src="http://idlebox.net/2007/1014-Stanislav_Ossovsky-Cry_of_Dolour/thumb.jpg" width="360" height="150" alt="Cry of Dolour by Stanislav Ossovsky" /></a>While stumbling around the web, today I found some fantastic instrumental classic-metal music. Listening into some random web music streams, I heard a piece that immediately matched my music taste. That taste is maybe best described as symphonic epic metal, though I'm generally against over-detailed (music) categorization. Consequently I entered the song's name into Amazon's search, but nothing was found. Some googling revealed that the song is downloadable for free: <a href="http://www.cryofdolour.ru">http://www.cryofdolour.ru</a> - (<a href="http://www.cryofdolour.ru/download.htm">download page</a>) It is part of a complete album of similar pieces composed by this Russian musician who signed the page with RAO. The pieces combine classic music motifs with metallic drumming and guitars. Sounds impossible, yet the songs masterfully weaved both styles together creating a bombastic epic expression. Yes, the songs are all instrumental, and yes, you need some patience for the first track. Having heard the pieces over and over again, I soon noticed that while the musical composition is excellent the tracks' sound itself does not reach usual CD production quality. They sound a bit synthetic and miss some bass blast. But hey, it's free. Original, incredible music by an unknown artist! My three favourite tracks are: "Hymn to Solitude", "Dies Irae", "It is Coming" and "Prelude". Ah, that is now four and I still missed some of the best. Just hear them yourself. If you also have no clue as to what the Russian text on the main page is about, I suggest <a href="http://translate.google.com/translate?u=http%3A%2F%2Fwww.cryofdolour.ru%2Findex.htm&langpair=ru%7Cen&hl=en&ie=UTF8">reading Google's translation of that page</a>. http://idlebox.net/2007/1014-Stanislav_Ossovsky-Cry_of_Dolour/ Sun, 14 Oct 2007 21:25:00 +0200 Really Good Lego Model of Escher's "Relativity" http://idlebox.net/2007/0907-Escher-Relativity-Lego/ <a href="http://idlebox.nethttp://www.andrewlipson.com/escher/relativity.html"><img src="http://idlebox.net/2007/0907-Escher-Relativity-Lego/thumb.jpg" width="250" height="220" alt="Thumbnail of Escher's Relativity in Lego" /></a>The idea strikes me as very strange: to take the impossible figures <a href="http://www.mcescher.com/">sketched by Escher</a> and build Lego models of them. Someone actually took up this seemingly "impossible" feat. Yesterday I found <a href="http://www.andrewlipson.com/escher/relativity.html">their pictures of "Relativity"</a>, of which I have a poster on the wall left of my PC. I've had some long looks at the poster. So the minute details of the Lego reconstruction interested me immediately. Due to the studs of (standard) Lego tiles pointing in only one direction they had to leave out a few railings, which help form the twisted triangle's composition lines. Each of the red Lego men are at the correct place and hold the correct action props. Sweetest are the Lego flowers and plants positioned at the picture's upper left, lower right and center. A very good job indeed. http://idlebox.net/2007/0907-Escher-Relativity-Lego/ Fri, 07 Sep 2007 10:41:00 +0200