Archiv für die Kategorie „CPUs“

Apple: will „schneller“ und „weniger warm“ werden. Und natürlich „glänzen“…

2005, also vor 15 langen Jahren, wurde die Computer-Hardware-Firma Apple aus Cupertino Opfer ihres eigenen Marketings: man pfiff auf die komplizierte Supercomputer-CPU-Architektur powerpc und stieg um auf die (mangelhaften) Prozessoren der 0815-CPU-Schmiede Intel.

Es war ein Paradigmenwechsel.

Vollkommerz und totaler Bull$hit.

Plus: null Innovation.

Den bis heute auf Expertenseite niemand verstand.

Mit Gehirn ist oft nicht bei Business-Entscheidungen, das wusste ich mit Anfang 20 vielleicht zu wenig. Mir war es als Linuxer eh wurscht.

Anyways.

Vorgespult, wir haben 2020 und Apple wagt erneut einen Paradigmenwechsel: man switcht von Intel zu ARM!

Offiziell weil die CPUs von Intel sich „nicht schnell genug weiterentwickeln“ (Quelle: Bloomberg), Apple „zu warm“ sind und überhaupt ja eh Schrott.

Inoffiziell denke ich, dass es zukünftig keinen Unterschied mehr machen wird zwischen iOS (Smartphones, Tablets) und macOS (Desktop) und man sich hier Richtung Vereinheitlichung der CPU-Plattform bewegen will. Was ja bei der PlayStation 4 ähnlich lief, wo man sich weg von Supercomputer-CPUs Richtung x64 bewegt hat, um a) Entwicklern entgegenzukommen und b) die PC-Plattform mit Ablegern zu fluten.

Gut und clever gewählt ist der aktuelle Schachzug der Gegen-die-Wände-Läufer aus Cupertino absolut: ARM-Prozessoren gehören mit zu den ältesten, sind daher bestens supportet und wirklich energieeffizient. Da bräuchte es nicht einmal interne Untersuchungen.

Ob man sich einen Gefallen machen wird die Desktop-Plattform für iOS-Gedönsen zu opfern steht auf einem anderen Blatt – gerade dieser Move läuft aber schon ein paar Jahre, da braucht man sich nur die „App-Stores“ beider Plattformen anschauen oder die LED-Bar diverser Macbooks. Ja, auch ich habe ein paar Schafe (verloren) in meinem Bekanntenkreis und sehe manche Bewegungen der Apfel-Welt.

Wann genau erste Mac-Hardware mit ARM-CPUs in 2021 kaufbar sein wird, wird wahrscheinlich am 22. Juni öffentlich, wenn Apple die WWDC 2020 abhält; natürlich online only wegen COVID-19.

Wenn dein Schlüsselbund mal wieder auf irgendeinem Fenstersims vergessen wurde:

Cooler Master! Call it a „keycard“! Made in Taiwan! Since 1992! xD

Oben: ein Die der Cell-CPU im Detail, Sony/Toshiba/IBM, 2007

Im Jahr 2020 gehört die 64bit-CPU-Architektur zu den meistgenutzten der Welt. Kein Hersteller von Hard- und/oder Software kann sich mehr erlauben, auf x86_64 zu verzichten. Simultan sind andere, alternative Prozessorarchitekturen im Auflösen begriffen oder mittlerweile ganz ausgestorben, wie beispielsweise powerpc. Letztere steckte bis 2005 in sämtlicher Hardware von Apple aus Cupertino, bevor man sich aus wirtschaftlichen Gründen dazu entschied, Intel zu verbauen.

Wie kam es eigentlich dazu, warum brauchte man das? Und warum war der Weg dahin so lange und so beschwerlich?

Dieser Frage widmet sich ein sehr langer und sehr gut ausgeführter Artikel von ACM Queue: https://queue.acm.org/detail.cfm?id=1165766.

Kurz zusammengefasst: die Entwicklung reicht bis in die 60er Jahre des 20. Jahrhunderts. Auch schlechte Programmierung war oft daran Schuld, dass sich der Einsatz solcher Architekturen länger verzögerte als nötig. Und: erst 2003 machte AMD Nägel mit Köpfen und produzierte kommerziell 64bit-CPUs, die man als Normalnutzer ab da in gängiger Hardware fand.

Zeitleiste, inkl. Kommentaren:

1964 IBM S/360: 32-bit, with 24-bit addressing (16 MB total) of real (core) memory.

1968 Algol 68: includes long long.

1970 DEC PDP-11/20: 16-bit, 16-bit addressing (64 KB total). IBM S/370 family: virtual memory, 24-bit addresses, but multiple user address spaces allowed.

1971 IBM 370/145: main memory no longer core, but DRAM, 1 Kbit/chip.

1973 DEC PDP-11/45: separate instruction+data (64 KI + 64 KD); 248 KB maximum real memory. Unix: PDP-11/45, operating system rewritten in C; IP16. C: integer data types: int, char; C on other machines (36-bit Honeywell 6000, IBM 370, others).

1975 Unix: sixth edition, 24-bit maximum file size (16 MB).

1976 DEC PDP-11/70: (64 KI + 64 KD), but larger physical memory (a huge 4 MB). C: short, long added (partly from doing C for XDS Sigma, although long was 64 bits there).

1977 Unix: ported to 32-bit Interdata 8/32. C: unsigned, typedef, union; 32-bit long used to replace int[2] in lseek, tell on 16-bit PDP-11; IP16L32. DEC VAX-11/780: 32-bit, 32-bit addressing (4 GB total, 2 GB per user process). C: PDP-11: I16LP32; VAX (other 32-bitters): ILP32.

1978 Unix: 32V for VAX-11/780; C is ILP32. C: The C Programming Language, Brian Kernighan and Dennis Ritchie (Prentice-Hall). Intel 8086: 16-bit, but with user-visible segmentation.

1979 Motorola MC68000: 32-bit ISA, but 24-bit addressing (e.g., S/360).

1982 C: I16LP32 on MC68000 in Bell Labs Blit terminal. Intel 80286: allows 16 MB of real memory, but restrictions keep most systems at 1 MB.

1983 IBM 370/XA: adds 31-bit mode for user programs; 24-bit mode still supported. C: Unix workstations generally use ILP32, following Unix on VAX systems.

1984 Motorola MC68020: 32-bit; 32- bit addressing. C: Amdahl UTS (32-bit S/370) uses long long, especially for large file pointers. C: Convex (64-bit vector mini-supercomputer) uses long long for 64-bit integers.

1986 Intel: 80386, 32-bit, with support for 8086 mode.

1987 Apple Mac II: MC68020’s 32-bit addressing causes trouble for some MC68000 software.

1988 IBM ESA/370: multiple 31-bit address spaces per user, although complex; 24-bit still there.

1989 ANSI C (“C89”): effort had started in 1983, ANSI X3J11.

1992 SGI: ships first 64-bit micro (MIPS R4000); still running 32-bit operating system. 64-bit C working group: discusses various models (LP64, ILP64, LLP64), with little agreement. DEC: ships 64-bit Alpha systems, running 64-bit operating system; LP64.

1994 SGI: ships IRIX 6 (64/32 operating system; ILP32LL + LP64) on Power Challenge; customers buy 4 GB+ memory, use it. DEC: ships 4 GB+ in DEC 7000 SMPs (may have been slightly earlier).

1995 Sun UltraSPARC: 64/32-bit hardware, 32-bit-only operating system. HAL Computer’s SPARC64: uses ILP64 model for C.
Large file summit: codifies 64-bit interface to files >2 GB, even in 32-bit systems (ILP32LL+LP64). Aspen group: supports LP64 model for C so that Unix vendors are consistent.

1996 HP: announces PA-RISC 2.0, 64-bit.

1997 HP: UP/UX 11.0 is 64/32-bit OS; ILP32LL + LP64. IBM: RS64 PowerPC, AIX 4.3; ILP32LL + LP64.

1998 Sun: 64/32 Solaris 7 released; ILP32LL + LP64.

1999 C: ISO/IEC C (WG14’s “C99”); includes long long, at least 64 bits.

2001 IBM: 64-bit zSeries (S/360 descendant); 24-bit addressing still supported. Intel: 64-bit Itanium.

2002 Microsoft: Windows 64-bit for Itanium.

2003 AMD: 64-bit X86 (now called AMD64).

2004 Intel: 64-bit X86 (called EMT64), compatible with AMD.

2005 Microsoft: Windows XP Professional x64 for X86; LLP64 (or IL32LLP64)

Immer wieder gerne gelesen und äußerst faszinierende Thematik!

Linux-Distributionen für die PlayStation 3 sind sehr rar, was zum einen an der von Wenigen benutzten CPU-Architektur ppc64 liegt; für mich bis heute unverständlich, gehört diese Architektur doch mit zu den modernsten und jüngsten überhaupt. Mit Red Ribbon GNU Linux lag uns bis Mitte 2018 dennoch eine inoffizielle Debian-Distribution vor, die man bis hoch zur Version 8.11 aktuell halten konnte. Danach waren Updates, nicht einmal Sicherheitsupdates, mehr möglich, da ppc von den Debian-Paketquellen-Maintainern nicht unterstützt wurde. Sonst hätte man damit noch locker bis zum 30. Juni diesen Jahres arbeiten können.

Dieser Umstand bzw. diese Not führt mich als PS3-Linux-Entwickler immer mal wieder zu den verschiedensten Ecken des Web, wo ich Fragen stelle und mich umhöre, ob wir nicht doch einen Workaround finden können zwischenzeitlich. Und siehe da: im letzten Monat wurde ich bei reddit fündig, wo jemand kurzerhand eine PS3-Distribution basierend auf Alpine Linux zusammengestellt hat:

https://github.com/fasif/AlpinePPC64.

Alpine Linux kannte ich bis dato gar nicht, Distrowatch liefert mir anschließend allerlei Informationen wie dass es aus Norwegen stammt, regulär oft auf Routern und Telefoniesystemen zum Einsatz kommt, und auch wie das Logo ausschaut:

Das Geilste aber ist der Kernel, mit dem diese PS3-Distribution läuft: hier wurde mein eigener 3.15.10er aus Ende 2018 dafür benutzt! 😀

Alle meine PS3-Kernels werden auf der PS3 selbst gebaut. Die Hardware braucht für das Kompilieren dafür oft mehrere Stunden. Im Zuge des Spectre-Meltdown-Desasters 2018, das so ziemlich alle OoOE-CPUs betraf und dazu zählt nun mal auch der Cell-Prozessor, hat dazu geführt, dass ich auch versucht habe 4er-Kernels zu bauen (siehe hier). Es scheiterte am Ende jedoch immer wieder an zu alten IBM-Patches. Die zu aktualisieren fiel mir schwer, kannte ich nämlich die Syntax nicht und begegnet sind mir solche Patches bis 2018 auch nie. Am Ende fehlten nicht viele (Link zur Übersicht), für etwaige Hilfe und Fehlersuche stellte ich auch *.rej-Dateien zur Verfügung. Allein, mir ist bis heute nicht bekannt, dass die Patches irgendwo aktualisiert zur Verfügung stünden, um einen lauffähigen 4.x.x-Kernel für eine CFW-PS3 zu bauen. Wäre mir das damals gelungen, diese neue PS3-Linux-Distribution weiter oben hätte dann einen aktuelleren Kernel als 3.15.10 gehabt. Immerhin ist mein Kernel aber neuer als der 3.12.6er, der mit Red Ribbon ausgeliefert wird und auch nie einem Update unterzogen wurde in der Lebensspanne der Distribution.

Es ist wie es ist und eigentlich habe ich auch mal wieder Lust mich am Kompilieren eines 5.x.x-Kernel für die PS3 zu versuchen. Allein, mir fehlt nach wie vor die Zeit dazu.

Trotzdem, es ist schön zu sehen, dass geleistete Arbeit für F/OSS auch von anderen verwertet wird, verwertet werden kann. Das ist einer der riesengroßen Vorteile der OpenSource-Bewegung und eine Leistung, auf die wir nicht umsonst sehr stolz sind.

Die PS3 mit ihrer besonderen und wertvollen Architektur aus den Jahren 2007/2008 ist nicht die einzige Hardware, die auf diese Weise weiter am Leben gehalten werden kann und generationenübergreifend für weitere Faszination und spannende Coding-Projekte sorgen wird. Eine nagelneue Linux-Distribution aus dem Nirgendwo ist schon eine Hammermeldung, wie ich finde.

Heute läuft der letzte Tag von versendeten Arbeitspaketen an unsere SETI@home-Clients.

Mein lokaler Client möchte sich deshalb heute persönlich verabschieden, inklusive wohl historischem Zeitstempel:

(Klicken zum Vergrößern, 6MB-Originaldatei)

Mit der Einstellung des Projekts stirbt auch eine gewisse Menschheitshoffnung. Liegt ja leider mit den aktuellen globalen Entwicklungen der letzten 20 Jahre sehr hart im Trend.

Ich bin gespannt, wann und welche Ergebnisse uns das Projekt liefern wird. Sehr wahrscheinlich werden wir direkt über die Projekt-Website informiert werden, https://setiathome.berkeley.edu/. Ich denke jedoch nicht, dass wir hier allzu viel erwarten sollten. Hätte es all die Jahre etwas wirklich Interessantes zu berichten gegeben, es hätte sich schwerlich verheimlichen lassen können.

Danke für die Möglichkeit zu diesem einzigartigen Projekt beitragen zu können und alles Gute! Es war mein erstes und ältestes Distributed Computing-Projekt und zählte fast 18 Jahre.

Nach knapp vier Wochen multimedialer Coronadauerbefeuerung ist mein an Informationsüberladung eigentlich gewöhntes Gehirn mittlerweile dann auch eingeknickt. Ich persönlich sehe zwar nach wie vor keinerlei Anlass zu Panik, doch leergeräumte Regale in Supermärkten, befremdliche Stille unter Menschenansammlungen wie Parkplätzen, und täglich neue Hiobsbotschaften wie Grenzschließungen in Europa oder Schulschließungen bis mindestens Anfang April fühlen sich für mich mittlerweile an, als sei ich ein NPC (non-playable character) in Plague Inc. Nur leider in Echt.

Schön ist das nicht und eigentlich unnötig. Doch zum Glück bin ich Wissenschaftler von Beruf! Und kann dann doch (sage und schreibe) zwei Projekte gerne weitergeben, was wir so mithelfen in diesem katastrophalen Zustand der Welt und was in den letzten 28 Tagen hängengeblieben ist.

Das erste Projekt ist von der John-Hopkins-Universität, hier ein Screenshot:

Coronavirus, Fallzahlen Stand 13.03.20

Die interaktive Karte ist öffentlich in einer Desktop- und Smartphone-Version hier abrufbar: https://www.arcgis.com/apps/opsdashboard/index.html#/bda7594740fd40299423467b48e9ecf6.

Die Karte und die Hintergründe hat man textlich bereits am 28. Februar bei Telepolis vorgestellt. Ich selbst hatte den Link wenige Tage zuvor von einem Arbeitskollegen bekommen.

Das zweite Großprojekt der Wissenschaft, und das freut mich als ITler besonders, der nach wie vor zu Distributed Computing beiträgt mit lokaler Hardware, ist der Fakt, dass weltweit Supercomputer umprogrammiert werden, um einen passenden Impfstoff zu finden. Das ist eben, worum es sich drehen sollte, nicht wie zuvor die Forschung für schmutzige Bomben. Nee, tatsächlich: der Sierra-Supercomputer des Lawrence Livermore National Laboratory zum Beispiel hier macht eben sonst genau das. Darüber nachzudenken würde weh tun, also lassen wir das. Der Supercomputer Summit soll hingegen bereits 8.000 Wirkstoffe durchprobiert haben und 77 erscheinen vielversprechend. Wer früh eine PS3 hatte, der kennt vielleicht noch das Projekt Folding@home: hier einfach mitmachen, denn die Rechenleistung eigener PCs fließt seit wenigen Tagen genau in die selbe forschende Richtung. Aus den VAE, Vereinigten Arabischen Emiraten, hilft der Supercomputer Artemis. Weitere Rechenzentren in Europa, mittlerweile das Epizentrum des Virus in der westlichen Welt nach China, helfen mit. Realistische Zahlen gehen davon aus, dass wir in 12-18 Monaten über einen Impfstoff verfügen werden…

Das war’s!

Ich habe mich bemüht und auch noch mein virtuelles Kurzzeitgedächtnis nach Ergebnissen durchforstet. Mehr fand ich leider nicht. In 28 Tagen. Irgendwie wird mir übel darüber nachzudenken, was die nächsten vier Wochen medial bringen mögen.

Eine gewohnte und beliebte Szenerie auf PCs jeglicher Bauart seit den 90ern des vergangenen Jahrtausends:

Oben: Mein SETI@home-Client, Stand März 2020

Das leider viel zu früh IMHO, Ende diesen(!) Monats nämlich, endgültig der Vergangenheit angehören wird:

Das Projekt SETI@home, jahrelang synonym verwendet für Projekte des verteilten Rechnens, das sich zur Aufgabe gestellt hatte nach außerirdischem Leben zu suchen, stellt den Betrieb ein. T_T

Warum? Offiziell wegen „abnehmenden Erträgen“. Übersetzt: zu wenig Nutzer. Stand Januar waren das noch ca. 104.000 weltweit…

Das Projekt wird abgeschaltet.
Sogar auf unbestimmte Zeit.
Man wolle sich nun der „Auswertung der Ergebnisse widmen“ und die irgendwann auch veröffentlichen.
Das offizielle Statement gibt es auf der Projekt-Homepage: https://setiathome.berkeley.edu.

Man zerstört hier Träume und bricht mit Hoffnungen von Millionen von Erwachsenen und Kindern.
Ich hoffe das ist den Machern bewusst.
Unsere Zeiten hier auf diesem kaputten Planeten werden erneut ein Stück sinnloser.

Im Normalfall bin ich kein großer Liebhaber von Laptops unter einer Displaygröße von 15“, doch für das ASUS ROG Zephyrus G14 kann ich gleich mehrere Ausnahmen auf einmal machen:

Zum einen bin ich CPU-N3rd sondergleichen und auch schon jahrelanger „Fanboy“ der Underdog-CPU-Schmiede AMD. Einen entsprechenden 80×15-Button aus Anno dazumal findet sich noch heute deswegen in meiner Sidebar. Und erst am 23. Dezember, also kurz vor Weihnachten, geisterte die Meldung durch das Web, Veröffentlichungen erster Laptops mit AMDs Ryzen 4xxx-er-Prozessorserie stünden kurz bevor, sowohl von ASUS, als auch HP. Die passenden Links lieferte ein spanischer Onlinehändler und machte diese Gerüchte dann „wahr“. Was fehlten, waren Fotos entsprechender Hardware. Komischerweise sind die Links heute auch nicht mehr erhältlich.

Im Zuge der Konsumentenmesse CES in Las Vegas hat zumindest ASUS das Geheimnis dann gelüftet. Deren subtiles Meisterwerk ist ein Laptop-Powerhouse im 14“-Format, das in zwei Farben ab dem 2. Quartal für ca. 1.299€-1.499€ erhältlich sein soll.

Was zuallererst dabei auffällt ist der ungewöhnliche Laptop-Deckel (siehe oben): es gibt nämlich ein Modell extra für G33ks, das 1.200(!) programmierbare(!) Mini-LEDs auf der Außenhülle mitbringt! Die Möglichkeiten zur Visualisierung scheinen hier unbegrenzt, auf der Messe selbst konnten sich schon diverse Hacker austoben, man findet viele Fotos wenn man in Suchmaschinen die Bildsuche anwirft und nach „AniMe Matrix“ sucht – so heißt dieses Feature nämlich offiziell im Sprech des Herstellers aus Taiwan.

Von der Optik wieder weg zum eigentlichen Novum: das leistungsfähige Maschinengehirn wird ein AMD Ryzen 4800H sein. Nicht nur die Typbezeichnung wurde inzwischen konkretisiert, diese SoC („SystemOnAChip“) bringt diesmal acht Zen2-Kerne mit. Höchste Taktung wird bei schönen 4,2GHz liegen. Pro Kern. Gepaart mit der zuletzt Anfang 2018 in die Schlagzeilen geratenen „Hyperthreading“-Technologie (Meltdown und Spectre und Konsorten, wir erinnern uns), stehen dem Betriebssystem hier also satte 16 Threads zur Verfügung. Und das bei nur 45W Leistungsaufnahme, möglichgemacht durch eine 7nm-Herstellungstechnologie, u.a. Weitere Daten zur CPU findet man direkt bei AMD oder z.B. Notebookcheck.

Ich selbst wäre hier bereits bedient gewesen.

Auch mache ich mir nichts aus den mitgelieferten Grafikeinheiten dieser SoCs.

Doch eine weitere Eigenart dieses Modells ist, dass man in einem G15 z.B. nicht finden wird: die Nvidia GeForce RTX 2060 Max-Q.

Jep, richtig gelesen: ASUS ist einer der wenigen Hersteller weltweit, der Highendgrafikkarten von Nvidia in AMD-Laptops verbaut (leider). Ich war schon immer großer Fan und auch Anwender dieser Kombo, weil Linux halt und Treibergedönsen; wissen schon. Für mich ist solche exotische Hardware daher sehr, sehr, sehr sehr attraktiv…

Diese Leistung wird hier einmalig sein. Selbst der 15“-Bruder wird prozessor- und grafikkartenseitig diesem Gerät hier unterlegen sein, zumindest auf dem Papier. Ob das merklich in der Praxis etwas ausmachen wird, darüber kann man bereits streiten und wird das auch erst herausfinden können, wenn beide Notebooks ausgiebig kurz vor dem 2. Quartal zur Verfügung stehen und getestet werden können.

Wer das G14 noch etwas detaillierter als lebendes Objekt sehen will, dem empfehle ich auch hier die Fotos von Notebookcheck: https://notebookcheck.com/Asus-ROG-Zephyrus-G14-Das-leistungsstaerkste-14-Zoll-Gaming-Notebook-der-Welt.449298.0.html. Die meisten anderen Quellen liefern nämlich lediglich Standardbildmaterial, z.B. von ASUS-Webseiten. Ist jedoch verständlich, schließlich hat nicht jedes Onlinemedium zum Thema Gadgets die Ressourcen mal schnell nach Las Vegas für Gadget-Pr0n zu fliegen. Schade eigentlich.

Ob das Teil seinen Platz in meine h4x0r-Stuben finden wird steht in den Sternen. Für die angebotene Leistung ist der Preis nicht mal „zu hoch“, aber doch ordentlich für einen kommerziell wenig erfolgreichen Indie-Autoren wie mich. Da bräuchte ich schon zigtausende Flattr-Spenden, das wird nicht funktionieren. Zudem ärgert mich irgendwie immer noch die 14“-Zoll-Displaygröße. Ich kann nichts dafür, ich bin fast so groß wie ein Zollstock, das sähe bei mir wie Kinderspielzeug aus!11 Witzig finde ich auch, dass mir diese AniMe Matrix nicht mehr aus dem Kopf geht – was ich damit alles programmieren könnte! Und wie viel Zeit es verschwenden würde!1 Und wie sinnlos es sein würde!11 Und wie unwichtig auf lange Sicht!111 Muhahaha! Ach, wir dummen Männer: sabbern und hecheln und träumen von PC-Hardware statt vom anderen, attraktiven, natürlich perfekten Geschlecht! Zum Glück, phew, war ich in der Vergangenheit so schlau und habe diese Art von Porno zum Beruf gemacht, haha! 😀

Google so: „Unsere CPU hier macht irgendwas mit Qubits, wofür ein regulärer Supercomputer 10.000 Jahre gebraucht hätte!“
IBM so: „Pfft, das selbe Experiment simulieren wir euch in 2,5 Tagen!“
Und ich so: „Hmmmm, nehme ich diese Woche SALZ oder ZUCKER zu meinem POPCORN!?“

Oben: Zerstörte Intel-CPU, CCBYSA porras

Es gibt Artikel zu Linux, da schüttelst du als IT-Experte einfach nur noch den Kopf.

Oder auch mehrfach.

Alleine auch schon, wo die Fragestellung dazu herkommen soll.

Hier ist mal wieder so einer: „HOWTO make Linux run blazing fast (again) on Intel CPUs“.

Nichts davon, was hier an „Workarounds“ beschrieben wird, sollte man machen, weder auf einem Arbeitsplatz-PC, noch auf einem persönlichen.

Da reißen sich ein Jahr lang Entwickler weltweit den Allerwertesten auf, damit Meltdown, Spectre & Co. in den Griff bekommen wird, und dann sowas.

Der Artikel hier beschreibt, wie man jegliche Sicherheitsschranke ausschaltet, die ab Januar 2018 im Linux-Betriebssystem-Kern implementiert wurde. Das ist einfach nur eklig.

An Insider-Wissen spart der Artikel hingegen nicht.

So steht hier, dass man bei allen Kerneln vor Version 5.1.13 auf insgesamt 8 neue Sicherheits-Features kam (noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off). Ab Kernel 5.3.6 waren es schon 10 (nopti, kpti=0, nobp=0, nospectre_v1, nospectre_v2, spectre_v2_user=off, spec_store_bypass_disable=off, ssbd=force-off, l1tf=off, mds=off). Wie immer bei meinen Artikeln zu diesem Thema: hardwareseitig ist auch damit rein gar nichts gepatcht. Lediglich das eigene Betriebssystem bleibt sicher.

Ferner liefert der Artikel auch einen Vergleich der „Performance-Einbußen“, die sich mittlerweile leichter erstellen lassen als noch vor knapp zwei Jahren. Ergebnis: solange „SMT“ (simultanes Multithreading) aktiv bleibt, die eigentliche Wurzel des Problems (Marketingidiotensprech „Hyperthreading“), wird man diese weder sehen, noch spüren können. Schaltet man das Problem hingegen komplett aus, wozu beispielsweise Google vor wenigen Monaten riet, sind die Einbußen im Schnitt bei 10-15% Leistung. Das kann sich, je nach genutzter Anwendung, durchaus beim Arbeiten/Spielen bemerkbar machen.

Warum ich dem Artikel am Ende doch dankbar war, lag an zweierlei Gründen: man kann die Inhalte auch wundervoll als Satire lesen und sich daran erfreuen. Und es spricht Bände, überhaupt über die gegenwärtige IT-Situation, dass er überhaupt existiert (und sogar noch heute aktuell gehalten wird, das letzte Update war am 15.10.).

Von Zeit zu Zeit befasse ich mich mit diversen PC-Hobbyprojekten. „FreeBSD“ wollte ich eigentlich schon seit Version 10.0 mir mal anschauen (2014…), kam aber zeitlich überhaupt nicht dazu.

Da ich noch einen alten, aber damals ziemlich leistungsfähigen Desktop-PC im Keller stehen hatte, musste dort die zweite, uralte Festplatte endlich mal bespielt werden. Mein Erfolg sollte damit besiegelt sein, ein lauffähiges, eventuell gar WLAN-internetfähiges „FreeBSD 12.0“ am Rennen zu haben. Mit diesem Beitrag kann ich sagen: a) ich hatte Erfolg und b) ich wollte festhalten, was für Schwierigkeiten ich hatte und einen ersten Einstieg geben.

(Oben: Läuft! „FreeBSD“ 12.0 beim ersten Gruß)

Da das eine alte i386-Kiste ist musste ich mir natürlich erstmal die ISO besorgen. Die passt auf eine CD und ist frei hier herunterladbar: https://download.freebsd.org/ftp/releases/i386/i386/ISO-IMAGES/12.0/.

Das Brennen mit k3b war erfolgreich, also kopfüber hinein in die kryptischen Installations-Routinen!

Hier sieht man mal wieder, wie verwöhnt man ist: alleine war es nicht zu packen. Windows wird meist mit den Maschinen mitgeliefert, hier braucht man sich kaum noch um Installer zu kümmern. Wenn man wie ich seit 2005 Linux-Installer gewohnt ist, hat man zwar die Entwicklung hier permanent mitbekommen und kann bestimmte Vorgänge im Schlaf. Doch „FreeBSD“ ist schon sehr eigen hier. Zum Glück gibt es ja das große „G“ und da fand ich einen Beitrag, der zur Installation kaum noch Wünsche offen ließ:

https://rauchland.com/articles/installing-freebsd/.

Sehr zu empfehlen und sehr netter Autor/Artikel!

Dadurch fand ich heraus, dass man als Hostname keinen Namen im eigentlichen Sinne, sondern eine Domain angibt. Meine Maschine heißt nun freebsd.aethyx.eu.

Das zweite Problem war wie immer: das Netzwerk. An dem Desktop-PC hängt aber eine Atheros-PCI-WLAN-Karte, die von Linux und BSD-Derivaten erkannt werden sollte. Nach drei Versuchen war das dann auch der Fall. Hier bin hier immer etwas egomanisch unterwegs und muss das schon mit dem Installer hinkriegen. So habe ich hinterher weniger Stress, auch bei den ersten Updates. 🙂

Drittes Problem war die „Reg-Domain“ als Code. Hier muss man aus Europa stammend ETSI nehmen und das Land auswählen.

Probleme mit der Formatierung der zweiten HDD gab es bei mir keine: wie erwähnt war die ja uralt und nur 30GB groß, konnte direkt platt gemacht werden. Etwas gestutzt habe ich beim Dateisystem, hier habe ich einfach das Vorausgewählte genommen, was irgendwie MSDOS-Bezug hatte. War dann zufällig hinterher richtig.

Gewöhnungsbedürftig war die Einrichtung meines Users. Aber auch hier half der Artikel von rauchland.com über alle kleinen Schwierigkeiten hinweg.

Ich dachte das war es dann und mache einen Reboot und schaue mal rein. Denkste!

grub2 von einem installierten Debian 9 auf der ersten HDD zeigt keinerlei neue Einträge. Scheinbar überschrieb „FreeBSD“ aber auch nichts, was irgwendwie gut war: so konnte ich das bestehende Linux nutzen, „FreeBSD“ mit dem PC „bekanntzumachen“.

Tatsächlich hat dieser Vorgang, „FreeBSD“ als Eintrag in grub2 zu bekommen und dass es auch startet, die meiste Zeit gekostet. Eine Standardlösung gab es hier nämlich nicht.

Die Lösung war im Verzeichnis /etc/grub.d/ eine Datei namens 40_custom auszufüllen. Ich kann mich jetzt nicht mehr zu 100% erinnern, doch in meinem Fall sah der lauffähige Code wohl aus:

menuentry "FreeBSD 12.0" {
set root= '(hd1,1)'
chainloader (hd1,1)+1
}

Hier half nur Try & Error weiter. Mit /dev/sdX und dergleichen ließ sich mein „FreeBSD“ nicht ansprechen. Ich hatte auch erst hd1,0 da drin und nichts lief. Weiß nicht mehr, wie viele Versuche ich gebraucht habe, aber waren mehr als drei. 😉

Cool. Also irgendwann lief das Betriebssystem dann. Macht coole Sounds, wenn man auf der Tastatur (zu viel) klimpert! 😀

Und, was ich auch nicht wusste: kein DE (Desktop Environment). War ja aber auch gar nicht mein Ziel. Es sollte laufen, ich sollte mich einloggen können und erste Updates fahren.

Wenn man das erste Mal eingeloggt ist muss man wissen, es gibt erstmal kein sudo. Also root-Ebene mit su und Updates eingespielt:

freebsd-update fetch
freebsd-update install

Das System sollte nun auf dem neuesten Stand sein.

Ähnlich wie der Artikel von rauchland für die Installation gibt es auch hier einen Artikel, den ich sehr empfehlen kann: https://tecmint.com/things-to-do-after-installing-freebsd/.

Hier kann man sich recht komfortabel entlang hangeln, was zu tun ist; eye candy ist ja nicht. Macht aber Spaß, und man hat schnelle Erfolge.

Genutzt habe ich hier, neben dem Update: die Installation einer bash; Installation meines favorisierten Texteditors nano; Installation und Konfiguration von sudo natürlich; alles andere konnte ich zumindest temporär liegen lassen. So wie ich das quer las sind hier viele Netzwerkgeschichten mit dabei, die mich als Coder jetzt erst einmal nicht interessieren.

Wer möchte, ich habe 9 Fotos während der Installation erstellt, und kann sich die in unserem eigenen Cloud-System von AETHYX MEDIAE gerne als Galerie ansehen:

https://cloud.aethyx.eu/index.php/apps/gallery/s/tdjdwt7PmTBZNNz.

Mein Lieblingsfoto seht ihr bereits oben als Teaser dieses Artikels. 🙂 Sind aber alle irgendwie sehr geil!

Ich bin am Wochenende bei der Installation von xorg geistig ausgestiegen. Die Wahl einer DE fällt mir nicht leicht, zumal „mein KDE“ wohl nicht mehr erhältlich sein soll, wie ich las? Jedenfalls, wer hier weitermachen möchte und z.B. Gnome oder LXDE aufspielen möchte, natürlich gibt es auch hierfür einen Artikel im Web: https://2daygeek.com/install-xfce-mate-kde-gnome-cinnamon-desktop-environment-on-freebsd/. Have fun!

Bei den Projekten, die ich so starte, ist anfangs nie wirklich klar, in welche Richtung sie sich entwickeln werden. Meist lasse ich mich dabei treiben und probiere verschiedene Dinge aus. Mit Entwickler-Background ist „FreeBSD“ natürlich erstmal interessant hinsichtlich Coding-Phänomenen, die nur hier möglich sein sollen; das fängt schon beim Aufbau des Betriebssystems an. Meist stürze ich mich damit zuerst wo rein. Ob sich das jetzt groß unterscheiden wird von Linux, da beide Systeme ja auf einer i386-CPU-Architektur laufen, bleibt abzuwarten.

Dann ist „FreeBSD“ natürlich die perfekte Grundlage um mal gutes altes UNIX zu lernen. Schließlich haben wir diese offene Möglichkeit auch erst seit 1993.

Und schließlich ist „FreeBSD“ auch die Grundlage für Apples Darwin und diverse Nintendo– und PlayStation-Spielekonsolen. Vielleicht treibt es mich auch dorthin, bevor ich nicht doch einen Server einrichte.

Ehrlich gesagt: kein. Plan.

Spaß gemacht hat es trotzdem! Und: läuft!

Das erste Quartal 2019 ist zu Ende. Wir befinden uns bald im 16. Monat des Bekanntwerdens der Hardcore-Hardware-Prozessoren-Bugs „Meltdown“ und „Spectre“. Zählt man das halbe Jahr Geheimhaltung dazu, sogar schon im 22. Monat.

Zeit für einen kurzen Status, wo wir gegenwärtig stehen.

Wie die folgende Grafik des „35C3“ (35. Chaos Communication Congress) anschaulich zeigt, sind aus zwei Hardware-Bugs hervorgerufen durch das OoOE-Paradigma nunmehr 27(!) geworden:

Eine Empfehlung zum Kauf von Hardware mit Prozessoren von Intel, AMD, ARM & IBM kann also derzeit in keinster Weise ausgesprochen werden.

Entspannung ist kaum in Sicht.

Intel will zwar noch dieses Jahr erste CPUs verkaufen können, die hardwareseitig gegen „Meltdown“ geschützt sind. Welche das sind steht jedoch in den Sternen genauso, wie warum es nur die „Basisversionen“ betreffen soll (was auch immer das sei…) und nicht durchgängig alle Intel-CPUs. Welchen größeren GAU brauchen die noch!?

AMD will dieses Jahr noch eine(!) der „Spectre“-Varianten hardwareseitig patchen, allerdings lediglich in „Zen2“-Architekturen. „Zen2“ ist die 3. Generation der „Ryzen“-CPUs, die Mitte 2019 kommerziell erhältlich sein soll. Wer dadurch Server betreiben will, sollte auf den Codenamen „Rome“ achten, Desktopnutzer auf „Matisse“. Wie man oben gut erkennen kann durch die Grafik, wird es das aber wohl kaum bringen und ist wohl nur ein Tropfen auf den (viel zu) heißen Stein. Schade, AMD.

ARM, verantwortlich für so ziemlich jeden Prozessor weltweit(!) in Smartphones und Tablets außer denen aus dem Hause Apple, verspricht lediglich nebulös, dass „alle künftigen CPUs gegen Angriffe im Spectre-Stil resistent sein werden“ und veröffentlicht weiter Online-Listen mit betroffenen Prozessoren. Ja gut, ähhh…

IBM. Ja, „Big Blue“. „Big Blue“ halt. „Big Blue“ hat erst kürzlich „Red Hat“ für Milliarden-Milliarden US-Dollar gefressen und schläft bzw. hat sich wohl mental vom CPU-Markt verabschiedet. Daher keine Ahnung, was deren Status hier derzeit ist. Hinweise werden dankend entgegengenommen und hier weiter gepflegt.

Und was machen wir Nutzer & Käufer, mit Hardware von vor 2018? No choice. At all: patchen, patchen, patchen & daran glauben, dass es softwareseitig irgendwas bringt, klaffende, physikalische Hardware-Sicherheitslücken verzweifelt zu stopfen, bis es kein Morgen mehr gibt.

Meine armen KollegInnen der Programmiererzunft weltweit. Man könnte meinen, das Schicksal nimmt uns persönlich seit Mitte 2017 unsere seriöse Arbeitsgrundlage. Was sollen wir alternativ machen jetzt? Nutztiere züchten!? Bäume pflanzen!? Ich für meinen Teil, bin leider schwer überfragt. Keine guten, keine gesunden IT-Zeiten derzeit. DAMN.

Zum kommenden März werden sowohl Firmware-Updates als auch PSN-Funktionen für die in die Jahre gekommenen Sony-Konsolen PS3 und PSVITA dauerhaft eingestellt.

Wir von AETHYX MEDIAE & gizmeo.eu sagen danke, und dieser höfliche japanische junge Herr verbeugt sich jetzt bitte vor uns:

Möge die Macht mit einer AMD-CPU-GPU-Hybrid-Architektur nun mit ihm & seinem legendären japanischen Hightech-Unternehmen sein! Denn Kutaragi-San war sein Vater…

Willkommen in 2019, einem weiteren Jahr geistiger Gehirnbehinderung! <3

Auf elektronischem Wege, zumindest.

Obwohl Winter ist wird in der deutchen Nachbarschaft gesägt, gehämmert, Bäume gefällt & Flüssigkristallerzeugnisse geleckt und massiert.

Ich weiß ja nicht, was hier los ist, doch der „technisch weit entwickelte Deutsche“ verträgt auch im ersten Jahr nach dem dümmsten Sommer aller Zeiten leider keine Weiterentwicklung -.- Willkommen im „Digitalneuland!“ TOTAL FTW!

Naja, machen wir uns nichts draus.

Es gibt Androiden, kaputte CPUs, vom Himmel fallende Satelliten zum Ausschlachten und Plattenspieler von Vestax zuhauf.

Frohes Neues Jahr 2019 wünscht gizmeo.eu! Auf unsere liebe Gehirnglotze! ^^

Wir arbeiteten diesen Herbst mit AETHYX MEDIAE hart daran, die Cell CPU von STI zu patchen. Leider ist uns das für den Kernel 4.1x bisher nicht gelungen.

Das ist nicht weiter schlimm, da Linuxnutzer sowieso erst seit August 2018 wieder einen PS3-Kernel nutzen können dank der Arbeit von Geoff Levand und der Linux-Kernel-Entwickler-Community. Der Kernel war seit Mitte 2014 überhaupt nicht mehr lauffähig auf Cell-B.E.-Hardware, aus welchem dümmlichen Grund auch immer.

Was wir erreicht haben bisher, ist beachtlich.

Nicht nur konnten wir den Kernel 3.12.x bis 3.15.x lauffähig machen mit unserem Repository, wir konnten sogar Kernel 4.18 zum Laufen bringen, allerdings hatten wir nie Zugriff auf die interne HDD.

Alle unsere Erkenntnisse haben wir fein säuberlich dokumentiert und sind hier erhältlich:
https://gitlab.com/aethyx/ps3linux/tree/master/Kernel%20patches%20and%20configs/ps3linux-kernel-patches-418.

Bitte hier unbedingt den Ordner need modifications || not working beachten!

Alles, was wir brauchen, um auch hier eine „Intel-CPU-Apokalypse“ abwenden zu können, ist den Schwachsinn von IBM (Naziklitsche, IMHO) stopfen. Das sah nicht sehr schwer aus, was wir bisher gesehen haben. Aber so tief gehen die CPU-Kenntnisse von AETHYX MEDIAE nun auch nicht und zweitens, haben wir überhaupt keine Lust und keine Zeit, Nazi-Firmen zu helfen, egal aus welchem Land diese kommen.

Vielen Dank für Eure Mithilfe (oder eben auch nicht). Linux auf DER Hardware war eben doch mal was wert…

Weitere Informationen ebenfalls im #cell auf OFTC (IRC).