Frågor om Apples bärbara M1-datorer?

Alltså min nördnerv gör att jag vill ha en. Men det är just hårdvaran jag vill åt, pallar inte mac os, det är inget för mig. Ska försöka följa hur det går med linuxkompatibilitet. En sån här som linuxmaskin vore najs. Det enda alternativet just nu är typ pinebook, ett skämt.

Det har du säkert redan fått svar på, men det finns massvis med stora projekt på GitHub och dylikt som du kan kompilera.

Mozilla Firefox brukar vara populärt, https://firefox-source-docs.mozilla.org/contributing/contribu...

Eller varför inte chromium https://github.com/chromium/chromium

WebKit har det provats med, med väldigt imponerande resultat:
https://techcrunch.com/2020/11/17/yeah-apples-m1-macbook-pro-...

Maskinerna som kördes:
2020 13” M1 MacBook Pro 8-core 16GB
2019 16” Macbook Pro 8-core 2.4GHz 32GB w/5500M
2019 13” MacBook Pro 4-core 2.8GHz 16GB
2019 Mac Pro 12-Core 3.3GHz 48GB w/AMD Radeon Pro Vega II 32GB

Upp till appleverentören att tillåta det
#18737942

Mycket svårt att se att ios-bankid skulle släppas till datorn, det är inte alls så det är tänkt. Hela vitsen är ju precis att ha en sekundär enhet och något man alltid har med sig... i alla fall qr-biten blir ju svår att fixa...

Jag menade mest att den mobila varianten nog inte kommer portas rakt av, vad de väljer att göra framöver är en helt annan fråga

Ja touch bar känns bara tacky, en touch-display ska väl vara på vanliga skärmen i så fall? Nice att ändra volym steglöst dock...

Touch Bar eller ej, är en smaksak och en vanesak.

Har det på min 15" MBP och gillade den inte i början, men det var mest för att ESC knappen var där. Man var ju helt plötsligt tvungen att först trycka en gång för att väcka TB och sedan en gång till på ESC. Omständigt eeellllleeerrr?
Nu några år senare, så har jag vant mig och gillar den i mångt och mycket... Finns som sagt både för och nackdelar med allt.

Klart det löser sig och som jag skrev kan jag kosta på mig att ha inställningen då jag har fullgoda alternativ. Inte heller förvånande att vi är här ett par veckor efter släpp, få community-projekt lär ha haft tillgång till dev-kit-systemet.

Kör också inställningen av lite praktiska skäl: vill inte "skräpa ned" systemet med massa x86_64 binärer, går naturligtvis att installera om men är ofta lat på den punkten. Kör samma installation till det är dags att byta dator...

Finns ändå fördelar med att köra Mac även när man bara använder den som en glorifierad terminalemulator: i terminalen finns text, vet inte vad MacOS gör så rätt men text renderas otroligt fint. Framförallt när man sitter på en 4k skärm. Hoppas min skärm kommer på måndag, grabben knorrar när jag snott hans YouTube-skärm (27" 4k IPS, helt OK men lite bleka färger, hoppas den jag köpt är lite bättre på den punkten).

Som jag skrev: jag kan kosta på mig inställningen "om det inte fungerar i ARM64 native så fungerar det inte" då jag har andra möjligheter.

Rosetta 2 är en cool teknik, men det är fortfarande ett plåster där det ligger i allas intresse att man kan få bort så fort som möjligt. För egen del är det primära mervärdet just att tillgång till ARM64 på skrivbordet. Det då jag jobbar allt mer med ARM64.

Håller inte alltid med Torvalds, men han har helt klart en poäng att x86 har en väldigt fördel på serversidan då vi fram till nu i princip varit fast på x86 på de maskiner vi utvecklar den programvara som ska köra i "molnet" och lokala servers. x86 togs sig inte riktigt i serverrummet på teknisk överlägsenhet. Så ligger både i Apples men även Amazon (som redan har ARM64 servers) och Microsoft (som av allt att döma jobbar med egna ARM64 servers) att få fram fullgoda utvecklingsmiljöer som är ARM64 native.

Värdet att ha native ARM64 på skrivbordet är i vissa lägen väldigt stort, primärt för oss som jobbar med någon form OS-kod. För de som jobbar med .Net/Java och liknande är det långt enklare att utveckla på en CPU-arch och köra på en annan, de som sitter i skriptspråk som Python har noll beroende av CPU-arkitektur.

Har själv inte riktigt tagit det lika långt som vissa kollegor, är ett par som modifierat RPi4 för att komma åt PCIe-delen där de satt en SSD för att kunna få en ARM64-native Linux miljö. Problemet är att det tar en arbetsdag att bygga allt, även inkrementella byggen blir rätt sega på en lågt klockad Cortex A72 (M1 är åtskilliga heltalsfaktorer snabbare per kärna).

Om jag är realistisk är Apple rätt mycket exakt där man kan förvänta sig, de har också resurser att göra snabb progress och tror det är exakt vad vi kommer se. Är väl ändå lite besviken då jag har testat på ARM64 på Ubuntu 20.04, där fungerar ju saker direkt lysande redan idag (inklusive saker som Go och Rust, så finns inga ARM64 problem där utan är just MacOS+ARM64 -> lär vara enkelt att lösa) men finns ingen tillräckligt snabb plattform att köra.

Go och Rust/cargo native ARM64 på Ubuntu 20.04. Det kommer inte vara några problem att få till detta på MacOS

kjn@rpi4:~$ file $(which go)
/opt/go/bin/go: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, Go BuildID=g2yBbNB6K_ZIKXTlpMY_/gtkbArBECgXqJuHsG0JL/Pmf8G_m6z2lZ_nRHRPty/KO_GwRFTf9Uddzrj6z8F, not stripped
kjn@rpi4:~$ file $(which cargo)
/home/kjn/.cargo/bin/cargo: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 4.2.6, with debug_info, not stripped

Så fort Docker fungerar i ARM64 native variant på MacOS är jag i nirvana! Irriterar mig inte så mycket på dålig tillgång av grafikkort eller CPUer (har en 5600X på beställning, är julklapp så inte supertight deadline). Jag står i stället och stampar efter att kunna börja använda ARM64 som CPU i mitt primära arbetsredskap!

Angående Homebrew, de jobbar på det och vissa saker fungerar redan nu. Följer och om tid finns kommer jag hjälpa till där

HOMEBREW_VERSION: 2.5.11-119-g7343fef
ORIGIN: https://github.com/Homebrew/brew
HEAD: 7343fefde5580ff3b35861dd038ddcf75afe8b9c
Last commit: 15 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: b35fd3fa17b42b37040284b01db30416a3759950
Core tap last commit: 14 hours ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_REPOSITORY: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit dunno
Clang: 12.0 build 1200
Git: 2.24.3 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.0.1-arm64
CLT: N/A
Xcode: 12.2
Rosetta 2: false

Kör beta av Homebrew MacOS/ARM64

Edit: tror ett av huvudproblem för Rust handlar mer om att 64-bitars Arm heter egentligen AArch64 och man använder just det ID på för att identifiera arkitekturen. MacOS identifierar i stället CPU-arkitekturen som ARM64, så är en skitsak (nästa version ska som sagt ha native-stöd och den kan komma vilken dag som helst).

Vad har du för use-case som gör att du vill ha bank-id på datorn?

Det är en lite större säkerhetsrisk att ha det liggandes på datorn än att ha det med dig på mobilen, eftersom du hanterar din mobil med samma varsamhet som en plånbok. Bägge enheter kan ju i och för sig bli övertagna av illvilliga om man klickar fel länkar/installerar fel mjukvara, men jag skulle säga att risken för det är även den något större på datorn än mobilen.

Eller menar du bank-id på kort med kortläsare? (Finns det kvar? Var länge sen jag arbetade med bank-id)

Efter gnället ovan: bra nyheter för er som levera era liv i NodeJS!

Finns inte färdigpaketerad NodeJS för MacOS/ARM64 än, tar man paketet för MacOS får man köra via Rosetta 2. Men installerar man via nvm får man en ARM64 native version av NodeJS.

Nu är det rätt få saker jag hunnit testa än, men säger bara wow! Prestanda i NodeJS är brutalt, tog ett av mina egna program (som i detta fall inte använder "workers" eller "cluster" modulen, så enkeltrådat). Firestorm är lite mer än dubbel så snabb jämfört med i7-8559U och 3900X (dessa drar väldigt jämt i de flesta enkeltrådade fall, så även här).

Gjorde också ett snabbskott på detta, inte samma fördel för M1 här. Den är "bara" ~65 % snabbare än 3900X och ~80 % snabbare än i7-8559U.

Allt för få fall för att dra speciellt stora växlar, men finns indikationer på att NodeJS prestanda är absolut fantastiskt på Apples CPU. Det skulle i så fall också ge en förklaring till varför Iphone "vinner" alla JS-benchmarks, handlar inte så mycket iOS utan mer om att CPU-arkitekturen av någon anledning älskar det JS-motorerna spottar ur sig.

Installerade också VS Code, är en "vanlig" MacOS bundle så trivialt att ta bort. VS Code körs för närvarande under Rosetta 2, vilket är lite trist givet att det är något som kör JS/Electron och borde vara rätt enkelt att få till "native". Verkar i alla fall fungera som det ska!

Nu har jag suttit och konfigurerat upp datormiljön i Macbook Pro M1, installerat nödvändig mjukvara, etc. Hittills har jag inte behövt installera tolkade Intel-versioner särskilt ofta, men applikationer som MS Word (har inte installerat M1-betan), Slack, Discord och Dropbox har fått köras via Rosetta 2.

När detta skrivs har jag inte våldsamt många applikationer igång. Utöver Dropbox som arbetar i bakgrunden har jag Safari och Chrome igång med cirka 8-9 flikar vardera, Mail, Slack, Discord, Pixelmator Pro och Microsoft Word körandes. Nästan 7 av testexets 8 GB primärminne är uppätet, så om man tenderar att utsätta sin dator för tyngre arbete av något slag är 16 GB nog att rekommendera. Det här representerar väldigt lätt användning för min del, och 8 GB skulle absolut inte räcka i långa loppet. Så fort jag kommit igång med att använda datorn för vardagligt arbete lär jag överskrida den fysiska minnesmängden ganska snabbt, och gå över på växlingsminne.