Get a free PDF Reader

Thu, 27 May 2010 01:11:55 +0000

Looking for some instructions for mozplugger embedding evince, besides the solution I found here, I also found a nice link to this campaign from the FSF Europe.

It is an appeal to use a free PDF Reader. Well, under Linux and other free systems, there are a lot of them, and they are all mostly good. I actually do not understand why there are still people who prefer the Adobe Reader under Linux. Not only are there a lot of alternatives, they are also mostly much better (faster, easier to use). Few PDFs are not working on them – the ones created with some strange WMF-Tools (M$ for the win) and of course the ones which are encrypted such that explicitly only Adobe Reader can open them. I had this situation exactly twice in my whole life – one time a PDF created with some strange settings from Scientific Workplace, and the other time from a Professor who wasnt allowed to publish parts of its book without encryption. Even commercial pdf-providers usually dont use this, because its basically useless – it is a crude form of DRM, but modern eBook-Formats have much better techniques for that.

Also under Windows, I dont want to use the Adobe Reader, but actually I mostly use (the non-free) Foxit Reader there. The FSE’s list names Evince for Windows – but Evince for Windows was in a Beta-State and I wouldnt have recommended it to normal people. Okular was stable but needed a full-blown KDE-Installation, and KDE for Windows is still no fun. I never tried Sumatra PDF though. I will have to do this.

Well, actually, I dont like PDF much. Many modern PDF-Files are bloated. I liked early versions of PostScript much better. And at the moment, I like djvu very much. At least for ebooks, djvu seems to be a good format. As a comparably simple format, I like SVG. I mean, its bloated with XML-Stuff, but at least the inner structure is simple.

Its a pity that only few pieces of free software work properly under Windows. Windows is still the main platform for most people, and to convince them of free software, it could be a good thing to actually make them work with it under Windows already.

Advertisements

Portal und andere Spiele …

Sat, 22 May 2010 00:02:46 +0000

… werden jetzt ja dann wohl in größerer Zahl auf Mac OS Portiert, und damit bleibt zu hoffen, dass man sie dann leichter auf Linux portierbar beziehungsweise emulierbar/virtualisierbar sein werden, denn die Grundlagen beider Systeme sollten doch näher verwandt sein.

Jedenfalls stiefelte ich heute Windows auf meinem neuen Denkblock. Konfigurierte Ubuntu auch gleichzeitig so, dass es virtualisierbar ist unter ebendiesem Windows, sodass nicht nicht mehrere Logs und Feuerfuchsprofile maintainen muss. Lief auch alles wunderbar.

Steam startierte und brauchte lange um Portal herunterzuladen und nachdem es dieses endlich fertiggetan hatte stürzte es erstmal gepflegt ab. Nach einem Neustart und dem versuch, Portal zu starten, klärte es mich auf, dass es meinen Grafikchip nicht kennen würde. Durchaus möglich, es ist nicht der Neueste, und dementsprechend Überrascht war ich, als dann das Spiel doch loslief und ich mit relativ wenigen aber eben immernoch daseienden Rucklern anfangen konnte zu spielen.

Die Ruckler waren nervig, und so wollte ich die Bildqualität heruntersetzen, was zu einem prompten Absturz führte, und vor einem kompletten Systemneustart schaffte ich es auch nicht das Spiel wieder zu starten. Danach stellte ich alles wieder um, in der Hoffnung, danach würde das Spiel wenigstens wieder im vorherigen Zustand sein. Was soll ich sagen, das Spiel hängte sich auf und lastete einen Prozessorkern voll aus, sodass ich mich gezwungen sah, es zu keksen.

Erst dann wurde mir plötzlich klar, was ich da eigentlich gerade tue: Ich versuche ein Windows-Spiel unter Windows zum Laufen zu bringen. Ich, der ich garnicht Windows verwenden will, und Windows nur boote, weil ich ein Spiel spielen will, strenge mich an, damit dieses Spiel funktioniert. Überhaupt gibt es wenig Gründe für mich, ein Windows-System zu starten. Ich habe mein Ubuntu – und wenn mir das nicht mehr gefällt habe ich Arch Linux. Und wenn mir selbst das nicht gefällt werde ich auf Solaris oder ein BSD umsteigen.

Ich muss mich also auch noch anstrengen, damit ein Spiel, das ich zumindest theoretisch gekauft haben könnte, unter einem kooperativen System läuft. Interessant. Selbstverständlich überlege ich mir nun also zweimal, ob ich mir wirklich eines der kostenpflichtigen Spiele kaufe. Ich hatte schon mehrere Spiele im Sinne, oft auch ältere, nur ist bei denen nie so klar ob sie unter Wine wirklich gut laufen – und bei etwas älteren Modellen ist selbst nicht klar ob sie auf einem modernen Windows gut laufen.

Ok, bevor ich gleich damit anfange, was ich am Verhalten der Spielehersteller alles nicht verstehe, erstmal eine Liste mit Dingen die ich verstehe – nur des guten Willens wegen:

  • Ich verstehe, dass sie ihre Spiele – wenigstens am Anfang – nicht Opensourcen. Kopierschutzmaßnahmen werden durch Open Source nahezu unmöglich. Außerdem steckt in einem Spiel mehr Interesse als bloße Software. Es ist ein Gesamtkunstwerk und man will freilich nicht dass Leute es bereits umschreiben bevor sie es überhaupt sinnvoll gespielt haben.
  • Ich verstehe, dass sie DRM-Maßnahmen ergreifen wollen. Ich finde es nicht gut, vor allem, weil die ganzen DRM-Lösungen so beschissen implementiert sind, aber ich verstehe es.
  • Ich verstehe, dass den Spieleherstellern OpenGL ohne diverse Erweiterungen nicht ausreicht.
  • Ich verstehe, dass Spielehersteller nicht die Portierung auf Betriebssysteme bezahlen wollen, die nicht hinreichend verbreitet sind.

Ja, so viel kann ich verstehen. Jetzt kommt dann mal, was ich nicht verstehe:

  • Ich verstehe nicht, dass sie nicht wenigstens Teile ihrer Spiele oder der verwendeten Spieleengines soweit offenlegen, dass die Geeks sich das Spiel entsprechend selbst portieren können. Der Hauptanteil des Unportierbaren sind wohl die direkten Hardwarezugriffe auf den Grafikkartenspeicher, beziehungsweise die niedrigstufigen Aufrufe der Grafikbibliotheken. Diese kann man ersetzen. Man kann jedenfalls der Wine-Community (die immerhin für eine Portierung auf mindestens 4 zusätzliche Betriebssysteme arbeiten würde) die Arbeit erleichtern durch Zusatzangaben.
  • Ich verstehe nicht, warum die ganzen DRM-Maßnahmen so beschissen programmiert sind. Wie wärs mit: Der Maschinencode ist Verschlüsselt und kann nur mit einem entsprechenden Schlüssel entschlüsselt werden. Und das auch nur indem man ihn meinetwegen irgendwo in den heap speichert und dann an eine definierte Speicherstelle springt. Irgendwas von der Form „ich schau regelmäßig im Internet nach ob du mich spielen darfst“ sollte man jedenfalls leichter wegcracken können. Letztendlich kann man alle Kopierschutzmaßnahmen aber irgendwie umgehen, wenn man ein irgendwie offenes System haben will – und damit meine ich nicht Betriebssystem sondern schon sowas von Wegen nicht so einen komplettgeschlossenen Krampf wie das iPhone oder sowas (und selbst das wird gejailbreaked …).
  • Ich verstehe nicht, warum Spielehersteller und Hardwarehersteller Microsoft so dermaßen in den Arsch kriechen, dass sie sich auf DirectX einlassen. Ich sage nicht, dass DirectX irgendwie extrinsisch schlecht ist, aber es ist intrinsisch schlecht weil nicht Portabel. Als Spielehersteller will ich mich doch nicht Abhängig machen von der Grafikbibliothek eines bestimmten Unternehmens, und schon garnicht von dessen Betriebssystem, an dem dieses Unternehmen wild rumbasteln kann ohne mein Einverständnis. Gleichermaßen will ich das doch als Hardwarehersteller nicht. Im Grunde ist der einzige Sinn von 3D-Grafikkarten auf Heim-PCs, dass man mit ihnen Spiele spielen kann. Das heißt, die Spiele wollen im Wesentlichen an die Grafikkarte, die Grafikkarte will im Wesentlichen an die Spiele, Windows ist nur ein Kleber dazwischen, und die Schicht soll möglichst dünn sein. Wieso tun sich nicht die verschiedenen Spiele- und Grafikkartenhersteller zusammen und machen eine eigene Infrastruktur auf – ich meine, sie müssen doch eh Treiber schreiben, so viel mehr Aufwandt kann das doch nicht sein. Vor Allem das Ganze dann einigermaßen Portabel aufzubauen sollte doch gehen. Immerhin ist doch die Rechenleistung selber selten der Flaschenhals, sondern eher die Grafikleistung.
  • Ich verstehe nicht, wieso jemand Spiele auf Macs portieren will. Einen Mac kauft man sich nicht um Spiele zu spielen. Man kauft ihn sich um mit Mac OS X zu spielen.

Jedenfalls werde ich jetzt also weiterhin lieber versuchen, das Ganze unter Wine zum Laufen zu bringen. Ich glaube die Zeit ist sinnvoller investiert. Spielen kann ich eh vergessen im jetzigen Zustand.


Are shared libraries still appropriate?

Thu, 20 May 2010 18:13:59 +0000

Currently, I am trying to remove some dependencies of Uxul-World. I was thinking of completely kicking LTK – though I like LTK – but as this is just part of the Level-Editor, till now I just thought I should keep it. On the other hand, it produces additional dependencies – lisp-magick right now, maybe I will switch to cl-gd or to my own little ffi-binding. On the other hand, if I did all that stuff directly without LTK, inside SDL, I would just have to use sdl-gfx to stretch and captionize Images.

However, hardlinking with SBCL against ffi-bindings is hard to impossible, and the License of SDL forbids this for free software anyway as far as I remember. Under Linux, SDL may be a default library which is nearly always installed, while under Windows, I dont think so. Under linux, there is no problem with providing a simple package-dependency-list, as long as the packages are not too exotic and can be easily installed. But of course, I also want the game to be playable under Windows, without having to install a whole Unix-Like Environment before. So maybe, under Windows, I should use OpenGL instead. Well, I will see  that.

I am currently not concentrating on portability but on finally getting some playable content into it. In general though, its good to already think about it: I dont want to produce a dependency-hell. I hate dependency-hells. Having a lot of additional dependencies in a software package can really make me sad. Mostly this leads to a lot of strange Download- and Installation-Procedures, since every project has its own policies, and in the end the only thing I have is additional knowledge about small libraries which I didnt even want to know about.

Having libraries like the zlib or libpng linked dynamically is something that really sounds anachronistic to me. Maybe in embedded devices this makes sense, but on every modern PC, the additional memory footprint should be negligibly small. A real dependency-monster depends on thousands of such small libraries, such that the footprint can get remarkable large. When using dynamic libraries, the executable code can be mapped multible times between different processes by the kernel, which needs less memory, and makes the code really „shared“.

But in the end, the only real bottleneck when just hardlinking against everything and deploying large binaries with small dependencies is the Usage of RAM. Neither hard disk space should be an issue nor should the additional needed traffic be.

And again, the solution I would suggest to this could come from deduplication technologies. Assume you download a binary, and execute it. Then the kernel has to read it, and can therefore create an index of checksums of the memory blocks the binary contents. Assuming that mostly the same libraries are hardly linked, and thus, the same or very similar binary code occurs, the kernel will notice that it loaded equivalent blocks into memory already, and can therefore map them together, like it would do with shared libraries. A main difference would be that the pages would have to be mapped as copy-on-write-pages, since some software may change its executable code (willingly or through a bug ). The binary could additionally provide hints for the kernel, for example flags that tell the kernel not to try to deduplicate certain parts of the loaded process image, for it may change or will only be used in extremely seldom cases, or flags telling to what library (and source-file) some memory-pages belonged, so the kernel can optimize the memory-deduplication.

Just to emphasize this – I am not talking about deduplication of all of the RAM-Memory, only about a small procedure run at the start of a new process, which searches for identical pages that are already mapped somewhere. I am sure this would take longer than just softlinking. But it shouldnt take too much additional time, and one could add heuristics for very small process-images not to deduplicate at all to make them load faster.

In any case, I think it would make the work with binaries easier, as well deploying as using, especially outside some package manager. For example it would produce an easier way of maintaining multiarch-systems.

And – imo – it fits more into the world of free software, where you have a lot of chaotic dependencies and a developer cannot keep track of all of these dependencies‘ newest versions and installation procedures, so he would just put everything inside his project directly.

Its basically giving up a bit of infrastructure while getting a new way of solving problems for which this infrastructure was basically created. And it sounds like everything is already there to implement this. Of course, I am not a kernel developer, I cant say how hard it really is. I am pretty sure, in Linux there wont ever be such a thing, but maybe more innovative Operating Systems like Open Solaris could provide it – as Solaris is known for its propensity to new technologies.


Computerprogramm gegen Amokläufer

Wed, 19 May 2010 02:01:11 +0000

Lol schon wieder meint irgendwer er hätte eine Möglichkeit gefunden Amokläufe anhand von Verhaltensmustern programmatisch vorauszusagen, schreibt gulli.com – sorry, das hab ich inzwischen einmal zu oft gehört um es wirklich zu glauben. Dass es Profiling-Software gibt die zumindest Anhaltspunkte geben kann ok. Aber dass man damit irgendeinen Amoklauf wirklich verhindern kann, das bezweifle ich stark.

Zum Einen müsste man damit sehr viele Informationen sehr vieler Personen sammeln – ich denke mal, so viel, dass selbst noch so viele Polizeigewerkschaftspressekonferenzen die Bevölkerung nicht mehr davon überzeugen könnten.

Außerdem sehe ich in sowas eine Gefahr. Die Frage die sich mir stellt: Angenommen, so eine Software würde wirklich funktionieren. Und angenommen, sie würde auf irgendeinen Menschen anschlagen, der sich sonst nichts vorzuwerfen hat. Was soll man tun? Soll man ihn zwingen eine Therapie zu machen? Soll man ihn einsperren? Ich bezweifle, dass das noch irgendwie mit rechtsstaatlichen Prinzipien vereinbar wäre, einen Menschen „präventiv“ einzusperren, vor allem nachdem sich der Gesetzgeber schon so schwer mit dem Stalking-Gesetz getan hat.

Imho produziert so etwas drei Dinge, die wir gerade im Moment am wenigsten brauchen: Angst, Misstrauen und Schuldige.

Schuldige vor Allem im Falle eines Amoklaufs. Denn nicht nur der Amokläufer wird schuld sein, sondern etliche Behörden, die nicht rechtzeitig reagiert haben, obwohl deren Profiling den Amokläufer frühzeitig erkannt hätte. Wir haben in letzter Zeit sowieso schon viel zu viele Mitschuldige bei jeder sich bietenden Gelegenheit. Anstatt eines komplizierten Computerprogramms das versucht einzelne Täter herauszupicken sollte man vielleicht eher nach den gesellschaftlichen oder sonstigen Gründen für die – angeblich – gestiegene Anzahl an Amokläufen in der letzten Zeit suchen.

Misstrauen vor Allem gegenüber dem Staat und der Polizei, die noch mehr Daten von uns sammelt, und diese möglicherweise in großen Datenbanken ansammelt, die dann – wie so oft – von irgendwem Gehackt werden, der damit die Persönlichkeitsprofile vieler Menschen hat. Außerdem ist ja nicht auszuschließen, dass die Daten die gesammelt werden fehlerhaft sind, und es ist auch nicht auszuschließen, dass sie wissentlich manipuliert werden. Und, wenn jemand erstmal als potenzieller Amokläufer stigmatisiert wurde, wird er eine sehr schlechte Position haben eine solche wissentliche Manipulation aufzudecken und sich dagegen zu wehren. Das Letzte was wir brauchen ist noch mehr Misstrauen gegenüber dem Staat. Davon gibt es eh schon genug.

Das Schlimmste ist wohl die zusätzliche Angst. Zunächst mal wird die Angst vor Amokläufen dadurch wohl eher verstärkt als geschwächt. „Die da oben“ werden ja schließlich ihre Gründe haben, warum sie so eine Maßnahme einführen. Zusätzlich zu der Angst vor neuen Amokläufen kommt die Angst davor, sich irgendwie auffällig zu verhalten, und selbst fälschlich als potenzieller Amokläufer „erkannt“ zu werden. Man wird von solchen Fällen hören (denn es wird sie sicher geben), und sein Verhalten unbewusst anpassen. Wahrscheinlich wird es dann irgendwann Kurse geben, wie man sich verhalten soll, um nicht erfasst zu werden.

Was ich damit sagen will ist nicht, dass ich eine solche Technik grundsätzlich sinnlos finde. Im Gegenteil, der Einsatz von Computern in der Psychologie ist sowieso etwas was ich ziemlich stark vermisse irgendwie. Ich rate nur zur extremen Vorsicht. Das Wissenschaftsteam wird – wie die meisten guten Wissenschaftsteams – vor Allem Nerds beinhalten, die von ihrer Sache fasziniert sind und dementsprechend diese auch benutzen wollen. Die Politiker werden wie üblich höchstens die Hälfte verstehen aber meinen, es sei ja ihre Aufgabe das Volk mit allen Mitteln vor Gefahren zu schützen. CCC und Konsorten werden das Ding unter die Lupe nehmen, kritisieren und wie üblich erstmal ignoriert werden.

Darum rate ich zur Vorsicht von vorne herein. Ich halte Derartiges für interessant aber auch hochgefährlich.


„Entwicklungsland“ Indien

Wed, 19 May 2010 01:15:48 +0000

Das als Entwicklungsland bekannte Indien will offenbar ein eigenes Betriebssystem schreiben, um Unabhängig von speziellen Anbietern und Staaten zu sein.

Damit sind sie schon mal schlauer als unsere Helden mit ihren seltsamen Mautplänen und diversen Wahlcomputern oder dem Verschenken von Volkseigentum.


Neues Notebook, neues Glück

Tue, 18 May 2010 04:26:38 +0000

W00t, endlich, ich habe ein neues Notebook. Ein Lenovo ThinkPad X200 Tablet. Momentan renne ich das vorinstallierte Windows und Xubuntu drauf.

Xubuntu vor Allem, weil ich eh einen Xubuntu-Stick hatte, und weil ich mit der Hardware darin und mit dem Konfigurieren solcher Tablets keinerlei Erfahrung habe, und ich deshalb erstmal etwas nehmen wollte, was einigermaßen automatisiert geht.

Vermutlich werde ich irgendwann wieder Arch Linux verwenden. Aber jetzt bin ich erstmal mit meinem Xubuntu zufrieden.

Leider gehen noch ein paar Sachen nicht, zum Beispiel kriege ich es noch nicht hin, bei entsprechenden ACPI-Events die Bildschirmanzeige zu drehen, das muss ich noch manuell per Commandline machen. Aber ich denke, das ist nur eine Frage der Zeit.

Jetzt kann ich vor Allem endlich wieder sinnvoll an meinem Jump And Run weiterprogrammieren, weil ich einen gescheiten Rechner habe, bei dem ich auch vorhabe, ihn auf längere Sicht hin zu haben.


Software that should exist #7: File-Allocation without Nullifying

Sun, 16 May 2010 03:26:26 +0000

I dont know about you, but I had this problem more than once: I just need a large file on my disk with no specific content to create some other fs on it. For example when creating Live-CDs, additional Swapfiles or just Test-Volumes for exotic filesystems or virtual machines, I need a big file on which I can then perform filesystem-creation and stuff. The default way to do this is to run dd with appropriate blocksize and blockcount options, let it read from /dev/zero, and write into the file. The problem here is that I then not just allocate the file but also overwrite it with zeroes. In many cases, this would not be necessary. The main reason for using /dev/zero is that /dev/zero is the fastest device one can get to get some data – but actually, I mostly dont care and the only reason for not using /dev/urandom is that /dev/urandom is a lot slower.

So, it would be nice to be able to say „give me a file with size … and random content“, such that the kernel does this by just allocating free blocks into a file, but not overwriting them, thus, the only write-accesses on the disk will be the ones for filesystem-headings like inode-tables, etc.

Problematic with this approach – and therefore probably the reason why this is no default mechanism – is that if every user could do this, the user would possibly be able to access blocks of files that shouldnt be seen by this user, i.e. blocks of files which have already been deleted but needed higher read-permissions. On the other hand, as root, there should be no such problem at all.

One possible solution which sometimes suffices is the creation of sparse-files, but only if the underlying filesystem supports sparse files, and even then, for most of the problems mentioned above the access becomes painfully slow, since the blocks have to be allocated ondemand, while the programs assume to get a blockdevice. Most mkfs-instructions will at least require some kind of „force“-option to create a filesystem on a sparse-file anyway. Loopmounting will most probably fail. Using a sparse file as swap-file isnt allowed at all (at least without strange kernel-patches).

Another solution comes – as far as I read – with ext4, which allows creating files which are nulled „virtually“ in the beginning, without having to be overwritten first. Except that I dont really like or trust ext4, since it doesnt bring the features btrfs would bring, but also doesnt seem to be a lot more stable, this is a solution on the filesystem-level. Unfortunately, such problems mostly arise in situations when you didnt choose the filesystem with respect to this or cant choose your filesystem anyway. There has got to be some more general solution.