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

[foo_1337]

Ist halt eher schwierig sich dagegen zu weigern, wenn man Kontakt zu vielen anderen Unternehmen hat. Früher oder später ist einer dabei, mit dem es ausschließlich via Zoom funktioniert. Insbesondere wenn das Unternehmen nicht aus D ist.

 

[KitKat::new()]

Früher oder später ist einer dabei, mit dem es ausschließlich via Zoom funktioniert.

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

 

[foo_1337]

Mit Kunden fängt man keine Diskussionen an. Da richtet man sich eher nachdem, was die nutzen, insbesondere wenn keine Techies dabei sind. Dazu kommt, dass auch diese gewisse Compliance Vorgaben haben. Und du weißt ja wie es ist: Wenn auf dem Papier steht, dass es sicher ist, dann wird das schon so sein. Und diesen Nachweis hast du für deine self hosted jitsi Alternative nicht (wobei ja mittlerweile immerhin e2ee geht).
Abgesehen davon war zu der Zeit, als wir jitsi evaluiert haben (Weil Teams damals noch das maximum von 4 sichtbaren Teilnehmern hatte), performanceseitig eine einzige Katastrophe war. Das mag sich aber mittlerweile geändert haben. Und grundsätzlich sind oss Alternativen auch nicht frei von Katastrophen, siehe z.B. BBB:
https://github.com/bigbluebutton/bigbluebutton/issues/8951
Sowas ist fast schlimmer als das, was sich Zoom geleistet hat, denn das ist definitiv ein DSGVO Verstoß gewesen (außer man hätte explizit darauf hingewiesen) Und dann gammelt das Ding noch 5 Monate unbearbeitet rum.

 

[konkretor]

Seit Zoom E2E integriert hat nutze ich es gerne

 

[foo_1337]

@konkretor so ist es... gibt viele, die über die privacy bei zoom schimpfen, aber dann teams nutzen. Dabei gibt es da kein e2ee.

 

[Floxxwhite]

Hast du da Quellen für, wie viel Geld da fließt? Bin da sehr dran interessiert.

Naja weiss ja jeder das Apple die kauflaunigere Kundschaft hat. Bei MS war jedem klar das dieses halb herzige ARM Support scheitert. Bei Apple bekommt man fast eine sichere Zusage, dass es langfristig das einzige übrig bleibt.

Das Apple bestimmt super einfache SDK etc. zur Verfügung stellt hilft auch. Und wahrscheinlich werden Sie auch was subventionieren. Und warum sollten sie auch nicht?

 

[Cool Master]

Und warum sollten sie auch nicht?

Warum sollten sie? Es ist eher das Gegenteil der Fall. Die Entwickler müssen 99 € im Jahr zahlen.

 

[Floxxwhite]

Warum sollten sie? Es ist eher das Gegenteil der Fall. Die Entwickler müssen 99 € im Jahr zahlen.

Aus dem selben Grund wie Nvidia und AMD Entwicklern unter die Arme greifen. Um der eigenen Plattform unter die Arme zugreifen. Sie kommen den Entwicklern mit den Appstore Verkäufen auch mehr entgegen.

Ob's jetzt mit Zoom ein Agreement gibt schwer zu sagen. Apple und Zoom passen halt super zusammen in der USA von der Ausbreitung.

Bei den anderen kann ich mir das gut vorstellen. Genauso wie Google halt Apple für die suchmaschine zahlt.

Wie gesagt scheint sich bei Apple ARM für die Entwickler einfach mehr zu lohnen als bei MS. Mit "wollen" aus Nettigkeit hat das denke ich wenig zu tun.

 

[foo_1337]

Apple hat es nicht nötig, Unternehmen/Entwicket dafür zu bezahlen. Das wäre vielleicht vor 15 Jahren eine Option gewesen, aber mittlerweile nicht mehr. Wenn zoom unter m1 Macs nicht performen würde, wechselt man halt die Plattform. Ein Videokonferenzanbieter ist schneller gewechselt als die Clients im Unternehmen. In den USA hat macOS einen Martktanteil von 27%, Tendenz steigend.
Dazu kommt eben, dass Apple den Entwicklern das Bereitstellen von universal binaries deutlich einfacher macht als z.B. Microsoft. Auch wenn vor einigen Jahren mal jemand auf der Bühne "Developers! Developers! Developers!" gebrüllt hat.


We are excited to announce that starting today we are releasing new versions of many of our Microsoft 365 for Mac apps that run natively on Macs with M1. This means that now our core flagship Office apps—Outlook, Word, Excel, PowerPoint, and OneNote—will run faster and take full advantage of the performance improvements on new Macs, making you even more productive on the latest MacBook Air, 13-inch MacBook Pro, and Mac mini. The new Office apps are Universal, so they will continue to run great on Macs with Intel processors. The apps are not only speedy, but they also look fantastic as they have been redesigned to match the new look of macOS Big Sur. Here is a peek at Outlook on the new 13-inch MacBook Pro.

https://www.microsoft.com/en-us/mic...65-is-improving-the-experience-for-mac-users/

Denkst du ernsthaft, dass Apple Microsoft hierfür bezahlt hat? Microsoft weiß genau, wie wichtig eine gute UX für Mac User ist und macht dementsprechend viel dafür. Auch wenn manches noch ausbaufähig ist. Unter Windows kriegt man hingegen nichtmal das Control Panel auf die Kette.

 

[KitKat::new()]

Dazu kommt eben, dass Apple den Entwicklern das Bereitstellen von universal binaries deutlich einfacher macht als z.B. Microsoft.

Inwiefern?

 

[foo_1337]

Inwiefern?

Dir sind doch sicher die Einschränkungen von UWP Apps bekannt?

 

[KitKat::new()]

Was hat UWP (Appmodel) mit universal binaries (CPU-Architektur) zu tun?

 

[foo_1337]

Ich kenne außer der UWP Krücke kein Äquivalent zu den macos universal binaries. So etwas würde es den Entwicklern jedoch deutlich einfacher machen. Dazu kommt, dass es nach wie vor kein vs für arm gibt und man auf das remote Debugging angewiesen ist. Immerhin haben sie es dieses Jahr auf die Reihe bekommen, vscode für arm windows zu veröffentlichen. Während Apple nach direkt nach WWDC Worte zu Taten machte, behandelt Microsoft das Thema eben weniger als Halbherzig. Und da soll es jemanden wundern, dass weder die User die Geräte kaufen noch die Entwickler groß Interesse zeigen, Software dafür zu entwickeln? Vermutlich haben genau aus dem selben Grund die eigenen Entwickler auch eher lange Entwicklungszyklen. Teams für arm64 kam erst 1 Jahr(!) als stabile Variante nach Veröffentlichung des Surface X.

 

[GregoryH]

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

Jitsi funktioniert lange nicht so stabil und zuverlässig wie ZOOM. Wir haben in der Klinik beides und 99.9% aller Konferenzen laufen jetzt über Zoom.

 

[KitKat::new()]

Ich kenne außer der UWP Krücke

Was daran ist eine Krücke?
Ich verstehe immer noch nicht inwiefern universal binaries (Architekturkonzept) damit (Appmodel/OS-API) überhaupt vergleichbar sind?

Mir wäre neu, dass Apple überhaupt irgendwas ähnliches zu UWP im Petto hätte. Apple macht es einem dadurch unmöglich UWP-Apps zu schreiben.

Und da soll es jemanden wundern, dass weder die User die Geräte kaufen noch die Entwickler groß Interesse zeigen, Software dafür zu entwickeln?

Ich wunder mich was so schwer daran wäre, dass man nicht einfach ARM als Buildoption hinzufügt - geht immerhin in Visual Studio sehr einfach.
Das ist nämlich alles was man (ohne architekturspezifische Optimierungen) machen muss, um eine ARM App zu bekommen.

 

[Miuwa]

Ich wunder mich was so schwer daran wäre, dass man nicht einfach ARM als Buildoption hinzufügt - geht immerhin in Visual Studio sehr einfach.
Das ist nämlich alles was man (ohne architekturspezifische Optimierungen) machen muss, um eine ARM App zu bekommen.

Bin da nicht up to date: Bietet Windows for ARM die vollständige Win32 API?

Ergänzung (21. Dezember 2020)

Also für Native Arm Apps, nicht nur für die emulierte x86 Umgebung.

 

[foo_1337]

Das ist nämlich alles was man (ohne architekturspezifische Optimierungen) machen muss, um eine ARM App zu bekommen.

Dann stelle ich mal die ketzerische Frage, wieso es dann fast keiner auf die Reihe bekommt, seine Apps für Windows on ARM bereitzustellen. Selbst MS lässt seine Surface X Käufer 1 Jahr mit einer total verbuggten Teams x32 Emulation arbeiten.
Vermutlich (ich habe hier keine Fakten) liegt es an irgendwelchen Libs, welche teilweise Uralt sind und neugeschrieben werden müssen, weil sie entweder nur als Runtime vorliegen oder der Quellcode unter modernen Bedingungen nicht mehr compiliert. Aber das ist wie gesagt nur Guesswork, ich habe mit Windows Applikationsentwicklung nichts am Hut.
Apple hingegen zwingt durch harte Deprecations schon seit vielen Jahren die Entwickler am Ball zu bleiben. Und das scheint sich auszubezahlen. Selbst Adobe hat das damals vergleichweise schnell mit Carbon -> Cocoa durchgezogen, obwohl das wahrlich ein Mammutprojekt war. Und warum? Weil Carbon deprecated wurde. MS hingegen schleppt fast alles mit und die Entwickler ruhen sich eben aus. Das scheint sich nun zu rächen.

Was daran ist eine Krücke?
Ich verstehe immer noch nicht inwiefern universal binaries (Architekturkonzept) damit (Appmodel/OS-API) überhaupt vergleichbar sind?

Ich spreche hier aus Nutzersicht:
Apple User: Downloaded sich die App aus dem Store oder via Browser. In letzterem Fall doppelklickt er das DMG und zieht die App nach /Applications. Er muss nichtmal wissen, welche CPU er hat.
Windows User: UWP App oder er muss wissen, welche Architektur er hat. Und da scheitert es schon bei vielen. Wenn man Glück hat, hat der Webseitenbetreiber nachgedacht und gibt anhand des Browsers die richtige Version mit. Aber intuitiv ist das nicht.

Mir wäre neu, dass Apple überhaupt irgendwas ähnliches zu UWP im Petto hätte. Apple macht es einem dadurch unmöglich UWP-Apps zu schreiben.

Die Möglichkeit hat man nun geschaffen, indem man iOS Apps direkt unter dem arm macOS starten kann. Und das funktioniert ganz plötzlich für (fast) alle iOS Apps.
Wie es mit UWP hingegen weitergeht, weiß man wohl noch nicht so genau.
https://www.thurrott.com/dev/206351/microsoft-confirms-uwp-is-not-the-future-of-windows-apps

 

[Miuwa]

Um meine eigene Frage von vorher zu beantworten:

Es sieht so aus, als ob fast die ganze Win32 API auch unser Windows 10 for ARM zur Verfügung steht:

https://github.com/notepad-plus-plus/notepad-plus-plus/issues/5158

Es ist echt schwer dazu Informationen zu googeln, weil fast immer nur von UWP, oder der x86 Emulation oder Windows RT die Rede ist, aber fast nie von win32 Apps die für Arm64 kompiliert werden.

Ergänzung (22. Dezember 2020)

Windows User: UWP App oder er muss wissen, welche Architektur er hat.

Meinst du nicht, dass jemand, der sich ein Tablett mit Windows 10 for ARM kauft, weiß welche Architektur er hat?

 

[foo_1337]

Meinst du nicht, dass jemand, der sich ein Tablett mit Windows 10 for ARM kauft, weiß welche Architektur er hat?

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

 

[KitKat::new()]

Dann stelle ich mal die ketzerische Frage, wieso es dann fast keiner auf die Reihe bekommt, seine Apps für Windows on ARM bereitzustellen.

Es gibt keinen Druck.

(ich habe hier keine Fakten)

scheint so

Das scheint sich nun zu rächen.

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

Die Möglichkeit hat man nun geschaffen, indem man iOS Apps direkt unter dem arm macOS starten kann. Und das funktioniert ganz plötzlich für (fast) alle iOS Apps.

Das ist was anderes. Man hat von zwei Architekturen eine gekilled und zwingt die Entwickler nur noch für eine Architektur zu entwickeln.
UWP vereint tatsächlich eine Vielzahl von Gerätetypen/Plattformen (auch unabhängig von der Architektur):

Universal Windows apps that are created using the UWP no longer indicate having been written for a specific OS in their manifest build; instead, they target one or more device families, such as a PC, smartphone, tablet, or Xbox One, using Universal Windows Platform Bridges. These extensions allow the app to automatically utilize the capabilities that are available to the particular device it is currently running on.[16] A universal app may run on either a mobile phone or a tablet and provide suitable experiences on each.

Windows User: UWP App oder er muss wissen, welche Architektur er hat. Und da scheitert es schon bei vielen.

Was hat das schon wieder mit UWP zu tun?
Als Windows-Nutzer ist wirklich jeder schon mit x86-64 vs x86 konfrontiert worden.

Wenn man Glück hat, hat der Webseitenbetreiber nachgedacht und gibt anhand des Browsers die richtige Version mit. Aber intuitiv ist das nicht.

Wenn man Glück hat, schiebt der Entwickler die App in den Store.
Was ist am detektieren der richtigen Version für den Nutzer unintuitiv?

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)
Aber selbst ohne dem Tool, wird es einem doch nicht schwer gemacht ARM zu supporten. Es ist nur eine
weiterere Buildvariante.

Wie es mit UWP hingegen weitergeht, weiß man wohl noch nicht so genau.

Fehlerhafte Interpretation durch den Autor.
Man hat lediglich die Strategie geändert und Win32/UWP jeweils nicht exklusiv gemacht, damit ein leichter UWP Support da ist.
Microsoft hat das auch klar so kommuniziert (siehe Entwicklerkonferenzen).