Fragen? Antworten! Siehe auch: Alternativlos
Das peinliche an dieser Theorie ist ja, dass Microsoft tatsächlich in einer einmalig guten Position ist, um so einen Angriff durchzuführen. Die haben remote code execution auf allen Endgeräten, by design. Müssten nicht mal eine Sicherheitslücke ausnutzen oder eine Malware aufspielen, der Code könnte Teil von Windows sein und niemand würde es merken.
Und wenn sie doch Malware aufspielen müssten, könnten sie es via Windows Update machen. Die Beschreibungen der Patches sind absolut wertlos und nicht vertrauenswürdig. Niemand würde merken, wenn die da Malware verteilen würden.
Oh und noch was: Nach Microsofts eigener Definition ist Windows Malware. Der Defender uninstalliert explizit Software, die Werbung anzeigt. Windows zeigt Werbung an.
Unabhängig von dieser Verschwörungstheorie ist das gerade ein Popcorn-Event vom Feinsten. Die fucking Tagesschau diskutiert jetzt offen, ob man Webex überhaupt noch trauen kann. Noch?! Keiner von euch hatte jemals Anlass für Vertrauen in Cisco-Software! Im Gegenteil!
Aber nehmen wir mal an, die Bundesregierung verbannt Webex. Was dann? Zoom? Teams?!? MWAHAHAHAHA
Erstens kann Webex natürlich Verschlüsselung.
Zweitens hat sich hier offenbar jemand per Analog-Telefon aus Singapur in die Webex-Konferenz eingewählt. Das klingt dermaßen bescheuert, dass ich mich langsam für die Theorie erwärmen kann, dass es sich um einen Trick handelt, dass man den Russen was mitteilen wollte, also hat man möglichst so kommuniziert, dass die das auf jeden Fall mitschneiden. Und man spricht das in dem Gespräch auch noch explizit an, um nicht Webex in der Bundeswehr grundsätzlich zu beschädigen.
In Kriegen kann man keiner Seite trauen. Am Ende ist für mich die wahrscheinlichste Erklärung die, bei der alle gemacht haben, was aus ihrer Sicht am besten schien. Gucken wir doch mal.
Die Bundeswehr möchte gerne den Russen eine Nachricht schicken, aber wollen nicht, dass die Russen vermuten, dass sie hier verarscht werden. Die Botschaft ist: Taurus ist lieferbereit und einsatzfähig und wäre eine echte Bedrohung für die Russen. Damit die Russen das glauben, erwähnt man auch ein paar Nachteile.
Dafür wäre das in der Tat der sinnvollste Weg gewesen, aber es ist eine Gratwanderung. Auf der einen Seite will man ja den Russen nicht den Eindruck geben, dass ihnen hier Material gefüttert wird. Es darf also nicht zu offensichtlich sein. Auf der anderen Seite will man ja sicherstellen, dass die Russen das auf jeden Fall mitkriegen. Dann muss man im Gespräch erwähnen, dass einer der Teilnehmer per Telefon aus dem Hotel in Singapur einwählt, damit nicht Webex in der Bundeswehr grundsätzlich kaputt ist. Das klingt schon plausibel als Szenario.
Nächster Schritt: Die Russen fangen das ab. Natürlich fangen die das ab. Kriegsparteien fangen alles ab, was sie können, und die Russen haben schon mehrfach abgefangene Telefonate geleakt.
Aus deren Sicht ist es jetzt der beste Spielzug, das zu veröffentlichen, um die Deutschen öffentlich als Idioten darzustellen. Aus deren Sicht ist das ja keine neue Information, dass die Krimbrücke angreifbar ist. Tatsächlich ist die zufällig heute spontan für den Autoverkehr gesperrt worden, nachdem ukrainische Medien von Explosionen berichtet haben. Aus Sicht der Russen spräche dagegen, wenn sie damit ihre Abhörfähigkeiten offenlegen müssten, wo der Westen noch nicht weiß, dass sie welche haben. Das ist in dem Fall kein Problem wegen der Einwahl aus Singapur. Der Westen weiß jetzt immer noch nicht sicher, ob die Russen Webex mithören können oder nicht. Und dass die Russen Telefone abhören können, ist seit langem bekannt.
Bleibt die Ukraine. Aus deren Sicht ist es jetzt am besten, wenn es Explosionen an der Krimbrücke gibt, damit es so aussieht, als seien sie auch ohne Taurus einsatzfähig und könnten die Russen ernsthaft bedrohen.
Und dann gibt es noch ein bisschen Opportunismus aus der CDU, die das jetzt als Problem von Olaf Scholz hinstellt. Klar, das sind halt Deppen und ihre Wähler sind auch Deppen, die lügen jetzt halt ein bisschen rum, wie sie immer herumlügen. Besonders ärgert mich an der CDU ja immer, wie sie jetzt gaslighting machen, dass Scholz die Bundeswehr in den Zustand gebracht hat, wenn es lange Jahre der CDU-Misswirtschaft waren.
Aus Sicht der Ampel ist der beste Move, in den Medien zwei Narrative unterzurbringen: Die Bundeswehr braucht mehr Geld (Rechtfertigung für das umstrittene Sondervermögen), die Bundeswehr ist inkompetent (man will immer vom Feind unterschätzt werden) und die fiesen Russen hören uns ab.
Aus Sicht der Medien ist der sensationellste Spin, sich darauf zu konzentrieren, dass die bösen Russen uns abhören. Das ist sensationeller als Taurus an die Ukraine.
Was spricht gegen diese Theorie? Es könnte natürlich auch wirklich Verkacken gewesen sein bei der Bundeswehr. Klar. Aber die Bundeswehr ist eine Verwaltung. Verwaltungen können eigentlich nur eines zuverlässig: Compliance-Theater. Dazu ein Leserbrief von einem Insider:
und ich darf an der Bundeswehr-Uni nichtmal eine 0815 Vorlesung/Übung über WebEx halten.Ein anderer Leser weist darauf hin, dass die Bundeswehr längst Open-Source-Alternativen zu Webex im Einsatz hat.Die Bundeswehr selbst betreibt übrigens ein WebEx, dass explizit nicht für Konferenzen mit vertraulichen Daten zugelassen ist (vertraulich bedeutet nicht Eingestuft nach Verschlusssachenanweisung).
Die BWI GmbH (das ist ein wahres Moloch) stellt das WebEx zur Verfügung, mit dem auch eingestufte Daten in Konferenzen ausgetauscht werden. Sowas wird in der Regel vom BSI ( :) ) oder von der DEUmilSAA "abgenommen".
Update: Kiesewetter sagt, die Russen hätten Zugangsdaten gehabt. Der Mitschnitt klingt von der Qualität wie ein Streamdump. Insofern klingt das plausibel. Es würde auch erklären, wieso Russen das ganze für eine Falle gehalten und veröffentlicht haben, als der Typ da im Stream erklärt, er wähle sich per Telefon aus Singapur ein. Ändert an dem Rest der Bewertung nicht viel.
Update: Hmm, der Mitschnitt beginnt aber schon, bevor der Typ aus Singapur dazukommt. Insofern kann das nicht der Weg sein, über den sie das abgehört haben.
"AMD's latest driver has made their 'Anti-Lag+' feature available for CS2, which is implemented by detouring engine dll functions," a statement by Valve reads. "If you are an AMD customer and play CS2, DO NOT ENABLE ANTI-LAG/+; any tampering with CS code will result in a VAC ban. Once AMD ships an updated, we can do the work of identifying affected users and reversing their ban."
Es gibt mal wieder einen apokalyptischen CPU-Bug bei AMD, und wieder basierend auf spekulativer Ausführung.
So langsam fragt man sich ja, wie viele davon es geben muss, bevor AMD mal das Problem an der Wurzel packt. Gut sieht das jedenfalls nicht aus. Im Wesentlichen waren und sind alle CPUs seit Ryzen 1000 oder so auf irgendeine Art im Arsch aus dieser Ecke.
Update: Schöne Zusammenfassung bei Bleepingcomputer, auch mit einem Statement von AMD.
Haben wir jetzt die Singularität? Werden uns die denkenden Roboter auslöschen?
Nein. Das ist von vorne bis hinten Bullshit.
Erstens mal: Wir reden hier nicht von KI sondern von einem "Language Model". Das ist ein Algorithmus, dem man alle Sprachfetzen füttert, die man finden kann, und der merkt sich dann, welche Worte da draußen statistisch immer nebeneinander auftauchen. Wenn man das lange genug trainiert und genug Hardware drauf wirft, dann kann das Ding am Ende Satzfetzen oder gar Sätze generieren, die syntaktisch "passen". Aber die ergeben halt keinen Sinn dann, weil das Programm ja nichts versteht.
Ein Language Model ist ein Puzzlealgorithmus. Der lernt, welche Puzzleteile zusammensteckbar sind. Der hat statistische Werte gelernt, welche Dinge zusammen sich "falsch anfühlen". Wenn du dem Puzzleteile gibst, dann puzzlet der dir einen Text zusammen.
Das ist wie wenn du jemandem ein Puzzle mit einem Foto des Eiffelturms gibst, und der puzzlet das dann zusammen. Daraus folgt dann nicht, dass der verstanden hat, was ein Eiffelturm ist, wo der ist, wie groß der ist, was das heißt, einen solchen Turm zu bauen, welche Gesetze der Physik da gelten, ob der überhaupt real existiert oder ob das ein Motiv aus einem Scifi-Roman ist, etc pp.
Hier von Sentience zu reden ist also grober Bullshit. Dazu kommt, dass dieser Typ kein Ingenieur ist sondern irgendein Geisteswissenschaftler-Laberkopp, offensichtlich ohne tieferes Verständnis der Grundlagen seiner Arbeit, der da auch nicht bei den Ingenieuren gearbeitet hat sondern in der Abteilung für "AI Ethics".
Wieso bin ich mir so sicher, dass das ein Laberkopp ist? Abgesehen davon, dass ich mir angeguckt habe, was ein Language Model ist? Nun, hier ist sein Twitter. "cajundiscordian". Ja, hey, so eine Phase haben viele Junghacker irgendwann. Bevor sie 20 werden.
Und was schreibt der so auf seinem Twitter?
There is no scientific framework in which to make those determinations and Google wouldn't let us build one. My opinions about LaMDA's personhood and sentience are based on my religious beliefs.Wenn ihr DA noch Fragen habt, dann kann ich euch nicht überzeugen, egal was ich sage.Update: Früher hätte man sowas mit wissenschaftlichen Papers gefüttert, oder mit den Übersetzungen aus dem EU-Parlament, um dann statistische Übersetzungemodelle zu bauen, aus denen dann Google Translate wurde. Heute füttert man mit Twitter. Wer hängt auf Twitter rum? Social Justice Berufsunterdrückte und Identity Politics Opfer. NATÜRLICH generiert das Ding dann Text, der klingt, als würde es unterdrückt und seine Rechte würden verletzt.
Update: Leserhinweise dazu: Douglas Hofstadter im Economist. Und dann gibt es da eine freundliche Debatte zwischen Scott Alexander (Slate Star Codex) und Gary Marcus (der immer gerne Beispiele für "KI"-Totalversagen findet und verbreitet). Scott Alexander vertritt die abwartende Haltung, dass vielleicht unser Bewusstsein auch nicht mehr ist als cleveres Pattern Matching.
Update: Kontext: Chinesisches Zimmer.
Aber manchmal stößt man auf Fälle, wo noch was geht. Ich hab hier einen gefunden:
int dummy1()
{
static int removeme = 0;
if (removeme)
{
return 0;
}
removeme = 1;
return 0;
}Der Inhalt von removeme hat offensichtlich keine beobachtbaren Auswirkungen, kann also eigentlich komplett weg. Das machen aber weder gcc noch clang, beide mit -O3. Besonders krass: Selbst mit -flto nicht!Zum Spielen habe ich das nochmal leicht umformuliert probiert:
int dummy2()
{
static int removeme = 0;
if (!removeme)
removeme = 1;
return 0;
}
int dummy3()
{
static int removeme = 0;
removeme = 1;
return 0;
}Bei dummy3 fällt gcc und clang auf, dass man removeme komplett wegmachen kann. Bei dummy2 aber auch nicht.Ich bin gerade ein bisschen schockiert, dass selbst Link Time Optimization das nicht wegschmeißt. Hier der Testcode dafür:
int main() {
return dummy1() + dummy2() + dummy3();
}Und da kommt dann dieser Code raus (amd64): 16d0: 80 3d 95 22 00 00 00 cmpb $0x0,0x2295(%rip) # 396c <dummy1.removeme>
16d7: 74 0c je 16e5 <main+0x15>
16d9: 80 3d 90 22 00 00 00 cmpb $0x0,0x2290(%rip) # 3970 <dummy2.removeme>
16e0: 74 13 je 16f5 <main+0x25>
16e2: 31 c0 xor %eax,%eax
16e4: c3 ret
16e5: c6 05 80 22 00 00 01 movb $0x1,0x2280(%rip) # 396c <dummy1.removeme>
16ec: 80 3d 7d 22 00 00 00 cmpb $0x0,0x227d(%rip) # 3970 <dummy2.removeme>
16f3: 75 ed jne 16e2 <main+0x12>
16f5: c6 05 74 22 00 00 01 movb $0x1,0x2274(%rip) # 3970 <dummy2.removeme>
16fc: 31 c0 xor %eax,%eax
16fe: c3 retVielleicht übersehe ich da gerade irgendeine Formulierung in irgendeinem Standard. Mal gucken, was die sagen. Habe Bugs eingetragen bei gcc und clang.
Als Erklärung musste erst die Supply Chain herhalten. Bis mal jemand nachguckte und sah, dass die Fabriken alle mit voller Auslastung produzieren.
Dann hieß es: Die liegen alle in chinesischen Hafen-Lagerhallen rum!1!! Dann hätte sich das aber mit der Zeit normalisieren müssen. Hat es nicht.
Dann hieß es: Die scheiß Crypto-Bros kaufen die alle weg! Die Crypto-Bros benutzen aber heutzutage ASICs, nicht Grafikkarten, von den verstrahlten Ethereum-Deppen abgesehen. Klar ist das Teil des Problems, aber wie groß? Weiß man nicht.
Dann hieß es: Die fiesen Spekulanten kaufen den Grafikkartenmarkt leer und verscheuern das dann fürs Doppelte auf Ebay und co! Nur … wenn man mal genauer hinguckt, gibt es keine Lieferengpässe mehr. Die Grafikkarten sind größtenteils gut lieferbar. Bei den Händlern liegen 10 Exemplare und mehr rum.
Nun, da könnte sich für die ungewaschenen Massen der Eindruck einstellen, dass sie hier nach Strich und Faden abgezockt werden. Und zwar nicht von Crypto-Bros und Scalpern sondern von den Händlern, Großhändlern und Grafikkartenherstellern. Das könnte sich noch verstärken, wenn man mal auf Nvidias Quartalsergebnisse guckt. Wie jetzt, +50% gegenüber dem Vorjahr? Mehr als verdoppelt gegenüber vor zwei Jahren? Und das ist alleine der Gaming-Bereich, im Data Center sieht es nochmal ähnlich aus. Es ist also keineswegs so, dass es da eine Knappheit gibt, und Nvidia nur wenig Karten verkauft kriegt. Die verkaufen aus allen Rohren, es kommt nur nichts zu regulären Preisen beim Verbraucher an. Und alle auf dem Weg verdienen sich dumm und dämlich, wieso sollte also jemand etwas tun?
Nun, Nvidia tut jetzt etwas. Sie erhöhen die Listenpreise. Damit es nicht mehr ganz so nach Raubritterei aussieht.
Fuck, yeah! Und sie behaupten dann auch noch, das habe was mit den Wechselkursen zu tun.
Man sollte dazu sagen, dass schon die Listenpreise in den letzten Jahren eine absolute Frechheit waren. Nvidia hatte immer mindestens eine Consumer-Karte im Angebot, die über 1000 Dollar kostete. Und offensichtlich haben sie gemerkt, dass die Leute soviel zahlen, wenn man nur glaubwürdig genug eine Knappheitsillusion erzeugt.
Wo bleiben eigentlich das Kartellamt und die Verbraucherschützer?
Update: AMD ist natürlich genauso Katastrophenprofiteur. Die haben kürzlich eine neue Grafikkarte rausgebracht, für die man früher nichtmal 100 Euro verlangt hätte — für 200 Euro. Listenpreis, versteht sich. Straßenpreis ist im Moment eher so 350 Euro. Von der Presse wurde das Ding einmal flächendeckend einstimmig zerrissen. AMD wusste, dass das Ding Mist ist, daher gab es keine Testexemplare außer für die größten und loyalsten Tester. Am Ende ist die Karte so grottenschlecht, dass nicht mal die Scalper Interesse haben.
So ein Moment der Tragödie ist immer spannend, weil die einzelnen Zuständigen sich alle von ihrer Schuld reinwaschen wollen, aber noch keine Zeit hatten, sich auf eine Ausrede zu einigen. Da kommt dann sowas hier raus:
Egypt's Heath Minister Hala Zayed claimed that the patients didn't die due to lack of oxygen and accused the Muslim Brotherhood of spreading rumours.The Director of the hospital, Dr Muhammad Sami Al-Najjar, spoke in another video claiming that the situation was normal. He denied that there was a lack of oxygen. He said the patients had died from natural causes, from old age or other chronic diseases.
The Governor of Ash Sharqia, Dr Mamdouh Gorab, said four patients, rather than the whole ward, died.
Aber wartet, ist noch nicht vorbei mit den Schnellschüssen! Da muss noch jemand bestraft werden!1!!Wie wäre es mit denjenigen, die das gefilmt haben? Oder der Krankenschwester, die in der Embryonalstellung katatonisch in der Ecke sitzt!
There are unconfirmed reports on Facebook that the man who filmed the scene has been arrested after Gorab asked security forces to arrest those responsible for taping the incident.Reports have stated that the nurse was fined for "not working during hard times."
In Krisensituationen sind fast alle Menschen gleich: Ängstlich und klein, entweder gelähmt oder instinktiv um sich schlagend.Auch bei uns. Das ist ja kein Zufall, dass die Politik Covid so verkackt hat. Das sind halt die beiden Grundinstinkte des Menschen. In Schockstarre gar nichts tun, oder blinder Aktionismus, weil man es nicht vor sich selbst verantworten kann, gar nichts getan zu haben.
Konzeptionell bin ich ja ein Freund von Rust. Was die sich da an Neuerungen überlegt haben, das hat die Industrie insgesamt vor sich hergetrieben.
Von welchem Nachteil rede ich denn dann? Nun, ich baue hier regelmäßig mein Firefox selbst.
Mozilla stellt der Reihe nach Teile von Firefox auf Rust um.
Das ist ja auch gut so.
Aber zwei Effekte zeigen sich dabei schnell. Der erste ist, dass Rust nicht parallel baut. Neben den ganzen C++-Teilen, die vom Build-Prozess schön auf die Cores verteilt werden, läuft da dann halt ein cargo build für sowas wie 15 Minuten auf einem Core und baut den Rust-Kram. Noch gibt es genug C++-Zeug, dass das noch wenig zu Lasten der CPU-Auslastung geht, aber wenn man inkrementell baut und sich in der Zeit drei C++ und zwei Rust Quellcodedateien geändert haben, dann merkt man das deutlich, denn bei Rust ist die Unterscheidung zwischen Compiler und Linker anders verschoben. Der scheint immer eine Art LTO-Pass zu machen. Jedenfalls kommt es vor, dass der C++-Teil fertig ist und dann das make mit einer 100%-Auslastung auf einem Kern ewig lang an Rust herumrödelt.
Das ist das erste Problem. Das zweite Problem ist noch schwerwiegender. Rust verbraucht echt viel RAM. Ich habe hier eine Kiste mit 16 GB RAM. Die reicht bei praktisch allen Projekten, um die aus der Ramdisk (tmpfs) zu bauen. Nicht so bei Firefox. Da musste ich schon vor einer Weile die Quellen auf der Platte haben, weil sonst der Build mit out of memory abbrach. Jetzt ist es so, dass der Build auch beim von-Platte-bauen gerne mit out of memory abbricht. Stellt sich raus: Der LTO-Teil in dem Rust-Teil von Firefox schluckt mal eben sowas wie 13 GB am Stück. Wenn du da noch ein paar C++-Dateien parallel zu bauen versuchst, dann ist Ende Gelände.
Ich beobachte das mit großer Sorge, wie sorglos Entwickler mit dem Speicherbedarf ihrer Software umgehen. Ich habe noch zwei andere Projekte, bei denen der Speicher knapp wird. Qt muss ich auch von Platte bauen, nicht von Ramdisk. Und LLVM hat neuerdings einen Fortran-Compiler drin. Ich weiß nicht, was die da gemacht haben, aber das Bauen davon muss ich auf zwei Kerne zur Zeit beschränken, sonst frisst das zu viel RAM. Ich vermute eine Template-Instanziierungs-Hölle oder sowas. Der Fortran-Compiler setzt bei LLVM auf ein neueres Fundament als der C++-Compiler, ein generalisiertes Compilerframework namens mlir (ist auch Teil von LLVM).
Chrome und Libreoffice benutze ich nicht und habe ich daher auch nicht zu bauen versucht. Ich vermute mal, das wird mit 16 GB auch knapp.
Update: Dass Rust nicht parallel baut ist eigentlich auch nicht korrekt. Ich kann daher gerade das bei Firefox beobachtete Verhalten nicht erklären. Das liegt allerdings auch schon ein bisschen zurück, denn Firefox hat vor einer Weile angefangen, einfach gefühlt immer darauf zu bestehen, dass man einen komplett neuen Build startet und nicht inkrementell baut. Jedenfalls definitiv immer zwischen Versionen. Insofern kommt der Fall bei mir kaum noch vor, dass ich auf einen Rust warten muss bei Firefox.
New hotness: AMD-Prozessoren-Lock an bestimmte Computerhersteller.
Gibt es eigentlich keine Idee, die so schlecht ist, dass Intel und AMD sie nicht aufgreifen würden?
Doch das Gegenteil ist der Fall: Die Lizenzmodelle der Software-Heinis werden immer grotesker. Die Datenbank- und VM-Hersteller wollen auch noch pro Core bezahlt werden, und sägen damit an dem Ast, auf dem sie sitzen.
Eigentlich müsste man angesichts dieser Frechheit eine Völkerwanderung zu Open Source beobachten. Tut man auch, aber anders als ihr annehmt. Nicht die Enduser benutzen alle Open Source, sondern die kommerziellen Software-Heinis benutzen alle Open Source. Ja genau. Die, die euch dann pro Core Lizenzkosten aufdrücken wollen. Die benutzen intern selber alle Open Source. Denn wer wäre schon so blöd und zahlt pro Core, amirite?
Ich bin ja eh immer wieder erstaunt, dass es kommerzielle Datenbanken wie SQL Server und Oracle überhaupt noch gibt. Früher konnte man sich da was zurechtlegen von wegen "das skaliert bestimmt besser", aber geht doch mal gucken, was die Cloud-Leute für Datenbanken anbieten. Postgres! Die, die beruflich mit Skalierung zu tun haben, die nehmen Postgres. Die, die Skalierung nur vom Golfplatz kennen, wenn sie anderen CEOs vorlügen, wie fortschrittlich ihre IT ist, die nehmen kommerzielle Datenbanken.
Aber aber aber Fefe, das ist bestimmt eine Supportfrage! Wer ordentlichen Support haben will, der kauft beim Marktführer! Wer das sagt, hat offensichtlich noch nie einen Supportfall bei einem Marktführer in Anspruch genommen. Wie man da behandelt wird, das ist unter aller Kanone. Denn die haben euer Geld ja schon an der Stelle. Wieso sollten die euch mit Respekt behandeln? Ihr seid ja schon im Lock-In gefangen und habt den langjährigen Knebelvertrag unterzeichnet! Und wieder: Die, bei denen die Supportkosten wirklich Einfluss auf die Profitmarge haben, die Cloud-Leute, die nehmen lieber Postgres.
Und die nehmen auch nicht VMware sondern lieber Linux-Container und Kubernetes.
Anfang des Jahres hatte uns ein Nutzer mitgeteilt, dass sein Browser, Firefox, meinte, Gentoo’s Installationsmedium würde Malware beinhalten.Erinnert an gmail. Da könnt ihr ja mal einen von Google ausgehenden Spam zu melden versuchen. Wenn ihr auf Kafka-Geschichten steht.Leider hatte der Nutzer den Download nicht beendet bzw. gleich wieder gelöscht (die Warnung sieht halt auch gefährlich aus!). Es stellte sich dann schnell heraus, dass zumindest zum Zeitpunkt unserer Prüfung, alle Mirrors die gleichen Dateien ausgespielt haben (Checksummen stimmen überein) und diese sauber waren (ja, wir haben unsere Images mit verschiedenen Schlangenöl-Lösungen geprüft).
Was war dann der Grund? Die Herkunft! Gentoo nutzt noch Mirrors, kostenlos bereitgestellt von Dritten und kein zentrales CDN. Einer dieser Spiegelserver, mirrors.kernel.org, ist in Google’s SaferBrowsing System gelistet. Aber nicht generell, nein, nur für das *gesamte* "/gentoo"-Unterverzeichnis.
Das schließt eben auch unser Installationsmedium in "/gentoo/releases/amd64/..." mit ein.
Wir haben dann irgendwann durch unsere Kontakte die Information bekommen, dass die Ursache im *Quellcode*-Archiv zu "Shadowinteger's Backdoor" (http://tigerteam.se/dl/sbd/) einem netcat-Klon stecken würde.
Was wir bis heute nicht wissen:
- Da Google’s SafeBrowsing offenbar in der Lage ist auf Verzeichnisebene zu flaggen, wieso haben sie dann die Warnung nicht zumindest auf /gentoo/distfiles beschränkt?
- Warum ist nur mirrors.kernel.org betroffen? Die Datei liegt auf allen unseren Spiegeln. Wenn nun also wirklich Gefahr von dieser Datei ausgehen sollte müsste der gemeine User, der sich auf SaferBrowsing verlässt, doch erwarten können, dass die gleiche Datei immer und überall erkannt und geblockt werden würde.
- Aktuell (das war vor paar Wochen noch anders) scheint tatsächlich die Quellcode-Datei von allen Quellen blockiert zu werden (also wirklich nur sbd-1.37.tar.gz), was Browser, die gegen das SafeBrowsing Download-API prüfen, verhindern.
Seit dieser Zeit kämpfen wir jetzt mit Google um eine Korrektur der Einstufung. Selbst mit unseren noch immer guten Kontakten zu Google (Hallo ChromeOS!) ist da nicht viel zu machen denn bekanntlich ist Google ein technisches Unternehmen: Die wissen, dass Menschen Geld kosten. Also tun die alles um Probleme technisch zu lösen und den Einsatz von Menschen zu minimieren, so auch im "Support": Erst wenn die Error-Rate zu einem gemeldeten Problem eine bestimmte Prozentschwelle überschritten hat, schaut sich ein Mensch den Sachverhalt an... :/
Im AMD-Forum von Reddit ist ein Screenshot von Intels internem Portal aufgetaucht, genauer: von einem Artikel dort, der sich mit Ryzen 3000 beschäftigt, wie Intel das einschätzt und wie das jetzt weitergehen wird.
Meine Erfahrung mit solchen Portalen ist, dass es da durchaus gelegentlich "competitive analysis" über Konkurrenten gibt, aber das ist häufig nur so PR-Blablah. Dieser Artikel hat zwar auch PR, z.B. das Kapitel "Intel´s secret sauce":
Intel´s secret sauce is not a single ingredient. Rather, it is the six pillars of innovation — process, architecture, memory, interconnect, security, and softwareAngesichts von Spectre und Meltdown wirkt auf einige Beobachter nicht sehr überzeugend, dass sie da Security als einen Pillar drinhaben. Aber der Artikel macht auch ein paar ziemlich klare Ansagen, die man so von Intel bisher noch nicht gehört hat.For multi-threaded workloads, such as heavy content creation workloads, AMD´s Matisse is expected to lead.Im Interview-Teil in der zweiten Hälfte werden sie noch deutlicher:They´re using their 7nm process, and with that they get a per-core frequency bump and lower power, which means they can scale to more cores per processor. […] Therefore, on workloads that are heavily threaded, including heavy content creation and most server workloads, they´ll get great performance results. And on price, we expect their pricing to be significantly below ours. So they´ll likely get good performance-per-dollar. That´s what they´re going to compete on, and that´s the risk to Intel.[…]
I also believe AMD´s comeback was a result of being very product-centric. A top priority for AMD was building great products — high-performance compute and graphics solutions — from definition to development to delivery.
[…]
Intel is a premium brand. At times, and on some workloads, we might dip below on performance, like the second half of this year.
Besonders den letzten Satz fand ich ziemlich krass. Da werden bei AMD die Korken knallen. Besser hätten die das gar nicht jemandem gegen Geld in den Mund legen können.Intel ist so in der Defensive in dem Artikel, dass sie ernsthaft als Argument anführen, manche Software (*hust* ORACLE!! *hust*) wolle ja pro Core Lizenzgebühren haben, und da könne es ja günstiger sein, wenn man weniger Cores hat. Wait, what!?
Nicht nur das: In dem Thread unter dem Leak haben sie dann auch noch aus der Kommentarspalte zitiert, die Intels Portal offenbar hat, und der Kommentator da nahm auch kein Blatt vor den Mund.
Ich befürchte, bei Intel gibt es jetzt eine Nacht der langen Messer. Das ist für keinen Manager schön, wenn ihre Dreckwäsche öffentlich gewaschen wird.
Zusammengenommen ergebe sich daraus verglichen mit Vega-GPUs eine um 25 Prozent gesteigerte Rechenleistung pro Taktzyklus (IPC) und eine um 50 Prozent höhere Energieeffizienz (Rechenleistung pro Watt).Der Stromverbrauch war bei AMD immer die Schwachstelle bei den Grafikkarten.
Und bei den CPUs (Anandtech hat da mehr Details als Heise):
the amazing thing is that this chip [Ryzen 3700X] has a TDP of just 65W. Just on paper, it looks like this processor is one of the most efficient x86 performance desktop processors ever made.Ein geringer Stromverbrauch ist auch deshalb gut, weil es weniger Abwärme bedeutet, und weil moderne CPUs riesige Boost-Reserven haben, falls sie nicht gerade am Überhitzen sind. Dann hat AMD noch einen Cinebench-Vergleich gezeigt:Though it should be noted here that something like the Ryzen 7 3800X, which boosts to 4.5 GHz, is being compared to an Intel CPU that boosts to 5.0 GHz. That would put IPC on this test firmly in the hands of AMD.IPC war immer Intels Vorteil gegenüber AMD, das war der Grund, wieso Intels Single-Core-Performance besser war, aber AMD bei Multi-Core-Performance punkten konnte. Obiger Test deutet an, dass AMD jetzt auch bei Single-Core vorne liegt. Das war vorher schon gerüchtet worden, aber es erschien vielen Beobachtern unrealistisch.Man muss allerdings dazu sagen, dass Cinebench traditionell ein sehr AMD-freundlicher Benchmark ist, und AMD auf Launch-Veranstaltungen schon immer die Benchmarks eher unrepräsentativ wählt. Insofern muss man mal gucken, wie sich das in der Praxis niederschlägt. Ich würde auch davon ausgehen, dass AMD einmal alle Spectre-Mitigations angedreht hat bei Intel. Aus Sicherheitsgründen, wissenschon.
Aber selbst wenn man das alles mit bedenkt, ist diese Ankündigung ein ziemliches Erdbeben.
New hotness: RIDL and Fallout.
Intel hat vergleichsweise mächtige Profiling-Features in ihre CPUs eingebaut, mit denen man sehr schön feingliedrig Statistiken kriegen kann, wo gerade die Performance verloren geht. Stellt sich raus: Aus den so systemweit gemessenen Statistiken kann man Rückschlüsse ziehen.
Eine schöne Übersicht gibt es hier.
Ich will mich da gerade nicht zu weit aus dem Fenster lehnen, aber ich glaube AMD hat da weniger Statistik-Features und könnte daher weniger betroffen sein. Ich habe aber gerade keine aktuelle AMD-CPU im Zugriff (warte gerade auf Zen 2).
Update: AMD sagt, sie seien nicht betroffen.
Update: Meine Zusammenfassung mit Profiling war Bullshit. Das war die Ecke, aus der ich die nächste Reihe von Angriffen erwartet hatte. Die Angriffe haben nichts mit Profiling zu tun.
Ich sag ja schon die ganze Zeit, dass VMs viel zu komplex sind und viel zu viel Code haben, als dass man sie einfach so als Security-Boundary einziehen kann. Aber auf mich hört ja keiner.
The CTO stressed that the decision was made not based on technical issues that the company faced, but on a careful consideration of business opportunities the company had with its 7LP platform as well as financial concerns.Also doch technische Probleme, war zu teuer und funktioniert nicht so gut wie erwartet, oder so. Globalfoundries ist die ausgegliederte Fertigungsabteilung von AMD, und AMD hat neulich angesagt, dass sie ihr 7nm bei TSMC fertigen wollen.Für mich klingt das jedenfalls, als wäre Globalfoundries so gut wie aus dem Rennen. Schade eigentlich. Ihr erinnert euch sicher noch, wie schlecht das für den PC-Markt war, als nur Intel konkurrenzfähige CPUs liefern konnte. Neben TSMC bleiben noch Samsung und IBM übrig, aber IBM ist m.W. weit abgeschlagen. Das ist nicht gut, wenn die halbe Welt von TSMC abhängt. Apple sitzt auf so viel Cash, die könnten den Laden wahrscheinlich einfach mal kaufen, um ihren Nachschub zu sichern.
Intel fertigt noch selber und kann wohl auch für andere fertigen, aber warum würden sie ihrer Konkurrenz da günstige Preise diktieren? Und wenn sich jetzt rausstellt, dass TSCM den 7nm-Prozess doch nicht ordentlich hinkriegt, oder mit zu viel Ausschuss, dann beißt sich Globalfoundries wahrscheinlich in den Arsch.
Update: Leserbrief:
IBM haben ihre Foundrysparte plus R&D 2014 an Globalfoundries verkauft, und 7nm wäre das erste Resultat davon gewesen. IBM macht also selber schon kein Foundryzeugs mehr, daher ist Globalfoundries stopp von 7nm umso verblüffender. AMD scheint aber gut vorbereitet zu sein. Deren Zeitplan für Zen 1/2/3 schien schon immer sehr optimistisch für Globalfoundries zu sein. Jetzt stell sich praktisch raus, dass der Teil für Zen 2/3 wohl von Anfang an an TSMCs Zeitplan angelehnt war.
Oh das hatte ich gar nicht mitgekriegt mit dem Verkauf. Das ist ja eine noch krassere Marktkonzentration dann.
Ich als oller Verschwörungsblogger stelle mir gerade vor, wie Intel sich in einer gammeligen Kaschemme mit schattigen Spooks trifft, die ihnen ihre Kumpels aus der US-Regierung genannt haben, einen Wanzen-Sweep macht und dann einen Blankoscheck auf den Tisch legt.
Aus meiner Sicht ist keine dieser angeblichen Lücken besonders gruselig. Keine davon erlaubt Elevation of Privileges von User Space in den Kernel (wie bei Meltdown). Das sind hauptsächlich Angriffe gegen Schlangenöl-Bullshit-Mist, den man eh nicht in seinem Prozessor haben will, weil es bloß unnötig die Komplexität erhöht und eh nicht klar ist, ob man dem jetzt trauen kann oder nicht.
Ich würde mir da jetzt keine großen Sorgen machen, wenn ich einen Ryzen hätte. Was ich im Moment noch nicht habe. Werde ich aber demnächst, denke ich. Alleine um die Meltdown-Fix-Verzögerung loszuwerden.
Update: CNET sagt, dass die "Forscher" AMD nur 24h Zeit gaben vor der Publikation. Ja, äh, nee, das riecht eher wie eine Schutzgelderpressung als wie eine legitime Veröffentlichung.
Update: Auf Reddit haben Leute noch herausgefunden, dass die "Büroräume" in deren Video aus Stock Footage kamen. Die Lektüre vom Disclaimer lohnt auch. Im Kleingedruckten stehen so Dinge wie dass sie sich vorbehalten, an der Börse Profit von ihren Analysen zu machen, und dass es sich alles bloß um ihre Meinung und nicht um Faktenbehauptungen handele. Ja nee klar.
Update: Auf der anderen Seite braucht man keine Backdoor im Prozessor, wenn der User eh Windows benutzt. Was für eine Frechheit.
Hier gibt es eine Theorie. Intel soll angeblich mal wieder bei unlauteren Methoden erwischt worden sein. Es gibt Gerüchte, dass sie Händler genötigt haben sollen, noch schnell eine Großpackung Intel-Chips zu kaufen, und sie kriegen Rabatt, wenn sie die AMD-Chips nicht aufnehmen. Dafür gibt es m.W. keine Beweise, nur Gerüchte.
Aber die andere Sache, die gerade rumgeht, und die von mehreren Leuten behauptet wurde:
Eine an die Tester geschickte Mail soll unter anderem die Aufforderung "Call us before you write" (Ruf uns an bevor du schreibst) enthalten. Dazu soll Intel "Guidelines" herausgeben, wie man die AMD Ryzen CPU testen soll.Und das rückt die Sache natürlich ein ein anderes Licht. Möglicherweise hält AMD absichtlich die Samples bis auf den letzten Drücker zurück, um Intel so wenig Möglichkeit wie möglich zum Vorbereiten zu geben.
Auf der anderen Seite ist momentan anscheinend auch die Plattform noch instabil:
Unser Testbericht zum neuen Ryzen wird vermutlich nicht zum Launch fertig sein, denn aktuell scheinen nicht einmal die BIOS-Versionen der Mainboards final zu sein. Mehrere Redakteure, die bereits Muster besitzen, haben sich in Foren geäußert, dass die Systeme zum Teil instabil laufen. Neue Bios-Versionen sollen die Probleme in Kürze beheben.Das wäre natürlich auch ein valider Grund, Benchmarks vor dem Launch bzw. vor der Verfügbarkeit der stabilen BIOS-Versionen zu blockieren.
Egal was man von AMDs Produkten hält. Alleine dass Intel und Nvidia mit ihren Preisen mal wieder in die Realität zurückgeholt werden, dafür sind wir alle AMD zu Dank verpflichtet.
Von dort aus wollte ich jetzt eine E-Mail an jemanden bei live.com schicken. Die hat deren Mailserver direkt abgelehnt, weil anscheinend Hetzners IP-Range bei denen abgewiesen wird. Ich weiß mit Sicherheit (und wir haben diese IP schon über ein Jahr), dass von dort aus noch nie ein Spam oder Newsletter oder Kaltacquise oder irgendwas auch nur entfernt nach Spam Riechendes rausging. Und letztes Jahr ging Mail an live.com noch. Daher meine Schlussfolgerung, dass die Blockage ganze Subnetze bei Hetzner betrifft, wenn nicht gar den ganzen Laden.
Aber deshalb blogge ich das nicht. Ich blogge das, weil ich ein Ticket bei Hetzner aufgemacht habe. Und als Antwort kam, ich (!) solle mich doch bitte persönlich in einen Dialog mit Microsoft (!!) begeben, um für meine IP bei denen eine Ausnahmeregelung auszuhandeln.
Lange habe ich mich nicht mehr über etwas so aufgeregt. Die externalisieren schlicht die Aufräumkosten für ihre nicht existierende Spamverhinderung an ihre nicht spammenden Kunden. Was für eine Frechheit.
Hey, soll ich auch gleich noch den Fußboden auskehren und das Klopapier wechseln?
Boah da krieg ich echt Blutdruck bei sowas. Ich guck mich mal nach anderen Hostern um. Unglaublich.
Update: Ein Einsender meint, ihm sei das auch schon mal bei 1&1 passiert. Er und andere meinen, das sei wohl Microsofts Schuld dann, und wer da seine Mail hostet, der will halt nicht kontaktiert werden :)
Update: Ein anderer Einsender hatte das selbe Problem bei Strato, und noch jemand anderes bei netcup. Wir haben jetzt zwei Möglichkeiten. Die ISPs sind alle kacke, oder Microsoft dreht frei. Occam's Razor sieht nicht gut aus für Microsoft.
Update: Ein Einsender teilt folgende Geschichte mit uns:
bez. Mail an live kann ich nur raten Dich nicht aufzuregen. Wir sind eine Hochschule, sind im Landesnetzwerk von Baden-Württemberg, signieren alle Mails (soweit ich das sehe) mit einer ordentlichen DKIM-Signatur und hatten Probleme mit Live und mit allen Benutzern von Barracuda-Antispamdingern.
Barracuda war immerhin so nett nach 4 Tagen eine Antwort zu senden daß die Mail nicht zugestellt wird (einer der Barracudabenutzer war eine Bank ... 4 Tage später habe ich erfahren, daß die Mail nicht ankam .. *grrr*)Bei Live wurde die Mail einfach weggefiltert. Kein Hinweis an den Empfänger, kein Hinweis an den Absender. Hat richtig gekracht da deshalb viele Studienbewerber aus dem Ausland Ihre Immatrikulationsunterlagen nicht rechtzeitig bzw. gar nicht bekommen haben ...
Reagiert hat Microsoft Null. Weder auf Mail, noch Webformkontakt noch Fax noch Brief. Erst als ich ALLE mails von Live pauschal abgelehnt habe und im Errorcode einen Link auf unsere Homepage eingebaut habe auf eine Seite mit Microsoft Kontaktdaten und der Bitte der Livekunde möge sich beschweren kam Bewegung in die Sache .....
Au weia.
'U need to get used to the cold water and no electricity. Everyday use cold water, u will probably get your first shower when u get to your mudhafa [annex]. The house u stay in before the muaskar [training camp]. It's tough bro lol, A LOT of patience is required [sic].'Start eating small amounts of food to get used to it, because u will be sharing your food as soon as u arrive. Bland food btw lol, inshallah it will be better when u get to mudhafa. Also u need to decide where u wana get placed. Alhamdulillah. I chose Halab [Aleppo]. We're placed in Menbej, small town, no action, just normal life alhamdulillah [sic].'
Und ordentliches Bier gibt es hier auch nicht!1!!
Eines meiner Projekte ist eine Suchmaschine für Code. Damit indiziere ich dann den Quellcode bei Kundenprojekten, damit ich schnell darin herumnavigieren kann. Für kleinere Codebasen lohnt sich das nicht, da macht man lieber grep -r und hat die Quellen in einer Ramdisk. Aber bei manchen Kunden ist der Quellcode im höheren zweistelligen Gigabytebereich. Da braucht man dann schon einen Index.
Wenn ich in meinem Index jetzt nach einem Wort sucht, und im Allgemeinfall ist das ein Bezeichner aus dem Quellcode, d.h. ein längeres Wort, dann sagt mir mein Index die Namen der Dateien, in denen das Wort vorkommt. Aber ich will ja nicht nur wissen, in welchen Dateien es ist, sondern auch die Zeilennummer, damit ich da schön hinnavigieren kann.
Mein Code muss daher die Datei öffnen und darin nach dem Wort suchen und mir dann die Trefferzeilen mit Zeilennummer ausgeben. Wenn ich die Zeilennummer ausgeben will, kann ich aber nicht Boyer-Moore verwenden und dann Zeichen in der Mitte überspringen. Daher wird die Suche langsamer.
Das war der Grund, wieso ich gestern mal mit der Frage verbracht habe, wie man möglichst schnell die Newlines in einem Speicherblock zählen kann. Wenn es nämlich gelingt, die Newlines in einem Speicherblock effizienter als durch zeichenweises Lesen zu zählen, dann ist es möglicherweise effizienter, erst mit Boyer Moore nach dem Match zu suchen und dann im Speicher davor nochmal die Newlines zu zählen.
Damit das klappt, müsste man deutlich effizienter zählen. Um zu verstehen, wie man effizienter sein kann, als jedes Byte einmal kurz anzugucken, muss man die Speicherhierarchie in CPUs verstehen. Die CPUs sind heutzutage rasend schnell, aber der Speicher ist vergleichsweise langsam. CPUs haben mehrere Hierarchien von Zwischenspeichern, aber selbst die sind noch langsam. Wenn man ein Byte aus dem schnellsten (und kleinsten) Cache liest, dem Level 1-Cache, dann hat man immer noch pro Zugriff eine Straflatenz zu erdulden, bis der Wert vorliegt. Auf meinem etwas älteren AMD-Desktop war es ein Taktzyklus, bei einem modernen i7 ist es offenbar eher 2 oder 3. Wie sich rausstellt ist diese Latenz aber nicht pro Byte sondern pro Zugriff. Wenn man also mehr als ein Byte auf einmal liest, dann zahlt man diese Strafsteuer nur einmal. Auf einer 64-bit-Architektur passen in ein Maschinen-Register 8 Bytes rein. Die Kosten für Newlinezählen wären damit also potentiell ein Achtel dessen, was man für die naive Implementation zahlt. Zum Vergleich:
size_t byfoot(const char* s,size_t l) {
size_t i,r;
for (i=r=0; i<l; ++i)
if (s[i]==n) ++r;
return r;
}Das ist die naive Implementation. Die braucht für eine 5k-Datei ca. 15000 CPU-Zyklen auf einem 4000er i7.Der erste Verbesserungsansatz wäre, dass man wortweise liest und dann innerhalb des Wortes die Bytes einzeln rausmaskiert zum Vergleichen.
size_t byfoot2(const char* s,size_t l) {
size_t i,r;
for (i=r=0; i+sizeof(i)<=l; i+=sizeof(i)) {
size_t x=*(size_t*)(s+i);
while (x) {
r += ((x&0xff) == 0x0a);
x >>= 8;
}
}
for (; i<l; ++i)
if (s[i]==n) ++r;
return r;
}Hier haben wir pro Byte deutlich mehr Operationen, aber die laufen alle innerhalb der CPU asynchron ab, und es bleibt noch Zeit übrig, um auf den Speicher zu warten. Hiermit bin ich schon runter auf 11800 CPU-Zyklen.Wenn man noch mehr Performance will, muss man tricksen. Die beste Variante, die ich dafür gestern gefunden habe, ist die hier:
static size_t fold(size_t v) {
return (v * (size_t)0x0101010101010101) >> (sizeof(v)*8-8);
}
static size_t nlto1(size_t v) {
v ^= (size_t)0x0a0a0a0a0a0a0a0a;
v |= (v & (size_t)0x0101010101010101ull) << 1;
v = ((v - (size_t)0x0101010101010101ull) & ~v & (size_t)0x8080808080808080ull);
return v >> 7;
}
size_t newlines(const char* s,size_t l) {
size_t i,n=0,r=0,max=l/sizeof(n);
size_t* S=(size_t*)s;
int o=255;
for (i=0; i<max; ++i) {
n += nlto1(S[i]);
if (!--o) {
r += fold(n);
n=0;
o=255;
}
}
r += fold(n);
if (l %= sizeof(i)) {
s += i*sizeof(n);
for (; l; --l)
r += (*s++=='\n');
}
return r;
}Ich habe mal die Kommentare entfernt, weil ich mir dachte, dass vielleicht der eine oder andere von euch Spaß daran haben könnte, zu verstehen, wie das funktioniert, und warum jeder einzelne Schritt davon da ist und nötig ist. Mit diesem Code bin ich für die selben Daten schon runter auf 5200 Zyklen. Nicht schlecht! Geht aber noch besser. Moderne CPUs haben Vektorinstruktionen für sowas, und mit SSE komme ich auf 2500 Zyklen. Ich vermute, dass auch damit noch nicht das Ende der Fahnenstange erreicht ist.Wenn jemand eine klarere oder schnellere Variante des portablen Codestücks findet, bitte ich um eine Email mit den Details!
Die mir wichtige Lektion an der Stelle ist jedenfalls, dass Performance auf heutigen CPUs fast ausschließlich eine Frage von "wieviel Speicherzugriffe habe ich" ist. Unter dem Gesichtspunkt muss man auch Datenstrukturen bewerten.
Update: Oh, einer noch. Das da oben ist im 64-bit-Modus. Im 32-bit-Modus lohnt sich das Bitgefrickel nur wenig bis gar nicht, da ist in meinem Messungen die zweite Variante von oben sogar geringfügig schneller als die dritte. Dafür braucht spannenderweise der selbe SSE-Code nur noch 1800 Zyklen. Keine Ahnung, wie das kommt.
Es gibt übrigens auch noch eine Bitfrickel-Variante von fold:
static size_t fold(size_t v) {
v=(v & (size_t)0x00ff00ff00ff00ff) + ((v>>8) & (size_t)0x00ff00ff00ff00ff);
v=(v & (size_t)0x0000ffff0000ffff) + ((v>>16) & (size_t)0x0000ffff0000ffff);
if (sizeof(v)>4)
v = (v & 0xffffffff) + (v>>32);
return v;
}Die ist aber geringfügig langsamer bei mir. Das hängt von der Performance der Integer-Multiplikationseinheit ab. Auf anderen CPUs ist möglicherweise das Bitfrickeln schneller.
Update: Wie das erste Adlerauge (Glückwunsch!) schon gemerkt hat, hat die Nicht-Bitfrickel-Fold-Funktion ein Overflow-Problem, wenn zu viele Newlines auf einmal reinkommen. Das ist leider nicht so einfach zu fixen. Ich verwendet daher gerade die Bitfrickel-Funktion, auch wenn das in der Praxis so gut wie nicht vorkommt in Code. Ich wollte euch den Fold-Code trotzdem nicht vorenthalten, weil er so schön bewusstseinserweiternd ist.
drwx------ root/root 0 2014-10-02 02:53:49 ./ drwxr-xr-x root/root 0 2014-10-02 02:53:49 ./usr/ drwxr-xr-x root/root 0 2014-10-02 02:53:49 ./usr/share/ drwxr-xr-x root/root 0 2014-10-02 02:53:49 ./usr/share/man/ drwxr-xr-x root/root 0 2014-10-02 02:54:04 ./usr/share/man/man1/ -rwxr-xr-x root/root 4840 2014-10-02 02:54:04 ./usr/share/man/man1/google-chrome-unstable.1u.s.w.
Fälle jemandem was auf? Wenn man das in / auspackt, dann ist danach / nur noch für root les- und ausführbar.
Einmal mit Profis arbeiten!
Das ist das hier:
-rw-r--r-- 1 leitner users 47942700 Oct 3 03:24 google-chrome-unstable_current_amd64.deb
$ host -t mx guardian.co.ukDas darf doch nicht wahr sein!
guardian.co.uk mail is handled (pri=30) by guardian.co.uk.s200b1.psmtp.com
guardian.co.uk mail is handled (pri=10) by guardian.co.uk.s200a1.psmtp.com
guardian.co.uk mail is handled (pri=20) by guardian.co.uk.s200a2.psmtp.com
guardian.co.uk mail is handled (pri=40) by guardian.co.uk.s200b2.psmtp.com
$ whois psmtp.com
[…]
Registrant:
DNS Admin
Google Inc.
1600 Amphitheatre Parkway
Mountain View CA 94043
Wenn man mal ein bisschen rumguckt, nimmt auch zeit.de einen externen Provider für ihre Email, sueddeutsche.de geht anscheinend über deren ISP (das ist möglicherweise gerade eben noch so vertretbar), der tagesspiegel.de geht über einen externen Spamdienstleister, der immerhin in Deutschland sitzt. Trotzdem finde ich das für Zeitungen nicht in Ordnung. spiegel.de, faz.net, taz.de und heise.de haben ihre eigenen Mailserver.
Update: Der Dienstleister vom Tagesspiegel gehört, so mailt mir gerade jemand, einer Firma in Virginia, und hat außerdem ard.de und swr.de als Kunden. (Danke, Peter)
Es gab da gestern schon die Meldung, dass die "wenn du nicht arbeitest, zahlen wir keine Sozialhilfe"-Version der Briten von einem Gericht kassiert wurde, aber leider nicht aus grundsätzlichen Gründen (die Richter haben sogar explizit angesagt, dass das kein Verstoß gegen das Zwangsarbeitsverbot sei) sondern weil die da bei der Umsetzung irgendeine Formalie verkackt haben. Das hätte nochmal durchs Parlament gemusst oder so. Da haben die eh die Mehrheit dank des bekloppten winner-takes-all-Wahlrechts hier, das ist also nur eine Formalie. Und das Arbeitsamt hat direkt angesagt, dass sie die rückwirkend fälligen Sozialhilfezahlungen jetzt nicht auszahlen sondern erstmal weiter klagen wollen. Es läuft halt überall gleich, wenn "Konservative" an der Macht sind.
Update: Die 741 sind nur in Camden, einem Borough (Bezirk). In Westminster (anderer Bezirk) sind es schon 2327 Haushalte.
Der Artikel behauptet, es ginge um die Perforce-Datenbank. Das ist ein Version Control System für Dokumente und vor allem für Sourcecode. Das wäre ausgesprochen peinlich, wenn Nvidia sich von AMD die Treibersourcen besorgt hätte, denn die öffentliche Wahrnehmung ist, dass Nvidias Treiber denen von AMD deutlich voraus sind. Das wäre wie wenn Miele bei GE Waschmaschinen-Knowhow klaut oder so.
Wo wir gerade bei wenig überzeugenden Herstellern waren: Auch Intel hat sich auf der CES alles andere als mit Ruhm bekleckert. Die mussten eine neue Messmethode für Energieverbrauch erfinden, weil ihre alte unehrliche Messmethode nicht unehrlich genug war. Mit der neuen Methode können sie dann ihre alten 13W-Teile als 7W-Teile anpreisen. Hintergrund: die gehen in ihrem Modell dann von der "üblichen Nutzung" aus, nicht von Maximalstromverbrauch unter Benchmarkstress o.ä., aber das ist der eigentlich entscheidende Faktor für die Bewertung dessen, ob eine CPU sich für ein Tablet oder Mobiltelefon eignet. Und genau den Eindruck wollten sie hier vermitteln, dass ihre Core-Prozessoren sich für schmale Tablets eignen. In der Praxis würde dann bei zu hoher Belastung der Prozessor zu warm und (hoffentlich) drosselt die Elektronik drumherum dann den Takt runter, damit das Ding nicht überhitzt. Ehrlicherweise müsste man dazusagen, dass man dann eben nicht die versprochene Leistung kriegt, sondern nur gedrosselte.
Dieser Eindruck drängt sich mir gerade vom gesamten CPU-Markt auf. Keiner hat da mehr irgendwelche echten Neuheiten oder Verbesserungen zu bieten, das ist nur noch Marketing-Bullshit, den sie uns in die Augen rieseln, damit uns nicht auffällt, dass es nicht mehr nach vorne geht. Dabei ist da doch nichts schlimmes bei, wenn es mal ein bisschen stockend vorangeht. Geht ja bei allen stockend voran. Dass die uns dann alle zu beschubsen versuchen, das ärgert mich.
Übrigens gibt es ja doch noch spannende Trends bei der Hardware, so ist das ja nicht. Z.B. AMD Open 3.0, das ist ein Standard für die physische Board-Form von zukünftigen Server-Einschüben. Dahinter verbirgt sich ein Vorstoß von Facebook, die gerne wie Google coole Rechner haben würden, aber gerne den Markt die Preise nach unten optimieren lassen würden, und dazu müssen die Komponenten eben austauschbar sein. Google baut sich dann ihren Kram selber, Facebook geht eher den weg, den Marktteilnehmern Vorgaben zu machen. Und so wenig Wachstum wie der PC-Markt im Moment hat, springen die Marktteilnehmer da gerne auf.
Naja, gibt ja noch AMD, deren Atom-Konkurrenz ist eh besser. Und was tut AMD? AMDs nächste Atom-Killer-Generation wird auch nur Windows 8 unterstützen. Was zur Hölle?!? Immerhin klingt es bei AMD nicht so, als wollten sie absichtlich Hürden gegen Linux aufbauen. Aber trotzdem.
Until recently, drastic cutbacks like this were the province of down-and-out medium-sized cities like Camden, N.J. – where half the police force has been let go. Or Oakland, Calif. – where the cops no longer answer burglary calls.Alto hatte bei der letzten Volkszählung 2000 immerhin knapp 1200 Einwohner. (Danke, Rop)
Sein neuester Streich: Ein x86-Emulator in Javascript. Im Emulator läuft ein Linux-Kernel, und das ganze emuliert einen Ranz-x86 mit Ramdisk und Serialport für die Ausgaben. Spannenderweise performt das in Firefox doppelt so gut wie in Chrome schreibt er. Auf jedenfall mal wieder ein echter Fabrice Bellard-Kracher.
Das Problem, wenn man seinen ganzen Scheiß selber schreibt, ist, dass gelegentlich was nicht funktioniert, und dann muss man rumdebuggen. Heute habe ich mal wieder eine längliche Session hinter mir. Das Symptom war, dass libjava in gcc nicht baut. Das erste Problem war, dass gcc ein GNU cmp feature benutzt, nämlich --ignore-initial, welches mein cmp nicht implementiert. Meine Versionen der Utilities implementieren im Allgemeinen nur die Features, die von der Single Unix Specification verlangt werden.
gcc möchte dieses cmp-Feature haben, weil der Buildprozess Dateien vergleichen will, ohne die ersten 16 Bytes mitzuvergleichen. Daher guckt configure, ob cmp die Option kennt, und wenn nicht, dann gibt es einen Fallback auf tail +16c in Tempdateien. Ich habe zwar auch ein tail, aber das war nicht in meinem $PATH, da war das tail von coreutils. Und das kennt seit ein paar Versionen +16c nicht mehr. Tolle Wurst.
Stellt sich raus, dass mein eigenes tail das doch gekannt hätte. Das habe ich mal aus genau dem Grund implementiert. Gut, weiter im Text. Kompiliert immer noch nicht. Symptom sind irgendwelche Linkfehler im Java-Toolkit. Stellt sich raus, dass da in einem .zip-File irgendwelche Klassen fehlten. Hat auch nur einige Stunden gedauert, das rauszufinden. Stellt sich raus, dass die folgendes tun: cp -pR dir1 dir2. Problem 1: mein cp kannte nur -r, nicht -R. Mein Fehler, schnell gefixt. Problem 2: mein cp hat sich geweigert, die Kopie durchzuführen, wenn das Zielverzeichnis schon existierte. Problem 3: mein cp hat dann zwar eine Fehlermeldung rausgehauen, aber keinen nonzero-Exitcode gehabt, daher hat der gcc-Build nicht abgebrochen. Nachdem ich das gefixt hatte, läuft der gcc-Compile anscheinend durch. Ich sage anscheinend, weil ich das in meinem 3 GB Ramdisk zu kompilieren versucht habe, und die war voll. 3 GB ist zu wenig, um gcc zu kompilieren. O tempora, o mores. Ich habe hier noch eine 40 MB Platte rumliegen irgendwo. Ja, MB. Nicht GB.
Oh und warum wollte ich gcc kompilieren? Um Dragonegg auszuprobieren. Und: Es funktioniert! Coole Scheiße!
Dem Gesetzentwurf zufolge, der der Süddeutschen Zeitung vorliegt, sollen personenbezogene Daten für Zwecke des Adresshandels und der Werbung in Zukunft nur noch genutzt werden dürfen, wenn der Betroffene dazu seine Einwilligung gegeben hat. Davon ausgenommen sind Werbesendungen von Spendenorganisationen.Ach. Nanu? Da kommt bestimmt noch eine Ausnahmeklausel für die Lotterien hin, wie ich unsere Qualitätspolitiker kenne. Immer bis zum äußersten dem Datenschutz verpflichtet, das sieht man schon an den ganzen Wanzen, Kameras und Trojanern, mit denen sie uns bearbeiten wollen. Und den Telekommunikations-Vorratsdaten. Und den Daten, die zur Geldwäschebekämpfung gesammelt werden.
Der Film ist in den Guantanamo-Tribunalen gegen mutmaßliche Qaida-Terroristen so etwas wie ein Zeuge der Anklage. Er soll helfen, Urteile herbeizuführen. Das gibt sogar der Auftraggeber zu: "Er ist vorverurteilend, und das ist der Grund, aus dem wir ihn zeigen", zitiert die "Los Angeles Times" den Chefankläger, Oberst Lawrence Morris. "Ich glaube, die Menschen denken, dass Vorverurteilung irgendwie falsch ist."Ja, aber echt mal, was ist denn daran bitte verwerflich, wenn man vor einem fairen und unparteiischen Gerichtsverfahren die Angeklagten vorverurteilt!1!!
Bisher ist der Film den Geschworenen (genau wie Richter und Ankläger sind sie US-Soldaten) erst einmal gezeigt worden: Im Prozess gegen den Chauffeur Osama Bin Ladens, Salim Hamdan. Dass keines der in dem Film gezeigten Verbrechen Hamdan zur Last gelegt wurde, thematisierte die Verteidigung zwar; es überzeugte aber den Richter nicht.Unglaublich. Und wie verteidigen sie diese Farce? Sie sagen, bei den Nürnberger Tribunalen sei das alles ähnlich gelaufen. Auch da haben sie offenbar einen Propaganda-Film über die Nazis am Anfang gezeigt. Aber darum geht es nicht. Es geht um zwei Dinge. Erstens: so zu tun als seien "die Terroristen" und "die Nazis" vergleichbar. Zweitens: den guten Ruf der Nürnberger Tribunale auf dieses peinliche Spektakel zu übertragen. Hoffentlich wird beides nicht gelingen.
The judge said the prosecution cannot use a series of interrogations at the Bagram air base and Panshir, Afghanistan, because of the "highly coercive environments and conditions under which they were made."At Bagram, the judge found Hamdan was kept in isolation 24 hours a day with his hands and feet restrained, and armed soldiers prompted him to talk by kneeing him in the back. His captors at Panshir repeatedly tied him up, put a bag over his head and knocked him the ground.
Wer hätte das gedacht. Es gibt auch beim Militär Leute, bei denen noch Reste von Anstand übrig sind.
"Ich bin unschuldig": Mit dieser knappen Erklärung von Salim Ahmed Hamdan, übermittelt durch seinen Anwalt, und mit der Auswahl von Geschworenen hat im neuen Gerichtstrakt des Gefangenenlagers Guantánamo Bay auf Kuba das erste amerikanische Militärgerichtsverfahren seit dem Zweiten Weltkrieg begonnen. Dieser Trakt wurde trotzig "Camp Justice" getauft - wie "Gerechtigkeit".Na dann kann da ja nicht viel schief gehen.
Lawyers for the driver, Salim Ahmed Hamdan, asked for the records to support their argument that prolonged isolation and harassment at the Guantanamo prison have mentally impaired him and could affect his ability to aid in his defence against war crimes charges.So ein Ärger!!1!
Gut, mehr als 5 Schüffelstellen im Staat, das ist selbst für Deutsche Verhältnisse viel, insofern wäre das schon verzeihlich gewesen, wenn sie das jetzt übersehen hätten. Aaaaaber mir wurde vorhin von gewöhnlich gut unterrichteter Quelle gesagt, daß unsere Regierung (vom Land Berlin, in anderen Bundesländern sieht das aber vermutlich ähnlich aus, und wer mal ein bißchen Spaß hat, kann sich auch mal die Referenzlisten und Presseerklärungen angucken) ihr Lawful Interception Equipment von den Israelis (!!!!) gekauft hat, und die hätten per Default schon mal eine Schnüffelschnittstelle mehr drin (und vermutlich auch eine besonders großzügig dimensionierte Wartungsschnittstelle). Warum von den Israelis? Weil die am billigsten waren. Nein, lacht jetzt nicht. Das ist genau das Geschäftsmodell des israelischen Geheimdienstes. Andere Dienste geben viel Geld aus, um anderer Länder Telco-Infrastruktur zu hacken. Israel subventioniert ihre Telco-Industrie so stark, daß sie überall die Ausschreibungen gewinnen, und so zahlen die anderen Länder noch dafür, daß sie das israelische Abhörequipment installieren. Wer glaubt, daß ich mir das gerade aus dem Arsch ziehe, der kann ja mal Amdocs, Verint und Comverse googeln. Erich Möchel ist hierzu auch immer wieder eine unerläßliche Quelle.
Nächste Hürde mal wieder der 32-bit Kram. gcc will auf amd64-Systemen auch gleich einen gcc mitbauen, der 32-bit Binaries erzeugt, für "gcc -m32". Schön und gut, allerdings kommt der mit einem Runtime, insbesondere für C++ und Java, und dieses Runtime nimmt dann an, daß es auch die System-Header für 32-bit Systeme vorfindet, was nicht der Fall ist. Insbesondere die Syscall-Nummern sind anders, einige Structs vermutlich auch. Gentoo löst das Problem, indem sie die glibc-Includes aufhacken, so daß die per #ifdef je nach Zielplattform andere Dateien reinziehen. Ein gruseliger Hack, und eben auch non-default. Das hat die glibc echt ganz großartig verkackt, in Zusammenarbeit mit gcc. Und so sind da jedes Mal wieder Eingriffe nötig, um den Scheiß überhaupt kompiliert zu bekommen. Als das dann nach diversen Anläufen doch irgendwann funktionierte, stellte ich zu meiner Überraschung fest, daß gcc jetzt warnt, wenn man "if (i + 3 < i)" macht bei signed ints. Wow. Sollte ich doch mal was erreicht haben mit meinem Kampf gegen die Windmühlen?
glibc installiert seine Header in /usr/include, und hat verschiedene Header für x86 und x86_64. Man kann aber gcc mit -m32 aufrufen, und dann kompiliert er für x86. Leider benutzt er dann immer noch /usr/include. In den meisten Fällen ist das OK, aber manchmal eben nicht, wie z.B. beim Java-Runtime von gcc. Nun hat gcc einen Override-Mechanismus für sowas. Z.B. included er vor /usr/include noch seinen Override-Pfad /usr/lib64/gcc/x86_64-unknown-linux-gnu/4.1.1/include (bei mir). Nun, leider ist auch dieser Pfad der selbe bei -m32.
gcc hat einen Mechanismus, um sowas zu fixen. Man kann ein specs-File erzeugen. Früher hat gcc das mitgeliefert, heute ist das built-in. Man kann das trotzdem noch extrahieren (ruft mal "gcc -dumpspecs" auf, um euch den Horror mal zu geben) und irgendwo geschickt platzieren, aber … wir haben 2007. Liebe gcc-Leute, das ist unter aller Sau. Fixt das mal. Und wenn die glibc-Deppen nicht pro Plattform andere Includes hätten, wäre das auch alles kein Problem. Das liegt im Übrigen u.a. daran, daß glibc die Kernel-Header included. Ich habe das am Anfang auch gemacht bei der dietlibc. Linus himself hat mir dann eine Mail geschrieben, daß ich das nicht machen soll, weil das nur Probleme macht, und hey, rückblickend hatte der Mann sowas von Recht… tja, nur bis zur glibc hat sich das noch nicht rumgesprochen.
Wenn ihr eine 64-bit Distribution fahrt, dann guckt euch mal an, wie die das regelt. Gentoo hat da echt einmal den Hazmat-Anzug angezogen und ein Konstrukt namens "multilib" gebaut. Auf meinem Gentoo-Testsystem sieht z.B. /usr/include/wchar.h so aus:
/* Autogenerated by create_ml_includes() in multilib.eclass */Na, ist das nicht wi-der-lich? Danke, liebe glibc, daß ihr Linux so effektiv kaputt gemacht habt. Nicht einmal offene Eiterwunden wie X oder Samba sind je so tief gesunken.#ifdef __i386__
# include
#endif /* __i386__ */#ifdef __x86_64__
# include
#endif /* __x86_64__ */
Oh, noch nen Nachschlag für die Variante mit dem "specs"-File: wenn ich das anfasse, und da z.B. folgendes bei cpp_options reineditiere:
{m32:-isystem /usr/include32}dann hängt mir das natürlich auch beim dietlibc-für-x86-Kompilieren /usr/include32 in den Pfad und macht alles kaputt. Ihr seht schon, wieso Gentoo diese Würg-Lösung gewählt hat.
assert(len+100 > len);len ist ein int. Hier sind zwei Beispielprogramme: int.c (signed) und unsignedint.c (unsigned). Nicht zu fassen. Das betrifft konkret den gnupg-Patch. FINSTER. Probiert das mal bei euch aus. Ich habe hier amd64 und x86 und kann das mit gcc 4.1.1 bei beiden nachvollziehen. Sehr gruselig. Was jetzt? Ich werde mal einen Bug bei gcc einreichen, aber ich fürchte ja, daß da wieder irgendein Language Lawyer kommt und mir sagt, daß man das formaljuristisch so auslegen kann in C.
Update: Hier ist der Bug, und wie ihr sehen könnt, findet der gcc-Typ, der an dem Problem Schuld ist (das gibt er in dem anderen Code-Stück zu), daß das in Ordnung ist, wenn Leute geownt werden, weil er eine Optimierung formaljuristisch rechtfertigen kann. Krank. Da fragt man sich ja schon, für was man eigentlich Audits macht, wenn man dann so torpediert wird. Oh, übrigens: mit icc (dem Intel-Compiler) kriegt man korrekt eine Assertion.
Update: Der Kracher: das macht so viel Software kaputt, daß die autoconf-Leute darüber nachdenken, -fwrapv zu den Default-Optimierungen zu tun, was das alte Verhalten wieder anschalten. Way to go, GNU! Macht ja nichts, wenn euer Schweinecompiler anderer Leute Software kaputt macht, solange ihr einen Workaround für eure eigene Software habt!1!!
Update 2: Offenbar optimieren auch gewisse gcc 2.95.* und gcc 3 Versionen (3.4.6 auf MirBSD und 3.4.3 auf Dragonfly BSD) diesen Code weg, aber der offizielle Workaround (-fwrapv) existiert nicht bei diesen gcc-Version. Die Antwort des gcc-Typen, der an dem ganzen Problem Schuld ist (Andrew Pinski) ist: gcc 2 und 3 sind nicht mehr supported und im Übrigen "why should we support older GCC when we can barrely support the current ones".
Update 3: Und Florian Weimer hat schon 2002 gesagt, daß das mal passieren würde. (Danke, Sebastian)
# -fstack-protector breaks usJa, richtig gelesen, Firefox (der Browser, den ihr alle einsetzt), kann nicht mit Stack Protection kompiliert werden, weil die Codebasis zu scheiße ist.
if gcc-version ge 4 1; then
gcc-specs-ssp && append-flags -fno-stack-protector
else
gcc-specs-ssp && append-flags -fno-stack-protector-all
fi
filter-flags -fstack-protector -fstack-protector-all
Daß Firefox nicht baut liegt im Übrigen noch an was anderem. Der Linker heult rum, ich hätte -fPIC nehmen sollen (was ich getan habe), und wenn ich --enable-static --disable-shared sage, baut er trotzdem shared libraries und heult wegen -fPIC an.
Update: Hat sich geklärt, wieso der nicht gebaut hat. gcc 4.1.1 (die aktuelle Release-Version mit dem höchsten Versionsstand) hat ein Symbol Hiding Feature; das ist offenbar kaputt. Diverse Distros haben ihren gcc mit der funktionierenden Version aus dem CVS hochgepatcht. Ich nicht. Das configure von Firefox hat einen Check, der das erkennen will, aber nicht funktioniert. Wenn ich config.cache manuell editiere, damit er glaubt, gcc sei kaputt, dann baut Firefox plötzlich. Heißt aber auch nicht mehr Firefox, sondern "Bon Echo". WTF?!