Hallo zusammen,

wir bekommen ab August Verstärkung und benötigen daher einen weiteren Arbeitsplatz im Bereich Mediengestaltung. Hier wurde bisher mit 27" iMacs gearbeitet. Dank Parallels war es auch kein Problem einige der zwingend erforderlichen x86 Windows Programme, welches es für kein anderes System gibt, zu verwenden. Am Ende eines jeden Arbeitstages haben die Intel iMac's einen belegten Arbeitsspeicher von ca. 90GB+.

Daher folgende Fragen:
Wie viel RAM wird bei ARM im Vergleich zu x86-x64 benötigt?
Wie ist jetzt der Stand der Dinge mit den M1 Macs und der Ausführung von Windows x86 Programmen?

Verwendet werden müssen das Adobe CC Paket, Final cut pro, Blender 2.79, Free CAD, Cura und eben einige Windows x86 Programme damit die Aufgaben erfüllt werden können.

Vorab vielen Dank für die Infos.

Ih habe einen Mac mini M1 mit 16GB RAM und einer 512 GB SSD. Darauf läuft Parallels 17 mit Win 11 für ARM völlig problemlos. Ich hatte Win 10 und konnte völlig problemfrei umwechseln und anschließend dann auch in Parallels auf Win 11 upgraden. Wie man Windows for ARM bekommt, wird ja an vielen Stellen beschrieben. "Normale" Windows-Programme laufen ohne Probleme. Einige ziemlich neue Spielen (z.B. Foundation und AoE 4), welche ja bei euch jetzt nicht anfallen, starten nicht wegen inkompatibler Grafikkarte.
ich denke, dass ihr mit einem Mac Studio und dem größten RAM-Ausbau gut hinkommen dürftet.

Das ist für einen handelsüblichen Mediengestalter völliger Overkill.

Das mit win auf den Macs geht zwar stand heute, da m$ aber schon erklärt hat das sie das nicht wollen stellt sich die Frage, wie sieht es mit der Planungssicherheit aus? Am Ende suchen und finden die eine Möglichkeit, auch bestehende Installationen auf nicht freigegebener Hardware zu stoppen, und schon steht ihr blöd da.
Eine Möglichkeit wäre zu prüfen, ob eure Programme auch unter Crossover laufen, eine andere noch schnell (mancher Händler hat eventuell noch welche) einen intel iMac anzuschaffen.
Nachtrag: Blender ist inzwischen bei Version 3.1 mit deutlich verbesserter Unterstützung für Macs, zumindest wenn ihr bereits auf Monterey arbeitet.

Ich wüsste nicht, warum ein Mac mit M1-Prozessor anders/mehr/weniger RAM verbrauchen sollte, als ein Mac mit Intel-CPU.
Die Angabe bzgl. 90+ GB RAM ist relativ, denn das was da ist, nimmt sich das System. Wenn detaillierte Infos abgegeben werden, mit welchen Dateien gearbeitet wird, kann zum RAM sicher eine Aussage getroffen werden.
Sicher läuft Windows on ARM via Parallels. Aber nur weil es geht, ist es trotzdem von niemandem supportet und fällt m.E. in die Kategorie „Bastelei“.
Ab einer gewissen Anzahl an Arbeitsplätzen macht es Sinn, z.b. Windows Server mit Terminalservices zu installieren und sich von den Macs aus via RDP zu verbinden. Natürlich nur, wenn die benötigten Programme damit zurechtkommen. Das kann locker auf einem Synology-NAS laufen.

Wenn du zwingend Windows benötigst musst du dich von einem Mac verabschieden. Das immer wieder zitierte Windows 11 über Parallels ist ein AR Windows. Darauf können nicht alle Windows Programme ausgeführt werden. Es soll eine Emulation von x86 auf ARM Windows geben, ich weiss aber nicht ob die das Beta Stadium schon verlassen hat. Die Performance wird aber grottenschlecht sein. Das wird auch ein schneller Mac nicht kompensieren können. Rechtlich befindet man sich zumindest in einer Grauzone da Microsoft ARM Windows nicht für Apple lizenziert hat.
Arbeitet man professionell heisst es Finger weg von solchen Experiment.
Entweder zweigleisig fahren, das kann durchaus seine Vorteile haben, oder sich vom Mac verabschieden.

Was sind das denn für Programme und was sind das für Aufgaben?
Was sich in meinem Bekanntenkreis als guter Workaround für das x86-Problem erwiesen hat ist einen miniPC () für die x86-Programme anzuschaffen. Das Ding wird dann "versteckt", läuft headless und es wird per Remote-Desktop darauf zugegriffen.

Es kommt dabei natürlich auf die Programme an, auf die man angewiesen ist. Hier war es so, dass sämtlichen Arbeiten nun von bzw. auf einem iPad Pro erledigt werden und auf Windows wird nur noch per RemoteDesktop zurückgegriffen … das ganze funktioniert sogar weltweit via VPN.

Das ging schnell mit den Rückmeldungen!

Zu Blender, wir verwenden deshalb die Version 2.79 da wir Jahre lange Projekte mit Blender Render erstellt haben diese sich nicht ohne weiteres in die neuen Render konvertieren lassen. Der Aufwand loht sich nicht und bis diese Projekte nicht mehr verwendet werden müssen vergehen noch ein paar Jahre. Könnte man aber notfalls auch darauf verzichten zugunsten des M1 und über RDP lösen.

Zum RAM, hatte ich vermutet. Wenn also zahlreiche hochauflösende Bilder und Videos bearbeitet wurden, dazu noch CAD und 3D Druck sieht es am Ende des Tages genauso aus wie bei den Intel Macs. Alternative, die Programme ständig schließen und bei Bedarf wieder öffnen.

Windows ARM scheint wirklich zu experimentell für den gewerblichen Einsatz. Hier werde ich dann wohl den Weg über RDP gehen müssen, einen der Server entsprechend konfigurieren und mit einer GPU bestücken, x16 Riser Kabel lässt grüßen. Sofern der Test erfolgreich verläuft, kann ja mit dem Remote Desktop client für Mac gut gearbeitet werden, verwende ich schon länger und funktioniert gut.

Schön war die Zeit mit Parallels im Coherencemodus......

Danke schon mal, da fällt die Wahl dann also auf einen Mac mit mindestens 64GB RAM.

Wozu MiniPCs anschaffen, wenn alte Intel-Macs zur Verfügung stehen? Auf den alten Macs kann Windows laufen und per RemoteDesktop von den ARM-Macs genutzt werden.
Ich habe mir für Windows aber tatsächlich einen gebrauchten MiniPC gekauft, bei dem ich das so mache.

Wir nutzen für unsere Warenwirtschaft auch Windows VM´s die auf nem Server laufen.
Über M1 mit Remote Desktop KEIN Problem. Und der Server ist uralt

Update: MacBook Pro 16" M1 Max 64GB 2TB ist bestellt.

Werde das MacBook natürlich erstmal ausgiebig testen, bin gespannt wie es sich im ganz normalen Alltag im Vergleich zum MacPro 2019 28C / 384GB / 4TB / W5700X schlägt und wo die Stärken und Schwächen liegen.

Klar wäre der Vergleich mit dem Studio in Vollausbau besser geeignet aber bis auf Rendern müsste der M1 Max mindestens gleichwertig sein.

Von wieviel? Die Aussagekraft dieses Wertes ist bei Null, da ein gutes Betriebssystem den Speicher nicht durch "Leerlassen" verschwendet. Da 90 keine Zweierpotenz ist, liegt aber der Verdacht nahe, dass Ihr im Moment zu viel Speicher habt, also ihn das System gar nicht füllen konnte.

Mehr Aussagekraft hätte die Größe des belegten Auslagerungsspeichers.

Bei Nutzung der gleichen Programme die gleiche Menge.

Hallo zusammen,
Ich habe mir 12.2021 einMacBook Pro mit M1Max 32GB RAM zugelegt. Weil auch ich Windows für den Windows SAP GUI brauche und noch eine Parallels-Lizenz von meinen MacBook Pro mit i9 hatte, habe ich halt Parallels installiert. Bein ersten Start von Parallels bot mir der Dialog an eine Windows 11 für ARM runter zu laden und zu installieren. Ich war echt erstaunt, und neugierig!
Nach dem die Installation problemlos lief und Windows 11 startete, Updates problemlos einliefen und der SAP GUI 7.70 sowie drei verschiedene VPN-Clients installiert waren und auch tun, habe ich mir eine Windows 10 Lizenz gekauft. Danach habe ich Office 356 und Teams installiert. Inzwischen ist die Container Datei etwa 38GB groß. Jeden Morgen, vor der Arbeit, macht Parallels ein Snapshot.
Inzwischen sind bestimmt drei oder vier weitere Updates eingelaufen. Alles läuft Super.
Ach auch eine Reisekosten Software aus 2015 - läuft.
Die VM bekommt 8GB RAM und 4 CPU-Kerne. Man will Windumm ja noch überfordern 😀
Viel Grüße
Meinolf

Die Performance von emulierten Intel-Win-Apps auf ARM-Win in einer VM auf M1-Macs unter macOS ist IMHO für sehr viele Programme mehr als völlig ausreichend. Warum sollten die Programmierer bei Microsoft eine solche Emulation nicht hinbekommen, wenn Apple es mit Rosetta2 praktisch problemlos schafft? Es kommt halt wie immer drauf an. Neuere Windows-Software wird eher laufen, ältere eher nicht, hardware-naher Assembler nicht, auf Frameworks-basierende Business-Anwendung eher ja.

Dass es Windows on ARM nicht offiziell für den Mac gibt, liegt an einem Abkommen zwischen MS und Qualcomm. Windows on ARM wurde erstmals 2016 angekündigt, den Aufwand für die Entwicklung eines Chips ließ sich Qualcomm dadurch vergolden. Nach allen Gerüchten läuft das Abkommen dieses Jahr aus. Interessant dazu ist der Artikel von XDA Developers .
Ich glaube nicht, dass MS 6 Jahre lang viel Geld und Ressourcen in ein OS steckt und das dann nur einem Anbieter zur Verfügung stellt. Der Trend geht nicht nur bei Laptops Richtung ARM (der schnellste Supercomputer Fugaku nutzt einen A64FX-Prozessor mit 48 ARM-Kernen, 15% aller Server nutzten im letzten Jahr ARM Chips ). MS würde sich selber ins Knie schießen, wenn sie WinOnARM nicht langsam für alle ARM-Plattformen offiziell anbieten würden. Und nach allem, was man so hört, scheint WinOnARM bereits jetzt hervorragend auf Macs zu laufen (hier ein Bericht von ZDnet ).

Aber das ist alles nicht offiziell, daher Stand heute finde ich den o.g. Vorschlag mit einem Windows-Server und Zugriff und Remote Desktop immer noch am praktikabelsten.

Wie es mit Windows on ARM und Intel weitergeht wird man sehen. Nutzt einem aber alles nichts, wenn jetzt eine Lösung benötigt.

Selbst wenn Microsoft heute verkündet man würde ARM voll unterstützen und lizenzieren braucht es Jahre bis der grösste Teil der Software sortiert ist.

Zudem bezweifle ich, dass Microsoft ein Interesse daran hat zwei Prozessorplattformen zu unterstützen. Das kostet nur Geld und Ressourcen die man anderswo besser einsetzen kann.

Genau das machen sie doch längst. Wer hat denn in eins dieser surface-Dinger einen ARM-Prozessor eingebaut? Und wenn nächstes Jahr (oder so) von Qualcomm und Samsung tatsächlich wie angekündigt die ersten Laptops mit ARM kommen, dann nimmt der Druck weiter zu. Zumindest mittelfristig wird ihnen gar nichts anderes übrig bleiben als zweigleisig zu fahren.

Die Firmen, die ARM Server verwenden, brauchen kein MS Windows. Ob und wann MS Windows auf ARM portiert, ist für die Cloud Anbieter relativ egal, da auch die Masse an x86-Server nicht mit Windows betrieben wird. Selbst MS gibt an, dass 70% der Server in der Azure Cloud mit Linux betrieben werden, und bietet z.B. MS SQL schon länger für Linux an. Großteile des MS Softwarestacks sind bereits auf Linux portiert, d.h. man kann Server Applikationen relativ simpel auf Linux portieren. Anders sieht das für Desktop Anwendungen aus, aber früher gab es einmal WinCE auch für ARM und was hatte das für Auswirkungen auf eine ARM Version von Windows? Exakt keine.

Man sollte auch nicht vergessen, dass es einmal Windows für PowerPC, MIPS, Alpha und Itanium gab. Die Betonung liegt auf gab.

Wenn es größere Ansprüche an die Grafik gibt, sind die Lösungen von Teradici ggf. eine Lösung.

Hallo nochmals,
Nach meiner Installation Windows 11 ob ARM war ich erstaunt wieviel Windows Programme nativ in ARM verfügbar sind. Sie sind sogar via Microsoft Store herunter ladbar und installierbar.
Und um die Performance, da würde ich mir gar nicht soooo die Gedanken machen. Wenn selbst bei so schlecht implementierten Programmen wie Teams oder Office die Performance auf meinen M1Max besser ist als auf dem Original Windows Rechner meiner Frau!!!
Und ob oder wie lang M$ ARM unterstützt ist mir nicht wichtig. Jetzt tut es, das ist wichtig. Und 10 Jahre in die Zukunft kann eh keiner überblicken.
Meinolf

Da gibt es schon ein wenig Unterschied.
1. Am auffälligsten wird Shared-Memory der GPU sein. Bei Intel-Macs wird für das Aufgabengebiet sicher die "diskrete" GPU benutzt, die ein eigenes RAM hat, je nach Karte sind das einige GB. Bei M1 gibt es (noch) keine diskrete GPU und es wird immer "Unified Memory" benutzt. Das können dann aber eben ein paar GB sein und ist nicht einmal vorhersehbar (da es sich dynamisch ändert). Also sollte ein M1 Mac - damit er im gewerblichen Umfeld vergleichbar ist, soviel RAM haben, wie der Vorgänger RAM und Video-RAM haben. (OK, bei shared Memory wird auch ein wenig gespart, weil manche Daten nicht in RAM und GPU-RAM doppelt gespeichert werden. Aber man muss eben vom Gesamtspeicher des M1 den Videospeicher abziehen.)
Für mich als Entwickler ist das hingegen unkritisch, da ich keine grafiklastigen Programme entwickle.

2. Eher ein Detail ist die "hw.pagesize: 16384" ("sysctl hw" im Terminal ausführen)
Immer wenn Speicher alloziert wird, dann wird im virtuellen Speicher ein Vielfaches einer VM-PageSize reserviert (also auf eine volle VM Page aufgerundet). Bei Intel lag die "hw.pagesize" bei 4096 = 4k, bei ARM sind es 16384 = 16k. Selbst wenn man nur 64 Bytes benutzen will, wird eine VM Page belegt. In manchen Fällen werden sogar zur Sicherheit 3 VM-Pages angelegt, aber die vor und die nach der eigentlichen VM-Page sind nur MallocGuard Pages und belegen kein physikalisches RAM. Kann auch sein, dass der Kernel da einzelne VM-Pages platzsparender im physikalischen Speicher unterbringt (dafür ist der Memory Pager im Kernel verantwortlich) und wenn VM komprimiert wird, dann natürlich auch nur der allozierte Teil, nicht die ganze VM-Page (schon da kann viel eingespart werden).
Im Grunde würden aber durch die größere hw.pagesize bis zu 4 Mal so viel RAM verbraucht werden, aber auch nur, wenn man lediglich extrem viele kleine Blöcke braucht. Bei den Aufgaben des TE wird das Problem nicht auftreten.

Übrigens: da die VM-Pagesize größer ist und der VM von Prozessen nicht so klar gekapselt sind, wären Angriffe auf die VM deutlich einfacher als bei Intel. Schreibt Apple auch irgendwo in ihrer Entwickler Doku. Da ist auch mehr Platz für Buffer-Overflow Angriffe. Mussten die zuvor in 4k passen können es jetzt 16k sein.

Noch was: Was Rosetta da macht ist teils irre. Intel-Code erwartet ja eine "hw.pagesize" von 4k und so wird der Prozess auch im RAM angelegt, aber dann mal auf 16k Grenzen verschoben und mal nicht.

Da muss man den großen Unterschied zwischen Emulation und Rosetta2 kennen, dann weiß man, warum Microsoft es vermutlich nicht so gut hinbekommen wird wie Apple.
Liegt daran, dass Apple durch das intensive Sponsoring beim LLVM-Projekt extrem viel Expertise mit dem "transcoding" hat. Rosetta 1 hatte PPC Code noch "on-the-fly" emuliert und zur Optimierung den übersetzten Code im Speicher behalten, um bereits übersetzte Code-Abschnitte nicht beim nächsten Aufruf erneut übersetzen zu müssen. Das dürfte in etwa der Stand des ARM-Emulators von MS sein (soweit ich darüber gelsen habe).
Bei Rosetta 2 wird im Grunde der Intel-Code noch vor der Ausführung komplett analysiert und in LLVM-IR übersetzt. LLVM optimiert das dann (und das sehr effizient) und wirft nativen Code aus, der in einer "Shadow"-Datei im System hinterlegt wird. Ist nicht ganz so einfach aber im großen und ganzen funktioniert es so und es wird so gut wie nichts mehr emuliert.
(Wir hatten das mal mit x86 Code vom MS-Compiler gemacht und dann wieder von LLVM als x86-Code ausgeben lassen - der dann ca. 10% effizienter war)

Bei Intel Systemen kann man auf Large Pages umschalten, dann werden nicht mehr 4kB Pages benutzt sondern wahlweise 2MB oder 1GB, die sind auch bei AArch64 (64Bit ARM) möglich.

Nicht die Adressierungs-Modi mit der hw.pagesize verwechseln. Die wird beim Booten vom Kernel/IOKit festgelegt. Bei größeren Pagesizes wird es dann doch wieder sehr ineffizient. Bei 1GB Pagesize könnte man je nur zB 16 Speicherblöcke allozieren. Das hast du schon alleine für die Argumente und Environment-Variablen überschritten, die jeder Prozess beim Starten vom System mitbekommt.

Auf jeden Fall sind mit den größeren Pagesizes bei Aarch64 viele kleine Speicherblöcke weniger effizient, dafür größere schneller zu verwalten, schon weil es weniger sind und der Kernel weniger zu tun hat um virtueller Speicherseiten mit physikalischen zu verknüpfen. Real würde ich mir diesbezüglich aber wenig Sorgen machen. Ist eher theoretischer Natur. Unified Memory knappst da mehr vom verfügbaren RAM weg.

Sorgen muss man sich eher bezüglich Sicherheit machen. AppleSilicon hat ein schwächeres Speichermanagement (was es auch schneller macht), da muss man im Code mehr Wert auf Sicherheit legen. Apple schreibt selbst in der Entwickler-Dokumentation:Tja - und ich wette, daran wird sich nicht jeder Entwickler halten, was für neue Exploits sorgen kann.

Ist doch kein Problem. Habe mit Rufus - Win 11 auf einer SSD - läuft super. Ausser dass man mit Alt booten muß. Ist ein Mac Mini 2014. Es darf aber keine Festplatte beim booten zusätzlich angeschlossen sein.
Bei meinen Mac s ist allerdings Win 10 als BootCamp installiert. WIN 11 geht noch nicht. Funktioniert auch sehr gut. Hatte noch nie Probleme. Als Backup stelle ich Clone s auf einer normalen HDD- Festplatte her mit Acronis. Aber es gibt auch noch andere Software.

WIN 11 - SSD Festplatte nehme ich auch zusätzlich bei den iMac's - wenn ich BootCamp nicht nehmen möchte bzw. mit WIN 11 arbeiten möchte. Für mein Mac Book gibt es auch ein WIN 11 auf SSD. Man könnte die SSD eigentlich auf jedem Apple PC benützen, aber es ist nervig zu warten bis die jeweiligen Treiber geladen werden.

Ich schreibe von der Hardware Pagesize. Aber eben nicht auf Apple Computer bezogen, sondern auf die CPU Plattform im Allgemeinem. Und da gibt es sowohl bei Intel wie auch ARM 4kB, 2MB und 1GB.
Wieso 16? Wir reden hier nicht über einen bestimmten Computer, sondern die CPU Plattform selbst. Bei den aktuellen Xeon SP G3 wären 12288 1GB Speicherseiten möglich, beim Ampere Altra sind es immerhin 8192, und beim MacStudio 64 bzw. 128.

Nur einmal ein historischer Vergleich der NeXT computer wurde mit 8MB ausgeliefert, und konnte auf 64MB aufgerüstet werden. D.h. 2048 4kB-Speicherseiten in der Grundausstattung und maximal 16384 4kB-Speicherseiten waren im System möglich.
Bei so etwas denke ich eher an rowhammer.

Von der theoretischen Effizienz sehe ich im Alltag nichts. Ich betreibe MS Edge im Rosetta-Modus auf einem M1-iMac, weil MS Teams nur dann seine Videofunktionen bereitstellt. Edge ist unter Rosette schnarchlahm im Vergleich zum nativen Modus. Auch die offizielle MS-Teams-App läuft (derzeit) unter Rosetta und ich habe das Gefühl, 20 Jahre in der Vergangenheit zu reisen, wenn ich das bedienen muss. Auf einem Intel-MacBook läuft das etwas fluffiger. Teams ist aber vermutlich kein gutes Beispiel. Das ist abgeschlagen die lahmarschigste App, die ich benutze(n muss), egal auf welchem System. Da laufen ja sogar Java-Apps wie BeaTunes und Jaikoz fluffiger und die sind schon grenzwertig.

Ich nutze auch täglich teams, allerdings kein Edge, den habe nicht mal installiert, und ich kann nicht behaupten Teams wäre "schnarchlahm" … Die täglichen Videokonferenzen werden, wenn überhaupt, von mein ab und an sehr wackligen Telekom-Anbindung gebremst.
Allerdings ist Teams was UX angeht wirklich grotten schlecht und man merkt dem Teil an, dass es eine keine native App ist sondern Electron-Mist, aber das zieht sich durch ALLE Microsoft-Produkte, aber Teams ist für mich da der Gipfel des UX-Grauens. Der größte Witz: Ich habe Teams einen eigene Space gegeben … um in diesen zu wechseln muss ich nicht einmal, sondern zwei mal das Icon im Dock tappen.

Wie @LoCal erwähnt hat, funktioniert Teams und einige andere Anwendungen per Electron. Im Browser (besonders Edge) wird Teams ebenfalls mit einer Unmenge von JavaScript Code ausgeführt.
JavaScript ist per se eine nicht-kompilierte Sprache, die im Browser per JiT (Just-in-Time) Compiler ausgeführt wird. Das kann Rosetta 2 nicht vorab transkodieren, weil es in der Regel vom Server geladen wird. Folglich muss der Code immer emuliert werden, was dann langsam wird. Das gilt zum Beispiel auch, wenn man Python einbettet.

Apple hat dazu recht gut dokumentiert, wie man Code, der per JIT ausgeführt wird, entsprechend markiert, damit er von Rosetta nicht übersetzt wird und daher per Emulation ausgeführt werden kann. Das ergäbe sonst einen Crash.

Bei mir läuft die Teams-App aber recht gut (ist ein Firmenrechner und die Firma will das benutzen - dann kommt die App drauf), auch im Browser (Safari) klappt es relativ gut, inkl. Video. Nur bei RDP merkt man, dass man beim Starten der App manchmal ein paar Intel-Gedenk-Sekunden warten muss. Die von Rosetta transkodierten Binaries werden wohl von Zeit zu Zeit aufgeräumt - ist halt ein Cache.

Kann ich aktuell nicht mit Sicherheit sagen, jedenfalls kam bei den 2015er 64GB iMacs schon mal die Meldung "nicht genügend Arbeitsspeicher vorhanden" (genauen Wortlaut habe ich nicht mehr im Kopf) bei der einen oder anderen Anwendung oder es wurde alles extrem langsam und macOS hat kaum mehr reagiert. Schließen von Programmen oder ein Neustart haben immer geholfen, war aber auch nur gelegentlich der Fall. Seit wir die 2020er mit 128GB im Einsatz haben ist diese Fehlermeldung nicht mehr aufgetaucht. Es werden also mehr als 64GB aber weit weniger als 128GB im Alltag benötigt.

Hm... irgendwas muss ich an meinen Macs falsch konfiguriert haben, wenn Teams bei euch gut läuft. Allein der Start fühlt sich an wie Booten (Icon hüpft . Mit Edge ist es zumindest erträglich und zeigt nicht ständig Einblendungen wie "Kalender wird geladen". Während eines Calls drehen nach einer gewissen Zeit bei Teams immer die Lüfter auf, egal ober Intel oder M1. Ich kann deshalb nicht die integrierten Mikros nutzen. Das passierte weder bei Jitsi, Skype, Zoom noch FaceTime.

Ich habe eine Firmen MacBook Pro 13" M1 mit 16GB … wir haben unser 30 Minuten Daily und durchschnittliche einmal pro Woche habe ich eine 60 - 90 Minuten Videokonferenz … dabei ist absolut kein Lüfter zu hören.
Insgesamt ist das MBP sehr leise und die Lüfter laufen nie … ausser wenn ich eine recht große Bibliothek über ein Build-System bauen muss und da kommen dann verschiedene Compiler und Interpreter gleichzeitig zum Einsatz … dann schnauft das MBP schon sehr. Sonst nie … wirklich nie.