Microsoft brengt Office 2019 met Apple M1-soc-ondersteuning uit

Microsoft 365 en Office 2019 hebben met de December 2020-versie allebei native ondersteuning voor Apples M1-soc. Het macOS-besturingssysteem kiest nu zelf of de M1-versie of de Intel-versie van Office 2019 opgestart moet worden.

Met de update zijn Word, Excel, PowerPoint, Outlook en OneNote volgens Microsoft Universal-apps, waarbij de programma's ondersteuning hebben voor zowel Intel-processors als Apples eigen M1-socs. Microsoft raadt gebruikers aan macOS te laten kiezen welke versie wordt opgestart, al zijn er volgens het bedrijf twee situaties waarin de gebruiker beter via de Rosetta 2-emulatie kan werken. Zo werkt Excels Get & Transform-functie, ook wel bekend als Power Query, nog niet in de M1-versie. In een ondersteuningsbericht geeft Microsoft wel aan dat deze ondersteuning later komt. De tweede situatie is wanneer de gebruiker plug-ins gebruikt die nog geen M1-ondersteuningsupdate hebben gehad.

De geüpdatete Office-programma's zijn volgens Microsoft sneller op Apple-computers met M1-soc, al geven ze geen details over de snelheidswinst. De apps hebben daarnaast uiterlijke veranderingen gekregen die beter moeten matchen met macOS Big Sur. De Outlook for Mac-app krijgt bovendien in de komende weken ondersteuning voor iCloud-accounts. Microsoft maakt daarnaast bekend dat Teams een Universal-app krijgt.

Microsoft maakte ruim een maand geleden bekend te werken aan de Universal-builds van de Office-apps en gaf toen een testversie vrij. Destijds gaf ontwikkelaar Erik Schwiebert aan dat de uitvoerbare bestanden vijftig procent groter zouden zijn dan voorheen. De apps zelf waren twaalf procent groter, evenals de installer. Het is onduidelijk of de bestanden bij de definitieve versie weer groter zijn.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (130)

Gaat hard zo! Vandaag ook al Firefox 84 verschenen met native support. Ik denk dat Microsoft snel deze switch heeft kunnen maken omdat sinds een paar jaar de codebase unified is, en dus al voor verschillende platforms en architecturen kon compilen:

https://twitter.com/schwieb/status/954037656677072896

Hard? We horen van een paar grote bedrijven (Microsoft en Adobe) met tientallen, zoniet honderden programmeursteams dat ze met mondjesmaat hun belangrijkste producten pas NA de launch van het product introduceren en naar eigen zeggen met tekortkomingen zoals hier wordt beschreven. Microsoft heeft al jaren ervaring met unified spul naast/omdat ze enerzijds hun windows phone en anderzijds windows for arm hebben gemaakt. Hoe moeilijk moeten bedrijfjes met een handvol werknemers het dan niet hebben? Ik kan me voorstellen dat ze eerst hun halve bedrijf moeten laten bijscholen om dan pas aan het werk te kunnen gaan met een compleet nieuwe situatie.

De meeste code kun je gewoon hercompileren naar ARM en dan zou de code moeten werken. De uitzonderingen daarop zijn libraries waarvan je de broncode niet hebt, bijvoorbeeld omdat ze door een derde partij zijn ontwikkeld, of processorspecifieke functies, zoals integers van arbitraire lengte waar endianness uitmaakt of bijvoorbeeld (JIT) compilers.

De meeste applicaties gebruiken hun eigen libraries of systeemlibraries en over het algemeen hoef je niet zo specifiek naar de geheugenlayout van integers te kijken; in die gevallen moet men met een paar dagen de applicatie wel weten om te bouwen tot een volledig werkende versie op ARM.

Het lijkt me sterk dat er voor de meeste programma's ook maar iemand moet worden bijgeschoold, de onderliggende concepten van de programmeertaal en de computers zijn niet veranderd. Er zijn alleen wat low-level details veranderd waar je rekening mee moet houden. Als je gewoon tests voor je belangrijke algoritmes schrijft, weet je met een druk op de knop precies waar je je programma moet aanpassen om op M1 te kunnen draaien.

processorspecifieke functies, zoals integers van arbitraire lengte waar endianness uitmaakt

Zowel Intel als ARM zijn little-endian. Of eigenlijk: ARM kan beide, maar iOS en macOS op ARM zijn little-endian.

zonder zelf er veel kennis van te hebben lijkt je uitleg heel aannemelijk, doch simplistisch terwijl hier in de praktijk toch het tegenovergestelde blijkt. We zijn een maand verder en wat maar een paar dagen zou duren volgens jou is nog altijd maar gedeeltelijk opgeleverd door een paar van de grootste techbedrijven ter wereld.

Je moet je afvragen of de investering op dit moment opweegt tegen de opbrengsten. Hoeveel apparaten zijn er verkocht met een M1 cpu? Dat aantal zal ongetwijfeld stijgen, maar zal nu nog, afgezet tegen apparaten met een Intel cpu behoorlijk laag zijn.

Dingen zijn ook pas een maand uit he. Maar als we even naar Japan kijken, daar is t MacOS marktaandeel gegroeid van 15 naar 27 procent sinds de M1 Macs uit zijn.

https://appleterm.com/202...sktop-market-share-japan/

Nu zijn dit geen cijfers over de hele markt maar het kan best eens zijn dat de M1 apparaten (vooral omdat vrijwel alle reviewers vreselijk positief zijn) een kleine verschuiving in markt percentages kan veroorzaken.

Dat is marktaandeel op gebied van verkopen bekeken in een heel kort tijdsbestek. Daarbij moet je je de vraag durven stellen hoeveel mensen hier op hebben zitten wachten en na release zo snel mogelijk er 1 hebben aangekocht. Om echt een impact te zien moet je nog een jaar wachten en zien hoe die cijfers standhouden.

In de dagen na de release is de nieuwe iPhone ook de best verkochte telefoon, betekend nog niet dat de meeste mensen met een iPhone rondlopen.

Percentages zijn niet zo relevant in dit geval. Dat kunnen ook gewoon mensen zijn die de aankoop van een Mac hebben uitgesteld vanwege de komst van de M1. Het enige dat echt telt zijn de absolute cijfers.

Het gaat hem niet over het aantal macs met M1 dat nu is verkocht maar het aantal Macs met M1 die zullen verkocht worden. Stel dat ik volgende maand een Mac met M1 koop dan ben ik vandaag aan het kijken wat native werkt. En als ik vandaag zie dat Office native is dan ga ik al minder geneigd zijn eens te kijken of er een alternatief voor Office.

Als je wacht met investeren tot er voldoende van het betreffende product verkocht wordt, is de concurrentie je al lang voor geweest en is je investering kansloos.

Hangt ook weer een beetje af van je product. Microsoft kan het zich met Office best wel veroorloven om wat later te komen. Veel gebruikers hebben een 365 abonnement en die stappen toch niet zo gauw over en krijgen vanzelf de ARM variant zodra die er is.

Nee, dat kan Microsoft niet!! Steve Jobs heeft destijds al een overeenkomst met Bill Gates gesloten waarbij MS zich verplicht altijd ook de nieuwste versie van Office voor de Mac beschikbaar te stellen.

Niet zolang Office dus ook al werkt op apparaten met een M1 cpu, zoals nu het geval is. Daarom is er geen haast. Er is al een perfect werkend office pakket op het besturingssysteem.

Microsoft Office is dan ook niet de minste applicatie. Ik denk dat het recompilen van de code en het corrigeren van de falende tests niet het grootste probleem is geweest eigenlijk; eerder het opsporen van gebruikte libraries, het nalopen van nieuwe compilerwaarschuwingen, het verifiëren dat file formats nog werken en vooral het testen van ieder scherm, in iedere taal, in zoveel mogelijk configuraties, van iedere applicatie in het pakket, om te zien of er nog wat mis mee is.

De kerncode van Office draait al op ARM in de vorm van hun mobiele app. Ik kan niet in hun tijdsschema kijken natuurlijk, maar als je op x86 en ARM Android je docx files kan inladen en aanpassen, is een van de lastigste problemen, namelijk je core engine omzetten, al gelukt. Bepaalde extern bestelde zaken (in Excel voor Windows zit bijvoorbeeld een scherm dat geschreven is door een derde partij waar Microsoft de broncode al niet meer van heeft, dat werd duidelijk toen dat scherm gepatcht moest worden) moet je uitschakelen of er een alternatief voor bedenken.

Zie alleen maar eens ieder menu in Office te testen om te kijken of alle knopjes nog werken. Daar ben je nog wel even mee bezig! Zelfs als een product technisch gezien perfect werkt, kun je dat niet zomaar naar klanten gooien en roepen "we testen nog even maar hier heb je het alvast". Dat gaat je klanten en reputatie kosten als er toch ergens een optimalisatie gedaan is waar de bytevolgorde uitmaakt.

Zal inderdaad wel vol unit tests zitten en dan nog gebruikers test.
Daarnaast moeten ze als ze het officieel uitbrengen ook de hele support op orde hebben mochten er bugs opduiken die alleen bij de m1 versie voorkomen.
Je wil geen excel uitbrengen die ineens een kleine afwijken heeft bij zoveel cijfers achter de komma :-)

De 'gewone' x86 applicaties draaien ook praktisch zonder moeite. Dit is puur een optimalisatie die doorgevoerd wordt. Het is niet alsof alles wat je hebt by default 'stuk' is met een M1-gebaseerd systeem...

Maar dat is toch normaal dat dit enkele weken na de launch gebeurd.

Ja, ze hebben vele programmeurs, maar zij beschikken NIET over de finale versie van het OS en de hardware. Van zodra die beschikbaar zijn moet men alle testen opnieuw draaien en kan men pas een publieke beta draaien om te zien hoe alles werkt bij eindgebruikers.

Als men op releasedag met een build zou komen en daar blijken enkele ernstige bugs in te zitten die ze bij hun eigen testen niet tegenkwamen dan is dat weer negatieve publiciteit voor hen. Beter voorkomen dan genezen op zo een moment en de release enkele weken later doen.

Apple heeft devkits zoals consolebouwers, namelijk Developer Transition Kits waarin weliswaar een A12Z zat, maar verder ook de beta van Big Sur en Xcode. In juni zijn er al leaks van geweest, dus het is niet zo dat Microsoft en de rest moest wachten tot launch-day om aan de slag te kunnen, ze zijn hier al minstens een half jaar mee bezig geweest.

Je kan niet launchen met een beta versie van Xcode, je moet daarvoor de officiële build hebben.

Dan nog. Je kunt dat prima gebruiken om je voor te bereiden, maar je wilt uiteindelijk toch zeker weten dat alles met een commercial versie van een OS goed werkt.

De x86/64 versie draait anders ook gewoon probleemloos.... dus niks “mondjesmaat”.

Zou het dan ook enigszins makkelijk zijn voor Microsoft om office voor Linux uit te brengen?

ze zouden dan ook de onderliggende UI toolkit naar Linux moeten porten (en dus geschikt moeten maken voor Xorg danwel Wayland danwel rendering op een andere manier)
Het zou in iedergeval niet per se voor een mooie native Linux ervaring zorgen

Naast technisch kunnen is er ook altijd nog politiek kunnen. Op het Apple platform heeft microsoft een geschiedenis. En bij apple wil microsoft ook via de apple-winkel leveren. Het apple publiek is altijd een loyaal betalend publiek geweest.

Richting het linux platform zal het voorlopig browser-based en/of office365 gebaseerd blijven. Inclusief vendor-lock-in die ze anders niet voor elkaar krijgen. Maar je kan en mag altijd blijven hopen.

Ze hebben al Office voor Android, dus het is meer de vraag voor welke Linux distributie ze Office willen uitbrengen.

Office voor Android (touch) is heel wat anders dan voor op de desktop. Ik denk dat je voor linux echt een port van de laatste wil.

Als dat commercieel interessant is zullen ze het zeker doen. Maar het marktaandeel van Linux (op de desktop) is klein, en de bereidheid om te betalen zal ook niet groot zijn. Maar waarom zou je het willen? Open source biedt toch alles?

Het gaat inderdaad hard, veel harder dan ik had verwacht.

Ik kreeg vandaag een melding dat Airmail nu ook ARM ondersteunt. Ik krijg nu zo ongeveer om de dag een updatemelding dat er weer een app ook als ARM versie uit is.

Ja ik vindt het ook snel gaan! Vergeet niet dat de M1 devices net 1 maand uit zijn. Uiteraard hadden de developers wat langer toegang. Hier ook een mooi overzicht van de apps die al M1 compatible zijn. https://isapplesiliconready.com/

Je vraagt je af waarom er nog steeds geen Office versie voor Linux is. Maar aan de andere kant is het antwoord misschien vrij gemakkelijk. Microsoft loves Linux maar alleen als het hun uit komt.
Marktaandeel verliezen t.o.v. Windows, daar houden ze niet zo van.

Er zijn amper Linuxgebruikers op de desktop, onder die gebruikers is relatief weinig vraag naar Microsoft's closed-source pakketten en dependency management op Linux is een regelrechte hel als je meer dan alleen Ubuntu or Fedora wil ondersteunen.

Daarnaast is de GUI van Office geschreven bovenop de GUI van Windows en macOS. Dat gaat op Linux natuurlijk niet werken. Om het werkend te krijgen moet je dus zorgen dat de GUI er normaal uitziet op KDE, GNOME, LXDE, XFCE en nog meer dingen eindigend op -E. Je moet kiezen of je een bestaand GUI-pakket wilt gebruiken (GTK+, GTK2, Qt, KDE) en uitzoeken welke libraries je mee moet nemen om er ook op andere omgevingen normaal uit te zien. Aangezien je met videoplayback en hardwareversnelling te maken hebt, moet je natuurlijk testen op AMD- en NVIDIA-hardware, met X11 en Wayland ingeschakeld.

Microsoft houdt van Linux in dat hun halve datacenters Linux draaien omdat daar alle serversoftware voor wordt geschreven. GUI software schrijven op Linux is echter hele andere koek. De kracht van Linux, namelijk dat alle onderdelen uit elkaar te halen zijn en te vervangen zijn door eindgebruikers, is ook de zwakte voor makers van closed-source software. Voor ieder onderdeel is een alternatief, en verschillende grote groepen mensen gebruiken verschillende combinaties naar hun voorkeuren.

Als Firefox crasht op LXDE vanwege een bug, kan een LXDE-ontwikkelaar daar naar kijken en een oplossing voordragen. Als dat bij Office gebeurt, moet Microsoft zelf de crashmeldingen van hun gebruikers genoeg prio geven dat een van hun ontwikkelaars er naar kijkt.

En wat levert het Microsoft op, behalve een hoop bugmeldingen? Weinig, want praktisch niemand in de kantoorwereld draait op Linux. De ROI is simpelweg te laag om daar aan te beginnen.

Dat standaardriedeltje gaat nog maar gedeeltelijk op, advocaat van de duivel:
- flatpak zorgt ervoor dat je je applicatie op alle linux distributies in één klap en met sandboxing en automatische updates kan uitbrengen; de Windows-store staat in zijn onderbroek vergeleken met flatpak
- door Qt te gebruik kan je alle platformen targeten en met een beetje aandacht overal native laten aanvoelen
- het is een misvatting dat je altijd alle mogelijke configuraties zou moeten testen; je pakt de meest gangbare en de rest is zelf-ondersteuning
- jij denkt dat microsoft op het moment alle crashmeldingen van office op windows en mac naloopt?
- heb je zelf ooit een bugmelding van office gemaakt? Denk je dat de meer technische gebruikers van Linux ineens een stortvloed aan bugmeldingen gaan aanmaken?
- wat levert het microsoft op? Wat dacht je van de concurrentie de pas afsnijden, meer cloud-diensten slijten en fris blijven qua technische know how? Volgens jouw redenatie hadden ze ook nooit aan ARM-versies moeten beginnen want de ROI is simpelweg te laag, vervolgens slaat apple een nieuwe processorweg in en mist microsoft de boot...

Ik raad microsoft vooral aan om naar jou te luisteren als ze opnieuw alle fouten van het verleden willen herhalen (anti-competitief, anti-opensource, windows 8, windows phone) en ze toch nog langzaamaan irrelevant willen worden.
Ben het er wel mee eens dat er op het moment niet veel geld te halen valt met office op linux. Het is een groot en complex pakket dus er is enige investering mee gemoeid en dan zijn web apps (of misschien api vertaling via wine) logischer.
Een item om wel rekening mee te houden is dat bepaalde landen/werelddelen wel eens te veel argwaan kunnen gaan krijgen bij Amerikaanse besturingssystemen en overstappen op een (eigen) linuxdistributie. Hoewel er dan waarschijnlijk ook veel sprake is van piraterij kan het (beperkt) ondersteunen van Linux een teken van welwillendheid en transparantie zijn, en het houdt de deur naar het ecosysteem op een kier.

Het punt is min of meer dat Linux toch een strategisch voordeel kan bieden, maar dat is vast niet wat de microsoftoortjes hier willen horen.

Ik draai hier zelf overal Linux, Windows boot ik alleen voor games. Ik zal Office vast nog geinstalleerd hebben staan, maar ik werk eigenlijk uitsluitend in LibreOffice of Texmaker.

- flatpak zorgt ervoor dat je je applicatie op alle linux distributies in één klap en met sandboxing en automatische updates kan uitbrengen; de Windows-store staat in zijn onderbroek vergeleken met flatpak

Daar ben ik het niet mee eens. Ja, Flatpak is erg goed, maar er zijn nog tal van problemen die er spelen. Denk bijvoorbeeld aan thema's: ik gebruik zelf een dark theme, maar de Flatpak-sandbox kan niet bij de systeemthema's dus alles dat op Gnome gebaseerd is en vanuit Flatpak draait, heeft het grijze Gnome-thema. Zeer storend, aangezien dezelfde applicatie geïnstalleerd vanuit een .deb of een .rpm wel gewoon het correcte thema pakt.
Bij Windows heb je dat probleem niet, omdat de Windows-sandbox anders werkt, op een manier die onder Linux-gebruikers waarschijnlijk zou worden bestempeld als een slecht plan dat vrijheden ontneemt.

- door Qt te gebruik kan je alle platformen targeten en met een beetje aandacht overal native laten aanvoelen

Niet helemaal, vind ik zelf. Qt-applicaties werken prima, maar op Gnome merk ik dat de designtaal en bepaalde functionaliteiten gewoon net niet native aanvoelen. Als ze hun eigen ribbon renderen in de titelbalk is dat het probleem niet, maar ik merk zelf al wel verschil.
Het lijkt me onrealistisch dat Microsoft Qt gaat betalen (gratis licentie is GPL) om hun GUI daarop om te bouwen. Als dat een goede optie was, hadden ze al lang zoiets gedaan voor hun macOS build.

het is een misvatting dat je altijd alle mogelijke configuraties zou moeten testen; je pakt de meest gangbare en de rest is zelf-ondersteuning

Zelf-ondersteuning verkoop je lastig aan een universiteit of bedrijf van vijfduizend werknemers. "Ja, jullie draaien niet Ubuntu 20.04 dus jullie zoeken het zelf maar uit" is nogal lastig als men Debian nodig heeft om hun interne tooling te kunnen draaien. MS kan zichzelf natuurlijk beperken tot de meestgebruikte opties (GNOME en KDE) maar zelfs dan moet je rekening gaan houden met tal van versies.

jij denkt dat microsoft op het moment alle crashmeldingen van office op windows en mac naloopt?

Microsoft kijkt wel degelijk naar veelvoorkomende crashes en feedback, daar is al die spyware van ze voor, en als je de juiste pagina's weet te vinden (de feature suggestionpagina's bijvoorbeeld) kunnen support teams direct ideën en problemen oppakken als ze genoeg stemmen krijgen. Denk je echt dat Microsoft die terabytes aan crash logs die ze in een maand verzamelen gewoon weggooit?

heb je zelf ooit een bugmelding van office gemaakt? Denk je dat de meer technische gebruikers van Linux ineens een stortvloed aan bugmeldingen gaan aanmaken?

Nee. Ja.

- wat levert het microsoft op? Wat dacht je van de concurrentie de pas afsnijden, meer cloud-diensten slijten en fris blijven qua technische know how? Volgens jouw redenatie hadden ze ook nooit aan ARM-versies moeten beginnen want de ROI is simpelweg te laag, vervolgens slaat apple een nieuwe processorweg in en mist microsoft de boot...

Microsoft heeft een uitgebreide webapplicatie waarin nagenoeg alles kan worden gedaan wat je op de desktop doet, net zoals Google dat heeft. De concurrentie op Linux is LibreOffice of een ander online-officepakket, maar door hun online Office te verbeteren halen ze die concurrent in op drie platformen in plaats van één.

De landen die momenteel overgestapt zijn op hun eigen Linux zijn Noord-Korea (draait op XP en een Linux-distro), gedeeltes van de Chinese overheid en een Duitse gemeente die onderhand weer terug is gegaan naar Microsoft door Microsoft's vieze spelletjes. Tot er een volledige overheid écht overstapt naar Linux, zijn Chromebooks grotere concurrentie voor Microsoft dan alle Linux-distributies bij elkaar. Door kinderen Office (of, sinds een paar jaar, GDocs) te leren verzeker je de komende jaren dat je de tekstverwerkersmarkt voor jezelf hebt. Die drie kinderen op een school wiens moeder Linux kent en op de laptop van haar kinderen gezet heeft, zijn niet relevant voor de statistieken.

Microsoft is een bedrijf en een bedrijf bestaat om winst te maken, niet om de wereld te verbeteren. Als ze hun welwillendheid zouden laten willen zien, zouden ze de Windows-kernel open source maken zoals Apple dat gedaan heeft. Als er geen winst te behalen valt, zal Microsoft geen stappen nemen.

Dit zie je terug in hun nieuwe bedrijfsmodel. Ze werken veel aan de Linux-kernel om deze optimaal op Azure te laten draaien, ze open-sourcen C# om de concurrentie aan te gaan met platformen als Java (waar toevallig hun Azure-omgeving voor geoptimaliseerd is), ze voegen een Linuxsubsysteem toe zodat ontwikkelaars moderne tools kunnen gebruiken zonder al te veel gezeik (er zijn veel verhalen te vinden van bijvoorbeeld webontwikkelaars die Linux te houtje-touwtje vonden en naar Windows + WSL2 zijn geswitcht), ze maken Android-telefoons omdat Windows Phone na een vierde keer compatibiliteit breken eindelijk gestorven is en ze hebben de gratis PowerToys, die grotendeels door ontwikkelaars worden gebruikt, op Github gegooid omdat er toch niks geheims in de broncode zit en het maar een bijproject is.

Ooit zal het mythische jaar van de Linux-desktop komen. De vorige grote kanshebber was vorig jaar, toen Windows 7 eindelijk support verloor voor de meeste mensen en er een alternatief moest worden gekozen, en er is een piek geweest in Ubuntu-adoptie, maar de 10% is nog lang niet bereikt. De strategische plek van Ubuntu is de servermarkt in enterprise-context, en dat is de reden dat Microsoft heel lang zo fel tegen Linux is geweest. De desktop vormt voor nu nog geen enkel obstakel in hun verdienmodel.

Hopelijk wordt dat over vijf jaar anders en wordt Microsoft door de markt gedwongen een Linux-variant te bouwen. Ik zou maar al te graag zien dat Microsoft's grip op de besturingssysteemmarkt minder wordt. Laten we ons allen alleen niet voor de gek houden en accepteren dat dat moment nog niet aangekomen is. Ik ga geen Linux op de laptop van mijn moeder zetten, ik krijg de SD-kaartlezer van mijn eigen laptop(s) niet eens werkend, laat staan dat ik ga komen opdraven als ik mijn ouders moet helpen. Pas als computers grootschalig met Linux worden verkocht, krijg je grootschalige adoptie, en daar heb je een kip-ei-probleem van jewelste te pakken.

Ik pik er één ding uit omdat ik het hiermee echt niet eens ben:

heb je zelf ooit een bugmelding van office gemaakt? Denk je dat de meer technische gebruikers van Linux ineens een stortvloed aan bugmeldingen gaan aanmaken?

Nee. Ja.
[...]

Gameontwikkelaars hebben er een handje van om applicaties te verschepen die vol met bugs zitten en soms totaal niet werken. Als je iets verkoopt moet het natuurlijk wel werken en niet om de haverklap niet meer opstarten of onwerkbaar zijn. Je haalt een voorbeeld van een kickstarter aan wat sowieso al een dumpster fire is van ontwikkelaars met een slecht business model. Veelal beloven ze veel om maar gefund te worden en maken ze vervolgens weinig klaar, helemaal als het niche-functies of een -groep betreft. Zeer slecht voorbeeld dus.
Als er kleine probleempjes zijn dan lost de technische Linuxgemeenschap dat zelf wel op. Als iets compleet troep is en niet kan werken dan heb je bij die groep inderdaad een probleem. Kortom, zorg dat het in de basis goed werkt en je bent klaar.

Het gros van de problemen zat hem dus niet in de game, maar in de drivers. De Nouveau-driver heeft de meeste ondersteuning die je van een grafische driver verwacht gewoon niet en de Nvidia-driver is bagger genoeg dat deze op mijn Ubuntu met een 1080 soms gewoon compleet het beeld bevriest als ik alleen maar op uitloggen klik. Ik zou "je account uit kunnen loggen" nou niet echt een ongebruikelijke actie noemen, dat moet gewoon werken.

Zo'n andere basisfunctie die slecht werkt is een extern scherm aansluiten op laptop en dan schakelen naar "alleen extern scherm", waardoor de FPS van libreoffice en zelfs Gedit naar onder de 60 zakt met luid blazende fans.

De AMD-driver is na het plaatsen van die tweet flink verbeterd, al heb ik daar ook mijn problemen mee gehad (Ubuntu LTS met officiële driver kon niet inloggen, corrupte frame buffer) . Graphics drivers op Linux zijn alleen vaak een drama, en dat is doorgaans niet de schuld van Linux of de Linuxgebruiker. Ik heb soortgelijke vage issues met de Nvidia driver als ik mijn PC als Hackintosh opstart, maar daar kun je natuurlijk helemaal geen support verlangen.

Het lijkt nu natuurlijk alsof ik denk dat Nvidia de allerslechtste Linuxdriver in GPU-land heeft geschreven, maar ik weet ook wel dat het op ARM-land nog vele male slechter gesteld is; daar zit je driver praktisch vast aan je specifieke kernel en als je die wil upgraden heb je pech.

In Firefox zijn diverse drivers op Linux geblacklist, daar gaat dan automatischdde GPU-acceleratie uit. Als game heb je die mogelijkheid niet, je kunt hooguit een popup geven met "hee, deze driver is slecht", maar dan moet je eerst proefondervindelijk ontdekken welke drivers er dan slecht zijn.

Dat een stuk software niet goed werkt op jouw computer is lang niet altijd de schuld van de ontwikkelaar, maar omdat de andere software wel werkt, kom je sneller tot de conclusie dat het aan dat specifieke stuk code moet liggen.

Klopt, nouveau is niet geschikt om te gamen. Qua gaming is de situatie inderdaad wat speciaal, maar er valt nog verrassend goed te gamen op Linux en ook op Windows zijn zo nu en dan de nodige problemen met grafische drivers.

Dat soort dingen zijn voor heel veel applicaties niet relevant. In het geval van office heb je mogelijk optioneel te maken met hardwarematige rendering, niet zo heel spannend dus. Wat blijft is dan multiscreen-ondersteuning voor powerpoint, lijkt me niet dat men hard gaat schreeuwen als dat onder bepaalde omstandigheden niet perfect werkt.

En je haalt zelf al mooi het voorbeeld aan van browsers en hardwarematige versnelling, waarbij blacklisting en opt-in voor voldoende stabiliteit zorgt. Het hoeft dus vaak helemaal niet perfect te zijn en met een beetje pragmatisme kom je al een heel eind.

Bij het hele supportverhaal vergeet je gemakshalve ook even dat men op Windows virusscanners gebruikt en die applicaties met enige regelmaat dwarszitten. Dat is een situatie die ook niet te testen is maar wel flink wat supportaandacht kan vereisen.

Ik blijf erbij dat Linux-ondersteuning voornamelijk een kwestie van visie is. Wie bepaalt de richting in het bedrijf? Marketing, finance, of ontwikkeling? Als het goed is is het een gezonde combinatie daarvan, maar te vaak gaan die eerste afdelingen ermee aan de haal. Windows en de ander diensten van microsoft zouden op zoveel vlakker fijner kunnen werken, maar er wordt niet voldoende prioriteit en belang aan de ontwikkeltak gegeven; op korte termijn mooie cijfertjes, op lange termijn stagnatie en terugval.

Microsoft Office draait al sinds jaar en dag prima in CodeWeavers CrossOver for Linux (proprietary frontend voor Wine). Het is waarschijnlijk zelfs de meest populaire toepassing hiervan. Dat icm Office 365 icm LibreOffice en er is anno 2020 nog minder noodzaak voor native MS Office op Linux dan ooit.

Wat betreft anti-Amerikaanse tendens. Dat is de reden dat Jolla het op Qt gebaseerde SailfishOS aan de Russische overheid kon slijten.

[Reactie gewijzigd door Jerie op 16 december 2020 00:34]

Ondersteun Ubuntu Gnome en je bent een heel eind.

Qua hoeveelheid machines wel, maar de doelklanten van Microsoft (bedrijven) draaien doorgaans versies van Linux die centraal beheerd kunnen worden en die niet snel kapot gaan door updates. Dan nog moet er een hoop werk worden verzet voor misschien 1.8% van de gebruikers met variërende staat van systeemsstabiliteit.

Zelfs als je je beperkt tot Gnome in Ubuntu, welke versies wil je supporten? Office heeft een support lifecycle van zo'n 10 jaar, dus Ubuntu 20.04 wordt je minimum (want LTS) en dan moet je je product alsnog een jaar na het afsluiten van Ubuntu's support ondersteunen, of je SLA verminderen (nieuwskop: "Microsoft vindt Linux minderwaardig voor ondersteuning", IT-nerds schuimbekkend in de comments). Neem je upgrades zonder reinstall, waarbij je dependencies spontaan allemaal van versie veranderen, mee? Hoe doe je packaging, via apt, snap, flatpak, of tar.gzs die je in /opt/ gooit? Allemaal dingen waar je niet direct een keuze voor kan maken, helemaal niet als je eindklanten geopinieërd zijn of weinig kennis van zake hebben op een systeem als Linux.

Ik geloof dat het de maker van Planetary Annihilation was die als stretch goal van hun Kickstarter beloofde Linux-ondersteuning te bieden maar dat moest intrekken omdat het merendeel van de bugreports van Linux kwamen en de oorzaak eigenlijk altijd ergens anders in het systeem lag. Onder andere drivers voor videokaarten zijn vaak niet goed geschreven (zowel bij AMD als NVIDIA als Intel zie je fouten) en de stack waar je software op draait kan spontaan veranderen.

En met al dat gedoe heb je het nog niet eens gehad over de licenties die aan alle systeemlibraries zitten die allemaal door Legal moeten worden gecontroleerd en waar mogelijk licentiegeld voor moet worden betaald om te zorgen dat je geen GPL-gelicenceerde code opneemt in je pakket.

Prachtige verhalen maar er is zat software die prima werkt op de Linux desktop. Je hebt het over Qt. Die heeft juist als voordeel dat deze cross-platform is. Neem bijvoorbeeld Steam.

Dat klopt, alle frameworks die ik noemde zijn cross platform te gebruiken (en ik geloof dat ik WxWidgets vergeten ben).

Het kán wel, maar als je software niet al in Qt geschreven is, waarom zou je? Steam is geport omdat Valve hoopte dat hun Steam boxes de gamemarkt zouden revolutioneren, wat uiteindelijk mislukte.

Er is een reden dat de meeste cross-platform-applicaties die ik zelf op Linux draai óf open source zijn óf gewoon Electron gebruiken. De enige uitzonderingen zijn de Telegram client, die al vanaf het begin in Qt is gebouwd, Firefox/Thunderbird en Chrome. Signal, Teams, Element/Riot.im, Slack, Bitwarden, Joplin, de Jetbrains suite, Ghidra, het draait allemaal op Electron of Java.

Tot Linux tien of twintig procent extra gebruikers weet te winnen op de desktop, denk ik gewoon niet dat het de moeite waard is voor een bedrijf als Microsoft om de moeite te steken in een port.

Steam is geport naar Linux omdat Microsoft dreigde met UWP. De Steam boxes waren meer conceptueel vziw.

Waarom Qt ipv bloated rommel als Java en Electron. Simpel, omdat native betere performance biedt, en je toch de native UI hebt plus bindings voor allerlei talen. Waarom wel Java of Electron? Luiheid, incompetentie, tijdgebrek, en het zijn joiw resources niet die de client draait.

Hier een waslijst aan Qt software https://en.m.wikipedia.org/wiki/Qt_(software) - > Qt in Use.

Een van mijn favoriete Qt applicaties is Ripcord. Deze zorgt er in het kort voor dat je fan niet spint als je Discord of Slack aan hebt staan...

Ook heeft Blizzard gelukkig voor Qt gekozen in geval van de Battle.net client. En zo zijn er wel meer voorbeelden.

En wat levert het Microsoft op, behalve een hoop bugmeldingen? Weinig, want praktisch niemand in de kantoorwereld draait op Linux. De ROI is simpelweg te laag om daar aan te beginnen.

Volgens mij is dat precies een waarom: Tel daar bij op dat de apple desktop gebruiker een loyaale betaler is en de linux gebruiker veel sneller bereid is om open source te gebruiken. En bij apple is er de vendor-lock-in van apple waar microsoft op haar manier op mee kan en wil liften. Bij linux is er niet zo'n software winkel. Wel kan daar gebruik gemaakt worden van office365, microsoft's eigen vendor-lock-in.

Dat is natuurlijk wel een kip-en-ei verhaal. Veel mensen gebruiken Windows omdat ze per se MS Office nodig hebben voor bijv werk. MS Office is de de facto standaard office suite en dus hebben veel mensen in de praktijk geen vrije OS-keuze. Pakketten als LibreOffice hebben wel steeds betere docx en xlsx ondersteuning maar 100% wordt dat natuurlijk nooit. Daarnaast weigert MS pertinent om up-to-date ODF-ondersteuning in te bouwen wat uitwisseling met andere office pakketten vrijwel onmogelijk maakt.

Wat gui's betreft. Azure Data Studio en Teams werken uitstekend in bijv KDE op Kubuntu. Blijkbaar is het bouwen van deze applicaties voor Linux distros geen probleem voor MS. Ik begrijp dat het niet makkelijk is om applicaties te bouwen die op meerdere distros functioneren maar als je de distros pakt die bij zowel zakelijke klanten als consumenten het populairst zijn dan kom je met een paar keuzes al een heel eind.

Voor met name het MKB is het draaiend houden van een goed severpark een kostbare zaak. Als je dan zou kunnen overstappen op een OS dat veel minder resources vergt dan Windows (wat een enorme resource vreter is geworden) en ook nog veel minder gevoelig is voor virussen en andere malware ellende dan is die ROI meteen een stuk hoger.

Er zijn amper Linuxgebruikers op de desktop

Dat kan zijn, maar ze zijn er.
Als je het hebt over 1,8% van de computer gebruikers (die overigens wel op internet moeten komen) dan heb je het over bijna 9 miljoen mensen. Hierbij worden mensen die geen internet verbinden hebben en dus alleen offline hun systeem gebruiken niet eens meegeteld.

onder die gebruikers is relatief weinig vraag naar Microsoft's closed-source pakketten

Dit is gebaseerd op welke feiten?

dependency management op Linux is een regelrechte hel als je meer dan alleen Ubuntu or Fedora wil ondersteunen

Dit is inmiddels zo achterhaalde uitspraak helemaal na de introductie van snap en flatpak

Daarnaast is de GUI van Office geschreven bovenop de GUI van Windows en macOS. Dat gaat op Linux natuurlijk niet werken. Om het werkend te krijgen moet je dus zorgen dat de GUI er normaal uitziet op KDE, GNOME, LXDE, XFCE en nog meer dingen eindigend op -E. Je moet kiezen of je een bestaand GUI-pakket wilt gebruiken (GTK+, GTK2, Qt, KDE) en uitzoeken welke libraries je mee moet nemen om er ook op andere omgevingen normaal uit te zien.

Ze maken zelf voor Teams en VCS op Linux al gebruik van electron, dit kan ook voor office waardoor jouw statement al komt te vervallen.

En wat levert het Microsoft op, behalve een hoop bugmeldingen? Weinig, want praktisch niemand in de kantoorwereld draait op Linux. De ROI is simpelweg te laag om daar aan te beginnen.

Inkomsten, bugmeldingen krijgen ze nu ook.

Dat er niet veel zijn wil niet zeggen dat ze er niet zijn en al helemaal niet dat er geen zijn of die liever om wat voor een reden dan ook over willen stappen naar een alternatief.
Als Exchange eenvoudiger te koppelen is in Linux en MS Office normaal draait, dan zullen er genoeg zijn die overstappen, waardoor er minder geld word verdient aan de diverse gebruikers overeenkomsten die MS heeft en dat is in mijn optiek de grootste reden dat ze Office niet voor Linux maken. De kans dat ze dan een deel (groot of klein) van hun userbase gaan verliezen is niet iets wat ze willen riskeren.
Dat ze wel voor Apple ontwikkelen is logisch, want daarmee nemen we een deel van de Apple gebruikers mee in hun eigen userbase.

Microsoft ziet linux meer als een server systeem, en office hoort op de desktop te draaien.

Omdat de desktopgebruikers (en dat zijn er al niet veel) zich ook nog eens graag versplinteren in tientallen GUI's. Ik zou er als bedrijf ook niet aan beginnen om dat allemaal bij te gaan houden voor een verwaarloosbaar aantal gebruikers die ervoor willen betalen.

Met een Microsoft 365 account kom je een heel eind zonder native support op Linux. Onze developers (op Ubuntu Linux of Mac) doen prima mee met de onedrive gedeelde presentaties en bestanden en de online tegenhangers van powerpoint en word.

Linux gebruikers willen toch geen closed source software? Dus waarom zou je daar een product voor gaan maken?

Je hebt natuurlijk wel de web versie. Maar ja, die is echt ruk. Dan kan je beter Google Docs nemen. Of een van de verscheidene desktop applicaties die wel compatible zijn.

... Totdat ze er bij je werk/opleiding op staan dat je Office gebruikt. En als je dan met meerderen een document aanpast via de webversie verdwijnt er om de haverklap tekst. Office Web is echt een heel slecht product.

Goed kijken wat ze eisen: Eisen ze "Office" Dan zijn er veel meer producten die dat in de naam hebben. Eisen ze het gebruik van een bestand formaat? LibreOffice spreekt alle doc en docx formaten die msOffice ook biedt. Eisen ze aansluiting bij een platform zoals sharepoint of zo? Eisen ze gebruik van templates met ingebouwde scripts, dan heb je een uitdaging.

Ze eisen vaak dat als je bestanden deelt of op een cloud zet, dit via Microsoft Office gaat. Andere diensten mogen niet. Als je dan ook nog bestanden samen moet bewerken valt LibreOffice al helemaal af.

Als je de weg weet in sharepoint (of je andere cloud omgeving), kan je de url omzetten naar een share of drive-map. Dat werkt ook binnen msOffice soepeler en daarmee kan je er ook met LibreOffice goed bij.

Toegegeven, het uit-en-inchecken gaat vanuit libre office niet zo soepel.

Maar LibreOffice synchroniseert dan niet in real-time. Is heel leuk als je met zijn 5 om een tafel zit te werken aan hetzelfde document, en iedereen is ineens zijn werk kwijt omdat 1 grappenmaker net via LibreOffice alles heeft overschreven.

Helaas heeft MS nog steeds geen Shared Mailbox optie beschikbaar in de nieuwe look en feel voor deze Outlook release... heel jammer, wacht er al 3 maanden op >_>

zie ook roadmap dev

Evenals Shared Calendars (komt in Januari/Februari in Beta Channel beschikbaar) en the Tasks en Notes modules die nu nog naar de webversie linken. Ik verwacht dat het nog een aantal maanden duurt voordat de nieuwe Outlook for Mac feature ready is. Gelukkig is makkelijk seamless switchen tussen de oude en nieuwe client.

klopt inderdaad; ook plugins werken maar half momenteel. en voor zo'n grote overhaul in syle en whatnot is het behoorlijk teleurstellend te noemen dat al deze functies er niet inzitten vanaf het begin... het switchen is makkelijk maar toch vind ik het jammer dat we er 3-6 maanden op moeten wachten

Ze nemen de tijd inderdaad maar dat komt ook omdat de onderliggende sync stack geheel vernieuwd is. Geen Exchange Web Servoces (EWS) meer maar hun modernere native sync stack die ook door Outlook for Mobile gebruikt wordt. Dus nieuwe functionaliteit toevoegen is niet enkel de UX en UI updaten in dit geval.

Daarnaast is het Office Engineering team voor Mac clients wel heel wat kleiner dan die aan de Windows kant, dus ze moeten regelmatig keuzes maken op wat prioriteit heeft en wat wordt aan de backlog toegevoegd.

Inderdaad, had dit ook ontdekt toen ik de nieuwe versie even had gepreviewd. Had gehoopt dat het met deze update ging meegekomen zijn maar blijkbaar dus niet. Wij stappen dus ook nog niet over, dit is voor ons de belangrijkste reden om Outlook te gebruiken. Thanks voor de link naar de roadmap.

Inderdaad, dat is nou net de reden om Outlook te gebruiken en niet Apple Mail...

Idd, al kan je in Apple Mail ook op de shared mailbox inloggen met de volgende gegevens:

[e-mail]/[e-mail]
wachtwoordvaneigenmailboxdietoegangheeft

Op:
outlook.office365.com

Maar erg stabiel werkt dit niet.

Klopt, maar dat moet dan weer aangepast worden zodra iemand zijn wachtwoord verlopen is. En je kan redelijkerwijs niet verwachten van gebruikers dat ze het zelf kunnen toevoegen op die manier, dat is met Outlook toch anders.

[Reactie gewijzigd door Metten op 16 december 2020 08:30]

Helaas heeft MS nog steeds geen Shared Mailbox optie beschikbaar in de nieuwe look en feel voor deze Outlook release... heel jammer, wacht er al 3 maanden op >_>

Oh dat is wel een grote tekortkoming, althans op mijn werk.

Kan je nog wel switchen naar de 'oude Outlook' zoals in de vorige versie? Want als dat niet meer kan, ga ik nog niet upgraden...

Dit is prima mogelijk, rechtsboven in de hoek zit een slider om terug naar de ‘oude’ look & feel te gaan; daarmee herstel je alle functionaliteit zoals je deze had

Je schrijft toch software (apps, programma's) voor het besturingssysteem en niet voor de daaronder liggende hardware?

Allebei

Reguliere desktop apps voor reguliere CPU's zijn zelden zo afhankelijk van de hardware dat je niet weg kan komen met een simpele recompile.

[Reactie gewijzigd door .oisyn op 16 december 2020 01:16]

ja en mobiele apps, wat eigenlijk het hele idee achter die M1 is, worden wel aangepast aan de hardware.

Hoe dichter tegen de cpu hoe beter het runt.

Jazeker, echter heeft Big Sur dus twee versies van het besturingssysteem. Een M1 versie (met Rosetta voor translatie), en een Intel-versie.

Men brengt nu dus ook twee versies van de apps uit.

Twee versies maar wel in èèn (Universal) installer. Deze werkt dus zowel voor Intel als voor Silicon Macs.

De architectuur is compleet verschillend, dus hoe meer low level je dingen programmeert, hoe meer problemen er gaan zijn als je van architectuur switcht. Ik studeer informatica en heb onlangs een programma in C/C++ moeten schrijven dat op x86 en ARM moet kunnen runnen (met elk een apart gecompileerde versie natuurlijk). Pas als je dit gaat testen, zie je dat er verschillende problemen opduiken. Een voorbeeldje hiervan is bijvoorbeeld de endianness (https://en.wikipedia.org/wiki/Endianness). Als ik het mij goed herinner, was dit voor een Intel chip big Endian, en voor een Raspberry Pi little endian. Hiermee moesten we dus onder andere rekening mee houden in onze code.
Dit is nu maar een klein voorbeeldje, maar ik vermoed dat bij het portten van apps het niet zozeer gaat om alles te herschrijven, maar problemen zoals deze op te lossen.

Ik ben best benieuwd, waar maakte endianness precies uit voor je opdracht? De meeste operaties waar de volgorde uitmaakt (bit shifts, bit masks, etc.) zijn voor zover ik weet in C++ niet afhankelijk van endianness. Ik moet zeggen dat het een tijd geleden is dat ik C++ gebruikt heb, maar ik kan me niet herinneren daar ooit tegenaan te zijn gelopen.

Het enige endianness-probleem dat mij kan heugen had te maken met netwerken, byte order vs network order, htons/ntohs en dat soort dingen, waar je ruwe bits zit uit te wisselen met andere apparaten. In dat geval wordt je als het goed is toch al geleerd de nodige wrapperfuncties aan te roepen dus zou code niet al te veel moeten veranderen, toch?

Het probleem dat we hadden ivm de endianness zat in het C gedeelte. Er moesten gegevens ingeladen worden uit een DAT bestand. Bij enkele conversies naar integers gaf dit problemen, welke gefixt konden worden door de vernoemde ntohs. Ik weet het allemaal niet exact omdat de opdracht per twee was, en ik niet verantwoordelijk was voor dit deel, maar op wat ik net gezegd hebt komt het eigenlijk neer

Ah, zo. In de praktijk denk ik niet dat je dat probleem zult hebben, omdat je als het goed is je databestanden al met een functie als ntohs in een bepaalde volgorde opslaat als je je data serialiseert. Als andere mensen het formaat bepalen of als andere programma's met je formaat klooien, moet je natuurlijk wel het eea voorbereiden, maar zelfs dat klinkt niet al te lastig om op te lossen eigenlijk.

Juist bij de shift operatoren is de endianes belangrijk: Een shift-left is vermenigvuldigen met 2 of delen door 2. En bij het opslaan en bij de telecom is de endianes zeker relevant. Als het in de taal wordt afgevangen dan is het mooi maar dan moet je er op een andere manier niet bij kunnen.

Ooit heb ik hier in pascal en modula-2 gebruik van kunnen maken, maar zelfs daar had TurboPascal, die het goed zou moeten doen, een uitdaging tussen de 68000 en de 8086. Modula-2 deed dat 'vele beter', daar heb je (in de pure taal) die operators gewoon niet.

Juist bij de shift operatoren is de endianes belangrijk: Een shift-left is vermenigvuldigen met 2 of delen door 2

En dus maakt de endianness in z'n geheel niets uit bij een shift. Net als bij andere berekeningen. Endianness zegt niets over waar conceptueel de most en least significant bit in het getal staat. Het zegt alleen iets over de volgorde waarin de bytes van het getal in het geheugen staan.

Als ik het mij goed herinner, was dit voor een Intel chip big Endian, en voor een Raspberry Pi little endian

Intel is altijd al little-endian geweest, en de standaard RPi distributies zijn dat ook. De meeste ARM architecturen ondersteunen overigens allebei, er is volgens mij wel een big-endian distributie te krijgen voor de Pi die de CPU dus ook in die mode zet.

De Apple M1 is overigens ook gewoon little endian.

[Reactie gewijzigd door .oisyn op 16 december 2020 01:11]

Klopt, de API is het allerbelangrijkste onderdeel. Op hardware-niveau kom je vooral in de problemen met verschillen in endianness (hier niet van toepassing) en race conditions, maar dat laatste vooral omdat je je al niet aan de regels hield en het "toevallig" gewoon werkte op een andere architectuur. Als je daarentegen altijd de juiste synchronisatie-primitieven met de juiste semantics (acquire/release/etc) gebruikt, dan werkt je code gewoon cross-platform.

[Reactie gewijzigd door .oisyn op 16 december 2020 01:18]

Zou je dit in iets meer lekentermen kunnen uitleggen?

En is dan eigenlijk de enige hardware die hiervoor van belang is, de machinetaal op de cpu en evt gpu?

Je schrijft voor een platform. Dat is de combinatie van het OS (eigenlijk de APIs die men beschikbaar maakt) alsook de architectuur van de hardware. Daarom dat je een x86 app niet zonder meer kunt draaien op een ARM CPU. Deze moet gehercompileerd worden voor dat platform. En hoewel men heel veel in de compiler kan afvangen, zitten er vaak kleine verschillen in. Je moet soms andere bibliotheken aanspreken of sommige calls net iets anders maken. De hoeveelheid aanpassingen in een project zoals MS Office gaat procentueel verwaarloosbaar zijn, maar het zou me echt verbazen als ze gewoon op de compile knop konden klikken en geen enkele fout tegen komen.

En de machinetaal op de gpu dan denk ik ook?

...hopelijk forceren ze dan NIET de nieuwe outlook die al een paar maanden optioneel is op mn mac: die ondersteunt namelijk geen pop3 en imap accounts. lekker handig, voor een MAILCLIENT

Waarom is er een Mac versie van Publisher ? Ik moet nu op mijn Mac Virtual Box installeren en daarin Windows installeren met Publisher erop.

Ik geloof niet echt dat daar zo veel vraag naar is omdat vrijwel alle professionals gewoon InDesign gebruiken voor desktop publishing

Publisher lijkt me toch niet echt voor de professionals (of ik kan het fout hebben, ik lig er alweer een possje uit).
Als je publisher in je office pakket erbij hebt zitten waar je makkelijk met de office look en feel simpele dingetjes in kan maken, dan wil je niet nog weer een compleet ander pakket aankopen en leren.

Publisher lijkt me toch niet echt voor de professionals

Dat zeg ik

Dat snap ik. Ik bedoelde dus dat publisher juist voor de gewone office gebruiker heel erg handig is. Die gaat dis niet overstappen naar indesign.
De professionals zullen eerder naar indesign gaan inderdaad.
Dat Publisher nooit is toegevoegd met een Mac versie is toch wel vreemd.

Afaik, de Mac Publisher app zit deels al in Word, via Pusblishing Layout.

Jammer dat je meteen minnetjes krijgt. Lijktme toch een reëler vraag. In ieder geval er van uit gaand dat je bedoeld "Waarom is er Geen Mac versie van publisher". Publisher is (was altijd) toch wel een onderdeel van de office paketten op windows. Tijdenlang wel dingen in gemaakt.
Nu op een Mac mis je die toch wel zo af en toe.

Waarom is er een Mac versie van Publisher ?

Ik neem aan dat je *geen* bedoelt? Maar er zijn wel meer Office-applicaties die missen... Access en vooral Visio mis ik veel harder.

Wel eens Affinity Publisher overwogen? Affinity is ook hard aan de stoelpoten van Adobe aan het zagen, met betaalbare alternatieven voor Illustrator en Photoshop.

Ik moet nu op mijn Mac Virtual Box installeren en daarin Windows installeren met Publisher erop.

Gaat dat straks op M1 nog werken? Virtualisatie-software translaten met Rosetta lijkt me tricky...

Dit is een stap vooruit voor de "nieuwe" ARM achitectuur, sta op afwachting te wachten wat windows onder hun mouw vandaan gaat halen om appel hiermee in te halen.

Ben benieuwd of Dell, Hp of microsoft zelf ARM in hun laptops zal stoppen. Zodanig dat windows de os, zoals appel er gemakkelijk mee kan werken zonder de virtualisatie dat windows op dit moment gebruikt.

Microsoft surface pro x heeft een ARM cpu. Zeer leuke tablet/laptop buiten de performance (voor mijn gebruik)

Dat is snel. Maar toen Office 2010 en 2016 naar x64 geupgrade moest worden toen MacOS Catalina uitkwam was Microsoft nergens te bekennen.

Behaalde resultaten uit het verleden geven geen garantie voor de toekomst

MS heeft de laatste jaren hard gewerkt aan zijn grootste, belangrijkste producten om een uniforme codebase te krijgen. Met Office 2019 is de Mac versie van Office gebasseerd geweest op de Windows versie. Alles uit 1 basis. Ongetwijfeld heeft het werk dat ze voor hun eigen ARM conversie gedaan hebben hen een voordeel gegeven toen Apple met ARM kwam aanzetten. Maar MS staat vandaag ook veel positiever tegenover dit soort veranderingen dan 5 of 10 jaar terug.

Ik had de beta al draaien. Bizar de snelheid, hij opent instant.

Echt bizar wil ik het niet noemen maar op mijn M1 MBA ben ik ook verbaasd over de snelheid van deze versie. Zeker vergelen met de Intel versie die op mijn 2019 MBP nogal wat tijd nodig had om op te starten.

Ik denk dat je het moet zien om het verschil te merken. Dit is meer alsof je een telefoonapp opent. Het verschil tussen een halve seconde en enkele milliseconden.

Dit is meer alsof je een telefoonapp opent.

Op mijn iPhone 6 opent bv. de Teams app tergend langzaam. Iets afdoen als een 'telefoonapp' is niet exact een goede indicatie, zeker gezien de verschillende apps beschikbaar en de vele generaties smartphones van verschillende 'kracht'/generatie...

Telefoon apps zijn vaak allesbehalve instant. Misschien krijg ik instant een wit scherm dat nog moet worden opgebouwd. Verschilt ook heel erg per applicatie.

Hier snel te vinden en te downloaden (legaal): https://macadmins.software
Build 16.44 is inderdaad de Universal. Top!

Bij mij werd de update zelf aangegeven.

Voor een nieuwe installatie, waarom zou je jouw website gebruiken? Ik zou zelf nooit dingen downloaden via links van een 3rd party.

Dit zijn directe download-links naar Microsofts CDN. Deze site wordt gehost door 1 van de Office for Mac engineers van Microsoft.