Apple: "Windows på våra ARM-datorer är upp till Microsoft"

Permalänk
Medlem
Skrivet av Sidde:

Jag förstår personligen inte varför man öht använder mjukvara som Docker då jag inte ser att det löser något problem egentligen, det bara gömmer eller flyttar problemet, men datorvärlden är rätt konstig ibland som tenderar ökad komplexitet hela tiden.
En liten slimmad linux-install på en vm och enkel shell-automation gör det klart enklare imo.
Men det är för en annan diskussion kanske.

Om vi ser det ur användarperspektiv och inte tekniskt (då det skiljer) så är en container en slimmad virtuell maskin med endast de saker du vill ha. Du automatiserar installationen genom att skriva din ".dockerfile". Det är samma sak som du förordar.

Det finns en rad sätt att hosta på som går från enkelt till superkomplicerat, men detsamma gäller om du använder virtuella maskiner eller baremetal och är inte kopplat till container som teknik.

Permalänk
Medlem
Skrivet av Sidde:

Du driftar inte k8s hör jag

Inget är stateless i den infrastrukturen, kanske så som applikationen uppfattar det men det är 200 andra applikationer som gör det möjligt som behöver spara sin state. Den enskilda applikationen blir enklare, men egentligen har man bara flyttat det komplexa för någon annan att lösa. Det är ju inte så att lastbalansering blir magiskt löst, det är bara en proxy framför precis som en vanlig applikation. Förutom att i k8s-lösningar är det ofta 4-8st proxys framför.

Openshift är tex nog den mest komplexa lösningen jag någonsin sett, och då har jag sett många stora lösningar från SAP, IBM och Oracle

Jojo jag vet det, ingen dragen bakom ljuset, men jag tolkade frågan varför en utvecklare bryr sig om docker/containers. Det kan bli ganska trevligt med centrerad loghantering och allt i klustrade databaser. Drift, infrastruktur och annat blir såklart en annan fråga.

Jag listade bara en liten del av teknikens potentiella fördelar (framförallt för de som litar på andras kod alltså)

Permalänk
Medlem
Skrivet av petabyte:

Om vi ser det ur användarperspektiv och inte tekniskt (då det skiljer) så är en container en slimmad virtuell maskin med endast de saker du vill ha. Du automatiserar installationen genom att skriva din ".dockerfile". Det är samma sak som du förordar.

Det finns en rad sätt att hosta på som går från enkelt till superkomplicerat, men detsamma gäller om du använder virtuella maskiner eller baremetal och är inte kopplat till container som teknik.

Se #18754418
Och nej, en container är inte en slimmad vm, det är en cgroups med namespaces på en linuxmaskin.
Men docker är så mycket mer än så, det är en hög med uppenbart svårportad kod istället för tex posix-kompatibel shellscript.

Permalänk
Datavetare
Skrivet av Sidde:

Bra input kring c/c++ btw

Som tur är lär sig folk med tiden. En stor anledning jag hoppas Rust riktigt tar fart är då det är en av ytterst få språk som likt C/C++ är lämpligt ända ned till OS-kernels, mikrokontrollers och liknande men man har sett till att det inte finns "undefined/implementation-defined" beteende.

Angående nätverksstöd i Docker, du har självklart rätt i att det inte är fullt definierat. Men det spelar faktiskt ingen roll för det man stoppar in i containern, den bryr sig bara om user-land APIer och att det på något sätt går att kommunicera med omvärlden.

Om det sker via något k8s nätverksnystan, via docker eller att man helt enkelt delar network-namespace med den kärna man kör ovanpå är irrelevant för applikationen!

Permalänk
Medlem
Skrivet av Yoshman:

Som tur är lär sig folk med tiden. En stor anledning jag hoppas Rust riktigt tar fart är då det är en av ytterst få språk som likt C/C++ är lämpligt ända ned till OS-kernels, mikrokontrollers och liknande men man har sett till att det inte finns "undefined/implementation-defined" beteende.

Angående nätverksstöd i Docker, du har självklart rätt i att det inte är fullt definierat. Men det spelar faktiskt ingen roll för det man stoppar in i containern, den bryr sig bara om user-land APIer och att det på något sätt går att kommunicera med omvärlden.

Om det sker via något k8s nätverksnystan, via docker eller att man helt enkelt delar network-namespace med den kärna man kör ovanpå är irrelevant för applikationen!

Om jag förstått det rätt angående Rust så är ganska mycket valideringar gjorda redan när det kompileras och tas sedan bort från det som exekverar, det känns som det borde lämna stora gap för säkerhetsbrister kompenserat med mer prestanda?

Permalänk
Medlem

Om så sker att Microsoft erbjuder en ARM-version lämplig att köras på Apples processorer så kommer man inget vart utan drivrutiner för hårdvaran, som måste skrivas/erbjudas Apple, precis som med tidigare situation för Boot Camp för X86.

Och vi vet ju hur (o)intresserade Apple är av att skriva bra drivrutiner för Windows. Dom gör ju medvetet dåliga drivare för att användaren ska få en dålig upplevelse av Windows på deras hårdvara.

Permalänk
Medlem
Skrivet av NaturMackan:

Om så sker att Microsoft erbjuder en ARM-version lämplig att köras på Apples processorer så kommer man inget vart utan drivrutiner för hårdvaran, som måste skrivas/erbjudas Apple, precis som med tidigare situation för Boot Camp för X86.

Och vi vet ju hur (o)intresserade Apple är av att skriva bra drivrutiner för Windows. Dom gör ju medvetet dåliga drivare för att användaren ska få en dålig upplevelse av Windows på deras hårdvara.

Tittar man på de senaste årens utveckling från Apples sida, t.ex. Slopat 32-bitsstöd, OS-förändringar, SwiftUI, non-user-upgradeability, så är det tydligt att de dels har banat väg för sin ARM-plattform, och dels för att ”soften the blow” så att det inte är ARM-releasen som tar bort alla de där sakerna. Då hade mottagandet varit betydligt svalare.

Så, jag tror nog att Apple kan visa intresse för Bootcamp framöver, när hela produktsviten är ersatt.

Permalänk
Medlem
Skrivet av Sidde:

Jag förstår personligen inte varför man öht använder mjukvara som Docker då jag inte ser att det löser något problem egentligen, det bara gömmer eller flyttar problemet, men datorvärlden är rätt konstig ibland som tenderar ökad komplexitet hela tiden.
En liten slimmad linux-install på en vm och enkel shell-automation gör det klart enklare imo.
Men det är för en annan diskussion kanske.

Poängen är väl till stor del att det är en isolerad replikerbar sandlåda. I mina ögon färdiginstallerad, specificerad och komplett.

Man kan göra allt det du talar om, men det "gamla" sättet som du snackar om är ju det som man ville komma ifrån.

När jag installerar Plex, Mumble, SQL, Apache och sådant idag så kör jag utslutande med docker-containers.

Det är ganska stort tryck på docker i min krets. Alla som har testat det älskar det för att det är så clean:t jämfört med vanliga deploys. OS:et i containern blir sekundärt. Det är bara till för att köra den koden som man byggt.

Permalänk
Medlem
Skrivet av Levandebild:

Jag har alltid sett avsaknaden av Windows på Mac som en bonus, inte skulle jag lägga ned extra tid på att få in smeten i paradiset.

Fast smeten sitter du ju redan i? (Mac OS)

Permalänk
Medlem

Jag kan tänka mig att det är en dealbreaker för vissa att man inte kan köra Windows på de nya maskinerna, men för den stora skaran är det skit samma.

Permalänk
Datavetare
Skrivet av Joppis:

Kanske är det bara så enkelt att Apple kör på ARMv8.4‑A och Qualcomm kör på ARMv8.2-A?

Källa för min gissning:
https://en.wikipedia.org/wiki/Comparison_of_ARMv8-A_cores

Det i sig är inte ett problem då versionen på HW > versionen som programvaran (Windows i detta fall) använder sig.

ARMv8.4-A är ett strikt superset av ARMv8.2-A, så om man bara zoomar in på CPU-delen har M1 inga problem att köras på Windows.

Huvudproblemet är ju att M1, likt de flesta ARM-system, är en systemkrets och för att köra Windows måste det till Windows-drivers för minst GPU och grundläggande I/O för M1.

Skrivet av medbor:

Om jag förstått det rätt angående Rust så är ganska mycket valideringar gjorda redan när det kompileras och tas sedan bort från det som exekverar, det känns som det borde lämna stora gap för säkerhetsbrister kompenserat med mer prestanda?

"Safe Rust" har en semantik som möjliggör för kompilatorn att upptäcka en lång rad av de absolut värsta buggarna som gäckar dagens program redan vid kompileringstillfället. D.v.s. om det kompilerar finns inte dessa buggar, då de inte finns behöver man inte heller leta efter dem vid runtime -> win/win då det ger snabbare program som är garanterad korrekt.

Vissa saker är omöjliga inom ramen av "safe Rust", t.ex. skriva drivrutiner då kommunikation med HW uppför sig "magiskt" jämfört med RAM. Du kan läsa samma adress flera gången och få olika svar hela tiden trots att ingen annan del av CPUn skrivit något.

I "safe Rust" får du ett kompileringsfel om du har data-race, minnesläcka etc. Man kan fortfarande göra off-by-one fel, den absolut största källan till säkerhetsbuggar i C/C++, men i safe-Rust fångas det runtime (likt Java/C#/Python m.fl.).

Det kommer massor med nya språk hela tiden, men väldigt få introducerar något egentligen av värde. C (slutet 60-talet / tidigt 70-tal) gav oss en portabel assembler som än idag är grunden för i princip alla operativsystem, LISP (sent 50-tal) gav oss de saker som många kanske tänker att Java gav oss (automatiskt minneshantering och en virtuell maskin).

Rust är det första sedan C++ som kan realistiskt användas som systemspråk, d.v.s det går att skriva OS-kärnor. Egentligen är det bara C som fungerar, standard C++ går inte använda utan man måste i praktiken köra en nedskalad version. Rust i OS kärna blir också en delmängd av hela miljön, men den delmängden är (kommer bli, man har inte nått 1.0 än) definierad av specifikationen.

Rust knäckte an vår tids största problem: data-race. Få andra moderna språk har tillfört något egentligt av värde är, Go är ett av undantaget då det gjorde hantera av massiv I/O väldigt enkelt. Även om Go egentligen gör samma sak som Erlang, fast Go har också effektiviteten nära C/C++/Rust samt att Go har en syntax många känner igen, att vara annorlunda som t.ex. Erlang är i praktiken ett stort problem.

Tyvärr är inget "gratis". Rust har lite Emacs-känsla över sig, d.v.s. det är en nära vertikal och rätt hög inlärningströskel, tror tyvärr det kommer sätta stopp för språket att bli ett nytt Python eller JavaScript sett till popularitet. Orkar man sig över tröskeln blir man belönad, de flesta lär välja en bekvämare väg.

Skrivet av x86:

Tittar man på de senaste årens utveckling från Apples sida, t.ex. Slopat 32-bitsstöd, OS-förändringar, SwiftUI, non-user-upgradeability, så är det tydligt att de dels har banat väg för sin ARM-plattform, och dels för att ”soften the blow” så att det inte är ARM-releasen som tar bort alla de där sakerna. Då hade mottagandet varit betydligt svalare.

Så, jag tror nog att Apple kan visa intresse för Bootcamp framöver, när hela produktsviten är ersatt.

Slopandet av 32-bitars stödet ända ned på HW-nivå är en del av förklaringen till hur Apple lyckades designat en CPU som så totalt demolerar alla andra CPU-designer sett till prestanda per MHz med hög absolut perf (Cortex A78 lär leda perf/W ligan av "big-core" ARM64, men den ligger en bra bit efter både Firestorm och X1 i absolut perf).

Ställer man 32-bitars Arm mot x86 ser man rätt mycket samma story vi sett genom historen när x86 ställs mot något annat: Arm är bättre på vissa saker, t.ex. blir programmen kompaktare medan x86 är bättre på andra, det är svårt att designa "breda" x86, men det är ännu svårare att designa "breda" 32-bitars Arm (p.g.a. hur ISA är designad).

Ur flera aspekter är 32-bitars Arm och 64-bitars Arm extremer, fast åt olika håll. Lär vara förvirrande, många var ju helt övertygade om att det inte skulle gå att designa en Arm CPU som prestera motsvarande high-end x86. För 32-bitars Arm är det nog sant, man skulle kunna komma nära men det skulle inte gå att göra något likt Firestorm som så totalt kör över både Willow Cove och Zen 3 sett till perf per MHz och perf per Watt samtidigt som den har likvärdig absolut prestanda.

Arm kommer följa efter Apple, high-end Cortex A kommer droppa stöd för 32-bitar inom de närmaste två åren. Det är goda nyheter för Microsoft, de ska helt ignorera 32-bitars stödet på Windows då det ändå kommer vara helt irrelevant när (för är övertygad att efter det Apple visat med M1 är det inte lägre frågan om) ARM64 slår igenom även på Windows.

Det Microsoft har nu i form av Surface Pro X ser jag som deras dev-kit, för att man ska kunna ta Microsoft på allvar måste de göra det Apple gjort: designa en krets som i alla fall på bärbara (som står för merparten av alla PC som säljs) totalt omdefinierar prestanda man kan förvänta sig i en tunn och lätt "ultrabook". Likt M1 måste den vara så överlägsen allt Intel/AMD har att det blir uppenbart att deras teknik nått vägens ände.

Nvidia är inte lätt att samarbete med, men om (tror det bara handlar om när även där) köpet av Arm går igenom är det just Nvidia Microsoft bör sätta sig ned med och diskutera vad de behöver från Cortex A serien för att lyckas med ARM64 på Windows. Cortex X1 är en bra bit på vägen, man att Microsoft inte ens använder den, man har inte ens gått till Cortex A78 utan stannar på en lite högre klockad A76 visar att Microsoft fortfarande inte riktigt släppt sargen.

Permalänk
Medlem
Skrivet av Sidde:

Bootcamp är ju bara en utility som hjälper dig partitionera disken, boota upp en windows-installer och ett paket med drivrutiner.
Du kan ju boota andra OS som Windows och Linux på en x86-mac med eller utan "hjälp" av bootcamp. Själva stödet är ju att EFI i macarna tillåter andra OS, även osignerade os och det har i sig inget med bootcamp att göra.

Om Apple själva tillåter tex boot av Windows på en Apple Silicon-mac innebär det att de att de byggt in stöd i firmwaren för att boota andra OS än Mac OS. Det gör det klart enklare att boota Linux också eftersom ingen då kanske behöver reverse engineera boot-processen.

Apple har ju inte officiellt supportat boot av Linux på några macar tidigare heller, men det har ju varit en självklarhet och enkelt att göra både på PPC och x86-macar genom att firmwaren har inte försökt förhindra boot av något annat heller.
I och med att hela datorbranchen har gått över till att bara boota signerade binärer så är det både enklare att förhindra, men också enklare att råka låsa ut andra utan onda intentioner

Jag ställer mig nog mer frågande till om det kommer gå att köra andra OS, förutom Windows som nämns i artikeln, native.
Artikeln verkar förövrigt hoppa lite fram och tillbaka mellan virtualiserad x86 och native ARM (som är custom i Apples fall).
Emulering har ju varit på tapeten många gånger tidigare och det går i många fall riktigt bra även om det finns frågetecken kring prestanda i vissa fall samt huruvida man får porta program/licenser mellan olika proprietära plattformar samt hur supportkedjan för sådant skulle se ut.

Något man ständigt bör ha i åtanke när det kommer till proprietärt är ju: Bara för att det går, betyder det inte att du borde eller får. -göra något i den stilen.

Om det nu verkligen handlar om native, och inte emulerat, är väl följdfrågan i vilket state det i såfall kommer vara möjligt att köra t.ex. Linux-baserade OS på Apples custom SOC, drivrutiner kommer troligtvis inte finnas tillgängliga på ett silverfat för det ändamålet.

Jag ställer mig fortfarande skeptisk till om det inte är önsketänkande att tro att Apple inte kommer vilja ha fullständig kontroll ut i fingerspetsarna när de nu gått denna vägen.

Permalänk
Medlem

Varför vill man köra MacOS? Varför vill man plåga sig själv?

Permalänk
Medlem
Skrivet av Dinkefing:

Varför vill man köra MacOS? Varför vill man plåga sig själv?

För att det faktiskt fungerar? 😉

Varför vill man köra Windows? Varför vill man plåga sig själv? 👀 Exempel är ju startmenyn som slutar fungera hälften av gångerna man trycker på ikonen. Men detta är ju bara en av många buggar i windows man måste stå ut med dagligen. Överlag upplever jag att microsoft mjukvara bara får fler och fler buggar. Visual Studio ska vi inte ens prata om. Fungerar sämre och sämre för varje version.

Permalänk
Medlem
Permalänk
Medlem

Varför skulle Apple vilja sälja windows-datorer?

Permalänk
Medlem

Jag förstår inte riktigt varför Apple INTE vill att man ska kunna köra Windows och Linux? macOS är ju "gratis", så Apple tjänar ju pengar på HW, inte SW, när det kommer till datorer. Och gissar apple laptops hade fått ytterligare ett uppsving i försäljning om företag kunde köra Windows och utvecklare köra Linux. Är det så att Apples plan är att tjäna lika mycket pengar på en app store i macOS som de gör till iOS, och därför vill ha alla på samma OS?

Permalänk
Medlem
Skrivet av jaqob:

Jag förstår inte riktigt varför Apple INTE vill att man ska kunna köra Windows och Linux?

Fram tills nu så har det varit en barnlek att köra Windows på Mac via Bootcamp, så hoppas att möjligheten kommer finnas kvar.

Linux har jag själv aldrig haft behovet av på en Mac, då macOS i sig är baserat på BSD i grunden.

Själv har jag försökt röra mig ifrån Windows i flera år och kör nu Linux dagligen på min laptop, men det känns som att macOS kommer bli min räddning.

Kanske börjar titta på CrossOver, WineBottler och WineSkin framöver. Använde det för nära 10 år sedan då jag senast försökte lämna Windows Skam den som ger sig!

Permalänk
Medlem
Skrivet av Mumsfilibaba:

För att det faktiskt fungerar? 😉

Varför vill man köra Windows? Varför vill man plåga sig själv? 👀 Exempel är ju startmenyn som slutar fungera hälften av gångerna man trycker på ikonen. Men detta är ju bara en av många buggar i windows man måste stå ut med dagligen. Överlag upplever jag att microsoft mjukvara bara får fler och fler buggar. Visual Studio ska vi inte ens prata om. Fungerar sämre och sämre för varje version.

Haha, det där med Startmenyn känner jag igen.

På tal om Startmenyn vore det fint med en inställning som säger att när ett program körs i fullskärm (som spel ofta gör) så ska det inte hända något när Windows-knappen på tangentbordet trycks ned. För hur ofta vill man att ett tryck på den knappen mitt i ett spel ska kasta en till skrivbordet och ta fram Startmenyn?

Jag vet att det finns olika lösningar för att stänga av och på Startmenyn via Windows-knappen helt, men borde finnas inbyggd smidig lösning i Windows som ju har ett visst spelfokus från Microsofts sida.

Permalänk
Medlem
Skrivet av star-affinity:

På tal om Startmenyn vore det fint med en inställning som säger att när ett program körs i fullskärm (som spel ofta gör) så ska det inte hända något när Windows-knappen på tangentbordet trycks ned. För hur ofta vill man att ett tryck på den knappen mitt i ett spel ska kasta en till skrivbordet och ta fram Startmenyn?

Tyvärr verkar det vara lite random som mycket annat i Windows. Såg fram emot att spela klassiska Monkey Island på min Windows-platta, men gav upp då jag _inte_ kan komma tillbaka till skrivbordet. Windows-knappen fungerar helt enkelt inte i helskärmsläget, utan jag måste använda mig av mus eller tangentbord för att komma vidare på en platta utan mus och tangentbord. Bra tänkt!

Föredrar annars Classic Start/Open-Shell för att ersätta startmenyn i Windows.

Jag hade helt klart uppskattat ett Windows där jag själv haft större kontroll på Windows-knappen, gestures och dylikt. Letar fortfarande efter ett sätt att stänga av "Win+W" då jag anser att Windows Ink Workspace är bloatware. "Win+tab" vill jag också stänga av helt.

Permalänk
Medlem
Skrivet av jaqob:

Jag förstår inte riktigt varför Apple INTE vill att man ska kunna köra Windows och Linux? macOS är ju "gratis", så Apple tjänar ju pengar på HW, inte SW, när det kommer till datorer. Och gissar apple laptops hade fått ytterligare ett uppsving i försäljning om företag kunde köra Windows och utvecklare köra Linux. Är det så att Apples plan är att tjäna lika mycket pengar på en app store i macOS som de gör till iOS, och därför vill ha alla på samma OS?

Apple tjänar absolut en stor del på hårdvaran, men appstore och andra tjänster är också en riktigt stor inkomstkälla, den delen tappar man helt om andra os används

Permalänk
Medlem
Skrivet av NaturMackan:

Om så sker att Microsoft erbjuder en ARM-version lämplig att köras på Apples processorer så kommer man inget vart utan drivrutiner för hårdvaran, som måste skrivas/erbjudas Apple, precis som med tidigare situation för Boot Camp för X86.

Och vi vet ju hur (o)intresserade Apple är av att skriva bra drivrutiner för Windows. Dom gör ju medvetet dåliga drivare för att användaren ska få en dålig upplevelse av Windows på deras hårdvara.

Nej, det räcker att Parellels skriver drivrutinerna. Kommer inte gå att köra något som bootar direkt på maskinen. Microsoft måste bestämma sig för om de ska lansera licenser för Windows eller inte vilket som och eftersom det är så omogen plattform för Microsoft så måste de arbeta med virtualiseringsleverantören, men inte med Apple.

För företag är Windows på ARM lite ointressant, Windows-applikationerna kommer ju gå att köra på deras interna applikationsservrar.

Qualcomm kommer inte kunna rädda Microsoft där.

Permalänk
Medlem
Skrivet av Petterk:

Nej, det räcker att Parellels skriver drivrutinerna. Kommer inte gå att köra något som bootar direkt på maskinen. Microsoft måste bestämma sig för om de ska lansera licenser för Windows eller inte vilket som och eftersom det är så omogen plattform för Microsoft så måste de arbeta med virtualiseringsleverantören, men inte med Apple.

För företag är Windows på ARM lite ointressant, Windows-applikationerna kommer ju gå att köra på deras interna applikationsservrar.

Qualcomm kommer inte kunna rädda Microsoft där.

Många andra säger att efi på dessa stödjer att boota andra os och går att stänga av signeringskollen på bootloaders. Kan vara fel, men det är vad andra sagt.

Bootcamp var väl mest ett enklare sätt att partitionera och installera? Behöver ju inte vara döden om det stödet inte finns

Permalänk
Medlem
Skrivet av medbor:

Många andra säger att efi på dessa stödjer att boota andra os och går att stänga av signeringskollen på bootloaders. Kan vara fel, men det är vad andra sagt.

Bootcamp var väl mest ett enklare sätt att partitionera och installera? Behöver ju inte vara döden om det stödet inte finns

Inte sett någon gräva i det. I dagsläget är det inte ens säkert vi ser andra hypervisors än Apples egna, men det kommer säkert Parallels och VMware ändra på.

Permalänk
Medlem
Skrivet av Dinkefing:

Varför vill man köra MacOS? Varför vill man plåga sig själv?

Vad är det som du upplever så dåligt med MacOS?

Permalänk
Medlem

Om det finns OEM-licenser av Windows för ARM-datorer, betyder det att det finns Windows-program kompilerade för ARM-datorer och då borde man åtminstone kunna köra dessa program genom Wine. Det är inte säkert att man behöver hela Windows; är det bara enstaka program man behöver kanske det räcker med Wine.

Fördelen med Wine jämfört med Virtualbox är att datorn går snabbare eftersom man inte behöver ha två olika operativsystem igång samtidigt. Fördelen med Wine jämfört med dual boot är att man inte behöver starta om datorn varje gång man ska byta från ett Mac- eller Linux-program till ett Windows-program eller vice versa. Nackdelen är att en del program inte funkar. Ett problem är att Wine inte är kompatibelt med Windows Store.