मेरे अजीब HP प्रिंटर के लिए macOS ड्राइवर लिखना, जो सिर्फ Windows के लिए बना था

मूल लेख ↗ Hacker News चर्चा ↗

Claude AI model का उपयोग करके एक Windows-only HP laser printer को macOS पर चलाने का एक प्रयोग इस बात पर व्यापक विचार-विमर्श छेड़ता है कि बड़े भाषा मॉडल unsupported hardware को कैसे फिर से उपयोगी बना सकते हैं—printers और scanners से लेकर game controllers और industrial devices तक। टिप्पणीकार AI का उपयोग करके protocols reverse-engineer करने, Linux या Windows drivers को adapt करने, और ऐसे niche tools बनाने के कई उदाहरण साझा करते हैं जिन्हें वे अकेले कभी बनाने का समय या विशेषज्ञता नहीं जुटा पाते। कुछ लोग इस marketing दावे पर सवाल उठाते हैं कि AI ने “driver लिख दिया”, जबकि वास्तव में उसने मौजूदा Linux components को wrap किया, और accuracy, security, energy use, तथा traditional low-level programming work के भविष्य को लेकर चिंताएँ जताते हैं.

मुख्य परिणाम

  • थ्रेड में एक LLM (Claude) का उपयोग करके USB-only HP/Samsung लेज़र प्रिंटर को macOS पर काम कराने पर चर्चा है, जबकि कोई vendor driver मौजूद नहीं था।
  • शुरुआती समाधान में HP के Linux “Unified Linux Driver” (ULD) component को Docker के अंदर पुनः उपयोग किया गया, और उसे macOS printing से जोड़ा गया।
  • आलोचना के बाद, प्रोजेक्ट को “पूरी तरह macOS native” सेटअप में अपडेट किया गया: Linux driver से rastertospl filter निकालना, उसे macOS के CUPS stack में जोड़ना, और साथ में एक छोटा USB bridge।

क्या यह सच में एक “Driver” है?

  • कुछ लोगों का तर्क है कि यह असली macOS driver नहीं, बल्कि एक existing Linux binary के ऊपर बनाया गया containerized या userland wrapper है।
  • दूसरे लोग जवाब देते हैं कि कोई भी software layer जो OS को hardware से बात कराने दे, driver ही कहलाता है, भले वह किसी और OS या binary को embed करे।
  • आलोचक headline/README को भ्रामक और एक marketing stunt मानते हैं; समर्थकों का कहना है कि मायने सिर्फ इतना रखता है: “printer पहले काम नहीं करता था, अब करता है।”

LLMs as Reverse-Engineering Tools

  • कई लोग ऐसी ही सफलता की कहानियाँ साझा करते हैं: निम्न चीज़ों के लिए drivers और tools लिखना या adapt करना:
    • Game controllers और extra buttons, MIDI interfaces, scanners, printers, BLE lamps, e-paper displays, golf cart controllers, USB cameras, label printers, audio/video apps, पुराने CAD formats, आदि।
  • आम pattern: specs, USB/Bluetooth captures, firmware dumps, या prior art देना; LLM फिर कई tedious steps के माध्यम से iterate करता है।
  • Reverse engineering को बार-बार LLMs के लिए एक “sweet spot” कहा गया है: अच्छी तरह specified, verifiable, और tedious।

Skepticism, Risk, and Tradeoffs

  • जिन चिंताओं को उठाया गया, उनमें शामिल हैं:
    • Security (root launchers, opaque code चलाना, containerized stacks)।
    • Maintainability और AI-generated fixes को upstream न करने की समस्या।
    • Overhyping: कभी-कभी समाधान मौजूदा projects या थोड़ी googling से भी मिल सकते थे।
    • Energy/resource tradeoffs बनाम बस नया printer खरीद लेना।
  • दूसरे लोग नोट करते हैं कि LLMs कठिन मामलों में अक्सर fail करते हैं या loop में फँस जाते हैं; सफलता की गारंटी नहीं है।

व्यापक विचार

  • चर्चा इन विषयों तक फैलती है:
    • Vendor lock-in और restricted hardware APIs (NFC, UWB, scanners, printers)।
    • यह उम्मीद कि AI custom tooling और “personal computing” को फिर से ज़्यादा वास्तविक बनाएगा।
    • low-level driver work के भविष्य को लेकर चिंताएँ, लेकिन पुराने hardware को फिर से जीवित करने को लेकर उत्साह भी।