शीर्षक से यह संकेत मिलना चाहिए कि यह नियमों की आलोचना है

222

ओहो, यह अच्छा फ़ैसला है..

साइड प्रोजेक्ट में solidjs का DX नंबर वन है >m< / बहुत खुशी

मुझे लगता है कि यह अनुमान लगाना मुश्किल होगा कि fork का नतीजा migration बनेगा या बिखराव का एक युग।
fork के बाद भी upstream के बदलावों को शामिल करना शायद कोई सुखद स्थिति नहीं होगी।

https://hi.news.hada.io/topic?id=16860
Realtime Linux fork को 20 साल बाद merge किया गया था, इसे देखते हुए क्या हमें fork करने का फैसला सावधानी से नहीं लेना चाहिए?

धन्यवाद!

यह ऐसा फ़ैसला लगता है जिसमें उनकी ऑपरेटिंग फिलॉसफी झलकती है। Chrome के बाद मैं Obsidian का सबसे ज़्यादा इस्तेमाल करता हूँ, और इसे हमेशा बहुत अच्छे से इस्तेमाल कर रहा हूँ।

अगर kernel में Rust को लाना चाहने वाले लोग इतने ज़्यादा हैं, तो क्या वे fork करके एक नया project शुरू नहीं कर सकते? फिर जब वह काफ़ी mature हो जाए, तो बड़े distribution शायद Rust-आधारित kernel पर switch कर लें।
मुझे ठीक से समझ नहीं आता कि वे आपस में क्यों लड़ रहे हैं।

बिलकुल, जो startup फेल हुए वे ब्लॉग न करने की वजह से बर्बाद नहीं हुए थे….

आखिर कौन ऐसा है जो किसी फेल हुए startup की विफलता का कारण परिभाषित कर सकता है?

अगर product अच्छा हो तो ब्लॉग की ज़रूरत नहीं होती, यह तो स्वाभाविक है।

उसी तर्क से देखें तो product अच्छा हो तो marketing/sales की भी ज़रूरत नहीं होगी।

यह उस तरह की एक典型 अतार्किक लिखाई है जो यह भ्रम पालती है कि “सबूत का अभाव, अभाव का सबूत होता है।”

मकसद समझ में आता है, लेकिन फिर भी शीर्षक इतना गलत है कि वह मुद्दे के सार को भटका देता है।

“नींद न लेने की वजह से फेल हुआ परीक्षार्थी कोई नहीं होता”
“अच्छा office न होने की वजह से फेल हुई company कोई नहीं होती”
“supplement न खाने की वजह से जल्दी मरने वाला इंसान कोई नहीं होता।”

ऐसे कई दर्जन उदाहरण बनाए जा सकते हैं।

यह लेख लिखने वाले मूल लेखक भी अगर इस पोस्ट को blogging करने से पहले तार्किक सोच से शुरुआत नहीं करेंगे, तो शायद वे भी फेल होंगे।

मैं Rust उपयोगकर्ता हूँ, लेकिन r/rust पर hgwxx7_ की टिप्पणी ने मुझ पर गहरा प्रभाव छोड़ा1.

मुझे लगता है कि Greg यहाँ जिस चीज़ को बहुत अच्छी तरह दिखाते हैं, वह है technical leadership। Leadership का मतलब सही होना नहीं है। वह सही हैं, लेकिन बात वह नहीं है।

Leadership का मतलब है लोगों को उस रास्ते पर साथ लेकर चलना, जिसे वह सबसे बेहतर मानते हैं। वह असहमति रखने वाले maintainers पर दबाव नहीं डालते, न उन्हें डाँटते हैं और न ही मजबूर करते हैं। इसके बजाय, वह पहले दो भाषाओं वाले code base को maintain करने को लेकर उनकी पूरी तरह वाजिब चिंताओं को स्वीकार करते हैं। यह अच्छी बात है, क्योंकि इस मामले में वे सही हैं; चीज़ें आसान होने से पहले उनकी ज़िंदगी सचमुच कठिन होगी।

फिर वह अंत में प्रेरणादायक स्वर अपनाते हैं और बताते हैं कि वे इससे कहीं कठिन काम पहले ही कर चुके हैं, और यह उनके सामर्थ्य के पूरी तरह भीतर है। वह बहुत सहज तरीके से उन्हें R4L devs का स्वागत करने के लिए प्रोत्साहित करते हैं।

Leadership की यह बिल्कुल masterclass है।
जब दूसरे maintainers इसे पढ़ेंगे, तब वे आश्वस्त होंगे या नहीं, यह मुझे नहीं पता। लेकिन मेरे लिए इससे अधिक प्रभावशाली प्रस्तुति की कल्पना करना मुश्किल है।

आखिरकार बात तो labor cost घटाने की ही है।
जब labor cost अलग है, तब भी एक जैसा काम करवाने की कोशिश अपने आप में cultural clash है.. बेहतर होगा कि इसे outsourcing के रूप में किया जाए, जहाँ client-vendor का रिश्ता साफ़ हो।

मैं सहमत हूँ। 24 घंटे काम चलता रहता है मैनेजर या प्रबंधन का एक भ्रम है।

"Rust सही जवाब नहीं है, लेकिन Java और Python की तुलना में सही जवाब के ज़्यादा करीब है" -codemaster kimc-

Microsoft, क्वांटम प्रोसेसर 'Majorana 1' का खुलासा

इसलिए मैं open weight शब्द को ज़्यादा पसंद करता हूँ।

लगता है Falco या linkerd से समस्या पकड़कर, ज़रूरत पड़ने पर subtrace से उसका विश्लेषण कर सकते हैं~ :)

प्यार है हसाबिस~

क्या दूसरे डेवलपरों की गालियां भी अब LLM मेरी जगह खा लेगा?

मुझे लगता है कि svelte जैसे विकल्प मौजूद थे, इसलिए React/nextjs को भी काफ़ी बड़ा प्रोत्साहन मिला होगा।
मूल रूप से svelte एक language है, इसलिए उम्मीद है कि यह UI को व्यक्त करने वाली भाषा को आगे किस दिशा में जाना चाहिए, यह भी अच्छी तरह दिखाएगा।

मैं तो React ही इस्तेमाल करूंगा

S25 और 256 के हिसाब से कीमत भी लगभग वही है, लेकिन 2025 में भी 10 लाख won से महंगे स्मार्टफोन का अभी तक 60Hz होना...