Dave Cutler द्वारा समझाया गया Windows [वीडियो]
(youtube.com)- Dave Cutler ने RSX-11, VMS, Windows NT से लेकर Azure और Xbox तक के अपने अनुभव के आधार पर Windows NT के डिजाइन बैकग्राउंड और Microsoft की development culture को याद किया
- Windows NT का लक्ष्य शुरुआत से ही portable operating system और कई execution environments का support था, और Windows 3.1 के 6 महीनों में 1.6 करोड़ copies बिकने के बाद OS/2 के बजाय Windows मुख्य environment बन गया
- शुरुआती NT ने i860, MIPS, x86, Alpha, PowerPC जैसे कई architectures और HAL, object manager, kernel/driver structure को संभाला, और इसकी core structure का बड़ा हिस्सा Windows 11 में भी बचा हुआ है
- VMS का लक्ष्य release के समय 0 known bugs था, और NT development team ने Friday WHIM से संगठन की एकजुटता बनाए रखी, लेकिन NT, Cairo, Longhorn और XP security response में schedule, quality और codebase branching बड़ा बोझ बन गए
- Cutler के अनुसार bug fixing, testing, quality assurance और अनावश्यक features न जोड़ने का संयम अच्छी software team के मूल attitude हैं
Windows NT से पहले operating systems में करियर
- Dave Cutler ने DuPont में real-time systems और computer simulation से परिचय के बाद problem-solving tools से ज्यादा computer itself में रुचि लेना शुरू किया
- Scott Paper की foam manufacturing process को GPSS 3 से simulate करने वाले project में उन्हें card errors और debugging से जूझना पड़ा
- errors घटाने के लिए उन्होंने Fortran program लिखा, और बाद में IBM 7044 assembly तक सीखते हुए computer के internal operations में रुचि बढ़ाई
- DuPont के real-time systems group में उन्होंने Instron tensile test data का automatic analysis करने वाला program लिखा
- data collection program real-time में चलता था और 1 millisecond या 100 millisecond units में data पढ़ता था
- इसके बाद Univac 1107 के operating system Exec II पर काम करते हुए वे operating system development में गंभीरता से उतर गए
- हर दिन शाम 5 बजे operators को बाहर भेजने के बाद 2 घंटे तक experimental code और tests चलाते थे
- लगभग debugger-रहित environment में switches और halt instruction से debugging करते थे
DEC के दिन: RSX, VMS, compilers, PRISM
- Digital Equipment Corporation में उन्हें शुरुआत में OS/45 के लिए hire किया गया था, लेकिन जल्द ही RSX-11C पर काम मिला
- उस समय PDP-11 का 16-bit address space Cutler के हिसाब से बड़ी limitation था
- उनका आकलन था कि RSX-11C एक छोटा system था और उस समय के मानकों से भी इसकी functionality limited थी
- VMS development को VAX hardware और PDP-11 compatible execution layer का इस्तेमाल करके bootstrap किया गया
- VAX में PDP-11 mode था, और Application Migration Executive नाम की layer से RSX-11M utilities चलती थीं
- Files-11 file system को भी VMS में फिर से implement करके compatibility बनाए रखी गई
- development के शुरुआती दौर में hardware emulator पर scheduling और memory management जैसे core काम किए गए
- VMS ने self-hosting को quality assurance का तरीका बनाया
- Proto 3 पर पर्याप्त stability से चलने लगा तो development team ने उसी system पर सीधे काम किया
- system bug check देता तो कुछ लोग machine के सामने जाकर debugger से cause ढूंढते, fix करते और फिर reboot करते
- उन्होंने याद किया कि VMS release के समय “0 known bugs” पर था
- इसका मतलब “bugs नहीं थे” नहीं, बल्कि release के समय तक ज्ञात सभी bugs को ठीक करने की कोशिश थी
- आखिरी समय में भी disk driver का race condition fix किया गया
- VMS के बाद वे PL/I compiler और C compiler backend, code generator, optimization और register allocation में भी शामिल रहे
- PL/I frontend Boston की एक company से खरीदा गया था, और backend VAX पर develop किया गया
- कुछ frontend काम MIT के Multics पर किया गया और data tape से ले जाया गया
- DEC West में वे Velon नाम के real-time system और MicroVAX project में शामिल रहे
- Velon ऐसा system था जिसमें user-mode drivers, message-oriented structure, multithreading और multiprocessor जैसे ideas experiment किए गए
- MicroVAX 1 में Cutler ने पूरा microcode लिखा
- PRISM project DEC का RISC architecture प्रयास था, और cancel होने के अगले दिन Cutler ने company छोड़ने का फैसला किया
- PRISM में 32-bit और 64-bit versions के architectures थे, और Micah नाम का ambitious software system भी चल रहा था
- PRISM cancel होने के बाद वे server company शुरू करना चाहते थे, लेकिन Microsoft से संपर्क होने पर दिशा बदल गई
Microsoft में शामिल होना और Windows NT design
- Microsoft में शामिल होना Bill Gates से बातचीत के बाद भी पक्का नहीं था, लेकिन Steve Ballmer के साथ Denny’s में breakfast के बाद फैसला जल्दी हो गया
- Cutler के अनुसार Ballmer वह key person थे जिन्होंने उन्हें Microsoft join करने के लिए मनाया
- NT का शुरुआती लक्ष्य portable operating system और कई execution environments का support था
- उस समय target environment OS/2 था, और POSIX भी अहम candidate था
- विचार यह था कि system का core basic services देगा और उसके ऊपर कई environments चलेंगे
- Windows के NT का central environment बनने की वजह Windows 3.1 की success थी
- Windows 3.1 की 6 महीनों में 1.6 करोड़ copies बिकीं, और Bill Gates ने माना कि नए system का मुख्य environment Windows होगा
- NT development OS/2 पर भी हुआ, लेकिन team जल्दी से NT को खुद self-host करना चाहती थी
- NT नाम का मतलब “New Technology” है
- i860 के code name N10 और NT के बीच धुंधला connection हो सकता था, लेकिन Cutler NT को New Technology मानते हैं
- marketing side ने विरोध किया कि “नई technology” जैसा नाम खरीदारी को लेकर हिचक पैदा कर सकता है, लेकिन Cutler ने NT नाम को आगे बढ़ाया
- NT के पहले version ने कई CPU architectures support किए
- x86, MIPS R3000/R4000 और Alpha का जिक्र हुआ
- PowerPC NT 3.5 या Daytona के समय आया, और Cutler के अनुसार PowerPC build और hardware competitiveness अच्छी नहीं थी
- NT का HAL मूल रूप से hardware abstraction layer से आगे vendor abstraction layer के करीब था
- शुरुआत में इसे अलग DLLs के रूप में बनाया गया ताकि vendors HAL provide कर सकें
- Cutler का बाद का मत था कि HAL को operating system के हिस्से की तरह build करना बेहतर होता
- NT kernel और HAL में assembly बहुत ज्यादा नहीं थी
- performance के लिए जरूरी कुछ frequent operations में assembly या intrinsic की जरूरत थी
- x64 में inline assembly के बजाय intrinsic इस्तेमाल करने की दिशा चुनी गई
NT development culture, Cairo, Longhorn, XP security
- NT team ने तेजी से बढ़ते organization को एक साथ रखने के लिए हर शुक्रवार WHIM आयोजित किया
- WHIM का full form Weekly Integration Meeting था
- शुरुआत में managers Safeway से beer और chips लाते थे और hardware lab में meeting होती थी, बाद में यह बड़े space और catering तक बढ़ा
- Cutler के अनुसार यह portrayal सही नहीं है कि NT development ने लोगों से लगातार सिर्फ overwork कराया; team ने हर हफ्ते stress release का मौका बनाने की कोशिश की
- NT 3.5 के बाद Windows 95 UI को NT में लाने की दिशा और Cairo project साथ-साथ चले
- Tuckwila को एक तरह के backup NT 4.0 की तरह maintain किया गया, और daily builds में Tuckwila stable निकलता था लेकिन Cairo अक्सर टूट जाता था
- Cairo features धीरे-धीरे हटते गए, और Cutler को याद रहने वाले प्रमुख porting results file server software और Kerberos जैसे थे
- NT 4.0 बहुत popular version बना रहा, और Cutler ने ऐसे लोगों से भी मुलाकात की है जो अभी भी NT 4.0 इस्तेमाल करते हैं
- NT 3.1 का schedule VMS से भी ज्यादा लंबा चला
- VMS को करीब 20 बेहद काबिल लोगों की team ने 2 साल में बनाया था
- NT में ज्यादा काम करना था, और i860 छोड़कर MIPS, x86, Alpha जैसी कई architectures जोड़ने से scope बढ़ गया
- Longhorn और Vista तक की प्रक्रिया में codebase separation बड़ी समस्या बनी
- Windows 2000 के बाद server और workstation codebases अलग हो गए, और server side जहां security issues के कई fixes कर रही थी, consumer side में build और execution unstable होते गए
- XP बहुत successful रहा लेकिन उसमें bugs बहुत थे, और बाद में security issues बढ़ने के बाद XP bug fixes में काफी effort लगा
- Cutler के group ने XP-related security bugs करीब 5,000 fix किए
- AMD का x64 extension Microsoft के अंदर अहम turning point बना
- AMD ने कम invasive 64-bit extension idea दिया जिसमें 32-bit applications तेजी से चल सकती थीं
- Cutler ने server codebase के आधार पर 64-bit workstations और servers बनाने का फैसला किया, और यह company द्वारा शुरुआत से officially approved project नहीं था
- AMD systems आने पर पहली boot CD से की गई, और 64-bit system तुरंत boot होकर चल पड़ा
- microsoft.com ने लगभग 1 हफ्ते test करने के बाद 64-bit servers पर switch किया, और इसे 32-bit systems से कहीं ज्यादा stable माना गया
- Longhorn आखिरकार x64 codebase पर shift हुआ, और वही codebase आज तक चला आ रहा है
Windows की internal structure और आज तक बचा code
- Windows 11 में भी NT 3.5 के दौर की बहुत-सी core functionality और structure बची हुई है
- kernel code, memory management structure, process structure और object manager जैसे core elements जारी हैं
- कुल code में original code का हिस्सा घटता रहता है, लेकिन वही functions निभाने वाली core structure का काफी हिस्सा बना हुआ है
- Cutler ने NT के object manager को अच्छे codebase का अहम कारण बताया
- Unix के “everything is a file” approach के उलट, NT में नया object type descriptor बनाकर और उसे object manager में integrate करके नया operating system object जोड़ा जा सकता है
- objects synchronization और access control जैसी functionality दे सकते हैं
- handle table performance के लिहाज से अहम हिस्सा है, इसलिए इसे कई बार फिर से लिखा गया
- handle translation असल performance issue था
- उन्होंने उदाहरण दिया कि Cutler के work system पर करीब 60 processes, सैकड़ों threads और 1.5 लाख handles खुले हुए थे
- Task Manager का size बढ़ना code bloat का उदाहरण बताया गया
- मूल Task Manager 85KB में compile होता था, लेकिन अब 4MB का है
- अब यह CPU, network, disk आदि ज्यादा information दिखाता है, लेकिन Cutler के अनुसार बढ़ोतरी जितनी है, functionality उतनी नहीं बढ़ी
- graphics driver को user mode से kernel mode में ले जाने का फैसला performance के लिए जरूरी था, लेकिन इसमें काफी growing pains थे
- Cutler ने शुरुआत में kernel mode में ले जाने का विरोध किया था
- user mode और kernel mode के synchronization models अलग थे, इसलिए यह सिर्फ code move करने भर का काम नहीं था, और 16-bit data structures और primitives भी बोझ थे
- बाद में reliability काफी बेहतर हुई, लेकिन एक समय vendor graphics drivers की समस्याएं बहुत थीं
Azure, Xbox, xCloud
- Cutler ने x64 system ship करने के बाद fcib समस्या से निराश होकर Microsoft छोड़ने की बात कही, और Steve Ballmer की सलाह पर छुट्टी लेने के बाद नवंबर 2005 में वापस लौटे
- fcib का मतलब checked-in binary है, और source के बजाय binaries check in करने वाले groups के कारण porting मुश्किल होती थी
- बाद में वे शुरुआती Azure project में शामिल हुए
- Ray Ozzie ने देखा कि कई cloud-based services के लिए common infrastructure नहीं है, और project शुरू कराया
- शुरुआती Azure का लक्ष्य application deployment, configuration control, version management, restart, billing और cloud file system जैसी platform infrastructure था
- उन्होंने समझाया कि AWS ने infrastructure-focused offering दी थी, जबकि Microsoft शुरुआत में platform services बेचना चाहता था
- Azure का शुरुआती hypervisor Connectix acquisition से आई technology पर आधारित था
- Connectix के पास Virtual PC और Virtual Server products थे, और hypervisor development भी शुरुआती अवस्था में चल रहा था
- बाद में Xbox hypervisor Azure के Red Dog hypervisor से आया
- Xbox तीन VM structure पर चलता है
- host system सभी devices का owner होता है और VMs के बीच communication में traffic cop की भूमिका निभाता है
- presentation VM window manager और display system संभालता है और लगातार चलता रहता है
- game VM हर game के लिए start/stop होता है, और game OS के साथ package होता है
- game का OS के साथ package होना backward compatibility के लिए फायदेमंद है
- game developers GDK के OS के साथ game package करते हैं, और run करते समय वही VM साथ में boot होता है
- इससे operating system changes के कारण पुराने games टूटने से बचते हैं
- लेकिन existing games में feature डालना हो तो universal game OS जैसे workaround की जरूरत होती थी
- Xbox का pause/resume VM save और restore करने के तरीके से चलता है
- game loading में gigabytes data शामिल होता है, इसलिए समय लगता है
- pause/resume VM state को save करके बाद में restore करने की functionality है
- मौजूदा काम के रूप में xCloud console के idle time का उपयोग करने वाले Linux VM और graphics stack का जिक्र हुआ
- xCloud में Xbox consoles को rack में repackage करके datacenter में रखा जाता है और remote access दिया जाता है
- console single tenant होता है, इसलिए एक समय में एक व्यक्ति उपयोग करता है और idle time बनता है
- unused time में Microsoft-only machine learning workloads चलाने की योजना के लिए Linux VM, Xbox hypervisor और graphics stack पर काम चल रहा है
Quality, team operations और development philosophy
- Cutler ने “successful लोग वे काम करते हैं जिन्हें unsuccessful लोग refuse करते हैं” वाली बात software teams पर भी लागू की
- code लिखा है इसलिए test नहीं करेंगे, schedule बचा है फिर भी शाम 5 बजे निकल जाएंगे, अपने bugs ठीक करने से बचेंगे—ऐसे attitudes को वे problem मानते हैं
- जरूरी काम खुद करके success दिलाने वाला attitude वे अहम मानते हैं
- वे “Thinker-doer” को बहुत महत्व देते हैं
- Brooks को quote करते हुए उन्होंने कहा कि सोचने वाले लोग कई हैं, पर execute करने वाले कम हैं, और दोनों करने वाले उससे भी कम
- उनके अनुसार architect को भी goals और constraints satisfy करते हुए actual results बनाना चाहिए
- वे University of Washington की lab wall पर “अगर डालोगे नहीं, तो निकालना भी नहीं पड़ेगा” वाक्य लगाना चाहते थे
- इसे अनावश्यक features न जोड़ने के संयम पर जोर देने के लिए इस्तेमाल किया गया
- शुरुआती development environments में debugging tools खराब थे, इसलिए शुरुआत से mistakes कम करने का attitude जरूरी था
- पहले कभी-कभी logic analyzer या oscilloscope तक इस्तेमाल करना पड़ता था
- आज tools में छोटी mistakes घटाने वाली कई capabilities आ गई हैं, लेकिन उनके हिसाब से quality पर pressure पहले जैसा नहीं है
- multitasking संभव है, लेकिन सबसे ज्यादा productivity single task पर focus करने से आती है
- क्योंकि context switch में समय लगता है
- हालांकि वे बताते हैं कि किसी और की अटकी problem में मदद करने या bugs fix करने जैसे task switches वे करते हैं
1 टिप्पणियां
Hacker News टिप्पणियाँ
इंटरव्यू लेने वाले Dave Plummer भी अपने आप में बहुत दिलचस्प इंसान हैं। खासकर https://www.youtube.com/watch?v=JlZe2JwrJqM और https://www.youtube.com/watch?v=b0zxIfJJLAY जैसे retro coding वीडियो बहुत अच्छे लगे
वीडियो मजेदार हैं, और बैकग्राउंड म्यूज़िक व RGB लाइटिंग से Christmas जैसा माहौल बनता है। इसने Microsoft के बारे में मेरी पुरानी छवि को पूरी तरह बदल दिया, और Redmond की अजीब बातों को मानते हुए भी अपने काम, सहकर्मियों और Microsoft के बारे में बहुत गर्मजोशी से बात करते हैं
बस इस चैनल को देखने के बाद YouTube algorithm में कुछ ट्रिगर हो जाता है और recommendation feed ADHD वीडियो से भर जाती है। शायद autism और ADHD से जुड़े वीडियो की वजह से, लेकिन मैंने तो सिर्फ coding और Microsoft history वाले वीडियो देखे थे—YouTube इतना समझदार तो होना चाहिए कि यह फर्क समझ सके
लेकिन यह कहना अच्छा नहीं लग रहा, फिर भी Microsoft/Windows के बाहर के विषयों पर उनकी बातों को काफी छानकर सुनना चाहिए। खासकर नीचे की टिप्पणी [1] के बाद तो और भी
हाल में ad blocker बंद करने के लिए मजबूर करने वाली हरकत भी आँखें खोलने वाली थी। YouTube ads वाकई बेहद खराब हैं, और यह सोचना भी शर्मनाक लगता है कि असली लोग उन पर प्रतिक्रिया देते होंगे। लगता है YouTube ने अच्छा user experience देने का दिखावा करना भी छोड़ दिया है
फिर भी इस Dave Cutler इंटरव्यू जैसी शानदार चीज़ें देखने के लिए कभी-कभी इस कीचड़ में थोड़ा खोदना वाजिब है
मजाक नहीं कर रहा, “आधा” कहना भी काफी सटीक है। या तो कुछ टूट गया है, या YouTube ने recommendation engine में किसी large language model को जोड़ दिया है
अच्छी तरह edited वीडियो की तुलना में उन्हें यूँ ही extempore बोलते देखना ज्यादा पसंद आया
उस एक ही वीडियो के बाद recommendations cancer, अंतिम समय से गुजर रहे लोगों, और तरह-तरह की बीमारियों वाले वीडियो से भर गईं। वह वीडियो उस व्यक्ति के सामान्य कंटेंट से भी बिल्कुल जुड़ा नहीं था, और मैंने ऐसे suggested videos में से एक भी नहीं देखा, फिर भी वे लगातार आते रहे
मैंने अभी तक यह वीडियो नहीं देखा है, लेकिन कुछ साल पहले Showstopper[1] पढ़ी थी, इसलिए काफ़ी उम्मीद है
जो बात मुझे ख़ास तौर पर याद रही, वह यह थी कि अपने शुरुआती 20s में जब मुझे लगता था कि हमेशा काम करते रहना चाहिए, तब Dave हर बार अपनी छुट्टियाँ समय पर, बिना किसी बहस के, ज़रूर लेते थे
हो सकता है आपको Microsoft पसंद न हो, लेकिन शायद यह पहली बार था जब मैंने किसी बेहद सक्षम और पूरी तरह योग्य व्यक्ति को देखा, जो 24 घंटे लगातार पिसता नहीं था
यह बात लिखना भी अभी थोड़ा अजीब लगता है, लेकिन मेरी सोच उस देहाती और retail culture से आई थी जहाँ माना जाता है कि “जितनी ज़्यादा तकलीफ़, उतना ज़्यादा पुण्य”
आज भी ठीक से आराम करना मुश्किल है, और X या Y को ज़्यादा महत्वपूर्ण मानकर उसे टाल देना आसान है। फिर भी Dave का नज़रिया याद दिलाता है कि आराम और X को अच्छी तरह करना, ये दोनों एक-दूसरे के विकल्प नहीं हैं
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
“सब्त के दिन को स्मरण रखो, और उसे पवित्र मानो… छह दिन परिश्रम करके अपना सब काम करना, पर सातवाँ दिन तुम्हारे परमेश्वर यहोवा का विश्रामदिन है…”
https://en.wikipedia.org/wiki/Protestant_work_ethic
https://www.biblegateway.com/passage/?search=Exodus%2020&ver...
कर्मचारी जितना ज़्यादा “नाक घिसकर” और “पीठ तोड़कर” काम करेंगे, कंपनी का मुनाफ़ा उतना बढ़ेगा, लेकिन ज़रूरी नहीं कि उन्हें ज़्यादा वेतन भी मिले। अगर उनकी सेहत इतनी बिगड़ जाए कि वे काम ही न कर सकें, तो बस उन्हें बदल दिया जाता है
देर रात लिखा जवाब है, इसलिए थोड़ा रूखा लगे तो माफ़ कीजिए, लेकिन लगता है यहाँ लोग यह बात वैसे भी सहज रूप से जानते हैं
फिर burnout हुआ, और अब मुझे लगता है कि आराम करना, और असली emergency को छोड़कर 8 घंटे के workday का पालन करना, सिर्फ़ निजी ज़िम्मेदारी नहीं बल्कि एक professional duty भी है। यह burnout के ख़तरे को कम करता है, और burnout सचमुच सबके लिए बुरा होता है
मैंने WinNT 3.1 के development के आख़िरी चरण के बारे में एक पोस्ट पढ़ी थी, जिसमें किसी ने ब्लू स्क्रीन दिखाने वाला एक screensaver बनाया था। शायद वह Usenet पर थी
तब तक मैंने कभी screensaver नहीं बनाया था, लेकिन Microsoft के एक internal network driver bug की वजह से मैं अपने WinNT development machine पर भरोसेमंद तरीके से blue screen ला सकता था
इसलिए मैंने Windows screensaver लिखने का documentation पढ़ा, अपनी blue screen पर दिखने वाले values नोट किए, और अपना पहला और आख़िरी Windows screensaver जल्दी-जल्दी बना डाला
मज़ाक में मैंने Windows NT group को mail भेजकर बताया कि मैंने क्या बनाया है, और कुछ हफ़्तों बाद NT build group ने Dave Cutler के साथ prank करने का फ़ैसला किया
उन्होंने मेरा blue-screen screensaver एक build server पर install कर दिया, mouse और keyboard भी unplug कर दिए, और इंतज़ार करने लगे
Dave Cutler नया NT build किस हालत में है यह देखने आए, monitor on किया और blue screen देखी। उन्होंने mouse हिलाया, लेकिन कोई प्रतिक्रिया नहीं हुई, और keyboard दबाया, तब भी कुछ नहीं हुआ
फिर कुछ अप्रत्याशित हुआ। उन्होंने हाथ बढ़ाकर build server का power button दबाया और उसे reboot कर दिया। NOOOOOOOOOOOOOOOOOOOOO
उस prank के बाद क्या हुआ या उसका क्या नतीजा निकला, यह मैं कभी नहीं सुन पाया। बड़ी ताक़त के साथ बड़ी ज़िम्मेदारी आती है
मैंने भी उसे install किया था, और मेरे आसपास बैठे कुछ सहकर्मियों ने भी वही लगाया था
CTO सुबह-सुबह एक meeting के लिए आया और हर स्क्रीन पर वही देखकर उसे लगा कि या तो virus फैल गया है या कोई software bug है, और वह थोड़ा घबरा गया
कुछ हफ़्ते पहले किसी ने यहाँ जिस किताब “Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft” की सिफ़ारिश की थी, मैं भी उसे यहाँ recommend करता हूँ
मैं अभी भी उसे पढ़ रहा हूँ, लेकिन वह सच में बहुत दिलचस्प है, और पढ़ते हुए लगता है कि काश मैं भी उस इतिहास का हिस्सा रहा होता। ख़ासकर यह बात कि वे एक बिल्कुल नए operating system को dogfooding कर रहे थे। बस यह मेरे समय से कुछ साल पहले की बात थी
उस किताब की वजह से मैं वास्तविकता से कहीं ज़्यादा जानकार लग रहा था, और कुछ दिन पहले की तुलना में पूरे क्षेत्र को लेकर बहुत ज़्यादा उत्साहित था
offer मिला था, लेकिन आख़िरकार मैंने वह काम नहीं लिया
इसी सिलसिले में यह भी है: https://blog.codinghorror.com/showstopper/
दिलचस्प हिस्सा यह था कि Xbox hypervisor desktop पक्ष से नहीं बना था, बल्कि Azure-आधारित था, और Xbox games डिवाइस के ऊपर एक single operating system पर निर्भर होने के बजाय operating system के साथ पैकेज किए जाते हैं, इसलिए वे कुछ हद तक container के ज्यादा करीब हैं
Dave ने यह भी कहा कि वह idle Xbox Cloud Gaming devices पर machine learning workloads चलाने लायक बनाने का काम कर रहे हैं। Azure और Xbox के बीच ऐसा architectural connection है, यह मैंने कभी सोचा ही नहीं था
उदाहरण के लिए, game executable वास्तव में game disc पर encrypted होता है, और चल रहे असली binary को dump करना भी लगभग असंभव है। RAM भी encrypted है
और modern TPM के CPU के अंदर आने की एक वजह यह भी थी कि लोग Xbox पर जैसा करते थे, वैसा TPM bus sniffing न कर सकें
मैंने Windows kernel team में काम किया था, और DC के बारे में मेरी पसंदीदा कहानी यह है कि वह Itanium architecture से इतनी नफरत करता था कि लगभग उसी ने x64 को हकीकत बना दिया
उसने AMD के साथ काम करते हुए अपने corner office में लगातार code लिखकर इस काम को practically आगे बढ़ाया
विचार यह था कि “कई, कभी-कभी variable bit length instructions को एक word में bundle कर दिया जाए, और compiler writer पर छोड़ दिया जाए कि वह instruction का optimal bundle खोजे, तो implementation simple हो जाएगा और तेज भी हो सकता है” — लेकिन अगर compiler वह optimal bundle नहीं खोज पाए, तो यह x86 जैसे traditional design से भी धीमा हो जाता है
Intel के अंदर कोई बहुत ऊँचे पद वाला व्यक्ति इस विचार से सचमुच बहुत प्रेम करता होगा। क्योंकि प्रमुख microprocessor vendor के रूप में Intel के पूरे इतिहास में इसे तीन बार आजमाया गया और तीनों बार असफल रहा
उस समय AMD64 को “उसी चीज़ का थोड़ा और” मानकर अच्छा विचार नहीं समझा गया था। फिर भी, RISC revolution को लगभग खत्म कर देने वाली बेकार चीज़ों को हटाने में Dave का योगदान अच्छी बात थी
काश मैं भी कभी अपने खाली समय में इतना प्रभावशाली कुछ बना पाऊँ
दुर्भाग्य से Microsoft के लिए, वह इनाम x86-64 पर Linux ले गया
मेरे software engineering career के सबसे निर्णायक पलों में से एक वह था जब मैंने 6–7 साल पहले leaked NT source code पढ़ते हुए साथ में Showstopper[1] भी पढ़ी थी
NT leak खास तौर पर इसलिए बेहद आकर्षक था क्योंकि उसमें author history पूरी शामिल थी, इसलिए आप देख सकते थे कि Dave Cutler ने ठीक किन files पर काम किया था। किताब में kernel modules में pageable sections आने की प्रक्रिया जैसी बातें भी काफी विस्तार से हैं, जो अपने आप में भी दिलचस्प हैं
किताब में एक दृश्य है जहाँ Cutler आकर एक खास assembly routine को फिर से ठीक करता है, और असली source code में आप देख सकते हैं कि वह routine बिल्कुल कौन-सा है
Cutler का code सचमुच बेहद खूबसूरत C code था, और मुझे यक़ीन है कि आज भी होगा। NT-style C code लिखने के मेरे तरीके पर उसका गहरा असर पड़ा
[1]: https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...
Computer History Museum की David Cutler oral history interview भी बहुत अच्छी है
Part 1: https://youtu.be/29RkHH-psrY
Part 2: https://youtu.be/SVgSLud50ss
नई interview के कुछ हिस्से मैंने देखे हैं, लेकिन अभी तक मुझे यकीन नहीं है कि उसमें मैंने कुछ सचमुच नया सुना है या नहीं
दोनों Dave ने जो कहा, उसे पीछे मुड़कर देखें तो, बनाकर रिलीज़ करने पर बहुत ज़्यादा ध्यान है, लेकिन दीर्घकालिक योजना या वास्तविक security strategy पर लगभग कोई बात नहीं है
पूरी बात commercial pressure के बीच meat grinder से sausage निकालने जैसी है, और failures को किसी स्वीकार्य स्तर तक नीचे रखने की है
यह भी हैरानी की बात नहीं है कि पूरे industry में स्थिति बेहतर नहीं हो रही और सही दिशा में मुड़ नहीं रही। कभी लगा था कि हम capability-based security तक पहुंचेंगे, लेकिन अब लगता है कि हम उसके लगभग बेकार चचेरे भाई, application permission flags, में हमेशा के लिए फंसे रहेंगे
भविष्य को लेकर चिंता होती है
VP से SVP, SVP से CEO तक जाने को सही ठहराने लायक बस कुछ अच्छे quarter या कुछ साल चाहिए होते हैं। पिछली भूमिका में किए गए दूरदर्शिता-विहीन फैसलों की वजह से 3 साल बाद नई भूमिका में जा चुके व्यक्ति को दोष देने या सज़ा देने जैसी कोई बात नहीं होती
इसका यह मतलब नहीं कि Cutler खुद ऐसे executive थे। लेकिन उन पर ऊपर से आने वाला रिलीज़ का दबाव और revenue flow बनाए रखने का दबाव साफ़ तौर पर था। जैसा वह interview की शुरुआत में कहते हैं, उन्हें bugs के साथ ship करना सच में बहुत नापसंद है, industry के software engineers की quality से वे काफ़ी निराश हैं, और program/project managers का हर bug को कोई rare corner case मानना भी उन्हें बेहद नापसंद है। इन तीनों बातों से मैं सहमत हूँ
मैं जो ज़्यादातर bugs दर्ज करता हूँ, उन्हें भी “corner case” माना जाता है, लेकिन मैं उन्हीं समस्याओं से हर दिन टकराता हूँ, और database में उन पर कई duplicate issues भी होते हैं, या फिर मेरी bug report को पहले की रिपोर्ट का duplicate कहकर बंद कर दिया जाता है
इस industry में कई दशक, और वह भी पूरे Big Tech में बिताने के बाद, मैंने अब तक ऐसी कोई कंपनी नहीं देखी जहाँ engineers और first-line managers pre-release bug fixes के लिए ज़ोर लगाते हों, ज़्यादा frequent bug-fix updates माँगते हों, और फिर भी आख़िर में उसी तरह के pressure के आगे झुके बिना रह पाते हों
यह एक बड़ा selling point था, लेकिन ज़्यादातर users के लिए इसका असर खास नहीं था। वास्तव में कई लोगों को लगता था, “मुझे इसकी ज़रूरत ही क्यों है?” और इससे यह ऐसा दिखता था मानो यह “सामान्य users” के लिए बना operating system न हो
1990 के शुरुआती दशक का security concept — यानी security किसे कहते हैं और वह किसके लिए कितनी relevant है — आज की expectations या current state of the art से मेल नहीं खाता
इसे सही तरीके से बनाने में थोड़ा समय लग सकता है। तब तक बस यही उम्मीद है कि आधे-अधूरे, status-quo को मज़बूत करने वाले, regression जैसे single-runtime-based alternatives जीत न जाएँ
[0]: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
शायद software ने हमें जो सबसे बड़ा आर्थिक “योगदान” दिया है, वह यही है। यानी ऐसा बाध्यकारी contract जो कहता हो, “हम पैसे तो लेंगे, लेकिन कुछ भी वादा नहीं करते, बेवकूफ़ ग्राहक!”
उल्टा, बाज़ार में दूसरे नंबर पर आने पर सज़ा मिलती है
यह सब सुनने का इंतज़ार है
उस व्यक्ति या उसकी कंपनी के बारे में भावनाओं से अलग, Cutler OpenVMS और Windows NT पर अपने काम के ज़रिए बेहद प्रभावशाली software engineer रहे हैं। मुझे लगता है कि Bell Labs के लोग, Stallman, Linus, Stroustrup जैसे नामों की तरह उनका ज़िक्र उतनी बार नहीं होता