Frequently asked questions (हिन्दी)
सामान्य
Arch Linux क्या है?
Arch Linux लेख देखें।
मैं Arch का उपयोग क्यों नहीं करना चाहूँगा?
आप Arch का उपयोग नहीं करना चाहेंगे, यदि:
- आपके पास 'do-it-yourself' GNU/Linux distribution के लिए क्षमता/समय/इच्छा नहीं है।
- आपको x86_64 के अलावा किसी अन्य architecture के लिए support की आवश्यकता है।
- आप एक ऐसे distribution का उपयोग करने पर दृढ़ता से विश्वास करते हैं जो केवल GNU द्वारा परिभाषित free software प्रदान करता है।
- आप मानते हैं कि एक operating system को खुद को configure करना चाहिए, out of the box चलना चाहिए, और installation media पर एक complete default set of software और desktop environment शामिल होना चाहिए।
- आप rolling release GNU/Linux distribution नहीं चाहते।
- आप अपने वर्तमान OS से खुश हैं।
मैं Arch का उपयोग क्यों करना चाहूँगा?
क्योंकि Arch सर्वश्रेष्ठ है।
Arch किन architectures को support करता है?
Arch केवल x86_64 (कभी-कभी amd64 कहा जाता है) architecture को support करता है। नवंबर 2017 में i686 के लिए support बंद कर दिया गया था [१]।
i686 architecture [२] और ARM CPUs [३] के लिए derivative distributions हैं, जिनके अपने community channels हैं। वे Arch Linux द्वारा support नहीं किए जाते।
यदि आप चाहते हैं कि Arch अन्य architectures को support करे, तो आप मौजूदा porting प्रयासों में मदद कर सकते हैं या अपनी खुद की शुरुआत कर सकते हैं। Getting involved#Help porting Arch Linux to other architectures देखें।
क्या Arch Linux Foundation के Filesystem Hierarchy Standard (FHS) का पालन करता है?
Arch Linux systemd service manager का उपयोग करने वाले operating systems के लिए file system hierarchy का पालन करता है। प्रत्येक directory और उनके designations की व्याख्या के लिए file-hierarchy(7) देखें। विशेष रूप से, /bin, /sbin, और /usr/sbin, /usr/bin के symbolic links हैं, और /lib और /lib64, /usr/lib के symbolic links हैं।
मैं एक पूर्ण GNU/Linux beginner हूं। क्या मुझे Arch का उपयोग करना चाहिए?
यदि आप beginner हैं और Arch का उपयोग करना चाहते हैं, तो आपको एक नए system को सीखने में समय लगाने के लिए तैयार रहना होगा, और यह स्वीकार करना होगा कि Arch को 'do-it-yourself' distribution के रूप में design किया गया है; यह user ही है जो system को assemble करता है।
मदद मांगने से पहले, Web, forum और Arch Wiki द्वारा प्रदान किए गए शानदार documentation को खोजकर अपना स्वतंत्र research करें। इन resources को आपके लिए उपलब्ध कराने का एक कारण है। हजारों स्वैच्छिक घंटे इस उत्कृष्ट जानकारी को संकलित करने में खर्च किए गए हैं।
Arch terminology#RTFM और Installation guide भी देखें।
क्या Arch को server के रूप में उपयोग करने के लिए design किया गया है? Desktop के रूप में? Workstation के रूप में?
Arch को किसी विशेष प्रकार के उपयोग के लिए design नहीं किया गया है। बल्कि, इसे एक विशेष प्रकार के user के लिए design किया गया है। Arch सक्षम users को target करता है जो इसकी 'do-it-yourself' प्रकृति का आनंद लेते हैं, और जो इसे अपनी unique जरूरतों के अनुसार system को shape देने के लिए आगे exploit करते हैं। इसलिए, अपने target user base के हाथों में, Arch का उपयोग लगभग किसी भी उद्देश्य के लिए किया जा सकता है। कई लोग अपने desktops और workstations दोनों पर Arch का उपयोग करते हैं। और निश्चित रूप से, archlinux.org, aur.archlinux.org और लगभग सभी Arch की infrastructure Arch पर चलती है।
मुझे वास्तव में Arch पसंद है, सिवाय इसके कि development team को feature X को implement करने की आवश्यकता है
शामिल हों, अपने code/solution को community में योगदान करें। यदि इसे community और development team द्वारा अच्छी तरह से माना जाता है, तो शायद इसे merge कर दिया जाएगा। Arch community code और tools के योगदान और साझाकरण पर फलता-फूलता है।
नया release कब उपलब्ध होगा?
Arch Linux releases केवल installation या rescue के लिए एक live environment हैं, जिसमें base meta package और कुछ अन्य packages शामिल हैं। Releases आमतौर पर हर महीने के पहले half में जारी किए जाते हैं।
क्या Arch Linux एक स्थिर (stable) distribution है? क्या मुझे बार-बार breakage मिलेगी?
यह user ही है जो अंततः अपने rolling release system की स्थिरता (stability) के लिए जिम्मेदार है। User तय करता है कि कब upgrade करना है, और जब आवश्यक हो तो आवश्यक changes को merge करता है। यदि user community से संपर्क करता है, तो अक्सर समय पर मदद प्रदान की जाती है। इस संबंध में Arch और अन्य distributions के बीच अंतर यह है कि Arch वास्तव में एक 'do-it-yourself' distribution है; breakage की शिकायतें misguided और unproductive हैं, क्योंकि upstream changes Arch devs की जिम्मेदारी नहीं हैं।
Arch Linux system को यथासंभव स्थिर (stable) बनाने के tips के लिए System maintenance लेख देखें।
Arch को अधिक press (यानी advertisement) की आवश्यकता है
Arch को पर्याप्त press मिलता है। Arch Linux का लक्ष्य बड़ा होना नहीं है; बल्कि, organic, sustainable growth target user base के बीच स्वाभाविक रूप से होता है।
Arch को अधिक developers की आवश्यकता है
संभवतः ऐसा है। अपना समय volunteer करने के लिए स्वतंत्र महसूस करें! forums, IRC channels, और mailing lists पर जाएं, और देखें कि क्या करने की आवश्यकता है। विवरण के लिए Getting involved भी देखें।
Installation
Arch को एक installer की आवश्यकता है। शायद एक GUI installer?
Text-based user interface के साथ एक guided installer उपलब्ध है। विवरण के लिए archinstall देखें।
मैंने Arch इंस्टॉल किया, और अब मैं shell पर हूँ! अब क्या?
General recommendations देखें।
मुझे कौन सा desktop environment या window manager उपयोग करना चाहिए?
चूंकि कई आपके लिए उपलब्ध हैं, उस का उपयोग करें जो आपकी जरूरतों को सबसे अच्छी तरह से फिट करता है। Desktop environment और Window manager लेख पर एक नज़र डालें।
अन्य "minimal" distributions के बीच Arch को क्या unique बनाता है?
Arch compared to other distributions देखें।
System maintenance
System maintenance भी देखें।
अन्य operating systems की तुलना में मेरा internet इतना धीमा क्यों है?
क्या आपका network सही ढंग से configured है? Network configuration लेख पर एक नज़र डालें। Advanced setups के लिए, आप traffic shaping को भी देखना चाह सकते हैं।
सबसे अधिक उपयोग किए जाने वाले kernels में से एक, linux, अन्य, अधिक स्थिर (stable), Linux distributions के kernel की तुलना में नया होता है। इसके कारण, आप शायद ही कभी kernel regression या driver bug का अनुभव कर सकते हैं, विशेष रूप से यदि Wi-Fi का उपयोग कर रहे हैं। ध्यान दें कि उन bugs में से अधिकांश Arch Linux-specific नहीं हैं क्योंकि Arch Linux केवल सबसे बुनियादी patches लागू करता है। इसे upstream लेने की आवश्यकता है। #मैंने package X के साथ एक error पाई है। मुझे क्या करना चाहिए? देखें।
Arch मेरे सभी RAM का उपयोग क्यों कर रहा है?
अनिवार्य रूप से, unused RAM, wasted RAM है।
कई नए users देखते हैं कि Linux kernel memory को उनकी आदत से अलग तरीके से handle करता है। चूंकि storage drive से डेटा access करने की तुलना में RAM से डेटा access करना बहुत तेज है, kernel memory में हाल ही में accessed डेटा को cache करता है। Cached डेटा केवल तब cleared होता है जब system available memory से बाहर होने लगता है और नए डेटा को load करने की आवश्यकता होती है।
हम free command से अंतर को distinguish कर सकते हैं:
$ free -h
total used free shared buff/cache available Mem: 377Gi 40Gi 146Gi 1.1Gi 196Gi 337Gi Swap: 377Gi 1.1Gi 376Gi
"free" और "available" memory के बीच अंतर को नोट करना महत्वपूर्ण है। उपरोक्त example में, 377 GiB total RAM वाला एक system इसके आधे से अधिक का उपयोग कर रहा प्रतीत होता है, केवल 146 GiB free memory के साथ। हालांकि, इसका 196 GiB "buff/cache" है। नए applications शुरू करने के लिए अभी भी 337 GiB उपलब्ध है, बिना swapping के। विवरण के लिए free(1) देखें। इस सब का परिणाम? Performance!
यदि आपकी जिज्ञासा बढ़ गई है तो इस अद्भुत लेख को देखें। इस confusion को clear करने के लिए समर्पित एक website भी है: https://www.linuxatemyram.com/।
मेरी सारी free space कहाँ गई?
इस प्रश्न का उत्तर आपके system पर निर्भर करता है। कुछ बढ़िया utilities हैं जो आपको उत्तर खोजने में मदद कर सकती हैं।
मैं log in करने में असमर्थ क्यों हूं?
क्या आपने अपना password गलत टाइप किया है या पंद्रह मिनट में तीन बार sudo command को cancel किया है? यदि ऐसा है, तो आपने brute-force attacks के खिलाफ एक prevention mechanism को trigger किया है: अधिक विवरण के लिए Security#Lock out user after three failed login attempts देखें।
क्या Arch "phone home" करता है?
संक्षेप में? नहीं।
अधिक विवरण में:
- NetworkManager के users को पता होना चाहिए कि यह automatic connectivity checks करता है। Default connectivity URL Arch द्वारा प्रदान किया जाता है और किसी भी access को log न करने के लिए प्रतिबद्ध है।
- Network Time Protocol clients अपने default configuration में NTP Pool Project द्वारा प्रदान किए गए NTP servers के vendor pool का उपयोग करते हैं (इसके rules के अनुसार)।
- जैसा कि pacman/Package signing#Upgrade system regularly में note द्वारा समझाया गया है, एक systemd timer हफ्ते में एक बार पहले से trusted keys के नए signatures को update करने के लिए चलता है। वहां भी किसी access की कोई logging नहीं है।
- Mirror list updating tool Reflector archlinux.org से mirror list download करता है। Live installation environment के लिए, यह default रूप से enabled है, और network connection स्थापित होते ही यह चलता है।
आप pkgstats project में योगदान करके स्वेच्छा से "phone home" करना चाह सकते हैं जो Arch developers को उनके प्रयासों को प्राथमिकता देने में मदद करने के लिए package popularity का anonymous डेटा एकत्र करता है।
Package management
अधिक उत्तरों के लिए pacman, pacman/Tips and tricks और Official repositories pages देखें।
मैंने package X के साथ एक error पाई है। मुझे क्या करना चाहिए?
सबसे पहले, आपको यह पता लगाने की आवश्यकता है कि क्या यह error कुछ ऐसा है जिसे Arch team ठीक कर सकती है। अक्सर ऐसा नहीं होता (उदाहरण के लिए Firefox crashes Mozilla team की गलती हो सकती है); इसे upstream error कहा जाता है, Bug reporting guidelines#Upstream or Arch? देखें। यदि यह Arch problem है, तो कुछ steps हैं जो आप ले सकते हैं:
- जानकारी के लिए forums को खोजें। देखें कि क्या किसी और ने इसे notice किया है।
- GitLab में Arch Linux bug tracker पर विस्तृत जानकारी के साथ bug report post करें।
- यदि आप चाहें, तो समस्या और तथ्य का विवरण देते हुए एक forum post लिखें कि आपने इसे पहले ही report कर दिया है। यह बहुत से लोगों को एक ही error की report करने से रोकने में मदद करेगा।
Arch packages को एक unique naming convention का उपयोग करने की आवश्यकता है। ".pkg.tar.zst" बहुत लंबा और/या confusing है
इस पर Arch mailing list पर चर्चा की गई है। कुछ ने .pac file extension का प्रस्ताव दिया, लेकिन package extension को बदलने की कोई योजना नहीं है। जैसा कि Tobias Kieslich, Arch developers में से एक ने कहा, "एक package है एक [compressed] tarball! और इसे किसी भी tar-capable application द्वारा खोला, investigate और manipulate किया जा सकता है। इसके अलावा, mime-type को अधिकांश applications द्वारा स्वचालित रूप से सही ढंग से detect किया जाता है।"
Pacman को एक library की आवश्यकता है ताकि अन्य applications आसानी से package information access कर सकें
Pacman libalpm(3) का एक front-end है—"Arch Linux Package Management" library—जो alternative front-ends, जैसे कि एक GUI front-end, को लिखने की अनुमति देती है।
Pacman को feature X की आवश्यकता है!
यदि आपको लगता है कि एक idea में merit है, तो आप pacman-dev पर इस पर चर्चा करने का चयन कर सकते हैं। मौजूदा feature requests के लिए https://gitlab.archlinux.org/pacman/pacman/-/issues भी check करें।
हालांकि, pacman या Arch Linux में एक feature जोड़ने का सबसे अच्छा तरीका है इसे स्वयं implement करना। Patch या code को आधिकारिक रूप से स्वीकार किया जा सकता है या नहीं भी हो सकता है, लेकिन शायद अन्य लोग आपके प्रयास की सराहना करेंगे, test करेंगे और योगदान देंगे।
मैंने अभी Package X install किया। मैं इसे कैसे शुरू करूं?
यदि आप KDE या GNOME जैसे desktop environment का उपयोग कर रहे हैं, तो program स्वचालित रूप से आपके menu में दिखाई देना चाहिए यदि यह desktop entry के साथ आता है। यदि आप terminal से program चलाने की कोशिश कर रहे हैं और binary name नहीं जानते हैं, तो उपयोग करें:
$ pacman -Qlq package_name | grep /usr/bin/
Official repositories में प्रत्येक shared library का केवल एक ही version क्यों है?
कई distributions, जैसे Debian, के पास different packages के रूप में packaged shared libraries के विभिन्न versions हैं: libfoo1, libfoo2, libfoo3 और इसी तरह। इस तरह से libfoo के विभिन्न versions के खिलाफ compiled applications को एक ही system पर installed होना संभव है।
Arch जैसे distribution के मामले में, केवल नवीनतम packaged versions को आधिकारिक रूप से support किया जाता है। Outdated software के लिए support छोड़कर, package maintainers यह सुनिश्चित करने में अधिक समय बिता सकते हैं कि नवीनतम versions अपेक्षा के अनुसार काम करें। जैसे ही upstream से एक shared library का एक नया version उपलब्ध होता है, इसे repositories में जोड़ दिया जाता है और प्रभावित packages को नए version का उपयोग करने के लिए rebuild किया जाता है।
क्या होगा यदि मैं एक full system upgrade चलाता हूं और एक shared library के लिए update होगा, लेकिन उस पर निर्भर applications के लिए नहीं?
यह परिदृश्य बिल्कुल नहीं होना चाहिए। यह मानते हुए कि foobaz नामक एक application official repositories में से एक में है और libbaz नामक shared library के एक नए version के खिलाफ सफलतापूर्वक builds होता है, इसे libbaz के साथ update किया जाएगा। यदि, हालांकि, यह सफलतापूर्वक build नहीं होता है, तो foobaz package में एक versioned dependency होगी (उदाहरण के लिए libbaz 1.5), और libbaz upgrade के दौरान conflict के कारण pacman द्वारा remove कर दिया जाएगा।
यदि foobaz एक ऐसा package है जिसे आपने स्वयं build किया और AUR से install किया है, तो आपको libbaz के नए version के खिलाफ foobaz को rebuild करना चाहिए। यदि build विफल होता है, तो foobaz developers को bug की report करें।
क्या यह संभव है कि repository में एक major kernel update हो, और कुछ driver packages update न हुए हों?
नहीं, यह संभव नहीं है। Major kernel updates (उदाहरण के लिए linux 3.5.0-1 से linux 3.6.0-1) हमेशा सभी supported kernel driver packages के rebuilds के साथ होते हैं। दूसरी ओर, यदि आपके system पर एक unsupported driver package (उदाहरण के लिए AUR से) installed है, तो kernel update आपके लिए चीजों को तोड़ सकता है यदि आप इसे नए kernel के लिए rebuild नहीं करते हैं। Users किसी भी unsupported driver packages को update करने के लिए जिम्मेदार हैं जो उन्होंने install किए हैं।
Upgrade करने से पहले क्या करना है?
System maintenance#Upgrading the system section का पालन करें।
एक package update release किया गया था, लेकिन pacman कहता है कि system up to date है
pacman mirrors तुरंत sync नहीं होते। एक update आपके लिए उपलब्ध होने से पहले 24 घंटे से अधिक का समय लग सकता है। केवल विकल्प धैर्य रखना या किसी अन्य mirror का उपयोग करना है। MirrorStatus आपको एक up-to-date mirror की पहचान करने में मदद कर सकता है।
Upstream project X ने एक नया version release किया है। Arch package को उस नए version में update होने में कितना समय लगेगा?
Package updates तब release किए जाएंगे जब वे तैयार होंगे। विशिष्ट समय upstream द्वारा minor bugfix update release करने के कुछ घंटों बाद से लेकर एक बड़े package group के major update के कई सप्ताह बाद तक हो सकता है। Upstream के नए version से लेकर Arch द्वारा नया package release करने तक का समय specific packages और package maintainers की availability पर निर्भर करता है। इसके अतिरिक्त, कुछ packages testing repository में कुछ समय बिताते हैं, इसलिए यह एक package के update होने से पहले समय को बढ़ा सकता है। Package maintainers repositories में stable updates लाने के लिए जल्दी काम करने का प्रयास करते हैं। यदि आपको official repositories में एक package मिलता है जो out of date है, तो package website पर उस package के page पर जाएं और इसे flag करें।
यदि मुझे एक installed library के पुराने version की आवश्यकता है, तो क्या मैं नए version में सिर्फ symlink कर सकता हूँ?
यदि आप भाग्यशाली हैं, तो यह कुछ समय के लिए काम कर सकता है। इसके बावजूद, यह एक उचित solution नहीं है, क्योंकि:
- Libraries randomly versions नहीं बदलती हैं – API/ABI संभवतः बदल गई होगी (संभवतः bits हटाए गए), और क्या वे changes उपयोग को प्रभावित करते हैं यह सिर्फ luck की बात है।
- Symlink एक package manager द्वारा untracked होगा। Beginners जो तुरंत system library files पर hack करने की कोशिश करते हैं, वे एक अवांछित change करने के सबसे बड़े risk में हैं जिसे वे diagnose/fix नहीं कर सकते, जिससे एक package manager guard करने में मदद करता है।
- Filesystem में untracked, पुरानी library file को dump करने का एक मामूली alternative इसके बारे में भुला दिया जाएगा, और संभावित security bugs को notice/patch नहीं किया जाएगा।
इसके बजाय, उदाहरण के लिए एक compat (compatibility) package का उपयोग/लेखन करें, जो आवश्यक library version प्रदान करता है।
64-bit
मैं कैसे निर्धारित करूं कि मेरा processor x86_64 compatible है?
यदि आपका processor x86_64 compatible है, तो आपके पास /proc/cpuinfo में lm (long mode) flag होगा। उदाहरण के लिए,
$ grep -w lm /proc/cpuinfo
Windows के तहत, freeware CPU-Z का उपयोग यह निर्धारित करने में मदद करता है कि आपका CPU 64-bit compatible है या नहीं। AMD के instruction set "AMD64" या Intel के solution "EM64T" वाले CPUs x86_64 releases और binary packages के साथ compatible होने चाहिए।
64-bit क्यों?
यह अधिकांश परिस्थितियों में तेज है और एक added bonus के रूप में Address space layout randomization (ASLR) की प्रकृति के कारण Position-independent code (PIC) और NX Bit के साथ संयोजन में स्वाभाविक रूप से अधिक secure है, जो stock i686 kernel में disabled Physical Address Extension (PAE) के कारण उपलब्ध नहीं है। यदि आपके computer में 4 GiB से अधिक RAM है, तो केवल एक 64-bit OS इसका पूरी तरह से उपयोग करने में सक्षम होगा।
Programmers भी तेजी से 32-bit ("legacy") की परवाह कम करते हैं क्योंकि "new" x86 CPUs आमतौर पर 64-bit extensions को support करते हैं।
यहां बहुत सारे और कारण हैं जो हम आपको 32-bit से बचने के लिए कह सकते हैं, लेकिन kernel, userspace और individual programs के बीच यह बस viable नहीं है कि हर उस चीज को list किया जाए जो 64-bit आजकल बहुत बेहतर करता है।