Die Vorbesitzer*innen meines aktuellen ASUS C443T Chromebooks haben wohl häufig Chips beim Streaming gegessen, jedenfalls waren einige Tasten sehr schwergängig. Obwohl man unzählige Videos zu Tastaturreparaturen im Netz findet ist mir keins untergekommen, welches die (De)Montage genau dieses Modells zeigt. Daher hier mein Beitrag zum großen Wissensspeicher:
Die Tasten verhalten sich etwas unterschiedlich:
Die normalgroßen Tasten sind am oberen Rand eingeklickt, man zieht sie also dort hoch bis sie ausrasten. Das kleine Gerüst darunter ist mit 4 Haken am Grund befestigt, ich konnte es beschädigungslos lösen in dem ich auch am oberen Rand ansetzte
Bei den schmalen Tasten am oberen Rand der Tastatur ist es genau umgekehrt, aber das Prinzip identisch
Die Leertaste hat eine etwas andere Konstruktion mit zwei Drähten, an denen die Taste eingeklemmt ist. Hier scheint es egal zu sein, von welcher Seite man zieht, aber vielleicht gibt es hier auch spezielles Werkzeug mit dem man weniger den Eindruck hat gleich etwas zu zerbrechen
Auch andere große Tasten wie Shift haben zusätzliche Drähte, hier sind weitere Bauformen zu finden
Ich habe hier Hilfsmittel verwendet, die sonst für den Tausch von Handydisplays verwendet werden, also einen kleinen Schraubendreher und ein Plektrum.
Beim Einbauen geht man umgekehrt vor, hängt also die Tasten zuerst auf der Seite ein, in der sie nicht einklicken. Beim Andrücken der kleinen Gerüste muss man etwas darauf achten die Metallhaken nicht zu verbiegen.
In den BIS News habe ich diesen kurzen Post über das 20. Betriebsjahr des eKVVs eingestellt. Man hätte mehr schreiben können, aber es gab in der Vergangenheit auch schon umfangreichere Texte zu anderen, runden Geburtstagen (10 Jahre Projekt BIS) oder inhaltlichen Meilensteinen (die 2.000.000ste Prüfungsleistung im System). Irgendwann fängt man sich zu wiederholen 😅
Und wenn der 20. Geburtstag mitten eine Zeit fällt, in der sich so viel bewegt – der Start des Medizin-Studiengang rückt näher und damit vielfältige Veränderungen im Grundsystem – ist das eher ein Anlass nach vorne zu blicken, als zurück.
Trotzdem … wenn ein technisches System allmählich ein Alter erreicht, in dem man als Mensch endgültig als Erwachsene*r gilt, ist das bemerkenswert, um so mehr wenn die Perspektive nach heutigen Stand ohne Deadline für eine Ablösung oder ein Nachfolgesystem ist.
Am Ende der langen Geschichte des BIS (bis Ende 2016) findet sich ein Abschnitt zur technologischen Zukunftsfähigkeit des Gesamtsystems. Das dort gesagte gilt für mich auch weiterhin: Die Nutzung von Java als Grundtechnologie gibt uns die Handlungsoptionen und das große, lebendige Ökosystem, welches wir für Weiterentwicklungen brauchen. Auch große Überarbeitung wie die aufwändige Umstellung der Oberflächen auf das aktuelle Corporate Design und die damit endlich erfolgende Einführung einer responsiven Darstellung lassen sich bewältigen, die hohen Kosten (in Form von Personalressourcen) entstehen eher durch die Komplexität und den Umfang der BIS Anwendungen und weniger durch die eingesetzte Grundtechnologie.
Im Moment spricht daher nichts dagegen, dass das eKVV in 10 Jahren weiterhin das zentrale System für die Lehrplanung an der Universität Bielefeld ist. Die sich dann mit einem Medizinstudiengang im Vollausbau, vielen neuen Gebäuden und vielleicht auch durch die Nachwirkungen der Corona-Online-Zeit sehr verändert haben wird.
PS.
Beim Schreiben des BIS News Posts habe ich den alten Screenshot des eKVVs aus dem Jahr 2003 herausgesucht:
Und irgendwie gefällt mir die Buntheit 😌 und die Läuferin, die wir damals in den Verlauf gesetzt haben. Vielleicht auch einfach nur weil weil der Kontrast zu heutigen Seiten einfach so groß ist.
Das ist ein Screenshot aufgefertigt auf dem ChromeBook, das gestern ankam. Das erste Modell hier im Haus, auf dem sich Crostini ausführen läßt. Damit hat ChromeOS Linux Container erhalten und so die Option Tools wie git oder eben Emacs nativ auszuführen. Und Google Drive lässt sich einfach mounten. Sehr schick 😊
Die Auseinandersetzungen zwischen Oracle und Google um Google’s Nutzung von Java APIs in Android sind offenbar vorbei: Das Oberste Gericht der USA hat entschieden, dass diese Nutzung unter den Fair Usefällt. Neben IT und Tech Seiten wie Heise und The Verge haben auch SPIEGEL und FAZ direkt darüber berichtet. Das Urteil ist spannend zu lesen:
Fast 11 Jahre vor Gericht
Zusammenfassungen der verschiedenen Etappen dieser Auseinandersetzung zwischen den beiden IT Giganten lassen sich an verschiedenen Stellen im Netz finden, für mich verbindet sich die Anfangsphase noch mit intensiven Diskussionen darüber beim schon lange eingestellten Google+. Dort haben sich naturgemäß die eher Google-freundlichen Diskutanten eingefunden, aber die Frage ob Google sich unrechtmäßig der kreativen Leistung anderer bedient hat, oder ob Oracle mit seinem Versuch Programmierschnittstellen nachträglich als urheberrechtlich geschützte Werke zu interpretieren die Softwarewelt aus ihren gewohnten Angeln hebt, war heiß umstritten. Ich war da eher auf der Seite, die Oracles Klagen strikt ablehnte. Die folgende Karikatur aus dieser Zeit zu den Organisationsstrukturen verschiedener IT Unternehmen ist mir daher direkt wieder eingefallen:
Das Urteil kann man hier als PDF vom Heise Verlag abrufen. Es ist durchaus lesenswert und auch ohne umfangreiche juristische Kenntnis durchaus verständlich. Ein paar Abschnitte habe ich mir rauskopiert:
‚To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on whether Google’s use of those lines was a “fair use.”
Das oberste Gericht hat also die für die IT Welt – insbesondere auch die Open Source Community – wesentliche Frage ob eine API überhaupt ganz grundsätzlich ein Urheberrecht haben kann, nicht entschieden. Und da hatte Oracle in früheren Instanzen einen Etappensieg errungen. Auch wenn die Oracles Niederlage nun vielleicht einen abschreckenden Effekt hat, grundsätzlich ist damit zumindest in den USA wohl mit weiteren Verfahren zu rechnen, in denen API-Nutzungen Anlass zu Gerichtsverfahren geben. Und nicht jede Beklagte ist so mächtig und wohlhabend wie Google.
‚Computer programs differ to some extent from many other copyrightable works because computer programs always serve a functional purpose.‘
Das Gericht hat sich aber Gedanken dazu gemacht, in wie weit das Urheberrecht eigentlich auf Software angewendet werden kann.
‚As a result, this code is different from many other types of code, such as the code that actually instructs the computer to execute a task. As part of an interface, the copied lines are inherently bound together with uncopyrightable ideas (the overall organization of the API) and the creation of new creative expression (the code independently written by Google). Unlike many other computer programs, the value of the copied lines is in significant part derived from the investment of users (here computer programmers) who have learned the API’s system.‚
Hier macht das Gericht zum ersten, aber nicht zum letzten Mal, einen interessanten Punkt: Eine API – zumindest die, um die es hier konkret geht – gewinnt dadurch an Wert, dass Programmierer*innen sie erlernen und dafür Zeit investieren. Damit wird die Wertgenerierung nicht mehr allein den Erschaffer*innen zugebilligt, sondern jede Java Entwickler*in, die diese APIs gelernt hat, vergrößert durch ihr Investment den Wert der Sprache.
‚Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language.‘
Auch hier wird wieder der Verweis auf das existierende Knowhow von Entwickler*innen gemacht und das es Googles Vorgehensweise diesen ermöglicht habe ihr Wissen nun in einem weiteren Umfeld zu nutzen. Dieses Wissen also wertvoller wurde.
‚Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as one small part of the considerably greater whole. As part of an interface, the copied lines of code are inextricably bound to other lines of code that are accessed by programmers. Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.‘
Und noch einmal der Verweis auf die Möglichkeit für Entwickler*innen ihr Knowhow in einer neuen Umgebung zu nutzen. Verbunden mit der Entlastung von Google, die eine vergleichsbare API oder gleich eine ganze Programmiersprache auch leicht hätten selbst entwickeln können (was sie in späteren Jahre mit Dart und Go taten).
‚The fourth statutory factor focuses upon the “effect” of the copying in the “market for or value of the copyrighted work.” §107(4). Here the record showed that Google’s new smartphone platform is not a market substitute for Java SE. The record also showed that Java SE’s copyright holder would benefit from the reimplementation of its interface into a different market‚
Mir persönlich gefällt, dass das Gericht den positiven Einfluss von Android auf das ganze Java Ökosystem hier honoriert. Schon bei den ersten Diskussionen gab es diesen Punkt, wenn es Oracle wirklich darum gegangen wäre Java zu pushen, dann hätten sie direkt mit Google zusammenarbeiten können. Und offenbar ist im Laufe der Jahre das Argument von Oracle verloren gegangen, wonach Google mit Android das ‚florierende‘ Ökosystem von Java ME Handys vernichtet habe.
Die Entwickler*innen als eigene Partei
Abgesehen von der eigentlichen Urheberrechtsfrage, die vermutlich in anderen Gerichtsverfahren – vielleicht nicht nur in den USA – entschieden wird, finde ich den Aspekt, das wir als Entwickler*innen eine wesentliche Rolle in solchen Erwägungen spielen, sehr spannend:
Wenn wir uns auf eine Sprache / API / Technologie einlassen kostet uns dies Zeit und vielleicht auch Geld und eine Technologie kann sich kaum durchsetzen ohne eine entsprechende Menge von Menschen, die sich damit gut auskennen. Und unsere Interessen sind dabei durchaus anders als die der potentiellen Urheberrechtsinhaber*innen: Für uns ist es attraktiv die Wahl zu haben, zwischen Werkzeugen und zwischen Implementierungen einer API, und jedes neue Feld, in dem wir unsere Kompetenz einsetzen können, ist zunächst einmal gut für uns und den Wert unseres Wissens.
Man wird sehen, ob dieser Aspekt auch in zukünftigen Gerichtsverfahren eine Rolle spielen wird.
Wenn die Ostereier in diesem Jahr ungefärbt waren, dann hat man vielleicht ein neues Logo darauf entdecken können, das Logo von respeggt. Damit werden Eier gekennzeichnet, die ohne das Töten von männlichen Küken bei der Zucht der Legehennen auskommen. Dieser Abschnitt aus der respeggt-Webseite sagt dazu:
Das respeggt-Siegel steht für das Versprechen: „Ohne Kükentöten“. Dank einer lückenlosen Prüfung der Lieferkette wird garantiert, dass nur Produkte das Siegel tragen, die die Forderung „Ohne Kükentöten“ erfüllen.
An dem respeggt-Siegel erkennt der Verbraucher sofort, dass es sich um Eier handelt, in deren gesamter Lieferkette die Grundsätze des respeggt-Versprechens eingehalten werden. Die Nutzung einer Blockchain-Technologie stellt sicher, dass jedes Ei, das das respeggt-Siegel trägt, lückenlos verfolgt und auf das Einhalten des respeggt-Versprechens verifiziert wird.
Das hört sich sowohl in ethischer wie auch in technologischer Hinsicht interessant an. Aber wie funktioniert das?
Was ist die Aufgabe
Die respeggt-Group ist selbst kein Eierproduzent, sie hat das Qualitätssiegel entwickelt und betreibt das System zur Sicherung dieser Qualität. Damit das Siegel glaubwürdig ist müssen dabei mindestens diese Dinge beleg- und nachvollziehbar sein und zwar lückenlos:
Von welchem Legehennenbetrieb kommt das mit dem Siegel gekennzeichnete Ei
Von welcher Henne wurde das Ei dort gelegt
In welchem Aufzuchtbetrieb wurde die Henne großgezogen
Woher kam das Ei, aus dem die Henne geschlüpft ist
Wie wurde in der Brüterei mit den männlichen Küken der Eier umgegangen, die zusammen mit dem Ei, aus dem die Henne geschlüpft ist, bebrütet wurden. Diese Frage ist das eigentliche Fundament des Qualitätssiegels
Bis das respeggt-Ei in die Handelsketten und zum Endkunden kommt sind also schon auf mehreren Ebenen Unternehmen mit unterschiedlichen Aufgaben beteiligt, und in jedem dieser Unternehmen und auch bei den Transporten von Hühnern und Eiern zwischen ihnen gibt es Potentiale für Fehler oder gar absichtliche Verstöße gegen die Richtlinien.
Das Supply Chain Monitoring System für so eine Produktions- und Lieferkette ist schon eine komplexe Aufgabe, um das Vertrauen der Verbraucher*innen zu gewinnen muss aber auch plausibel gemacht werden, dass die Dokumentationen dazu vollständig und fälschungssicher sind.
Was kann die Blockchain dazu tun
Für die Blockchain Technologie, die mit dem Aufstieg von Kryptowährungen wie Bitcoin Bekanntheit erlangte, werden schon lange weitere Einsatzfelder diskutiert. Genauer gesagt muss es dabei nicht unbedingt eine Blockchain sein, sondern generell eine Distributed-Ledger-Technologie, was man als verteiltes Kassenbuch übersetzen kann, und Blockchain ist dabei das heute am weitesten verbreitete Verfahren.
Eine Distribute-Ledger-Technologie hat dabei mehrere interessante Eigenschaften, hier sind es wohl diese beiden, die wesentlich sind:
Das ‚Kassenbuch‘ ist kryptografisch so abgesichert, das nachträgliche Änderungen nicht möglich sind, zumindest nicht ohne das sie auffallen. Die Blöcke in der Blockkette verweisen dazu aufeinander und bilden so eine Kette, die nicht unterbrochen werden kann
Bei einem echten verteilten Kassenbuch gibt keinen zentralen Akteur, der uneingeschränkt über das Kassenbuch bestimmt, es sich mehrere Akteure notwendig, um den nächsten Dokumentationsabschnitt (= Block) zu bestätigen und damit unveränderlich zu machen. Allerdings ist mir beim respeggt-System nicht klar, ob das Sinn macht bzw. so umgesetzt wurde
Diese Eigenschaften sind etwa in der Bildungslandschaft die Grundlage für Überlegungen über eine Blockchain fälschungssichere und allgemein zugängliche Dokumentationen von Abschlüssen bzw. Bildungszertifikaten aufzubauen, die je nach Nutzungsweise auch ohne zentrale Datenhaltung auskommen könnte. Dabei müssen ’nur‘ noch ein paar Hürden überwunden werden, etwa die, das nicht komplette Zeugnisse in die Blockchain aufgenommen werden können: Die personenbezogenen Daten darin würden sich nie mehr daraus entfernen lassen, was sich nicht mit der DSGVO vereinbaren lässt. Hier könnte mit Dokumentenhashes gearbeitet werden, über die sich dann Dokumente, die von Absolvent*innen präsentiert werden, validieren lassen.
Eine andere Idee – und hier kommen wir denke ich dem Einsatzszenario bei den respeggt-Eiern schon näher – ist das hier beschriebene Verfahren für Diamanten Herkunftsnachweise zu realisieren. Und so den Nachweis zu führen, dass es sich nicht um sogenannte Blutdiamanten handelt. Ob dieses Verfahren inzwischen tatsächlich eingeführt und genutzt wird habe ich leider nicht herausgefunden, aber das liegt vielleicht in der Natur der Sache:
Während die Bitcoin Blockchain vom Prinzip her öffentlich sein muss, würden sich die am Diamantenhandel beteiligten Parteien wohl eher nicht völlig frei in die Karten schauen lassen. Hier wird die Blockchain dann zu einem internen Werkzeug für Unternehmen, die sich nicht völlig (oder überhaupt nicht) vertrauen können, aber damit eine gegenseitige Kontrollmöglichkeit erhalten könnten ohne eine zentralisierte Struktur.
Leider habe ich auch zur respeggt-Blockchain keine konkreteren Angaben im Netz finden können, die inhaltlich über den oben zitierten Satz hinausgehen. Es gibt nur von Telefonica dieses Paper (PDF), welches im Kontext des Internet of Things die Anbindung von respeggt-Infrastrukturen beschreibt. Vielleicht speisen verschiedene Gerätschaften wie die Drucker, die das Siegel auf die Eier drucken, ihre Daten so gleich in die Blockchain ein? Leider ist auch nicht klar wer genau wie tief in die Blockchain schauen kann und was genau da alles drin steht. Als Endkunde kann man nur hier seinen Eiercode online prüfen.
Trotzdem ist das für mich eines der bisher noch wenigen Beispiele, in denen die Blockchain Technologie jenseits von Bitcoin ganz direkt nutzbar geworden ist.
