Ladybird ने web-platform-tests में Apple की 90% थ्रेशहोल्ड पार की

• Ladybird ने web-platform-tests नामक वेब स्टैंडर्ड्स ऑटोमेटेड टेस्ट में Apple की 90% पास थ्रेशहोल्ड हासिल की
• यह टेस्ट HTML, CSS, JavaScript आदि के लिए ब्राउज़र की वेब स्टैंडर्ड्स संगतता को समग्र रूप से मापता है
• Apple (मुख्यतः Safari) ब्राउज़र के समान स्तर की उच्च टेस्ट पास दर दर्ज करके, Ladybird के कोर एल्गोरिदम और वेब स्टैंडर्ड्स इम्प्लीमेंटेशन ने इंडस्ट्री के शीर्ष ब्राउज़रों जैसी विश्वसनीयता हासिल की है
• यह एक महत्वपूर्ण मील का पत्थर है, जो दिखाता है कि नया ओपन सोर्स ब्राउज़र मौजूदा बाज़ार दिग्गजों के साथ व्यावहारिक रूप से प्रतिस्पर्धा कर सकता है

[shakespeares]

उम्मीद है कि यह Blink और WebKit के साथ कंधे से कंधा मिलाकर खड़ा होगा।

[GN⁺]

Hacker News राय

• मैंने web-platform-tests में गहराई से काम किया है, इसलिए test pass rate को किसी metric की तरह इस्तेमाल करते समय सावधानी बरतनी चाहिए। इसका मतलब यह नहीं कि मैं Ladybird की उपलब्धि को कमतर दिखाना चाहता हूँ; Ladybird की तेज़ प्रगति वाकई चौंकाने वाली है, और अगर web-platform-tests इस टीम की मदद कर रहा है तो वह अपने-आप में अच्छी बात है। Ladybird, Servo, Flow जैसे नए web platform implementation उभरते देखना बेहद स्वागतयोग्य है। बस, web-platform-tests मूल रूप से एक engineering tool के रूप में optimize किया गया था, कोई objective metric बनाकर नहीं। उदाहरण के लिए, कुल tests में decoding से जुड़े tests का अनुपात बहुत ज़्यादा है। वजह यह नहीं कि browser development में वे सबसे कठिन हैं, बल्कि यह कि उन्हें बनाना आसान है। साथ ही, हम चाहते हैं कि लोग उपयोगी tests आसानी से contribute कर सकें, इसलिए technical और social barriers को कम रखने की कोशिश करते हैं। यह अच्छे metrics बनाने के लिए उपयुक्त नहीं है, लेकिन एक अच्छे engineering resource के लिए बहुत उपयुक्त है। Interop Project अलग trade-off और चुने हुए test set के ज़रिए इस समस्या को कुछ हद तक हल करता है, लेकिन मौजूदा system वैसे संगठनों को ध्यान में रखकर बना है जिनके पास पहले से लगभग पूरा web browser engine मौजूद है
  • ट्वीट में बताया गया है कि यह metric Apple द्वारा Ladybird टीम पर थोपा गया एक मनमाना मानदंड है। Ladybird की monthly updates में encoding tests को हटाकर pass किए गए tests की संख्या भी प्रकाशित की जाती है, क्योंकि वे pass rate को जरूरत से ज़्यादा बढ़ा देते हैं
  • सोचता हूँ कि क्या चुने हुए test subset को metric की तरह इस्तेमाल करना असंभव है
  • तो फिर Apple से सीधे बात करनी चाहिए। यह मानदंड Apple ने बनाया है
  • समझ नहीं आता कि यह बात यहाँ क्यों उठाई जा रही है। यह Ladybird metric नहीं है; iOS के लिए Apple की शर्त है
• यह सचमुच बहुत शानदार है कि Ladybird browser शायद जल्द ही वास्तविक उपयोग के लायक स्तर पर पहुँच जाए। मैंने सोचा था इसमें अभी कई साल लगेंगे, लेकिन यह इतनी जल्दी competitive हो जाएगा, इसकी उम्मीद नहीं थी
  • मैंने खुद इसे इस्तेमाल नहीं किया, लेकिन monthly summary videos कुछ देखे हैं। tests pass करना और रोज़मर्रा के इस्तेमाल में पर्याप्त तेज़ होना दो बिल्कुल अलग बातें हैं। अभी Ladybird उतना तेज़ नहीं लगता। फिर भी पूरी टीम की development उपलब्धि जबरदस्त है
  • क्या “90% complete होने में 90% समय लगता है, और बाकी 10% में भी 90% समय” वाली बात Ladybird पर लागू होती है? अगर हाँ, तब भी कुल मिलाकर development timeline काफ़ी अच्छी लगेगी
  • बहुत ज़्यादा उम्मीद न रखने की सलाह दूँगा। सितंबर development report देखकर लगता है कि अभी भी ठीक करने के लिए बहुत कुछ बचा है। प्रगति असाधारण है, इसमें कोई शक नहीं, लेकिन Ladybird को पूरा होने में अभी भी कुछ साल और लगेंगे
  • 3 साल पहले मैं Ladybird को लेकर काफ़ी संशय में था। लेकिन पहली बात, अब full-time engineers की संख्या 8 हो गई है, जो मैंने नहीं सोचा था; और दूसरी बात, सचमुच 3 साल बीत भी चुके हैं। इसलिए अब मैं कहीं ज़्यादा आशावादी हूँ। हाँ, Chrome से प्रतिस्पर्धा करने में अभी बहुत समय लगेगा, और किसी मौजूदा engine को fork किए बिना खुद से बनाने के मूल्य पर मेरे मन में अभी भी सवाल हैं
  • पहले मुझे लगता था कि बिल्कुल नया browser engine बनाने में कई दशक लगेंगे, लेकिन Ladybird टीम जैसे समर्पित लोगों को यह करते देखना हैरान करने वाला है
• संबंधित ट्वीट में कहा गया है कि iOS पर वैकल्पिक browser engine के रूप में विचार किए जाने के लिए यह Ladybird का एक अहम milestone है
  • इसलिए headline में Apple आने का संदर्भ समझ आता है
  • लेकिन कम-से-कम यह बात सिर्फ EU के भीतर की है; उसके बाहर Apple चाहे engine कितना भी अच्छा हो, उसे अनुमति नहीं देगा
• यह बहुत प्रभावशाली है कि Ladybird जैसा स्वतंत्र और non-corporate project इतनी तेज़ी से बढ़ा है
  • “non-corpo” जैसी अभिव्यक्ति समझ में आती है, लेकिन असल में Ladybird organization खुद एक corporation है। संबंधित दस्तावेज़ देखें
  • Browser कितनी सारी चीज़ें करता है, यह सोचें तो इस स्तर का project सचमुच बहुत विशाल है। एक बेहतरीन html/css renderer और JS engine बना लेना ही अपने-आप में बहुत बड़ी बात है, लेकिन ecosystem में प्रवेश करते ही आगे होने वाले हर बदलाव के साथ कदम मिलाकर चलना पड़ता है। Chrome नए proposals का विरोध भी कर सकता है, जबकि छोटे browsers ज़्यादातर बस पीछे-पीछे चलने को मजबूर लगते हैं
  • मुझे शक है कि Ladybird वाकई non-corporate है। याद है कि इसे कुछ corporate sponsorship मिली थी। उस हिसाब से यह कहना मुश्किल है कि यह Firefox वाले non-profit Gecko से बेहतर है
  • अगर Ladybird यह गति बनाए रखता है, तो उम्मीद है कि 2027 के अंत तक यह एक गंभीर competitor बन सकता है। लेकिन व्यक्तिगत रूप से मुझे लगता है कि अगला सबसे feature-rich Servo engine भी इतने ही केंद्रित प्रयास का हकदार है। FF/Mozilla को इसमें खास दिलचस्पी नहीं दिखती, इसलिए एक अलग browser project ज़रूरी लगता है
  • tests pass कर लेना और सुरक्षित होना दो बिल्कुल अलग बातें हैं। यह conformance tests हैं, security tests नहीं। फिर भी यह बेहद प्रभावशाली है
• सोच रहा हूँ कि आख़िरी 10% कितना कठिन होगा। सामान्य software projects में आख़िरी 10% तक पहुँचने के लिए 90% से भी ज़्यादा अतिरिक्त मेहनत लगती है
  • और आख़िरी 1% तो लगातार बदलता रहेगा और कभी सचमुच पूरा नहीं होगा। 90% Apple का मानदंड है। लेकिन आम users के लिए पर्याप्त स्तर क्या है, यह जानना दिलचस्प होगा
  • Browser ऐतिहासिक रूप से सबसे बड़े और सबसे कठिन projects में रहे हैं। इसलिए इसके आसान हो जाने की उम्मीद क्यों की जाए, समझ नहीं आता। अगर segfault खोजने पर $20,000 का bounty रखा जाए, तब शायद इसे सचमुच completion stage के करीब मानूँगा
• मैंने खुद Ladybird को build करके चलाया है। हैरानी की बात है कि काफ़ी सारी websites पहले से ठीक खुल जाती हैं। हालांकि Youtube अभी काम नहीं करता, और Vimeo या Reddit comment box पर crash हो जाता है। फिर भी नतीजे बहुत उत्साहजनक हैं। build के लिए लगभग 6GB HDD space चाहिए
• graph में बड़ा jump दिख रहा है! जानना चाहता हूँ कि किस बदलाव से यह सुधार आया
  • Twitter thread में किसी ने Andreas से यही सवाल पूछा था, और कारण CSS Typed Object Model API spec को merge करना बताया गया
  • इस Pull Request से CSS से जुड़े लगभग 6400 tests अतिरिक्त pass होने लगे। फिर भी शायद graph में दिख रहे पूरे spike की यही एकमात्र वजह नहीं है, लेकिन इससे निश्चित रूप से मदद मिली। PR विवरण
  • graph में axes ही नहीं हैं, इसलिए यह पता नहीं चलता कि jump वास्तव में कितना बड़ा है। उदाहरण के लिए, यह 89% से 90.2% तक भी हो सकता है। हो सकता है यह graph के बाएँ हिस्से में न दिखाए गए पुराने increments से विशेष रूप से बड़ा मामला न हो
• जानना चाहता हूँ कि Ladybird के gtk से जुड़े development का क्या हाल है
• सोच रहा हूँ कि Ladybird कौन-सा JS engine इस्तेमाल करता है
  • यह अपना खुद का engine LibJS इस्तेमाल करता है LibJS GitHub
  • पूरा source code original है
• एक engineer के नज़रिए से यह चौंकाने वाला है कि एक giant corporation quality standards तय करे और 3rd party software की API access को सीमित करे। ग्राहक के नज़रिए से, सख्त quality standards और OS-level API restrictions के कारण security verification होना अच्छी बात लग सकती है
  • consumer के नज़रिए से, browser को Apple review pass करना पड़ता है, इसलिए updates — जिनमें bugs और security fixes भी शामिल हैं — धीमे हो जाते हैं। Mac या दूसरे platforms पर इसकी ज़रूरत नहीं होती। Apple ऐसे browsers को, जो सिर्फ Safari न हों, ठीक से काम भी नहीं करने देता, जबकि Mac या दूसरे OS पर ऐसा माहौल नहीं है। और EU में वैकल्पिक engines की अनुमति देने का दिखावा भी है, लेकिन व्यवहार में सिर्फ malicious compliance बढ़ी है, जिससे alternative engines लगभग सिर्फ सैद्धांतिक संभावना बनकर रह गए हैं। नतीजतन consumer के लिए भी यह नुकसानदेह है
  • consumer के नज़रिए से, लोग OS के official browser में GitHub या Threads जैसी services इस्तेमाल करने में भी दिक्कत झेल रहे हैं
  • engineer के रूप में मेरा सवाल यह है कि क्या Apple का browser खुद भी अपने मानदंडों पर खरा उतरता है। Safari में ही मुझे कुछ खास bugs बार-बार बहुत अधिक दिखते हैं। इनमें कई ऐसे सामान्य bugs भी हैं जिनसे शायद वेबपेज बनाने वाला लगभग हर व्यक्ति कभी न कभी टकराया होगा
  • क्या टूटा हुआ browser न इस्तेमाल करने का विकल्प वास्तव में मौजूद है, यह भी सवाल है
  • यह कोई हैरानी की बात नहीं, बल्कि मुझे यह नियंत्रण बनाए रखने की anti-competitive और unfair कोशिश लगती है