Debian 13 "Trixie" रिलीज़

• Debian परियोजना ने लगभग 2 वर्ष 1 माह 30 दिन के विकास के बाद नया stable संस्करण Debian 13 "Trixie" जारी किया
• GNOME 48, KDE Plasma 6.3, LXDE 13, LXQt 2.1.0, Xfce 4.20 आदि कई डेस्कटॉप वातावरण को डिफ़ॉल्ट रूप से सपोर्ट करता है
• 14,100 से अधिक नए पैकेज जोड़े गए; कुल पैकेज संख्या 69,830 हो गई, जबकि 8,840 पैकेज पुराने/obsolete होने के कारण हटाए गए
• 44,326 पैकेज का अपडेट किया गया और व्यापक codebase cleanup किया गया; कुल डिस्क उपयोग 403GB है और कोड लाइनें 14 करोड़ हैं
• समर्थित आर्किटेक्चर: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x
  • riscv64 का आधिकारिक सपोर्ट पहली बार जोड़ा गया
  • i386 सपोर्ट हटाने का निर्णय: official kernel और install tools उपलब्ध नहीं होंगे, इसलिए यह केवल 64-bit CPU पर सीमित रूप से उपयोग किया जा सकता है
  • armel आर्किटेक्चर के लिए यह अंतिम रिलीज़ सपोर्ट है
• i386 को छोड़कर सभी आर्किटेक्चर में 64-bit time_t ABI लागू किया गया है, जिससे 2038 के बाद की तारीखें भी समर्थित होंगी

सॉफ़्टवेयर और डेवलपमेंट टूल्स

• सभी पैकेजों में से 63% से अधिक अपडेट किए गए हैं
• मुख्य सॉफ़्टवेयर और डेवलपमेंट टूल्स: Apache 2.4.64, Bash 5.2.37, BIND 9.20, curl/libcurl 8.14.1, Emacs 30.1, GNU Compiler Collection 14.2, GIMP 3.0.4, LibreOffice 25.2, Linux kernel 6.12 LTS, LLVM/Clang 19, Python 3.13, Rustc 1.85, Systemd 257, Vim 9.1 आदि
• आर्किटेक्चर, सर्वर, डेस्कटॉप, क्लस्टर, डेटाबेस, वेब और स्टोरेज सर्वर जैसी विभिन्न उपयोग के लिए उपयुक्त
• स्वचालित इंस्टॉलेशन और अपग्रेड टेस्ट जैसी गुणवत्ता आश्वासन प्रक्रिया मजबूत की गई है

क्लाउड एवं लाइव इंस्टॉलेशन सपोर्ट

• Amazon EC2, Microsoft Azure, OpenStack, PlainVM, NoCloud आदि cloud services के लिए images उपलब्ध हैं
• क्लाउड images में cloud-init automation और तेज़ instance boot के लिए kernel/bootloader ऑप्टिमाइज़ेशन जोड़े गए हैं
• लाइव images amd64, arm64 के लिए DVD, USB, network boot रूप में उपलब्ध हैं
• लाइव images में कई डेस्कटॉप वातावरण चुनकर अनुभव किया जा सकता है, और बिना GUI वाला standard image भी उपलब्ध है
• Calamares और standard Debian Installer के जरिए इंस्टॉलेशन संभव है; HTTP Boot सपोर्ट सहित कई इंस्टॉलेशन विकल्प उपलब्ध हैं

[zihado]

IRC के Debian चैनल पर पहले मौजूद रहे लोग कैसे हैं, पता नहीं. Debian Potato के समय मैं IRC पर बहुत घूमता था.. हाहा

[jungmin1237]

docker टैग भी पहले ही आ गया है।
https://hub.docker.com/layers/library/…

[dongjinahn]

मैंने भी RAM 512MB वाले $2.5/month VPS पर Ubuntu चलाते-चलाते Debian पर शिफ्ट किया था, और यह अच्छा लगा। Ubuntu से सीधे Debian पर आने के कारण यह स्वाभाविक रूप से परिचित लगा, और यह कम मेमोरी खाता है।

[GN⁺]

Hacker News टिप्पणी

• अभी यह टिप्पणी मैं एक Debian सिस्टम पर लिख रहा हूँ, और personal use में इसे daily driver के तौर पर इस्तेमाल करके मैं बहुत संतुष्ट हूँ। Ubuntu पहले की तुलना में जबसे काफी खराब हो गया, मैं Debian 6 पर स्विच हुआ और मुझे कभी पछतावा नहीं हुआ। Debian का सबसे अच्छा लगने वाली बात यह है कि इसमें philosophy और practicality दोनों में बैलेंस है: डिफ़ॉल्ट रूप से free software को प्राथमिकता देता है, लेकिन जरूरत पड़े तो non-free software या firmware install करना भी आसान है। पैकेज गाइडलाइंस, dpkg और बहुत मजबूत documentation भी बहुत पसंद आए (documentation की बात करें तो Arch अभी भी आगे है)। stable/testing package streams की वजह से पुराने stable विकल्प या नए करीब-करीब स्थिर विकल्प चुनना आसान है। और सबसे बड़ी बात, जब तक मेरी गलती नहीं होती Debian की वजह से system खराब होने की मुझे एक भी बार घटना नहीं हुई। हाँ, कभी-कभी बूट पूरी तरह फेल होने या बड़ी समस्या आने के केस देखे हैं, लेकिन कारण हर बार तीसरे-पक्ष repositories जोड़ना या अपनी सेटिंग गलत edit करना ही रहा।

  • Debian अच्छा है—यह मैं भी मानता हूँ—लेकिन यह कह पाना मुश्किल है कि system तब तक नहीं टूटेगा जब तक कि मैं खुद नहीं तोड़ूँ। खासकर Debian stable में kernel पर बहुत सारे patches backport होते हैं, और DRM subsystem के तेज बदलावों की वजह से backport के दौरान ऐसे कई crashes आए हैं जिन्हें debug करना कठिन था। नाम के लिए kernel version रिलीज़ अवधि में लगभग स्थिर रहता है, लेकिन Ubuntu की तरह लगातार नया kernel (hwe line) चलाना यह patch stress कम कर देता। इसलिए मैं VMs में Debian और bare-metal पर Ubuntu रखता हूँ। मैंने debian-backports repo से kernel अभी कोशिश करके नहीं देखा।

  • मुझे भी Ubuntu Server पर रहते हुए upgrade issues से बहुत परेशानी हुई थी। 75 से ज़्यादा VPS चलाने में maintenance updates के हर दौर में boot-failure हो जाने का डर लगा। उस recovery में प्रति VPS 1–2 घंटे अतिरिक्त लग जाते थे। 2015 के आसपास, 8.x के दौर से Debian पर शिफ्ट करने के बाद से हालत बहुत बेहतर हैं। जब तक मैं कुछ गलत नहीं छेड़ता, तब तक यह टूटता नहीं है।

  • पूछना चाहूँगा कि Ubuntu में कौन-सी बातें आपको “बहुत खराब” लगीं?

  • Debian की एक कमी मुझे यही लगती है कि नया server software install करते ही तुरंत चलाने की कोशिश करता है। अधिकांश default सेटिंग्स safe हैं, लेकिन जब तक मैं खुद config नहीं कर दूँ, service शुरू हो जाए तो थोड़ा डर लगता है। Red Hat में install करने के बाद मैं जब तक खुद manually ना चलाऊँ, service नहीं चलती; इसलिए वो behavior मुझे ज्यादा भरोसेमंद लगता है।

• Debian मेरे server operations की नींव है। servers को मैं Old Stable पर रखता हूँ और नए release features को temporary systems पर test करता हूँ। Bookworm में मैंने nftables सीखा, और Trixie में labwc use करके देखा। labwc, Wayland support करता है और Openbox-style configuration की सुविधा देता है।

• Debian समुदाय के सभी volunteers का मैं आभारी हूँ। Debian और Debian-based countless projects आपके कारण संभव हुए हैं। सच में बहुत से लोग और companies आपके hard work से सीधे benefit ले रहे हैं। Personal स्तर पर, इस Trixie रिलीज़ का आना सच में exciting है। मेरा side project ntfy Trixie में package के रूप में शामिल हो गया है। हालाँकि रिलीज़ साइकिल के आख़िरी हिस्से में पता चला कि ntfy packager ने license पूछताछ करते वक्त बताया कि Debian package से web app हटाया गया था और कुछ फीचर्स patch करके हटाए गए। हमने build tags जोड़कर Stripe, Firebase, WebPush जैसे components हटाना आसान बनाया है, इसलिए अगले Debian release में शायद patches कम करने पड़ेंगे। Upstream maintainer के नज़रिए से देखें तो web app हटने की स्पष्ट guidance न मिलना दुख की बात है। शायद इसे जानबूझकर हटाया गया, लेकिन अगले release में वापस डालने का तरीका ठीक से समझ नहीं आया। अगर apt install ntfy के बाद web app काम न करे तो कई users निराश होंगे। कोई सलाह या guide हो तो welcome। आप source code भी देख सकते हैं।

  • पैकेज maintainer ने संबंधित explanation यहाँ जोड़ दी है। web app nodejs-based है, और Debian में वो nodejs packages मौजूद नहीं हैं। Debian philosophy के अनुसार सीधे package में dependency source शामिल करना पसंद नहीं किया जाता, क्योंकि फिर उन निर्भरताओं के लिए अलग से पैकेज बनाकर maintain करने पड़ते और काम भारी हो जाता।

  • Debian में npm package build को हमेशा buildable होना चाहिए। इसलिए अलग debian-specific package.json में npm dependencies को Debian packages में बदलना, पोर्ट करना या अलग package में देना पड़ता है। अगर lockfile बड़ा है तो workload बहुत बढ़ जाता है। शायद maintainer को यह काम पर्याप्त भारी लगा हो। Debian तरीके से शायद ntfy-web जैसा अलग package देना अधिक natural लगता है।

  • ntfy के लिए काफी शुक्रिया—home setup में मैं इसे daily Meshtastic node से event notifications के लिए use करता हूँ।

  • ntfy software सच में बहुत अच्छे से काम करता है।

  • अगर dependency समस्या को बेहतर तरीके से solve करना है, तो शायद container image के जरिए distribute करना बेहतर option हो सकता है।

• Debian मेरे स्वतंत्र कंप्यूटिंग सफर का reliable base रहा है। Condorcet voting model से मैंने जो सीखा—procedural consensus, principle-based निर्णय—उसका मुझ पर बड़ा प्रभाव पड़ा। इस project और culture का दुनिया पर असर कितना बड़ा है, यह नापा नहीं जा सकता। प्यार के साथ बधाई।

• i386 architecture का generic support आखिरकार खत्म हो गया—नए kernel या installer उपलब्ध नहीं हैं, केवल 64-bit CPUs की recommendation है, और pure 32-bit hardware के लिए अब upgrade recommend नहीं। 2025 अगस्त तक i386 support जारी रहा, जो impressive है। मैं अभी भी जून 2024 में EOL हुए Debian 10 Buster को Pentium 3 hardware पर चला रहा था। पुराने hardware पर प्रयोग करने के लिए support का इतना लंबा चलना वाकई काम का रहा। अगर कोई अभी भी i386 पर latest OS चाहता है तो OpenBSD भी एक विकल्प हो सकता है।

  • मुझे याद था कि मैं करीब 2007 के बाद Pentium 3 पर काम नहीं कर रहा, लेकिन अब तो सिर्फ $1 में 100 गुना तेज़ PC भी मिल सकता है।

  • अगर i386 Debian ports infrastructure (जैसे m68k) में migrate होता है, तो शायद Debian 14 या 15 तक इसे experimental रूप में इस्तेमाल करना संभव होगा।

  • old stable में लगभग 1 साल अतिरिक्त support मिलता है—इसका मतलब 2025 के बाद सब कुछ तुरंत खत्म नहीं।

  • यह Debian support की बात है। Linux kernel की native support अब भी original Pentium के बाद की 32-bit CPUs को मिलती रहती है (कुछ clone chipsets छोड़कर)।

  • कहीं हम 386 और 32-bit को mix तो नहीं कर रहे? आमतौर पर 686 ही standard 32-bit architecture है; 386 तो 1980s की चीज़ है।

• sysvinit अभी भी काम करने के लिए उपलब्ध है। मैंने server/desktop दोनों पर टेस्ट कर लिया है। कुछ packages की dependency समस्या से बचने के लिए नीचे दिए कमांड से install/remove को साथ में run करने पर समस्या टाली जा सकती है। संबंधित Debian bug के मुताबिक, systemd-sysv और systemd हटाते समय नाम के बाद - जोड़ना key है। इस तरीके से debootstrap से बने sysvinit build, bookworm वाले सेटअप के लगभग समान दिखते हैं (desktop सहित)। bookworm या buster में भी, apt preferences में सिर्फ libsystemd0 रखकर बाकी systemd packages को priority -1 पर सेट करने से काम चल जाता है।

  • मुझे जानना है कि Debian 13 में sysvinit ठीक से चलेगा क्या? यानी क्या server को सच में बिना systemd के operate किया जा सकता है?

  • जानकारी साझा करने के लिए धन्यवाद। कम से कम इसे मैं lxc container में test करने की सोच रहा हूँ।

  • पूछता हूँ कि कोई इतनी दूरी तक क्यों जाता है?

• x86-64 .torrent image कहीं खोजने में दिक्कत हो तो लिंक नीचे हैं
  Minimal: netinstall ISO
  Full: DVD ISO

  • अधिकांश users को DVD (full) image की जरूरत नहीं होती। install के समय केवल minimal netinstall CD पर्याप्त है, बाकी packages बाद में download हो जाते हैं।

• Trixie में official तौर पर समर्थन की जा रही 7 architectures यह हैं

  • amd64 (64-bit PC)
  • arm64
  • armel (ARM EABI)
  • armhf (ARMv7 EABI hard-float)
  • ppc64el (64-bit little-endian PowerPC)
  • riscv64 (64-bit little-endian RISC-V)
  • s390x (IBM System z)
    RISC-V के लिए अभी practical hardware बहुत ज्यादा नहीं है, लेकिन इसे finally first-class platform की तरह मिलना अच्छी खबर है। आजकल PowerPC और System z का उपयोग कहाँ होता है, और amd64/arm64/riscv64 के अलावा अन्य architectures वास्तविक deployment में कहाँ हैं—यह जानने का मन है।

  • Power और z अभी भी multi-billion dollar business हैं। दोनों architectures को वित्तीय क्षेत्र और बैंकों में अभी भी खूब use किया जाता है। IBM अभी भी z पर गर्व करता है, लेकिन Power को देखकर लगता है कि अब बस maintenance mode में है—थोड़ा अफसोस। Power का architecture और सिस्टम दोनों बहुत अच्छे हैं।

  • Mainframe का स्थान अभी भी वही है जहाँ एक server से दशकों तक बिना downtime सेवा देनी हो। यहाँ तक कि processor और memory जैसे hardware components भी hot-swap हो सकते हैं, और OS services से अलग hardware हमेशा monitored/diagnostic रहता है। hardware issue detect होने पर owner और IBM को auto alert चला जाता है। IBM ने 2000s की शुरुआत से mainframe पर Linux को first-class OS के रूप में support किया है। developer point-of-view से देखें तो s390x शायद आखिरी बची हुई big-endian architectures में से एक है (SPARC अभी मौजूद है लेकिन effective तौर पर maintenance mode में है, और Oracle अभी मुख्यतः Solaris पर focus कर रहा), इसलिए endian-related bugs खोजने में भी यह useful है। अभी बाकी 32-bit architectures केवल armel और armhf दो ही हैं, और यह release armel के लिए अंतिम है (reference)। जल्द ही official 32-bit support समाप्त होने की संभावना है।

  • IBM इन दोनों architectures को प्रमुख distros में ठीक से काम करने के लिए बहुत प्रयास कर रहा है। इसलिए, बाकी architectures की तरह ये ecosystem में naturally नहीं बचे हैं; IBM के support के कारण ही ये बने रहते हैं।

• अगर systemd में NIC नाम बदलने की चिंता हो, तो release notes देखें (link)। udevadm command से upgrade के बाद interface नाम कैसे बदलेंगे, पहले से देखा जा सकता है। bond/lo को छोड़कर बाकी सूची नीचे दिए one-liner से देखी जा सकती है। मेरी direct testing में अब तक नाम बदलने का कोई केस नहीं मिला, इसलिए यह निश्चित नहीं कि ऊपर की method सच में वास्तविक बदलाव पहले से पकड़ पाती है।

  • शायद यह interface naming का अंतिम बड़ा बदलाव हो। enoX naming हमेशा stable रहनी चाहिए क्योंकि BIOS (ACPI table आदि) पोर्ट-से-पोर्ट ID मैपिंग देता है। ensX तरीका PCIe slot पर आधारित है, लेकिन PCIe tree के कारण एक ही स्लॉट में कई NIC आ सकते हैं, जिससे complexity बढ़ती है। systemd ने इन edge cases संभालने के लिए नाम बदलने की logic कई बार बदल दी है। पहले PCIe slot नंबर को indirect पढ़ने से भी conflict हुआ था, जिसे systemd 257 में ठीक किया गया।

  • upgrade से पहले यदि systemd का Predictable Network Interface Names पहले से disable किया था, तब भी interface नाम बदल सकते हैं क्या?

• मैंने slink के समय से Debian इस्तेमाल किया है। आज भी apt-get ... लिखना पड़ता है और फिर भी यह काफी हद तक ठीक चलता है। 25 साल से ज्यादा time में upgrades के दौरान छोटे-बड़े issues आए हैं, लेकिन जो time/effort लगा वो बाकी Linux या proprietary software की तुलना में सच में बहुत कम था। एक कमी यह है कि मैं community contribution में उतना शामिल नहीं हो पाया। Debian का बड़ा फायदा यह है कि user को system के काम करने के तरीके की कम से कम बुनियादी समझ होनी चाहिए। शायद इसी वजह से यह philosophy अभी भी सही बैठी है: "as simple as possible, but not too simple."

• Debian का एक प्रमुख फायदा यह है कि stable से अगले stable पर 15 मिनट से कम में upgrade किया जा सकता है। मेरे पहले सिस्टम migration में package डाउनलोड और reboot सहित 10 मिनट से कम लगे थे। कोई खास high-end कंप्यूटर नहीं था—बस 50Mbps वाला mini PC था।