Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Nachgefragt: Ein stabiler Kernel…

Und trotzdem keine standard kernel abi für module

  1. Thema

Neues Thema Ansicht wechseln


  1. Und trotzdem keine standard kernel abi für module

    Autor: anonymous 17.08.06 - 12:31

    Nach Aussagen aus dem Artiel gibt es nicht mal genug Entwickler alle Fehler zu beheben, statt dessen/trotzdem passen die Leute alle Treiber immer wieder an die neuen Kernelversionen an. Ist das nicht Arbeit an der falschen Stelle eingestezt? Ob nun opensource treiber oder nicht, wäre es nicht sinnvoll wenigstens stufenweise kernel api für treiber module einzurichten?!

  2. Re: Und trotzdem keine standard kernel abi für module

    Autor: soc 17.08.06 - 12:44

    anonymous schrieb:
    -------------------------------------------------------
    > Nach Aussagen aus dem Artiel gibt es nicht mal
    > genug Entwickler alle Fehler zu beheben, statt
    > dessen/trotzdem passen die Leute alle Treiber
    > immer wieder an die neuen Kernelversionen an. Ist
    > das nicht Arbeit an der falschen Stelle
    > eingestezt?
    es sind oftmals verschiedene personen, die neue treiber schreiben und die, die fehler beheben. warum sollte sich ein entwickler der firma xyz um irgendwelche kernel-bugs z. b. in linux/mm/madvise.c kümmern, wenn er angestellt ist einen treiber für ein neues produkt zu schreiben.

    > Ob nun opensource treiber oder nicht,
    > wäre es nicht sinnvoll wenigstens stufenweise
    > kernel api für treiber module einzurichten?!
    und jetzt noch mal auf deutsch?
    es gibt bereits eine api.

  3. Re: Und trotzdem keine standard kernel abi für module

    Autor: Hello World 17.08.06 - 14:57

    soc schrieb:
    -------------------------------------------------------
    > kernel api für treiber module einzurichten?!
    > und jetzt noch mal auf deutsch?
    > es gibt bereits eine api.
    Ja, eine die alle drei Releases geändert wird -.-

  4. Re: Und trotzdem keine standard kernel abi für module

    Autor: föhn 17.08.06 - 16:11

    Hello World schrieb:
    -------------------------------------------------------
    > soc schrieb:
    > --------------------------------------------------
    > -----
    > > kernel api für treiber module
    > einzurichten?!
    > und jetzt noch mal auf
    > deutsch?
    > es gibt bereits eine api.
    > Ja, eine die alle drei Releases geändert wird

    was aber für OSS treiber die im kernel enthalten sind unwesentlich ist, da diese imho von den kernel-maintainern angepasst werden.

    die philosophie ist ja eben die möglichst nur OSS im kernel zu haben.
    deshalb wird es anbietern die nur CSS treiber bereitstellen nicht grade erleichtert - in dem man eben keine rücksicht auf dieselbigen nimmt und wenn nötig mirnichtsdirnichts die api ändert.

  5. Re: Und trotzdem keine standard kernel abi für module

    Autor: kalikiana 17.08.06 - 17:46

    >
    > die philosophie ist ja eben die möglichst nur OSS
    > im kernel zu haben.
    > deshalb wird es anbietern die nur CSS treiber
    > bereitstellen nicht grade erleichtert - in dem man
    > eben keine rücksicht auf dieselbigen nimmt und
    > wenn nötig mirnichtsdirnichts die api ändert.

    Und dann geht es nach Hinten los wenn Firmen wie z.B. ATI einfach kein Interesse an aktuellen Linuxtreibern haben. :(

  6. Ursache an der Wurzel bekämpfen

    Autor: iggy 17.08.06 - 18:25

    Ich fände es klüger, wenn man sich endlich vom Monolithischem Kernel verabschieden würde und mehr in Richtung Microkernel arbeiten würde.
    Gerade jetzt, da ohnehin auf dualcore-cpu, quad-cpu usw. gearbeitet wird, fielen einige der ursprünglichen Nachteile des Microkernel ohnehin gen Vergangenheit.

    Natürlich hat das Monolithische System seine Vorteile. Aber man sieht ja, wie die Nachteile langsam die Vorzüge in den Schatten stellen.
    Ich denke, auch das Treiberproblem könnte so besser gelöst werden.

  7. Ursache an der Wurzel bekämpfen

    Autor: iggy 17.08.06 - 18:26

    Ich fände es klüger, wenn man sich endlich vom Monolithischem Kernel verabschieden würde und mehr in Richtung Microkernel arbeiten würde.
    Gerade jetzt, da ohnehin auf dualcore-cpu, quad-cpu usw. gearbeitet wird, fielen einige der ursprünglichen Nachteile des Microkernel ohnehin gen Vergangenheit.

    Natürlich hat das Monolithische System seine Vorteile. Aber man sieht ja, wie die Nachteile langsam die Vorzüge in den Schatten stellen.
    Ich denke, auch das Treiberproblem könnte so besser gelöst werden.

  8. na fang doch an damit

    Autor: xXXXXx 17.08.06 - 19:59

    wozu sollte man das bei linux tun? kommt doch demnächst GNU HURD. :D

  9. Re: Und trotzdem keine standard kernel abi für module

    Autor: Marek 17.08.06 - 21:42

    Was wiederum für ATI nach hinten los gehen würde.
    Naja "würde" denn AMD hat ja angekündigt OSS Treiber zu veröffentlichen..
    Wer die Kunden nicht nötig hat lässt es eben...aber auch wenn es nach Getrolle klingt: die Verbreitung steigt und wird mit Vista noch mehr steigen. TCPA oder wie auch immer MS das nun nennt sei dank.
    Hab mit der Beta 2 von Vista 3 Tage rumspielen dürfen und es ist schon nevigt bei JEDEM Programm eine "Nicht zertifiziertes Programm" - Meldung wegzuklicken.. Ausserdem ist es auf der 3 Mhz Maschine mit 3/4 Gig unglaublich langsam..

  10. Re: Und trotzdem keine standard kernel abi für module

    Autor: XeniosZeus 17.08.06 - 22:08

    föhn schrieb:
    -------------------------------------------------------
    > die philosophie ist ja eben die möglichst nur OSS
    > im kernel zu haben.
    Das ist ja genau das Dilemma. Um immer möglichst viele neue Hardware zu unterstützen, wird der Kernel immer schneller weiterentwickelt. Schnell und stabil passt aber nicht zusammen.

    > deshalb wird es anbietern die nur CSS treiber
    > bereitstellen nicht grade erleichtert - in dem man
    > eben keine rücksicht auf dieselbigen nimmt und
    > wenn nötig mirnichtsdirnichts die api ändert.
    Das nächste Dilemma. Beispiel Cherry.
    Für die Linux-Tastatur CyMotion gibt es 6 verschiedene Treiber - Fedora 4.0, Debian 3.1, Mandrake 10.1, Suse 9.x und 10.0 sowie den Source-Code Treiber.
    Schaut man in die entsprechenden Foren, gibt es trotz vorbildlicher Treiberunterstützung von Cherry viele nervige Probleme. Im Kernel wird die Tastatur nicht unterstützt, obwohl der Source-Code vorliegt.
    Da entscheidet eine kleine Gruppe, was neu in den Kernel kommt. Der Hersteller der Hardware hat darauf keinen Einfluss. Seine eigenen Treiber laufen wegen ständiger Änderung der Programmierschnittstelle (API) mehr schlecht als recht.
    Warum sollte ein Hardwarehersteller überhaupt noch Linux unterstützen?
    Über die Aufnahme im Kernel entscheidet er nicht und schlecht funktionierende Treiber schädigen den Ruf.
    Die Philosophie ist falsch! Problem ist nur zu lösen, wenn alles in Frage gestellt wird.


  11. Re: na fang doch an damit

    Autor: Mog 18.08.06 - 09:30

    xXXXXx schrieb:
    -------------------------------------------------------
    > wozu sollte man das bei linux tun? kommt doch
    > demnächst GNU HURD. :D

    Und das schon seit ueber 30 Jahren. ^^d

  12. Re: Und trotzdem keine standard kernel abi für module

    Autor: paddor 18.08.06 - 11:29

    XeniosZeus schrieb:
    -------------------------------------------------------
    > föhn schrieb:
    > --------------------------------------------------
    > -----
    > > die philosophie ist ja eben die möglichst nur
    > OSS
    > im kernel zu haben.
    > Das ist ja genau das Dilemma. Um immer möglichst
    > viele neue Hardware zu unterstützen, wird der
    > Kernel immer schneller weiterentwickelt. Schnell
    > und stabil passt aber nicht zusammen.
    >
    > > deshalb wird es anbietern die nur CSS
    > treiber
    > bereitstellen nicht grade erleichtert
    > - in dem man
    > eben keine rücksicht auf
    > dieselbigen nimmt und
    > wenn nötig
    > mirnichtsdirnichts die api ändert.
    > Das nächste Dilemma. Beispiel Cherry.
    > Für die Linux-Tastatur CyMotion gibt es 6
    > verschiedene Treiber - Fedora 4.0, Debian 3.1,
    > Mandrake 10.1, Suse 9.x und 10.0 sowie den
    > Source-Code Treiber.
    > Schaut man in die entsprechenden Foren, gibt es
    > trotz vorbildlicher Treiberunterstützung von
    > Cherry viele nervige Probleme. Im Kernel wird die
    > Tastatur nicht unterstützt, obwohl der Source-Code
    > vorliegt.
    > Da entscheidet eine kleine Gruppe, was neu in den
    > Kernel kommt. Der Hersteller der Hardware hat
    > darauf keinen Einfluss. Seine eigenen Treiber
    > laufen wegen ständiger Änderung der
    > Programmierschnittstelle (API) mehr schlecht als
    > recht.
    > Warum sollte ein Hardwarehersteller überhaupt noch
    > Linux unterstützen?
    > Über die Aufnahme im Kernel entscheidet er nicht
    > und schlecht funktionierende Treiber schädigen den
    > Ruf.
    > Die Philosophie ist falsch! Problem ist nur zu
    > lösen, wenn alles in Frage gestellt wird.
    >
    >


    loool, du troll
    hast du gedacht, alles kommt einfach so in den offiziellen kernel rein, nur weil die source verfügbar ist?
    1. heisst ist es nicht zwingend, dass die software unter der GPL steht, wenn deren source verfügbar ist (und GPL wird von den kernel-entwicklern bevorzugt/vorgeschrieben)
    2. kann man ja eigene treiber (sogar während laufendem betrieb) einbinden!
    3. wollen die kernel-entwickler auch sicher sein, dass die software durch und durch getestet ist und einwandfrei läuft! denn sie sind unabhängig, da geht's nicht um geld.. sie haben das recht und die freiheit dazu (darum ist reiser4 immer noch nicht drin, obwohl herr reiser dauernd stürmt)
    4. ist so eine tastatur nicht gross verbreitet
    5. wäre der kernel dann innerhalb von einer woche 5gb gross, wenn jeder treiber einfach so rein kommen würde

    und ganz nebenbei. was ist denn daran falsch, dass es jetzt eine neue kernel-serie gibt? ist doch ne super initiative, da die entwickler selber merken und auch zugeben, dass die neuen kernel im gegenstaz zu den älteren kerneln recht viele fehler enthalten (meiner meinung nach immer noch um welten besser als bei M$)

  13. Re: Ursache an der Wurzel bekämpfen

    Autor: paddor 18.08.06 - 11:30

    iggy schrieb:
    -------------------------------------------------------
    > Ich fände es klüger, wenn man sich endlich vom
    > Monolithischem Kernel verabschieden würde und mehr
    > in Richtung Microkernel arbeiten würde.
    > Gerade jetzt, da ohnehin auf dualcore-cpu,
    > quad-cpu usw. gearbeitet wird, fielen einige der
    > ursprünglichen Nachteile des Microkernel ohnehin
    > gen Vergangenheit.
    >
    > Natürlich hat das Monolithische System seine
    > Vorteile. Aber man sieht ja, wie die Nachteile
    > langsam die Vorzüge in den Schatten stellen.
    > Ich denke, auch das Treiberproblem könnte so
    > besser gelöst werden.


    ACK. GNU/Hurd soll endlich fertig werden! :P

  14. Re: na fang doch an damit

    Autor: iggy 18.08.06 - 11:30

    Nein, im Ernst.
    Wär doch ein guter Vorsatz für Kernel 3.0
    Bzgl. Gnu HURD: Was ist das genau? Wie weit ist das Einsetzbar?
    Sollte es nicht möglich sein, den GNU HURD-Code für ein neues Linux zu benutzen?

    xXXXXx schrieb:
    -------------------------------------------------------
    > wozu sollte man das bei linux tun? kommt doch
    > demnächst GNU HURD. :D


  15. Re: Und trotzdem keine standard kernel abi für module

    Autor: XeniosZeus 18.08.06 - 17:38

    paddor schrieb:
    -------------------------------------------------------
    > loool, du troll
    > hast du gedacht, alles kommt einfach so in den
    > offiziellen kernel rein, nur weil die source
    > verfügbar ist?
    Nein, hab ich nicht. Ich habe nur den derzeitigen Stand dargestellt, mit dem ein Hardwarehersteller zu kämpfen hat.
    Den Troll geb ich wieder zurück, der fühlt sich bei dir wohler.

    > 1. heisst ist es nicht zwingend, dass die software
    > unter der GPL steht, wenn deren source verfügbar
    > ist (und GPL wird von den kernel-entwicklern
    > bevorzugt/vorgeschrieben)
    Cherry war hier nur als Beispiel gedacht. Der Treiber von Cherry steht übrigens unter der GPL.

    > 2. kann man ja eigene treiber (sogar während
    > laufendem betrieb) einbinden!
    Das ist nicht das Thema. Beim Beispiel Cherry gibt es ja auch genügend Treiber. Ich wollte das Problem darstellen, dass der Hardwarehersteller keinen Einfluss auf den Kernel hat und er Treiber für verschiedene Distributionen und Kernelversionen herstellen muss, weil durch Fehler im Kernel laufend neue Versionen erscheinen. Deshalb ja auch der Ruf nach einem stabilen Kernel, auf dem aufgebaut werden kann.

    > 3. wollen die kernel-entwickler auch sicher sein,
    > dass die software durch und durch getestet ist und
    > einwandfrei läuft! denn sie sind unabhängig, da
    > geht's nicht um geld.. sie haben das recht und die
    > freiheit dazu (darum ist reiser4 immer noch nicht
    > drin, obwohl herr reiser dauernd stürmt)
    Genau! Welchen Teil des Golem-Beitages hast du dann nicht verstanden?
    Darum geht es. Ein stabiler Kernel wird gefordert. Da kann dann auch der Hardwarehersteller drauf aufbauen und muss nicht andauernd neue Treiber erstellen, weil Kernelpatches und Neuerungen zusammen als neue Kernelversion erscheinen, die dann wieder gepatcht werden muss, weil Fehler in den Neuerungen sind usw.

    > 4. ist so eine tastatur nicht gross verbreitet
    Typisches Grosskotzgehabe der Kernel-Maintainer. Kann für einen mittelständischen Hardwarehersteller nur heißen: Finger weg von der Unterstützung für Linux, oder was?

    > 5. wäre der kernel dann innerhalb von einer woche
    > 5gb gross, wenn jeder treiber einfach so rein
    > kommen würde
    Sag ich doch, die Philosophie ist falsch. Man kann nicht auf der einen Seite Treiber auf Basis der GPL einfordern und dann nicht im Kernel integrieren und auf der anderen Seite durch permanente unsichere Kernelversionen die Treiber der Hardwarehersteller unbrauchbar machen, um dann genau auf diese Treiber wieder zu schimpfen.

    > und ganz nebenbei. was ist denn daran falsch, dass
    > es jetzt eine neue kernel-serie gibt? ist doch ne
    > super initiative, da die entwickler selber merken
    > und auch zugeben, dass die neuen kernel im
    > gegenstaz zu den älteren kerneln recht viele
    > fehler enthalten (meiner meinung nach immer noch
    > um welten besser als bei M$)
    Falsch daran ist, dass Fehler UND neue Features zusammen in einen neuen Kernel eingebaut werden. Neue Features haben nun mal auch Fehler, somit bleibt der neue Kernel weiterhin fehlerhaft und zerstört ggf. Funktionen, die im alten Kernel noch einwandfrei liefen.
    Es wird ein stabiler Kernel verlangt. Keiner spricht davon, die Entwicklung neuer Features und Einbindung neuer Treiber einzustellen.
    Was hier gefordert wird, ist die Pflege des alten Kernels bei zusätzlicher Entwicklung einen neuen Kernels. Und das klappt höchstwahrscheinlich nicht, weil es zu wenige Entwickler gibt.
    Wichtige Sache für Firmen und Behörden, die Linux als OS haben. Die PCs werden vielleicht alle 3 bis 5 Jahre ausgetauscht und die Änderungen in der Software sind in der Regel nicht umwälzend. Da zählt nur Sicherheit. Wenn Sicherheit nur durch einen neuen Kernel mit dann zusätzlich neuen, aber nicht benötigten Funktionen erreicht werden kann, könnte die Sache kritisch werden. Immerhin sollen die Kisten nach einem Kernelupdate auch weiterhin laufen.


  16. Re: Und trotzdem keine standard kernel abi für module

    Autor: ich auch 18.08.06 - 17:47

    paddor schrieb:

    > loool, du troll
    > hast du gedacht, alles kommt einfach so in den
    > offiziellen kernel rein, nur weil die source
    > verfügbar ist?

    Wäre ja auch zuviel Arbeit. Das beweist das ein Monolithen Kernel nie komplette Hardwareunterstützung liefern kann. Zeit das Modell des Monolithen zu überdenken? Nicht für die Linusjünger...

    > 1. heisst ist es nicht zwingend, dass die software
    > unter der GPL steht, wenn deren source verfügbar
    > ist (und GPL wird von den kernel-entwicklern
    > bevorzugt/vorgeschrieben)

    VORGESCHRIEBEN, alles andere darf nicht gegen die GPL software gelinkt werden, so es veröffentlicht wird. Sourcen wirklich freier Lizenzen wie BSD werden kurzerhand assimiliert!

    > 2. kann man ja eigene treiber (sogar während
    > laufendem betrieb) einbinden!

    Genau. Am besten gleich selbst schreiben die Treiber. Und das Akrobatenstück mit dem laufenden betrieb ist auch ganz toll nützlich. Zum einbau der Hardware musst du einen normalen Rechner zwar sowieso ausschalten, hauptsache die Theorie stimmt. Und die ganzen leute die ihre lebenswichtigen Server zu hause haben soll man nicht vergessen. Da wo die Atomkraftwerke drannhaengen und so...

    > 3. wollen die kernel-entwickler auch sicher sein,
    > dass die software durch und durch getestet ist und
    > einwandfrei läuft!

    Und wieso braucht es dann jetzt den Stabilen Kernel wenn das so ist?

    > denn sie sind unabhängig, da
    > geht's nicht um geld..

    Genau. Und wie war das mit OS lässt sich Geld verdienen? Die machen das alles nur für die Liebe der "Community", lässt sich auch prima davon leben, wenn man Stüze kassiet. Den erwirtschaftbaren gewinn schöpft dann IBM am oberen Ende wieder ab.

    > sie haben das recht und die
    > freiheit dazu (darum ist reiser4 immer noch nicht
    > drin, obwohl herr reiser dauernd stürmt)

    Genau. Weil der böse Herr Reiser nämlich ganz viel Geld dafür bekommt wenn die sein FS einbauen. Vielleicht haben Sie auch einfach nur mal lust ihre MACHT auszukosten...

    > 4. ist so eine tastatur nicht gross verbreitet

    Genau. Linux unterstüzt ja fast alles an Hardware was auch Windows unterstüzt. Es sei denn es ist eben nicht so gross verbreitete Hardware. Dann kauf deine Hardware halt Linuxgerecht von GROSSEN Firmen wie Logitech. Nicht das da irgendwie diese ganze "freie" software geschichte nach hinten losgeht!

    > 5. wäre der kernel dann innerhalb von einer woche
    > 5gb gross, wenn jeder treiber einfach so rein
    > kommen würde

    Eben. Vielleicht doch an der zeit das Konzept zu überdenken, das der Kernel die Treiber stellt?

    > und ganz nebenbei. was ist denn daran falsch, dass
    > es jetzt eine neue kernel-serie gibt? ist doch ne
    > super initiative, da die entwickler selber merken
    > und auch zugeben, dass die neuen kernel im
    > gegenstaz zu den älteren kerneln recht viele
    > fehler enthalten (meiner meinung nach immer noch
    > um welten besser als bei M$)

    Und die meinug der "Community" ist hier bei weitem wichtiger...


  17. tanenbaum vs. torvalds

    Autor: iggy 19.08.06 - 13:11

    würde linus torvalds sich endlich mit hr. tanenbaum zusammensetzen und nicht immer auf stur stellen, wenns um das thema microkernel geht, hätte er sich vielleicht schon am hurd-projekt beteiligt. wie gesagt: kernel 3.0

    aber stolz und einsicht vertragen sich eben nicht.




    2 mal bearbeitet, zuletzt am 19.08.06 13:15 durch iggy.

  18. Re: Und trotzdem keine standard kernel abi für module

    Autor: meyerm 19.08.06 - 14:51

    Hallo Marek,

    Marek schrieb:
    -------------------------------------------------------
    > Naja "würde" denn AMD hat ja angekündigt OSS
    > Treiber zu veröffentlichen..

    Das ist doch eine sehr erfreuliche Nachricht! Könntest Du mir noch einen Verweis auf einen Artikel oder gar Presseerklärung schicken, um da etwas mehr nachlesen zu können? Vielen Dank dafür!

    M

  19. Re: Und trotzdem keine standard kernel abi für module

    Autor: cos3 21.08.06 - 15:12

    > Ausserdem ist es auf der 3 Mhz
    > Maschine mit 3/4 Gig unglaublich langsam..

    bei 3 mhz wudert mich das garnicht..


  1. Thema

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. GBA Professional e. Kfr., Ahrensfelde-Lindenberg
  2. GEOMAGIC GmbH, Leipzig
  3. Energiedienst Holding AG, Rheinfelden (Baden)
  4. Apollo-Optik Holding GmbH & Co. KG, Schwabach / Metropolregion Nürnberg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 135,00€ (Bestpreis!)
  2. (u. a. The Elder Scrolls Online: Elsweyr für 15,99€, Diablo 3 Battlechest für 17,49€, Iratus...
  3. 99,00€
  4. (u. a. 49-Zoll-TV für 399,99€, High-Resolution-Kopfhörer für 159,99€, Alpha 5100...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Noise Cancelling Headphones 700 im Test: Boses bester ANC-Kopfhörer sticht Sony vielfach aus
Noise Cancelling Headphones 700 im Test
Boses bester ANC-Kopfhörer sticht Sony vielfach aus

Bose schafft mit seinen neuen Noise Cancelling Headphones 700 eine fast so gute Geräuschreduzierung wie Sony und ist in manchen Punkten sogar besser. Die Kopfhörer haben uns beim Testen aber auch mal genervt.
Ein Test von Ingo Pakalski

  1. Bose Frames im Test Sonnenbrille mit Musik
  2. Noise Cancelling Headphones 700 ANC-Kopfhörer von Bose versprechen tollen Klang
  3. Frames Boses Audio-Sonnenbrille kommt für 230 Euro nach Deutschland

Arbeit: Hilfe für frustrierte ITler
Arbeit
Hilfe für frustrierte ITler

Viele ITler sind frustriert, weil ihre Führungskraft nichts vom Fach versteht und sie mit Ideen gegen Wände laufen. Doch nicht immer ist an der Situation nur die Führungskraft schuld. Denn oft verkaufen die ITler ihre Ideen einfach nicht gut genug.
Von Robert Meyer

  1. IT-Fachkräftemangel Freie sind gefragt
  2. Sysadmin "Man kommt erst ins Spiel, wenn es brennt"
  3. Verdeckte Leiharbeit Wenn die Firma IT-Spezialisten als Fremdpersonal einsetzt

Schienenverkehr: Die Bahn hat wieder eine Vision
Schienenverkehr
Die Bahn hat wieder eine Vision

Alle halbe Stunde von einer Stadt in die andere, keine langen Umsteigezeiten zur Regionalbahn mehr: Das verspricht der Deutschlandtakt der Deutschen Bahn. Zu schön, um wahr zu werden?
Eine Analyse von Caspar Schwietering

  1. DB Navigator Deutsche Bahn lädt iOS-Nutzer in Betaphase ein
  2. One Fiber EWE will Bahn mit bundesweitem Glasfasernetz ausstatten
  3. VVS S-Bahn-Netz der Region Stuttgart bietet vollständig WLAN

  1. Magentagaming: Auch die Telekom startet einen Cloud-Gaming-Dienst
    Magentagaming
    Auch die Telekom startet einen Cloud-Gaming-Dienst

    Google Stadia, Blade Shadow und jetzt Magentagaming: Die Deutsche Telekom macht beim derzeit viel diskutierten Cloud-Gaming-Geschäft mit. Das Angebot der Telekom umfasst zum Beginn 100 Spiele und soll in Full-HD und später in 4K funktionieren. Die Beta startet noch auf der Gamescom 2019.

  2. Streaming: Disney+ kommt zunächst nicht für Amazon-Geräte
    Streaming
    Disney+ kommt zunächst nicht für Amazon-Geräte

    Disneys Streamingdienst Disney+ wird auf einer Reihe von Geräten als App verfügbar sein - nicht jedoch auf Amazons Tablets und TV-Sticks. Außerdem hat Disney die ersten Länder bekanntgegeben, in denen der Dienst im November 2019 starten wird.

  3. Per Hubschrauber: US-Marine testet analoge Nachrichtenübermittlung
    Per Hubschrauber
    US-Marine testet analoge Nachrichtenübermittlung

    Wie übermittelt man eine Nachricht und stellt sicher, dass der Feind sie nicht mithört? Man lässt sie von einem fliegenden Boten ausliefern. Was vor 80 Jahren funktioniert hat, geht auch heute noch.


  1. 17:39

  2. 16:45

  3. 15:43

  4. 13:30

  5. 13:00

  6. 12:30

  7. 12:02

  8. 11:55