- साधारण फीचर्स के लिए भी हजारों dependencies और करोड़ों लाइनों का code लगने की हकीकत में, software का फूलना-फैलना खुद security vulnerabilities का बड़ा कारण बन गया है
- Security सिर्फ bug density पर नहीं, बल्कि attacker की पहुंच में आने वाले code की कुल मात्रा पर निर्भर करती है; बेवजह बड़ा attack surface वास्तविक breaches तक ले जा सकता है
- Electron JS, Node.js, Docker images, npm·PyPI dependency ecosystems deployed code की मात्रा और स्रोत को धुंधला कर देते हैं, और garage door खोलने वाले app में भी 5 करोड़ से अधिक lines of active code शामिल हो सकती हैं
- Rust, sanitizer, fuzzer code quality बढ़ाते हैं, लेकिन document के अंदर code को automatically execute करने जैसी logical design failure को सिर्फ bugs हटाकर रोकना मुश्किल है
- Trifecta 1,600 lines of new code, करीब 5 core dependencies और कुल 3MB size में image sharing feature देता है, दिखाता है कि सीमित code और dependencies से भी modern software बनाया जा सकता है
Software security की खतरनाक स्थिति
- हाल में software security की स्थिति बहुत खराब है
- Ivanti, MOVEit, Outlook, Confluence, Barracuda Email Security Gateway, Citrix NetScaler ADC·NetScaler Gateway जैसे industry-standard software में पिछले एक साल में गंभीर breaches हुए
- Apple और Google जैसी बहुत resources वाली companies भी customers को जोखिम में डालने वाली security mistakes करती हैं
- Software बहुत जोखिम भरा हो गया है, इस धारणा के कारण उसे खुद run न करके X as a service या cloud को सौंपने की सलाह आम हो गई है
- यह धारणा भी डगमगा रही है कि cloud vulnerable software को भरोसेमंद बना देता है
- Microsoft email platform, confidential government emails सहित, hack हो गया
- Azure cloud security को लेकर चिंताएं बनी हुई हैं
- Okta ने 2 साल के अंदर दूसरा breach झेला, और उसके बाद Okta users के hacking cases संदिग्ध रूप से जारी रहे
- EU software security से निपटने के लिए तीन तरह के legislation आगे बढ़ा रहा है
- NIS2: important services के लिए
- Cyber Resilience Act: लगभग सभी commercial software और electronic devices के लिए
- Product Liability Directive: liability का दायरा software तक बढ़ाता है
Vulnerabilities code quality और code की मात्रा, दोनों से आती हैं
- Software security दो axes पर निर्भर करती है
- source code में security issues की density
- hackers की पहुंच में आने वाले code की मात्रा
- Code जितना बढ़ता है, risk भी उतना बढ़ता है
- bug density कम हो तब भी millions of lines of code में exploitable holes मिल सकते हैं
- iMessage का example दिखाता है कि attack surface बढ़ने से कैसी problems बनती हैं
- अनचाहे iMessage भी iPhone पर तुरंत process होकर preview बनाते हैं
- Apple ने कई तरह के image formats support किए, और अजीब compressed fonts वाली PDF भी processing scope में आ गई
- उस पुराने format में दरअसल programming language शामिल थी, और attackers इसके जरिए phone की दूसरी weaknesses खोज सकते थे
- Apple preview को बहुत कम image formats या एक single “known good” format तक सीमित करके attack surface घटा सकता था
- EU Cyber Resilience Act भी साफ कहता है कि suppliers को attack surface minimize करना चाहिए
सिर्फ बेहतर code काफी नहीं है
- Code quality बढ़ाने की कोशिशें पहले से हैं
- Rust जैसी memory-safe languages
- AddressSanitizer जैसे security hardening tools
- input को automatically mutate करके vulnerabilities और bugs खोजने वाले fuzzers
- लेकिन कई security issues code के bugs से ज्यादा उसके नीचे की logic से पैदा होते हैं
- Barracuda email vulnerability की वजह यह थी कि virus scanning के लिए Excel spreadsheets scan करने वाली third-party library ने वास्तव में code execute कर दिया
- Documents के अंदर code को automatically execute करने की capability जोड़ने का फैसला, code के सारे bugs हटाने पर भी हल नहीं होता
हमें पता ही नहीं कि हम क्या deploy कर रहे हैं
- Modern software इतना बड़ा हो गया है कि वास्तव में क्या deploy हो रहा है, यह जानना मुश्किल है
- Niklaus Wirth ने 1995 में “A Plea for Lean Software” में software के megabyte scale तक बढ़ने की आलोचना की थी
- उनका Oberon operating system editor और compiler सहित 200KB का था
- आज कुछ projects में सिर्फ config files ही 200KB से अधिक हो जाती हैं
- आज का typical app Electron JS आधारित हो सकता है
- Electron JS में Chromium और Node.js शामिल होते हैं
- Node.js tens of thousands JavaScript packages तक access देता है
- अनुमान है कि सिर्फ Electron JS इस्तेमाल करने से ही dependencies सहित कम से कम 5 करोड़ lines of code आ सकती हैं
- Apps सैकड़ों से हजारों helper packages लाते हैं, और dependencies फिर अपनी dependencies खींच लाती हैं
- build में ठीक-ठीक क्या शामिल है, यह रोज बदल सकता है
- कुछ packages by default users को advertisers या data brokers के सामने expose कर सकते हैं
- घर के devices control करने वाला app Amazon-side software stack से भी जुड़ सकता है, और वह stack भी Node.js और कई dependencies इस्तेमाल कर सकता है
- नतीजतन garage door खोलने के लिए भी कई operating system images और कई servers पर 5 करोड़ से अधिक lines of active code चल सकती हैं
Containers और dependency supply chain का बोझ
- पहले compiler outputs या interpreted files के bundles deploy किए जाते थे, और installation व configuration के दौरान package में क्या है, इस पर सोचना पड़ता था
- आजकल containers के जरिए software के साथ-साथ runtime environment मिलाने के लिए operating system files भी साथ deploy किए जाते हैं
- अक्सर स्थिति लगभग पूरे computer disk image को deploy करने जैसी हो जाती है
- Docker Hub पर 350MB से बड़े बहुत images हैं
- Containers अच्छे कामों में इस्तेमाल हो सकते हैं, लेकिन actual usage के तरीके के आधार पर deployed code की मात्रा बहुत बढ़ा सकते हैं
- Dependencies के security updates final app तक पहुंचते हैं या नहीं, यह भी अनिश्चित है
- Google और Apple ने जिन image processing bugs के लिए updates जल्दी roll out किए थे, वे Electron apps में अब भी बचे हैं या नहीं, जानना मुश्किल है
- npm ecosystem में package repository takeover, hijacking, same-name package revival जैसी history है
- PyPI भी मिलती-जुलती problems झेलता है
- Dependencies की review जरूरी है, लेकिन हजारों dependencies को बार-बार check करने की उम्मीद करना मुश्किल है
- सब कुछ खुद से दोबारा implement करना भी जवाब नहीं है; SQLite जैसे अच्छे modules हैं जो खुद लिखे code से अधिक safe हो सकते हैं
Trifecta: छोटे code से बना image sharing tool
- Trifecta minimalist होने के साथ-साथ वास्तव में इस्तेमाल लायक standalone image sharing software है
- Browser में images drag-and-drop करके आसानी से share की जा सकती हैं
- imgur इस्तेमाल करने पर browser में कई cookies और trackers install होते हैं, और shared images देखने वालों पर भी trackers थोपे जा सकते हैं
- Self-hosted image sharing tools भी अक्सर बड़े frameworks पर आधारित होते हैं, इसलिए उन्हें भरोसेमंद मानना मुश्किल लगा
- Trifecta को छोटा बनाया गया ताकि पूरा code कुछ घंटों में review किया जा सके
- नया source code 1,600 lines
- लगभग 5 important dependencies
- कुल code size 3MB
- तुलना में दिए गए दूसरे image sharing solution को 288MB Docker image के रूप में deploy किया जाता है
- एक और Node-based photo sharing solution में 1,600 dependencies और 40 लाख से अधिक lines of JavaScript पाई गईं
- Trifecta random लोगों द्वारा images upload करने वाली public site नहीं, बल्कि company या personal use के लिए उपयुक्त है
Complexity को ताकत समझने की समस्या
- Trifecta पर आम reactions में से एक था कि इसे Amazon Web Services bundle का उपयोग करके deploy किया जाए
- यह external services पर निर्भर न रहने वाले standalone software के लक्ष्य से मेल नहीं खाता
- Docker के साथ unfair treatment की प्रतिक्रिया भी थी, लेकिन माना गया कि containers अच्छे उद्देश्य के लिए इस्तेमाल किए जा सकते हैं
- Niklaus Wirth ने 1995 के paper में बताया था कि लोग complexity को sophistication समझने की tendency रखते हैं
- Tony Hoare के शब्दों में software design के दो तरीके हैं
- program को इतना simple बनाना कि कोई errors न होना स्पष्ट हो
- उसे इतना complex बनाना कि कोई obvious errors न दिखें
- Wirth ने time pressure को bloated software का मुख्य कारण माना
- time pressure careful planning में बाधा डालता है
- acceptable solution को improve करने के बजाय तेजी से additions और fixes करवाता है
- engineers के quality standards और completeness को धीरे-धीरे नुकसान पहुंचाता है
- Software explosion कोई natural law नहीं है; यह ऐसी चीज है जिसे software engineers को घटाना चाहिए
Code की मात्रा घटाना security measure बनता है
- मौजूदा दुनिया बहुत ज्यादा code deploy कर रही है
- अधिकतर third-party code है
- कुछ अनजाने में शामिल हो जाता है
- अधिकतर की पर्याप्त जांच नहीं होती
- इसके परिणामस्वरूप विशाल attack surface बनता है, जिसमें ordinary-quality code बड़ी मात्रा में exposed रहता है
- Code quality improvement की कोशिशें जारी हैं, लेकिन कई exploits logic failures से आते हैं, और उन्हें detect करने में progress अपेक्षाकृत कम है
- दुनिया के सामने expose किए जाने वाले code की मात्रा घटाने मात्र से भी बड़ा सुधार संभव है
- Product launch time बढ़ सकता है, लेकिन आने वाला legislation suppliers को security को ज्यादा गंभीरता से लेने पर मजबूर कर सकता है
- Trifecta और Oberon दिखाते हैं कि सीमित code और dependencies से भी बहुत functionality दी जा सकती है
1 टिप्पणियां
Hacker News की टिप्पणियाँ
Vernor Vinge की 『A Deepness in the Sky』 में मानवता सिर्फ sub-light तकनीक के सहारे तारों के बीच फैल चुकी है, और interstellar जहाज़ों में कई star systems और सभ्यताओं की पुरानी तकनीकों का मिला-जुला ढेर दिखता है
कंप्यूटर सिस्टम भी इतने लंबे समय तक evolve हो चुके हैं कि ज़्यादातर code अब कोई समझता ही नहीं; लोग बस उसे इस्तेमाल करते हैं और उसके ऊपर फिर से नई परतें चढ़ा देते हैं
खास तौर पर एक किरदार, जो लंबे समय तक suspended state और यात्रा को बार-बार दोहराने की वजह से जीवित इंसानों में सबसे पुराने लोगों में से एक पुराना systems engineer है, ऐसे भविष्य में जहाँ सबने उन सिस्टमों के ऊपर कई layers बना दी हैं, उसके अपने दौर की working और vulnerabilities की जानकारी उलटे एक बड़ा फायदा बन जाती है
मुझे लगता है Vinge ने किसी बात को बिल्कुल सही पकड़ा था
पहला आधुनिक विज्ञान और बेहद होशियार लोगों के हल करने लायक असली mystery है, लेकिन दूसरा ज़्यादा रुचि की कमी जैसा है
अगर आप पर्याप्त पैसे दें, तो कोई सक्षम engineer washing machine खोलकर सटीक खराबी ढूंढ निकालेगा, लेकिन कोई वह खर्च नहीं देगा और बस उसे फेंककर नई खरीद लेगा
पुराने software का ज्ञान साफ़ तौर पर दूसरे वर्ग में आता है। किसी भी हिस्से में गहराई से जाएँ तो आखिरकार उसे पूरी तरह समझा जा सकता है, लेकिन ज़्यादातर मामलों में उसे अनदेखा करना या उसके ऊपर एक और layer जोड़ देना कहीं ज्यादा सस्ता और practical होता है
कहानी यह है कि भविष्य की मानवता basic arithmetic भूल चुकी है, और जब कोई उसे फिर से खोजता है तो सत्ता में बैठे लोग उसे युद्ध में इस्तेमाल करना चाहते हैं। संदेश क्या देना है, समझ आता है, लेकिन मुझे लगता है setting इतनी अवास्तविक रूप से हास्यास्पद है कि असर खो देती है
और चर्चा के लिए http://lambda-the-ultimate.org/node/4424 देखें
हम पहले से ही ऐसी समस्या झेल रहे हैं। मेरे 60s में चल रहे अंकल COBOL में बने पुराने trucking software को maintain करते हैं, और ऐसी legacy technology jobs भी हैं। रुचि हो तो परिचय करा सकता हूँ
मूल समस्या left-pad वाली घटना जैसी ही है। हम बिना supervision वाले junior engineer का dependencies को लापरवाही से install करने पर मज़ाक उड़ाते हैं, लेकिन दशकों और developers की कई पीढ़ियों के बाद आखिरकार ज़्यादातर software किसी न किसी हद तक अनजानी dependencies पर निर्भर हो जाता है
मान लें कि 2100 में update deploy करना है, तो उसे उस समय के npm dependency management system के जरिए push किया जाएगा। साथ ही security updates की जरूरत वाले dependent devices पूरे solar system के पैमाने पर होंगे, और खरबों devices व बीच के caches हो सकते हैं जिनके up-to-date होने का पता नहीं होगा। ऐसी dependency tree कैसी दिखेगी, इसकी कल्पना भी नहीं कर सकता
ऐसे माहौल में काम करना भी झुंझलाहट भरा है जहाँ core तक पहुँचने के लिए framework code खोदना पड़ता है। लगता है समय बर्बाद हो रहा है
ब्लोट ज़्यादातर npm libraries में दिखता है। लेखक अच्छे design को नहीं जानते, और हर library से हर काम करवाना चाहते हैं
यह कुछ ऐसा है जैसे string encoding conversion library कहकर उसी repository में file load, save, internet download और command-line tool तक डाल देना। Library को सिर्फ अपना एक काम करना चाहिए और बाकी user पर छोड़ना चाहिए
Rust side भी बेहतर नहीं दिखती। अगर आप Rust documentation को ठीक करने की कोशिश करें, तो देखेंगे कि करीब 1000 crates install हो जाते हैं
समस्या language में नहीं है, बल्कि इसमें है कि कोई भी library upload कर सकता है, और वाकई कोई भी कर देता है। जो लोग “बस काम खत्म करना चाहते हैं” वे सबसे ज़्यादा features वाली library चुनते हैं, और library के बाहर 3 lines में हो जाने वाला code लिखना नहीं चाहते, इसलिए और features मांगते हैं। जैसे, “क्या PDF rendering भी जोड़ सकते हैं?”
समाधान मुझे ठीक से नहीं पता, लेकिन मैंने सोचा है कि Low Dependency समर्थक group और badge बनाए जाएँ, ताकि library authors वह badge चाहें और users भी library चुनते समय उसे खोजें
उल्टा, अगर आप कम dependencies वाली library चाहते हैं, तो आप कुछ ऐसी libraries लाएँगे जो बहुत सारे काम करती हैं
मेरे नज़रिए से, किसी भरोसेमंद author की बनाई कम dependencies वाली थोड़ी मोटी library बेहतर है। Lodash बड़ा है, लेकिन ES6 module version tree shaking support करता है, और असल में JavaScript में जो standard library नहीं थी, उसकी भूमिका निभाता है। Date के लिए date-fns भी कुछ ऐसा ही है। JavaScript core libraries की कमियाँ भरने के लिए मैं लगभग हर project में इन दोनों को default रूप से जोड़ता हूँ
पहले मैंने Ruby on Rails contract work किया था, और performance problems इतनी गंभीर थीं कि हम release mode में develop कर रहे थे। Server file changes detect करके auto-reload भी नहीं कर पा रहा था
एक दिन थककर मैंने अंदर तक जांच शुरू की, और इतने gems खिंच रहे थे कि मुझे संख्या भी याद नहीं। उनमें से एक सचमुच 3 lines code बचाने के लिए gem था
उसके बाद से मैंने RoR community से दूरी बना ली। हाल में कई साल बाद फिर RoR contract लिया, और यह पहले जितना खराब तो नहीं, लेकिन अब भी अच्छा नहीं है
कुछ communities dependencies से आने वाले risks की बिल्कुल कद्र नहीं करतीं
वहीं, यह बात बेहद सुविधाजनक है कि कोई भी Git repository Go library host कर सकती है, और कोई भी उस URL से उसे use कर सकता है
पहले तो package creators इसे career बनाना चाहते हैं, और attention पाने का तरीका सिर्फ ढेर सारे packages बनाना है। इसलिए वे ऐसे packages बनाते रहते हैं जो उनके ही बनाए दूसरे packages पर depend करते हैं, और अपने एक-दो उपयोगी packages को दूसरे लोगों के code में घुसाना चाहते हैं
दूसरा, वे लोग हैं जो मानते हैं कि problem solving का मतलब हमेशा नया package शामिल करना है। उन्हें इस बात से फर्क नहीं पड़ता कि dependencies कितनी हैं या actual problem कठिन है या नहीं। इसलिए problem solve करना सीखने के बजाय वे GitHub पर 4 stars वाले wrapper की API सीखते हैं
आदर्श रूप में ऐसा tool उबाऊ समय लगाकर unnecessary packages prune करे, हर package की responsibility न्यूनतम करे, environment को समझदारी से व्यवस्थित करे, फिर independently cache करे ताकि LLM dependency हट जाए। बेहतर होगा कि update checker या curator को सिर्फ तब बुलाया जाए जब कोई समस्या हो
ईमानदारी से कहूँ तो यह modern software की सबसे खराब समस्याओं में से एक है, और मुझे लगता है कि यह 50% से ज़्यादा projects को बेकार बना देती है। यह उबाऊ लेकिन हल की जा सकने वाली समस्या है, इसलिए सही LLM agent के लिए बिल्कुल उपयुक्त है, और ऐसा हो तो बहुत मदद मिलेगी
“क्या आपने modern airplane देखा है? क्या आपने यह follow किया है कि उसकी lines हर साल कैसे evolve होती हैं? क्या आपने कभी सोचा है कि सिर्फ airplane ही नहीं, बल्कि humans द्वारा बनाई हर चीज़ में, मानव के industrial प्रयास, calculations और drawings पर बिताई रातें आखिरकार एकमात्र और dominant principle, यानी ultimate simplicity, तक पहुँचती हैं?
मानो कोई प्राकृतिक नियम हो, जो आदेश देता हो कि furniture की curves, ship की keel, या airplane fuselage को इंसान के सीने या कंधों की curves जैसी मौलिक purity के करीब लाने के लिए कारीगरों की कई पीढ़ियों के experiments जरूरी हैं। लगता है perfection तब नहीं मिलती जब जोड़ने के लिए कुछ और न बचे, बल्कि तब मिलती है जब हटाने के लिए कुछ और न बचे।”
— Antoine de Saint Exupéry, Terre des Hommes
“Garage door खोलने के लिए 5 करोड़ से ज़्यादा active code lines और कई servers के operating system images की जरूरत पड़ सकती है” — इस तरह लिखकर देखें तो यह सचमुच पागलपन लगता है
जिस machine पर मैं अभी यह लिख रहा हूँ, उस पर कितना code चल रहा है, यह सोचकर चक्कर आ जाता है। ऐसा code जिसे मैंने कभी review नहीं किया, और शायद जिसका strict review भी बहुत कम हुआ होगा
खैर, अब फिर npm dependencies install करने जा रहा हूँ
“सॉफ्टवेयर को अब इतना जोखिम भरा माना जाने लगा है कि लोगों से कहा जाता है कि इसे खुद न चलाएँ। इसके बजाय इसे ‘X as a service’ प्रदाता या बस ‘cloud’ के हवाले कर दें। इसकी तुलना एक काल्पनिक स्थिति से करें, जहाँ कारों में इतनी बार आग लगती है कि सलाह दी जाती है कि खुद ड्राइव न करें, बल्कि ड्राइविंग किसी ऐसे विशेषज्ञ को सौंप दें जिसके पीछे हमेशा professional firefighter लगा रहता हो”—यह उपमा ऐसी है कि इस्तेमाल करने का मन करता है
मेरी ex-girlfriend, जो पहले Eastern Bloc में पली-बढ़ी थी, इसलिए “cloud” पर अविश्वास करने के उसके तर्कसंगत कारण थे। लेकिन विकल्प यह था कि बस उम्मीद की जाए कि सबसे सस्ते में खरीदा HP laptop खो न जाए। थोड़ी शिक्षा देने के बाद कम से कम उस हिस्से में वह निश्चिंत हो गई
समस्या कुल मिलाकर शिक्षा की कमी और उसके परिणामों पर विचार की कमी है। आखिरकार या तो जोखिम स्वीकार करना पड़ता है, या खुद सीखना पड़ता है, या SaaS और cloud कंपनियों पर निर्भर होना पड़ता है। मैंने बहुत आँसू देखे हैं, और खुद सीखने के मामले बहुत कम देखे हैं
यह व्यक्तिगत ज़िम्मेदारी का सवाल है, लेकिन जब कोई वह ज़िम्मेदारी लेना नहीं चाहता, तो experts को सौंपना खुद पर भरोसा करने से कम खराब समाधान हो सकता है। सही जवाब शिक्षा है, लेकिन वह बेहद कठिन है
सॉफ्टवेयर और lean नहीं हो सकता। उसके लिए समय, कौशल और महंगे लोग चाहिए; सिर्फ ऐसे लोग नहीं जो 12 अलग-अलग tech stack examples जोड़कर Franken-shit बना दें
मैं independent developer हूँ, और जिसने पिछले साल node.js सीखा है वह node.js, containers, कोई भी AWS hosted DB service, Lambda, object storage, Cloudflare, YAML, React, Vite और दूसरी dependencies को एक दिन में जोड़कर घिसा-पिटा लेकिन फिर भी कमजोर webapp बना देता है—और वह हमेशा मुझसे कम कीमत बोलता है
lean, तेज़, कम running cost वाला और maintenance में भी सस्ता software लंबे समय में भले ही सस्ता पड़े, उसे profitably लिखना मुश्किल है
पहले एक सपना था कि system द्वारा दिए गए standard hooks और routines हों और हर कोई उन्हें interfaces आदि के लिए इस्तेमाल करे। Macintosh Toolbox या QuickDraw जैसी चीज़ों को सोचिए
कहा जाता था कि developer का मुख्य काम program logic लिखना है, और बदलाव या additions transparent होने चाहिए। System calls अंदरूनी code बदलने पर भी वही काम smoothly करें, और नए features पुराने features के superset हों, ताकि पुराना code बिना समस्या compile या run हो और नया software ज्यादा capabilities पा सके
माना जाता था कि इससे maintenance आसान होगा, interfaces standardized होंगे, और system calls पर ज्यादा निर्भरता होने से code भी lean होगा। External libraries से बचना चाहिए—ऐसा माहौल था
यह सपना जल्दी ही टूट गया; DLLs याद कर लीजिए। आज की बहुत-सी package management और packaging बस सही libraries मौजूद हैं, यह सुनिश्चित करने जैसा दिखता है
तब बड़े पैमाने का software development अभी लगभग शैशवावस्था में था, इसलिए यह उम्मीदों जैसा नहीं हुआ, यह समझ में आता है। अब इन समस्याओं पर सामूहिक अनुभव बहुत जमा हो चुका है; सोचता हूँ कि क्या निष्कर्ष यह निकला है कि यह सपना समझदारी से लागू ही नहीं हो सकता, या मौजूदा गंदगी को काफी झेल लेने के बाद हम किसी आधुनिक नए प्रयास की ओर बढ़ रहे हैं
अगर हमें तेज़, lean, stable और secure software चाहिए, तो चारों चीजें एक साथ पाना मुश्किल हो सकता है, लेकिन यह स्पष्ट नहीं कि मौजूदा हालात उस दिशा में जा रहे हैं या नहीं
शुरुआती Lisp ने language में बहुत कम चीजें रखी थीं, लेकिन Raku तो npm library में जाने लायक मामूली चीजों तक को language spec में धकेल देता है
C ने यह आप पर छोड़ा था कि code कैसे build करना है, लेकिन नई compiled languages में से ज्यादातर किसी न किसी रूप में build tool साथ देती हैं
इस landscape में काफी प्रभावी चीजें भी हैं, लेकिन वे Wirth के काम को चलाने वाले “तुम, machine, नया project” context के बाहर होती हैं। समस्या यह है कि इनके साथ database या browser engine जैसी विशाल dependencies की दहलीज आती है, और अगर आपको वे dependencies जिस तरह बनी हैं वह पसंद नहीं, तो अंत में आप दुखी ही होते हैं
Rust के बारे में मैं लगातार यही कहता हूँ
अगर पुरानी C++ vulnerabilities में 70% सचमुच memory-related हैं, तो प्रति code line vulnerabilities C++ से 70% कम हो सकती हैं
लेकिन अगर Rust में आप सैकड़ों packages खींच लाते हैं और code lines 10 गुना हो जाती हैं, तो कहानी बदल जाती है
100 हज़ार lines का 30%, 10 हज़ार lines के 100% से कुल मिलाकर ज्यादा है
QT जैसी चीज़ भी अगर Rust में लिखी गई होती, तो खुद सैकड़ों crates होती, लेकिन code की मात्रा और उठाया गया risk level ठीक वही रहता
लेकिन बड़ी समस्या vulnerabilities है। क्या बेहतर है: एक shared library के bug को ठीक करके सैकड़ों libraries ठीक करना, या सैकड़ों libraries को एक-एक करके ठीक करना?
यह तथ्य कि Rust कुछ विशाल dependencies की बजाय कई छोटी dependencies आसानी से खींचने देता है, अप्रासंगिक है। इसका मतलब ज्यादा code लिखना नहीं है
उदाहरण के लिए, क्या Rust के
regexcrate को dependency गिनते हैं? C++ में वही standard library में हैक्या Boost को C++ में एक dependency गिनते हैं? Rust होता तो वह करीब 30 अलग-अलग crates के बराबर होता
Rust programs में C++ की तुलना में remote code execution कितनी हुई होगी? लगता है C++ में remote code execution की frequency Rust से 70% से कहीं ज्यादा होगी
कहा जाता है कि आजकल ऐप्स आम तौर पर Electron JS से बनाए जाते हैं, लेकिन लगता है कि लोगों को यह बात पर्याप्त रूप से पता नहीं है कि हर platform के native web controls का उपयोग करके Electron को bundle किए बिना भी ऐप बनाया जा सकता है
ऐसा करने पर distributed app का आकार kilobytes में हो सकता है। यह approach, जब तक web view से communicate किया जा सके, किसी भी backend language या tech stack का उपयोग करने की आज़ादी देता है
आजकल काफी बड़े अनुपात के applications के लिए PWA संभव होना चाहिए, है न?
ठीक से नहीं जानता, लेकिन क्या Discord भी Electron app के बजाय PWA नहीं हो सकता?
सबसे बड़ा gap शायद SQLite के बराबर किसी मजबूत चीज़ और IndexedDB के बीच का अंतर होगा, फिर भी लगता है कि ज्यादातर apps को IndexedDB के B-tree model से higher-level query language की अनिवार्य ज़रूरत नहीं होती
suckless philosophy के लिए एक बार फिर जयकार। वाह
[0 ]https://suckless.org/