Einträge für datenritter

Wer sich nicht mehr an die (optisch) scheußlichen Anfangsjahre des Webs mit quitschbunten Farben und aggressiven Kontrasten erinnert, bekommt durch den Geocities-izer einen ungefähren Eindruck, wie es war, als Anfänger ihr HTML noch mit Sekundenkleber zusammengehalten haben. Bis sich einfache Design-Grundlagen in der Breite durchgesetzt hatten, dauerte es Jahre. Jahre, in denen helle Schrift auf dunklem Grund generell in Verruf geriet.

Vielleicht zu unrecht. Helle Farbschemata sind zwar leichter zu handhaben und bergen ein geringeres Risiko, das Auge des Betrachters zu beleidigen. Aber Microsoft eine gewisse große Softwarefirma, die angeblich viel Usability-Forschung betreibt, ist beispielsweise zu kontrastärmeren Kombinationen übergegangen und nutzt einen blauen Hintergrund. Das Blog philosecurity ist in Grautönen mit heller, zum Teil sogar gelber, Schrift gehalten. Der Webshop von getDigital hat ebenfalls ein sehr dunkles Schema (jedoch hellen Hintergrund in den Produktbeschreibungen). Der ColorScheme Designer ist selbst dunkel und hat eine Vorschaufunktion für helle und dunkle Seiten. In einem c't-Artikel über Typografie im Web stand, weißer Text auf dunklem Grund durchaus seine Berechtigung haben. (Gründe gab der Autor aber nicht an. Vielleicht dachte er ja nur an Star-Trek-Fansites.)



Klar ist, dass für selbstleuchtende Medien durchaus andere Regeln gelten können als für Papier. Bildschirme sind oft brutal hell und strengen das Auge an. Menschen, die unter ausgeprägten Floaters (Mouches volantes) leiden, haben tatsächlich Vorteile von gelber oder weißer Schrift auf grauem Grund, denn die dunklen Wölkchen, die im Auge herumschwimmen, nimmt man nur wahr, wenn man gegen einen hellen Hintergrund sieht. Andererseits sieht man auf einem überwiegend dunklen Glare-Type-Display bei heller Umgebung nur noch Reflexionen.

Testweise habe ich vor ein paar Wochen in kpdf weiße Schrift auf dunkelgrauem Grund eingestellt. Meine Konsolenfenster waren schon immer schwarz, und die Farben in Iceweasel (Thunderbird) habe ich mit Mühe ebenfalls verändert.

Ergebnis: Die "Leseerfahrung" ist nicht schlechter. (Eine stärkere Aussage wäre aufgrund dieses völlig unwissenschaftlichen Experiments unseriös.) Gerade bei PDF-Dokumenten scheint die Konzentration höher, das Auge weniger angestrengt. Vielleicht lohnt es sich auch für andere, das mal auszuprobieren.

Ich probiere jetzt auch mal Flattr aus. Kristian Köhntopp erklärt einigermaßen kurz, was das ist. Noch kürzer: Ein sozialer Micropayment-Dienst. Man klickt, weil einem ein Beitrag (oder irgendwas anderes) gefällt, der Empfänger bekommt dafür etwas Geld. (Robert Basic rechnet vor, wieviel.)


Flattr passt irgendwie zum Internet, das es jedem ermöglicht, zu publizieren, aber bisher außer Werbung kaum Einnahmequellen bietet. Vielleicht erleben wir eine kleine Revolution. Vielleicht auch nicht...

"Flattr" vollständig lesen »

Isotopp erklärt in seinem Eintrag "WLANs mappen", weswegen man Kennungen und Positionen von WLAN-Access-Points aufzeichnet und wie sie zur Positionsbestimmung mit Smartphones verwendet werden. Er reicht ihm, "um den Kunden zu finden, das ist alles was ich will, danke sehr."

Klugscheißmodus an.

Nun sind Argumentationen, die mit "ich will nur..." anfangen entweder falsch oder enden mit der Installation von Linux. ;)

Isotopp betont nicht genug, dass er ein Telefon-GPS, also eher ein Spielzeug, mit WLAN-Navigation vergleicht. Irgendwann wird mal jemand in der Wüste umkommen, weil er dort mit einem Smartphone rumgelaufen ist.

Jemand anderes schreibt in den Kommentaren, sein Mobiltelefon habe den besseren Kompass als seine GPS-Geräte. Dazu muss man wissen, dass die Kompasse, von denen wir sprechen, alle elektronisch sind. Sie müssen immer wieder kalibriert werden. Und welcher Sensor genau verbaut ist, oder ob sich die Geräte nur in der Software unterscheiden, ist unklar. Elektronische Kompasse sind auf jeden Fall mit Vorsicht zu genießen.

Zurück zur Navigation: Ein dedizierter GPS-Empfänger funktioniert auch unter widrigen Bedingungen ausreichend gut und vor allem viel besser, als man beim Lesen des Artikels denken könnte. Nur halt nicht immer hausnummerngenau – was am Kartenmaterial liegt und auch nicht seine wichtigste Aufgabe ist.



Um "zum Kunden zu kommen" haben die meisten Menschen ein Auto. Ein Auto-Navigatsionssystem funktioniert in der Regel auch in der Stadt problemlos, und man kann sich ein größeres Display erlauben und einen höheren Stromverbrauch. Man kann dort natürlich auch sein Smartphone anschließen. (Dann kann man auch während der Fahrt twittern…)

Auf dem Fahrrad braucht es bei sportlicher Fahrweise bereits ein robusteres Gerät mit direkter Bedienung.

Wer aber auf dem Land, im entfernten Ausland oder auch mal abseits befestigter Wege unterwegs ist, will definitv ein richtiges GPS, das auch vom Fahrzeug getrennt lange durchhält, den Akku des Kommunikationsgeräts nicht belastet, mit der Situation (auch: Temperatur) angepassten Batterien betrieben wird und auch noch funktioniert, nach dem es 40 Meter tief in die Stromschnellen gefallen ist und drei Stunden lang gesucht werden musste, während ein Nilpferd darauf Mittagsschlaf gehalten hat.

Das Mobiltelefon ist also nur für die innerstädtische letzte Meile vom Parkplatz zum Kunden gut, danke sehr.

Klugscheißmodus aus.

Wieder mal ein Grund, sich ungebremst über die Linux-Welt zu freuen: Traffic Shaping mit Squid.

Wenn man seine Bandbreite fair verteilen will, dann hat man mit einem Proxy ein Problem. Der Proxy ist im Upstream Quelle aller Anfragen, die können also nicht nach User unterschieden werden, egal was man vorher in der mangle table angestellt hat. Ohnehin ist Shaping im Upstream von begrenzter Nützlichkeit.

Im Downstream kann man die Bandbreite zwar fair verteilen, muss sich dann aber nach der Geschwindigkeit des Netzwerkes hinter dem Proxy richten. Das ist meistens langsamer als das Netz, aus dem die Anfragen kommen. Zum Beispiel wenn der Proxy zwischen einer DSL-Leitung und einem schnelleren LAN sitzt. Der Vorteil des Proxys, dass er zwischengespeicherte Daten schneller ausliefert als die DSL-Leitung es könnte, wäre bei einem solchen Shaping dahin.

Squid 3 kann deshalb Pakete abhängig davon, ob die gelieferten Daten aus dem Cache kommen oder nicht, markieren. Anhand der Markierung sortiert man die dann in verschiedene Qdiscs oder Klassen — einmal Bandbreitenmanagement mit DSL-Geschwindigkeit, einmal mit LAN-geschwindigkeit. Problem gelöst.

Aus der Doku:

This setting is configured by setting the source TOS values:

local-hit=0xFF Value to mark local cache hits.

sibling-hit=0xFF Value to mark hits from sibling peers.

parent-hit=0xFF Value to mark hits from parent peers.

(...)
disable-preserve-miss
If set, any HTTP response towards clients will
have the TOS value of the response comming from the
remote server masked with the value of miss-mask.

miss-mask=0xFF
Allows you to mask certain bits in the TOS received from the
remote server, before copying the value to the TOS sent
towards clients.
Default: 0xFF (TOS from server is not changed).

Update 2010-04-28: Ok, ich hätte vielleicht erwähnen sollen, dass Squid3 dazu mit --enable-zph-qos kompiliert werden muss. Im Debian-Paket ist das nicht der Fall, es führt also kein Weg dran vorbei.

Eine 5.25" breite Quantum Bigfoot mit einer Kapazität von 4GB musste für dieses Experiment sterben:



Das Video stammt wohl von Thomas Pfeifer.

Schon irgendwie seltsam. Ich tippe Buchstaben auf meinen Bildschirm, und die erscheinen fast im selben Moment in einer ganz anderen Stadt in einer ganz anderen Straße auf einem anderen Bildschirm. Plopp. Einfach so.

Wer hätte, sagen wir, 1988 gedacht, dass wir auf diese Art Unterhaltungen führen würden?

Damals gab es noch den Quelle-Katalog. Und CB-Funk.

Na ja, und Zeitungen und so Zeug.

So, nun wird diese ganze SSL-Problematik langsam unheimlich.

Erklärung: http://blog.fefe.de/?ts=b544bbc7.

Konsequenz:



Und unter Debian:



Grmbl.

Wer debian testing nutzt und den Instant-Messenger pidgin nicht mehr gestartet bekommt, sollte zwei Pakete deinstallieren:

aptitide purge frei0r-plugins python2.3

Letzteres wird nicht mehr unterstützt, was beim Update zu Fehlern führt, ersteres scheint einen Bug zu haben.

Gulli berichtet:

Eine neue wissenschaftliche Arbeit kommt zu dem Schluss, dass die US-Regierung mit vielen SSL-Zertifizierungsstellen kooperiert, um das Mitlesen verschlüsselter Verbindungen zu ermöglichen.

Die IT-Sicherheitsforscher Christopher Soghoian und Sid Stamm kommen zu dem Schluss, dass die Regierung vielfach die Schlüssel von SSL-Zertifikaten von den Zertifizierungsstellen (Certificate Authorities - CAs) erhält. So können sie Websites vortäuschen und die Benutzer in Sicherheit wiegen. Mit Hilfe von Forensik-Tools können sogenannte Man-in-the-Middle-Angriffe sogar automatisiert durchgeführt werden. Die Konsequenz: die US-Regierung ist offenbar in der Lage, routinemäßig SSL-Verbindungen mitzulesen, ohne den Schlüssel knacken zu müssen.

Es ist absolut nicht überraschend, dass eine Zertifikatsautorität für "Bedarfsträger" falsche Zertifikate ausstellen kann, das sieht der X.509-Standard so vor.

Stand hier schon 2008.

Und wie schon erwähnt erzählt Dan Kaminsky einiges dazu in seinem Vortrag auf dem 26C3.

Dass eine Regierung von dieser Möglichkeit Gebrauch macht ist eine Selbstverständlichkeit. Wenn eine Vertrauensstelle in einem System vorkommt, sei es eine Bank, ein Offizier, ein Programmierer oder eben eine Zertifikatsauthorität, dann ist diese immer ein möglicher Angriffspunkt, daran lässt sich auch kaum etwas ändern. Aber X.509 setzt darauf, dass wir den Autoritäten vertrauen, denen die Browserlieferanten vertrauen. Allen. Allen gleichzeitig. Selbst schuld.

Eine Lücke, mit der normale User an Administrator-Rechte gelangen konnten, existiert seit 17 Jahren. Schreibt heise. Ich sag nichts mehr.