apple/container में Container Machine फीचर जोड़ा गया

• Mac पर Linux containers को हल्के virtual machine के रूप में बनाने और चलाने का टूल
• WWDC26 में नया जोड़ा गया Container Machine होम डायरेक्टरी और repositories को अपने-आप mount करके तेज़, हल्का और persistent Linux environment चलाने देता है
• पारंपरिक application-स्तर containers से अलग, यह पूरे Linux environment को मॉडल करता है (WSL2 जैसा)
• इमेज के init system को चलाकर लंबे समय तक चलने वाली services रजिस्टर की जा सकती हैं या process manager के तहत applications का परीक्षण किया जा सकता है
• systemd इंस्टॉल की गई इमेज में systemctl start postgresql जैसी वास्तविक Linux services चलाई जा सकती हैं
• यूज़रनेम और होम डायरेक्टरी को अपने-आप map करके repositories और dotfiles को macOS और Linux दोनों तरफ साझा करता है
• repositories macOS के $HOME में रहती हैं और अंदर /Users/<username> पर mount होती हैं, इसलिए macOS editor या IDE में एडिट करते हुए अंदर build और run किया जा सकता है
• profiler, browser, GUI debugger जैसे macOS native tools वही फ़ाइलें पहचानते हैं, इसलिए build और inspect के बीच copy step की ज़रूरत नहीं पड़ती
• alpine, ubuntu, debian जैसी जितनी target distributions चाहिए उतनी Container Machine बनाई जा सकती हैं, और सभी में वही $HOME और dotfiles साझा करके कई distributions पर तेज़ testing की जा सकती है
  • /sbin/init शामिल करने वाली कोई भी Linux image सीधे Container Machine image के रूप में इस्तेमाल की जा सकती है
• यह OCI-compatible container images को consume और create करता है, इसलिए standard container registry से Docker images को pull और push किया जा सकता है
  • वही images दूसरे OCI-compatible applications में भी चलाई जा सकती हैं
  • low-level container, image और process management के लिए यह Containerization Swift package पर निर्भर है
• इसे चलाने के लिए Apple silicon वाला Mac चाहिए, और macOS 26 में सपोर्ट है
  • यह macOS 26 की virtualization और networking की नई सुविधाओं और सुधारों का उपयोग करता है; macOS के पुराने versions समर्थित नहीं हैं
• Apache-2.0 लाइसेंस

कमांड उदाहरण

container machine create alpine:latest --name dev  
container machine run -n dev whoami       # your host username, not root  
container machine run -n dev pwd          # /home/<you> — your Mac home dir, mounted in  
container machine run -n dev              # interactive shell; cd into your repos in $HOME  
  
container machine ls                  # list all container machines  
container machine inspect dev         # JSON detail for one  
container machine stop dev            # stop the container machine  
container machine rm dev              # delete, including its persistent storage  
  
container machine set -n dev cpus=4 memory=8G  
container machine stop dev  
container machine run -n dev -- nproc  

WWDC26 का परिचय वीडियो - Container Machine पर एक नज़र

• Containerization, WWDC 25 में open source के रूप में जारी किया गया Swift framework है, जो macOS पर Linux containers चलाने की नींव है
• इसे हर container के लिए virtual machine-आधारित isolation देने के लिए डिज़ाइन किया गया है, और हल्के virtual machines के कारण तेज़ performance तथा 1 सेकंड से कम startup time देता है
• Container machine, Containerization के ऊपर बना नया फीचर है, जो containers की usability और speed को virtual machine की persistence के साथ जोड़ता है, और integration features के ज़रिए Linux environment को macOS के विस्तार जैसा महसूस कराता है

• डिज़ाइन सिद्धांत

  • Container machine इतना तेज़ और हल्का होना चाहिए कि वह मौजूदा workflows में आसानी से शामिल हो सके
  • macOS और Linux के बीच आसानी से स्विच किया जा सके
  • उपयोगकर्ता नए environments को जल्दी बना और customize कर सकें, ताकि कई projects अपनी अलग environments रख सकें और dependencies या toolchain conflicts की चिंता न हो
  • development lifecycle के दौरान ज़रूरी tools और dependencies बदल सकते हैं, इसलिए persistent environment में tools जोड़े जा सकें और उन्हें बाद में फिर से इस्तेमाल किया जा सके
  • कई platforms को target करते समय बड़े context switch या नए tools सीखने की ज़रूरत नहीं होनी चाहिए

[recast7838]

क्या इससे पर्याप्त प्रदर्शन मिल पाएगा?

[click]

कैसे भी देखें तो यह Mac के लिए WSL2 जैसा ही लगता है, लेकिन host volume mapping करते समय क्या IO performance बहुत गिरने जैसी समस्या नहीं होगी?
अभी भी limactl से VM के ऊपर container चला रहा हूँ, तो ऐसा भी लगता है कि बहुत बड़ा फ़र्क नहीं है

[GN⁺]

Hacker News की राय

• यहाँ कुछ बातें साफ़ कर दूँ, यह सिर्फ़ OCI कंटेनरों के बारे में नहीं है
  Container Machines persistence और filesystem mount को सपोर्ट करता है, इसलिए macOS इस्तेमाल करने वाले डेवलपर्स के लिए यह एक बेहतरीन हल्का Linux environment बन जाता है
  ज़्यादा जानकारी यहाँ: https://developer.apple.com/videos/play/wwdc2026/389

  • आह, तो Linux के लिए Darwin/BSD subsystem है

• OrbStack मेरे लिए बहुत अच्छा काम करता है
  performance के मामले में यह उससे कैसा तुलना करेगा, जानने की जिज्ञासा है

  • मैं OrbStack का डेवलपर हूँ
    Virtualization.framework की जगह, filesystem sharing जैसी चीज़ों के लिए custom devices और protocols वाले Rust-based virtualization stack का सीधे इस्तेमाल करता हूँ
    यह Linux machines और containers चलाने के लिए विशेष रूप से optimized, vertically integrated stack है
    सबसे बड़ा performance/resource फ़ायदा dynamic memory है, जो unused memory को macOS को वापस दे देता है, जिससे memory usage काफी कम हो जाता है
    Containerization समेत बाकी चीज़ें इसे सपोर्ट नहीं करतीं
    Container Machines इस्तेमाल करके देखा, तो यह OrbStack machines की तुलना में default bind mounts लगे OCI containers के काफ़ी ज़्यादा क़रीब लगा
    integration features कम हैं, और यह systemd या सामान्य init system नहीं चलाता, इसलिए services चलाना कठिन है
  • OrbStack का concept मुझे पसंद है, लेकिन open source और free alternatives बहुत हैं, इसलिए $96/वर्ष license को सही ठहराना मुश्किल लगता है
    अभी तो मैं Podman या Colima ही इस्तेमाल करूँगा
  • https://tart.run/ के साथ तुलना भी देखना चाहूँगा
    मुझे तो यह काफ़ी मिलता-जुलता लगता है
  • यह पूरा Docker environment नहीं है, बल्कि build use cases के लिए बनाया गया है
    चाहें तो dockerd भी चला सकते हैं, और https://github.com/cpuguy83/crucible Containerization framework के साथ buildkitd या dockerd चलाकर docker/buildx CLI या अपनी पसंद के client tools से जोड़ देता है
    Containerization framework, Virtualization framework के ऊपर बनी library है, इसलिए हर container का अपना VM होता है
    Machine, Containerization framework के ऊपर बना एक tool है जो VM के अंदर containers पर कई tasks चलाता है
  • मुझे OrbStack सच में बहुत पसंद है, और अभी तक समझ नहीं आ रहा कि इस समय Container Machines को इसकी जगह क्यों इस्तेमाल करूँ

• क्या ये containers common kernel शेयर करते हैं? या हर एक अलग VM में चलता है?
  संपादन: हर container के लिए एक VM है https://github.com/apple/container/blob/main/docs/technical-...

• Apple containers AI coding agents को sandbox देने के लिए अच्छे हैं
  मैंने इसे MCP के रूप में बनाया है ताकि सभी coding agents इसे आसानी से खोज सकें
  https://github.com/instavm/coderunner

• मैं सोच रहा था कि container volume को, उदाहरण के लिए, external drive पर बदला जा सकता है या नहीं
  अभी मैं QMEU और qcow2 images के साथ ऐसा कर रहा हूँ, और यह ठीक-ठाक काम कर रहा है

• समझ नहीं आता कि macOS WSL1-style approach क्यों नहीं आज़माता
  Windows पर वह पूरी तरह सफल क्यों नहीं हुआ, यह समझता हूँ, लेकिन macOS तो एक और *nix है, इसलिए Windows में जो चीज़ें मुश्किल थीं उनमें से बहुत-सी Mac पर आसान होनी चाहिए
  कुछ नए APIs जोड़कर ज़्यादातर Linux applications को macOS पर native तौर पर चलाना संभव लगता है
  BSD में तो वास्तव में यह पहले से मौजूद है

  • Apple को वैसे भी जिस VM infrastructure की ज़रूरत है, उसके मुकाबले इसका क्या फ़ायदा होगा?
    Linux kernel की तुलना में ABI काफ़ी ज़्यादा सरल और स्थिर है

• क्या यह Docker Desktop जैसी चीज़ों की जगह लेकर साथ में चलने वाले महंगे Linux VM को हटा सकता है?

  • मेरे मन में भी सबसे पहले यही आया था
    Docker Desktop का overhead काफ़ी ज़्यादा है, इसलिए अच्छा होगा अगर यह DD में native रूप से आ जाए
    Docker ने ऐतिहासिक रूप से performance सुधारने की कोशिश की लेकिन उसे जल्दी ही platform limitations को स्वीकार करना पड़ा, यह देखते हुए यह संभव लगता है, और DD को container side पर ले जाना स्वाभाविक लगता है
  • यह बड़े shared background VM को ज़्यादातर हटाकर उसकी जगह छोटे और ज़्यादा isolated Apple-native VM लाता है
    मैंने अपना Podman workload Apple container पर शिफ्ट करने का प्रयोग किया: https://gist.github.com/jmonster/39e14585e107dbf990a90966c0f...
    संक्षेप में, RAM/storage usage कम हो जाता है और इसका असर लगभग नगण्य रहता है
  • यहाँ भी दूसरों ने कहा है, लेकिन मैं हाल में Colima पर चला गया हूँ
    Docker Desktop को बाइपास करते हुए काम करना काफ़ी परेशान करने वाला है
  • वह सच में बहुत अच्छा होगा
    लगता है मैं हर कुछ दिनों में rm -rf ~/.colima चला रहा हूँ

• यह देखकर हैरानी होती है कि Apple ने इस पर इतना ध्यान दिया
  फिर भी मैं अब भी Linux ही इस्तेमाल करना चाहूँगा, लेकिन MacBook की value बहुत ज़्यादा है

  • मैं भी हमेशा Linux इस्तेमाल करना चाहूँगा, लेकिन कभी-कभी कंपनी MacBook दे देती है
    यह tool शायद मैं इस्तेमाल करूँ

• हर बार जब Apple को Linux containers दिखाते देखता हूँ, तो इसे हार मानने की स्वीकारोक्ति के अलावा और कुछ मानना मुश्किल है
  अगर उनमें अब भी क्षमता होती, तो Darwin के साथ ही सब किया जा सकता था

  • Apple ने जिस क्षण macOS को proprietary code बनाने का फ़ैसला किया, उसी समय उसने server और developer market में अपनी हार की ज़मीन तैयार कर दी
    कोई गंभीर developer ऐसे closed-source code का इस्तेमाल क्यों करेगा जिसे वह debug और fix ही न कर सके? ख़ासकर production servers पर?
    गंभीर developers या hackers macOS क्यों नहीं इस्तेमाल करते, इसकी वजह भी यही है
    developer होने का एक अहम हिस्सा यह है कि आप किसी भी layer के code में उतरकर debug और fix कर सकें
  • बस internet के 30 साल के इतिहास को बदलना होगा
  • विकल्प क्या है?
    Apple ने 10 साल पहले server market छोड़ दिया था, और उससे पहले भी असली support लगभग नहीं था
    अगर Darwin containers को support भी करे तो उसका मतलब क्या होगा? सचमुच कोई भी उसके लिए build नहीं करेगा, और Linux जीत चुका है

• क्या यह नया feature है?
  मुझे लगा यह पहले से मौजूद था
  जब मैंने इसे test किया था, तब बहुत सारे छोटे files पर stat करने वाले Node/Rust development environments में filesystem performance उपयोगी स्तर की नहीं थी
  अपडेट: नया हिस्सा container machine subcommand है
  मैंने इसे आज़माने की कोशिश की, लेकिन मेरे environment में container चला ही नहीं: https://github.com/apple/container/issues/1681

  • क्या आपने OrbStack इस्तेमाल किया है?
    अभी और काम बाकी है, लेकिन test workloads का स्वागत है
    OrbStack के custom filesystem sharing protocol में छोटे files और सामान्य developer workloads को optimize करने पर हमने बहुत मेहनत की है
    यह standard virtiofs नहीं है
  • जानकारी के लिए, Podman macOS पर भी काम करता है
    यह machine चलाने के लिए पहले से मौजूद container framework का इस्तेमाल करता है
    rootful और rootless, दोनों तरीके संभव हैं