1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Kernel: Google will User-Threads…

Kooperatives Multitasking kommt wieder?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Kooperatives Multitasking kommt wieder?

    Autor: GAK 27.07.20 - 11:53

    Die Erweiterung um 'Switch' klingt für mich als ob das die Vorteile von kooperativem Multitasking (wenig bis kein Resourcenvertbrauch auf wartende Threads) bringen könnte ohne sich gleichzeitig den Nachteil (ein amoklaufender Thread bringt alles zum Stillstand) einzutreten.

    Spannend.

  2. Re: Kooperatives Multitasking kommt wieder?

    Autor: pythoneer 27.07.20 - 13:15

    "Kooperatives Multitasking" ist doch auch schon bei vielen Programmiersprachen ganz "hipp". Mit der Einführung von "promises" und dann die Verwendung von "async/await" in C#/Javascript/Rust/Goroutines ... macht den wandel dorthin deutlich. Man muss nur dummerweise wissen was man da tut – das ist dann wieder die andere Seite der Medaille. Man _KANN_ damit Sachen schneller machen, wenn man weiß was man tut und wie man overhead vermeiden kann. Man _KANN_ aber eben auch ganz schön ins Klo greifen, wovor einem das OS – wenigstens ein bisschen – geschützt hat.

  3. Re: Kooperatives Multitasking kommt wieder?

    Autor: schnedan 27.07.20 - 15:19

    Das Problem ist preemptives Multitasking: prima um ein Ressource an X Verbraucher zu verteilen... wenn es X+1 sind, dauert es länger, aber alle kommen irgendwann dran. Das ist das Problem eines Mainframes. Andererseits wenn du Reaktionszeit sicherstellen willst (Daten / Streamserver), dann ist preemptives Multitasking einfach der falsche Ansatz. Zumindest wenn man 100% Realtime benötigt.
    Definiertes Reaktionsverhalten (nachweisbar!!!) ist mit preemptiven MT nicht möglich... manche RTOS System schalten dazu nahtlos von preemptiv nach kooperativ um.
    kenne kein Paper das aussagt das man mit preemptiven Multitasking Latenz und Jitter garantieren kann. Aber der Linux kann ja soweit ich es verstehe inzw. auch kooperativ mit den RT Patches... oder zumindest etwas das nahe dran ist.

  4. Re: Kooperatives Multitasking kommt wieder?

    Autor: Quantium40 27.07.20 - 16:06

    schnedan schrieb:
    > Definiertes Reaktionsverhalten (nachweisbar!!!) ist mit preemptiven MT
    > nicht möglich... manche RTOS System schalten dazu nahtlos von preemptiv
    > nach kooperativ um.

    Es ist allerdings genau umgekehrt.
    Kooperatives Multitasking bedeutet, dass sich Tasks kooperativ verhalten müssen, da jeder Task selbst entscheidet, wann er die Kontrolle an den Scheduler zurückgibt. Beim präemptiven Multitasking hingegen sorgt der Scheduler per Hardwareinterrupt dafür, dass ein Task nach einer definierten Zeit die Kontrolle zurückgibt.
    Gerade in RTOS wäre kooperatives Multitasking potentiell tödlich, da ein einzelner hängender Prozess die CPU bis zum Timeout die CPU blockieren würde.

  5. Re: Kooperatives Multitasking kommt wieder?

    Autor: Deff-Zero 27.07.20 - 16:48

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > "Kooperatives Multitasking" ist doch auch schon bei vielen
    > Programmiersprachen ganz "hipp". Mit der Einführung von "promises" und dann
    > die Verwendung von "async/await" in C#/Javascript/Rust/Goroutines ... macht
    > den wandel dorthin deutlich.

    Das ist kein kooperatives Multitasking. Kooperatives MT heißt, daß ein laufender Thread verhindern kann, daß ein _beliebiger_ anderer Thread jemals wieder an die Reihe kommt.



    1 mal bearbeitet, zuletzt am 27.07.20 16:49 durch Deff-Zero.

  6. Re: Kooperatives Multitasking kommt wieder?

    Autor: schnedan 27.07.20 - 17:17

    nein, kooperatives Multitasking ist streng deterministisch und somit kann man das Einhalten der Timingvorgaben durch statische Analyse und oder math. Nachweis sicher nachweisen. Natürlich sind solche Modelle anfälliger für fehlerhaften Code.
    In Kommunikationssystemen hat man daher gerne reine Betriebsysteme auf ineinander verschachtelten State Machines basierend geschrieben. Damit kann man prima Multithreading nachbilden, es ist per se immer kooperativ und 100% deterministisch.

    Preemptives Multitasking hat seine Vorteile, aber wie gesagt ein 100% System für harte Echtzeit kann man damit einfach nicht machen. Lasse mich aber gerne durch ein wissenschaftliches Paper das das Gegenteil beweist gerne belehren.

  7. Re: Kooperatives Multitasking kommt wieder?

    Autor: MarcusK 27.07.20 - 17:44

    Quantium40 schrieb:
    > Gerade in RTOS wäre kooperatives Multitasking potentiell tödlich, da ein
    > einzelner hängender Prozess die CPU bis zum Timeout die CPU blockieren
    > würde.
    da ein hängender Prozess generell ein Fehler ist macht die Betrachtung wenig sinn. Ein defekter Thread kann auch wild im Speicher rumschreiben und damit das RTOS lahmlegen.

  8. Re: Kooperatives Multitasking kommt wieder?

    Autor: ulink 27.07.20 - 21:36

    MarcusK schrieb:
    --------------------------------------------------------------------------------
    > Ein defekter Thread kann auch wild im Speicher rumschreiben und
    > damit das RTOS lahmlegen.

    Ein "defekter" Thread kann dem OS nichts anhaben, nur den anderen Threads im selben Prozess.

  9. Re: Kooperatives Multitasking kommt wieder?

    Autor: nirgendwer 28.07.20 - 09:46

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > nein, kooperatives Multitasking ist streng deterministisch [...]

    Ich denke du verwechselst das. Es ist genau umgekehrt.

  10. Re: Kooperatives Multitasking kommt wieder?

    Autor: nirgendwer 28.07.20 - 10:12

    nirgendwer schrieb:
    --------------------------------------------------------------------------------
    > schnedan schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > nein, kooperatives Multitasking ist streng deterministisch [...]
    >
    > Ich denke du verwechselst das. Es ist genau umgekehrt.

    Zur Erklärung:

    - kooperativ -> Dein nächster Slide ist davon abhängig, wann der andere Thread/Prozess fertig ist und freiwillig die CPU abgibt. <- nicht vorhersagbar => nicht deterministisch

    - preemptive -> Du bekommst deinen nächsten Slice, festgelegt durch einen festen Timer-Interrupt <- vorhersagbar => deterministisch

    Der Unterschied zwischen RTOS und nicht-RTOS ist nun, dass es bei einem Nicht-RTOS-System mit preemtivem Scheduler Prozesse gibt, die nicht preemptible sind. IO, Kerneltreiber, etc. bzw. generell größere Interruptbehandlungen können den regelmäßigen Scheduling-Ablauf unterbrechen und bringen so nicht-Determinismus hinein. Bei Linux z.B. gab es lange den Big Kernel Lock -> der Kernel war mitunter mal lange mit sich selbst beschäftigt, ohne dass ein Userspace-Prozess dran kam. Das geht bei RTOS mal gar nicht.

    Cooperative funktioniert nur in einem Fall wirklich gut, dann aber tatsächlich besser: Du hast exakt eine Anwendung, die in sich und für sich kooperativ arbeitet. Das ist dann auch ein weiterer Punkt, der für Cooperative spricht: Durchsatz. Eine Anwendung kann beliebig lange arbeiten und so optimalen Durchsatz erzielen. (Stört mitunter ja nicht, dass andere "liebere" Prozesse völlig verhungern.)

  11. Re: Kooperatives Multitasking kommt wieder?

    Autor: schnedan 28.07.20 - 10:22

    kooperativ: ich weis genau wie lange jeder Thread dauert und kann genau vorhersagen wann ein Task fetig wird und welcher Task danach dran kommt.

    --> streng deterministisch

    preemptiv: ein Task wird beliebig zerstückelt, die Reihenfolge dazwischen ist kaum vorhersagbar da diese auch von externen Ereignissen abhängig sein kann - aber selbst wenn nicht ist der Lösungsraum riesig, die Bearbeitungsdauer eines Tasks ist sehr stark schwankend

    --> kein Determinismus

  12. Re: Kooperatives Multitasking kommt wieder?

    Autor: nirgendwer 28.07.20 - 10:39

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > kooperativ: ich weis genau wie lange jeder Thread dauert und kann genau
    > vorhersagen wann ein Task fetig wird und welcher Task danach dran kommt.
    >
    > --> streng deterministisch

    Nope. Der Task arbeitet so lange er will. Wie willst du da etwas vorhersagen?

    > preemptiv: ein Task wird beliebig zerstückelt, die Reihenfolge dazwischen
    > ist kaum vorhersagbar

    Ehm, er wird nicht "irgendwie" zerstückelt, sondern abhängig davon wie viele andere Prozesse es gibt und welche Priorität dieser Prozess hat. Bei einem RTOS mit RTOS-Priorität erhält er einen _festen_ Slot. Mithin: deterministisch.
    Wie gesagt: jedoch mitunter nicht mit maximalem Durchsatz. Aber das ist auch nicht die Aufgabe eines RTOS. (z.B. gelten RTOS allgemein alles andere als durchsatzkräftig und auch Linux wird mit RTOS-Patches weniger durchsatzkräftig)

    > da diese auch von externen Ereignissen abhängig sein
    > kann - aber selbst wenn nicht ist der Lösungsraum riesig, die
    > Bearbeitungsdauer eines Tasks ist sehr stark schwankend
    >
    > --> kein Determinismus

    Wie gesagt, sobald mehr als ein Task im System läuft, gilt das "sehr stark schwankend" insbesondere für kooperative Tasks! Da kann man sich auf überhaupt nichts mehr verlassen. Dummerweise ist genau das immer der Fall, sobald ein OS läuft. Das OS selber läuft ja auch.

  13. Re: Kooperatives Multitasking kommt wieder?

    Autor: nirgendwer 28.07.20 - 17:34

    nirgendwer schrieb:
    --------------------------------------------------------------------------------
    > Wie gesagt, sobald mehr als ein Task im System läuft, gilt das "sehr stark
    > schwankend" insbesondere für kooperative Tasks! Da kann man sich auf
    > überhaupt nichts mehr verlassen. Dummerweise ist genau das immer der Fall,
    > sobald ein OS läuft. Das OS selber läuft ja auch.

    Zur weiteren Erklärung: Wenn OS wie Anwendung kooperativ sein müssen, kann weder das OS wissen, wann es nach der Anwendung wieder dran ist, der es übergibt, noch kann die Anwendung wissen, wann sie wieder dran ist, nachdem sie dem OS übergeben hat. Das ist alles mögliche, aber sicher nicht deterministisch. Deterministisch, also vorhersagbar, wird es durch feste Zeitslots und das ist klar die Sache des "preemptive" Schedulers, solche vorausschauend/präventiv<sic> festlegt.

  14. Re: Kooperatives Multitasking kommt wieder?

    Autor: theojk 28.07.20 - 18:03

    MarcusK schrieb:
    --------------------------------------------------------------------------------
    > Quantium40 schrieb:
    > > Gerade in RTOS wäre kooperatives Multitasking potentiell tödlich, da ein
    > > einzelner hängender Prozess die CPU bis zum Timeout die CPU blockieren
    > > würde.
    > da ein hängender Prozess generell ein Fehler ist macht die Betrachtung
    > wenig sinn. Ein defekter Thread kann auch wild im Speicher rumschreiben und
    > damit das RTOS lahmlegen.

    Es muss ja nichtmal ein hängender Prozess sein. Es reicht ein schlecht programmierter Thread, der eine nicht voher absehbare Anzahl von Schleifendurchgängen durchgehen muss. So wird die Threadzeit unabsehbar lang. Bei sehr grossen Schleifen kann das bis zum Timeout dauern.

  15. Re: Kooperatives Multitasking kommt wieder?

    Autor: nirgendwer 29.07.20 - 09:15

    MarcusK schrieb:
    --------------------------------------------------------------------------------
    > da ein hängender Prozess generell ein Fehler ist macht die Betrachtung
    > wenig sinn. Ein defekter Thread kann auch wild im Speicher rumschreiben und
    > damit das RTOS lahmlegen.

    Diese Einstellung kommt vielleicht aus den 80ern des letzten Jahrhunderts, heute vielleicht noch von kleinen Mikrocontrollern, bei denen kein OS läuft sondern die Applikation nackt auf der Hardware. Auch RTOS-Systeme bestehen doch heute aus vielen Prozessen/Threads, die parallel aktiv sind, mit teils völlig unterschiedlicher Relevanz und laufen auf Hardware, die eine MMU bietet. Da ist nichts mit "wild im Speicher rumschreiben und damit das RTOS lahmlegen". Und bei preemptivem Scheduler auch nichts mit verhungern lassen anderer Prozesse inkl. dem OS.

    Auch bei einem RTOS-System sind dabei nicht zwangsläufig alle Prozesse von _essentieller_ Relevanz. Ein wildgewordener Sicherungs- oder Überwachungsprozess löst vielleicht eine Meldung aus, das System funktioniert aber weiter. Bzw. gerade auch essentielle Prozesse können durch einen fest durch einen Hardwareinterrupt ausgelösten Einsprung ins Betriebssystem (und dabei geht es ja bei der preemption) erkannt und neu gestartet werden, ohne dass das ganze System hängt oder andere essentielle Prozesse ebenfalls neu gestartet werden müssen und somit ihre Daten verlieren.

    Das gilt natürlich nicht, wenn auf kooperatives Scheduling gesetzt wird...

  16. Re: Kooperatives Multitasking kommt wieder?

    Autor: schnedan 29.07.20 - 09:35

    Ich gebs auf, Ich hoffe nur nie ein System nutzen zu müssen von Menschen die die Basics nicht zusammen bekommen...

  17. Re: Kooperatives Multitasking kommt wieder?

    Autor: nirgendwer 29.07.20 - 09:39

    Na dann lass die Finger von solchen Systemen und dir ist in diesem Punkt schon einmal ein Schritt geholfen.

  18. Re: Kooperatives Multitasking kommt wieder?

    Autor: mifritscher 29.07.20 - 15:55

    Vor allem weil schnedan einiges durcheinander haut bzw. vermischt.

    > kooperativ: ich weis genau wie lange jeder Thread dauert und kann genau
    > vorhersagen wann ein Task fetig wird und welcher Task danach dran kommt.
    >
    > --> streng deterministisch

    > preemptiv: ein Task wird beliebig zerstückelt, die Reihenfolge dazwischen
    > ist kaum vorhersagbar

    Zum einen: Die Aussagen "kooperativ" und "weiß wie lange jeder Thread dauert" sind orthogonal zueinander: Sprich: haben nichts miteinander zu tun.

    Zum anderen: Preemptiv und die Aussagen "beliebig zerstückeln und "Reihenfolge ist kaum vorhersagbar" sind ebenfalls orthogonal. DAs ist Aufgabe des Schedulers. Preemptiv und einen festen Timerinterrupt ist ebenfalls nicht zwingend.

    Kooperativ bedeutet nur, dass jeder Task selbst dafür verantwortlich gibt, die Kontrolle abzugeben, preemptiv, dass es einen Mechanismus gibt, die Kontrolle zu wechseln, der außerhalb des Tasks liegt. Unter welchen Bedingungen dieser Mechanismus zuschlägt und wie die Taskauswahl erfolgt ist davon erstmal völlig unabhängig.

    Harte Echtzeit kann man mit beiden Ansätzen erfüllen.
    Kooperativ ist da in kleinen Systemen erstmal einfacher, aber ein Fehler (Software, "Treiberhänger" aufgrund fehlerhafter HW etc.), und dir zerschießts das komplette Timing.
    Häufig unterlegt man das mit einem Preemptiven Multitasking: Jeder Task bekommt eine vorher festgelegte Zeit, in der er die anfallenden Aufgaben eigentlich dicke abarbeiten können muss - danach wird die Kontrolle freiwillig abgegeben. Wenn das wegen einem Fehler o.ä. nicht passiert haut das Timeout rein. Je nach Situation kann dann entweder einfach zum nächsten Task übergangen werden - oder dieser Task wird neu gestartet. In ganz einfachen Systemen gibts stattdessen die Watchdog - die das komplette System resetet. Die kann man auch als Art preemptives Multitasking ansehen.

    Spätestens wenn man einige "Idle"-Tasks hat (aka: Welche, die keine RT-Anforderungen haben) macht einem Preemptives Multitasking das Leben deutlich leichter, weil man dessen Laufzeiten nicht so akkurat durchrechnen muss - und gerade diese Tasks mit häufigen komplexen Berechnungen oder auch I/O können das einem auch ziemlich schwer machen.

  19. Ich glaube, du verwechselst was

    Autor: janoP 01.08.20 - 16:53

    Vorweg: Ich habe keine Ahnung von der Materie und habe mich nie näher mit Prozessmanagment beschäftigt. Bis heute kannte ich noch nicht mal die Begriffe „präemtives Multitasking“ und „kooperatives Multitasking“.

    Aber du argumentierst nicht dafür, dass das präemptive Multitasking deterministisch ist. Du argumentierst dafür, dass das Betriebssystem mehr Kontrolle darüber hat, wann welcher Task ausgeführt wird. Das bedeutet aber nicht, dass es deterministisch ist.

    Wenn das Betriebssystem einen Task anstößt, ohne zu wissen, wie lange dieser dauern wird, hat das nichts mit deterministisch oder nicht-deterministisch zu tun. Wenn das Betriebssystem den Task so lange laufen lässt, wie er braucht, kann ich (ich, nicht das Betriebssystem) im vorhinein ausrechnen, wie lange es brauchen wird, bis der Task zuende ist. Das Betriebssystem kann das natürlich nicht, dafür müsste es den Quellcode analysieren. Ich habe aber den Quellcode in der Hand, und wenn ich alle Details des Programm-Kontexts kenne (bzw. die Eingabe), kann ich sagen, wie viele CPU-Zyklen gebraucht werden, damit er zuende ist, und wenn ich weiß, welche Frequenz die CPU hat, kann ich auch sagen, wie lange der Task braucht.

    Das ist bei Echtzeit ganz wichtig. Da ist es nämlich so, dass es besser ist, wenn das Betriebssystem blockiert, als dass der eine Task verzögert wird.

    Wenn die Echzeitanwendung jetzt einen Fehler hat, so dass sie keinen Prozess danach mehr laufen lässt, dann ist das natürlich doof, und da kann einen dann auch das Betriebssystem nicht retten. Aber so ist das halt, wenn Programme Fehler haben. Theoretisch könnte das Betriebssystem auch einen Fehler haben und das präemtive Multitasking falsch implementieren. Kommt natürlich seltener vor, als dass einzelne Consumer-Anwendungen Fehler haben. Aber das ist halt der Tradeoff eines Echtzeitbetriebssystems.

  20. Re: Ich glaube, du verwechselst was

    Autor: nirgendwer 02.08.20 - 09:52

    janoP schrieb:
    --------------------------------------------------------------------------------
    > Vorweg: Ich habe keine Ahnung von der Materie und habe mich nie näher mit
    > Prozessmanagment beschäftigt. Bis heute kannte ich noch nicht mal die
    > Begriffe „präemtives Multitasking“ und „kooperatives
    > Multitasking“.
    >
    > Aber du argumentierst nicht dafür, dass das präemptive Multitasking
    > deterministisch ist. Du argumentierst dafür, dass das Betriebssystem mehr
    > Kontrolle darüber hat, wann welcher Task ausgeführt wird. Das bedeutet aber
    > nicht, dass es deterministisch ist.

    Doch, genau das bedeutet es: Planbarkeit für alle.

    > Wenn das Betriebssystem einen Task anstößt, ohne zu wissen, wie lange
    > dieser dauern wird, hat das nichts mit deterministisch oder
    > nicht-deterministisch zu tun.

    Eben, und das ist bei kooperativen Systemen der Fall: "ohne zu wissen, wie lang". Jeder andere Prozess (inklusive des Betriebssystems) hat keine Ahnung, wann er wieder dran ist. Auch "dein Echtzeitprozess" nicht, sobald er nicht mehr alleinig dranne ist, weil jeder andere Prozess ja ebenfalls beliebig lange dran sein kann. Also: Will er in "Echtzeit" (in der Praxis also einer definierten Zeitgrenze) reagieren, DARF er die Kontrolle NIEMALS abgeben. Mithin: Es gibt gar kein Betriebssystem in deinem Szenario.

    Bei Preemption ist das anders: Es steht vorher fest, wann spätestens das System wieder dran ist und bei Echtzeitsystemen dann eben auch ziemlich genau, wann der nächste Task mit Echtzeitpriorität dran ist. Mithin: Deterministisch. Auch wenn andere Tasks dran sind, können Echtzeitprozesse ihre Zeitanforderungen einhalten.

    > Wenn das Betriebssystem den Task so lange
    > laufen lässt, wie er braucht, kann ich (ich, nicht das Betriebssystem) im
    > vorhinein ausrechnen, wie lange es brauchen wird, bis der Task zuende ist.

    Sobald du in dem Fall die Kontrolle abgibst, wird das für dich völlig unberechenbar. Das funktioniert also nur, solange du ganz alleine bist und auch kein Betriebssystem da ist. Das ist genau der Punkt, den ich ja auch schon angesprochen hatte. Mithin: Du begründest die Kooperativen Systeme damit, dass man das System ganz weg lässt. Klar, keine Frage, das funktioniert.

    > Das Betriebssystem kann das natürlich nicht, dafür müsste es den Quellcode
    > analysieren.

    Eben genau dafür sind die definierten Rücksprungpunkte (Zeit und Codestelle) da. Mithin: Preemption.

    > Ich habe aber den Quellcode in der Hand, und wenn ich alle
    > Details des Programm-Kontexts kenne (bzw. die Eingabe), kann ich sagen, wie
    > viele CPU-Zyklen gebraucht werden, damit er zuende ist, und wenn ich weiß,
    > welche Frequenz die CPU hat, kann ich auch sagen, wie lange der Task
    > braucht.

    Dann musst du alles, inlusive IO und Interrupthandling und ... und ... und ... komplett selber machen. Sonst funktioniert das nicht. Mithin: Es gibt kein OS, das nicht bzgl. deiner "Kontrolle" mit involviert ist. Klar, das funktioniert auch, hat aber dann weder mit einem kooperativen noch präemptiven System zu tun, weil es kein "System" gibt.

    > Das ist bei Echtzeit ganz wichtig. Da ist es nämlich so, dass es besser
    > ist, wenn das Betriebssystem blockiert, als dass der eine Task verzögert
    > wird.

    Nope. Das ist für den Maximalen Durchsatz der High-Prio-Anwendung wichtig, das ist aber das exakte Gegenteil von Echtzeitsystemen.

    > Wenn die Echzeitanwendung jetzt einen Fehler hat, so dass sie keinen
    > Prozess danach mehr laufen lässt, dann ist das natürlich doof, und da kann
    > einen dann auch das Betriebssystem nicht retten.

    Kooperativ: System tot. Punkt.

    Präemptiv: Diese eine Anwendung tot. Das System (wie genereller I/O) und alle anderen Anwendungen funktionieren weiter. Andere Echzeitanwendungen sogar durchaus ohne dass ihre Zeitanforderungen gebrochen werden. Das System kann auf den toten Prozess reagieren - Neustarten, Fehlermeldungen generieren, etc.

    Also ich sehe da einen gehörigen Unterschied!

    > Aber so ist das halt, wenn
    > Programme Fehler haben. Theoretisch könnte das Betriebssystem auch einen
    > Fehler haben und das präemtive Multitasking falsch implementieren. Kommt
    > natürlich seltener vor, als dass einzelne Consumer-Anwendungen Fehler
    > haben. Aber das ist halt der Tradeoff eines Echtzeitbetriebssystems.

    Du beschreibst gar kein EchtzeitBETRIEBSsystem.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Zahoransky AG, Todtnau
  2. DMK E-BUSINESS GmbH, Berlin-Potsdam, Köln, Chemnitz
  3. MRH Trowe, Frankfurt am Main, München, Düsseldorf, Alsfeld
  4. Lidl Digital, Neckarsulm, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. PS5 inkl. 2. Controller + Spider-Man: Miles Morales für 649€)
  2. (u. a. Lenovo Tablets und Laptops (u. a. Lenovo Yoga S740 Laptop 14 Zoll FHD-IPS für 973,82€)
  3. ab 1.599€ auf Geizhals
  4. 499,99€ (Release 19.11.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


  1. Echo: Amazon bringt mehr Datenschutz für Alexa
    Echo
    Amazon bringt mehr Datenschutz für Alexa

    Bei der Nutzung von Alexa kann neuerdings die Speicherung der Sprachaufzeichnungen ganz unterbunden werden.

  2. Bytedance: Trump muss Download-Stopp von Tiktok begründen
    Bytedance
    Trump muss Download-Stopp von Tiktok begründen

    Einfach aus den App-Marktplätzen werfen geht nicht: Die US-Regierung um Donald Trump soll einem Gericht verraten, weshalb Tiktok aus dem App Store und dem Play Store fliegen soll.

  3. iPad 8 und iPad OS 14 im Test: Kritzeln auf dem iPad
    iPad 8 und iPad OS 14 im Test
    Kritzeln auf dem iPad

    Das neue iPad 8 ist ein eher unauffälliger Refresh seines Vorgängers, bleibt aber eines der lohnenswertesten Tablets. Mit iPad OS 14 bekommt zudem der Apple Pencil spannende neue Funktionen.


  1. 09:47

  2. 09:23

  3. 09:07

  4. 08:50

  5. 08:35

  6. 08:20

  7. 08:04

  8. 07:53