Notiz Zoom für Apple Silicon: Videokonferenz-App läuft nativ auf M1-Prozessor

[Miuwa]

Frag doch mal in deiner Familie, ob in deren PCs, Smartphones und Tablets ein x86, x86-64, ARM32 oder ARM64 Prozessor ist.

Keiner von denen hat ein Windows ARM Tablett und ich bin mir ziemlich sicher, dass man sich sowas nicht aus Versehen kauft, sondern sich bewusst dafür entscheidet.

 

[foo_1337]

Glaube ich nicht. So lasch wie die ARM angehen, scheinen sie da nicht viel zu bedauern.

Immerhin planen sie jetzt auch eine "eigene" CPU. Wenngleich der Fokus für diese eher bei Azure liegen dürfte.

Das ist was anderes. Man hat von zwei Architekturen eine gekilled und zwingt die Entwickler nur noch für eine Architektur zu entwickeln.

Das Ganze wird sich noch über viele Jahre ziehen. Und so macht man den Entwicklern und den Usern die Transitionsphase so einfach wie möglich.

Als Windows-Nutzer ist wirklich jeder schon mit x86-64 vs x86 konfrontiert worden.

Und selbst das sorgt noch für viele Fragezeichen in den Köpfen

Will man doch eine universalen Installer haben (gesehen habe ich das noch nie - scheint der Bedarf zu fehlen), kann man ja Tools wie folgendes nutzen: sjmulder/fatpack: Build multi-architecture 'fat' binaries for Windows. (github.com)

Installer sind sowas von 90er. Schade, dass das in der Windows Welt nach wie vor so verbreitet ist.

Zum Druck: Microsoft hat bzgl. der M1 Macs auch keinen Druck. Die absolute Mehrheit auf dem Markt sind Intel Macs. Trotzdem haben sie es geschafft, innerhalb recht kurzer Zeit Teams UND office als universal zu veröffentlichen. Für ihr eigenes Surface haben sie für Teams 1 Jahr gebraucht. Wie lange wird dann Office benötigen? Aktuell ist das ja CHPE.

Ergänzung (22. Dezember 2020)

Keiner von denen hat ein Windows ARM Tablett und ich bin mir ziemlich sicher, dass man sich sowas nicht aus Versehen kauft.

Ja? https://www.amazon.de/Microsoft-Surface-Zoll-Tablet-Home/dp/B07Y2DKNJC
"Microsoft Surface Pro X, 13 Zoll 2-in-1 Tablet (Microsoft SQ1, 8 GB RAM, 128 GB SSD, Win 10 Home)"
Liest sich ja schonmal vielversprechend. Kein Laie weiß, was Microsoft SQ1 bedeutet. Nun haben wir bei Amazon noch eine Besonderheit, falls jemand doch mehr Details lesen möchte:

Wenn man dann so durch die Bewertungen scrollt, gibt es dann doch schon recht viele enttäuschte Nutzer, die das wohl nicht kommen sehen haben.
Aus dem Microsoft Werbetext, den man z.B. bei NBB sehen kann:

Ja, da steht Funktionen, aber der Laie geht davon aus, dass das ein normales Windows 10 ist, mit Touchscreen eben. Sowas wie seine Kollegen vielleicht in Form eines x86 Surface haben und keine Kompatibilitätsprobleme haben.

 

[KitKat::new()]

Das Ganze wird sich noch über viele Jahre ziehen. Und so macht man den Entwicklern und den Usern die Transitionsphase so einfach wie möglich.

Keine Transitionsphase ist noch einfacher, insbesondere als Nutzer von z.B. Software, die nicht mehr weiterentwickelt wird (aus welchen Gründen auch immer).

Und selbst das sorgt noch für viele Fragezeichen in den Köpfen

Aber definitiv aber kein Hindernis eine ARM-Variante zu produzieren.

Zum Druck: Microsoft hat bzgl. der M1 Macs auch keinen Druck. Die absolute Mehrheit auf dem Markt sind Intel Macs. Trotzdem haben sie es geschafft, innerhalb recht kurzer Zeit Teams UND office als universal zu veröffentlichen.

MS hat beim M1 den gleichen Druck wie jeder andere App-Anbieter

 

[Miuwa]

@foo_1337 : keine Ahnung, was di mir dankt sagen willst. Ich Kern jedenfalls keinen, der sich IT Equipment für 1000 Euro kauft ohne sich davor zumindest ein bisschen zu informieren und beim Surface Pro X stößt man beim googeln sofort auf den ARM Aspekt.

Kennst du jemanden, der sich das X zugelegt hat und nicht weiß, dass es ein ARM Gerät ist? Ich mein, die Leute gibts sicher, aber ich kann mir einfach nicht vorstellen, dass das ein signifikanter Anteil ist, weshalb sich ein Entwickler Gedanken machen solle.

Schwerwiegender ist da vermutlich, dass die Windows ARM Kunden Keinen signifikanten Anteil am Windowsmarkt ausmachen und damit generell für Entwickler recht uninteressant sind.

 

[foo_1337]

Keine Transitionsphase ist noch einfacher, insbesondere als Nutzer von z.B. Software, die nicht mehr weiterentwickelt wird (aus welchen Gründen auch immer).

Dafür gibt es Rosetta, welche

MS hat beim M1 den gleichen Druck wie jeder andere App-Anbieter

genau diesen Druck nimmt. Denn im Gegensatz zu Teams via x86 Emulation performt Teams (und Office) via Rosetta sehr gut. Die native Beta von Office kam kurz nach dem Launch der M1 Macs. War es nicht vielleicht doch einfacher für MS einen Build für MacOS bereitszustellen als für Windows? Wenn sie einfach das Target in VS hätten wählen müssen, wäre das Release doch sicher viel schneller da gewesen.

Ergänzung (22. Dezember 2020)

Kennst du jemanden, der sich das X zugelegt hat und nicht weiß, dass es ein ARM Gerät ist?

Nein, persönlich kenne ich keinen, bzw. ich kenne keinen, der sich überhaupt eines gekauft hat. Aber zu Surface RT Zeiten schon. Und wenn du dir die Amazon Rezensionen durchliest, wirst du sehen, dass es davon noch mehr gibt. Ich weiß, es ist schwer sich da rein zu versetzen, aber es gibt Personen, die kaufen einfach, weil sie etwas in der Verkaufsannonce lesen und sich keine weiteren Gedanken darüber machen.
Aber anscheinend gelingt es mir nicht den Kern meiner Aussage rüber zu bringen: Egal ob kompletter Laie oder Poweruser, die macbooks erfüllen beides. Sowohl Hard- wie auch Softwaretechnisch. Deshalb wächst der Marktanteil auch immer mehr. Und deshalb kann sich Apple auch (zum dritten mal) einen Architekturwechsel erlauben, ohne dass die Nutzer davon groß was spüren. Knarzen wird es immer irgendwo, aber im großen und ganzen wird es gut laufen. In der Windows Welt sieht es halt ganz anders aus.
Auch unter Linux ist das kein großes Problem, das sieht man ja sehr gut in den Clouds oder beim Pi. Sobald du aber einen Windows Server von Intel/Epyc auf Gravitron umziehen wolltest, hört der Spaß auf. Selbst wenn es dafür ein AMI gäbe.
Und auch auf dem Desktop wäre es easy, weil fast alles als arm binary vorliegt.. weil das target einfach mitgebaut wird.

 

[KitKat::new()]

War es nicht vielleicht doch einfacher für MS einen Build für MacOS bereitszustellen als für Windows?

Beleg es doch mal statt mir immer Gegenbeweise abzuverlangen.

Hinweis: Electron gibt es seit einem Jahr für Arm for Windows 😀

genau diesen Druck nimmt.

gut, dann kann man ja auf eine Portierung verzichten.

 

[foo_1337]

Beleg es doch mal statt mir immer Gegenbeweise abzuverlangen.

Hinweis: Electron gibt es seit einem Jahr für Arm for Windows 😀

Ich verlange übrigens keine Gegenbeweise. Und ohne den Sourcecode zu haben oder Insights bei Microsoft, wird es eben schwierig.
Ich weiß, dass es eine Electron App ist. Aber es wird eben auch einiges an native Code mitgeliefert und eingebunden. Ein Grund, weshalb es auch Unterschiede zwischen dem Windows, macOS und Linux Teams Client gibt. Ähnlich wie du kein Java einfach verteilen kannst, wenn jni genutzt wird.

gut, dann kann man ja auf eine Portierung verzichten.

Nur weil es den Druck nimmt, heißt das nicht, dass man verzichten kann.

 

[KitKat::new()]

Nur weil es den Druck nimmt, heißt das nicht, dass man verzichten kann.

Könnte doch das Warum beantworten?
(Auch wenn ich "nicht verzichten können" als Druck bezeichnen würde)

Aber es wird eben auch einiges an native Code mitgeliefert und eingebunden.

Und das könnte ein Problem aus welchem konkreten Grund sein?

 

[foo_1337]

Und das könnte ein Problem aus welchem konkreten Grund sein?

Entweder hat dieser Code Abhängigkeiten beim Linken, die nicht aufgelöst werden können, weil es keine ARM Version gibt bzw. diese erstmal erstellt werden muss. Wenn diese dann noch 3rd Party ist und kein Source Code verfügbar, wird es noch interessanter. Das war damals auch die größte Herausforderung für Adobe bei der Carbon -> Cocoa Portierung ihrer Applikationen.
Oder es ist nativer Code, der zuerst umgeschrieben werden muss. Wird vor allem dann spaßig, wenn man von CPU Features gebrauch macht, die es auf der anderen Architektur nicht gibt.

 

[KitKat::new()]

Wenn diese dann noch 3rd Party ist und kein Source Code verfügbar, wird es noch interessanter. Das war damals auch die größte Herausforderung für Adobe bei der Carbon -> Cocoa Portierung ihrer Applikationen.

Organisatorischer Grund. Bei Abhängigkeiten ist man grundsätzlich abhängig.

Oder es ist nativer Code, der zuerst umgeschrieben werden muss. Wird vor allem dann spaßig, wenn man von CPU Features gebrauch macht, die es auf der anderen Architektur nicht gibt.

Das wäre auch bei Apple nicht vermeidbar.

 

[foo_1337]

Organisatorischer Grund. Bei Abhängigkeiten ist man grundsätzlich abhängig.

Sag das mal der node.js Fraktion
Im Prinzip ist das ja kein Problem, blöd ist es halt nur dann, wenn man sich von einer 3rd Party abhängig macht und nur die Runtime kauft. Dann steht man in so einem Fall vor einem Problem, insbesondere dann, wenn es die Firma nicht mehr gibt.

Das wäre auch bei Apple nicht vermeidbar.

Ja, das stimmt. Das wird auch bestimmt bei diversen Audio Produkten der Fall sein.

 

[m3rch3r]

Trotzdem nervig, wenn jetzt zu jedem beliebigen Programm extra gepostet wird, dass es jetzt auch aufm M1 nativ läuft. Bei den ersten wichtigen Programmen wars ja noch interessant, aber jetzt...

Vllt. würde es dich ja mehr interessieren, wenn du selbst mit Zoom arbeiten MÜSSTEST, wie momentan immer mehr Leute.

Da Zoom aktuell DIE Software für viele Home-Office-Gebundenen ist, 100% eine News wert, denn Apple Hardware ist im Business-Umfeld weit verbreitet und das wird in Zukunft auch noch weiter zunehmen, gemessen daran, wie performant Apple Silicon ist.

 

[Fyres]

Also ich bin gespannt, was da noch alles mit diesen ARM-basierten Prozessoren auf uns zu kommt. Apple hat ja dann doch den Vorteil einer durchaus großen und zahlungspotenten Userbase. Dadurch steigt auch schnell die Bereitschaft der Unternehmen, die Apps entsprechend anzupassen.

 

[sinkpäd]

Ich hatte eigentlich die Hoffnung, dass mein MBP 16" aus 2019 eine Rarität z.B. für x86-Entwickler wird, aber mit dem Tempo, das Apple die Softwarehersteller an den Tag legen, zweifle ich langsam dran

 

[Turrican101]

(Optional selbstgehostetes) Jitsi über den Browser funktioniert doch mit jedem.

Jitsi läuft mehr als schlecht. Wäre das nicht OS/umsonst würde das kein Mensch nutzen. Egal bei wem ich das bisher benutzt hab, auch selbstgehostet, selbst bei ner kleinen Anzahl Leute immer irgendwo matschiges Bild, mal hat jemand Standbild, Ton ist auch eher von 2005.
Dagegen gab es bei keiner einzigen Zoomkonferenz irgendwelche Probleme. Bei uns in der Firma sind wir genau deswegen auch von Jitsi weg.

 

[Suteki]

Microsoft lernt es einfach nicht.
Als sie den Store + UWP eingeführt haben, hätten dort alle MS Tools als UWP Variante verfügbar sein MÜSSEN. Wenn nicht mal der Hausherr des OS seine eigenen Tools damit zur Verfügung stellt, wieso sollten Entwickler dann Vertrauen zu der Plattform haben?
Mit den ARM Versionen scheint es dasselbe zu werden, sie veröffentlichen teilweise Tools, und das nicht mal auf ihrer eigenen Plattform zuerst.
So wie bei Windows Phone sehe ich da keine große Chance, weil sie es immer nur halbherzig angehen (bin immer noch traurig, dass sie das nicht auf die Kette bekommen haben. Fand das Konzept von Windows Phone super, schöne Bedienung und alles sehr flüssig selbst auf hardwareschwachen Geräten).
Ich musste gestern kurz lachen als sie bei den "Neuerungen" für den nächsten Windows 10 Build aufgelistet hatten, dass das Suchfeld in der Taskleiste nun den Darkmode unterstützt. Kann man als Anwender nicht erwarten, dass das ganze OS im Darkmode ist, wenn man diesen mit Tamtam angekündigt hat? Warum kommt das dunkle Suchfeld Jahre später?

 

[Cool Master]

Wenn nicht mal der Hausherr des OS seine eigenen Tools damit zur Verfügung stellt, wieso sollten Entwickler dann Vertrauen zu der Plattform haben?

Weil der Hausherr keine Ahnung hat. Das sieht man ja auch an Windows 10 welches keine echte klare Linie hat. Die alten UIs haben z.B. mehr Funktionen als die neuen. Dazu kommt, dass die neue UI deutlich schwerer zu navigieren ist.

Warum kommt das dunkle Suchfeld Jahre später?

Warum gibt es im Jahr 2020 noch keine Tabs im Explorer? Nur weil das OS Windows heißt muss ich nicht immer mehr Fenster haben als nötig wen es auch zwei Tabs tun würden. Aber wie gesagt MS kann keine Software. Die haben den Vorteil das einfach jeder Windows nutzt. Meiner Meinung nach wäre es auch mal angebracht 32 Bit aufzugeben und 64 Bit only zu machen, das würde sicherlich viele Bugs beheben.

 

[smalM]

Mit Kunden fängt man keine Diskussionen an.

Das ist in einem deutschen Forum schwer vermittelbar...

 

[Suteki]

Warum gibt es im Jahr 2020 noch keine Tabs im Explorer? Nur weil das OS Windows heißt muss ich nicht immer mehr Fenster haben als nötig wen es auch zwei Tabs tun würden.

Ja das stimmt. Wobei der Finder auch noch Potenzial nach oben hat.
Ich habe bei mir aktuell den Bug, dass sich dieser nach einem Neustart die zuvor eingestellte Größe nicht merkt. Der ist jedes mal winzig -.-.
Habe schon zwischen DP und HDMi gewechselt, Größe eingestellt und Fenster mit gedrückter alt Taste geschlossen usw. Das ist aber auch kein Big Sur Problem, im Netz findet man das bis mindestens 2008 zurück. Ich selbst hatte das auch schon mal mit Catalina und Yosemite. Eine Ursache konnte ich bisher nicht identifizieren, eine klare Lösung ebenfalls nicht. Hast du das schon mal gehabt?

Übrigens: Ich habe meinen 2018 Mac Mini verkauft und gegen den M1 getauscht. Da liegen gefühlt Welten zwischen. Super snappy die Kiste, egal was ich damit mache immer flüsterleise und die Komponenten sind deutlich kühler (SSD z.B. 29 Grad statt knapp 50) als beim Intel Mac. Bin super happy damit.

 

[foo_1337]

@Suteki find $HOME -name ".DS_Store" -exec rm {} \;
Sowas auf dem Handy zu tippen nervt echt