Linux के लिए app development

 (makealinux.app)
1 पॉइंट द्वारा GN⁺ 2023-12-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Linux desktop और mobile पर नए software की मांग है, लेकिन app store और repository में applications की कमी है, इसलिए नए distro बनाने से ज़्यादा app development पर ध्यान देने का संदेश दिया गया है
  • किसी व्यक्ति की ज़रूरत से शुरू हुआ app भी अगर publicly develop किया जाए, तो वह learning material और community बनकर Linux ecosystem के विस्तार तक पहुंच सकता है
  • सैकड़ों distros की विविधता एक बोझ लग सकती है, लेकिन documented packaging और distribution systems का इस्तेमाल करके अलग-अलग environments के users तक app पहुंचाए जा सकते हैं
  • GNOME, KDE Frameworks, elementary OS, Electron, Ubuntu Touch क्रमशः Gtk, Qt, Vala, JavaScript·HTML·CSS, QML जैसे अलग-अलग development paths प्रदान करते हैं
  • AppCenter, AppImage, Flatpak, Open Build Service, Snapcraft जैसे distribution options उपलब्ध हैं, और paid apps·services तथा patronage-based app stores के जरिए monetization की संभावना भी है

Linux को और apps की ज़रूरत क्यों है

  • desktop और mobile Linux users में नए software की demand है
  • Linux app stores और repositories में proprietary platforms की तुलना में applications कम हैं
  • tech enthusiasts से यह अपील की जा रही है कि वे नए Linux distros बनाने के बजाय Linux users के लिए नई applications बनाने में अपना passion और creativity लगाएं
  • मुख्य संदेश है: “Linux distro बनाना बंद करो और applications बनाओ”

app development का ecosystem पर असर

  • अगर आपके पास व्यक्तिगत रूप से ज़रूरी किसी app का idea है, तो संभव है कि दूसरी users को भी वही ज़रूरत हो
  • अगर आप application को public रूप से बनाते हैं, तो नए developers भी उससे सीखकर शुरुआत कर सकते हैं, जिससे अगली पीढ़ी के Linux app development को मदद मिलती है
  • application development एक creative काम है, और project पूरा करने पर मिलने वाली achievement की भावना भी एक reward हो सकती है
  • app development community बनाने में मदद करता है, और Linux community अक्सर developers को सफल होते देखना चाहती है
  • software development skills की मांग है, और सीखने के लिए बहुत से free resources भी उपलब्ध हैं
  • यह धारणा कि Linux users developers को financially support नहीं करते, एक गलतफहमी है; popular paid apps और services के जरिए नई income streams बनाई जा सकती हैं

अलग-अलग Linux distros को target करना

  • Linux, दूसरे platforms के विपरीत, बहुत विविध targets वाला ecosystem है, और इसके सैकड़ों distros मौजूद हैं
  • एक बार प्रकाशित होने के बाद application आमतौर पर कई environments में चल सकता है
  • अच्छी तरह documented packaging और distribution systems उपलब्ध हैं, जिनसे developers users तक app पहुंचा सकते हैं
  • हर development framework और Linux distro के पास users तक app पहुंचाने का एक recommended path होता है
  • जब आप app share करने के लिए तैयार हों, तो development docs में recommended packaging guides देख सकते हैं

development शुरू करने के रास्ते

  • GNOME

    • GNOME project, GNOME Shell desktop बनाता है और Gjs तथा Gtk आधारित development को support करता है
    • Gtk में Python, C, C++, Rust, JavaScript जैसी popular languages का इस्तेमाल किया जा सकता है
    • GNOME Developer Center

  • KDE Frameworks

    • KDE, Plasma desktop और application बनाने के tools·frameworks प्रदान करता है
    • KDE Frameworks का इस्तेमाल कई तरह की desktop applications के development में किया गया है
    • इसमें मुख्य रूप से Qt toolkit और C++ programming language का उपयोग होता है
    • KDE Frameworks Getting Started

  • elementary OS

    • elementary OS खुद को Windows और macOS के विकल्प के रूप में एक तेज, open और privacy-respecting operating system मानता है
    • इसके developers ने app development के लिए desktop और ecosystem तैयार किया है
    • developer guide में Vala और Gtk की सिफारिश की गई है
    • elementary OS Developer Guide

  • Electron

    • Electron, JavaScript, HTML, CSS से cross-platform desktop apps बनाना संभव बनाता है
    • developers विशाल node module library का इस्तेमाल कर web technology आधारित apps बना सकते हैं
    • Electron Documentation

  • Ubuntu Touch

    • Ubuntu Touch एक open source operating system है, जिसे phones, tablets, PCs सहित कई devices पर चलने के लिए design किया गया है
    • native Ubuntu Touch apps को QML या HTML में बनाया जाता है, और उनका behavior JavaScript, C++, Python, Rust, Go से define किया जाता है
    • Ubuntu Touch Documentation

Linux app ecosystem पर developers की राय

  • GNOME Foundation के Neil McGovern का मानना है कि Linux को आम लोगों तक ले जाने के लिए एक thriving app ecosystem ज़रूरी है, और अगर हर कोई Linux के लिए develop कर सके तो open desktop के लक्ष्य के और करीब पहुंचा जा सकता है
  • KDE e.V. के Aleix Pol का कहना है कि Linux को पसंदीदा operating system बनाना है, तो बेहतरीन apps चाहिए, और development tools की मदद से आप अपनी कल्पना को साकार कर सकते हैं
  • elementary के founder Daniel Foré का मानना है कि desktop Linux पर शानदार apps बनाने के अलावा platform API बनाने और desktop की दिशा को प्रभावित करने का अवसर भी है
  • UBports Foundation board member Jan Sprinz के अनुसार Linux app development, closed ecosystems से पूरी तरह अलग है; तकनीकी रूप से प्रतिस्पर्धा होने पर भी लोग एक बड़े vision के लिए सहयोग करते हैं

apps को share और distribute कैसे करें

  • AppCenter

    • यह independent developers के लिए एक open pay-what-you-want app store और build service है
    • AppCenter Dashboard, GitHub के साथ integrate होकर release और issue tracking को support करता है
    • AppCenter Dashboard

  • AppImage

    • desktop Linux applications को AppImage format में distribute करके सामान्य Linux distro users तक पहुंचा जा सकता है
    • इसका दावा है: एक बार package करो और कहीं भी चलाओ
    • AppImage Packaging Guide

  • Flatpak

    • यह Linux desktop applications की distribution के लिए एक framework है
    • इसे Linux desktop पर लंबे समय से काम कर रहे developers ने बनाया है, और यह एक independent open source project के रूप में चलाया जाता है
    • Flatpak Documentation

  • Open Build Service

    • openSUSE Build Service, Open Build Service का public instance है
    • इसका उपयोग openSUSE distro development के साथ-साथ Fedora, Debian, Ubuntu, SUSE Linux Enterprise सहित कई distros के लिए एक ही source से packages उपलब्ध कराने में होता है
    • openSUSE Build Service Help

  • Snapcraft

    • Snapcraft, snaps बनाने के लिए command-line tool है
    • snaps को desktop, cloud, IoT के लिए app packages बताया जाता है, जो easy to install, secure, cross-platform और dependency-free होते हैं
    • Snapcraft Documentation

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

1 टिप्पणियां

 
GN⁺ 2023-12-11
Hacker News की रायें

  • मुझे लगता है कि आधार ही गलत है, क्योंकि Linux में अभी तक ABI-stable core frameworks का कोई bundle नहीं है
    प्रतिस्पर्धी platforms पर CoreImage, CoreAudio, CodeML, SceneKit, AppKit जैसे built-in frameworks कहीं ज्यादा हैं और वे कम बार टूटते हैं
    Linux के snap या flatpak भी दिलचस्प हैं, लेकिन यह apps से अपेक्षित frameworks और programming language में ही समाधान करने के बजाय infrastructure और package management के जरिए रास्ता निकालने जैसा है

    • Linux enthusiast community आम तौर पर ऐसी दिशा का सक्रिय विरोध करती है। क्योंकि वे हर चीज़ को modular बनाना और किसी खास application के हिसाब से assemble करना चाहते हैं
      Linux में भी de facto standard bundles हैं, लेकिन चीज़ें बदलती और deprecated होती रहती हैं, इसलिए stability कम है। फिर भी यह बाहर से दिखने से बेहतर है, और Snaps कुछ समस्याओं को कम कर सकते हैं
      हालांकि अगर लोग ऐसी distribution चुनते हैं जिसमें वे standards नहीं हैं, तो जिस पल आप हर तरह की अजीब configuration को support नहीं करते, आप संभावित users के आधे हिस्से को खो देते हैं
    • मैंने कहीं पढ़ा था कि अभी Linux पर सबसे stable target Wine या Proton के जरिए Win32 है
    • इसका core GNOME या KDE frameworks और FreeDesktop standards होना था, कम से कम 20 साल पहले योजना यही थी
      लेकिन लेख में जैसा कहा गया है, ज्यादातर लोग लगातार distributions बनाने पर ही केंद्रित रहे, और स्वाभाविक रूप से अनगिनत अजीब distributions के साथ चल सकने वाला single stack बनना मुश्किल है
      आखिरकार Google ने Linux kernel लिया और Java व JavaScript आधारित core frameworks के दो bundles उसके ऊपर रख दिए, और आम consumers के लिए वही Linux distributions विजेता बन गईं
    • मेरे हिसाब से मुख्य जिम्मेदारी glibc developers की है। version name का दुरुपयोग और हाल में नए ELF relocation types जोड़ने जैसी चीज़ें, कई distributions पर game binaries distribute करना दर्दनाक बना देती हैं
      आम तौर पर game developer किसी latest बड़े distribution पर build करके Steam पर upload करता है, और अगर उस distribution में glibc 2.36 है, तो binary में भी अक्सर ऐसे version names आ जाते हैं जो glibc 2.36 या उससे ऊपर मांगते हैं
      आखिरकार binutils gas के symver directive का इस्तेमाल करके किसी पर्याप्त पुराने glibc से compatible version names जबरन सेट करने पड़ते हैं। निजी तौर पर मैं 5 साल, शायद 7–8 साल को भी reasonable मानक मानता हूं: https://sourceware.org/glibc/wiki/Glibc%20Timeline
      सामान्य game developers को ऐसी समस्या के बारे में मुश्किल से पता होता है, और पता हो भी तो वे market के 1% के लिए इतना दर्दनाक काम नहीं करेंगे। libgcc और C++ के मामले में libstdc++ को भी statically link करना होगा ताकि उस ABI issue से बचा जा सके
      फिर भी Godot engine ऐसे build containers दे रहा है जो इन बातों का ध्यान रखते हैं, और Unity भी इस तरफ साफ-सुथरा दिखता है। UT5.x के बारे में ठीक से नहीं जानता
      दूसरी ओर Electron-based games जैसे कुछ engines तैयार नहीं हैं। Enlightenment, Qt, pure X11, Wayland जैसी distributions के अनुकूल GTK+ version न हो तो वे चल नहीं सकते
      व्यापक range की ELF/Linux distributions को target करके पूरे Google Blink engine को ठीक से package कर binary distribute करना भी आसान नहीं है
      ELF/Linux कुल मिलाकर ABI breakage की वजह से binary-only distribution के प्रति hostile है, खासकर SDK और core libraries में
      अगर game binaries भी इतनी मुश्किल हैं, तो apps और कठिन होंगे। मुझे दिखता है कि developers आखिरकार कहेंगे, “फर्क नहीं पड़ता, बस Microsoft SUSE GNU/Linux install करके इस्तेमाल करो, बाकी supported नहीं हैं”
    • अगर Linux में macOS जितनी व्यापक frameworks की range होती, तो मैं अपने personal projects भी बहुत पहले Linux target करके बना चुका होता
      support period, कौन-सा fork बेहतर है, दूसरी third-party libraries के साथ ठीक बैठता है या नहीं—ऐसी चीज़ों की लगभग चिंता किए बिना सीधे इस्तेमाल कर सकने वाले tools का होना बड़ी बात है। यह friction को बहुत घटा देता है और आपको बस बनाने देता है
      KDE Qt ecosystem और GNOME/GTK side सबसे करीब हैं, लेकिन अभी उस स्तर पर नहीं हैं

  • हो सकता है कि मुझे वह pattern पता न हो जिससे तय होता है कि package नामों में dev और version कब लगाना चाहिए, और पीछे लगने वाले मनमाने 1 या 0 का क्या मतलब है, लेकिन मुझे लगता है कि consistent package naming rules वाला पहला Linux distribution दिल जीत लेगा
    libgnutls-dev
    libgtk-3-0
    libwayland-server0
    libxcb1
    libx11-6
    libffi-dev
    libncurses5-dev

    • -dev में headers होते हैं, इसलिए यह समझना काफी आसान है
      संख्या उस version को दिखाती है जब एक साथ कई versions install किए जा सकते हैं. हालांकि xcb1 की तरह अगर वह library name का हिस्सा हो, तो exception हो सकता है
      उदाहरण के लिए किसी समय libgtk-3-0 और libgtk-2-$something को एक साथ install किया जा सकता रहा होगा. बाद में libgtk-2 हटाने पर भी पुराने tutorials में libgtk-3-0 reference न टूटे, इसलिए नाम रहने दिया गया होगा
      libwayland-server0 के अंत का 0 मुझे भी ठीक से नहीं पता. /var/lib में same library के कई .$number suffix लगे हुए दिखते हैं, लेकिन यह असल में क्या solve करता है, मैंने कभी खोदकर नहीं देखा
    • binaries और source को अलग करना Debian convention है. अगर आप सिर्फ library use कर रहे हैं, तो non--dev package काफी है; और अगर उस library से development करना है, तो headers install करने वाला -dev भी चाहिए
      पीछे का 1 या 0 कोई खास चीज नहीं, बस package name या version का हिस्सा है
    • Arch और उसके derivative distributions में आमतौर पर ऐसी चीज नहीं होती
      हालांकि -dev का मतलब वे चीजें हैं जो सिर्फ उस library को target करके development करते समय चाहिए होती हैं
      संख्या major version number, यानी compatibility number है. इससे अलग-अलग packages जिन multiple major versions पर depend करते हैं, उन्हें बिना conflict के साथ install करना आसान हो जाता है
    • अगर आप program build कर रहे हैं, तो -dev package install करें. नंबर लगे -dev packages पर आमतौर पर सीधे ध्यान देने की जरूरत नहीं होती; जरूरत हो तो बिना नंबर वाला package उसे forward कर देना चाहिए
      build के दौरान यह record होता है कि कौन-सा numeric suffix, यानी ABI version, इस्तेमाल हुआ. यह .so.N suffix जैसा होना चाहिए, लेकिन इसे सीधे उस तरह खोजा नहीं जाता
      इस तरीके से incompatible library copies कई install की जा सकती हैं, और सही वाली इस्तेमाल हो सकती है. distributions आमतौर पर हर बड़े release में पुरानी चीजें साफ कर देते हैं
      install करते समय build के दौरान record की गई dependencies अपने-आप use होनी चाहिए
    • GoboLinux है, और मेरे नजरिए से यह सब कुछ solve करता है और Nix जितना जटिल भी नहीं है. लेकिन किसी ने ध्यान नहीं दिया

  • यह Linux platform को पीछे खींचने वाली सबसे बड़ी समस्याओं में से एक है. लोग अक्सर इसे benefit कहते हैं, लेकिन मैं इसे ऐसा नहीं देखता
    developers ज्यादा choices को Linux की ताकत बताते हैं, लेकिन कई users के लिए यह paradox of choice बन जाता है और उन्हें अपने पुराने platform पर वापस भेज देता है
    macOS और Windows में choices कम हैं, लेकिन जो choices उपलब्ध हैं वे कहीं ज्यादा polished और कम fragmented हैं
    उदाहरण के लिए कितने tiling window managers चाहिए? क्या best tiling window manager चुनकर बेहतर dock और applets नहीं बनाए जा सकते? tiling window manager paradigm में integrate होने वाले apps और launcher का क्या?
    इसके बजाय अक्सर 10 तरह के tiling window managers और उनके ऊपर चढ़े अधूरे workaround programs ही रह जाते हैं

    • लोग हर option का exhaustive analysis करके नहीं चुनते. वे कुछ candidates देखते हैं और popularity या accessibility के आधार पर एक चुनकर इस्तेमाल करते हैं
      successful ecosystem यह सुनिश्चित करता है कि दिखाई देने वाला option चुनने पर भी result काफी अच्छा हो
      Linux distributions का बढ़ना ज्यादातर छोटी-छोटी differences है जो meaningful suitability को कम नहीं करतीं, और इसे समस्या वही बहुत कम लोग मानते हैं जिन्हें distribution चुनने में पहले से कोई खास दिक्कत नहीं थी
      इसके उलट Wayland जैसे मामले में plumbing और hardware अचानक महत्वपूर्ण हो जाते हैं, और usable combination चुनने के लिए internal structure की कुछ समझ चाहिए, इसलिए यह सचमुच समस्या बनता है
      Mac या Windows की Linux से तुलना करना भी बहुत meaningful नहीं है. 95% consumers के लिए operating system computer की fixed characteristic या feature है, अलग product नहीं
      पूरा package fit हो तो वे उस operating system वाला computer खरीद सकते हैं, लेकिन अपने Windows या Mac device पर अलग से install करने की कोशिश नहीं करते
      जिन लोगों के पास संतोषजनक technical knowledge है, वे Ubuntu derivatives के 3 और Arch derivatives के 2 और बढ़ जाने से बहुत confuse नहीं होंगे
    • tiling window manager बनाना मजेदार है. collaboration से software बनाना सिर्फ कोई output पाने का माध्यम नहीं, अपने-आप में भी एक उद्देश्य है
      open source developer होने का मतलब है कि आप goals और means खुद तय कर सकते हैं, और commercial software development में अक्सर ऐसी आजादी नहीं होती
      rough edges तो आते हैं, लेकिन IKEA effect काम करता है और आखिर में वह पसंद आने लगता है
    • यह समस्या distributions के solve करने की domain है. जिन्हें बहुत choices नहीं चाहिए, वे ऐसा distribution इस्तेमाल कर सकते हैं जो उनकी ओर से कई choices कर दे; पूरे ecosystem से choices हटाने के लिए pressure डालने की जरूरत नहीं
      अगर सब same software इस्तेमाल करें, तो यह attacks के लिए ज्यादा vulnerable monoculture ecosystem बन जाता है. Windows viruses का बड़ा target इसलिए भी बना क्योंकि target बड़ा और consistent था
      एक सामान्य user की Windows machine में घुस जाएं तो बाकी में भी लगभग वैसे ही घुसा जा सकता था. Linux को target करना कहीं ज्यादा मुश्किल है
      ऊपर से यह free software है. अगर हम किसी को पैसे देकर काम नहीं करवा रहे, तो ज्यादातर volunteer activity है, और हम दूसरों के volunteer time को कहां खर्च करना है, यह नहीं बता सकते
      इतने सारे groups होने के बावजूद अगर कोई join करना नहीं चाहता, तो dominant social structure को भी देखना चाहिए. शुरुआत उन codes of conduct को हटाने से हो सकती है जो project के बाहर के behavior तक punish करने देते हैं
    • मुझे लगता है launchers और docks, tiling window managers से ज्यादा हैं
      और यह भी साफ नहीं कि क्या और improve करना है. Ulauncher या Albert जैसी चीजें दूसरे platforms पर possible चीजों से कहीं ज्यादा powerful हैं, और UI को कैसे बेहतर बनाया जा सकता है यह भी समझ नहीं आता
    • जितने tiling window managers लोग बनाना चाहते हैं, उतने होने चाहिए

  • सॉफ़्टवेयर का बढ़ना अच्छी बात है। लेकिन शुरुआत से नया बनाने से पहले, जो पहले से मौजूद है उसमें योगदान देना, या ऐसा प्रोजेक्ट चुनना कैसा रहेगा जो छोड़ा जा चुका हो या जिसे नए compiler और hardware पर build/run होने लायक बनाने के लिए थोड़ा काम चाहिए?
    यह भी जानना चाहूंगा कि कहीं कोई निष्क्रिय/मृत projects database है क्या, जिनमें नई जान डालना worthwhile हो

    • पहले से मौजूद कोई चीज़ शायद मेरे लक्ष्य वाले तरीके से बनी न हो
      कोई दूसरा प्रोजेक्ट ऐसे व्यक्ति के नेतृत्व में हो सकता है जिसके साथ काम करना मुश्किल हो, या उसकी community सुझाव और patches स्वीकार न करती हो
      सामाजिक प्रक्रियाएं और रुकावटें योगदान की प्रेरणा खत्म कर सकती हैं। हर कोई बिना व्यक्तित्व वाला आशावादी team player नहीं बन सकता
      मेरे लिए शुरुआत से नया शुरू करना बेहतर है। क्योंकि मैं सभी variables control कर सकता हूं, मौजूदा social/technical infrastructure को छेड़ने की जरूरत नहीं, किसी को यह मनाने की जरूरत नहीं कि मेरा idea अच्छा है, और मैं code से ज्यादा बहस और चर्चा में समय नहीं लगाना चाहता
      solo development का अनुभव बेहतर है। क्योंकि यह politics और सामाजिक प्रक्रियाओं में नहीं बांधता, और team player बनने की कोशिश ने मुझे सिर्फ तकलीफ दी है
    • अधिकतर क्षेत्रों में low-quality प्रयास बहुत ज्यादा हैं, और अगर वह मेहनत कुछ top projects में इकट्ठी हो जाए तो कुछ शानदार apps निकल सकते हैं
      collaboration बोझिल और मुश्किल लग सकता है, लेकिन आखिरकार वही परिणाम देता है और यह उस समय से बेहतर उपयोग है जो किसी छोड़े जाने वाले project पर खर्च होगा
    • क्या कोई प्रमुख Linux package repositories में ऐसे stats इकट्ठे करता है जिनसे बहुत इस्तेमाल होने वाली लेकिन unmaintained या अधूरी features वाली apps खोजी जा सकें?

  • कई लोग शिकायत करते हैं कि अलग-अलग operating systems पर compatible apps बनाने के tools कम हैं, लेकिन मैं सहमत नहीं हूं। Electron के अलावा भी solutions मौजूद हैं
    Telegram Qt इस्तेमाल करके तीनों operating systems पर performance वाली native app ship करता है
    Flutter तीनों operating systems और mobile पर native code में compile होता है
    Kirigami एक QtQuick framework है, जो mobile और desktop दोनों targets के लिए चलने वाली apps बनाने देता है
    बस app बना दीजिए। इसे Linux को दोष देने का बहाना बनाने की जरूरत नहीं

    • Flutter हर platform पर थोड़ा अलग व्यवहार करता है, इसलिए सभी platforms पर अनुभव subtle तौर पर खराब हो जाता है। Kirigami या Qt Quick को भी practically viable विकल्प कहना मुश्किल है
      Windows, macOS और mobile पर community या गंभीर projects लगभग नहीं हैं। KDE को नीचा दिखाने का इरादा नहीं है, लेकिन reality यही है
      Qt Quick की licensing भी iOS पर आसान नहीं है, या commercial route लेने पर बहुत महंगी है
      इसके उलट Electron में बड़ी कंपनियां निवेश कर रही हैं और बहुत polished production-grade tools दे रही हैं, एक विशाल community और library ecosystem है, और यह Dart जैसी अपरिचित language भी नहीं है
      Telegram सच में एक level extra effort करता है। client बेहतरीन है
    • Qt-based Telegram app भी macOS पर अच्छी चलती है, लेकिन अधिकतर Apple users macOS और iOS के लिए Swift/Cocoa client चुनते हैं[0]
      [0]: https://github.com/overtake/TelegramSwift

  • समस्या यह है कि OSS सॉफ़्टवेयर अक्सर बाज़ार से मुकाबला करने की कोशिश तक ठीक से नहीं करता
    OSS सॉफ़्टवेयर इस्तेमाल करने वाले लोग यह मानकर चलते हैं कि UX में कमी होगी, और असल में भी अक्सर ऐसा ही होता है
    सामान्य proprietary software में यह जोखिम होता है कि यूज़र पैसे नहीं देंगे, इसलिए वे अंतिम यूज़र अनुभव बेहतर बनाने के लिए खुद को ढालते हैं, लेकिन OSS में आमतौर पर ऐसा जोखिम नहीं होता। Open source को भी अंतिम यूज़र से आने वाले जोखिम के सामने expose होने की ज़रूरत है
    Notes[1] के ज़रिए मैंने इसे बदलने की कोशिश की, लेकिन लगा कि सिर्फ़ विज्ञापनों पर टिके रहना मुश्किल है। Kanban जैसी premium features के लिए payment भी जोड़ी, लेकिन ऐप पूरी तरह FOSS है, इसलिए कोई भी source से आसानी से compile कर सकता है
    अगला ऐप[2] release से पहले closed source रखने का सोच रहा हूँ। मैं यह जोखिम नहीं उठा सकता कि मेरी मेहनत का प्रतिफल न मिले
    अगर पैसे लिए जा सकें, तो Linux पर UX-केंद्रित ऐप्स में और निवेश किया जा सकता है, इसलिए मुझे लगता है कि यह Linux community के लिए भी मददगार होगा। कुछ हिस्सा open source कर सकता हूँ, और बहुत दूर भविष्य में शायद पूरा भी खोल दूँ
    [1] https://github.com/nuttyartist/notes
    [2] https://www.get-plume.com

    • Linux यूज़र्स और freedom को महत्व देने वालों का overlap बड़ा है। बहुत से लोगों के लिए non-open-source नोट ऐप vendor lock-in और privacy समस्याओं के कारण शुरू से ही विकल्प नहीं होता
      इसलिए अगर आप प्रोग्राम को open source नहीं बनाते, तो संभव है कि आप उससे ज़्यादा खो दें जितना open source बनाकर कुछ लोगों के पैसे न देने का जोखिम उठाने से खोते
      मेरा मानना है कि proprietary software इस्तेमाल करने वालों की तुलना में, पैसे देकर भी open source इस्तेमाल करने वाले लोग कहीं ज़्यादा होंगे
      Open source होने का मतलब यह नहीं कि आपको code सबको distribute करना ही होगा; अगर आप पैसे लेते हैं, तो source code सिर्फ़ paid users को भी दे सकते हैं। हालांकि उन्हें modification और redistribution के अधिकार मिलेंगे
      अगर किसी को open source में रुचि नहीं है, तो वह Notion या Evernote इस्तेमाल कर सकता है। अगर modern open-source notes app चाहिए, तो Logseq recommend करूँगा
    • लगता है आप सही फैसला कर रहे हैं। Open source से रोज़ी-रोटी चलाने लायक पैसे कमाना बेहद कठिन है, और commercial software से जीवनयापन करने वालों की तुलना में इसका scale कई orders of magnitude छोटा है
    • आपकी झुंझलाहट समझता हूँ, लेकिन counterexamples भी हैं। मेरा इरादा नीचा दिखाने का नहीं है
      पहला, Notes काफ़ी हद तक Standard Notes जैसा दिखता है। अगर आपने copyleft OSS का इस्तेमाल करके Notes बनाया है, तो उसमें शामिल दूसरे programmers के काम पर royalty दिए बिना शिकायत करना मुश्किल लगता है
      दूसरा, मैं शायद atypical user हूँ। मैंने 20 साल से ज़्यादा Linux इस्तेमाल किया है, लेकिन Bash script या Perl की एक लाइन भी ठीक से नहीं लिख सकता
      लेकिन क्योंकि मैं coding नहीं कर सकता और दूसरों के काम व उससे मिलने वाली freedom की कद्र करता हूँ, इसलिए मैंने software पर उतने पैसे खर्च किए हैं जितने दूसरे platforms पर individual users आमतौर पर नहीं करते
      मैं Kaisen और Debian, FSF की core utilities और Emacs, KDE, Mozilla के Firefox, Betterbird, Syncthing, LaGrange, Joplin, ClipTo, SoulSeek और envs.net जैसी services सहित कई जगह support करता हूँ
      कुछ को हर साल, कुछ को हर महीने, और कुछ को सिर्फ़ एक बार भुगतान करता हूँ
      Standard Notes जब पहली बार आया था, तब भी मैंने 7 साल की subscription ली थी, लेकिन लगभग दो महीने इस्तेमाल करके संतुष्ट नहीं हुआ और छोड़ दिया। Alacritty जैसी चीज़ें भी हैं जिन्हें मैं बहुत इस्तेमाल करता हूँ लेकिन donation का तरीका नहीं मिला, और ऐसे मामलों को कम से कम रखने की कोशिश करता हूँ
    • निजी तौर पर मुझे KDE, macOS और Windows से काफ़ी आगे लगता है
      असल में macOS लोकप्रिय platforms में सबसे खराब window managers में से एक लगता है। यह सुंदर और इस्तेमाल में आसान है, लेकिन basic से आगे कुछ करना हो तो ऐसे magic spells चाहिए जो naturally discover नहीं होते
      बेशक, सबकी पसंद अलग होती है
    • मेरे कुछ विचार हैं। मैं इस क्षेत्र को काफ़ी follow करता हूँ, फिर भी उस app के बारे में कभी नहीं सुना, और competition बेहद कड़ा है
      Premium pricing देखने के लिए click किया; yearly basis पर reasonable था, लेकिन सिर्फ़ monthly subscription option दिखा, इसलिए वह मुश्किल लगा
      ऐसे apps में premium version के लिए payment करने की बजाय donation करने की संभावना ज़्यादा होती है। Obsidian में वह model अच्छी तरह काम किया
      मुझे नहीं लगता कि features का early access बहुत value देता है, लेकिन काम को support करने के लिए पैसे देने वाले लोग बहुत हैं
      साथ ही, बंद core product के आसपास बड़ा open-source ecosystem होने वाली संरचना लोगों को पैसे देने की वजह देती है

  • अच्छा होता अगर लेख में कुछ उदाहरण होते
    मुझे आसानी से ऐसा कोई व्यक्ति याद नहीं आता जो distro बना रहा हो जबकि उसे असल में application बनानी चाहिए। ज़बरदस्ती सोचें तो शायद LinuxCNC? लेकिन उसकी कुछ specific kernel requirements हैं, इसलिए custom distro शायद ज़्यादा सही हो सकता है

    • Desktop environment असल में ऐसी application है जिसे एक-दो clicks या commands से आसानी से install किया जा सकता है
      derivatives की derivatives distros सिर्फ़ अलग desktop environment शामिल करके distribute की जाती हैं, यह बात मुझे ठीक से समझ नहीं आती

  • “Linux distros बनाना बंद करो, applications बनाओ” कहने के बजाय, मुझे लगता है कि बेहतर है उन लोगों की बातें सुनना बंद करें जो बताते हैं कि क्या करना चाहिए और क्या नहीं

    • मुझे भी वह tone खटकी
      फिर भी message और जानकारी अपने-आप में अच्छी है
      निजी तौर पर मैं शायद इसे “Linux users और distros नहीं चाहते। उन्हें software चाहिए” जैसा कहता। कम से कम मेरे लिए तो ऐसा ही है
    • जो लोग कहते हैं कि क्या करना चाहिए और क्या नहीं, उनकी बातें सुनना बंद करो—ऐसा कहने वालों की बातें भी सुनना बंद करना चाहिए। सब कुछ relative नहीं होता; अच्छे choices और बुरे choices होते हैं

  • हाल ही में Mac से Linux पर शिफ्ट हुआ, मकसद था एक अच्छी परफ़ॉर्मेंस वाला सेकंड-हैंड डिवाइस रोज़मर्रा की मशीन के तौर पर इस्तेमाल करना
    पहले भी कई मशीनों पर Linux इंस्टॉल किया था, लेकिन इस बार यह सिर्फ़ शौक नहीं है
    Ubuntu मेरे हार्डवेयर और peripherals को अच्छी तरह सपोर्ट करता है, लेकिन ऐप स्टोर अधूरा और ज़बरदस्ती जोड़ा हुआ-सा लगता है। फिर भी लगभग सब कुछ उम्मीद के मुताबिक काम करता है
    Mint, Debian, Arch भी आज़माना चाहता हूँ, लेकिन लगता है कि बहुत-सा software Ubuntu को ध्यान में रखकर लिखा गया है, इसलिए थोड़ा सतर्क हूँ

    • Linux Mint, Ubuntu पर आधारित है, इसलिए Ubuntu packages बिना समस्या इस्तेमाल किए जा सकते हैं। असल में इसे बेहतर Ubuntu भी माना जा सकता है
      Debian-आधारित Mint version भी है, लेकिन वह Ubuntu पर बहुत ज़्यादा निर्भर न रहने के लिए एक safety net जैसा है
      आजकल कोई असामान्य distribution इस्तेमाल करने पर भी बड़ी समस्या नहीं होती। क्योंकि अगर default package manager मनचाहा app उपलब्ध न कराए, तो AppImage, Flatpak, Snap इस्तेमाल किए जा सकते हैं
    • Ubuntu के लिए लिखी गई चीज़ों में ऐसी बहुत कम हैं जो Arch या ज़्यादातर modern distributions पर न चलें
      Arch इस्तेमाल करते समय लोगों की Ubuntu-केंद्रित assumptions की आदत डालनी पड़ी थी, लेकिन ज़्यादातर मामला config files patch करने या environment variables set करने भर का था
      ऐसी चीज़ें उपयोगी skills हैं और दूसरी जगहों पर भी काम आती हैं
    • Fedora भी एक बार ज़रूर आज़माना अच्छा रहेगा
      सोचता हूँ, काश इसे पहले आज़माया होता

  • समझ नहीं आता कोई ऐसा क्यों करेगा। यह ज़्यादा मुश्किल है, और Linux users उन चीज़ों के लिए पैसे नहीं देते जिन्हें वे पैसे देने लायक नहीं समझते

    • क्योंकि दुनिया में अच्छा free software ज़्यादा होगा तो सभी के लिए बेहतर होगा