Flatpak अब systemd पर निर्भर होने वाला है

 (osnews.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Flatpak अब तक “हर distro के लिए app build” को अपनी बड़ी ताकत बताता रहा है, लेकिन अगले प्रमुख version में systemd dependency जुड़ने की संभावना काफी बढ़ गई है
  • Flatpak Next या Flatpak 2.0, मौजूदा 1.x की दशकों पुरानी design सीमाओं को पार करने के लिए लगभग एक rewrite जैसा होगा, और अभी योजना के चरण में है
  • नई service systemd-appd app identifiers और permissions को store करेगी, और दूसरे components उन्हें query कर सकेंगे; साथ ही यह subsandboxing को संभव बनाने में केंद्रीय भूमिका निभाएगी
  • non-systemd distros के लिए elogind जैसी स्वतंत्र daemon implementation की गुंजाइश थी, लेकिन विवाद बढ़ने के बाद developers की इस दिशा में सहयोग की इच्छा कमजोर होती दिख रही है
  • अगर systemd dependency सख्त हो जाती है, तो Void, Guix, Alpine जैसे distros पर Flatpak का इस्तेमाल मुश्किल हो सकता है और इसकी distro neutrality भी कमजोर पड़ सकती है

Flatpak की distro neutrality में बदलाव की संभावना

  • Flatpak वेबसाइट अपनी पहली बड़ी खासियत के रूप में “Build for every distro: create one app and distribute it to the entire Linux desktop market.” बताती है, और supported distros की सूची में Void Linux, Guix, Alpine जैसे ऐसे distros भी शामिल हैं जो systemd के बजाय दूसरे init systems का इस्तेमाल करते हैं
  • अभी Flatpak इस बात की परवाह नहीं करता कि user कौन-सा init system चला रहा है, लेकिन अगले major version में systemd dependency जुड़ने की संभावना काफी बढ़ गई है
  • अगर यह बदलाव वास्तव में लागू होता है, तो मुख्य सवाल यह होगा कि क्या systemd का इस्तेमाल न करने वाले distros पर Flatpak को आगे भी उपलब्ध कराया जा सकेगा

Flatpak Next और redesign की दिशा

  • Arian Vovk और Sebastian Wick ने Linux App Summit में Flatpak के भविष्य पर एक presentation दी
  • Flatpak के मौजूदा version में सुधार जारी रहेंगे, लेकिन दशकों पुरानी design की सीमाओं को bypass करना लगातार कठिन होता जा रहा है
  • Flatpak Next या Flatpak 2.0 नाम से चल रहा यह काम, Flatpak 1.x के बाद जमा हुए अनुभव को दर्शाने वाला एक तरह का वास्तविक rewrite है
  • नई design को Flatpak की शुरुआती design के बाद स्थापित हुई आधुनिक technologies और ideas का उपयोग करने की दिशा में योजना बनाई जा रही है
  • presentation की सामग्री अभी सिर्फ योजना के स्तर पर है, और क्योंकि अभी तक एक लाइन code भी नहीं लिखी गई है, आने वाले कुछ वर्षों में काम आगे बढ़ने के साथ नतीजे काफी बदल सकते हैं

systemd-appd और permissions management का बदलाव

  • Flatpak की development direction में सबसे बड़ा बदलाव यह है कि permissions management को Flatpak के अंदर रखने के बजाय service layer में ले जाया जाए
  • नई service systemd-appd applications को identifiers देगी, permissions store करेगी, और system के दूसरे components को यह data query करने देगी
  • यह structure कई features को संभव बनाता है, जिनमें खास तौर पर subsandboxing एक महत्वपूर्ण feature माना जा रहा है
  • मौजूदा योजना यह है कि इस feature को वर्तमान Flatpak version में ही लाया जाए, और इसके परिणामस्वरूप Flatpak में systemd dependency आ जाएगी

non-systemd distros के लिए गुंजाइश

  • Vovk की व्याख्या के अनुसार, systemd का इस्तेमाल न करने वाले distros और users का “बहुत ध्यान” रखने का इरादा था
  • एक संभावित मॉडल elogind की तरह माना जा सकता है, जहाँ systemd-logind को एक अलग daemon के रूप में split किया गया ताकि दूसरे init systems इस्तेमाल करने वाले distros भी systemd-logind पर निर्भर desktop environments चला सकें
  • ऐसा लगता है कि Flatpak developers ने भी systemd-appd के लिए इसी तरह की स्वतंत्र daemon implementation संभव रहे, इसके लिए जितनी व्यावहारिक गुंजाइश हो सके उतनी छोड़ने की कोशिश की थी
  • अगर यह approach बनी रहती, तो Flatpak के systemd का इस्तेमाल न करने वाले distros पर भी उपलब्ध बने रहने की संभावना थी

विवाद बढ़ना और developers की प्रतिक्रिया में बदलाव

  • Void या Alpine जैसे distros के users ने चिंता जताई कि अगर Flatpak systemd पर बहुत अधिक निर्भर हो गया, तो यह उनके systems पर काम करना बंद कर सकता है
  • Flatpak development में तकनीकी रूप से शामिल न रहे एक व्यक्ति पर सवालों की बाढ़ आ गई, और उसके जवाब कभी मददगार नहीं थे, कभी अपमानजनक, और कभी उकसाने वाले रहे
  • बहुत-से लोगों ने गलतफहमी में मान लिया कि वह Flatpak development से जुड़ा है, और इस वजह से गंभीर व मित्रतापूर्ण सवाल, तथा anti-systemd रुझान वाली तीखी प्रतिक्रियाएँ आपस में मिलकर स्थिति को और खराब करती गईं
  • इसके परिणामस्वरूप Flatpak developers ने ऐसी प्रतिक्रिया दिखाई कि वे systemd का इस्तेमाल न करने वाले distros और users का ध्यान रखने में समय नहीं लगाना चाहते
  • अगर यह रुझान जारी रहा, तो systemd dependency और सख्त हो सकती है, और systemd-appd feature को replicate करने वाली स्वतंत्र daemon implementation बनाना शुरुआती अनुमान से कहीं अधिक कठिन हो सकता है

संभावित नतीजे और महत्व

  • मौजूदा स्थिति को देखते हुए, आने वाले कुछ वर्षों में Flatpak के systemd dependency अपनाने की संभावना ज्यादा है
  • यह गुंजाइश भी खत्म हो सकती है कि systemd का इस्तेमाल न करने वाले distros के लिए systemd-appd features को replace करने वाला कोई स्वतंत्र daemon बनाया जा सके
  • ऐसा होने पर Flatpak के लिए यह दावा करना मुश्किल होगा कि एक ही app को हर distro तक पहुँचाने वाली इसकी distro neutrality बनी हुई है
  • Flatpak ऐसा tool है जिसकी वास्तविक मांग users में उनके init system से परे मौजूद है, इसलिए यह बदलाव Linux desktop app distribution की पहुँच पर सीधा असर डालेगा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Lobste.rs की राय

  • समझ नहीं आता कि लोग systemd से इतनी नफ़रत क्यों करते हैं। मेरे हिसाब से यह आसान API और उचित dependency·conflict management के ज़रिए उपयोगी फीचर्स देता है।
    systemd को नापसंद करने वाले अक्सर बस ऐसे धुंधले कारण देते हैं जैसे “यह Unix जैसा नहीं है”, “यह केंद्रीकृत है”, “systemd-journald का फ़ाइल फ़ॉर्मैट plain text नहीं है”।
    अगर आप विरोध करते हैं, तो ठोस वजह, समाधान, और यह भी बताइए कि दूसरे init systems क्यों बेहतर हैं। तब मैं समझा सकता हूँ कि rc scripts कितने भयानक और बेतरतीब hacks हैं

    • लिंक की गई Mastodon बहस का बड़ा हिस्सा असल में systemd-विरोध से ज़्यादा केंद्रीकरण-विरोध के करीब है। अगर Flatpak systemd पर निर्भर हो जाता है, तो दूसरे init systems इस्तेमाल करने वाली Linux distributions के लिए flatpak की उपलब्धता खत्म हो जाएगी।
      Linux की philosophy कम-से-कम मेरे लिए मूल रूप से choice के बारे में रही है, और अगर Flatpak किसी खास init system की मांग करता है, तो मनचाहा नतीजा पाने के लिए system configure करते समय user के options कम हो जाते हैं
    • मैं systemd का अच्छे से उपयोग करता हूँ, लेकिन Flatpak जैसे मामले में विरोध समझ में आता है। Flatpak की मूल उपयोगिता लगभग “किसी भी Linux distribution पर चल जाने” वाली है, और systemd dependency उस उपयोगिता को कुछ हद तक कम कर देती है
    • systemd को लेकर मेरी बिना बदली हुई शिकायतें इतनी हैं: journald implementation खास अच्छी नहीं है, लेकिन idea अपने-आप में ठीक है, और units को manage करने वाली असली abstraction यानी job queue में कुछ अजीब edge cases हैं जो undocumented हैं या ढूँढ़ना मुश्किल है।
      इसे container images में डालना आसान होना चाहिए, और user systemd को system instance के read API access मिलना चाहिए ताकि कम-से-कम After, Requires जैसी चीज़ों से units schedule किए जा सकें।
      फिर भी, मुझे लगता है कि HAL हटने के बाद Linux में हुई यह सबसे अच्छी चीज़ है, और मैंने Lennart से मिलकर project के लिए धन्यवाद भी दिया है
    • Chimera जैसे लोग, जो सच में भरोसेमंद alternative stack बना रहे हैं, FUD नहीं फैलाते और विनम्र व सहज हैं। दूसरी तरफ, online outrage crowd के पास साफ़ तौर पर कोई समाधान नहीं है, और आगे भी शायद नहीं होगा।
      ये “विरोधी” व्यवहार में लगभग यह कह रहे हैं कि समाधान का अस्तित्व ही नहीं होना चाहिए। ये Linux के HOA की तरह बर्ताव करते हैं, और मुझे यह उस प्रतिक्रियावादी राजनीति जैसा लगता है जो वास्तव में मजबूत, usable, competitive systems की उस प्रगति को रोकती है जो monopolistic operating systems को पीछे धकेल सकती है
    • अगर बात सिर्फ ऐसे systems की हो जो वेबपेज serve करते हैं या GUI browser में वेबपेज दिखाते हैं, तो मुझे systemd से नफ़रत नहीं है। VPS पर deploy की जाने वाली चीज़ों में सीधे systemd units इस्तेमाल करना भी ठीक है, और अगर SysV init या upstart होता तो भी मुझे ज़्यादा शिकायत नहीं होती।
      लेकिन laptop पर मेरी ज़रूरतें अलग हैं। मेरे अपने विचार हैं कि personal environment कैसे काम करे, मैं कुछ ऐसे convenience features भी चाहता हूँ जो आम Linux users नहीं चाहते, और मैं चाहता हूँ कि जो चीज़ें मैंने साफ़ तौर पर नहीं मांगीं, वे अपने-आप न हों। “कुछ चलाने के लिए मेहनत” से कहीं ज़्यादा मुझे “कुछ बंद कराने के लिए मेहनत” से चिढ़ है।
      NixOS को systemd की वजह से छोड़ने का मुख्य कारण था लगातार बढ़ता दायरा और opinionated defaults। power management और login handling के integrate होने के बाद ढक्कन बंद करते ही अनिवार्य suspend होने जैसी चीज़ों को हर बार फिर से ठीक करना पड़ता था, linger permission scope में बदलाव ने POSIX द्वारा अपेक्षित nohup और screen को तोड़ दिया, और ज़्यादा सख्त VT management ने “एक बार login करके कई Xorg instances चलाना” या “VT पकड़ना” जैसी चीज़ों को systemd तरीके से फिर डिज़ाइन करने पर मजबूर किया।
      आखिर में मैंने तय किया कि minimal init sinit और बिना service supervision के रहना बेहतर है, और मैंने shell boot scripts खुद लिखीं, जिनमें system functionality का कुछ हिस्सा shell में और कुछ Common Lisp में implement किया। laptop पर PostgreSQL जैसी चीज़ें एक बार शुरू हों तो चलती रहती हैं, अगर रुकें तो मैं नोटिस कर सकता हूँ, और अगर restart काफ़ी है तो मामला आसान है, और अगर वह भी काफ़ी नहीं है तो service supervisor भी मदद नहीं करेगा।
      भरोसा टूटने के उदाहरणों में यह शामिल है कि HDD पर journald से cold cache स्थिति में logs दिखाने के लिए मिनटों इंतज़ार करने पर भी output नहीं आया, मैंने खुद https://github.com/systemd/systemd/issues/2913 का अनुभव किया, और nohup तोड़ने में उन्हें कोई हिचक नहीं थी।
      development process में भी https://github.com/systemd/systemd/issues/437 पर ऐसा रवैया, जो लगभग “हम अच्छे defaults देते हैं, लेकिन defaults खराब हों तो distribution उन्हें ठीक कर सकती है” जैसा लगा, और stable API promises से हिचक दिखाने वाला http://lists.freedesktop.org/archives/systemd-devel/… जैसा रुख, भरोसा कम करने वाला था।
      हालांकि ये शिकायतें पुरानी हैं। systemd कुछ समस्याएँ हल करते हुए दूसरी समस्याएँ पैदा करता दिखा, और दोनों ही वे समस्याएँ नहीं थीं जो मेरे पास शुरू से थीं; यह देखने के बाद मैंने laptop पर boot shell scripts अपना लीं, और अब maintenance cost इतनी कम है कि systemd को फिर से आज़माने की कोई वजह नहीं दिखती। VPS पर मैं Debian के परिचित दायरे में systemd इस्तेमाल करता हूँ

  • यह बात परेशान करती है कि इस मामले की शुरुआत Flatpak developer नहीं रहे किसी व्यक्ति ने गलत जानकारी से की, फिर भावनात्मक प्रतिक्रिया भड़की, और मूल thread आगे बढ़ते-बढ़ते Flatpak project और developers की प्रतिष्ठा पर और भी तीखे शब्दों के साथ लोग टूट पड़े।
    नतीजतन, यह भी हैरानी की बात नहीं कि असली Flatpak developers भावनात्मक रूप से प्रभावित हुए और गुस्साई भीड़ से दूरी बनाना चाहते हों।
    अच्छा होगा कि सब लोग शांत हों और इस बात को और न बढ़ाएँ। अगर कोई संदेह या चिंता है, तो असली maintainers से बात करें, बीच का रास्ता निकालने के समर्थन का संकेत दें, और दिखाएँ कि यह पूरे community का प्रतिनिधित्व नहीं बल्कि कुछ व्यक्तियों की अलग-थलग घटना है।
    जैसे systemd dependency का विचार भी कोई तय फैसला नहीं बल्कि एक idea था, वैसे ही maintainers के लिए ज़्यादा तरह के projects के support पर फिर से विचार करने की संभावना भी अभी बंद नहीं हुई है

  • अच्छा होगा अगर लोग इतने सहयोगी रहें कि systemd पर न चलने वाले systems का support भी जारी रखा जा सके। Flatpak और दूसरे container तरीक़े users को ऐसे packages चलाने में मदद करते हैं जो target platform पर आसानी से build नहीं होते, इसलिए जब किसी खास software की ज़रूरत हो तो ऐसे systems पर Flatpak चला पाना उपयोगी है।
    containers भी कुछ हद तक यही काम करते हैं, लेकिन काफ़ी असामान्य setups में x11docker जैसी चीज़ों को सही से चलाना परेशान करने वाली हद तक मुश्किल हो सकता है

    • मैं 10 साल से ज़्यादा समय से Void को संतोष के साथ इस्तेमाल कर रहा हूँ। init system या systemd integration की आख़िरी बार कब चिंता की थी, यह भी याद नहीं। Void पर किए गए सारे काम के लिए धन्यवाद

  • मैं अपने laptop पर Void इस्तेमाल करता हूँ; इस पर काम करना काफ़ी efficient है और documentation भी काफ़ी अच्छी है। developers ने अब तक जो भी काम किया है उसके लिए आभारी हूँ, और उम्मीद है कि Flatpak में यह बदलाव बहुत बड़ा बोझ नहीं बनेगा

  • “यही आधुनिक Linux है, और बस systemd है।”
    यह साफ़ तौर पर याद दिलाता है कि Linux community किसी community से ज़्यादा WeWork जैसी है। आसपास लगभग सभी लोग Red Hat की मौजूदगी पर निर्भर वेतन पा रहे हैं, जबकि कोई GNU readline को मुफ़्त में hack कर रहा है

    • यह कहना मुश्किल है कि लेख इस हिस्से में ग़लत है: यानी यह बात कि “यह कट्टर anti-systemd Red Hat साज़िश सिद्धांतकारों (और उससे भी बदतर लोगों) को खींच लाता है”

  • इस चरण पर पक्के तौर पर यह कहना कि “यह निर्भर हो जाएगा” अभी बहुत जल्दबाज़ी होगी और यह काफ़ी अटकल-आधारित लगता है

  • यह दिलचस्प है कि शीर्षक लेख के मुख्य भाग से कहीं ज़्यादा निर्णायक है। बहुत-सी टिप्पणियाँ साफ़ तौर पर सिर्फ़ शीर्षक पर प्रतिक्रिया दे रही हैं, और शुक्र है कि सब नहीं, लेकिन इंटरनेट पर यह नया नहीं है
    आजकल lobste.rs पर भी मैं अक्सर देखता हूँ कि लोग सिर्फ़ शीर्षक या किसी लंबी टिप्पणी की एक पंक्ति पर ही प्रतिक्रिया देते हैं, और यह चिंताजनक है। आम तौर पर वे अपनी पहली, और अक्सर आक्रामक, व्याख्या के अलावा किसी और संभावना के लिए बहुत कम जगह छोड़ते हैं
    लेख पढ़ने पर लगता है कि Flatpak 2.0 की बहस में भी कुछ ऐसा ही हुआ था। शायद दूसरे init systems के लिए जगह रखने की कोशिश की गई थी, लेकिन उसके आसपास की बहस जल्दी ही शत्रुतापूर्ण हो गई और लगता है कि उसे लगभग छोड़ दिया गया

  • वैकल्पिक init system इस्तेमाल करने वालों के लिए यह सच में बहुत निराशाजनक है। मैं एक laptop पर Alpine Linux चला रहा हूँ, और सिर्फ़ glibc पर चलने वाले software को चलाने के लिए Flatpak का इस्तेमाल करता रहा हूँ। यह बदलाव मुझे उस environment से बाहर कर देगा
    मुझे systemd से नफ़रत नहीं है। मेरे सभी Gentoo systems systemd-आधारित हैं। लेकिन मुझे यह पसंद नहीं कि systemd जिस तरह free/open source software को GNU/Linux पर धीरे-धीरे और ज़्यादा निर्भर बनाता जा रहा है

  • यह निश्चित रूप से अच्छी बात है
    systemd स्थिर और अच्छी तरह परिभाषित API वाले daemons से बना है, इसलिए Flatpak जिस भी हिस्से पर निर्भर होगा, अगर कोई मेहनत करे तो उसे शुरुआत से साफ़-सुथरे ढंग से फिर से implement किया जा सकता है
    यह संभवतः सबसे अच्छा नतीजा है। fragmentation कम होगी, और जिन लोगों की ज़रूरतें अलग हैं उन्हें reimplementation के लिए एक स्थिर target मिल जाएगा

    • मैंने इसे पहले व्यंग्य समझकर पढ़ना शुरू किया था, लेकिन ऐसा नहीं था
      systemd API अक्सर man pages में अस्पष्ट रूप से परिभाषित होती हैं, और क्योंकि systemd पक्ष दूसरी implementations की उम्मीद नहीं करता, इसलिए वे दोनों दिशाओं में stable या versioned भी नहीं हैं
      notify socket API के मामले में तो यह स्थिरता उलटी दिशा में ही है। vsock support जोड़ने से वे daemons व्यवहारिक रूप से टूट गए जो libsystemd पर निर्भर हुए बिना implement किए गए थे। यह breakage ज़्यादा ज्ञात नहीं हुई क्योंकि vsock मुख्यतः virtualization boundary के पार systemd-to-systemd communication के लिए था। अगर इसे सही ढंग से design किया गया होता, तो इसे सिर्फ़ उसी boundary पर इस्तेमाल होने वाला extension बनाया गया होता
      “daemons” कहा जाता है, लेकिन व्यवहार में ज़्यादातर logind और systemd ही हैं, और यही दोनों पूरी API surface को expose करते हैं, इसलिए composition की संभावना सीमित है। यह कुछ DBus interfaces, अब varlink, और एक single library के ज़रिए ऐसा करता है
      systemd को replace करने के लिए या तो उसे पूरा का पूरा replace करना होगा और internal model को systemd-style API के रूप में expose करने के लिए मुश्किल से fit करना होगा, या पहले systemd की API design choices को अलग करके plug-able backends देने वाली एक मध्य-परत बनानी होगी
      मैं कई सालों से इस समस्या से जूझ रहा हूँ। systemd के कई design principles मुझे उचित लगते हैं, लेकिन मौजूदा design ज़्यादातर लोगों के लिए अनावश्यक complexity को front पर ले आता है। ज़्यादा modular और replaceable design संभव है, और अलग किए जा सकने वाले simple interface designs की कल्पना करना या मौजूदा चीज़ों को reuse करना भी अपेक्षाकृत आसान है
      लेकिन समस्या वह software है जिसने systemd API पर निर्भर रहने का चुनाव किया है। इसे किसी और चीज़ के साथ काम कराने के लिए या तो upstream में ऐसे patches डालने पड़ते हैं जो libsystemd से बँधे feature support को अलग करें, या नए अलग API support जोड़े जाएँ; पहला कभी सफल नहीं हुआ, और दूसरा release से पहले/कम इस्तेमाल होने वाले APIs के maintenance burden के कारण स्वीकार किया जाना मुश्किल है
      या फिर software जिन APIs का इस्तेमाल करता है सिर्फ़ वही implement किए जा सकते हैं। उदाहरण के लिए ऐसा login1 DBus service इस्तेमाल करना जो अधिकांश APIs को implement नहीं करता। लेकिन तब यह API के दूसरे हिस्सों को replace करने की कोशिश करने वाली दूसरी implementations से टकराता है, और आपको मूल साफ़ API, logind/systemd DBus API, और varlink के लिए API — इन तीन variants को implement करना पड़ता है
      लंबे समय में पूरा systemd या logind API implement करके पीछे अलग किए गए APIs से जोड़ने वाला एक router समाधान हो सकता है। लेकिन मौजूदा design में बहुत ज़्यादा duplication और systemd-specific चीज़ें गहराई से भरी हैं, इसलिए इसे ठीक से बनाना बहुत जटिल है
      यह इरादा था या नहीं, पता नहीं, लेकिन systemd developers की बातों से कम-से-कम इतना तो लगता है कि यह ऐसा मुद्दा था जिसकी उन्होंने जानबूझकर परवाह नहीं की। कोई जटिल middle layer बनाए बिना या systemd को दोबारा लिखे बिना systemd replacement बनाना बहुत मुश्किल है, और भले ही applications API के सिर्फ़ उसी हिस्से पर निर्भर हों जिसे isolated pieces के रूप में दिया जा सकता है, फिर भी systemd के सिर्फ़ एक हिस्से को साफ़-सुथरे ढंग से replace करना व्यवहार में लगभग असंभव है
    • क्या यह बात कि systemd के कुछ हिस्सों को शुरुआत से साफ़-सुथरे ढंग से फिर से implement किया जा सकता है, अभी वास्तव में भी सही है? लेख में elogind को उदाहरण के तौर पर दिया गया है

  • मुझे यह तरीका पसंद नहीं कि Red Hat के पास Linux ecosystem पर बहुत ज़्यादा control हो

    • मुझे भी, लेकिन आजकल Red Hat का systemd पर कितना control है, यह मुझे ठीक से पता नहीं
    • यह काफ़ी दोधारी बात है। control को केंद्रीकृत करना बुरा है, लेकिन लोगों को पैसे देकर free/open source software बनवाना अच्छी बात है। और उन्हें जो control मिलता है उसका बड़ा हिस्सा इसी से आता है कि वे लोगों को पैसे देकर free/open source software बनवाते हैं
      फिर भी, Red Hat ने free software को अपनाया है, यह बात उसके प्रभाव को लेकर चिंता को कुछ हद तक कम करती है। सालों में उसने जिन technologies का अधिग्रहण किया, उनमें ऐसी चीज़ें भी थीं जिनका पहले कोई upstream नहीं था, और उनके लिए उसने खुद free/open source upstream बनाए। Dogtag PKI और 389 Directory Server ख़ास तौर पर याद आते हैं
      कुल मिलाकर, यह ecosystem के लिए ज़्यादातर बुरा नहीं रहा, और मेरे हिसाब से इसने नुकसान से ज़्यादा विकास किया है

  • मैं इस बहस से सीधे तौर पर प्रभावित नहीं हूँ, लेकिन Linux systems में लगातार बढ़ती अनावश्यक complexity और abstraction को लेकर जो बेचैनी है, उसे कम करने वाली यहाँ कोई बात नहीं है
    Linux तेज़ी से operating systems की Java बनता जा रहा है। यह सच में दुखद है