Re: Xorg mal wieder

On Wed, 20 Aug 2014 00:40:21 +0200, Marc Santhoff wrote:
> On Di, 2014-08-19 at 23:17 +0200, Polytropon wrote:
> > On Tue, 19 Aug 2014 22:53:08 +0200, Marc Santhoff wrote:
> > > Und bei der Zahl von
> > > Bibliotheken, aus denen man sich was greifen kann, wird es
> > > unübersichtlich(st).
> >
> > Dafür gibt es eine "Lösung", die gern bemüht wird: Abstraktion.
> > Man legt einfach eine abstrahierende Bibliothek drüber, die das
> > vereinheitlichen soll. Und noch eine. Und noch eine wegen der
> > Kompatibilität. Und dann noch eine wegen unterschiedlich. Und
> > noch eine wegen bequemerem Zugriff... und schon hat man das,
> > was den typischen Bloat verursacht, weil sich keiner mehr "die
> > Finger dreckig machen" will oder Angst vor Zeigern hat. :-)
>
> Kommt mir jetzt aktuell bekannt vor. Ich hatte geguckt, was man für
> Android-Programmierung auf unterstem Level braucht, wenn man FreeBSD
> benutzt:
>
> Android-SDK (nur Lunix, Mäc, Win)
> also:
>
> FreeBSD
> VirtualBox
> Debian irgendeiner Geschmacksrichtung
> Java VM
> Eclipse
> Android Emulator
>
> Ordentlich hochgestapelt ...

Mit Firefox OS wäre das bequemer: Hier sind alle Apps im Grunde
Webseiten. Ihre Struktur wird durch HTML, ihr Aussehen durch CSS
und ihre Funktion durch JavaScript repräsentiert, von wo aus auch
der Zugriff auf die Gerätefunktionen erfolgt. Mozilla bietet dafür
ein beeindruckendes Entwicklerpaket an, das rund um den Firefox-
Webbrowser aufgebaut ist, inklusive Endgeräteemulator. Von allen
aktuell verfügbaren Smartphone- und Tabletplattformen scheint dies
das kleinste Übel zu sein - die Alternativen sind alle irgendwie
abschreckender, in zunehmendem Maße, je teurer es wird. ;-)

Bei Android wäre die Frage: Das ist Java-lastig, gibt es da keine
nativen Tools für FreeBSD? Java haben wir, Eclipse auch. Was ich
mir als problematiscch vorstellen kann, wäre der Android-Emulator
und der Zugriff auf das Entgerät selbst. Aber ich bin auch kein
App-Entwickler, ich habe davon kaum Ahnung, denn ich traue diesen
Smartphones nicht weiter, als ich sie werfen kann. :-)

> Außerdem finde ich schon, daß manche Weiterentwicklung durchaus Sinn
> macht. Ich möchte jedenfalls nicht mehr in Assembler programmieren, was
> ich sogar unter Windows (16 Bit) noch ausprobiert habe. Ging, hat Spaß
> gemacht. Zeiger direkt anfassen kann man in Fällen, wo es nötig ist und
> in die Umgebung paßt, tun. Leider kann man dabei aber so viele Fehler
> machen, daß eine typsichere Programmiersprache einfach besser ist (nur
> _ein_ Beispiel von vielen). IMO.
> Das heißt nicht, daß Bibiotheken übereinanderstapeln eine gute Sache
> wäre.

Man muß das hinsichtlich der Ausgewogenheit und der faktischen
Anforderungen sehen. Da, wo Ressourcen knapp sind, sind die
hardwarenahen Programmiersprachen (Assembler und C) gern gesehen,
denn sie werden auch von "geschultem Personal" bedient. Wo es
auf Schnelligkeit der Entwicklung ankommt, nutzt man gern
bestehende Tools (Bibliotheken und existierenden Code), um
das Rad nicht zum 100. Mal neu erfinden zu müssen. Klar, da
ist oft der Ressourcenverbrauch höher, aber die Plattformen,
wo das vorkommt, haben mehr als genug davon. Wenn man einfach
mal bedenkt, daß der "Wirkungsgrad" eines herkömmlichen PCs
mit seinen Zehnmelonenhundertgigahertz und fette Grafikkarte
nur knapp 10% beträgt (schlechter als eine Glühbirne), dann
ist es vertretbar, diese Ressourcen auch zu nutzen, wenn man
sich damit vor "Eins daneben" oder "Ups, jetzt habe ich mich
selbst überschrieben" schützen kann. Das heißt nicht, daß man
unendlich stapeln kann - irgendwann muß man "neu anfangen".

Das dauerhafte Mitschleppen von Infrastrukturen, die keinen
Nutzwert haben, macht Weiterentwicklung natürlich schwierig.
Schau als Beispiel in die "Windows"-Welt: Dort werden Krücken
aus "Windows 1.0"-Zeiten bis in die aktuell veraltete Version
"Windows 8.1" mitgeschleppt, dann wird dazugeklebt, drumherum-
gebaut, nachgebessert, und auf dem Weg zerbricht trotzdem immer
wieder was, und "geschäftskritische Applikationen" von "führen-
den Unternehmen" fallen plötzlich ersatzlos auseinander. Und
da keine Quelltexte verfügbar sind, geht das Rätselraten los.

FreeBSD erneuert solche "Speisereste" in entscheidenden
Feldern nur langsam, auch der "Neubau" von Funktionen erfolgt
nicht so schnell wie unter Linux. OpenCL oder neue WLAN-
Standards sind da ein gutes Beispiel. Die Gründe dafür sind
meiner Ansicht nach Designentscheidungen, die früher mal
getroffen worden sind und die sich heute nicht auf einen
Schlag revidieren lassen. Man muß aber eben anerkennen,
daß FreeBSD ein von Linux verschiedenes Betriebssystem ist.
Nein, das macht es nicht besser, aber vielleicht verständlich.
Aufgrund seiner geringeren "Marktdurchdringung" haben Hersteller
FreeBSD nicht so auf dem Schirm, es ist nicht so "medienwirksam"
in den Bestrebungen, eine Alternative zu "Windows", das für mehr
und mehr Bereiche der IT untragbar wird, zu schaffen. Das ist
ein sehr langsamer Prozeß, den MICROS~1, aber auch Intel, AMD
oder nVidia mit Einsatz von viel Geldmitteln in bestimmte
Richtungen und Geschwindigkeiten lenken ("Bremsen"). Aber
es gibt Trends: Offene Hardware, offene Software, ARM statt
x86, energieeffizientere PCs, weg vom PC, die Cloud, funk-
tionierende Verschlüsselung und so weiter. Anzunehmen, daß
es da eine eierlegende Wollmilchsau ("one size fits all")
geben könnte, ist meiner Ansicht nach unrealistisch. Der
Schlüssel ist also Interoperabilität in heterogenen Systemen.

> Dokumentation ist irgendwie ein Sonderfall: Wer dokumentieren könnte,
> hat keine Lust. Wer Doku braucht, kann es nicht. Und wenn letzterer
> erstmal verstanden hat, wie's geht, braucht er keine Doku mehr ... ;)

So schön hätte ich das nie formulieren können. :-)

Dokumentation ist für den Endanwender solange uninteressant,
wie alles funktioniert. Mit "trial & error" kann man sich
leicht Funktionen eines Programms erschließen. Probelmatisch
wird es, wenn etwas _nicht_ mehr funktioniert und man es
diagnostizieren will. Als Entwickler sehe ich das sogar noch
kritischer: Was nützt mir eine Library, die ich benutzen
will, wenn ich nicht weiß, wie es funktioniert? Für Leute,
die etwas erschaffen, programmieren, ist Dokumentation ein
oft notwendiges Werkzeug. Wie sagte einer meiner Professoren
an der Uni so treffend? "Aufpassen: 'Trial and error' ist _kein_
Programmierkonzept!" :-)

> > > Das ist für GTK normal, Evolution, claws mail, etc. müllen auch solche
> > > Meldungen raus. Ich bin mir nicht ganz sicher, aber scheinbar wird da
> > > jede programmintern normale "Exception" behandelt wie ein meldenswerter
> > > Programmfehler. Das kenne ich seit GTK1 und bisher war nichts wirklich
> > > fatal kaputt, wie ich an einem Eigengewächs, dessen Code ich natürlich
> > > beurteilen kann, feststellen konnte. Vielleicht gibt es sogar einen
> > > Compilerschalter bzw. ein #define um den Unsinn abzuschalten.
> >
> > Diese Meldungen, oft mit "warning" oder sogar "critical",
> > scheinen aber keine Programmfunktionalität als "geht nicht"
> > zu kennzeichnen - es geht nämlich alles. Noch fürchterlicher
> > ist es, sich .xsession-errors duchzulesen:
> >
> > (process:2980): Gtk-WARNING **: Locale not supported
> > by C library. Using the fallback 'C' locale.
> >
> > Wir Deutschen sind halt nur Nutzer zweiter Klasse.
>
> Dafür sind wir Deutsche erster Klasse. ;)
> Über sowas rege ich mich schon lange nicht mehr auf. Doof für Leute ohne
> englische Sprachkenntnisse. Oder jene, die Zahlen bitte mit Komma als
> Trenner benutzen möchten. sed, awk. Aber da geht es ja los, wieder das
> Problem nicht an der Wurzel angefaßt ...

Daher hoffe ich, daß der unter PC-BSD neu entwickelte Desktop auch
irgendwann so gut ist, daß er auf Deutsch benutzt werden kann. Nur
unter dieser Voraussetzung haben "normale" Menschen Zugang zu
Computertechnik, die sie nicht ausspioniert, betrügt, manipuliert
und abzockt. Ja, auch heute, im Zeitalter der "Weltsprache Englisch",
ist das keine Selbstverständlichkeit: Die Sprachbarriere existiert.

Ich persönlich ziehe einen gut verständlichen englischen Text einer
stückelhaften, unklaren oder falschen deutschen Übersetzung vor,
aber wie gesagt: Ich bin ja auch vollkommen wahnsinnig. ;-)

> > Oft und gern wiederholt:
> >
> > open: No such file or directory
> >
> > Super. Da weiß man sofort, welches Programm, welche Datei und
> > welches Verzeichnis. Was ich oben über Dokumentation sagte,
> > scheint auch auf Fehlermeldungen zuzutreffen.
>
> Ja, da fühle ich mich gleich wie zuhause unter Windows.

Fehler! Es ist ein Fehler aufgetreten. Fehler: Fehler.
Wollen Sie neustarten? Ja / nein / alle. :-)

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message