|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Der "Neustart" bei Netcup um die Lücke zu stopfen dauert jetzt schon 2 h, thx Obama.
|
|
|
|
|
|
|
|
|
|
|
|
Mein X1 Carbon ist zu 99,9% lautlos, leicht, stabil und hat alle wichtigen Anschlüsse. Kostet halt.
|
|
|
|
|
|
|
|
|
|
|
Die Diskussion ist halt auch völlig sinnlos. "Spielt für mich keine Rolle" - "DOCH IST WICHTIG".
Jo, kann man so halt ad absurdum immer weiter hin und her pfeffern.
|
|
|
|
|
|
|
|
|
|
|
Hier kann keiner etwas dafür, dass du dir Schlepptop geben hast lassen.
Das trifft als Variante 1 "Bounds Check Bypass" (klassische if/else Optimierung). Was meint ihr, wie viel Performance das hier kostet? Ich habe (noch) keinen Ryzen. In der Theorie erwarte ich einen starken Einbruch.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 06.01.2018 12:06]
|
|
|
|
|
|
|
|
|
Nein, bitte genau lesen. Bei den Branch Predictor Kram geht es NUR um indirekte Sprünge. D.h. es geht hier z.B. darum, dass der Prozessor Funktionsaufrufe durch vtables oder Pointer spekulativ ausführen kann. Diese Patches deaktivieren NICHT die Sprungvorhersage im Allgemeinen.
Vgl. auch https://reviews.llvm.org/D41723
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 06.01.2018 12:08]
|
|
|
|
|
|
|
|
|
Habe ich ja nicht, bin mit meinem T450s total zufrieden.
Könnte trotzdem gerne ein Kilo leichter sein.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Nein, bitte genau lesen. Bei den Branch Predictor Kram geht es NUR um indirekte Sprünge. D.h. es geht hier z.B. darum, dass der Prozessor Funktionsaufrufe durch vtables oder Pointer spekulativ ausführen kann. Diese Patches deaktivieren NICHT die Sprungvorhersage im Allgemeinen.
Vgl. auch https://reviews.llvm.org/D41723
| |
Ich hoffe es. Das müsste sonst in vielen Anwendungsfällen (vorsortieres Array, wie im Beispiel bei Stackoverflow und dazu noch realistisch) heftig durchschlagen. Sie druecken sie sich eben nicht klar aus:
Das ist unklar. Variante 1 und eben auch Variante 2 sind beide "branch prediction". Wohl aber andere Anwendungs und Implementierungsgebiete, gerade weil AMD ja behauptet von Variante 2 nicht betroffen zu sein. Hier wird ja quasi ein Buffer der letzten Sprünge geführt und AMD sagt, bei uns funktioniert das anders. Wenn es anders ist, warum dann abschalten?
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 06.01.2018 12:38]
|
|
|
|
|
|
|
|
|
List: openbsd-misc
Subject: Meltdown, aka "Dear Intel, you suck"
From: Philip Guenther <guenther () gmail ! com>
Date: 2018-01-06 8:31:01
Message-ID: CAKKmsNj1nSNm0urypaz3m7Tg_4edxD=N7fD6icnjAizJdHK0DA () mail ! gmail ! com
[Download message RAW]
So, yes, we the OpenBSD developers are not totally asleep and a handful of
us are working out how to deal with Intel's fuck-up aka the Meltdown
attack. While we have the advantage of less complexity in this area (e.g.,
no 32bit-on-64bit compat), there's still a pile of details to work through
about what has to be *always* in the page tables vs what can/should/must be
hidden.
Do KARL or other features of OpenBSD mitigate this? Not particularly. If
you're running code from multiple trust domains then yeah, you're largely
at risk.
We have received *no* non-public information. I've seen posts elsewhere by
other *BSD people implying that they receive little or no prior warning, so
I have no reason to believe this was specific to OpenBSD and/or our
philosophy. Personally, I do find it....amusing? that public announcements
were moved up after the issue was deduced from development discussions and
commits to a different open source OS project. Aren't we all glad that
this was under embargo and strongly believe in the future value of
embargoes?
Unless something unexpected happens, we'll be applying the workaround to
amd64 first and then working out what to do for i386 and arm* (if still
though to be necessary for arm) after that. No promises on only applying
it to Intel CPUs or knobs to disable it, yet: we'll see how complex that
would make things. As always, our own developer laptops are the first
targets, so we're invested in it working and being usable.
Philip Guenther
guenther@openbsd.org
|
|
|
|
|
|
|
|
|
|
|
Bei uns hat das übrigens tatsächlich einen meltdown zur Folge. Ich meine, ich könnte jetzt auf dem hohen Pferd sitzen und sagen: hat man davon wenn man AWS Kunde ist. Aber das würde auch unser Inhouse-hosting betreffen (tut es auch). Schon nichtmal ganz so nice, muss man sagen.
¤: Und ein besonderes Geheimnis dürfte es nicht sein, dass wir wahrscheinlich einer der grössten AWS Kunden sind. Es ist also tatsächlich nicht so wahnsinnig cool.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 06.01.2018 12:57]
|
|
|
|
|
|
|
|
|
Habe gerade Retpoline (begreift man auch ohne Assemblerwissen, RSP muss man halt nachschlagen) durchgelesen, ich konnte mir ein kurz Lachen nicht verkneifen. Nicht wegen dem Namen, wegen der Implementierung.
@csde_rats:
Wie funktioniert das bei Responsible Disclosure, wer bekommt den die Info. Ein System gibt es dafür nicht? Entweder man gehört zu den coolen Kindern auf dem Schulfhof und ist auf der Mailingliste oder nicht, oder? Oder ist das jetzt schon eine kleine Rache wegen Theos Unzuverlässigkeit bei KRACK? Die sind da ja seit Sommer dran, also vor KRACK. Aber panisch sind alle beteiligten ja wohl erst im Dezember geworden?
Zumindest der Mensch hinter KRACK hat ja süffisant angedeutet, das OpenBSD bei ihm unten durch ist.
@Swiss:
Hier wir das ähnlich werden am Montag, Kein AWS bei uns, aber ein riesiges VMWare mit Eigen- und Fremdnutzung. Und ich bin sowieso kein Freund dieser "Sparmaßnahme" die wie immer Nachteile hat. Dedizierte Hardwaer und keine Internetverbindung oder man hat wenig Kontrolle.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 06.01.2018 15:00]
|
|
|
|
|
|
|
|
|
|
dedizierte Hardware hat ihre eigenen Schwächen. Strom, Wartung, Lizenzen, Kühlung, Platz, Anschaffung an sich. Dazu noch deutlich höhere Komplexität bei HA-Anforderungen oder Recoveries. Nö, VM all the way. Seit wir VMware haben ist unser kleines RZ deutlich effizienter und einfacher zu managen. Wenn da jetzt mal ein kleiner Dämpfer ein bisschen negativen Einfluss hat, macht das die Vorteile noch nicht mal im Ansatz wett.
|
|
|
|
|
|
|
|
|
|
|
hoschi: Unabhängig davon, wie man da Disclosure handhaben möchte, ein Bug, der X-Milliarden CPUs von potentiell dutzenden Herstellern betrifft und Patches in jedem Betriebssystem benötigt ... da greifen einfache "Regeln" nicht mehr.
War's bei KRACK nicht so, dass OpenBSD gefragt hat, ob sie vorher patchen dürfen, sie die Erlaubnis bekommen haben, und sich dann der Typ hinterher darüber aufgeregt hat, dass er das erlaubt hat?
-
http://kroah.com/log/blog/2018/01/06/meltdown-status/
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
dedizierte Hardware hat ihre eigenen Schwächen. Strom, Wartung, Lizenzen, Kühlung, Platz, Anschaffung an sich. Dazu noch deutlich höhere Komplexität bei HA-Anforderungen oder Recoveries. Nö, VM all the way. Seit wir VMware haben ist unser kleines RZ deutlich effizienter und einfacher zu managen. Wenn da jetzt mal ein kleiner Dämpfer ein bisschen negativen Einfluss hat, macht das die Vorteile noch nicht mal im Ansatz wett.
| |
Ist mir alles klar. Die Nachteile sind eben auch da, wenn du unzaehlige Server auf eine VMWare packst (es geht ja darum Geld zu sparen...) hast du auch einen Single-Point-Of-Failure. Ich bitte die Admins seit einem gewissen Erlebnis meine Server wenigstens auf alle VMWare-Instanzen zu verteilen, damit ein Einschlag nicht alles zum Einsturz bringt.
Letzthin wieder Spass gehabt, kurz vor der Weihnachtsfeier, irgend ein RAID-Controller ist verstorben und VMWare hat einen Fallback automatisch verwendet (gut!) - nur war der leider viel langsamer und niemand hat es bemerkt, bis die Datenbank dann feierlich mit Timeouts ausgetickt ist 
Ich bin halt auch ein Systemintegrator und habe nie Turnschuhadmin spielen muessen, damit laesst sich leicht reden.
Wenn den Spiel von EPIC jetzt ruckelt, bitte weitergehen. Jetzt duerfen die Programmier bei denen wohl demnaechst versuchen irgendwie SYSCALLs einzusparen, die werden sich bedanken.
Bin ich der einzige, dessen Bauchgefühl einem sagt, dass die eBPF-Entwickler nichts verbrochen haben, man aber nochmal über alles nachdenken sollte? Die haben da etwas unglaublich mächtiges und auch tolles eingebaut. Und das lässt sich wunderbar missbrauchen.
Und das sich JavaScript so verbreitet hat und Browser das zur Laufzeit interpretieren - mit hochgerüsteten Interpretern - fällt jetzt allen auf die Füße. Und daran erinnert mich eBPF gerade, auch wenn ich das nicht schlecht machen kann und will. Traxer 
| | Zitat von csde_rats
War's bei KRACK nicht so, dass OpenBSD gefragt hat, ob sie vorher patchen dürfen, sie die Erlaubnis bekommen haben, und sich dann der Typ hinterher darüber aufgeregt hat, dass er das erlaubt hat?
| |
Nachgelesen, genau so war es. Der Krackmensch wird OpenBSD in Zukunft verspätet informieren, weil er sich darüber hinterher geärgert hat Theo das zu erlauben. Theo trifft keine Schuld. Unabhängig davon sehe ich das genauso wie du, dafür gibt es einfach kein Handbuch.
| |
As for how this was all handled by the companies involved, well this could be described as a textbook example of how NOT to interact with the Linux kernel community properly. The people and companies involved know what happened, and I’m sure it will all come out eventually, but right now we need to focus on fixing the issues involved, and not pointing blame, no matter how much we want to. | |
Oh. Bei der Anzahl an beteiligten Leute (und speziell Google) wunder mich das jetzt aber schon.
|
|
[Dieser Beitrag wurde 7 mal editiert; zum letzten Mal von hoschi am 06.01.2018 19:32]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Ist mir alles klar. Die Nachteile sind eben auch da, wenn du unzaehlige Server auf eine VMWare packst (es geht ja darum Geld zu sparen...) hast du auch einen Single-Point-Of-Failure. Ich bitte die Admins seit einem gewissen Erlebnis meine Server wenigstens auf alle VMWare-Instanzen zu verteilen, damit ein Einschlag nicht alles zum Einsturz bringt.
Letzthin wieder Spass gehabt, kurz vor der Weihnachtsfeier, irgend ein RAID-Controller ist verstorben und VMWare hat einen Fallback automatisch verwendet (gut!) - nur war der leider viel langsamer und niemand hat es bemerkt, bis die Datenbank dann feierlich mit Timeouts ausgetickt ist
Ich bin halt auch ein Systemintegrator und habe nie Turnschuhadmin spielen muessen, damit laesst sich leicht reden.
Die Ruckler kommen nicht von uns, bitte weitergehen. Jetzt duerfen die Programmier bei denen wohl demnaechst versuchen irgendwie SYSCALLs einzusparen, die werden sich bedanken.
| |
VMware hat ja grad den Vorteil, HA übergreifend über einen Cluster zu bieten, ohne den ganzen OS-spezifischen Dreck anpacken zu müssen. Wer sich nen einzelnen ESXi in den Serverraum stellt, hat 3/4 der Vorteile moderner Virtualisierungssysteme verloren. Für kritische Systeme kann man ja auch noch Fault Tolerance nutzen, da wird selbst ein Server-Ausfall unterbrechungsfrei abgefangen.
Bei uns hat Virtualisierung für eine deutlich bessere Trennung von Systemen gesorgt. Wir hatten früher halt ein paar Hardware-Server, da liefen teilweise 3-4 Dienste (oder auch mal mehr) drauf. Muss man für Dienst 1 mal den Server neustarten, sind Dienst 2-4 auch weg. Von Problemen mit Bibliotheksabhängigkeiten fangen wir gar nicht an. Dazu höhere Sicherheit, weil ich Serverdienste isolieren kann. Neue Server sind auch schnell aufgesetzt. Lizenzen sind auch recht einfach zu managen. Einfach entsprechende Datacenter-Lizenzen kaufen und soviele Server ausrollen wie man möchte. Unsere 4 Server lassen grad so grob 50 VMs laufen, und CPU-Leistung ist nicht mal im Ansatz ein Problem. Arbeitsspeicher schon eher, da mussten wir vor einiger Zeit auf 1.5 TB aufrüsten, effektive Belastung liegt grad so bei 600-700 GB. Storage dahinter ist auch was performanteres als man sich in einem einzelnen Server leisten würde, mehrere TB SSDs und im 2nd Tier 10k-Disks, über 10 GBe iSCSI angebunden. Ohne Virtualisierung hätte man in der Hälfte der Server immer noch irgendwelche rummeligen 7.2k-Near Line SAS-Platten, weil Budget und so.
Das erkaufe ich mir natürlich mit der theoretisch angreifbaren VM-Plattform, aber selbst die ist unproblematischer zu patchen als die Gastbetriebssysteme. VMs umziehen, patchen, nächster Server. Man muss manche Hardwareverfechter-Admins glaub ich mal in so ein VM-loses RZ schicken und die da Updates installieren lassen. So mit Bios-Updates und so, weil muss ja auch mal sein. Wenn der dann zwei Wochen nichts anderes gemacht hat als Server für Server zu patchen baut der nach der Rückkehr als erstes einen Altar für seine neuen Götter aus Palo Alto.
|
|
|
|
|
|
|
|
|
|
|
Kann ich dir meine VMs geben, sind so vierunfünfzig Stück insgesamt. RAM und CPU haben wir genügend, aber Festspeicher scheint grundsätzlich ein Problem zu sein. Wir bekommen immer sehr wenig und sollen für Festspeichererweiterungen ordentlich zahlen.
Die haben uns zu Beginn 16 Kerne und 16 GB RAM (jetzt 32 GB oder mehr) und dann lächerliche 100 GB Festspeicher (250 GB oder mehr) gegeben. Der Festspeicher hat halt hinten und vorne nicht gereicht, sobald die Anwender mal losgelegt haben.
Die Anwendungen sind halt auch das Problem, wenn man wirklich wollen würde, wäre unsere Ansprüche viel niedriger. Aber Hardware ist billiger als Entwickler, viel billiger.
PS: Ich werde mir aber nicht mehr so schnell einen Snapshot vom laufenden System machen lassen. Habe mir das wie ein Journal vorgstellt, aber dass war sooooo viel langsamer. Praktisch, wenn man was dummes vorhat, aber bei hohen Anspruch an I/O geht das nicht.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 06.01.2018 19:39]
|
|
|
|
|
|
|
|
|
Plattenplatz in VM-Umgebungen ist auch so ne nicht ganz so unkomplizierte Sache, wenn man on a budget arbeitet. Wir hatten früher Lefthand (HP P4000). Das erweitert man, indem man einen weiteren Node dazukauft. Wenn man Daten räumlich getrennt gespiegelt haben möchte, jeweils 2 Nodes. So ein Node kostet so 25.000 ¤, da ist jede Aufrüstung ein kleiner Investitionskampf. Andere Systeme lizensieren teilweise nach Speicherplatz, was beim Aufrüsten auch immer wieder zu lustigen Überraschungen in Angeboten führt. Sind doch nur 2 TB, wofür wollen die jetzt 20.000 ¤?
Wir sind auf Dell Compellent umgestiegen, das lizensiert nach Anzahl der verbauten Platten. Im Endeffekt wird unsere Lizenz mit 48 Platten (oder so, wir haben aktuell so 30 drin) wohl ewig reichen, weil Platten ja auch nicht kleiner werden.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
| |
As for how this was all handled by the companies involved, well this could be described as a textbook example of how NOT to interact with the Linux kernel community properly. The people and companies involved know what happened, and I’m sure it will all come out eventually, but right now we need to focus on fixing the issues involved, and not pointing blame, no matter how much we want to. | |
Oh. Bei der Anzahl an beteiligten Leute (und speziell Google) wunder mich das jetzt aber schon.
| |
Da er sich später ja ausdrücklich bei den Devs bedankt, scheint mir das Richtung Management der involvierten Firmen zu gehen. Das klingt in meinen Ohren so ein bisschen in die Richtung von "Ihr Spackos wusstet seit Juni davon und plant das dann so, dass ihr uns alle Weihnachten ruiniert?! Wer hat euch denn ins Hirn gekackt?"
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 06.01.2018 20:00]
|
|
|
|
|
|
|
|
|
Und ich kann es voll nachvollziehen, mit ist so mein Urlaub vor Weihnachten versaut worden. Anruf um 16:00 Uhr am Freitag, Ende um 02:00 Uhr am Samstag. Aber das war keine Entscheidung der Kollegen, es war einfach Mist.
| | Zitat von GarlandGreene
...
| |
Danke für den Einblick 
|
|
|
|
|
|
|
|
|
|
|
Das X280 hat einen Kartenslot, einen MicroSD-Kartenslot. Ich vermute, dass dieser möglichst unpraktisch auf der Geräterückseite untergebracht wurde, zumindest ist da eine kleine Abdeckung. Aber das sieht nach SIM aus 
Und SD-Karten kann das Gerät damit trotzdem nicht lesen, es gibt MicroSD auf SD-Adapter (meist nachgeworfen beim Kauf), umgekehrt ist das physikalisch nicht möglich.
Scheint wohl Computerbase und Heise entgangnen zu sein, Notebookcheck erwähnt das.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 07.01.2018 1:23]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Die haben uns zu Beginn 16 Kerne und 16 GB RAM (jetzt 32 GB oder mehr) und dann lächerliche 100 GB Festspeicher (250 GB oder mehr) | |
sorry aber:wie bitte?
da scheint das problem bei euch echt anderweitig zu liegen.
ich hab schon für unsern studiverein vor fünf jahren server geschenkt(!) bekommen die soviel cpu und ram hatten. und bei dem plattenplatz frag ich mich echt woher die noch so kleine platten überhaupt herbekommen?
kann man schon machen als firma sowas, dann aber schön die kosten aufführen die entstehen weil man jetzt "sparmasnahme x und y umschiffen muss".
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von RichterSkala
omg, wie scheiße sind denn die Dokumentationen von gstreamer? m(
| |
jo leider teilweise sehr unhilfreich.
als $firma kommt man oft nicht drumrum collabora oder wie sie auch grade heissen gld in rachen zu werfen (was ich grundsätzlich ne gute sache find, die leute haben da auch ahnung).
ansonstne kommt man mit beispielen bzw anderen plugins wenn man die sich anschaut ziemlich weit.
generell machts dann doch sehr spass, hab mal ne eigene sink dafür programmiert, das fand ich zum schluss schon nicht so unsexy.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
¤: Und ein besonderes Geheimnis dürfte es nicht sein, dass wir wahrscheinlich einer der grössten AWS Kunden sind. Es ist also tatsächlich nicht so wahnsinnig cool.
| |
also für mich wars ein geheimnis bis jetzt  wer seid denn ihr?
und wenn ihr so ein riesen kunde seid, lohnt sichs ab ner gewissen grösse nicht doch wieder alles selbst zu machen? so einfach vong zuverlässigkeit her, dass man mehr unter kontrolle hat und letzendlich auch kosten?
auch das von mir aus über mehrere colocation rechenzentren zu streuen usw wenn man die infrastruktur nicht selbst betreiben möchte?
denk mir halt dass sich sowas wie AWS nur für kleine bis wirklich mittlere sachen wirklich lohnt oder bin ich da mit der vorstellung so auf dem holzweg?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
| | Zitat von hoschi
Die haben uns zu Beginn 16 Kerne und 16 GB RAM (jetzt 32 GB oder mehr) und dann lächerliche 100 GB Festspeicher (250 GB oder mehr) | |
sorry aber:wie bitte?
da scheint das problem bei euch echt anderweitig zu liegen.
ich hab schon für unsern studiverein vor fünf jahren server geschenkt(!) bekommen die soviel cpu und ram hatten. und bei dem plattenplatz frag ich mich echt woher die noch so kleine platten überhaupt herbekommen?
kann man schon machen als firma sowas, dann aber schön die kosten aufführen die entstehen weil man jetzt "sparmasnahme x und y umschiffen muss".
| |
Der Festspeicher kommt von einem zentralen System wie Garland beschrieben hat und ich vermute das Problem mit der Lizenzierung von Festspeicher hat man nicht gelöst. Dass die Firma in eine Firmengruppe aufgeteilt ist um irgendwie Steuern zu sparen (Profitcenter blabla) hilft sicher nicht. Ich denke wir wären so viel besser, schneller und flexibler - wenn alle in genau einem Schiff sitzen würden, nicht einzelnen Booten.
Ich denke ähnlich bezüglich selber machen. Aber sogar Netflix ist bei Amazon! Haben die wirklich die Risiken betrachtet? Der größte Konkurrent hat die Server von Netflix unter Kontrolle. Andererseits nutze auch ich mein FireTV nur für Netflix, aber davon hängt auch nicht meine Firma ab. Wichtiges Detail, Netflix hat ein komplettes eigenes CDN und macht damit die Schwerstarbeit, aber ohne Amazon dürfte der Login nicht möglich sein.
Die Frage an Swiss wäre also, ob dass mit AWS trotz der größe nur ein Nebenschauplatz ist? Vielleicht gibt es historisch auch kein eigenes RZ und damit entsprechendes Personal?
Exkurs:
Für Amazon - war bisher - der Verstanddienstleister auch nur ein Nebenschauplatz, ändert sich gerade wohl. Amazon hat eigene Frachtflugzeug geleast. Mir würde das bei FedEx oder DHL richtig große Sorgen machen.
Ich mag ja Outsourcing wie es praktiziert wird nicht, aber man kann das durchaus sinnvoll verwenden. Wer sein Kerngeschäft immer selbst macht und Nebengeschäfte je nach Situation und Lage auslagert, kann im Krisenfall womöglich Nebengeschäfte wieder herein holen und die Arbeitsplätze sichern. Geht freilich nicht mit allem, aber manchem. Sehr weit weg vom Thema...
|
|
[Dieser Beitrag wurde 9 mal editiert; zum letzten Mal von hoschi am 07.01.2018 11:19]
|
|
|
|
|
|
|
|
|
AWS ist für Amazon die Cash Cow. Die werden einen Teufel tun und einen ihrer prominentesten Kunden irgendwie behindern.
Für uns steht Cloudrummel auch irgendwann an. Aber vorher will ich redundantes Gbit-Internet haben.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
AWS ist für Amazon die Cash Cow. Die werden einen Teufel tun und einen ihrer prominentesten Kunden irgendwie behindern.
| |
das wollte ich damit garnicht unterstellen, das glaub ich auch im geringsten nicht. ich stell nur in frage "ob sich das ab ner ewissen grösse auch noch lohnt".
wie gesagt, ohne selbst zu wissen ob ich da jetzt sowas von falsch lieg, jemand wie netflix wird ja nicht die offizielle preisliste gezeigt bekommen.
|
|
|
|
|
|
|
|
|
|
|
Das habe ja auch als eine rein theoretische Möglichkeit in den Raum gestellt, denke da immer Paranoid nach "Sag niemals nie...". In der Situation wird Amazon Netflix nicht anpinkeln. Amazon und Google haben allerdings gezeigt, dass ein gegenseitiger Angriff jederzeit in Frage kommt (YouTube-App auf FireTV und die plötzliche Einführung von Firefox) und beide nicht damit rechnen das Kartellbehörden überhaupt noch einschreiten. Amazon hatte auch kein Problem "1984" per Remote vom Kindle zu löschen, als das praktisch erschien. Realistischer wäre schon eher, das Amazon den Dienst ordentlich betreibt, wenn ihnen Netflix aber in die Quere kommt - wird der Vertrag möglichst kurzfristig einseitig gekündigt.
Die Kartellbehörden, speziell in den USA, sind seit Bush praktisch komplett untätig. Letzte Zuckungen gegen Microsoft und die waren komplett wirkungslos. Bei Apple vs. Google auf dem iPhone war die Kartellaufsicht still und sogar hier in Deutschland bei T-Entertain, was ja per se die Kartellbehörde alarmieren hätte müssen. Du kannst halt nicht neutraler Netzbetreiber und Contentanbieter gleichzeitig sein, und deshalb müssen wir jetzt über Netzneutralität reden. Ist ein oberflächlicher Artikel in der Süddeutschen dazu am Freitag erschienen.
Nicht das jetzt alles gut war, was die Kartellbehörden getan haben. Stellt euch vor AT&T wäre nicht zerschlagen worden, dann wäre UNIX frei geblieben (bedingt durch die weiterhin geltenden Kartellauflagen) und es gäbe vielleicht quellgeschlossene Software in der Form nicht. AT&T gibt es heute wieder als ein großes Unternehmen, komplett Nullnummer mit maximalen Schaden. Ab hier ganz viel Fantasie einfügen...
Offizielle Preislisten sind wirklich nur etwas für Privatkunden. Ich frage mich ja, warum Boeing oder Airbus dafür überhaupt Papier verschwenden.
|
|
[Dieser Beitrag wurde 6 mal editiert; zum letzten Mal von hoschi am 07.01.2018 14:07]
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
| | Zitat von GarlandGreene
AWS ist für Amazon die Cash Cow. Die werden einen Teufel tun und einen ihrer prominentesten Kunden irgendwie behindern.
| |
das wollte ich damit garnicht unterstellen, das glaub ich auch im geringsten nicht. ich stell nur in frage "ob sich das ab ner ewissen grösse auch noch lohnt".
wie gesagt, ohne selbst zu wissen ob ich da jetzt sowas von falsch lieg, jemand wie netflix wird ja nicht die offizielle preisliste gezeigt bekommen.
| |
ist halt ne ziemliche Aufgabe, so eine Infrastruktur auf die Beine zu stellen. Netflix will sich vermutlich nicht so sehr engagieren. Gäbs kein Amazon und Azure würde sich Netflix das vielleicht überlegen.
|
|
|
|
|
|
|
|
|
|
|
Der openbsd-misc Banter-Thread zu Meltdown ist PURES Massivgold.
https://marc.info/?t=151498459200002&r=1&w=2
| |
On 01/06/18 10:27, Otto Moerbeek wrote:
> On Sat, Jan 06, 2018 at 10:22:25AM -0800, Jordan Geoghegan wrote:
>
>> All my web-facing servers are running SPARC and/or for a couple smaller
>> projects, PowerPC. People thought I was a loon when I vehemently insisted on
>> SPARC over the years, and called me crazy when I hosted my personal web
>> projects on PowerPC. x86 is a disease.
>>
>> A little bit extra in electricity costs, and a whole lot extra when it comes
>> to peace of mind - niche architectures ftw!
> Sparc64 and powerpc also have speculative execution, branch
> prediction and extensive caches. It is much wiser to assume they are
> also affected by (similar) bugs/explots or whatever you call it.
>
> That said, they are indeed nicer than the Intel stuff that can hardly
> be called an architecture.
>
> -Otto
Fair enough, any idea if this could effect MIPS {32 64}? That's my next
most commonly deployed arch. I do assume that there will likely be some
issues on other arches, but from what I see, folks are still doing
pensive beard stroking trying to determine if AMD chips are susceptible.
SPARC is tight like a tiger as Goldmember would say, and I would be
wholeheartedly shocked to find it was vulnerable to the same degree as x86. | |
| |
Ted Unangst wrote:
> Otto Moerbeek wrote:
> > Sparc64 and powerpc also have speculative execution, branch
> > prediction and extensive caches. It is much wiser to assume they are
> > also affected by (similar) bugs/explots or whatever you call it.
>
> A lot of the commonly available sparc64 gear, T2 and USIII, are in order.
So that's not exactly right, since branch prediction and speculative exection
are somewhat orthogonal to out of order execution. I'm assuming they are
somewhat less affected because without all the fun out of order machinery the
CPU won't go nearly so far down the branch.
Specifically regarding meltdown, sparc64 doesn't map the kernel in userland,
right?
Regarding spectre, the bounds check bypass requires executing past two
branches. Can a sparc do that? | |
| | > Ted Unangst wrote:
> > Otto Moerbeek wrote:
> > > Sparc64 and powerpc also have speculative execution, branch
> > > prediction and extensive caches. It is much wiser to assume they are
> > > also affected by (similar) bugs/explots or whatever you call it.
> >
> > A lot of the commonly available sparc64 gear, T2 and USIII, are in order.
>
> So that's not exactly right, since branch prediction and speculative exection
> are somewhat orthogonal to out of order execution. I'm assuming they are
> somewhat less affected because without all the fun out of order machinery the
> CPU won't go nearly so far down the branch.
>
> Specifically regarding meltdown, sparc64 doesn't map the kernel in userland,
> right?
sun4u have a split U vs S I/Dtlbs. Those TLB are software-updated.
I'm not entirely sure of the sun4v situation.
> Regarding spectre, the bounds check bypass requires executing past two
> branches. Can a sparc do that?
doubt it. Note since the tlb are software-updated if a branch
prefetched an unmapped page and that page translation didn't exist,
we'd have seen seen spurious speculative faults in the past, because
our software-update codepath isn't a willing party to such an
emmisions scandal. | |
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
|
