<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Disqus - Latest Comments for asbjornu</title><link>http://disqus.com/by/asbjornu/</link><description></description><atom:link href="http://disqus.com/asbjornu/comments.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Tue, 19 Aug 2025 05:39:44 -0000</lastBuildDate><item><title>Re: Designing a True REST State Machine</title><link>https://nordicapis.com/designing-a-true-rest-state-machine/#comment-6754487271</link><description>&lt;p&gt;Hi, and sorry for the late reply. I'll try to answer your questions as best I can.&lt;/p&gt;&lt;p&gt;1. "rel" is short for "relation", known from the HTML attribute with the same name and purpose. In your own hypermedia format, you can choose any name for this property you want, such as "name", "type", "operation", or similar.&lt;br&gt;2. The point of the different URIs is that the structure of the URIs doesn't matter in a truly RESTful API, since the client should be served the URI by the server and follow them through named link relations and operations. Only the link relations and operations are hard coded in the client, not the structure of the URIs.&lt;/p&gt;&lt;p&gt;Indeed, as I've pointed out in my 2016 talk "The REST And Then Some" (as this article is based upon) and elsewhere; REST is not CRUD. Modelling rich domain operations in REST is not only possible, but highly recommended. Limiting your REST API design to CRUD will only lead to an API that is difficult to use.&lt;/p&gt;&lt;p&gt;Regarding how to design hypermedia operations, OpenAPI doesn't really offer a way to do it. Indeed, OpenAPI encourages you to instead document the URI structure, requiring lots of hard coding an little flexibility in the client. It might be worth investigating another format that supports hypermedia out of the box, such as Siren or Hydra.&lt;/p&gt;&lt;p&gt;However, if you insist on using OpenAPI, I would model the hypermedia controls as named "operations" with specified request and response types, and allow the server to embed the available operations in the response.&lt;/p&gt;&lt;p&gt;I recommend that you watch my "The REST And Then Some" talk and read my follow-up article "REST State Machine Revisited" to get more food for thought:&lt;/p&gt;&lt;p&gt; &lt;a href="https://nordicapis.com/rest-state-machine-revisited/" rel="nofollow noopener" target="_blank" title="https://nordicapis.com/rest-state-machine-revisited/"&gt;https://nordicapis.com/rest-state-machine-revisited/&lt;/a&gt; &lt;br&gt; &lt;a href="https://www.youtube.com/watch?v=QIv9YR1bMwY" rel="nofollow noopener" target="_blank" title="https://www.youtube.com/watch?v=QIv9YR1bMwY"&gt;https://www.youtube.com/watch?v=QIv9YR1bMwY&lt;/a&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Tue, 19 Aug 2025 05:39:44 -0000</pubDate></item><item><title>Re: Exclusive: Apple testing new external display with a dedicated A13 chip and Neural Engine</title><link>https://9to5mac.com/2021/07/23/exclusive-apple-testing-new-external-display-with-a-dedicated-a13-chip-and-neural-engine/#comment-5467074324</link><description>&lt;p&gt;Perhaps the Mac Pro isn't the intended video source of this display? The Macs that actually have use for external GPU acceleration are the Mac Mini and MacBooks, not the Mac Pro. Being able to plug a laptop into a monitor that serves as an external display,  eGPU, charger and connectivity hub sounds like a dream to me.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Fri, 23 Jul 2021 16:44:27 -0000</pubDate></item><item><title>Re: Windows 11 hands-on: A Mac user’s perspective on the new design and what Apple could learn</title><link>https://9to5mac.com/2021/06/29/windows-11-hands-on-a-mac-users-perspective-on-the-new-design-and-what-apple-could-learn/#comment-5439408072</link><description>&lt;p&gt;Sensible defaults shouldn't be configurable. They should be the default.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Wed, 30 Jun 2021 18:30:55 -0000</pubDate></item><item><title>Re: Understanding how Universal Control works (and how it doesn’t)</title><link>https://9to5mac.com/2021/06/08/how-universal-control-works/#comment-5413626114</link><description>&lt;p&gt;Name one KVM app that doesn't require ANY configuration (besides being logged in to an iCloud account, which I assume well over 99% of all Apple devices are).&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Wed, 09 Jun 2021 08:13:56 -0000</pubDate></item><item><title>Re: API Change Strategy</title><link>https://nordicapis.com/?p=7717#comment-5404885903</link><description>&lt;p&gt;I don't think we are in disagreement about anything. I just didn't go deep into the wonders of hypermedia in this blog post. If you haven't, please read this as it will hopefully reflect many of your thoughts as well.&lt;/p&gt;&lt;p&gt;&lt;a href="https://nordicapis.com/rest-state-machine-revisited/" rel="nofollow noopener" target="_blank" title="https://nordicapis.com/rest-state-machine-revisited/"&gt;https://nordicapis.com/rest...&lt;/a&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Tue, 01 Jun 2021 18:18:37 -0000</pubDate></item><item><title>Re: Opinion: Apple Music needs these features and fixes to catch up to Spotify</title><link>https://9to5mac.com/2021/03/13/opinion-apple-music-needs-these-features-and-fixes-to-catch-up-to-spotify/#comment-5304722312</link><description>&lt;p&gt;My personally largest quarrel with Apple Music is that it's not integrated into the music library Apple already built with iTunes. So instead of choosing to buy or stream a single song, I have to choose to stream all songs and not purchase a single one before even performing a search. That is just messed up and makes no sense whatsoever.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Mon, 15 Mar 2021 09:26:14 -0000</pubDate></item><item><title>Re: API Change Strategy</title><link>https://nordicapis.com/?p=7717#comment-5295799616</link><description>&lt;p&gt;Try not to do API versioining at all. Think more in terms of evolving resources. If you write a hypermedia-driven API, you may use a format that has rich capabilities to describe hypermedia controls (think HTML forms). In that case, you're free to change the hypermedia controls as long as the client has all the data required to fulfill the needs. You're free to add optional properties and even required ones as long as they have default values or the client are able to provide them with a value.&lt;/p&gt;&lt;p&gt;If you need to introduce breaking changes, consider whether the resource itself is the same or whether you may be inventing an entirely new resource. Reconsider the bounded context and whether the boundary you've drawn around the new, breaking resource, fits correctly into the same boundary as the old resource. If you still conclude that you need to introduce a breaking change, consider introducing it through configuration, where you toggle consumers onto the new breaking change gradually through a switch in a backend administration interface. Then you know precisely who uses the new feature based on the state of the toggle and can communicate with everyone who haven't upgraded yet, providing them with incentives to go through with the upgrade.&lt;/p&gt;&lt;p&gt;In the end, my point is that slapping a version number on a web API seems like a simple solution to a simple problem, while in fact it is a very naïve solution to a very complex problem. Think hard about the problem and figure out a strategy before you turn to versioning. And when you do turn to versioning, do it in a granular, nimble and measurable manner, backed by a communication strategy, so you you're not stuck in the "knot" having to maintain X number of versions of your API forever.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Mon, 08 Mar 2021 05:32:02 -0000</pubDate></item><item><title>Re: iPhone punch-hole display next year: Is it a realistic option? - 9to5Mac</title><link>https://9to5mac.com/2021/03/02/iphone-punch-hole-display/#comment-5289194720</link><description>&lt;p&gt;The best would be both. Touch ID is  terrible when wearing gloves, having wet hands, wearing a band-aid on the key finger, etc., while Face ID only works at a minimum distance so is bad when lying on stomach in bed, when wearing a mask, when eating, etc. Having both would reduce the number of times I'd have to use the code to 0.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Tue, 02 Mar 2021 18:33:30 -0000</pubDate></item><item><title>Re: Dette er en konspirasjonsteori</title><link>https://politainment.no/2021/01/16/dette-er-en-konspirasjonsteori/#comment-5243916385</link><description>&lt;p&gt;Ytringen jeg henviser til er etter all sannsynlighet ulovlig i Norge. Det er også sannsynlig at den ville blitt erklært ulovlig i USA om noen tok den til retten. Ytringsfriheten er ikke absolutt og uten unntak i noen land i verden, inkludert i USA.&lt;/p&gt;&lt;p&gt;&lt;a href="https://en.wikipedia.org/wiki/United_States_free_speech_exceptions" rel="nofollow noopener" target="_blank" title="https://en.wikipedia.org/wiki/United_States_free_speech_exceptions"&gt;https://en.wikipedia.org/wi...&lt;/a&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Wed, 27 Jan 2021 10:38:05 -0000</pubDate></item><item><title>Re: Dette er en konspirasjonsteori</title><link>https://politainment.no/2021/01/16/dette-er-en-konspirasjonsteori/#comment-5243913227</link><description>&lt;p&gt;Stalin, Mao og Pol-Pot har venstresiden tatt ansvar for og oppgjør med. Mussolini, Hitler, Pinochet og Franco må høyresiden ta ansvar for. Men det gjør dere ikke, dere omskriver i stedet historien og vrir på fakta for å fraskrive dere alt ansvar slik at høyresiden i praksis gjenstår helt historisk plettfri uten ett eneste menneskeliv på samvittigheten. Det er både historieløst og uredelig.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Wed, 27 Jan 2021 10:35:42 -0000</pubDate></item><item><title>Re: Dette er en konspirasjonsteori</title><link>https://politainment.no/2021/01/16/dette-er-en-konspirasjonsteori/#comment-5242250805</link><description>&lt;p&gt;Selvfølgelig synes jeg ikke det er greit at Twitter lar slikt passere. Jeg har imidlertid inntrykk av at det er mindre systematisk og omfattende på Twitter enn på Parler. Dessuten mener jeg at selv om Twitter ikke er raskt nok ute med å stenge ned misbruk og overtramp, eller at Gab er mye verre enn Parler, er en dårlig unnskyldning for å holde liv i Parler.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Tue, 26 Jan 2021 03:59:06 -0000</pubDate></item><item><title>Re: Dette er en konspirasjonsteori</title><link>https://politainment.no/2021/01/16/dette-er-en-konspirasjonsteori/#comment-5241316407</link><description>&lt;p&gt;At Parler også ble brukt til legitime, lovlige, gode diskusjoner blir som å si at nazister også har positive egenskaper. Med ditt forsvar av Parler er ytringer som dette noe du ønsker fritt ytret og publisert.&lt;/p&gt;&lt;p&gt;Jeg mener imidlertid at når slike ytringer slipper gjennom den "moderasjonen" Parler hadde, så fortjener hele plattformen å bli slettet fra Amazon sine servere.&lt;/p&gt;&lt;p&gt; &lt;a href="https://uploads.disquscdn.com/images/798e6e1514435689973c94202bb53f69783abceb38a36bf80845e03a994bf439.png" rel="nofollow noopener" target="_blank" title="https://uploads.disquscdn.com/images/798e6e1514435689973c94202bb53f69783abceb38a36bf80845e03a994bf439.png"&gt;https://uploads.disquscdn.c...&lt;/a&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Mon, 25 Jan 2021 12:38:38 -0000</pubDate></item><item><title>Re: Dette er en konspirasjonsteori</title><link>https://politainment.no/2021/01/16/dette-er-en-konspirasjonsteori/#comment-5241310779</link><description>&lt;p&gt;Nei, jeg gjør mitt beste for å avstå fra ad hominem-angrep i debatter. Hvorfor tror du jeg mener du er en nazist?&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Mon, 25 Jan 2021 12:34:23 -0000</pubDate></item><item><title>Re: Dette er en konspirasjonsteori</title><link>https://politainment.no/2021/01/16/dette-er-en-konspirasjonsteori/#comment-5241142417</link><description>&lt;p&gt;Forskjellen på Parler og de fleste andre sosiale medier var at Parler ikke drev noen form for moderering og tillot derfor ytringer som er ulovlige i de fleste land, som f.eks. drapstrusler, beskrivelser av ekstrem vold mot kommunister, osv. å florere.&lt;/p&gt;&lt;p&gt;Slikt innhold vil føre til at kontoen din blir stengt nokså øyeblikkelig på Facebook, Twitter, osv., men på Parler ble slikt innhold beskyttet og fikk spre seg helt fritt. Når både ytringene er ulovlige og man fra forskning vet at hatprat fører til vold, er det farlig å la en slik tjeneste være tilgjengelig. Troll sprekker ikke i lyset, de formerer seg.&lt;/p&gt;&lt;p&gt;&lt;a href="https://www.researchgate.net/publication/323445855_Hatefulle_ytringer_Delrapport_2_Forskning_pa_hat_og_diskriminering" rel="nofollow noopener" target="_blank" title="https://www.researchgate.net/publication/323445855_Hatefulle_ytringer_Delrapport_2_Forskning_pa_hat_og_diskriminering"&gt;https://www.researchgate.ne...&lt;/a&gt;&lt;/p&gt;&lt;p&gt;&lt;a href="https://onlinelibrary.wiley.com/doi/abs/10.1111/pops.12670" rel="nofollow noopener" target="_blank" title="https://onlinelibrary.wiley.com/doi/abs/10.1111/pops.12670"&gt;https://onlinelibrary.wiley...&lt;/a&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Mon, 25 Jan 2021 10:18:39 -0000</pubDate></item><item><title>Re: Dette er en konspirasjonsteori</title><link>https://politainment.no/2021/01/16/dette-er-en-konspirasjonsteori/#comment-5241116610</link><description>&lt;p&gt;Jeg antar at referansen til "nynazister" gjelder Parler og ikke Signal. At Parler var yngleplass for nazister og white supremasists hersker det ingen tvil om.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Mon, 25 Jan 2021 09:57:29 -0000</pubDate></item><item><title>Re: Dette er en konspirasjonsteori</title><link>https://politainment.no/2021/01/16/dette-er-en-konspirasjonsteori/#comment-5241113519</link><description>&lt;p&gt;Med din logikk er Den demokratiske folkerepublikken Korea og  Deutsche Demokratische Republik demokratiske stater og Buffalo Wings laget av vinger av bøffel-okser. Hvilket navn noen velger å gi noe sier ikke nødvendigvis så mye om innholdet.&lt;/p&gt;&lt;p&gt;Det vi vet om Nazismens politikk er at den økonmisk befinner seg litt til høyre for sentrum, bl.a. fordi de bevarte privat kapital og eierskap, samt privatiserte statlige bedrifter i et så stort tempo at The Economist måtte finne opp ordet "privatisering" for å beskrive fenomenet:&lt;/p&gt;&lt;p&gt;&lt;a href="https://no.wikipedia.org/wiki/Privatisering#Etymologi" rel="nofollow noopener" target="_blank" title="https://no.wikipedia.org/wiki/Privatisering#Etymologi"&gt;https://no.wikipedia.org/wi...&lt;/a&gt;&lt;/p&gt;&lt;p&gt;Selv om de aller fleste institusjoner i nazi-Tyskland var privateid, hadde de ikke full handlefrihet, noe som gjør at samfunnet ikke var økonomisk libertariansk på noen måte, men det var heller ikke statlig eierskap med formål om distribusjon av penger og makt som var hensikten med den sentrale planleggingen til nazistene, men opprustning til krig. Dette er sentralt i Fascismen.&lt;/p&gt;&lt;p&gt;Men politisk tilhørighet handler om mye mer enn økonomi. Der de fleste politiske partier kan inngå kompromisser om økonomiske modeller, er det verdigrunnlag som utgjør de tydeligste og ufravikelige skillene som gjør samarbeid på tvers av det politiske spektrum vanskelig.&lt;/p&gt;&lt;p&gt;Det som plasserer nazismen trygt på høyresiden er derfor  ikke den økonomiske politikken, men verdigrunnlaget. Nazistene var (og er) ultra-konservative nasjonalister. Det er de konservative holdningene som aller tydeligst plasserer nazismen på høyresiden.&lt;/p&gt;&lt;p&gt;Dette blir tydelig når man kjenner opprinnelsen til skillet mellom høyre- og venstresiden i politikken: Det franske parlamentet etter den franske revolusjon, der de som satt til høyre for "le président" ønsket seg tilbake til "Ancien Régime" (gammelt styresett, dvs. et kongelig diktatur med hoff og embedsverk). Konservative til høyre, progressive og revolusjonære til venstre.&lt;/p&gt;&lt;p&gt;Historisk sett tar du dermed så feil som det er mulig å ta og bør lese litt flere bøker før du uttaler deg ytterligere.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Mon, 25 Jan 2021 09:54:47 -0000</pubDate></item><item><title>Re: Dette er en konspirasjonsteori</title><link>https://politainment.no/2021/01/16/dette-er-en-konspirasjonsteori/#comment-5240984326</link><description>&lt;p&gt;Heartbleed skjedde fordi OpenSSL var en varslet og underfinansiert katastrofe.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Mon, 25 Jan 2021 07:43:55 -0000</pubDate></item><item><title>Re: Dette er en konspirasjonsteori</title><link>https://politainment.no/2021/01/16/dette-er-en-konspirasjonsteori/#comment-5240982738</link><description>&lt;p&gt;Apple vet for eksempel hva binærfilen inneholder. Alle apps som blir publisert blir grundig testet, det er derfor spredning av virus, phishing og annen svindel er fraværende på Apple sine App Stores i motsetning til på Google Play der manuell moderasjon er fraværende.&lt;/p&gt;&lt;p&gt;Diskusjon om å kunne kryptografisk verifisere at binærfilen i App Store ikke er endret ifht. kildekoden som ligger åpent på GitHub diskuteres også åpent på GitHub:&lt;/p&gt;&lt;p&gt;&lt;a href="https://github.com/signalapp/Signal-iOS/issues/641" rel="nofollow noopener" target="_blank" title="https://github.com/signalapp/Signal-iOS/issues/641"&gt;https://github.com/signalap...&lt;/a&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Mon, 25 Jan 2021 07:41:58 -0000</pubDate></item><item><title>Re: Poll: Which rumored upcoming Apple Silicon Mac are you most excited to see?</title><link>https://9to5mac.com/2021/01/19/apple-silicon-mac-poll/#comment-5233986396</link><description>&lt;p&gt;I know, it doesn't seem likely. But I remember Apple being both best and cheapest in its segment with the MacBook Air. With some iPad models, they are at the same quality/price equilibrium in the tablet market. With the margins they are able to crank up with their own SOC, I can't really accept that they can't reach that equilibrium in the laptop market again as well.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Tue, 19 Jan 2021 18:53:55 -0000</pubDate></item><item><title>Re: Poll: Which rumored upcoming Apple Silicon Mac are you most excited to see?</title><link>https://9to5mac.com/2021/01/19/apple-silicon-mac-poll/#comment-5233875737</link><description>&lt;p&gt;I'm a bit disappointed that they didn't introduce a truly low-cost MacBook at the price level of an iPad. Considering the insane speeds of the M1 macs they have released, they could have cut that in half and still deliver a great machine at a much lower cost.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Tue, 19 Jan 2021 17:16:20 -0000</pubDate></item><item><title>Re: Johns Hopkins security researchers ‘shocked’ at Android and iOS vulnerabilities</title><link>https://9to5mac.com/2021/01/14/johns-hopkins-ios-vulnerabilities/#comment-5227655354</link><description>&lt;p&gt;Trashing the keys after use would indeed hurt performance, but it would be nice if Apple gave users (or companies, enforced via MDM) a choice between security and performance.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Thu, 14 Jan 2021 18:02:56 -0000</pubDate></item><item><title>Re: Here’s everything Apple didn’t announce at its November Mac event</title><link>https://9to5mac.com/2020/11/13/everything-apple-didnt-announce-november-event/#comment-5152001678</link><description>&lt;p&gt;"Maybe grow up a little" was unnecessary and MM's reaction was not uncalled for. I think it's necessary and important to acknowledge that Apple has become too expensive across their entire product range. Even with my salary having increased beyond inflation I still pay a proportionally larger amount of my salary for every piece of Apple device I buy now than I did 10 years ago.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Sat, 14 Nov 2020 18:39:51 -0000</pubDate></item><item><title>Re: Designing a True REST State Machine</title><link>https://nordicapis.com/designing-a-true-rest-state-machine/#comment-5033542905</link><description>&lt;p&gt;That would be up to the media type to define. As with HTML, some types of content can come pre-filled from the server (like hidden input fields) and some content can come typed, but without value (such as range fields for integer values or e-mail input fields only accepting e-mail addresses). Whenever a client finds these sorts of fields, it will have to render a form control corresponding to the hypermedia control that is expected by the server. If your client is a web browser, you can even use HTML for this and allow the API to communicate in both JSON and HTML through content negotiation.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Mon, 17 Aug 2020 03:55:44 -0000</pubDate></item><item><title>Re: Former Intel engineer says Skylake problems were turning point for Apple’s ARM Mac transition</title><link>https://9to5mac.com/2020/06/24/former-intel-engineer-says-skylake-problems-were-turning-point-for-apples-arm-mac-transition/#comment-4968016195</link><description>&lt;p&gt;There is decades of history proving Microsoft isn't able to move as much as an inch towards transitioning from one CPU architecture to another. They have added support for various architectures over the years, but they are too deep into x86-32 and are too afraid to scare any of their customers to transition away from it. Not even a 100% compatible x86-32 emulation layer would cut it. Microsoft obviously has the competency to do this, but tech isn't calling the shots in Microsoft, business and marketing is. They just aren't bold enough.&lt;/p&gt;&lt;p&gt;In a few years, when Apple has transitioned from Intel to ARM, Apple has been able to go from PowerPC to x86-32 to x86-64 to ARM32 to ARM64 in a timeframe where Microsoft haven't been able to move a single inch. It's amusing and depressing at the same time. But seeing how much I despise Windows, it's mostly amusing as I want nothing more than for that OS to just die in the swamps of outdated irrelevancy, just like Internet Explorer.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Thu, 25 Jun 2020 12:55:04 -0000</pubDate></item><item><title>Re: Former Intel engineer says Skylake problems were turning point for Apple’s ARM Mac transition</title><link>https://9to5mac.com/2020/06/24/former-intel-engineer-says-skylake-problems-were-turning-point-for-apples-arm-mac-transition/#comment-4968001368</link><description>&lt;p&gt;How do you measure "best"?&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Asbjørn Ulsberg</dc:creator><pubDate>Thu, 25 Jun 2020 12:43:30 -0000</pubDate></item></channel></rss>