Rust से बना Servo वेब ब्राउज़र: उपयोग अनुभव
(spacebar.news)- दुनिया भर में Chromium-आधारित ब्राउज़र की हिस्सेदारी बढ़ने से वेब मानकों की विविधता और ओपन वेब के भविष्य को लेकर चिंता बढ़ रही है
- Rust में विकसित Servo इंजन मल्टी‑थ्रेडेड परफॉर्मेंस और मेमोरी सेफ्टी—इन दो मजबूत बिंदुओं के साथ वेब रेंडरिंग इंजन के क्षेत्र में एक नए विकल्प के रूप में सामने आ रहा है
- यह अभी शुरुआती चरण में होने के कारण अधिकांश वेबसाइटों पर रेंडरिंग बग मौजूद हैं, लेकिन कुछ डेमो पेज या Wikipedia जैसी साधारण साइटों पर यह सही तरीके से काम करता है
- Servo परियोजना की शुरुआत Mozilla ने की थी, लेकिन अब इसका प्रबंधन Linux Foundation Europe के पास है और इसमें तकनीकी स्वतंत्रता तथा समुदाय-केंद्रित निर्णय प्रक्रिया मौजूद है
- ब्राउज़र इंजन के एकीकरण की धारा में Gecko, Servo जैसे वैकल्पिक इंजनों का निरंतर विकास वेब इकोसिस्टम की विविधता को बनाए रखने के लिए महत्वपूर्ण संकेत देता है
वेब इंजन का एकाधिकार और उसका जोखिम
- 1990 के दशक से 2000 के शुरुआती दशक तक Internet Explorer का Trident, Opera का Presto, Netscape का Gecko, Konqueror का KHTML आदि कई अलग-अलग वेब ब्राउज़र इंजन मौजूद थे
- समय के साथ KHTML का WebKit में विलय या प्रतिस्थापन हुआ, जबकि Presto और Trident (साथ ही Tasman) को Blink (Chromium इंजन) ने बदल दिया
- आज के प्रमुख ब्राउज़र (Chrome, Edge, Opera आदि) लगभग सभी Chromium/Blink आधारित होने से ऐसा ट्रेंड बना कि इम्प्लीमेंटेशन ही धीरे-धीरे मानक जैसा हो रहा है
- सुरक्षा कमजोरियाँ, स्केलेबिलिटी सीमाएँ जैसी समस्याएँ और स्पष्ट हुईं, क्योंकि किसी एक इंजन पर निर्भर रहने पर पूरा वेब इकोसिस्टम साथ में प्रभावित होता है
Servo इंजन का आगमन
- Servo शुरू से ही Rust में नया बनाकर विकसित किया गया ब्राउज़र रेंडरिंग इंजन है
- Rust के फायदों—मल्टी‑थ्रेडिंग और मेमोरी सेफ्टी—का उपयोग करके यह प्रयास C/C++ आधारित पुराने इंजनों की संरचनात्मक कमज़ोरियों (जैसे मेमोरी बग) को घटाने की दिशा में है
- Servo का मुख्य लक्ष्य एम्बेडेड वेब रेंडरिंग इंजन होना है, यानी यह स्टैंडअलोन ब्राउज़र के अलावा Electron या Android WebView का विकल्प भी बन सकता है
- Linux Foundation Europe के तहत तकनीकी निर्णय बड़ी कंपनियों के बजाय तकनीकी कमेटी-केंद्रित तरीके से लिए जाते हैं
- लगभग दस साल बाद आया एक पूरी तरह नया वेब ब्राउज़र इंजन होने के कारण, Servo अपनी पूर्णता बढ़ाने के लिए मुख्यधारा इंजनों का अनुभव भी सम्मिलित कर रहा है
Servo का उपयोग अनुभव और वर्तमान स्थिति
- आधिकारिक साइट पर उपलब्ध Nightly build (Windows, macOS, Android, Linux के लिए) से Servo का उपयोग करके देखा जा सकता है
- बुकमार्क, एक्सटेंशन, डेटा सिंक जैसी मौलिक ब्राउज़र सुविधाएँ अभी उपलब्ध नहीं हैं
- अधिकांश वेबसाइटों पर रेंडरिंग बग दिखते हैं, और Google Search या कुछ साइटों पर लेआउट टूट जाता है या क्रैश हो जाता है
- Wikipedia, CNN Lite जैसी सादा संरचना वाली पेजें सामान्यतः ठीक से काम करती हैं
- Servo डेमो पेज पर ग्राफिक्स परफॉर्मेंस डेमो दिखाया जा सकता है, और Particle Physics जैसे बेंचमार्क में नए MacBook Pro (x86 emulation) पर 55–60 FPS के नतीजे मिले
- Acid3 टेस्ट में 83/100 अंक मिले, जो मुख्यधारा ब्राउज़र (लगभग 95) से कम हैं
- आगे के रोडमैप में Shadow DOM, CSS Grid जैसे महत्वपूर्ण वेब स्टैंडर्ड सपोर्ट को शामिल किया गया है, और वेब संगतता सुधार पर ध्यान केंद्रित है
Servo का इतिहास और प्रमुख मोड़
- Servo की शुरुआत 2012 में Mozilla से हुई और 2013 में Samsung ने विकास में हिस्सा लिया
- शुरुआती लक्ष्य स्थिरीकरण के बाद Gecko इंजन के प्रतिस्थापन पर विचार करना था, लेकिन व्यवहार में रणनीति बदलकर Gecko के प्रत्येक हिस्से को धीरे-धीरे Servo कोड से बदलने पर आ गई
- Firefox 57 (Quantum) अपडेट के जरिए CSS इंजन (Quantum CSS, Stylo) को Servo कोड से बदला गया और प्रदर्शन व मेमोरी दक्षता में स्पष्ट सुधार देखा गया
- 2020 के Mozilla के बड़े restructuring (Servo डेवलपर्स समेत) के बाद Servo को Linux Foundation के अधीन स्थानांतरित कर फंडिंग फिर से सुनिश्चित की गई; Igalia जैसी ओपन सोर्स कंपनियों के सहयोग से यह आज भी समुदाय-केंद्रित विकास जारी रखे हुए है
ब्राउज़र इकोसिस्टम का भविष्य और संभावनाएँ
- अमेरिका के Department of Justice द्वारा Google की एकाधिकार स्थिति (Chrome, Android) के खिलाफ मुकदमे में जीतने के बाद Chrome की संभावित बिक्री तथा अन्य ब्राउज़र कंपनियों के साथ सर्च डील पर प्रतिबंध जैसे कदमों पर चर्चा चल रही है
- Mozilla की Firefox में डिफ़ॉल्ट सर्च से होने वाली आय पर निर्भरता बहुत अधिक है (Gecko के विकास को जारी रखने के लिए अनिवार्य), इसलिए उसने इन कदमों का विरोध जताया
- अगर Mozilla Google से मिलने वाली आय खो देता है, तो खर्च कम करने के लिए Firefox का WebKit या Chromium/Blink पर शिफ्ट हो जाना संभव है
- ऐसी स्थिति में Gecko code के फोर्किंग और समुदाय-आधारित संचालन की संभावना या Gecko के क्रमिक पतन की संभावना जैसी कई संभावित दिशाएँ सामने आ सकती हैं
- Servo और Gecko जैसे वैकल्पिक इंजनों की मौजूदगी वेब प्लेटफॉर्म में विविधता और संतुलन बनाए रखने का एक महत्वपूर्ण तत्व बनकर फिर उभर रही है
निष्कर्ष और निहितार्थ
- मुख्यधारा ब्राउज़र इंजनों के एकीकरण के बीच भी, Servo जैसे नवोन्मेषी विकल्प का आना वेब इकोसYSTEM की विविधता और स्वास्थ्य बनाए रखने में महत्वपूर्ण भूमिका निभा सकता है
- अल्पकाल में इसे पूर्णतः दैनिक उपयोग के ब्राउज़र के रूप में तैयार करना कठिन है, लेकिन तकनीकी प्रयोग और विकास लगातार जारी हैं
- Servo के भविष्य के विकास और उद्योग पर इसके प्रभाव को लेकर काफी उत्सुकता है
4 टिप्पणियां
जो ठीक से चलता भी नहीं, उसे डाउनलोड करके इस्तेमाल करने को कह रहे हैं क्या? ऐसी घमंड भरी सोच आखिर आती कहाँ से है?
सुना है कि Rust, Servo डेवलप करने के लिए बनाई गई भाषा है.. उम्मीद है Servo अच्छा चलेगा।
Hurd प्रोजेक्ट बार-बार याद आ रहा है… शायद यह सिर्फ मेरा भ्रम होगा?
Hacker News राय
मौजूदा रोडमैप में Shadow DOM और CSS Grid को प्राथमिकता दी गई है। मैं CSS Grid सपोर्ट पर काम कर रहा हूँ, और जल्द ही "named grid lines and areas" का सपोर्ट जोड़ा जाएगा। उम्मीद है कि इससे और ज़्यादा वेबसाइट लेआउट सही तरह से काम करेंगे। यह मेरा अपना प्रोजेक्ट है, इसलिए मैं पक्षपाती हो सकता हूँ, लेकिन मुझे लगता है कि Servo जिस तरह CSS Grid को implement कर रहा है, वह काफ़ी शानदार है। इसका मुख्य implementation एक बाहरी लाइब्रेरी (Taffy, GitHub लिंक) में अलग किया गया है, और यह लाइब्रेरी Rust UI ecosystem में काफ़ी व्यापक रूप से इस्तेमाल होती है। उदाहरण के तौर पर Blitz(लिंक) web engine, Zed(लिंक) text editor, और Bevy(लिंक) game engine में यह Flexbox, Block layout आदि जैसी कई भूमिकाओं में इस्तेमाल हो रही है। Stylo, html5ever जैसी modular libraries बनाने के अपने अनुभव के आधार पर Servo web engine को स्वतंत्र modules और public APIs में बाँटने का रास्ता अपना रहा है। उम्मीद है कि इससे भविष्य में web engine development में प्रवेश की बाधा कम होगी और नए web engine developers को बहुत मदद मिलेगी
मैंने Blitz के बारे में पहली बार सुना है। यह काफ़ी दिलचस्प और महत्वाकांक्षी प्रोजेक्ट लगता है, लगभग एक सचमुच के 'छिपे हुए' web engine जैसा। Servo तो Rust के शुरुआती दिनों से ही काफ़ी मशहूर रहा है, लेकिन Blitz भी उतना ही प्रभावशाली लगता है
जानना चाहता हूँ कि web browser engine features को खुद implement करने का अनुभव HTML या CSS लिखने के तरीके को प्रभावित करता है या नहीं। और क्या आप अब भी हफ़्ते में तीन बार "css grid cheatsheet" खोजते हैं
चिंता है कि features को तोड़कर modular बनाने का यह तरीका कहीं उल्टा feature bloat या fragmentation की ओर न ले जाए। Google का मुकाबला करना है तो एक focused strategy ज़रूरी है, और यही बात परेशान करती है
मैं taffy का इस्तेमाल करके अपने छोटे Rust-आधारित e-ink calendar में layout बना रहा हूँ। इसलिए यह ख़बर मुझे बहुत मज़ेदार लग रही है
web engine को स्वतंत्र रूप से इस्तेमाल किए जा सकने वाले public API modules में बाँटने का विचार मुझे सचमुच बहुत पसंद है। पहले जब मैं WebRTC देख रहा था, तब सोचता था कि कोई साधारण-सा Skype clone बनाना या तो 50 lines का JavaScript हो या फिर एक हफ़्ते तक चलने वाला Chromium C++ build nightmare—आख़िर यह दो ही विकल्प क्यों हों? अब WebRTC Rust crate भी है, तो अच्छा है कि सिर्फ web apps ही इस तरह के निवेश का लाभ नहीं उठा रहे
लगता है Mozilla भी Xerox जैसी उन कंपनियों के hall of fame में पहुँच सकती है जिन्होंने "भविष्य की तकनीक बनाई और फिर लापरवाही में प्रतियोगियों को दे दी"। Rust और Servo के साथ उसने एक समय browser development में Google को पीछे छोड़ दिया था, लेकिन फिर उसे आगे न बढ़ाना सचमुच समझ से बाहर है
Mozilla, Xerox जैसी नहीं है। अगर कोई नई Xerox है, तो वह बल्कि Google है। Google भारी फंडिंग के साथ ऐसे R&D विभागों में निवेश करता है जिनके पास साफ़ business plan नहीं होता। इसका सबसे बड़ा उदाहरण transformer models हैं—असल में LLM जैसी चीज़ सबसे पहले Google ने ही बनाई थी, फिर भी आख़िरकार OpenAI उससे आगे निकल गया। Mozilla की सफलता हमेशा Netscape, Firefox जैसे web browsers पर केंद्रित रही है। Rust भी मूल रूप से browser के लिए बनाई गई भाषा है। इसका दूसरी जगह उपयोगी होना बस एक अच्छा side effect है
2006 से Google, Mozilla की मुख्य आय का स्रोत रहा है। Mozilla को बने रहना है तो Google को संतुष्ट रखना काफ़ी है। इसमें टकराव की संभावना है, लेकिन Mozilla के नज़रिए से यह काफ़ी अच्छा सौदा है
मुझे लगता है Mozilla अब ख़त्म है। उसने Google पर बहुत ज़्यादा निर्भरता बना ली, और अब शायद वह भी खोने वाला है। आगे का भविष्य Servo और Ladybird होंगे, और Ladybird जिस तरह बहुत कम लोगों की टीम के साथ तेज़ी से आगे बढ़ रहा है, वह सचमुच प्रभावशाली है
अगर Mozilla कभी Gecko को छोड़ देता है, तो वही समय होगा जब hard fork और Mozilla से exodus करना चाहिए। साफ़ कर दूँ कि Gecko को छोड़ने का मतलब Servo नहीं, बल्कि Chromium पर जाना होगा
लगता है लोगों से browser के लिए पैसे दिलवाना मुश्किल है। 10 यूरो की beer पर लोग आसानी से खर्च कर देते हैं, लेकिन मैंने अपने आसपास बहुत लोगों को WhatsApp की lifetime 0.99 euro license तक से बचने की कोशिश करते देखा है
अब भी समझ नहीं आता कि Mozilla ने Firefox के तकनीकी भविष्य को क्यों छोड़ दिया। लेकिन जब Mozilla को पैसे के प्रवाह के नज़रिए से देखते हैं, तो बहुत-सी बातें समझ में आने लगती हैं
Pocket service का बंद होना भी एक दुखद उदाहरण है। मैं कभी-कभी सोचता हूँ कि अगर April Fools के मज़ाक में Mozilla यह घोषणा करे कि वह Firefox बंद कर रही है और core business पर ध्यान देगी, तो कैसा लगेगा। यह एक कड़वा मज़ाक होगा कि लोकप्रिय products को सुंदर तरीके से बंद कर देना ही शायद उसका असली core business है
लोगों के जाने और communication style को देखकर लगता है कि उस समय Mozilla बेहद राजनीतिक कंपनी थी। Servo में communication बहुत सक्रिय था और Rust का माहौल भी अच्छा था, इसलिए शायद वही बात ऊपर बैठे लोगों को खटकती रही हो। Mozilla अब भी पुराने लोगों के प्रभाव में चल रही है, और मुझे लगता है कि इसका बड़ा कारण top management की ग़लतियाँ हैं
मुझे अब भी पूरा भरोसा है कि Servo, Chrome/Chromium के monopoly का एक वास्तविक विकल्प बन सकता है। समझ नहीं आता Mozilla ने इसे क्यों छोड़ा, और Linux Foundation भी इसे लगभग कोई समर्थन क्यों नहीं दे रहा
अगर Mozilla की strategy को लंबी अवधि में Google funding से स्वतंत्र होने के नज़रिए से देखें, तो उसमें तर्क दिखता है। 2022 में non-Google revenue 80 million dollars से बढ़कर 2023 में 150 million dollars हो गया। कुल assets भी हर साल 100 million dollars बढ़ते हुए 2023 में 1 billion dollars तक पहुँच गए। Google funding का अनुपात 2020 के 90% से घटकर 2023 में 75% हो गया। यानी पूरी तरह स्वतंत्र तो नहीं, लेकिन दिशा मौजूद है। लोग आम तौर पर जो कहते हैं, उसके विपरीत, सिर्फ funding flow को देखें तो निष्कर्ष अलग हो सकता है। लोग कहते हैं कि Servo को जारी रखना चाहिए था, लेकिन मुझे लगता है कि Quantum के बाद Firefox में Servo की भूमिका वास्तव में बहुत बड़ी नहीं रही
क्या यह सही है कि Mozilla की ज़्यादातर आय Firefox से आती है
Blink monopoly को चुनौती देने के लिए Ladybird(आधिकारिक वेबसाइट) भी है। आगे क्या होगा, यह तय नहीं, लेकिन मैं उत्साहित हूँ
मुझे Ladybird का उद्देश्य ठीक से समझ नहीं आता। इसमें पूर्व इंजीनियर भी हैं और donations भी जुटाए जा रहे हैं, इसलिए यह सिर्फ एक hobby project नहीं है। लेकिन features, security और performance के स्तर पर यह Blink, Webkit, Gecko से टक्कर ले सकेगा, इसकी कल्पना करना मुश्किल है। इतने बड़े पैमाने की टीम नहीं होने पर, अगर popular adoption न मिले तो सिर्फ engine बनाना बहुत असरदार नहीं होगा। यह बात Servo पर भी लागू होती है, लेकिन Servo के तकनीकी लक्ष्य ज़्यादा विश्वसनीय लगते हैं। Ladybird के मामले में ऐसी स्पष्ट जानकारी कम दिखती है
सिर्फ तकनीकी नज़रिए से देखें, तो मुझे Ladybird का आकर्षण समझ नहीं आता। यह मूल रूप से C++ में लिखा गया है, इसलिए Gecko और Blink से कोई स्पष्ट अंतर नहीं दिखता। Servo में security, parallelism जैसी स्पष्ट तकनीकी design differences हैं, और यही उसे आकर्षक बनाती हैं
मैं चाहता हूँ कि Ladybird सफल हो। अब इसे सीधे sponsor भी किया जा सकता है, इसलिए यह सार्थक लगता है। Mozilla के विपरीत, मुझे भरोसा है कि जमा हुआ donation पूरी तरह browser development में ही खर्च होगा
क्या Ladybird, Swift में migrate करने की कोशिश कर रहा है? अगर browser engine C++ में बन रहा हो तो मुझे वह ज़्यादा पसंद नहीं, लेकिन यह व्यावहारिक और results-focused लगता है। Rust होता तो उसे future-oriented कहकर सराहता। लेकिन Swift जैसी दूसरी भाषा में engine बनाना मुझे किसी कंपनी के अंदरूनी राजनीतिक फ़ैसले जैसा लगता है। ऐसे ecosystem support की कमी वाली भाषा को जानबूझकर चुनने पर सवाल उठता है (संदर्भ ट्वीट)
Dogemania test, M4 Pro MacBook Pro पर 400 images तक आसानी से 60 FPS पर चला। लेकिन Chrome में 1400 images तक 60 FPS बना रहा, और उसके बाद आगे बढ़ने की झुंझलाहट में मैंने बंद कर दिया
मैंने भी वही experiment किया, और Firefox तथा Chromium के बीच का अंतर निराशाजनक रूप से बड़ा था। Chromium में 1000 images पार करने के बाद भी 100 FPS बना रहा, जबकि Firefox में 500 images के बाद ही 60 FPS से नीचे गिर गया। यह पूरी तरह निष्पक्ष test शायद नहीं था (Chromium में कोई addons नहीं थे और वह मेरा कम इस्तेमाल किया जाने वाला browser है), लेकिन comparative performance के बारे में इसने बहुत कुछ महसूस कराया
अगर dogemania में images animation के बाद स्थिर हो जाती हैं, तो क्या यह वास्तव में बहुत आसानी से optimize किया जा सकने वाला मामला नहीं है? लगता है Amiga जैसे पुराने computers भी इस तरह की चीज़ को अनिश्चित काल तक संभाल सकते थे
Servo को 'नया' engine कहना थोड़ा ज़बरदस्ती लगता है
मेरी समझ थी कि Rust, web browser Servo के लिए बनाई गई थी
“अगर किसी standard की सिर्फ एक ही implementation बची रह जाए, तो वही standard बन जाने का ख़तरा है” — इस राय पर मुझे समझ नहीं आता कि यह समस्या क्यों है। अगर implementation open source हो और specification किसी ऐसे committee द्वारा तय हो जिसे कई पक्ष मिलकर चलाते हों, तो मुझे यह ठीक लगता है। अभी की तरह resources झोंककर कई engines बनाना ही उल्टा बर्बादी लगता है। मुझे तो browser engine भी Linux kernel की तरह एक ही होना चाहिए और अलग-अलग distributions अलग तरह से उसे बाँटें—यह ज़्यादा कुशल लगता है
इरादे कितने भी अच्छे हों, implementation में bugs और छोटे defects रह ही जाते हैं। अगर दूसरा स्वतंत्र implementation न हो, तो आख़िरकार “सबमें यही चलता है” कहते-कहते वही bug standard बन जाता है। और जब web pages ऐसे bugs पर निर्भर होने लगते हैं, तो वे specification के बजाय किसी खास implementation की बारीक खामियों के हिसाब से चलने लगते हैं। MS Windows में पुराने UI की परतें चढ़ती चली गईं और compatibility nightmare बन गया—उसके पीछे यही कारण था। कई स्वतंत्र implementations हों तो standard वास्तव में maintain और evolve किया जा सकता है, और optimization भी आसान होती है
सिद्धांत में यह ठीक लगता है, लेकिन व्यवहार में एक अकेले developer के हित हमेशा users के हितों से मेल नहीं खाते, इसलिए monopoly वांछनीय नहीं है। खासकर Blink-आधारित manifest v2 हटाने जैसा हालिया कदम users को पसंद नहीं आया
जितने ज़्यादा browser engines होंगे, उतना कम जोखिम होगा कि कोई एक security vulnerability सबको एक साथ प्रभावित कर दे। Memory-safe language होने पर भी logical mistakes नुकसान पहुँचा सकती हैं, इसलिए विविधता महत्वपूर्ण है
आपने “एक engine, कई distributions” की strategy की बात की, लेकिन BSD environment या ZFS आदि के अभ्यस्त लोगों के लिए पुरानी व्यवस्था से बाहर आकर देखने पर स्थिरता और परिपक्वता का अंतर बहुत साफ़ महसूस होता है
पहले ही standardization पर Google या उसके नेटवर्क के लोगों का असर बहुत ज़्यादा है। अगर सब कुछ Chromium द्वारा ही चलने लगे, तो स्थिति और बदतर होगी। शायद सचमुच किसी बड़े संकट के बाद ही सब लोग W3C, WHATWG जैसी संस्थाओं की सीमाओं को स्वीकार करेंगे
“ज़्यादातर websites में थोड़ी-बहुत rendering bugs हैं और कुछ तो बिल्कुल काम ही नहीं करतीं, Google search results में overlapping elements बहुत हैं और MacRumors home scroll के बाद crash हो जाता है, लेकिन Wikipedia, CNN Lite, personal sites, NPR text वगैरह पूरी तरह सही चलते हैं” — इस तरह के अवलोकन देखकर शायद ही कभी किसी को Google या MacRumors की तरफ़ इशारा करते हुए यह कहते देखा है कि उन्हें Servo के हिसाब से ठीक किया जाना चाहिए। इसके बजाय हमेशा यही निष्कर्ष निकलता है कि Servo को Chrome/Chromium जैसा behave करना चाहिए, और यही बात बहुत खटकती है। ऐसा होने पर (a) आख़िरकार विज्ञापन कंपनियाँ standard तय करेंगी, और (b) web page बनाने वालों को ग़लत incentives मिलेंगे। Wikipedia या CNN Lite जैसी आसान चीज़ों के हिसाब से बनाना तो ज़्यादा सरल है। मेरा मानना है कि 'standard' browser को लोकप्रियता के हिसाब से नहीं, बल्कि असली standard के ज़्यादा क़रीब जाने की कोशिश करनी चाहिए। जो browser अलोकप्रिय है और जो लोकप्रिय है—दोनों पर चलने वाला page ही सच में standard है। आख़िरकार समाधान web browser को नहीं बल्कि web pages को ठीक करने में है। मैं अब भी w3c की मूल libwww library और tools के साथ प्रयोग कर रहा हूँ। थोड़ा-बहुत सुधार करने पर वह आज भी text-based web pages optimization के लिए 30 साल से ज़्यादा बाद अच्छे से काम करती है। Internet एक public good है, लेकिन आज के browsers और pages advertising optimization और data collection की तरफ़ बहुत ज़्यादा झुक गए हैं, जो दुखद है। सचमुच www users के लिए pages/browsers को प्राथमिकता मिलनी चाहिए, तभी बात सार्थक है। नीचे libwww को static binary के रूप में build करने की एक सरल script है
Mozilla का एक competitive browser कंपनी से धीरे-धीरे activist जैसी संस्था में बदलना सचमुच दुखद है। इसी वजह से शायद उसका core product लगातार कमज़ोर होता गया, और यह बात काफ़ी कड़वी लगती है