Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › WebGPU: Apple stellt moderne 3D…

Na hoffentlich...

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Na hoffentlich...

    Autor: ffx2010 08.02.17 - 17:20

    ...holt Apple dieses Mal wirklich alle ins Boot, gibt sich grosszügig und macht nicht irgendeinen weiteren, hirnrissigen Alleingang, wie z.B. mit OSX Metal vs. Mantle vs. DX.

    Mit Swift auf Windows sieht es ja AFAIK auch ziemlich mau aus. Dabei ist Swift wirklich super.



    1 mal bearbeitet, zuletzt am 08.02.17 17:21 durch ffx2010.

  2. Re: Na hoffentlich...

    Autor: maze_1980 08.02.17 - 17:49

    Ohne Android und PC würde das sowieso nichts, nur für Apple entwickeln die wenigsten.

  3. Re: Na hoffentlich...

    Autor: Stereo 08.02.17 - 18:05

    maze_1980 schrieb:
    --------------------------------------------------------------------------------
    > Ohne Android und PC würde das sowieso nichts, nur für Apple entwickeln die
    > wenigsten.

    Interessant, kannst du mal bitte die Statistik mit den genauen Zahlen verlinken?

  4. Re: Na hoffentlich...

    Autor: Bigfoo29 08.02.17 - 18:35

    Naja, schau Dir mal die Realität an... Windows Desktop-Marktdurchdringung vs. MacOS X, Android vs. Rest... es kann sich kaum ein Hersteller LEISTEN, nur für Apple zu entwickeln. Da brauchst Du keine extra Statistiken für.

    Regards.

  5. Re: Na hoffentlich...

    Autor: Stereo 08.02.17 - 18:57

    Bigfoo29 schrieb:
    --------------------------------------------------------------------------------
    > Naja, schau Dir mal die Realität an... Windows Desktop-Marktdurchdringung
    > vs. MacOS X, Android vs. Rest... es kann sich kaum ein Hersteller LEISTEN,
    > nur für Apple zu entwickeln. Da brauchst Du keine extra Statistiken für.
    >
    > Regards.

    Na ja, es geht hier nicht um "gefühlte" Tatsachen.
    Ich kenne zum Beispiel kaum jemanden der Windows benutzt und ein paar wenige die Android-Geräte besitzen. In meiner Branchen gibt es auch so gut wie keine Entwickler die für Windows programmieren und Android nur auf Nachfrage und mit erheblichen Preisaufschlag.

    Daher wären diese Zahlen schon ganz hilfreich. Gerade in Zeiten der "alternativen Fakten" ;)

  6. Re: Na hoffentlich...

    Autor: Moe479 08.02.17 - 19:06

    sry, deine "branche" scheint mir sehr begrenzt zu sein ...

  7. Re: Na hoffentlich...

    Autor: pythoneer 08.02.17 - 19:15

    Moe479 schrieb:
    --------------------------------------------------------------------------------
    > sry, deine "branche" scheint mir sehr begrenzt zu sein ...

    Ich weiß was er meint. Wir haben auch öfter Kunden, wo der Anteil an Apple Telefonen fast 90% ist. Meist so "Hippe" Unternehmen aus der Werbe- und Design Branche oder "Hippe" Sportartikelhersteller. Dann gibt es aber auch noch "normale" Unternehmen in eher "bodenständigeren" Branchen wo es dann wieder mehr auf Android Seite ist. Das sind aber immer mehr "Besserverdiener" – da ist es in der Tat so, dass es häufig ein Apple Gerät ist.

    Wenn man natürlich nur "Besserverdiener" in seinem Job und privat Leben um sich herum hat, dann kann natürlich der Eindruck entstehen, dass alle ein Apple Telefon haben. Aber steig mal in ein öffentliches Verkehrsmittel in Berlin, da sieht es dann wieder ganz anders aus und das zeigen auch die Statistiken. Die meisten Leute sind nun mal keine "Besserverdiener" und darum hat Android auch einen Marktanteil von > 80% im Mobilen Segment.

    Linux is highly user friendly, it is just highly selective who it is friends with.

  8. Re: Na hoffentlich...

    Autor: Seroy 08.02.17 - 19:19

    Stereo schrieb:
    --------------------------------------------------------------------------------
    > Bigfoo29 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Naja, schau Dir mal die Realität an... Windows
    > Desktop-Marktdurchdringung
    > > vs. MacOS X, Android vs. Rest... es kann sich kaum ein Hersteller
    > LEISTEN,
    > > nur für Apple zu entwickeln. Da brauchst Du keine extra Statistiken für.
    > >
    > > Regards.
    >
    > Na ja, es geht hier nicht um "gefühlte" Tatsachen.
    > Ich kenne zum Beispiel kaum jemanden der Windows benutzt und ein paar
    > wenige die Android-Geräte besitzen. In meiner Branchen gibt es auch so gut
    > wie keine Entwickler die für Windows programmieren und Android nur auf
    > Nachfrage und mit erheblichen Preisaufschlag.
    >
    > Daher wären diese Zahlen schon ganz hilfreich. Gerade in Zeiten der
    > "alternativen Fakten" ;)

    Ich weiß nicht in was für einer Welt du lebst aber die meisten Leute auf dieser großen Welt greifen eher mit einem Windows PC/Laptop und einem Android Handy auf das Internert zu, siehe
    http://gs.statcounter.com/os-market-share/all/worldwide/#monthly-201608-201701

    (Das Ergebnis ist ungefähr mit der Realität vereinbar, da Statcounter in sehr vielen Seiten drin ist und egal was du auf google dazu findest die Ergebnisse zeigen, das Apple User die Minderheit sind)

    Nicht jeder lebt in der bunten Apfel Welt, die meisten haben wie vorhin schon gesagt Windows und Android und wenn man für die nicht mitentwickelt dann spricht man nur 18% der Internetnutzer an was ja sehr viek bringt.



    3 mal bearbeitet, zuletzt am 08.02.17 19:27 durch Seroy.

  9. Re: Na hoffentlich...

    Autor: Iomega 08.02.17 - 19:46

    ffx2010 schrieb:
    --------------------------------------------------------------------------------
    > Mit Swift auf Windows sieht es ja AFAIK auch ziemlich mau aus. Dabei ist
    > Swift wirklich super.
    Wieso? Es hindert niemand dich oder andere dran es für Window zu Portieren. Aber warum sollte gerade Apple dass machen...

  10. Re: Na hoffentlich...

    Autor: Stereo 08.02.17 - 19:47

    Seroy schrieb:
    --------------------------------------------------------------------------------

    > Ich weiß nicht in was für einer Welt du lebst aber die meisten Leute auf
    > dieser großen Welt greifen eher mit einem Windows PC/Laptop und einem
    > Android Handy auf das Internert zu, siehe
    > gs.statcounter.com#monthly-201608-201701
    >
    > (Das Ergebnis ist ungefähr mit der Realität vereinbar, da Statcounter in
    > sehr vielen Seiten drin ist und egal was du auf google dazu findest die
    > Ergebnisse zeigen, das Apple User die Minderheit sind)
    >
    > Nicht jeder lebt in der bunten Apfel Welt, die meisten haben wie vorhin
    > schon gesagt Windows und Android und wenn man für die nicht mitentwickelt
    > dann spricht man nur 18% der Internetnutzer an was ja sehr viek bringt.

    Es geht hier nicht um "Schwanzvergleiche", sondern um die Beantwortung einer schlichten Frage.

  11. Re: Na hoffentlich...

    Autor: /mecki78 08.02.17 - 20:17

    ffx2010 schrieb:
    --------------------------------------------------------------------------------
    > OSX Metal vs. Mantle vs. DX.

    Mantle ist von AMD und das hat auch noch nie mit irgendwas funktioniert als AMD Grafikkarten unter Windows. Was kann Apple bitte für Mantel oder was haben sie damit zu tun? Apple verbaut größtenteils keine AMD Grafikchips, ergo könnten sie Mantel nicht einmal unterstützen, selbst wenn sie wollten.

    Und DirectX gehört Microsoft und Microsoft würde Apple im Leben nicht erlauben, dass zu unterstützen. Apple könnte das gar nicht unterstützen, selbst wenn sie wollten. Außerdem ist DirectX C++ mit einem C# Binding. C++ wäre absolut exotisch unter MacOS weil da so gut wie nichts C++ ist. Für Mac Entwickler wäre das höchst befremdlich, hier müsste man erst mal einen Wrapper bauen, denn C# gibt es auch nicht für den Mac und auch da kann Apple nichts dafür (auch das gehört Microsoft und auch hier hat MS gar kein Interesse daran, dass C# Apps unter MacOS X laufen; GOD BEHAVE!)

    Also das einzige was du Apple vorwerfen kannst, ist das sie nicht auf Vulkan setzten, denn das ist ein offener Standard und den dürften sie implementieren. Aber als Apple Metal vorgestellt hat, als fertige und bereits nutzbare API, da war Vulkan gerade mal ein schönes Konzept. Die API war da noch nicht einmal auf dem Papier fertig, geschweige denn final oder irgendwo implementiert. Apple brauchte eine neue, besser 3D API als OpenGL und das sofort und nicht erst in 3-5 Jahren. Also haben sie eine eigene gemacht, denn Mantel und DX wäre nicht möglich gewesen, siehe oben, und was anderes hat der Markt nicht angeboten.

    Die neuen APIs sind alle recht ähnlich, denn GPUs können nun einmal das was sie können und funktionieren nun einmal so wie sie funktionieren. Egal ob du DX, Vulkan oder Matel nimmst, die Treiber funktionieren gleich, die GPUs funktionieren gleich und daher gleichen sich diese APIs auch enorm. Viel mehr als z.B. OpenGL und DX sich jemals geglichen hätten. Denn diese APIs sind nur noch hauchdünne Schichten zwischen der App und dem Treiber, die nur dazu dienen dass "jede App mit jedem Treiber sprechen kann", da die App immer die gleiche "Sprache" spricht (die der API) und der Treiber immer die gleiche "Sprache" versteht (die der API), um dann die Anweisungen in die passenden Anweisungen für die GPU umzuwandeln (wie das geht, dass muss wiederum nur der Treiber wissen).

    Ohne so eine Zwischen API müsste eine App direkt wissen, wie man mit jedem GPU Treiber am Markt spricht bzw. direkt wissen, wie man mit jeder GPU spricht. So war das früher mal (z.B. bei der Soundausgabe; mit den ersten Adlib Musikkarten und Soundblastern haben Apps noch direkt geredet, so Code habe ich sogar selber mal geschrieben), aber das skaliert nicht über eine gewisse Anzahl von Herstellern und Karten hinaus, setzt man heute eine Zwischensicht dazwischen. Die App kennt nur die API, der Treiber weiß wie er sich in die API hängen kann, der Treiber kennt seine GPU und weiß wie er mit der reden muss. Und sonst weiß niemand irgendwas.

    Bei OpenGL hat die API noch wirklich was gemacht. Da gab es Code, der echte 3D Berechnungen ausgeführt hat, denn die Idee von OpenGL war, dass die GPU zwar Dinge berechnen kann, aber nicht muss, zur Not macht man es halt auf der CPU. So bieten manchen Karten OpenGL Funktionen, die aber in Wahrheit komplett auf der CPU laufen, weil die GPU in Wahrheit gar nichts davon kann. Und bei vielen anderen Dingen ist es so, dass diese nur als Erweiterungen vorhanden waren, d.h. eine App konnte sich nicht darauf verlassen, dass die GPU etwas kann, sie musste vorher fragen und sich eine Backup Strategie einfallen lassen, falls nicht. Der Vorteil von OpenGL war nur der, dass man es so auf quasi jeden System hat anbieten können, zur Not als komplette Software-Emulation auf der CPU.

    Die neuen APIs, also DirectX ab 12, Vulkan und Mantel hingegen verfolgen ein anderes Konzept. Kann es die GPU nicht, dann ist es auch nicht möglich. Auch haben sie viel genauerer und modernere Anforderungen an das Mindestfunktionsset, dass ein GPU können muss um überhaupt zu den APIs kompatibel zu sein. Fast jeder Aufruf der API lässt sich auf einen Aufruf im GPU Treiber abbilden. Und deswegen unterscheiden sie sich nur im groben Design und wie bestimmte Konzepte gehandhabt werden. Insgesamt aber sind die APIs sehr ähnlich geworden, da sie sich eben an der Arbeitsweisen moderner Grafikkarten orientieren und die ist ja immer gleich, egal ob das System jetzt mit Linux, Windows oder macOS läuft.

    Und somit mach es auch Sinn zu sagen, dass wir einen Ersatz für WebGL brauchen und hier aber einen basteln, der eben weder WebDX, noch WebVulkan oder WebMetal ist, sondern einfach eine neutrale API, die die gleichen Konzepte verfolgt wie die drei und sich daher auf jede dieser drei APIs abbilden lässt.

    Und hier muss Apple "niemand in's Boot holen", das ist die falsche Redensart. Die anderen müssen "auf den Zug aufspringen". Apple definiert die API, implementiert sie für Metal und damit für macOS und iOS und bietet somit auch eine Referenzimplementierung mit. WebGPU dann auch auf der Basis von Vulkan und DX zu implementieren, dass wäre dann die Aufgabe der Linux Community oder Microsoft. Es klingt nicht so als würde Apple ihnen irgendwelche Steine dabei in den Weg legen, aber sie dazu zwingen können sie auch nicht, das müssen sie schon freiwillig tun.

    /Mecki

  12. Re: Na hoffentlich...

    Autor: QDOS 08.02.17 - 20:22

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Außerdem ist DirectX C++ mit einem C# Binding. C++ wäre absolut exotisch unter MacOS weil da so gut wie nichts C++ ist.
    Bitte was? DirectX basiert auf COM und nicht auf .NET!

    > Für Mac Entwickler wäre das höchst befremdlich, hier müsste man erst mal einen
    > Wrapper bauen, denn C# gibt es auch nicht für den Mac und auch da kann
    > Apple nichts dafür (auch das gehört Microsoft und auch hier hat MS gar kein
    > Interesse daran, dass C# Apps unter MacOS X laufen; GOD BEHAVE!)
    1. Ist C# bei der ECMA bist Version 2 standardisiert
    2. Ist .NET Core Open Source, zusätzlich gibt es als Alternative mono
    3. Ist der offizielle C# Compiler Open Source

  13. Re: Na hoffentlich...

    Autor: ffx2010 08.02.17 - 21:04

    Darum geht es doch gar nicht. Hätte Apple sich für Metal mit nVidia und AMD geeinigt, hätten sie jetzt alle Vorteile, plus die Portierung von Spielen wäre zukünftig leichter. Stattdessen hat Apple wieder ein eigenes Süppchen gekocht, zeitgleich sind doch mehrere GFX-APIs unter Windows/XboX/PS4 herausgekommen (Namen weiss nicht mehr). Die hätte Apple implementieren, oder Metal mit dazu beitragen müssen.

    Kaum jemand wird nur für Apple entwickeln oder eine Apple-eigene Schnittstelle bedienen wollen.

    Swift ist eine äussert gute Programmiersprache, wird sind aber nur behaupten können, wenn sie unter Windows genauso einfach genutzt werden kann. Eine weite Verbreitung der Sprache wäre im Sinne von Apple.

  14. Re: Na hoffentlich...

    Autor: ffx2010 08.02.17 - 21:05

    Ja genau, dass sie nicht auf Vulkan setzen. Metal wird keine Sau interessieren.

    Und Apple's Web-API genauso wenig. Dafür muss Apple schon noch mehr anbieten.



    1 mal bearbeitet, zuletzt am 08.02.17 21:08 durch ffx2010.

  15. Re: Na hoffentlich...

    Autor: FreiGeistler 09.02.17 - 12:07

    Stereo schrieb:
    --------------------------------------------------------------------------------
    > maze_1980 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ohne Android und PC würde das sowieso nichts, nur für Apple entwickeln
    > die
    > > wenigsten.
    >
    > Interessant, kannst du mal bitte die Statistik mit den genauen Zahlen
    > verlinken?

    Ein ehemaliger Kollege hat ähnlich reagiert, als ich Ihm als strenggläubigen Christen Russels Teekanne erklärte. ;-)

  16. Re: Na hoffentlich...

    Autor: /mecki78 09.02.17 - 13:45

    QDOS schrieb:
    --------------------------------------------------------------------------------
    >> Außerdem ist DirectX C++ mit einem C# Binding. C++ wäre absolut exotisch
    >> unter MacOS weil da so gut wie nichts C++ ist.
    > Bitte was? DirectX basiert auf COM und nicht auf .NET!

    Wo bitte hatte ich geschrieben, dass es auf .NET basiert? Ich sagte es ist eine C++ API, was erst einmal gar nichts mit COM oder .NET zu tun hat.

    COM ist keine Programmiersprache, es ist eine Interface-Technik, erfunden von Microsoft, und Microsoft verwendet das, weil in der frühen Phase von C++ es nicht möglich war stabile C++ Interfaces anzubieten (die C++ ABI war nicht stabil und konnte sich mit jedem Compiler Release ändern). Auch COM existiert so gut wie gar nicht außerhalb der MS Welt und ist eigentlich auch nicht nötig, wenn man für C++ einen ABI definiert und dann auch bei dieser bleibt (seit GCC 3.4 hat GCC eine feste ABI für C++, und zwar genau die gleiche, die auch Intel in ihren Compilern nutzt).

    Das ändert aber nichts daran, dass alle D3D COM Objekte C++ Klassen oder Gruppen von Klassen sind. Und es macht nichts an meiner Aussage besser, sondern es verschlechtert sie sogar noch. Nicht nur, dass hier eine für Mac Entwickler "fremdartige" Programmiersprache zum Zuge kommt (C++), nein, es kommt auch eine für Mac Entwickler (und macOS als System) fremdartige Schnittstelle (COM) zum Einsatz. Wo ist da bitte die Verbesserung?

    Und dann sagte ich es gibt ein C# Binding dafür und auch das hat mit COM oder .NET gar nichts zu tun. Du weißt schon was ein "Binding" ist, oder? Und geschrieben hatte ich das nur deswegen, da viele Entwickler D3D ja nur von C# aus kennen und sonst sehr befremdliche geschaut hätten, wenn ich sage "das ist C++", aber es ist C++, auch wenn man es "nativ" in C# verwenden kann.

    > 1. Ist C# bei der ECMA bist Version 2 standardisiert
    > 2. Ist .NET Core Open Source, zusätzlich gibt es als Alternative mono
    > 3. Ist der offizielle C# Compiler Open Source

    Und was hat das mit dem zu tun was ich geschrieben habe? Richtig, gar nichts. H.264 ist auch bei der ISO und der IEC standardisiert und es gibt diverse OpenSource Implementierungen von H.264. Deswegen ist es noch lange nicht Public Domain und jeder darf es nach belieben nutzten.

    Java ist auch standardisiert, es gibt diverse ganz freie Implementierungen und schon zu SUN Zeiten wurde der Quelltext ihrer JVM weitgehend online gestellt (OpenJDK) und auch Oracle pflegt dort brav weiter ihren Code ein (die betreiben ja auch OpenJDK). Das alles heißt aber nicht, dass jeder Java frei nutzen darf wie er will, wie Google erst kürzlich lernen musste:
    https://www.golem.de/news/java-rechtsstreit-oracle-geht-offiziell-weiter-gegen-google-vor-1610-124123.html

    Also vermisch' hier nicht Äpfel und Birnen zu Obstsalat. Weder eine Standardisierung noch irgend ein offener Quelltext hebelt Urheberrecht, Patentrecht oder Markenrecht aus.

    Und mono ist nur von Microsoft "geduldet" und sitzt in genau der gleichen rechtlichen Grauzone wie wine (winehq.org) oder ReactOS (reactos.org), die auch nur von Microsoft "geduldet" werden. Dass sie das dulden heißt aber nicht, dass sie nicht rechtlich dagegen vorgehen könnten, sondern nur, dass sie es nicht wollen, weil das eine langjährige Geschichte wäre, der Aufwand im keinen Verhältnis zum Ergebnis stünde (wo schaden diese Projekte MS denn groß?) und es dort auch nirgendwo etwas finanziell zu holen gibt (da ist niemand, denn du auf Mio Schadensersatz verklagen könnte bzw. selbst wenn, könnte er das eh nie zahlen). Aber Apple ist da eine ganz andere Geschichte, denn Apple könnte MS natürlich massiv schaden und bei Apple gibt es jede Menge zu holen.

    /Mecki

  17. Re: Na hoffentlich...

    Autor: Bigfoo29 10.02.17 - 17:37

    ...die Dir keiner geben kann, weil es keine Statistiken darüber gibt, welcher Hersteller für welches Betriebssystem exklusiv entwickelt.

    Wenn man Dir böses unterstellen wöllte, könnte man sagen,dass Du das sehr genau weißt und deshalb bewusst auf nicht belegbare Fakten pochst. (Klassisches Element, wenn man in einer Diskussion widerlegt wurde. Nach Details und Beweisen fragen, die das Gesprächsgegenüber schon menschlich/technisch nicht liefern kann.) ;)

    Regards.

  18. Re: Na hoffentlich...

    Autor: /mecki78 14.02.17 - 14:59

    ffx2010 schrieb:
    --------------------------------------------------------------------------------
    > Ja genau, dass sie nicht auf Vulkan setzen.
    > Metal wird keine Sau interessieren.

    Get your facts straight!

    Apple hat Mitte 2014 Metal vorgestellt, als fertige API. D.h. sie müssen bereits 2013 daran gearbeitet haben. Da so eine API einiges an Planung braucht, haben sie wahrscheinlich schon 2012 mit der Planung angefangen.

    Die Idee von Vulkan ist aber selber erst überhaupt in 2014 entstanden, der Entschluss so eine API zu schaffen wurde dann erst auf der GDC 2015 der Öffentlichkeit präsentiert (bis dahin hätte das Projekt auch jederzeit wieder sterben können) und erst seit Anfang 2016 gibt es eine finale 1.0 Spezifikation.

    Wie hätte Apple 2014 auf eine nicht existente API setzen sollen, von der bis Mitte 2015 nicht einmal fest stand, dass es sie jemals geben wird? Und erwartest du ernsthaft, dass Apple ein Projekt, in das mindestens 2 Jahre Planung und Entwicklung geflossen sind, das man bis zum Ende durchgezogen und final implementiert hat und das sogar schon von Betriebssystem selber und externen Entwicklern aktiv genutzt wird, einfach so wieder einstampft, nur weil ein Jahr später die Khronos Group aus ihrem tiefen Winterschlaf erwacht ist und angekündigt, dass sie vor hat jetzt (endlich) auch so eine ähnliche API schaffen zu wollen, ohne dabei einen konkreten Release Termin zu nennen, ja? In welcher alternativen Realität lebst du gleich nochmal?

    /Mecki

Neues Thema Ansicht wechseln


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

Anzeige
Stellenmarkt
  1. Hochschule Esslingen, Esslingen
  2. über Mentis International Human Resources GmbH, Bayern
  3. rhenag Rheinische Energie Aktiengesellschaft, Siegburg
  4. Hella Gutmann Solutions GmbH, Ihringen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 10,99€
  2. 57,99€/69,99€ (Vorbesteller-Preisgarantie)
  3. (u. a. Dark Souls II 9,99€, Dark Souls III 19,99€ und Project CARS 8,99€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Creoqode 2048 im Test: Wir programmieren die größte portable Spielkonsole der Welt
Creoqode 2048 im Test
Wir programmieren die größte portable Spielkonsole der Welt
  1. Arduino 101 Intel stellt auch das letzte Bastler-Board ein
  2. 1Sheeld für Arduino angetestet Sensor-Platine hat keine Sensoren und liefert doch Daten
  3. Calliope Mini im Test Neuland lernt programmieren

Anker Powercore+ 26800 PD im Test: Die Powerbank für (fast) alles
Anker Powercore+ 26800 PD im Test
Die Powerbank für (fast) alles
  1. SW271 Benq bringt HDR-Display mit 10-Bit-Panel
  2. Toshiba Teures Thunderbolt-3-Dock mit VGA-Anschluss
  3. Asus Das Zenbook Flip S ist 10,9 mm flach

Microsoft Surface Pro im Test: Dieses Tablet kann lange
Microsoft Surface Pro im Test
Dieses Tablet kann lange
  1. Surface Diagnostic Toolkit Surface-Tool kommt in den Windows Store
  2. Microsoft Lautloses Surface Pro hält länger durch und bekommt LTE
  3. Microsoft Surface Laptop Vollwertiges Notebook mit eingeschränktem Windows

  1. Ipod Touch günstiger: iPod Nano und iPod Shuffle eingestellt
    Ipod Touch günstiger
    iPod Nano und iPod Shuffle eingestellt

    Apple hat den Verkauf der Musikplayer iPod Nano und iPod Shuffle eingestellt. Im Onlineshop werden die Geräte nicht mehr gelistet, andernorts gibt es noch Restbestände. Der iPod Touch wird günstiger verkauft.

  2. Nissan Leaf: Geringer Reichweitenverlust durch alternden Akku
    Nissan Leaf
    Geringer Reichweitenverlust durch alternden Akku

    Der Nissan Leaf ist vom ADAC fünf Jahre lang getestet und dabei 80.000 Kilometer gefahren worden. Das Elektroauto kam fabrikneu auf eine Reichweite von 105 Kilometern. Nun sind es 93 Kilometer geworden.

  3. Quartalsbericht: Amazons Gewinn bricht ein
    Quartalsbericht
    Amazons Gewinn bricht ein

    Amazons Gewinn ist um 77 Prozent zurückgegangen. Der Konzern hat erneut viel investiert. Jeff Bezos ist nur kurz der reichste Mann der Welt gewesen.


  1. 07:23

  2. 07:13

  3. 22:47

  4. 18:56

  5. 17:35

  6. 16:44

  7. 16:27

  8. 15:00