2012/2013 war Secure Boot ein megaheißes Thema. So dermaßen heiß, dass ich sogar in meinem Feedreader zweistellig zählen konnte, siehe hier.
2020 ist dieses Rotzthema immer noch nicht tot.
Wie ist das möglich?
Gestern ein Update für das mitgelieferte Windows 10 auf einem Laptop gemacht, das berüchtigte Update 2004 vom Mai. Ich weiß nicht wieso, wohl aus Laune heraus oder weil ich einfach ein System wollte, wo ich nicht dauernd darauf hingewiesen werden möchte, dass es nicht 100% aktuell ist. Ich hätte es lassen sollen, denn ich verlor meinen GRUB.
Bootet anschließend Linux, bekam ich das hier heraus:
Welcome to Grub!
error: unknown filesystem.
Entering rescue mode…
grub rescue>
Jop, das war’s dann. Kein Linux will mehr booten. Und das mit ausgeschaltetem Secure Boot, ausgeschaltetem Fastboot _und_ dem manuell ausgewählten EFI-Eintrag im mitgelieferten BIOS-Interface.
Mit ls
geht dann das Debugging los. Irgendwas mit (hd1,gptX)
spuckt das System dann aus. Bei mir waren das 10+ Einträge. Jeden durchgehen, mit englischsprachigem Tastaturlayout, kurz vor Mitternacht, wo hängt mein verschollenes root
herum?
Als es dann gefunden war, erst einmal /home
gefunden, geil! Nix bootet. Glücklich war ich dann dennoch, denn irgendwie ist mein Linux ja noch da.
Da es auf einem Haussystem eigentlich nur zwei ext-Systeme geben kann wegen / und /home (oder welches Linux-Dateisystem auch immer man verwendet, z.B. reiser, etc.), hatte ich mit dem zweiten dann Glück. Mit folgenden Codezeilen brachte ich das System wieder in einen grafischen Bootzustand:
grub rescue > root=(hd1,gpt2)
grub rescue > prefix=(hd1,gpt2)/boot/grub
grub rescue > insmod normal
grub rescue > normal
Der soll dann zwar nur temporär sein, aber mir reicht das. Windows nutze ich vielleicht einmal im Schaltjahr. Dann kracht es aber richtig.
Ahhhh! Ahahahaha! Ihr Redmonder Zoophilie-Junkies mal wieder! Hatte euch schon fast komplett vergessen!
[Update I, 16.10.20]
Das mit der temporären Lösung ist einem ja irgendwann doch zu blöde, weshalb ich mir kürzlich wieder die permanente zurückerobert habe. Hier hilft es, wenn man sich zuerst mal ausgeben lässt, welche Partitionen man benutzt und wie diese heißen: lsblk -o PATH,PTTYPE,PARTTYPE,FSTYPE,PARTTYPENAME
. Heutzutage wird das eher in Richtung nvmeXYZ gehen, bei älteren PCs ohne SSDs dann wahrscheinlich sda. Dann noch ein sudo update-grub
, was bekannt sein sollte, sowie ein sudo grub-install /dev/sda
bzw. ein sudo grub-install /dev/nvmeXYZ
danach und dann „Macht’s gut, Redmond!“.
Heute gesehen bei heise.de, ein „Highend-Notebook“ mit „300Hz“ vom Gemüse-Discounter unseres Vertrauens:
Ich musste heftig suchen, in welchem PC-Jahr wir hier wirklich angekommen sind.
Der Z3 von Zuse hatte 4 bis 5 Hz, irgendwann um 1941. Der ENIAC vier Jahre später, 1945, schon wuchtige 5kHz. Also irgendwo dazwischen.
Nur wurden leider keine weiteren Computer „dazwischen“ gebaut. Vielleicht fehlen hier auch Einträge in der westlichen Literatur. Die Technik war in jedem Fall noch zu neu und füllte Hallen, alleine die Z3 wog über eine Tonne.
Mit der Headline habe ich noch ein weiteres riesiges Problem neben der Unvollständigkeit (falls das überhaupt jemandem auffiel): ich gehe hier von der Taktfrequenz eines Prozessors aus und halte das für „normal“. Im Text aber geht es um das Display.
Sind Displays heute wichtiger als CPUs!? Sind CPU-Infos nicht mehr relevant für Technikmagazine?? Und: wer kauft eigentlich PCs bei ALDI!? Hakt’s?
Weihnachten 2017: Kernel-Entwickler arbeiten durch. Neujahr 2018 ebenso. Der Grund: eklatante Hardwarefehler in Computerprozessoren, dem Gehirn unserer PCs. Die Wissenschaftler taufen diese „Meltdown“ und „Spectre“, „Kernschmelze“ und „Schreckgespenst“.
Sommer 2020. Inzwischen sind wir in Monat #32 nach Bekanntwerden dieser Hardwarelücken. Was der aktuelle Stand?
Folgender:
SUMMARY: CVE-2017-5753, CVE-2017-5715, CVE-2017-5754, CVE-2018-3640, CVE-2018-3639, CVE-2018-3615, CVE-2018-3620, CVE-2018-3646, CVE-2018-12126, CVE-2018-12130, CVE-2018-12127, CVE-2019-11091, CVE-2019-11135, CVE-2018-12207
Oben: Zusammenfassung aktueller CPU-Lücken des Tools spectre-meltdown-checker, Stand August 2020
Aus drei Lücken (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) wurden 14. In Worten: Vierzehn.
Selbst AMD scheint auch 2020 nicht in der Lage zu sein Prozessoren zu bauen, die alle Fehler ausschließen können.
Unterziehe ich meinen neuesten AMD-Prozessor, den 4800HS, einem Test mit dem kostenlosen OpenSource-Tool spectre-meltdown-checker, wird klar, dass besonders ein Bug hardwaretechnisch bisher unmöglich zu beseitigen scheint.
Es ist jener mit den Kennungen CVE-2017-5753 aka ‚Spectre Variant 1, bounds check bypass‘, CVE-2017-5715 aka ‚Spectre Variant 2, branch target injection‘ und CVE-2018-3639 aka ‚Variant 4, speculative store bypass‘, bekannt als „Spectre“, das „Schreckgespenst“.
Ohne die pausenlose Arbeit zum Jahreswechsel 2017/2018 der weltweiten Entwickler-Community, wären selbst AMD-CPUs des Jahres 2020 hier verwundbar. Die gelisteten drei Varianten von Spectre sind ledliglich softwareseitig gepatcht und damit seit über 2,5 Jahren auf keinem aktuelleren Stand als damals.
Mir ist das zu lange. Als Entwickler, wie als Anwender.
Von 14 Hardwarefehlern sind 11 aus der Welt und drei nach wie vor vorhanden. Willkommen in der neuen Realität der 78,57%-PC-Hardware für 100% hardverdientes Geld! Was ein Scheißdreck.
In einer digitalen Welt voll mit kostenlos erhältlichen Datenbanksystemen setzen nur noch IT-Steinzeitmenschen auf reine Tabellenkalkulationen.
Sei’s drum, denn: wer braucht heute noch ein Gehirn!? Richtig!?
Luckysheet möchte selbst kommerziellen Tabellenkalkulationsprogrammen Konkurrenz machen und man muss zugeben, zumindest geschwindigkeitstechnisch und optisch macht es absolut etwas her:
Für eilige Ex-Excel-Junkies lässt sich die Demo auch gleich direkt ausprobieren: https://mengshukeji.github.io/LuckysheetDemo/.
Wer etwas mehr Zeit erübrigen kann, der braucht nur Node.js in Version 6 oder höher und kann das Programm lokal auf dem PC mit nur wenigen Zeilen installieren:
npm install
npm install gulp -g
Luckysheet wird von einer kleinen chinesischen Community entwickelt und basiert auf einer MIT-OpenSource-Lizenz. Vielleicht der einzige Wermutstropfen, doch was ist heutzutage nicht aus China? Richtig!?
Whoa! KDE macht offenbar in Ultrabooks:
Direkt der Slimbook-Website entnommen
Und die Dinger sehen auch noch hardwaretechnisch supersexy aus! Passend zur Desktopumgebung! 🙂
Mit 899€ auch zu einem sehr humanen Preis, wie ich finde: dafür erhält man ein 14“-HD-IPS-LED-Display mit leistungsstarkem AMD Ryzen 4800H-Prozessor (8 Kerne, 16 Threads, integrierte Radeon-Grafikkarte mit 1,43 T(!)FLOPS), der erst im Januar auf der CES öffentlich vorgestellt wurde (hier nochmal der Bericht). Eine bisschen mickrige 250GB-SSD, sowie 8GB RAM ebenso.
Wer will, kann über den Onlineshop das Setup jedoch noch nach Belieben (oder was der eigene Geldbeutel hergibt) aufstocken. Im Kurzbesuch konnte ich bis zu 64GB RAM und eine 2TB Samsung-SSD ohne Probleme finden, siehe: https://slimbook.es/en/store/slimbook-kde/kde-slimbook-14-comprar.
Das Geilste aber ist natürlich: KDE Neon vorinstalliert!
Die auf Debian bzw. Ubuntu LTS basierende Linux-Distribution gilt als bleeding edge und liefert immer das Neueste und Feinste von KDE frei Haus. Und das noch gar nicht lange: sie ist erst vier Jahre alt, wurde 2016 ins Leben gerufen. Aktuell ist sie mit Platz 11 locker in den TOP20 von distrowatch.com zu finden. Sehr populär also.
Wem 14“ zu klein sind, kein Problem: für nur 30€ mehr erhält man das 15“-Modell.
Fazit: hardwaretechnisch und von Betriebssystemseite erste Sahne und wenn die Verarbeitung nur halb so geil ist, wie sie aussieht, für mich ein Anwärter auf das Gadget des Jahres!
Schon extremst geil und wirklich heftigst eye candy plus cyberpunk:
eDEX-UI ist ein Terminalemulator, wie man ihn von PC-Interfaces aus Scifi-Filmen wie „Tron“ und „Alien“ kennt. Er läuft auf allen gängigen Plattformen, Linux bevorzugt, aber auch Mac oder sogar Windows mit wenigen Einschränkungen.
Das Programm aus der Zukunft ist frei hier erhältlich: https://github.com/GitSquared/edex-ui.
Nach der Installation erwartet einen ein Echtzeitmonitor für CPU, RAM, Swap und laufende Prozesse, sowie das Netzwerk. Für Touchscreens liefert er eine entsprechende Tastatur mit, die sich bei Nichtbedarf auch ausblenden lässt. In jedem Interface ist ein Verzeichnis-Browser eingebaut. Und: natürlich enthält er immer auch die entsprechende Konsole zum Arbeiten oder Experimentieren.
Das Customising kann man selbst übernehmen, braucht dafür allerdings das Wiki. Das sind schon erweiterte Konfigurationen, die man hier durchführen muss, nicht jeder kennt sich beispielsweise mit CSS-Injections aus.
Wer möchte, kann sich auch zum Konsolen-Skin entsprechende Sounds einblenden lassen.
Oben zu sehen ist der Skin neofetch mit eDEX-UI 2.2 und dem Standard-„Tron“-Thema. Ein Stückchen weiter unten das Thema „interstellar“ mit den geöffneten Grafikeinstellungen der Applikation.
Fettestes Projekt, absolute Empfehlung! Viel Spaß beim Ausprobieren!
Erst im Januar hatte AMD auf der CES in Las Vegas der Welt die neue 4000er-Serie seiner leistungsstarken Ryzen-Prozessoren vorgestellt. Unter anderem auch den 4800H(S), der in einem 14-Zoll-Exzellenz-Gaming-Notebook von ASUS präsentiert wurde, die sechs Monate das Exklusivrecht für die Veröffentlichung dieser CPUs halten sollten.
Das passte ganz gut in meine eigenen Hardwareplanungen, hatte ich mir doch seit 2011 keinen Rechner mehr gegönnt. Und die Thematik mit Meltdown und Spectre machte ab 2018 ja alles nur noch viel schlimmer und ätzender. Es war mal wieder allerhöchste Zeit, Intel so richtig in den A**** zu treten!
Die Notebook-Prozessoren von AMD spielen mittlerweile in einer eigenen Liga. Kein Vergleich mehr zu meiner letzten AMD-Hardware aus 2005, damals war der Turion64 „ultramodern“ und 64bit war d-e-r heiße Scheiß, die CPUs aber wie immer von AMD im Notebook viel zu laut und viel zu warm.
Die Hardware, die ich seit letzter Woche nun mein Eigen nennen darf, gilt aktuell als beste Laptop-CPU der Welt, neben dem 4900er-Modell, der Ryzen 7 4800HS.
Wie es der Zufall so wollte bin ich seit 2018 im CPU-Benchmarking-Territorium unterwegs, zumindest in meiner Freizeit. Was lag da also näher, als sich den Prozessor mal mit dem Tool HPL (High Performance Linpack) vorzunehmen, der Benchmark-Suite, mit der auch die TOP500-Liste der Supercomputer seit Jahren gebenchmarkt wird? Eben!
Gesagt, getan, Freitag Abend drei Stunden Arbeit investiert und das Ergebnis meiner Maschine kann sich doch durchaus sehen lassen, wie ich finde:
================================================================================
HPLinpack 2.2 — High-Performance Linpack benchmark — February 24, 2016
Written by A. Petitet and R. Clint Whaley, Innovative Computing Laboratory, UTK
Modified by Piotr Luszczek, Innovative Computing Laboratory, UTK
Modified by Julien Langou, University of Colorado Denver
================================================================================An explanation of the input/output parameters follows:
T/V : Wall time / encoded variant.
N : The order of the coefficient matrix A.
NB : The partitioning blocking factor.
P : The number of process rows.
Q : The number of process columns.
Time : Time in seconds to solve the linear system.
Gflops : Rate of execution for solving the linear system.The following parameter values will be used:
N : 13920
NB : 240
PMAP : Row-major process mapping
P : 1
Q : 2
PFACT : Right
NBMIN : 4
NDIV : 2
RFACT : Right
BCAST : 2ring
DEPTH : 1
SWAP : Spread-roll (long)
L1 : transposed form
U : transposed form
EQUIL : yes
ALIGN : 8 double precision words——————————————————————————–
– The matrix A is randomly generated for each test.
– The following scaled residual check will be computed:
||Ax-b||_oo / ( eps * ( || x ||_oo * || A ||_oo + || b ||_oo ) * N )
– The relative machine precision (eps) is taken to be 1.110223e-16
– Computational tests pass if scaled residuals are less than 16.0================================================================================
T/V N NB P Q Time Gflops
——————————————————————————–
WR12R2R4 13920 240 1 2 7.23 2.486e+02
HPL_pdgesv() start time Fri Jul 10 23:17:19 2020HPL_pdgesv() end time Fri Jul 10 23:17:26 2020
——————————————————————————–
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)= 0.0046572 …… PASSED
================================================================================Finished 1 tests with the following results:
1 tests completed and passed residual checks,
0 tests completed and failed residual checks,
0 tests skipped because of illegal input values.
——————————————————————————–End of Tests.
================================================================================
Wie zu erwarten war schneidet das 8-Kerne-AMD-Biest formidabel ab, das Endergebnis des etwas über 7 Sekunden dauernden und alle acht Kerne ausnutzenden Tests ging voll auf den L3-Cache, der hier zwei Mal vorhanden ist und je 4MB beträgt: 248,6 GFLOPS!
I <3 it! Selbst nur im Akkumodus und vom Stromnetz getrennt kam der Prozessor noch auf 210,4 GFLOPS.
Ich kann mir nicht helfen, aber ich habe selten so eine krasse, alleinige CPU-Leistung von einem meiner Heimgeräte gesehen. Gut, die PS3 war auch noch gut dabei, bis heute übrigens, obwohl die Hardware aus 2007/2008 stammt. Der Ryzen 7 4800HS ist also die zweite CPU in meinem Haushalt, die über 200 GFLOPS mit HPL erreicht. Hut ab, AMD, gerne mehr davon!
Solche Benchmarks selbst durchzuführen, v.a. unter Linux, ist eine Kunst, die selbst mich als Berufsinformatiker immer wieder vor Herausforderungen stellt. Man merkt das schon sehr gut bei der Recherche zu dem Thema, wo nie Tools gelistet sind, die außerhalb der Intel-Welt ein Ergbnis in (G)FLOPS liefern. Wie kompliziert das hier war und wie man den Test erfolgreich durchführt, bei noch viel komplizierterer Vorkonfiguration, erläutere ich gerne mal in einem anderen Beitrag. Stay tuned! 😉
Was Unterstützung für Linux betrifft, so ist Canon aus Japan beileibe kein A****loch-Hersteller: für meinen Drucker TR 8550 aus 2017/2018 gibt es wenigstens Treiber für Debian Linux und RPM-basierte wie z.B. Fedora. Wenngleich die seit Ende 2017 auch nie mehr einem Update unterzogen wurden…
Wie Canon in den 80ern Populärkultur wurde: dank „Akira“!
Nur was mit Arch oder auf Arch basierenden Derivaten? Viel Spaß mit der Installation über den Sourcecode!
Nee, das funktioniert nicht. Ehrlich jetzt.
Ich hatte noch ein funktionierendes Setup auf einem anderen Linux-Rechner, aber selbst meine manuell kopierten Dateien (cmdtocanonij2
, cmdtocanonij3
, rastertocanonij
) nach /usr/lib/cups/filter/
brachten das Mistding nicht ans Laufen. Ich bekam beim Druckversuch einer Testseite nur immer wieder die Meldung „Filter failed“.
In einer Onlinerecherche kam irgendwo (ich spare mir Links, keine Zeit, hier auch unnötig), das bedeute „eine Vielzahl von Fehlern“, ich solle debuggen.
Nee, das funktioniert heute nicht. Nicht heute. Und morgen auch nicht. Und auch nicht irgendwann nächstes Jahr.
Phew, was tun?
Wir werden pervers! Aber so richtig! Wir konvertieren das erhältliche *.deb-Paket in eine Arch-Installationsdatei, die pacman dann essen muss! Völlig egal, ob es funktioniert oder nicht danach! Muhahahaha!
Das Tool, das dies erledigt, nennt sich debtap und ist über offizielle Quellen nicht erhältlich, man muss das inoffizielle AUR anzapfen. Doch selbst dann läuft es nicht einfach von selbst, man muss indizieren lassen, aber wie das alles genau geht steht hier, denn den Link share ich gerne weiter: https://ostechnix.com/convert-deb-packages-arch-linux-packages/.
Der Befehl, der die Konvertierung durchführt, lautet schließlich so:
debtap cnijfilter2_5.50-1_amd64.deb
Der hat wahrscheinlich eine halbe Ewigkeit Gültigkeit, denn der Treiber wird von Canon für Pinguinnutzer ja eh nie geupdatet.
Man kann übrigens die Fragen, die sich hier stellen, nach Belieben ausfüllen, das ist nicht wichtig. Heraus kommt eine cnijfilter2-5.50-1-x86_64.pkg.tar.zst
, die man nur noch mit sudo pacman -U
installieren muss. DONE!
Gestern, nach 22:00, end-lich funktioniert’s!
Gut, bei mir schlug die Installation erst einmal fehl, denn meine manuell kopierten Dateien waren ja noch da, worüber sich pacman beschwert hat. Doch nach dem Löschen dieser war dann eine Installation ohne Fehlermeldung möglich. Danke debtap, danke pacman, danke TCP/IP!
Mit diesem Tutorial wollte ich mehrere Dinge auf einmal zeigen:
1) die erfolgreiche Installation des Druckers TR 8550 von Canon unter Arch Linux bzw. einem der vielen Derivate
2) dass eine manuelle Installation fehl schlägt (verschwendete Lebenszeit!)
3) was das Tool debtap ist und warum wir hier pervers werden müssen
4) warum Versuch manchmal kluch macht
5) get it running or die tryin‘!
Wenn diese Exkursion in die Tiefen der Linux-Druckertreiber-Höllen bei euch auch zum Erfolg geführt hat, klickt doch auf einen der Buttons und spendet bitte! KTHXBYE! <3
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.
Der Begriff fuzzing entstand 1988 an der Universität von Wisconsin. Die Studierenden wurden aufgefordert ein UNIX-Werkzeug einem fuzz test zu unterziehen: so sollten diese mit zufällig generierten Daten und Kommandozeilenparametern das Programm an den Rand des Wahnsinns und damit zum Absturz bringen. Nebenbei half das Projekt bei der Entwicklung von Debugging-Tools, um die aufgetretenen Fehler aufzuspüren und zu kategorisieren.
Und da wir aktuell alle viel zu viel Zeit wegen Corona haben, machen wir heute mal zur Abwechslung etwas Sinnvolles:
Wir fuzzen den Windows-Kernel! Yay!
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!
Einmal im Schaltjahr biegt eine Firefox-Neuerung um die Ecke, mit der ich nichts anfangen kann.
Am 7. April war es mit der Version 75 mal wieder so weit, eine „neue Adressleiste“ wurde implementiert, sieht so aus:
Kann ich nicht nachvollziehen.
Zum einen wirkt das wie eine Art Vergrößerungseffekt, eine Lupe, die ich nicht brauche. Es bricht auch das UI, wie ich finde.
Zum anderen flogen alle meine am meisten aufgerufenen Websites heraus. Also wurde hier irgendwas ohne bei mir nachzufragen zurückgesetzt.
Ohne in den Konfigurationsdateien des Browsers Hand anlegen zu müssen geht es hier nicht weiter, leider.
Also about:config
geöffnet und folgende Einstellungen auf false
gestellt:
1. browser.urlbar.openViewOnFocus
2. browser.urlbar.update1
3. browser.urlbar.update1.interventions
4. browser.urlbar.update1.searchTips
5. browser.urlbar.update1.view.stripHttps
Danach den Firefox neustarten.
So wie mir ging es wohl vielen Millionen Usern und das fliegt Mozilla gerade in Internetforen und Blogs um die Ohren. Richtig so! Absolutes bad habit!
Denn erstens gilt hier der Leitspruch never change a running system und zweitens will ich wenigstens informiert werden, ob ich diesem Change zustimmen will. Debian fragt mich ab wegen jedem Blödsinn bei jeder Paketänderung. Kann für Mozilla so schwer also nicht sein.
Schwer für mich zu glauben, doch dieses kleine feine Gadget-Internetmedium hier wird diesen Monat tatsächlich bereits 10 Jahre alt…
Was mit einem Export der populärsten Unterkategorie meines cipha.net im April 2010 seinen Anfang nahm, ist über diesen Zeitraum auf mehr als 1.200 Beiträge und knapp 200 Kommentare angewachsen. Die Besucherzahl liegt meist zwischen 250-350 pro Monat bei ca. 300-450 Page Views.
Wie das cipha.net so war auch dieses Weblog als „Mitmachmedium“ gedacht. Noch heute steht auf der internen Mitmach-Seite zum Projekt:
„Mitmachen kann eigentlich jeder, der Gadgets hat.
So ziemlich jeder von uns hat zum Beispiel ein Handy oder einen Rechner und verfügt damit über gewisse Erfahrungen. Das ist als Hintergrund durchaus von Vorteil.
Wenn ihr einsteigen wollt, benutzt dafür bitte das Kontakt-Formular!“ [via]
Allein, irgendwie fand sich außer mir bis heute keiner zusätzlich hier Inhalte bereitzustellen.
Vielleicht ist gizm{e}o einfach „zu klein“? Oder „zu technisch“? Oder „zu underground“? Ich weiß es nicht.
Was ich aber weiß ist, wie die Gadget-Passion bei mir mal angefangen hat. Und so dachte ich mir, aus aktuellem Anlass teile ich einfach mal, wie das damals aussah. So irgendwann um Weihnachten herum, 1994, irgendwo in Westeuropa:
(Oben: Mein Weihnachtsstolz 1994: SNES mit dem „Super GameBoy“ und der C64, der bis heute im Besitz meines Vaters ist)
Was wir hier sehen, das bin ich mit 12 und mein Weihnachtseinkauf 1994 in Aktion, ein Super Nintendo mit Super GameBoy. Angeschlossen an den zweckentfremdetem Monitor des C64 meines Vaters. Links unter dem Kalender steht noch eine meiner ersten Stereoanlagen(!). Meine Gadget-Anfänge, wenn man so will.
Zwei von diesen Gadgets nutze ich heute noch: aus dem C64 wurde ein Laptop und IT sogar mein Beruf. Aus dem Super Nintendo die PlayStation, in welcher Iteration auch immer. Nur die Stereoanlage, die hat es nicht mehr geschafft. Wie Tapes und CDs als Medien verschwand sie mit anderen Geräten wie Walkmans, Discmans oder Handys dank der digitalen Revolution in der Bedeutungslosigkeit der Gegenwart.
Als das Web in mein Leben trat, irgendwann 1999/2000, mit erster eigener Email-Adresse und erster eigener Domain, war meine Vision immer, Dinge oder Themen zu verbinden, wo meine wirklichen Talente und Stärken lagen. Und daraus für sich selbst stehende, innovative, unabhängige Webmedien zu bauen. Zwar war es zu der Zeit einfach Domains zu registrieren, schwer aber war, diese mit Inhalten zu füllen. Erst im November 2001 konnte ich ein solches Projekt an den Start bringen und rückblickend war das an absolute riot. Es muss mir solch einen Spaß gemacht haben, dass diese Art von „Produkten“ (können, sollen wir sie so nennen?), selbst neun Jahre danach noch von mir mit viel Freude und Hingabe entworfen und veröffentlicht wurden. Zur Uni-Zeit; eigentlich hat man hier genügend zu tun. Un-mög-lich.
Das Adjektiv unmöglich hat mehrere Bedeutungen, nicht alle sind positiv konnotiert:
[1] nicht machbar, undurchführbar
[2] personenbezogen: unduldbar, unentschuldbar, nicht akzeptabel, unpassend
[3] unwahrscheinlich, nicht vorstellbar, seltsam, merkwürdig
Aus unmöglichen Gegebenheiten erwachsen unmögliche Projekte. Gizm{e}o war und ist eines davon. Von mir persönlich, einem unmöglichen Typen aus einer unmöglichen Zeit.
Mögen die nächsten 10-100 Jahre un-mög-lich bleiben!
Alles, alles Gute, gizmeo.eu!
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.
Traveling, von begemot_dr via flickr.com
Schlechte Nachrichten für alle Zeitreisende oder die, die es noch werden wollen: eine aktuelle Physikstudie fand heraus, wenn sich drei oder mehr Objekte gegenseitig beeinflussen, lässt sich die Zeit bzw. die Geschichte nicht mehr zurückdrehen. Damit sei die Unmöglichkeit der Zeitumkehrung fest in der Natur verankert.
Getestet wurde das Modell im Computer anhand von Schwarzen Löchern. Das Phänomen lässt sich wohl bis auf die atomare Ebene zurückverfolgen. Bedeutet konkret, es spielt offenbar keine Rolle, ob das drei Schwarze Löcher, drei Planeten oder drei Atome sind.
Also Obacht: ab drei oder mehr Personen kennt die Zeitachse naturgegeben nur noch eine Richtung und alles endet im Chaos!11