1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Container: Docker hat offenbar…

Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: NeoChronos 02.10.19 - 13:49

    Wenn die Registry offline geht bei einer Pleite

  2. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: uschatko 02.10.19 - 14:04

    Wenn man es im Unternehmen einsetzt sollte auch eine lokale Registry vorhanden sein. Sonst ist das nur üble Frickelei.

  3. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: eechauch 02.10.19 - 14:22

    Wen interessiert denn im professionellen Umfeld die offizielle Registry? Das ist ja genau das Probem von Docker Inc, dass niemand ihre Services wie Docker Hub für den professionellen Einsatz nutzt, sondern es lieber selbst macht. Da seh ich jetzt kein wirkliches Risiko.

  4. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: 1e3ste4 02.10.19 - 14:37

    uschatko schrieb:
    --------------------------------------------------------------------------------
    > Wenn man es im Unternehmen einsetzt sollte auch eine lokale Registry
    > vorhanden sein. Sonst ist das nur üble Frickelei.

    Niemand baut in einem Unternehmen baut das Basis-Image mit der Linux-Distri selbst. Die allermeisten Distris haben ihre offiziellen Docker-Images auf dem Docker Hub.

    Selbst ein Basisimage zu bauen ist die wahre Frickelei.

  5. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: Schattenwerk 02.10.19 - 15:15

    Oh, du meinst also jede professionelle Einsatz hostet und aktualisiert sämtliche Images von benötigten OS lokal? :)

  6. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: Tuxraxer007 02.10.19 - 15:25

    eechauch schrieb:
    --------------------------------------------------------------------------------
    > Wen interessiert denn im professionellen Umfeld die offizielle Registry?
    Ich war kürzlich noch auf eine CI/CD Veranstaltung und man hört auch vielen Unternehmen das selbe, die setzen vermehrt auf RedHat OpenShift ( wir bei uns auch ) und RedHat hat sich gerade mit der aktuellen OpenShift Release von Docker losgelöst und geht andere Wege.
    Es gab zw. Docker und Redhat wohl einige Probleme in der Zusammenarbeit.



    1 mal bearbeitet, zuletzt am 02.10.19 15:26 durch Tuxraxer007.

  7. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: 1e3ste4 02.10.19 - 15:34

    Tuxraxer007 schrieb:
    --------------------------------------------------------------------------------
    > Ich war kürzlich noch auf eine CI/CD Veranstaltung und man hört auch vielen
    > Unternehmen das selbe, die setzen vermehrt auf RedHat OpenShift

    Diese CI/CD-Veranstaltung war nicht zufällig von Red Hat gesponsort?

  8. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: eisbart 02.10.19 - 16:14

    Tuxraxer007 schrieb:
    --------------------------------------------------------------------------------
    > Es gab zw. Docker und Redhat wohl einige Probleme in der Zusammenarbeit.

    Ja, bei Docker laufen ein paar Type rum, die kein systemd und SELinux mögen und deswegen interop pull requests ohne Kommentar schließen. Abgesehen davon implementiert Docker eine eigene Art init System in schlecht.



    1 mal bearbeitet, zuletzt am 02.10.19 16:14 durch eisbart.

  9. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: divStar 02.10.19 - 16:16

    Es wird unternehmensweit festgelegt was für Images vorgehalten werden müssen und dann wird das lokale Artifactory oder Nexus bemüht. Fertig.

  10. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: uschatko 02.10.19 - 18:00

    Schattenwerk schrieb:
    --------------------------------------------------------------------------------
    > Oh, du meinst also jede professionelle Einsatz hostet und aktualisiert
    > sämtliche Images von benötigten OS lokal? :)

    In dem Laden möchte ich nicht tätig sein, Ein Alptraum jedes sicherheitsbewussten Admins wenn jeder seine Dockerimages von sonstwo holt.

  11. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: 1e3ste4 02.10.19 - 18:17

    divStar schrieb:
    --------------------------------------------------------------------------------
    > Es wird unternehmensweit festgelegt was für Images vorgehalten werden
    > müssen und dann wird das lokale Artifactory oder Nexus bemüht. Fertig.

    Und von wo holt sich das lokale Artifactory die Basis-Images, Einstein?

  12. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: SchrubbelDrubbel 02.10.19 - 18:24

    uschatko schrieb:
    --------------------------------------------------------------------------------

    > In dem Laden möchte ich nicht tätig sein, Ein Alptraum jedes
    > sicherheitsbewussten Admins wenn jeder seine Dockerimages von sonstwo holt.

    Wie gut, wenn man selbst der Admin ist; ich habs verboten :-D

  13. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: GodsBoss 02.10.19 - 18:28

    > > Wenn man es im Unternehmen einsetzt sollte auch eine lokale Registry
    > > vorhanden sein. Sonst ist das nur üble Frickelei.
    >
    > Niemand baut in einem Unternehmen baut das Basis-Image mit der Linux-Distri
    > selbst. Die allermeisten Distris haben ihre offiziellen Docker-Images auf
    > dem Docker Hub.
    >
    > Selbst ein Basisimage zu bauen ist die wahre Frickelei.

    Was hat dein Beitrag mit seinem Beitrag zu tun? Er schrieb von einer lokalen Registry, in die man natürlich auch Third-Party-Docker-Images (damit meine ich alle, die nicht von einem selbst stammen) packen kann und sollte. So machen wir es. Du schreibst davon, Images zu erzeugen.

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  14. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: ibsi 02.10.19 - 18:30

    Deshalb greift man im Regelfall nur auf die images zu, die von den original Autoren / Firmen sind, und nicht welche von Hinz und Kunz

  15. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: Hawk321 02.10.19 - 21:30

    ibsi schrieb:
    --------------------------------------------------------------------------------
    > Deshalb greift man im Regelfall nur auf die images zu, die von den original
    > Autoren / Firmen sind, und nicht welche von Hinz und Kunz

    Selbst das nur in begrenzter Weise....da es viele "offizielle" Images gibt, die 0 Support haben !
    Images, baut ein seriöser Admin selbst auf Basis von den offiziellen. Die Firmen schreiben allesamt selbst, das nur "default values" genutzt werden.

    Diese Images kommen dann in die eigene Registry. Gerade Docker Hub bietet so irre viel Schund an...ich nutze es nur als Gedankenstütze.

    Schlimm wird es, wenn die GF meint das nun die Entwickler den Kram selbst erstellen sollen...die allerdings keine Ahnung von Linux und Bash haben. Die ganze Magic geschieht zum
    größten Teil in den Entry Skripten und das sind nun mal BASH Skripte ...und BASH zwingt seriöses Linux Wissen voraus. Wenn Entwickler dann da rumbasteln müssen, kommt nur ein alte Shell Syntax, Copy&Paste von Stackoverflow Murks bei raus.
    Container, sind Linux Server in klein und aufgesetzt wie vor 15 Jahren mit Skripten !

    Das sollte auch in der Hand von fähigen Admins bleiben. Später, wenn der Container dann läuft und auch den Sec Scan der CI Pipeline besteht, DANN kann der Entwickler kleinere Anpassungen seiner Anwendung im Dockerfile vornehmen und das Jenkins übergeben (oder wen auch immer). Den DANN braucht man nur die Container starten, stoppen und killen.

    Doch auch hier sind die "Entscheider" schon auf den Gummizellenkurs und wollen Datenbanken, Webserver und Co vom Entwickler konfigurieren lassen...mit dem Ziel KEINE Admins mehr zu haben.

    Alles erlebt...x mal..."GF und Entscheider"....und ich vermute, das wird noch so richtig krachen. Den man lässt keine Pfuscher an sowas dran und erst recht niemanden, der sich weigert sich da ERNSTHAFT einzuarbeiten.



    1 mal bearbeitet, zuletzt am 02.10.19 21:30 durch Hawk321.

  16. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: Schnarchnase 02.10.19 - 23:17

    1e3ste4 schrieb:
    --------------------------------------------------------------------------------
    > Selbst ein Basisimage zu bauen ist die wahre Frickelei.

    Das ist Quatsch und vor allem auf Basis von Alpine-Linux oder Debian (Slim) relativ zügig erledigt. Viele offizielle Images waren bzw. sind explizit nicht für den Produktiveinsatz ausgelegt. Es ist mir schleierhaft, warum so viele scheinbar der Meinung sind es wäre sinnvoll darauf zu setzen.

  17. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: Schnarchnase 02.10.19 - 23:19

    1e3ste4 schrieb:
    --------------------------------------------------------------------------------
    > Und von wo holt sich das lokale Artifactory die Basis-Images, Einstein?

    Die kann man z.B. auch von Gitlab automatisch bauen lassen. Möglichkeiten gibt es da viele und das ist auch kein Hexenwerk (vielleicht ist das auch das Problem von Docker, die Alternativen sind so schön einfach, dass sich schwierig Geld verdienen lässt).

  18. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: peddy_hh 02.10.19 - 23:42

    eisbart schrieb:
    --------------------------------------------------------------------------------
    > Tuxraxer007 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Es gab zw. Docker und Redhat wohl einige Probleme in der Zusammenarbeit.
    >
    > Ja, bei Docker laufen ein paar Type rum, die kein systemd und SELinux mögen
    > und deswegen interop pull requests ohne Kommentar schließen. Abgesehen
    > davon implementiert Docker eine eigene Art init System in schlecht.

    Hallo,

    ich bin mir gerade nicht sicher, ob ich die Aussage richig nachvollziehe. Ich habe verstanden, Sie meinen, dass man innerhalb eines Dockercontainers mit init-Skripten usw. arbeitet.

    Nach meinem Verständnis hat man innerhalb eines Containers möglichst nur die notwendigen Libs und ein Programm, welches man im Idealfall direkt startet. Der Idealfall ist gegeben, wenn das Programm die SIGs richtig verarbeiten bzw. darauf reagieren kann. Ansonsten gibt es jetzt noch dumb-init, was quasi transparent im Hintergrund das abräumen übernimmt. Mehr braucht es nicht, oder?

    Gruß,
    Peddy

  19. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: Hawk321 02.10.19 - 23:58

    peddy_hh schrieb:
    --------------------------------------------------------------------------------
    > eisbart schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Tuxraxer007 schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Es gab zw. Docker und Redhat wohl einige Probleme in der
    > Zusammenarbeit.
    > >
    > > Ja, bei Docker laufen ein paar Type rum, die kein systemd und SELinux
    > mögen
    > > und deswegen interop pull requests ohne Kommentar schließen. Abgesehen
    > > davon implementiert Docker eine eigene Art init System in schlecht.
    >
    > Hallo,
    >
    > ich bin mir gerade nicht sicher, ob ich die Aussage richig nachvollziehe.
    > Ich habe verstanden, Sie meinen, dass man innerhalb eines Dockercontainers
    > mit init-Skripten usw. arbeitet.
    Docker hat kein init System ! Jedenfalls kein richtiges, mehr als 1 main Prozess geht nicht. Wenn man das will, muss man ein extra Tool wie SupervisorD nutzen, das als main App genutzt wird und dann andere Dienste spawnt...verglichen zu SystemD mit direkt konfigurierten Diensten empfinde ich das als reinste Tortur. Das ist ja gerade eines der Hauptmankos.

    > Nach meinem Verständnis hat man innerhalb eines Containers möglichst nur
    > die notwendigen Libs und ein Programm, welches man im Idealfall direkt
    > startet. Der Idealfall ist gegeben, wenn das Programm die SIGs richtig
    > verarbeiten bzw. darauf reagieren kann. Ansonsten gibt es jetzt noch
    > dumb-init, was quasi transparent im Hintergrund das abräumen übernimmt.
    > Mehr braucht es nicht, oder?
    >
    > Gruß,
    > Peddy
    Nicht ganz...die Anwendung kann richtig groß sein. Sollte nicht, aber viele Firmen verwechseln Docker mit einer VM. Und so kommen dann große Anwendungen die aufwändig via Skript konfiguriert werden müssen. Sobald so ein Container die 1GB Grenze erreicht hat und mehrere davon laufen, dauert auch ein Start recht lange...so lange, das eine kleine VM schneller hochgefahren ist.
    Docker kann toll sein, wenn die Anwendung im Container gekapselt ist, die Konfigdateien überschaubar sind und die da rein gemounted werden. Sobald das alles komplexer und größer wird, kann so ein Container dir große Kopfschmerzen bereiten. Die Dinger sind nicht wirklich kleiner. Alpine ist zwar klein, wird jedoch oftmals in Enterprise Umgebungen komplett untersagt.
    Und sobald man für jeden Kram einen eigenen Container hat (LAMP Stack), ist die Sache nicht mehr soo viel kleiner als eine VM (hatte sogar es größer gehabt).

    Letztenendes ist Docker ein Tool, nicht mehr und nicht weniger. Leider häufig missbraucht und von den falschen Leuten entwickelt und betrieben. Hier das Marketing nicht ganz unschuldig dran, meiner Meinung nach.

    Grundsätzlich kann ich sagen, wenn Unternehmen es nicht schaffen Ihre Programme vernünftig zu dokumentieren und wissen, was wirklich benötigt wird...wird es nie was mit Container...egal von welchen "Anbieter". Meine Erfahrung: "Ja läuft doch ...irgendwie" oder "Ja ich kopiere da immer was rein und es ging".
    Engineering sieht anders aus !

  20. Re: Na da bin ich ja mal auf die ganzen Totalausfälle gespannt

    Autor: peddy_hh 03.10.19 - 00:35

    Hawk321 schrieb:
    --------------------------------------------------------------------------------
    > peddy_hh schrieb:
    > ---------------------------------------------------------------------------


    > > Nach meinem Verständnis hat man innerhalb eines Containers möglichst nur
    > > die notwendigen Libs und ein Programm, welches man im Idealfall direkt
    > > startet. Der Idealfall ist gegeben, wenn das Programm die SIGs richtig
    > > verarbeiten bzw. darauf reagieren kann. Ansonsten gibt es jetzt noch
    > > dumb-init, was quasi transparent im Hintergrund das abräumen übernimmt.
    > > Mehr braucht es nicht, oder?

    > Nicht ganz...die Anwendung kann richtig groß sein. Sollte nicht, aber viele
    > Firmen verwechseln Docker mit einer VM. Und so kommen dann große
    > Anwendungen die aufwändig via Skript konfiguriert werden müssen. Sobald so
    > ein Container die 1GB Grenze erreicht hat und mehrere davon laufen,
    OK, das verstehe ich noch nicht ganz. Was macht die Anwendung so richtig gross?
    Das Basis-Dockerimages, also z.B. Debian, Centos, Alpine?
    Die darin installierten Zusatz Libs?
    Die darin installierten "Hilfsprogramme", welche?
    Evtl. ein Applicationserver wie Websphere?
    Das eigentlich Programm?


    > Docker kann toll sein, wenn die Anwendung im Container gekapselt ist, die
    > Konfigdateien überschaubar sind und die da rein gemounted werden. Sobald
    > das alles komplexer und größer wird, kann so ein Container dir große
    > Kopfschmerzen bereiten.
    Die hatte man aus meiner Sicht dann aber schon vorher.
    Docker ändert wie gesagt daran nichts.


    > Die Dinger sind nicht wirklich kleiner.
    Naja, wenn man im ersten Schritt alles "nur" in Dockercontainer verpackt,
    bleibt es eben "gleichgross".
    Meiner Erfahrung nach ist das ggf. sogar erstmal ein gutes Vorgehen, denn dann macht man sich mit Docker bzw. Containerizierung vertraut. Wenn man jetzt selbst Erfahrungen gesammelt hat, lernt man schnell, wie man ggf. "Anwendungen", welche aus mehreren Programmen bestehen, auspalten kann. Dann wird der verbrauchte Festplattenplatz erstmal etwas mehr, Hauptspeicherverbrauch bleibt gleich.


    > Alpine ist zwar klein, wird jedoch oftmals in Enterprise Umgebungen komplett
    > untersagt.
    Warum eigentlich? Was wird stattdessen genommen?

    > Und sobald man für jeden Kram einen eigenen Container hat (LAMP Stack), ist
    > die Sache nicht mehr soo viel kleiner als eine VM (hatte sogar es größer
    > gehabt).
    Bzgl. Hauptspeicher oder Festplattenplatz?
    Hauptspeicher kann ich mir nicht vorstellen / erklären. Denn die eigentlichen Prozesse sind diesselben. Dort adressiert nur Linux-Namespaces, Cgroups und IP-Tables, das kostet höchstens ein KB, wenn überhaupt.
    Festplattenplatz sollte bei gleichem Betriebssystem-Dockerbasisimages auch kaum mehr sein, weil Docker hier mit sog. Layern arbeitet und das funktioniert ausgezeichnet. Kurz illustiert heisst das bei einer Anwendung mit 3 Programmen:

    Bei VMs:
    3x VM Basisbetriebssystem
    1x AnwendungA
    1x AnwendungB
    1x AnwendungC


    Bei Container:
    1x Basisbetriebsystem als Layer + 3x minimale Verwaltungseinträge für jede Anwendung
    1x AnwendungA
    1x AnwendungB
    1x AnwendungC


    Dies gilt für Festplattenplatz und Hauptspeicher gleichermassen.


    > Letztenendes ist Docker ein Tool, nicht mehr und nicht weniger.
    Dem kann ich vorbehaltlos zustimmen.

    > Leider häufig missbraucht und von den falschen Leuten entwickelt und betrieben.
    Das verstehe ich nicht.

    > Hier das Marketing nicht ganz unschuldig dran, meiner Meinung nach.
    Wessen Marketing?


    > Grundsätzlich kann ich sagen, wenn Unternehmen es nicht schaffen Ihre
    > Programme vernünftig zu dokumentieren und wissen, was wirklich benötigt
    > wird...wird es nie was mit Container...egal von welchen "Anbieter".
    An dieser Stelle hab ich eine komplett andere Meinung.
    Gerade durch die Dockerfiles (ich nehm die mal stellvertretend)
    bekommt man endlich mal sowas wie eine impliziert erstellte Dokumentation.
    Selbst diese Art der Konfiguration und Installationsanleitung fehlte ja bisher häufig.
    (ich bin seit ca. 1988 in diesem Umfeld tätig).

    > Meine
    > Erfahrung: "Ja läuft doch ...irgendwie" oder "Ja ich kopiere da immer was
    > rein und es ging".
    > Engineering sieht anders aus !
    Wie gesagt, sehe ich anders.
    Die Dockerfiles und letztendlich auch die Bauanleitungen (bei uns Jenkins bzw. Jenkinsfiles) liegen im SCM (git).
    Einzig die jetzt ordentlich entstehenden Architekturskizzen sind im Confluence. Ideal wäre, die wären auch mit im GIT. Hier ist aber häufig schwierig zu sagen, in welchem Repro man sie ablegen sollte, das wir einzelne Repros, anstatt von einem Monorepro haben.

    Die Container erlauben uns Kubernetes und somit auch die Dienstleistungen inder Cloud oder beim Datacenteranbieter zu nutzen. Wir waren noch nie so schnell in der Lage neben DEV, QS und PROD weitere Umgebungen hochzuziehen. Das aufwendigste ist das Mocken der Drittanbieter, sofern nötig.

    Gruß,
    Peddy

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Sanofi-Aventis Deutschland GmbH, Frankfurt am Main
  2. Elektrobit Automotive GmbH, Ulm
  3. Hays AG, Berlin
  4. Stiftung Kirchliches Rechenzentrum Südwestdeutschland, Eggenstein-Leopoldshafen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. 555,55€ (zzgl. Versandkosten)
  3. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Netzwerke: Warum 5G nicht das bessere Wi-Fi ist
Netzwerke
Warum 5G nicht das bessere Wi-Fi ist

5G ist mit großen Marketing-Versprechungen verbunden. Doch tatsächlich wird hier mit immensem technischem und finanziellem Aufwand überwiegend das umgesetzt, was Wi-Fi bereits kann - ohne dessen Probleme zu lösen.
Eine Analyse von Elektra Wagenrad

  1. Rechenzentren 5G lässt Energiebedarf stark ansteigen
  2. Hamburg Telekom startet 5G in weiterer Großstadt
  3. Campusnetze Bisher nur sechs Anträge auf firmeneigenes 5G-Netz

Elektroschrott: Kauft keine kleinen Konsolen!
Elektroschrott
Kauft keine kleinen Konsolen!

Ich bin ein Fan von Retro. Und ein Fan von Games. Und ich habe den kleinen Plastikschachteln mit ihrer schlechten Umweltbilanz wirklich eine Chance gegeben. Aber es hilft alles nichts.
Ein IMHO von Martin Wolf

  1. IMHO Porsche prescht beim Preis übers Ziel hinaus
  2. Gaming Konsolenkrieg statt Spielestreaming

Weltraumsimulation: Die Star-Citizen-Euphorie ist ansteckend
Weltraumsimulation
Die Star-Citizen-Euphorie ist ansteckend

Jubelnde Massen, ehrliche Entwickler und ein 30 Kilogramm schweres Modell des Javelin-Zerstörers: Die Citizencon 2949 hat gezeigt, wie sehr die Community ihr Star Citizen liebt. Auf der anderen Seite reden Entwickler Klartext, statt Marketing-Floskeln zum Besten zu geben. Das steckt an.
Ein IMHO von Oliver Nickel

  1. Theatres of War angespielt Star Citizen wird zu Battlefield mit Raumschiffen
  2. Star Citizen Mit der Carrack ins neue Sonnensystem
  3. Star Citizen Squadron 42 wird noch einmal verschoben

  1. Half-Life: Testspieler schaffen 2 bis 3 Stunden Alyx am Stück
    Half-Life
    Testspieler schaffen 2 bis 3 Stunden Alyx am Stück

    Virtual Reality kann anstrengend sein, das nur für VR geplante Half-Life Alyx soll aber Spaß machen - so viel, dass sich Spieler im Versuchslabor länger damit beschäftigen als vom Entwickler erwartet. Valve hat noch ein paar weitere neue Informationen zum Gameplay veröffentlicht.

  2. Soziales Netzwerk: Medienanstalt geht wegen Pornografie gegen Twitter vor
    Soziales Netzwerk
    Medienanstalt geht wegen Pornografie gegen Twitter vor

    Laut der Medienanstalt Hamburg/Schleswig-Holstein macht sich Twitter strafbar, indem es Profile nicht sperrt oder löscht, die pornografisches Material verbreiten. Ein entsprechendes Verfahren ist eingeleitet worden, es drohen ein Bußgeld und eine Untersagung.

  3. The Eliminator: Forza Horizon 4 bekommt Battle-Royale-Modus
    The Eliminator
    Forza Horizon 4 bekommt Battle-Royale-Modus

    Bis zu 72 Fahrer können an einem neuen Battle-Royale-Modus namens The Eliminator teilnehmen, den Microsoft kostenlos für das Rennspiel Forza Horizon 4 anbietet. Einzige Regel: möglichst lange überleben.


  1. 17:28

  2. 16:54

  3. 16:26

  4. 16:03

  5. 15:17

  6. 15:00

  7. 14:42

  8. 14:18