Názory k článku
Apple představil nástroj Container pro běh linuxových kontejnerů v macOS

Málo informácii páni z apple dodali. Jediné viem, že to bude púšťať OCI kontajnery. Či je emulácia X86 zahrnutá v cene, to neviem, lebo servery s apple silicon sa nevyrábajú. Aký to má performance a čo je killer feature oproti napríklad dockeru. (Napríklad že pytorch efektívne vďaka tým natívnym rozhraniam využije akceleráciu, alebo tak)

Asi to o chvíľu niekto testne, len mne to apple nepredal.

arm64 servery a kontejnery jsou relativně běžné. Ty by snad měly běžet bez modifikace, když do toho VM dají vhodné jádro. (ale přece jen mají arm64 větší variabilitu než x86, takže komplikace by mě nepřekvapily)

AArch64 servery jsou sice běžné, ale kolik jich běží na MacOS?

Řekl bych, že to bude blízké číslu 0 :)

A proc by ty servery meli bezet na macu? Tohle cili na vyvojare. Muzes vyvijet a zkouset vse na macu zatimco windows a linux utre...

Bolo k tomu video na WWDC.

Neemuluje to ziadnu architekturu, spusta vo arm64 virtualku linuxu, pre kazdy kontajner samostatnu (to je rozdiel voci dockeru, ktory ma jednu pre vsetkych). Je to lightweight virtualka, je tam len kernel, staticky init a ten hned spusti kontajner. Kazdy z nich ma samostatny networking namespace a kazdy z nich ma samostane mapovanie adresarov z hosta cez virtio-fs.

https://developer.apple.com/videos/play/wwdc2025/346/

Ďakujem veľmi pekne za video, pozriem si to.

Tady mě zajímá, jaký bude mít výkon FS vrstva. Jablečný Docker trpí na hrozný výkon FS vrstvy, když se něco mapuje z lokálního adresáře přístupného v macOS, takže nějaký projekt, co se skládá ze stovek souborů malých souborů, s kterými se má něco udělat v kontejneru, to je hrozná bolest, že jsem s kontejnery všechno vzdal a rozjel si to nativně lokálně.

Hej, node_modules v dockeri na macu je bolestive. Kedze tento novy nastroj pouziva nove featury macOS 26 a ja betu riesit nejdem, tak na jesen uvidime.

Takže ten kontejner vlastně není kontejner.

Ne, kontejner je kontejner. Jenom se různé kontejnery ve výchozím nastavení spouští v různých virtuálech.

emulaci neumí. Je to alternativa k UTM, Orbstack a dalším nástrojům. Používá to kernelové api na virtualizaci, které už nějakou dobu máme.

Pokud jde o emulaci, na tu musíš použít qemu, což funguje, část práce zajistí i rosetta.

Práve niečo rosettoidne by som tam tak trochu čakal. Už len dynamická rekompilácia v box64 na mojom raspberry pi dosť pomáha a apple to má už asi viacej vychytané. (samozrejme aj qemu to vie, ale tam je asi niečo univerzálnejšie a menej optimalizované)

Technicky je mozne pouzivat rosettu v linuxovej virtualke: https://developer.apple.com/documentation/virtualization/running-intel-binaries-in-linux-vms-with-rosetta (stale ide o arm64 linux, kde sa rosetta zaregistruje ako binfmt handler pre x64).

Ale: preco? velmi malo docker images je x64 only (ano, su. Niekedy len z neochoty, napr. postgis/postgis je amd64-only a tretie strany publikuju arm64 image). Tak ked sa da pouzit nativny, pouzijem nativny.

Dôvod je ten, že keď budem robiť deploy na server, aby sa použil ten istý kontajner. Nechcem byť nejký odporný, ale drvivá väčšina serverov je ešte stále X86_64. Až bude bežná custom architektúra apple silicon na serveroch, potom samozrejme. (schválne nehovorím, že je to ARM, lebo je to kvázi ARM)

Jen, já si úplně nemyslím, že tam nepůjdou spustit kontejnery s x86_64 binárkami.
Ten nástroj containers používá související Swift balíček containerization
https://github.com/apple/containerization
Tam je zmíněná podpora Rosetty v readme a podle částí kódu s tím počítají:
https://github.com/apple/containerization/blob/main/Sources/Containerization/Agent/Vminitd%2BRosetta.swift
https://github.com/apple/containerization/blob/main/Sources/Containerization/VZVirtualMachineInstance.swift#L48
atd.
Tzn. počítám, že tam bude sice Linux s aarch64 jádrem, ale bude mít binfmt handler na tyhle binárky přes Rosettu.

Docker na apple silicon macos funguje bez problému, tak není důvod, aby nefungovalo tohle. Většina populárních kontejnerů má ARM variantu ale fungujou i emulované x86.

Hosana! Kontejnery na Macu byly doposud osina v zadku a jestli tohle pojede rozumně efektivně, pak palec nahoru. Když si vezmu, kam se posouvá jejich profi HW a jak zároveň macOS stagnoval, pokud šlo právě o profi aplikace jako kontejnery, můžu jen doufat, že v podobných zlepšeních budou jen pokračovat.

Jen ze zajímavosti, proč jsou teď osinou?
Chvíli jsem si před časem hrál s Dockerem, OrbStackem, nepřišlo mi to tak hrozné. Další možnost pro určité situace je nahození celého Linux virtuálu (např. přes UTM).
Tohle mi zatím přijde jen obdoba vyloženě pro OCI kontejnery, jen přímo od Apple.
Zajímavé je i to rozhodnutí, spouštět na pozadí automaticky svůj virtuál pro každý kontejner místo jednoho sdíleného container hosta. Což je možná zajímavé z hlediska totální izolace, na druhou stranu to podle mě nutně bude potřebovat víc paměti s více spuštěnými kontejnery (samostatné virtualizované systémy, každý se svou virtuální pamětí, page cache).

Minimálně Docker a Podman mi na Apple Silicon přišly pomalé a žravé. Od Containers si slibuju právě lepší efektivitu (ale můžu se mýlit, právě kvůli agresivnější virtualizaci). Tak jako tak to beru jako dobrý znak do budoucna, že Apple řeší i tyhle use-casy.

To je otázka, jestli to bude rychlejší. Tu rychlost běhu primárně určuje virtualizační metoda na Linux systém pod těmi kontejnery, efektivita emulace zařízení (síť a bloková zařízení).
Tam jsou v podstatě dvě možnosti, buď generické QEMU nebo nativní frameworky (Virtualization, Hypervisor, vmnet) od Apple v macOS, přičemž většina jich je dostupná do macOS 11 dál, a samozřjemě jsou tam inkrementální vylepšení s novými verzemi systémů.
Na začátku používalo hodně nástrojů právě QEMU, ale postupně přecházely na nativní frameworky (minimálně jako volbu). Tzn. třeba Docker Desktop má, myslím, někdy od loňska tuhle možnost také a QEMU je v podstatě deprecated.
Ty samé frameworky logicky používá i tenhle nový kontejnerizační nástroj od Apple.

Jestli vám přišly kontejnery pomalé, nemohlo to být tím, že máte Apple Silicon Mac a používané kontejnery byly jen pro amd64 (x86_64)? Tzn. musel se použít překlad na ARM (aarch64) - buď s Rosettou (rychlejší), nebo QEMU/binfmt (emulace - velmi pomalé).

Docker na masoxu sám o sobě cajk. Problém nastává s shared volumes (tedy typicky tvůj zdrojak). Opakovaně jsem to testoval. Když to nebylo shared volume tak to bylo řadověstejne jako na linuxu. Kdyz byl shared volume tak to šlo o 1-2 řády dolu.

Provozovat Linux na MACku? Vždyť ta věc nemá ani normální klávesnici s funkčními klávesami F1..F12, používat midnight commander v MACkové konzoli bylo utrpení... ale zkoušel jsem to kdysi dávno před opuštěním x86 CPU. Jistě se za tu dobu zlepšili, už mají tlačítka u touchpadu, Fka zpět na klávesnici, funguje na nich CTRL a pravý Alt... ne?

12. 6. 2025, 11:29 editováno autorem komentáře

Provozovat Linux na MACku?
Tady jde o kontejnery - pracujete normálně na macOS UI a s jeho nativními aplikacem, akorát vám na pozadí běží služby a server aplikace nad Linuxovým VM.
Pokud byste chtěl celý Linux na Apple hardware místo MacOS, tak je to Asahi.

Vždyť ta věc nemá ani normální klávesnici s funkčními klávesami F1..F12, používat midnight commander v MACkové konzoli bylo utrpení...
https://support.apple.com/en-us/102439
Tzn. jako např. na téměř jakémkoliv PC notebooku

už mají tlačítka u touchpadu
Je to vymyšlené jinak.
https://support.apple.com/en-us/102482

Nikdo vám samozřejmě nebrání si připojit USB, BT periferie jaké chcete, třeba myš s dalšími tlačítky, trackball, klávesnici atp.

Díky za odkaz na ten návod, jak zacházet s touchpadem. Nejspíš to budu používat jako ukázku zbytečné překomplikovanosti :) Multitouch samozřejmě používám na PC (zoom, scroll a pod.) ale o některých gestech jsem fakt netušíl, že existují.

A ano, já vím, že k MACku můžu připojit PC klávesnici a PC myš. Taky to občas dělám, když mě někdo nutí s tím pracovat (déle než chvilku). Kdykoli jsem měl v ruce originál applí... jak bych to řekl - design v CADu a na propagačních materiálech jistě zářivě vynikl, ale pracovat s tím byl vopruz.

Proto mám pocit, že MACkaři z ovládání Linuxu budou mít podobné osypky a bojím se, aby to nevedlo k poškození ergonomie tím, že nám zpět budou zavádět své zvyky aniž by pochopili kontext.

Tohle je hodně lacinej hejt a náběh na flame. Nicméně, za sebe mohu říct, linuxáci přecházejí na Mac stejně dobře, nebo lépe, než windowsáci. Osobně paralelně používám Mac, linux i win. Odjakživa první co jsem vždy na Mac instaloval byl mc (protože nostalgie) a homebrew s normálním repositářem a přemapoval a přenastavil klávesnici a myš podle sebe, a v kanclu používal normální klávesnici . A ktomu doinstaloval stejné aplikace jako kolegové na linuxu. Je to prostě jen jinej unix s jiným grafickým rozhraním. Takže jak říkám lacinej windows-bfu hejt “ježišmarja já nemám tlačítko start vlevo dole a nezavírá se to křížkem vpravo “.

Hm. Takže "ergonomie" znamená "to, na co jsem zvyklý já", a to, na co jsou zvyklí ostatní je "překomplikova­nost". (Zřejmě bez ohledu na počet potřebných pohybů a úkonů.) O "pochopení kontextu" možná platí totéž. A pak tu máme ještě Windows, kde má skoro každá verze novou "ergonomii" a řadu nových "kontextů" k "pochopení". Ale můžeme se hádat donekonečna o tom, co je "ergonomičtější" a argumentovat tím, že ostatní nechápou "náš kontext".

Je to fakt asi primárně o zvyku. Přesně jak jste zmínil, když bude někdo přecházet z Apple prostředí na PC/Linux, taky mu to bude připadat divné.. Nejde jen o periferie, ale i obvyklé zkratky pro navigaci v textu (začátek stránky, odstavce atd.), přepínání mezi více okny v rámci jedné aplikace vs více aplikacemi, otevírání preferencí od aplikace atp., zvyklosti které jsou tam možná od 80-90. let.

Já mám třeba zas rád klávesnice s vyšším zdvihem u desktopu, proto mám u současného Mac mini starou USB klávesnici A1048 (už je tam přes tři Macy).
Zas třeba ten jejich touchpad (jak v notebooku, tak i USB varianta) mi přijde opravdu skvěle implementovaný (i tím, že to chodí dobře ve všech nativních aplikacích), i když nemá žádná fyzická tlačítka.
Nicméně je to individuální, mám kamaráda zvukaře, který je za léta zvyklý na trackball (což bývalo dost obvyklé vedle mixpultu, kde je málo místa) ten třeba touchpady nenávidí, prostě nefunguje ta zažitá motorická paměť.

12. 6. 2025, 12:51 editováno autorem komentáře

Ano, je to o zvyku. Ked mam laptop zadockovany, tak k nemu pouzivam mechanicku klavesnicu a hernu mys pre pc.

Co sa tyka klavesovych skratiek, vela ludom unika, ze widgety v macOS podporuju subset z Emacs binding - a je zapnuty by default! (daju sa dalej customizovat cez ~/Library/Key­Bindings/Defau­ltKeyBinding.dic­t) Toto je super navykova vec a chyba mi v Linuxe (kedysi to Gtk vedelo tiez) aj Windowse.

Cauky. Bsdckar, aixak, solarisak ( vc xwin+sunrayu), mainframe user zdravi trolla.
Maca pouzivam protoze je to stabilni desktop, nemusim resit korporatni spyware co zabira 8GB po startu na widlich, nehreje to a vydrzi 8-12h na baterce.
Pouzivam to hloupou frikulinskou klavesnici pro gelouse s este hloupejsi mysi naprosto minimalne

13. 6. 2025, 14:52 editováno autorem komentáře

> Vždyť ta věc nemá ani normální klávesnici s funkčními klávesami F1..F12,

Uz ma. Touchbar bol pred nejakym casom zruseny a aktualne macbooky ho uz nemaju.

A to, ci je default fn-funkcia alebo f-funkcia, je zalezitost jedneho checkboxu v nastaveniach.

(A mimochodom, o ESC si pocul? Tak sme pouzivali mc na terminaloch, kde F-klavesy boli podobne naprd namapovane).

12. 6. 2025, 12:18 editováno autorem komentáře

Uz ma. Touchbar bol pred nejakym casom zruseny a aktualne macbooky ho uz nemaju.

No ještěže tak... mimo jiné jsem se s tím setkal na nějakých Thinkpadech (tuším X1 Carbon?) a kromě toho, že ten touchbar uhnil (doslova, degradoval displej pod dotykovou vrstvou), tak to bylo k použití stejně nepříjemné jako ten applí.

Jak mi má escape pomoct s nepohodlím? Ano, technicky to jde, ale...

Terminaly su.. take vselijake. Plus terminfo/termcap databazy su podobne vselijako rozbite. Napr. na aktualnych synology ako user mam htop ciernobielo s rozbitou semigrafikou, ako root to ide korektne (obe su xterm-256color). Alebo aktualny Windows Terminal odchytava Alt+Enter pre prepinanie na fullscreen, ako teda v mc skopirujem cestu k aktualne vyselektovanemu suboru do cmdline? Esc+Enter.

Ale to som odbocil. Teda ESC+cislo = Fcislo. Je to vec nepohodla? Lepsie ako touchbar a vzhladom na dlhu historiu rozlicnych rozbitosti, uz som si zvykol :)

Fx klavesy slo nastavit jako default i na tom Touchbaru, stacilo to kliknout v nastaveni. Stejne jako ted na fyzickych klavesach (pouzivam to tak).

kazdopadne z reakci je zrejme, ze uz jste se rozhodl, ze je vsechno naprd a kazda odpoved je tedy smerovana pouze tim zvolenym smerem :)

Touchbar mi vadil nikoli proto, že na něm mohly být multimediální funkce, ale proto, že když mačkám tlačítka, tak očekávám konzistentně stejnou hmatovou odezvu.

To znamená, že tlačítka mačkám nějakou silou a pokud jsem se u touchbaru zapomněl, tak jsem udeřil prstem do hladké nepoddajné plochy, kde nešlo hmatem rozlišit, kde jedno tlačítko končí a druhé začíná.

Proto mi touchbar vadil všude, na jakémkoli hardwaru a pod jakýmkoli OS. A i nadále vadí, Není to hejt (abych provokoval), je to prostě jen zkušenost, která mi ukázala, že to je pro mě krajně nepříjemné a nepraktické.

Microsoft má WSL, tak i Apple něco potřebuje. Linux je prostě moc důležitý :)

wsl podporuje na nearmove architekture armove binarky? Se ptam pro kamarada...

WSL2 je ✨ virtualizace ✨, ne emulace.

12. 6. 2025, 19:23 editováno autorem komentáře

to nepodporuje ani ten Container. Potřebuje to Apple Silicon (takže AArch64) a pouští to AArch64 binárky, prostě virtualizace.

Interne to pouziva jadro z Kata kontainerov (co mozete mat i v k8s/dockeri). Userland je asi nejaky ich skompilovany staticky.

Nevie to ale memory ballonning. Taky Orbstack vie aj pamat uvolnovat a chvalia sa, ze aj vykon FS sa blizi native (hovorim o Orbstacku).