Software

Zebuntu heißt nun zeVenOS, aus irgendwelchen rechtlichen Gründen. Bernd Korz (der Mensch hinter Zeta) ist auch nicht mehr dabei, und irgendwie ist das Ding eh etwas seltsam: "yet another Ubuntu distro", mit "BeOS touch".. Hmm..

Naja, scheint, als ob der Hauptentwickler von dem System einfach eine nette Zusammenstellung neuer Defaults und Tools in ein ISO-Image presst. Zu Open Source-Entwicklung hat er jedenfalls folgendes zu erzählen:

Als Schlusswort, Vielfalt, ist je wie man es sieht ein Vorteil oder Nachteil von freier und offener Software. Ich sehe Vielfalt eher als einen Vorteil, solange man sich an Standards hält. Sprich man entwickelt sich z.B. nicht seinen eigenen Kernel oder Treiber.
Dies wurde nämlich bereits einmal gemacht. Damals hieß das System Unix. Dies war der Untergang des Systems. Es setzte sich gerade auf dem Desktop überhaupt nicht durch. Die Inkompatibilitäten unterseits führen auch gerade jetzt dazu, dass immer mehr Firmen weg von Unix Servern hinzu Linux Servern wechseln.
Meiner Meinung nach sollte es nicht daraufhin herauslaufen, dass man nur einen Linux Desktop und damit eine Distribution anbietet, denn dann hat man eine ähnliche Situation wie mit Microsoft Windows heutzutage. Aus der Lizenz zu schließen, wird es auch nie zu so etwas kommen können.

Von der historischen Verzerrung (die Unix-Systeme unterschieden sich nicht primär duch einen "eigenen Kernel oder Treiber", sondern in aller Regel durch unterschiedliche Architekturen, auf denen sie liefen, und - schmerzhafter - inkompatiblen APIs für Anwendungsentwickler) mal abgesehen frage ich mich, was dieser Seitenhieb gegen nicht-Linuxsysteme (etwa Haiku, Syllable, ...) denn soll. Und dabei lasse ich mal außen vor, dass Linux selbst nur ein "me too"-Projekt ist (BSD in seiner Gesamtheit ist älter).

Unixoide Kernel sind trivialer Kleinkram (der dann beliebig aufwändig optimiert und verbessert werden kann), der zu Dutzenden in irgendwelchen Uni-Kursen von Studenten zusammengefrickelt wird. Treiber sind (dank Linux, FreeBSD und OpenBSD) auch kein Problem mehr - man kann sie bei Bedarf relativ schnell portieren (außer Grafikkartentreibern, da besteht Vendor-Lockin - im OSS-Bereich).

Es ist ein überschaubares Problem, einen Kernel mit einer handvoll Treibern zusammenzustellen (Beweis durch Aufzählung: Syllable, Haiku, SkyOS, Linux - und die hunderte von "Spielzeugkernels", denen "lediglich" der Überbau fehlt - also Userspace, lasse ich mal weg).

Einen wirklich guten Desktop gibts irgendwie noch nicht.

Wenn ich mir die Freedesktop.org-Spezifikationen so ansehe, wird ein guter Desktop "kompatibel" auch kaum möglich sein (nun, alles abhängig davon, was "gut" nun eigentlich bedeutet).

Diese Spezifikationen bauen einen immer größeren Stack auf, um Probleme relativ weit "oben" zu bearbeiten, die "unten" eventuell besser gelöst wären: Message Passing? Klar, Userspace Daemon ("D-BUS"). BeOS macht sowas mit per-Thread Message Queues (Kernel-Support). Aber das wäre ja nicht "Unix" (was auch immer das dann heißt).

Man muss also, um "kompatibel" zu sein (ein Erfolgskriterium, nach obigem Quote) 150MB Bloat im RAM rumschleppen, und hunderte von APIs implementieren und nutzen, um so grundlegende Geschichten wie Interprozesskommunikation abzuwickeln. Oder einem Window Manager Support für die ca. 700 Hints mitgeben, mit denen man X11 soweit aufbohrt, dass es doch wieder halbwegs state of the art ist. Oder einen Composition Manager implementieren, damit die modernen Grafikeffekte umgesetzt werden können (der kann - realistisch gesehen - eh nur lokal laufen, aber wo man ja schon so einen tollen Kommunikationskanal, eben das X11-Protokoll, hat, muss man den ja auch nutzen - also: noch mehr Komplexität, um diese Gigabytes an Bitmaps irgendwie durch ein Netzwerkprotokoll zu schieben).

Man kann sich das Problem aussuchen: Kompatibel sein, was bedeutet, dass man jede Menge Zeugs übernimmt oder neu implementiert, das man vielleicht gar nicht haben wollte, wodurch man am Ende auch nicht wirklich vom Rest zu unterscheiden ist (und wenn man eh nur "noch eins" macht, warum dann eigentlich - außer zu Lehrzwecken?).

Oder etwas neues schaffen - mit allen Problemen, die sich dadurch auftun: neue Schnittstellen, wenig Software, Fragmentierung des "Marktes" - eben den Problemen, mit denen sich die UNIX Systeme rumgeschlagen haben. Linux "löste" diese Probleme durch - Monokultur (womit wir bei Windows wären, was im Quote ja auch schon besprochen wurde).

Gemäß meiner Theorie, dass Kompatibilität gute Entwicklungen zu sehr einschränkt: Wird zeVenOS nun kompatibel, oder wird es gut?

Nur ein kleiner Nachtrag: ich habe GCC nicht beibringen können, __udivdi3 andere Aufrufsemantik zu geben, als den Default, von daher bleibt -mregparm=3 bei meiner GRUB2-Variante deaktiviert.

Es geht aber, theoretisch: __attribute__ ((regparm(1))). Den kleinen Kniff habe ich gefunden, als ich die handvoll Assemblerfunktionen verarzten musste, die auf regparm(3) basierten.

Habe ich schonmal Qemu über den grünen Klee gelobt? Nein? Dann wird es höchste Zeit dafür:

Wie letztens schon einmal erwähnt, ist Qemu zusammen mit einem Debugger (GDB) eine super Möglichkeit, Code zu singlesteppen, an den man sonst nicht so leicht rankommt. Und auch ohne Debugger ist es sehr angenehm, Treiber zu schreiben oder sonstigen Lowlevel-Krams zu machen, ohne alle 3 Minuten rebooten zu müssen (bzw. nur eine virtuelle Maschine starten zu müssen).

Virtuelle Maschine - da gibts aber auch andere. Ja, die gibt es. Aber außer Bochs (und VirtualBox, dass seinen eigenen Katalog an Problemen hat) ist keins zu dem in der Lage, was ich heute brauchte: Die Möglichkeit, die emulierte Hardware zu tracen (printf-Debugging), um so den Bug in meinem Treiber zu identifizieren.

Qemu hat definitiv auch seine Macken, aber insgesamt ist es doch ein wirklich praktisches Tool.

"Some attributes in sysfs need a terminating newline, some don't, so try both." - heißt es in einem Changelog eines Ubuntu-Packages. Das bedarf keines weiteren Kommentars von meiner Seite.

Zur Problematik mit dem Verständnis, das Notes von "Autoren" hat, habe ich mich schon einmal ausgelassen.

Wenn man ein Dokument von mehreren Autoren bearbeiten lassen will, reicht der Trick, "@Username" evaluieren zu lassen, allerdings nicht aus. Um allen Autoren Schreibrecht auf das Dokument zu geben (in diesem Fall war es eine Art Zähler), ist die richtige Lösung, einen festen Wert "*" in ein Autorenfeld zu legen, wodurch (Wildcard-sei-Dank) jeder Autor berechtigt ist, das Dokument zu editieren (Dokumenteneigenschaften beachten!)

Nachdem ich im letzten Eintrag angemerkt habe, womit ich zu kämpfen hatte, hier die Lösung: gcc -mregparm=3 ist eine nette Möglichkeit, in stand-alone Code dafür zu sorgen, dass der Code ein wenig kleiner und schneller wird. Allerdings muss der Code auch wirklich stand-alone sein, und nicht etwa auf fremde Funktionen aufbauen - etwa aus libgcc.. Ups

Nachdem ich den Tree ohne die Option hab bauen lassen, funktionierte dann auch alles. Und da diese Option vor allem aus Platzgründen genutzt wurde, wir in Coreboot aber etwas mehr Platz haben, als die paar Sektoren in der ersten Spur der Festplatte (in die der "normale" GRUB2 reinpassen muss), geht das auch noch..

Seit OS X 10.5 werden nicht-Apple AFP-Server nicht mehr ohne weiteres gefunden. Das liegt diesmal nicht daran, dass AFP mal wieder verändert wurde, sondern dass für den Lookup nun mDNS alias Zeroconf alias Bonjour, statt appletalk verwendet wird.

Mit dem Wissen ist die Lösung dann auch denkbar einfach:

Read More

Brad Eckert fasst in seinem Post auf comp.lang.forth ganz gut zusammen (finde ich), was im gesamten Thread so los war. Read More

Nachdem ich bei Trolltech nachgefragt hatte, und nach langer Zeit tatsächlich eine Antwort erhielt, ist es nun soweit:

Qt 4.3.3 hat eine Ausnahmeregelung für Software unter der CDDL, nachdem schon für einige andere Lizenzen, darunter die MPL eine derartige Regelung galt.

Dank auch an Simon Phipps, über dessen Blog ich die Änderung mitbekommen habe.

Gestern gabs mal wieder Gottesdienst bei Apple, mit einigen Neuigkeiten, darunter das MacBook Air.

Die üblichen Nachteile sind wohl alle schon ausreichend diskutiert worden (nur 1 USB Port, kein DVD-Laufwerk, kein Ethernet, kein Audio-in, PATA-Festplatte statt SATA), aber was mir beim Durchlesen der Werbe-Webseite aufgefallen ist: "2GB of 667MHz DDR2 SDRAM onboard" - heißt "onboard", dass der Kram aufgelötet ist, so wie "damals"? Wenn man also jemals mehr RAM braucht, wars das?

Oh, der Akku ist auch nicht auswechselbar. Das wird viel Spaß für den Apple Support in 2 Jahren: Akkus tauschen lassen, aber ja die Festplatten nicht anrühren.

Auch lustig: Die Apple-Fanboys (und -girls) sind schon schwer im Verteidigungsmodus. Die CPU ist langsamer? - "Wer nutzt die Performance seines Rechners heutzutags überhaupt?" uswusf.

(Passt nicht ganz in die Kategorie "Software", aber Apple propagiert ja immer "Think Different", von daher passt es wohl doch.)

"Fitts' Law" ist eine der populärsten Regeln aus dem Bereich der HCI (Human-Computer-Interaction). Es geht dabei (grob gesagt) darum, wie leicht ein Ziel auf dem Bildschirm mit der Maus zu treffen ist.

Unter anderem wird abgeleitet, dass die Bildschirmkanten (und noch mehr, die -Ecken) gute Ziele sind, da sie "unendlich hoch" (bzw. weit oder beides) sind, was insbesondere von MacOS-"Freunden" gern angebracht wird, wegen der globalen Menuzeile.

Leider ist Fitts' Law ziemlich uninteressant geworden...

Read More

Der WebKit-Port für Haiku ist ja schon länger in der Mache - erstmals gibts nun aber einen Screenshot, was vor allem daran liegt, dass jetzt ausreichend Bugs gefixt sind, dass die Darstellung bis zu diesem Punkt funktioniert.

Auch schön ist: das WebKit/KHTML-Team scheint ernsthaft dran interessiert zu sein, auch solche "Nischen"-Systeme zu unterstützen - der Haiku-Code dürfte, wenn er soweit ist, in den offiziellen WebKit-Sourcen unterkommen.

Zum Beispiel Factor: Einfach mal so Plattformsupport rauswerfen ist tödlich, denn wer sagt, dass nicht als nächstes die eigene dran ist?

Toll: tagesschau.de bietet die Audio Clips aus dem öffentlich-rechtlichen Radioprogramm auch im Ogg Vorbis Format (Beispiel) an. Und als nächstes auch die Videoclips?

Ich lese mich momentan in das Design von Forth-Metacompilern ein. ForthV3 ist mein Port der ForthV2-Codebase (wie kreativ) von Assembler zu Forth. Leider reicht meine Erfahrung mit Forthsystemen langsam nicht mehr aus. Jeff Fox hat da einige gute Ideen dokumentiert. Ansonsten ist Moving Forth ein guter Referenztext zum Design von Forthsystemen, auch wenn der Code mittlerweile unter GPLv3 released wird (was für Forth-code meiner Meinung nach nicht wirklich Sinn ergibt) - aber um den Code gehts mir ja nicht.