Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Programmiersprachen…

So geht es mir mit meinem Hobbyprojekt auch

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. So geht es mir mit meinem Hobbyprojekt auch

    Autor: TomSc 04.01.17 - 14:12

    Eines wundert mich: Die Sicherheit soll wachsen und gleichzeitig kommt es darauf an, dass der Code automatisch übersetzt werden kann? Das muss ja heißen, dass auf den übersetzten Code schon sehr viel Verlass ist.

    Jetzt noch ein C++ zu Rust-Tool und ein eindeutiger Weg, wie beim Entwickeln mit Rust auf Programmierfehler reagiert werden soll, und dann wäre das höchst interessant. Mein ganz persönliches Problem mit neuen Sprachen ist, dass ich genau diesen Punkt bis jetzt nicht durchschaue. Es gibt i.d.R. eine Toolchain, an der debugging Tools wie gdb hängen, und gerade wenn man etwas zusammen mit Windows machen möchte, stellt sich mir die Frage, ob das angenehm wird. (Problem: Rust schließt nicht jede Art von Zugriffsfehler aus, sondern laut eines Mitarbeiters nur bestimmte.) Ich habe unter solchen Umständen sowohl D als auch Rust nicht weiter interessant gefunden. Und dazu kommt halt auch Menge notwendiger unsafe-Blöcke in Rust code. In Servo beispielsweise gibt es einfach so viele Stellen davon, dass ich am Ende zu skeptisch bin, Rust eine Chance zu geben.

  2. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: SYS1 04.01.17 - 14:26

    Wenn du wirklich alle Probleme ausschließen willst, kommst du wohl nicht um eine formale Prüfung des Codes herum. Das gibt es, ist aber auch mit etwas Aufwand verbunden. Wenn du nur Speicherfehler vermeiden willst, kannst du hingegen in einer Sprache programmieren, die z.B. auf der JVM läuft, denn die verhindert Überläufe u.ä. grundsätzlich. Manche interessante Dinge, wie z.B. ein System, um C-Code so auszuführen, dass Speicher-Probleme nicht auftreten können (in dem Fall: C-Code mit einer ähnlichen Technologie wie in der JVM o.ä. ausführen), sind derzeit leider noch in Entwicklung. Der Vorteil von sowas ist jedenfalls, dass man entweder volle Performance auf Kosten der Sicherheit haben kann, oder volle Sicherheit vor Speicherfehlern auf Kosten von etwas Performance (Checks sind halt nicht ganz "kostenlos").

    Am Ende kommt es wohl nicht ausschließlich auf die Sprache an, sondern vielmehr auf die Tools, die man zum Prüfen/Ausführen des Codes nutzt.

  3. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: Trockenobst 04.01.17 - 14:38

    TomSc schrieb:
    --------------------------------------------------------------------------------
    > wäre das höchst interessant. Mein ganz persönliches Problem mit neuen
    > Sprachen ist, dass ich genau diesen Punkt bis jetzt nicht durchschaue. Es
    > gibt i.d.R. eine Toolchain, an der debugging Tools wie gdb hängen, und
    > gerade wenn man etwas zusammen mit Windows machen möchte, stellt sich mir
    > die Frage, ob das angenehm wird.

    Ich nutze Go mit VisualStudio (es klappt auch im Eclipse unter Linux, ist aber nicht so lecker und simpel).

    Crosscompile für x64 und ARM Architekturen ist kein Problem. Anbinden an viele alte C-Libs ist genauso eine unsafe Hölle, aber solange keiner die gesamte Infrastruktur nativ nach entwickelt bleibt es für eine lange Zeit so.

    Fürs debugging auf x64 klappt es mit VisualStudio und ein bisschen Handarbeit:
    https://duosoftware.com/blog/how-to-setup-visual-studio-code-to-debug-golang-with-delve/

    Jetzt wäre nativ Debugging auf Android auch schön ;) Aber das ist natürlich eine fortgeschrittene Ansage. Denn der Entwicklungsumgebung müsste Java, golang und vielleicht sogar C/C++ aus einem Guss debuggen können.

    Android Studio kann Java und C++ auf dem Device debuggen, aber bei den Golang Binaries gibt es dann abstürze, obwohl es dafür auch schon Plugins gibt.

    Für Windows ist man mit dem kostenlosen VistualStudio+Plugins schon sehr effizient.

  4. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: stiGGG 04.01.17 - 14:45

    SYS1 schrieb:
    --------------------------------------------------------------------------------
    > Wenn du wirklich alle Probleme ausschließen willst, kommst du wohl nicht um
    > eine formale Prüfung des Codes herum. Das gibt es, ist aber auch mit etwas
    > Aufwand verbunden. Wenn du nur Speicherfehler vermeiden willst, kannst du
    > hingegen in einer Sprache programmieren, die z.B. auf der JVM läuft, denn
    > die verhindert Überläufe u.ä. grundsätzlich. Manche interessante Dinge, wie
    > z.B. ein System, um C-Code so auszuführen, dass Speicher-Probleme nicht
    > auftreten können (in dem Fall: C-Code mit einer ähnlichen Technologie wie
    > in der JVM o.ä. ausführen), sind derzeit leider noch in Entwicklung. Der
    > Vorteil von sowas ist jedenfalls, dass man entweder volle Performance auf
    > Kosten der Sicherheit haben kann, oder volle Sicherheit vor Speicherfehlern
    > auf Kosten von etwas Performance (Checks sind halt nicht ganz
    > "kostenlos").
    >
    > Am Ende kommt es wohl nicht ausschließlich auf die Sprache an, sondern
    > vielmehr auf die Tools, die man zum Prüfen/Ausführen des Codes nutzt.

    So einfach ist das nicht. In Rust wird die Speichersicherheit zur Compile Time sichergestellt. Da passieren keine Checks zur Laufzeit und es geht auch kein GarbageCollector umher.

  5. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: Steffo 04.01.17 - 14:49

    TomSc schrieb:
    --------------------------------------------------------------------------------
    > (Problem: Rust schließt nicht jede Art von
    > Zugriffsfehler aus, sondern laut eines Mitarbeiters nur bestimmte.)

    Welche Zugriffsfehler soll Rust nicht ausschließen? Hört sich für mich mal wieder nach Halbwissen an. Rust schließt defaultmäßig alle Zugriffsfehler aus bzw. verursacht einen Panic, wenn man bei einem Array auf einen ungültigen Bereich zugreift. In C/C++ merkst du im schlimmsten Fall davon nichts, sondern liest einfach nur Mist aus und wunderst dich, weshalb dein Programm nicht richtig funktioniert.

    > Und dazu kommt halt auch Menge notwendiger
    > unsafe-Blöcke in Rust code. In Servo beispielsweise gibt es einfach so
    > viele Stellen davon, dass ich am Ende zu skeptisch bin, Rust eine Chance zu
    > geben.

    Das ist total übertrieben. Unsafe-Blöcke machen nur einen kleinen Teil aus und wenn es Abstürze gibt, dann kann man schon eine ganze Menge Code ausschließen, die für den Absturz verantwortlich sind. Darüber hinaus bietet Rust nicht nur Zugrifsssicherheit, sondern verhindert auch Data Races zur Compile-Zeit. Auch der Datentyp NULL existiert im Safe-Code nicht. Ferner ist es ein Leichtes in Rust Tests sogar für private Funktionen zu schreiben. Das geht selbst in modernen Programmiersprachen wie C# und Java nicht.



    1 mal bearbeitet, zuletzt am 04.01.17 14:54 durch Steffo.

  6. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: Anonymer Nutzer 04.01.17 - 14:50

    dh, der speicher wird nie freigegeben? :-)

  7. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: Vanger 04.01.17 - 14:52

    > Eines wundert mich: Die Sicherheit soll wachsen und gleichzeitig kommt es
    > darauf an, dass der Code automatisch übersetzt werden kann? Das muss ja
    > heißen, dass auf den übersetzten Code schon sehr viel Verlass ist.

    Ich behaupte jetzt einfach mal, dass die automatische Codeübersetzung nicht der letzte Schritt bei der Portierung ist sondern vielmehr einer der Zwischenschritte. Die automatische Übersetzung erledigt den Großteil der Arbeit, anschließend geht man den übersetzten Code nochmal Zeile für Zeile durch und prüft ihn. Das spart im Vergleich zu einer manuellen Übersetzung, die zum Großteil nur aus den immer gleichen Änderungen der Syntax besteht, noch immer immens Zeit.

  8. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: Anonymer Nutzer 04.01.17 - 14:54

    Steffo schrieb:
    > Welche Zugriffsfehler soll Rust nicht ausschließen? Hört sich für mich mal
    > wieder nach Halbwissen an. Rust schließt defaultmäßig alle Zugriffsfehler
    > aus bzw. verursacht einen Panic, wenn man bei einem Array auf einen
    > ungültigen Bereich zugreift. In C/C++ merkst du im schlimmsten Fall davon
    > nichts, sondern liest einfach nur Mist aus und wunderst dich, weshalb dein
    > Programm nicht richtig funktioniert.
    das geht mit vector bei c++ auch. ich will mal behaupten, dass c++ mit konsequentem einsatz von referenzen statt pointer und der c++ standard bibliothek genauso sicher wie rust ist. in rust wird das nur einfach in die syntax der sprache eingebaut. wenn es um mächtigkeit geht, kann man grundsätzlich sagen, dass fast alle sprachen eine (echte) teilmenge von c++ sind. mit c++ geht alles, was mit allen sprachen geht, und mehr.

  9. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: stiGGG 04.01.17 - 14:55

    bjs schrieb:
    --------------------------------------------------------------------------------
    > dh, der speicher wird nie freigegeben? :-)

    Nein, der Compiler stellt sicher, dass er immer freigegeben wird und das ganze wie in C nicht vergessen geht. Stichwörter sind lifetimes, ownership und borrowing.

  10. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: mnementh 04.01.17 - 15:03

    bjs schrieb:
    --------------------------------------------------------------------------------
    > Steffo schrieb:
    > > Welche Zugriffsfehler soll Rust nicht ausschließen? Hört sich für mich
    > mal
    > > wieder nach Halbwissen an. Rust schließt defaultmäßig alle
    > Zugriffsfehler
    > > aus bzw. verursacht einen Panic, wenn man bei einem Array auf einen
    > > ungültigen Bereich zugreift. In C/C++ merkst du im schlimmsten Fall
    > davon
    > > nichts, sondern liest einfach nur Mist aus und wunderst dich, weshalb
    > dein
    > > Programm nicht richtig funktioniert.
    > das geht mit vector bei c++ auch. ich will mal behaupten, dass c++ mit
    > konsequentem einsatz von referenzen statt pointer und der c++ standard
    > bibliothek genauso sicher wie rust ist. in rust wird das nur einfach in die
    > syntax der sprache eingebaut. wenn es um mächtigkeit geht, kann man
    > grundsätzlich sagen, dass fast alle sprachen eine (echte) teilmenge von c++
    > sind. mit c++ geht alles, was mit allen sprachen geht, und mehr.
    Beide (und viele andere Sprache) sind turingmächtig und daher können sie sich gegenseitig simulieren. Rust ist also eine echte Teilmenge von C++ und C++ eine echte Teilmenge von Rust.

  11. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: Steffo 04.01.17 - 15:06

    bjs schrieb:
    --------------------------------------------------------------------------------
    > Steffo schrieb:
    > > Welche Zugriffsfehler soll Rust nicht ausschließen? Hört sich für mich
    > mal
    > > wieder nach Halbwissen an. Rust schließt defaultmäßig alle
    > Zugriffsfehler
    > > aus bzw. verursacht einen Panic, wenn man bei einem Array auf einen
    > > ungültigen Bereich zugreift. In C/C++ merkst du im schlimmsten Fall
    > davon
    > > nichts, sondern liest einfach nur Mist aus und wunderst dich, weshalb
    > dein
    > > Programm nicht richtig funktioniert.
    > das geht mit vector bei c++ auch.

    Ja, bei Vektoren, wenn du at(), anstatt [] verwendest und dann wird diese Prüfung immer(!) gemacht. Rust macht diese Überprüfung aber nur, wenn diese nötig sind, d. h., dass hier Laufzeit gespart wird.

    > ich will mal behaupten, dass c++ mit
    > konsequentem einsatz von referenzen statt pointer und der c++ standard
    > bibliothek genauso sicher wie rust ist.

    Sicherlich nicht.
    - Du kannst mit C++ keine Data Races zur Compilezeit verhindern.
    - NULL ist immer noch in der Sprache eingebaut. Das kriegst du nicht mehr raus.
    - Zugriff auf nicht initialisierten Speicher problemlos möglich.
    - Du kannst in C++ jederzeit auf ungültige Bereiche zugreifen.

    Nimms mir nicht übel, aber du hast keine gute Vorstellung von Sicherheit und Gefahren.

    Rust würde diesen Code erst gar nicht kompilieren:

    void example {
    vector<string> vec;
    auto& elem = vec[0];
    vec.push_back("some string");
    cout << elem;
    }

    So viel, dass mit Referenzen alles sicher ist...



    2 mal bearbeitet, zuletzt am 04.01.17 15:11 durch Steffo.

  12. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: pythoneer 04.01.17 - 15:07

    stiGGG schrieb:
    --------------------------------------------------------------------------------
    > Nein, der Compiler stellt sicher, dass er immer freigegeben wird und das
    > ganze wie in C nicht vergessen geht. Stichwörter sind lifetimes, ownership
    > und borrowing.

    Es gibt unter Rust keine Sicherheit, dass Speicher wieder freigegeben wird. Leaks gelten als safe. Jedoch ist es nicht so das da ein Haufen Speicherleichen rumliegen. Und da kommt das von dir gesagte ins Spiel, Rust hat dafür einen Automatismus der keinen GC braucht, wie bei Java, Go, Swift etc. Das Freigeben wird halt einfach nicht garantiert wie es bei keine double frees, use after free, data races etc. ist. Und das liegt nicht an unsafe. std::mem::forget ist NICHT unsafe! Und das macht auch absolut Sinn denn bei einem abort werden die Destruktoren (Drop) nicht aufgerufen ... alles andere wäre unsafe! Denn in diesem Zustand ist es nicht mehr sicher Drop aufzurufen und würde zu undefined behavior führen und das will man unter Rust natürlich vermeiden.



    2 mal bearbeitet, zuletzt am 04.01.17 15:11 durch pythoneer.

  13. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: Anonymer Nutzer 04.01.17 - 15:10

    ich glaube, das geht nicht und widerspricht in erweiterten sinne dem halteproblem.

  14. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: Anonymer Nutzer 04.01.17 - 15:12

    die aussage kann schon mal nicht stimmen. wenn a eine echte teilmenge von b und b eine echte tellmenge von a ist, so sind a und b gleich und damit keine echten teilmengen voneinander, da eine echte teilmenge definiert ist als teilmenge aber ungleich.

    es geht mir eher um die praktische mächtigkeit. beispielweise beim direkten zugriff auf speicherbereiche.

  15. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: Anonymer Nutzer 04.01.17 - 15:14

    ich nehms dir nicht übel. :-)

    ich hab nur eben gemeint, wenn man diese ganzen features von c++ nicht verwendet. erklär mir mal data races zur kompilierungszeit.

  16. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: pythoneer 04.01.17 - 15:17

    bjs schrieb:
    --------------------------------------------------------------------------------
    > ich will mal behaupten, dass c++ mit
    > konsequentem einsatz von referenzen statt pointer und der c++ standard
    > bibliothek genauso sicher wie rust ist.

    Das kannst du gerne machen, ist dann halt einfach nur falsch. Das ist wirklich nicht böse gemeint aber es entspricht nicht der Wahrheit.

  17. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: TomSc 04.01.17 - 15:19

    In mir wächst die Vorstellung, dass Rust doch viel brächte. Die Unsicherheit bzgl. der ausgeschlossenen Fehlerklassen kommt hiervon https://users.rust-lang.org/t/rust-guarantees-no-segfaults-with-only-safe-code-but-it-segfaults-stack-overflow/4305

    Ganz blöd ist die tatsächliche erste Erfahrung, die ich mit Rust diesbezüglich hatte. Es passierte ein Abbruch (ich weiss nicht mehr ob Panic oder sonst etwas) zur Laufzeit, und obwohl die environment variable richtig gesetzt war, blieb der Backtrace leer. Es stand also da "Backtrace:" und dahinter gähnende Leere. Bedeutet, ich gebe der ganzen Sache noch mehr Zeit, bis ich wieder einsteige.

  18. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: tha_specializt 04.01.17 - 15:23

    Steffo schrieb:
    --------------------------------------------------------------------------------
    >Ferner ist es ein Leichtes in Rust Tests sogar für private
    > Funktionen zu schreiben. Das geht selbst in modernen Programmiersprachen
    > wie C# und Java nicht.

    Totaler Schwachsinn - das ist sowohl in C# als auch java problemlos möglich. Nicht besonders effizient aber das ist standardisiert und funktioniert prima - zumindest unter Java lautet das Stichwort für dich "Reflection", es gibt komplette testing / mockup frameworks die genau das automatisieren und vereinfachen - und wem das nicht reicht der kann sogar noch Kolosse wie aspektorientierte Programmierung mit CDI fahren, dann sind sogar anonyme Klassen ergo Laufzeitobjekte kein Problem mehr



    2 mal bearbeitet, zuletzt am 04.01.17 15:27 durch tha_specializt.

  19. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: Steffo 04.01.17 - 15:23

    bjs schrieb:
    --------------------------------------------------------------------------------
    > ich hab nur eben gemeint, wenn man diese ganzen features von c++ nicht
    > verwendet.

    Ich habe dir gerade unsicheren C++ Code gezeigt, der deinen "sicheren" Kriterien entsprach. Letztendes höre ich immer denselben O-Ton: "Wenn man keine Fehler macht, dann kann ich mit C/C++ auch sicher programmieren". – Etwas sinnfrei dieser O-Ton...

    > erklär mir mal data races zur kompilierungszeit.

    Du weißt was Data Races sind? Wenn also mehrere Threads auf eine Ressource zugreifen, eine lesend, die andere schreibend oder beide schreibend, dann werden inkonsistente Zustände gelesen bzw. geschrieben. Durch das Ownership-Modell von Rust, wird dieses schon zur Compilezeit verhindert. D. h., du willst den Code compilieren, der Compiler gibt dir aber einen Fehler. D. h., du musst dann einen Mutex o. ä. verwenden oder das Problem anderweitig lösen.

  20. Re: So geht es mir mit meinem Hobbyprojekt auch

    Autor: pythoneer 04.01.17 - 15:26

    TomSc schrieb:
    --------------------------------------------------------------------------------
    > In mir wächst die Vorstellung, dass Rust doch viel brächte. Die
    > Unsicherheit bzgl. der ausgeschlossenen Fehlerklassen kommt hiervon
    > users.rust-lang.org
    >
    > Ganz blöd ist die tatsächliche erste Erfahrung, die ich mit Rust
    > diesbezüglich hatte. Es passierte ein Abbruch (ich weiss nicht mehr ob
    > Panic oder sonst etwas) zur Laufzeit, und obwohl die environment variable
    > richtig gesetzt war, blieb der Backtrace leer. Es stand also da
    > "Backtrace:" und dahinter gähnende Leere. Bedeutet, ich gebe der ganzen
    > Sache noch mehr Zeit, bis ich wieder einsteige.

    Es ist natürlich so, dass rustc (der compiler) natürlich noch Fehler enthält. Die Garantien die es für Rust gibt können natürlich durch Fehler im Compiler negiert werden. Aber es sind dann halt bugs und immer wenn ein Programm welches mit rustc übersetzt werden konnte segfaulted dann ist das ein Compilerbug und man freut sich über Bugreports. Einige Sachen in rustc sind halt einfach noch "unsound" https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20%20label%3AI-unsound%20

    Und werden wohl erst behoben durch den Einsatz von MIR (https://blog.rust-lang.org/2016/04/19/MIR.html) an wichtigen Stellen. So kann man in Rust noch ein use after free erzeugen, was aber ein Bug ist. Hier zum selber ausprobieren auf Playrust https://is.gd/Zy8XPx

  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. Stadtwerke München GmbH, München
  2. KVV Kassel, Kassel
  3. we.CONECT Global Leaders GmbH, Berlin-Kreuzberg,Berlin
  4. Wilhelm Layher GmbH & Co. KG, Güglingen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 107,00€ (Bestpreis!)
  2. 92,60€
  3. 135,80€
  4. (u. a. Alien 40th Anniversary Steelbook, Ash vs Evil Dead Collector's edition, Predator 1 - 4 Box...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ryzen 3900X/3700X im Test: AMDs 7-nm-CPUs lassen Intel hinter sich
Ryzen 3900X/3700X im Test
AMDs 7-nm-CPUs lassen Intel hinter sich

Das beste Prozessor-Design seit dem Athlon 64: Mit den Ryzen 3000 alias Matisse bringt AMD sehr leistungsstarke und Energie-effiziente CPUs zu niedrigen Preisen in den Handel. Obendrein laufen die auch auf zwei Jahre alten sowie günstigen Platinen mit schnellem DDR4-Speicher.
Ein Test von Marc Sauter

  1. Ryzen 3000 BIOS-Updates schalten PCIe Gen4 für ältere Boards frei
  2. Mehr Performance Windows 10 v1903 hat besseren Ryzen-Scheduler
  3. Picasso für Sockel AM4 AMD verlötet Ryzen 3400G für flottere iGPU

LEDs: Schlimmes Flimmern
LEDs
Schlimmes Flimmern

LED-Licht zu Hause oder im Auto leuchtet nur selten völlig konstant. Je nach Frequenz und Intensität kann das Flimmern der Leuchtmittel problematisch sein, für manche Menschen sogar gesundheitsschädlich.
Von Wolfgang Messer

  1. Wissenschaft Schadet LED-Licht unseren Augen?
  2. Straßenbeleuchtung Detroit kämpft mit LED-Ausfällen und der Hersteller schweigt
  3. ULED Ubiquitis Netzwerkleuchten bieten Wechselstromversorgung

Forschung: Mehr Elektronen sollen Photovoltaik effizienter machen
Forschung
Mehr Elektronen sollen Photovoltaik effizienter machen

Zwei dünne Schichten auf einer Silizium-Solarzelle könnten ihre Effizienz erhöhen. Grünes und blaues Licht kann darin gleich zwei Elektronen statt nur eines freisetzen.
Von Frank Wunderlich-Pfeiffer

  1. ISS Tierbeobachtungssystem Icarus startet
  2. Sun To Liquid Solaranlage erzeugt Kerosin aus Sonnenlicht, Wasser und CO2
  3. Shell Ocean Discovery X Prize X-Prize für unbemannte Systeme zur Meereskartierung vergeben

  1. Coradia iLint: Alstoms Brennstoffzellenzüge bewähren sich
    Coradia iLint
    Alstoms Brennstoffzellenzüge bewähren sich

    Zwei Züge, 100.000 Kilometer, keine Probleme: Nach zehn Monaten regulärem Einsatz in Niedersachsen ist das französische Unternehmen Alstom zufrieden mit seinen Brennstoffzellenzügen.

  2. Matternet: Schweizer Post pausiert Drohnenlieferungen nach Absturz
    Matternet
    Schweizer Post pausiert Drohnenlieferungen nach Absturz

    Blutkonserven oder Gewebeproben müssen unter Umständen schnell zu ihrem Bestimmungsort gebracht werden. Die Schweizer Post setzt für solche Transporte Drohnen ein. Doch nach vielen problemlosen Flüge ist ein Copter abgestürzt. Das Drohnenprogramm wurde daraufhin vorerst gestoppt.

  3. Nintendo: Akku von überarbeiteter Switch schafft bis zu 9 Stunden
    Nintendo
    Akku von überarbeiteter Switch schafft bis zu 9 Stunden

    Die Hinweise auf eine Hardwarerevision bei der Nintendo Switch sind bestätigt. Bei der neuen Version ist die Akkulaufzeit deutlich verbessert - sie übertrumpft nun sogar die vom Handheld Switch Lite.


  1. 19:06

  2. 16:52

  3. 15:49

  4. 14:30

  5. 14:10

  6. 13:40

  7. 13:00

  8. 12:45