• Zu schwer: Mit ca. 700g kann man das iPad in einer Hand nicht sehr lange bequem halten.
• Auflösung zu klein: 1024x768 ist bei der Größe des Displays lästig, zumal alle Apps die Schriften antialiased darstellen. Sieht erst gut aus, wenn man die meisten Schriften vergrößert. Besonders im Safari.
• Keine Kamera: Warum eigentlich nicht, Apple?
• Kein Multiuser: Und das ist wirklich lästig. Das iPad hat das Potential zu einem perfekten Wohnzimmer-Rechner. Aber wenn ich jedesmal die App-Konfigurationen ändern muss, wenn ich meine eigenen Daten lesen will (z.B. bei Facebook), dann ist das öde. Von Privatsphäre garnicht zu reden.

Das waren nur die offensichtlichsten Probleme, die ich mit dem iPad hatte. Das es dennoch praktisch ist, kann ich nicht leugnen. Es ist ein tolles Spielzeug. Aber kaufen will ich es denoch nicht.

Schade, dass es keine echten Alternativen gibt. Interessant wirkt das WeTab. Leider voraussichtlich erst Ende des Jahres verfügbar.

Designed in Germany | WeTab

Wer dann verzweifelt sucht, warum der MySQL-Connector bei Class.forName() eine Exception wirft, statt die Datenbank-Klasse zu liefern, der möge sich an die wichtige obere Info erinnern!

Inzwischen bin ich beim 8. Bild und habe damit noch einiges vor mir. Aber es geht langsam vorwärts.

Dieses Mal habe ich das Bild nicht mit GIMP erstellt, wie alle vorherigen Bilder, sondern habe mich mal mit MyPaint probiert. Beide Programme sind Open Source und damit frei erhältlich.

MyPaint ist dabei mehr der Versuch, zusammen mit einem Grafiktablett, echte (und sehr unechte) Malwerkzeuge nachzubilden. Das ganze ist nicht so intuitiv wie man denkt, da die Malwerkzeuge natürlich digital anders reagieren, als in Echt. Dennoch kann man mit etwas Übung ganz gut damit umgehen.

Welche Open Source Grafikprogramme könnte ich noch ausprobieren?!

GIMP - The GNU Image Manipulation Program

MyPaint

Jetzt habe ich eigentlich bereits seit meinem Geburtstag mein neues Grafiktablett (Wacom Bamboo Pen and Touch), das mir meine suesse Freundin geschenkt hat, und bin leider bisher noch nicht dazugekommen, es tatsächlich zu benutzen. (Inzwischen habe ich es dank folgenden Links endlich unter ubuntu 10.04 zum Laufen gebracht: Get Wacom Bamboo Pen Working in Ubuntu Lucid - Frank Groeneveld)

Daher habe ich mir nun ein Ziel gesetzt um mich etwas mit dem Tablet zu üben: In (ca.) 100 Tagen möchte ich genausoviele Bilder machen, die ich dann in meiner Galerie hier poste.

Ob ich das ganze tatsächlich in 100 Tagen schaffe ist sehr ungewiss. Aber zumindestens die Menge will ich doch schaffen. Mit etwas Glück wird vielleicht sogar mit der Zeit ein Webcomic draus. Aber das wird sich noch zeigen.

Ich präsentiere somit in der Galerie die ersten beiden Bilder aus dem Projekt "100".

Galerie - 100

Get Wacom Bamboo Pen Working in Ubuntu Lucid - Frank Groeneveld

dolic.com - Jeder kann es gewesen sein 2010/04/11+12

Jeder kann es gewesen sein...

Suppose you make a strace of a process (e.g. ls -lvim --help which outputs the standard vim commandline help) using the following command

strace -f -s 4095 vim --help 2>$HOME/tracefile.txt

This creates a very large file with all system calls the process did during it's execution. To now find the file accesses in this tracefile you maybe would open this file in vim and then would naïvly search e.g. for the string ] open ( to see, which files where opened. Vim search hightlighting would show you all open statements, but you would have to read the file yourself to find the corresponding close statement. Works, but gets very strenously if there are a lot of open-calls.

Now, with the following search-pattern in vim (using search highlighting) you will find the whole block in the trace file; from the beginning open to the ending close-call wonderfully highlighted for a quick overview. (Enter this after pressing / in command-mode.)

] open(.* = \(\d*\)\_.\{-}] close(\1)

This pattern uses several new features I never really used before (Which is funny, as I tend to use regular expressions a lot). An example of the block this pattern finds is

] open("/usr/share/tcltk/tcl8.4/encoding/iso8859-1.enc", O_RDONLY|O_LARGEFILE) = 5
[pid 14780] fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
[pid 14780] ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfb1bfa8) = -1 ENOTTY (Inappropriate ioctl for device)
[pid 14780] read(5, "# Encoding file: iso8859-1, single-byte...", 4096) = 1094
[pid 14780] read(5, "", 4096)           = 0
[pid 14780] close(5)

EDIT: As a reader remarked, my first example in this blog entry with ls -l is not very good. strace -f -s 4095 ls -l 2>$HOME/tracefile.txt does not work with the given pattern, as no pid-information is output (it seems strace only outputs pid-information, if the process is multithreaded.). So without the pid-information, the pattern should look like this: ^open(.* = \(\d*\)\_.\{-}] close(\1). In this case only open and close calls on the main-thread are found. If you omit the first ^ in the pattern, the search should still work although it might get mixed up with the string open inside string-outputs from strace. In summary this blog entry was created way to fast without proper testing. Sorry for this. Hopefully the information in this entry still is of some use.

backreferencing

As you can see, the open call returns a handler id which is used to also close the access again. Therefore we use \(\d*\) to mark the first occurrence of the handler at the end of the line and backreference it at the end with \1. (Using \2, \3 etc. you also could backreference more than one \(\) pattern.

multi line search

Normal you only search for patterns which can be found on one line. Here we have read over line endings. This is done by using \_. which is the same as . but also takes in account line endings.

greedy search

I you use the multiplier * to match more then one character, the longest string matching the atom will be found. For example with the string cabcabcabcab searching for c.*b will result in the full string found, as it starts with c and ends with b. If you only want to get cab you have to do a greedy search, which is done by using the multiplier \{-}. So doing c.\{-}b will result in finding only cab.

addendum

Be aware that this will not really work good, if the open and close statements are entangled. But it seems to work most of the time.

If you want to learn more about regular expressions in vim just enter :help regular-expression or :help pattern inside a vim-session.

Regular expressions can and should also be using in perl, javascript, sed, php, etc. They are very powerful constructs. Unfortunately every system seems to have its own dialect of regular expressions. But if you know the basic structure of regular expressions you learn to cope with the differences really fast.

Unfortunately I did not find a tool to exactly tell me which application is currently writing to which file on the harddrive. But a least with the tool iotop I was able to find out, which application is writing to the hard disc at all. Under ubunto or debian install this simply by invoking

apt-get install iotop

Like top this python-application continuously outputs the current processes which are using the hard drive. But you have to be very attentive to catch all applications while this tool is running. To get a better overview of all hard drive activity call the tool with the following parameters:

sudo iotop -qqqtaPob

This parameters put iotop into a mode where it outputs something like a logfile to the screen. Just let this run in the background, do something on your computer and then check, what tools where using the harddrive. Take a look in the man-pages of iotop to get the meaning of the parameters.

Now I am looking for a tool to really see to which files a running process currently is writing to. Some tests with strace -f -e trace=file -p PID where promising but failed if the running process opens the file only once at startup.

Anyone any ideas how to really see what and where a process writes something to the hard drive?

Zunächst mal Eclim. Das ist ein Plugin sowohl für Vim als auch für Eclipse. Wer normalerweise mit Vim arbeitet, wird Eclipse als ein furchtbar langsames Ungetüm empfinden. Um einige der Funktionalitäten von Eclipse in Vim zu verwenden, aber dabei trotzdem schnell und flexibel zu arbeiten, der wird dieses Plugin mögen. Für Projekte mit tiefer Baumstruktur lohnt es sich definitiv. Auch die automatische Syntax-Pruefung bei Speicherung von php-Dateien ist sehr praktisch. Auch ich habe allerdings die ganze tiefe von Eclim noch nicht durchschaut. Dieses kleine Plugin ist sehr mächtig und der Programmierer Eric Van Dewoestine ist in seiner Mailingliste wahnsinnig schnell beim Beantworten von Fragen.

Ein kleiner Tipp von mir (selbst erst in der Mailing-Liste gelernt). Mit den folgenden beiden Einstellungen, sieht Vim schon beim Start in einem Eclipse-Projekt-Verzeichnis ein bisschen wie eine IDE aus. :)

" ProjectTree immer darstellen.
let g:EclimProjectTreeAutoOpen = 1
let g:EclimProjectTreeExpandPathOnOpen = 1

Die zweite Seite ist eine fantastische Fundgrube an Tools und Ideen für Vim, um hier wirklich IDE-Funktionalität zu erhalten. Vor allem der Tipp mit xdebug und dem Vim-Debugger-Plugin, ist genial. Nur ein bisschen Konfiguration und man kann bequem php-Applikationen debuggen. Und das beste dabei, unter Debian sind die meisten Sachen nur ein apt-get install weiter entfernt.

Das ganze mag einigen nicht neu vorkommen, aber ich war doch überrascht über die Möglichkeiten, die hier noch zu finden sind. Ich mag Vim einfach!

Welcome to Eclim - eclim (eclipse + vim)

VIM an a PHP IDE - Thomas Koch

Ansonsten hier noch ein Link zu einem neuen Blog von einem guten alten Freund. Wobei ich sagen muss, dass die Seite ziemlich dunkel ist (von der Farbe her) und sehr kleine Schrift verwendet (oder ich werde alt. :) )

NanoBlogger

w7x - So gehts auch…