ARM i var fjärde bärbar dator om fem år

Fördelen med Docker är att man får isoleringen

Fixas det ett väl fungerade Windows till ARM så kan jag vara intresserad. Förutsatt att prestandan är bättre eller mer prisvärd.

AMD borde inte avbrutit K12 utan även fortsatt utveckla ARM-processorer.
Hoppas det även kommer bra RISC-V lösningar framöver.

K12 var ett R&D-intensivt projekt. Tror AMD i det läget behövde alle man på däck för ryzen

Jag kör Raspberry Pi med Ubuntu, har en Mac M1 och dessutom en Microsoft Surface Pro X med Arm processor.

Windows på Arm är det inget fel på, nackdelen är att inte alla program kör native Arm ännu.

På Surface Pro X använder jag mest Firefox, Spotify och Photoshop (som alla är native Arm) men det är många program som inte är kompilerade för Arm ännu.

Microsoft måste också bli bättre på att tydliggöra vilka appar i Microsoft store som är x86 och vilka som är Arm - i dagsläget måste man leta aktivt på nätet för att hitta Arm-versionen av program/appar.

K12 var ett R&D-intensivt projekt. Tror AMD i det läget behövde alle man på däck för ryzen

Initialt hade Windows bara stöd för att köra x86 program, d.v.s. 32-bit x86 kod.

I Windows 11 lades inte bara stöd för att köra x86_64 till (i grunden exakt samma teknik Apple använder i Rosetta 2), med det Microsoft kallar Arm64EC kan samma process blanda ARM64 och x86_64 kod.

"Code built as Arm64EC is interoperable with x64 code running under emulation within the same process. The Arm64EC code in the process runs with native performance, while any x64 code runs using emulation that comes built-in with Windows 11. Even if your app relies on existing dependencies or plugins that don't yet support Arm, you can start to rebuild parts of your app as Arm64EC to gain the benefits of native performance."

Microsoft känner nog att något likt Arm64EC är nödvändigt för att kunna göra ett väldigt gradvis införande av ARM64 kod i Windows. Det har varit x86/x86_64 only så länge, övergången till x86_64 tog ju brutalt mycket längre på Windows än det gjorde på t.ex. Linux och MacOS!

Ovanpå detta har Windows 11 även den form som erbjuds i Rosetta 2, d.v.s. möjlighet att köra "rena" x86_64 binärer.

Intressant. Tack för svaret!
Antar att gamla program med 32-bit x86 kod bara är att glömma?

Edit: eller kanske bara jag som är trög. 32-bit x86 fungerar redan på Windows ARM.

Vad betyder "hårdvarustödda virtuella maskiner" mer än att den isolering de erbjuder numera har olika former av HW-acceleration i kisel?

Hypervisors ("VMs") och OS-kärnor gör i grunden exakt samma sak: de hanterar resurser och erbjuder olika former av services till sina "applikationer", en av de viktigaste services man erbjuder är isolering från övriga "applikationer".

För en hypervisor är applikationerna OS-kärnor, för OS-kärnor är applikationer "vanliga" applikationer (user-land processer).

HW-stödet för isolering kommer primärt ned till MMU. Hypervisors har en MMU av MMUs, kärnor har en MMU.

Båda har buggar, både i programvara och definitivt även i HW (nu när AMD börjar få en relevant andel i datacenter börjar också antalet hittade HW-buggar ökar rejält, tyvärr lär samma gälla ARM64 men där finns ändå fundamentala fördelar i att det är en långt renare/enklare ISA).

Hypervisors och OS-kärnor har olika uppgifter. Om vi delar dator-HW i ett datacenter används naturligtvis en hypervisor för att ge oss en OS-kärna var.

Men som utvecklare/organisation, ge ett enda relevant use-case (utöver att man av någon anledning måste köra saker på olika OSes) där det finns en fördel med VMs över containers. Det man vill uppnå är separation mellan olika services, containers har en högre grad av isolation än "vanliga" applikationer och egentligen räcker det stöd OS:et ger, men av pakteringsmässiga och mer eller mindre dålig ingenjörskonst i programmeringdesign har det visat sig väldigt fördelaktigt att paketera services i "containers".

Själva containers/applikationer har aldrig behövt köras som root, däremot behövde docker-services:eb köras som det för att kunna göra sin "magi" mot Linux cgroups/namespaces.

Detta var ett problem som löstest i kärnan 2016 med cgroups v2 och som markerats "stabilt" i Docker sedan 2020, v20.10.

Värt att notera är att Docker-desktop (Windows/MacOS) aldrig behövt köras som root då man där kör QEMU under huven då containers faktiskt kör Linux.

Edit: och att man alltid kan köra som "root" i containers är ju inget problem. Detta är ju en funktion hos Linux namespaces där både PIDs (via PID namespace) och användare (via USER namespace) har ett värde inuti container, men har något annat på "host" (så root i container kan vara vilken användare som helst på host).

Finns det någon som helst möjlighet att köra x86 program på Windows ARM? Emulator eller liknande?

Du har fått flera bra svar men kan bara flika in att det inte är alltid det fungerar ändå.

Jag har exempelvis testat 'Mullvad VPN' för Windows på min Surface Pro X som alltså är x86 och den installeras OK, men kan ändå inte ansluta till tjänsten.

Det kan säkert behövas en native ARM från Mullvad för att det ska fungera.

Det är därför hypervisors inte är poänglösa. De har högre kostnad, men de isolerar även OS-kärnor.
Är därför vettigt att använda hypervisors för att partionera olika organisationer som delar HW. Olika organisationer har i normalfallet ingen anledning att lita på varandra.

Men i grunden gäller ändå: kan du inte lita på OS-kärnan är du ändå rökt. Graden av "rökt" spelar liksom inte så stor roll...

Containers har lägre, i vissa fall väsentligt lägre, overhead för kommunikation + de kostar klart mindre resurser att köra (i nivå med vilken process som helst, det är inte alls sant för hypervisors då de drar runt ett extra OS). Inom samma projekt/organisation finns därför flera anledningar att välja en sådan lösning där.

Normal kommer man inte åt någon HW direkt från en container. Det är möjligt att tillåta det och i det läget har det som kör inuti container samma direkta access till HW som "host". Men är typiskt också möjligt att ge indirekt access till HW via "virtuell" HW som delas mellan host/container och hosten agerar proxy mot verklig HW.

Fast just filsystemet är något man i väldigt nära 100 % inte direkt delar mellan containers och "host", varför skulle man göra det? Undantaget är "bind-mounts", men det är väl mer ett utvecklingshjälpmedel än något man använder i drift?

/proc och /sys går numera att till största del "emulera", d.v.s. det man ser i en container är inte direktaccess till host:ens /proc och /sys.

Finns en rad olika sätt att dela nätverk. Standardvalet är nästa alltid Dockers "bridge" mode som ger "containers" access till t.ex. internet via host:ens nätverk. Men det går fortfarande via virtuella Ethernet enheter, "containers" har inte direkt access till de fysiska interfacen.

Det är möjligt att ge direkt access till "containers", men varför skulle man göra det när det på en modern dator går att pusha åtskilliga TB/s över "veth"?

Portar man exponerar mot containers blir i "bridge" mode ofta även synliga utåt. Fast det beror på firewall/iptables policy och är fullt möjligt att ha en default-policy satt till "block" för all forwarding av trafik in mot containers. I det läget måste man explicit öppna varje port/service utåt, men går att ha en konfig som gör dem åtkomliga lokalt från host (eller så blockar man även det by default).

Vidare går det att låta specifika containers ha en separat nätverkslösning, t.ex. ett virtuellt Ethernet som inte är tillagd till host-bryggan. I det läget får man hantera hosten som vilken router som helst när det kommer till att bestämma vilken trafik som ska nå det virtuella Ethernet:et.

Det går absolut att ställa till det för sig här, men lösningarna finns!

Antar att du pratar om host-filsystemet ovan. Varför skulle en container överhuvudtaget ha någon access till det i normalfallet? Att tillåta det låter verkligen som en disaster waiting to happen...

Normalfallet är väl ändå att varje container har sitt helt privata filsystem + möjligen någon delad volym + eventuellt bind-mounts (och dessa ger access till host-filsystemet).

Och om man nu måste ge sådan access: om Docker services inte kör som root har containers ingen root-access till host-filsystemet med mindre än att det finns kernel-buggar.

Det går att köra 32-bit x86-kod sedan tidigare.

Däremot gissar jag att funktionen som erbjuds i Arm64EC är x86_64 only. Det lär inte vara ett stort problem, eventuell kvarvarande 32-bit kod borde inte vara prestandakritisk och då lär det fungera OK ändå.

32-bit x86 har fungerat sedan första versionerna av windows för ARM

64-bit stöd (x86_64 och framåt) kom förra året och nu kan alla gamla program köras felfritt i windows på arm

Du har fått flera bra svar men kan bara flika in att det inte är alltid det fungerar ändå.

Jag har exempelvis testat 'Mullvad VPN' för Windows på min Surface Pro X som alltså är x86 och den installeras OK, men kan ändå inte ansluta till tjänsten.

Det kan säkert behövas en native ARM från Mullvad för att det ska fungera.

Tack för svar!
Blir allt bra sugen på att ge det ett försök.

Fungerar det bra så är jag inte främmande att köra ARM på stationära. Men då vill jag kräva lösa moderkort, CPU och liknande.

Socklade processorer för ARM är ovanliga tyvärr, men vi får hoppas det kommer. Gärna standardiserade interface för flera aktörer som det var förr med sockel 7 till exempel

Vad betyder "hårdvarustödda virtuella maskiner" mer än att den isolering de erbjuder numera har olika former av HW-acceleration i kisel?

Hypervisors ("VMs") och OS-kärnor gör i grunden exakt samma sak: de hanterar resurser och erbjuder olika former av services till sina "applikationer", en av de viktigaste services man erbjuder är isolering från övriga "applikationer".

För en hypervisor är applikationerna OS-kärnor, för OS-kärnor är applikationer "vanliga" applikationer (user-land processer).

HW-stödet för isolering kommer primärt ned till MMU. Hypervisors har en MMU av MMUs, kärnor har en MMU.

Båda har buggar, både i programvara och definitivt även i HW (nu när AMD börjar få en relevant andel i datacenter börjar också antalet hittade HW-buggar ökar rejält, tyvärr lär samma gälla ARM64 men där finns ändå fundamentala fördelar i att det är en långt renare/enklare ISA).

Hypervisors och OS-kärnor har olika uppgifter. Om vi delar dator-HW i ett datacenter används naturligtvis en hypervisor för att ge oss en OS-kärna var.

Men som utvecklare/organisation, ge ett enda relevant use-case (utöver att man av någon anledning måste köra saker på olika OSes) där det finns en fördel med VMs över containers. Det man vill uppnå är separation mellan olika services, containers har en högre grad av isolation än "vanliga" applikationer och egentligen räcker det stöd OS:et ger, men av pakteringsmässiga och mer eller mindre dålig ingenjörskonst i programmeringdesign har det visat sig väldigt fördelaktigt att paketera services i "containers".

Själva containers/applikationer har aldrig behövt köras som root, däremot behövde docker-services:eb köras som det för att kunna göra sin "magi" mot Linux cgroups/namespaces.

Detta var ett problem som löstest i kärnan 2016 med cgroups v2 och som markerats "stabilt" i Docker sedan 2020, v20.10.

Värt att notera är att Docker-desktop (Windows/MacOS) aldrig behövt köras som root då man där kör QEMU under huven då containers faktiskt kör Linux.

Edit: och att man alltid kan köra som "root" i containers är ju inget problem. Detta är ju en funktion hos Linux namespaces där både PIDs (via PID namespace) och användare (via USER namespace) har ett värde inuti container, men har något annat på "host" (så root i container kan vara vilken användare som helst på host).