ปรับปรุงไดรเวอร์เคอร์เนลอายุ 25 ปีให้ทันสมัยด้วย Claude Code

 (dmitrybrant.com)
15 คะแนน โดย GN⁺ 2025-09-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ไดรเวอร์ ftape เป็นไดรเวอร์เคอร์เนลโอเพนซอร์สของลินุกซ์เพียงตัวเดียวที่สามารถกู้คืนข้อมูลจากเทปสำรอง (QIC-80) ยุค 1990 ได้
  • แต่ไดรเวอร์นี้ ไม่ได้รับการบำรุงรักษา อีกต่อไปหลังปี 2000 ทำให้ใช้งานได้เฉพาะบนสภาพแวดล้อมลินุกซ์รุ่นเก่าเท่านั้น
  • ผู้เขียนใช้ Claude Code รีแฟกเตอร์ซอร์สโค้ดเก่าให้เข้ากับ เคอร์เนลลินุกซ์ รุ่นใหม่ และ แปลงสำเร็จ ให้เป็นโมดูลเคอร์เนลแบบแยกอิสระ
  • ระหว่างกระบวนการ Claude ได้แปลง ฟังก์ชันและโครงสร้างข้อมูลแบบเก่า ไปเป็น API รุ่นใหม่โดยอัตโนมัติ ขณะที่ผู้ใช้วิเคราะห์ผลลัพธ์ด้วยตนเองเพื่อแก้ไขความผิดพลาดของการตั้งค่าบางส่วน
  • ประสบการณ์การใช้ AI coding agent ครั้งนี้ให้มุมมองเกี่ยวกับ การขยายขีดความสามารถของโปรแกรมเมอร์ และการ onboarding เข้าสู่เทคโนโลยีหรือเฟรมเวิร์กใหม่ได้อย่างรวดเร็ว

เบื้องหลัง: การกู้คืนเทปสำรองเก่าและไดรเวอร์ ftape

  • หนึ่งในงานอดิเรกของผู้เขียนคือการกู้คืนข้อมูลจาก ตลับเทป เช่น QIC-80
  • เทปเหล่านี้ส่วนใหญ่ต้องใช้ เทปไดรฟ์แบบพิเศษ ที่เชื่อมต่อกับฟลอปปีดิสก์คอนโทรลเลอร์
    • ไดรฟ์เหล่านี้มักถูกใช้เพื่อการสำรองข้อมูลโดยธุรกิจขนาดเล็กหรือผู้ใช้ตามบ้านในช่วงทศวรรษ 1990
    • วิธีที่ใช้ฟลอปปีดิสก์คอนโทรลเลอร์นั้นทำได้ในต้นทุนต่ำโดยไม่ต้องมี SCSI adapter แยก แต่ก็มีข้อเสียหลายอย่าง เช่น ข้อจำกัดด้านความเร็ว (500Kbps) และโปรโตคอลที่ไม่เป็นมาตรฐาน
  • ในการสื่อสารกับอุปกรณ์เทปเหล่านี้ บนลินุกซ์จำเป็นต้องมี ไดรเวอร์เคอร์เนล ftape
    • เนื่องจากมีเพียง ftape เท่านั้นที่สามารถอ่านข้อมูลไบนารีดิบได้โดยตรง จึงจำเป็นต่อการกู้คืนข้อมูล
  • อย่างไรก็ตาม ไดรเวอร์ ftape ไม่ได้รับการบำรุงรักษาอีกเลยหลังราวปี 2000 ทำให้ไม่สามารถใช้งานบนเคอร์เนลลินุกซ์สมัยใหม่ได้
    • ดังนั้นทุกครั้งที่ต้องการกู้ข้อมูล ผู้เขียนจึงต้องบูตลินุกซ์รุ่นเก่าโดยตรง (เช่น CentOS 3.5)

เริ่มปรับปรุงไดรเวอร์เคอร์เนลให้ทันสมัยด้วย Claude Code

  • ผู้เขียนขอให้ Claude Code พร้อมคำอธิบายของรีโพซิทอรีว่าให้ "ปรับปรุงไดรเวอร์ให้สามารถ build ได้บนเคอร์เนลรุ่นใหม่"
  • Claude ค้นหาและแทนที่ ฟังก์ชันและโครงสร้างข้อมูลแบบเก่า ให้สอดคล้องกับ API และโครงสร้างของเคอร์เนลปัจจุบัน
    • หลังผ่านการให้ฟีดแบ็กหลายรอบและการปรับแก้ด้วยตนเอง ก็ได้โค้ดไดรเวอร์ที่คอมไพล์ได้โดยไม่มีข้อผิดพลาด
  • โค้ดในช่วงแรกยัง build ได้เฉพาะภายในซอร์สทรีของเคอร์เนลทั้งหมด แต่เมื่อมีการร้องขอเพิ่มเติม Claude ก็สร้าง ระบบ build สำหรับ external module แบบแยกอิสระ ให้โดยอัตโนมัติ
    • ทำให้สามารถสร้างโมดูลเคอร์เนลเป็นไฟล์ .ko แยกต่างหากได้ และเริ่มทดสอบกับฮาร์ดแวร์จริง

กระบวนการแก้ปัญหา

  • แม้โมดูลเคอร์เนลจะโหลดได้ตามปกติ แต่กลับเกิด ปัญหาเรื่องการตรวจพบไดรฟ์และการสื่อสาร
    • งานที่ต้องใช้สิทธิ์ sudo ทำให้ Claude ไม่สามารถรันซ้ำเองได้โดยตรง ผู้เขียนจึงส่ง dmesg log ให้ด้วยตนเองเพื่อติดตามปัญหา
  • จากการเทียบ log กับกรณีที่เคยสำเร็จ Claude พบข้อบกพร่องเกี่ยวกับ การไม่ได้ตั้งค่า I/O port address เริ่มต้น และการกำหนดค่าเริ่มต้นของพารามิเตอร์
    • ค่าเริ่มต้นถูกแปลงจาก -1 เป็น 0xffff จนตรวจจับไม่สำเร็จ และเมื่อรีเซ็ตเป็น address ที่ถูกต้องก็แก้ปัญหาได้
  • ในที่สุดโมดูลก็โหลดได้สมบูรณ์ และ dump ข้อมูลจากเทปทดสอบได้สำเร็จ

ข้อสังเกตจากประสบการณ์ทำงานร่วมกับ AI coding agent

  • การโต้ตอบกับ Claude Code ให้ความรู้สึกเหมือน "การทำงานร่วมกับนักพัฒนาระดับจูเนียร์" คล้ายกับการทำงานกับวิศวกรจริง
    • ผู้ใช้ยังคงต้องเป็นผู้นำในการตัดสินใจด้านสถาปัตยกรรม การค้นหาปัญหา และการกำหนดทิศทาง
  • ยิ่งใช้ คีย์เวิร์ดที่เฉพาะทางตามโดเมน และคำขอที่ชัดเจน ก็ยิ่งได้ผลดี
  • AI agent จะเพิ่มผลิตภาพอย่างมากเมื่อได้รับ งานในประเภทที่เหมาะสม จึงต้องเข้าใจทั้งข้อจำกัดและจุดแข็งของมัน
  • AI ช่วยเพิ่มความสามารถของผู้เขียนได้อย่างมาก งานที่ถ้าทำด้วยมือล้วน ๆ อาจใช้เวลาหลายสัปดาห์ กลับเสร็จได้ในไม่กี่วันผ่านการสนทนาและฟีดแบ็กตามปกติ
    • ในกระบวนการนี้ ผู้เขียนยังได้เรียนรู้ทักษะที่ใช้งานได้จริง เช่น แนวปฏิบัติการพัฒนาเคอร์เนลสมัยใหม่, สถาปัตยกรรม x86, เครื่องมือ command line แบบใหม่
  • ผู้เขียนเน้นว่า AI ช่วยเร่ง กระบวนการ onboarding และการปรับตัวช่วงเริ่มต้น กับเฟรมเวิร์กใหม่ ๆ (เช่น Rust, Flutter) ได้อย่างมาก

บทสรุป: ftape กลับมามีชีวิตอีกครั้ง

  • หลังผ่านไป 25 ปี ftape ก็กลับมา build และใช้งานได้บนลินุกซ์รุ่นใหม่ อีกครั้ง
  • ผู้เขียนกำลังดำเนินการปรับปรุงฟีเจอร์เพิ่มเติมและทดสอบต่อเนื่อง อีกทั้งยังยืนยันการรองรับ อุปกรณ์ที่ใช้พอร์ตขนาน นอกเหนือจากไดรฟ์ที่ใช้ฟลอปปี
  • ตัวอุปกรณ์จริงแทบไม่ต่างจากในอดีต แต่ระบบปฏิบัติการเปลี่ยนจาก CentOS 3.5 มาเป็น Xubuntu 24.04

อ้างอิง

  • ซอร์สโค้ดของโปรเจกต์ ftape เปิดเผยบน GitHub
  • รายการอุปกรณ์สะสมของผู้เขียนและรายละเอียดอื่น ๆ สามารถดูได้จากบล็อกส่วนตัว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-09-08
ความคิดเห็นบน Hacker News

  • ผมโหลดโมดูลด้วยตัวเองแล้วก็คัดลอกเอาต์พุตจาก dmesg ไปแปะให้ Claude แบบแมนนวลซ้ำๆ
    หนึ่งในเหตุผลหลักที่ผมใช้ Claude เป็นหลักก็คือ มันสามารถเริ่มโปรเซสที่ใช้เวลานาน แล้วอ่านเอาต์พุตเพื่อนำไปดีบักต่อได้
    ตรงนี้มีวิธีแฮ็กหลายแบบที่จะข้ามขั้นตอนที่ต้องทำเองได้—เช่น pipe dmesg ไปยังพอร์ต UDP ภายในเครื่อง แล้วให้ Claude เปิด listener ขึ้นมา

  • ผมคิดว่านี่เป็นกรณีศึกษาที่ดี
    ผมมองว่าเวลาใช้เครื่องมือแบบนี้ เราจะได้ผลหลักๆ สองอย่าง
    อย่างแรกคือ ในเฟรมเวิร์กที่ผมคุ้นเคยอยู่แล้ว Claude จะจับแพตเทิร์นงานซ้ำๆ ได้เร็วมาก ทำให้ผลิตภาพเพิ่มขึ้นมหาศาล
    อย่างที่สองคือ ตอนต้องเรียนรู้เฟรมเวิร์กใหม่ ก็ onboard ได้เร็วขึ้นมาก—จุดนี้มีประโยชน์มากเป็นพิเศษในบริษัทใหญ่ที่ใช้สแตกหลากหลาย
    ถ้าจะประเมินความสามารถของ AI ให้ถูกจริงๆ ต้องลงทุนเวลาไม่น้อยกับเทคโนโลยีและเฟรมเวิร์กที่เปลี่ยนเร็ว
    ถ้าคุณยังไม่ได้ใช้ Claude Code หรือ Claude 4.0 เกิน 100 ชั่วโมง คุณอาจยังไม่เห็นศักยภาพของมันเต็มที่
    สถานการณ์แบบ “คนที่ไม่ใช่โปรแกรมเมอร์ลองเขียนโค้ดแบบมั่วๆ แล้วเจอปัญหา” คงเป็นเรื่องปกติบน X (ชื่อเดิม Twitter) แต่ถ้าเป็นนักพัฒนาที่มีประสบการณ์และใช้มันอย่างต่อเนื่อง ประสบการณ์จะต่างออกไปมาก

    • นี่แหละคือประเด็นสำคัญ
      ผมใช้ Claude Code เป็นเครื่องมือหลักสำหรับแก้ไขโค้ดใน codebase เดิมทุกวันแบบไม่ขาด
      หลังจากลองผิดลองถูก ผมก็สร้างกระบวนการของตัวเองขึ้นมาได้ และมันช่วยเพิ่มทั้งผลิตภาพและความกล้าจะทำการทดลองขนาดใหญ่
      โดยเฉพาะถ้าผมออกแบบ data structure, schema และ internal API ไว้ก่อน Claude Code จะทำ UI ของเครื่องมือภายในออกมาได้ดีมากแทบจะจบในรอบเดียว
      มันทำให้ผมกลับไปคิดในระดับนามธรรมได้ โดยไม่ต้องจมกับงานซ้ำๆ หรือความซับซ้อนของเฟรมเวิร์ก และกลายเป็นจุดเปลี่ยนครั้งใหญ่ในอาชีพ 16 ปีของผม

    • ใช่เลย
      เจ้าของโพสต์ก็คือสั่งให้ Claude ช่วยพอร์ตไดรเวอร์ Linux 2.4 ไปเป็น 6.8
      เพราะมีข้อมูลที่เกี่ยวข้องอยู่บนอินเทอร์เน็ตมากพอ งานส่วนใหญ่เลยเป็นสิ่งที่ Claude จัดการได้ และความเชี่ยวชาญของเจ้าของโพสต์จำเป็นจริงๆ ก็เฉพาะในส่วนแกนหลักที่ซับซ้อนมากเท่านั้น
      คำว่า “ใช้ AI เป็นเครื่องมือขยายทักษะของตัวเองแบบก้าวกระโดด” ฟังแล้วเข้าท่ามาก
      แต่ถ้าความสามารถตั้งต้นของคุณเป็น 0 ต่อให้คูณด้วย AI ก็ยังเกือบเป็น 0 หรืออาจติดลบในแง่ผลิตภาพด้วยซ้ำ

    • ในทีมเราก็มีคนที่กล้าลองของใหม่ผ่าน LLM เหมือนกัน แต่ถึงจะให้ทุกคนใช้ Claude 4 thinking agent ก็ยังได้โค้ดแปลกๆ ออกมาเยอะมาก
      ถ้าคุณใช้ชีวิตการเขียนโค้ดส่วนใหญ่ไปกับการจับแพตเทิร์น LLM agent ก็เหมือนเข้ามาจับแพตเทิร์นทับอีกชั้นหนึ่ง ซึ่งสำหรับสมาชิกทีมที่ไม่มีประสบการณ์แบบนั้นกลับกลายเป็นเรื่องปวดหัว
      LLM agent ทำการจับแพตเทิร์นแบบที่มนุษย์ทำได้เร็วกว่าเยอะ แต่โดยรวมแล้วผมยังไม่คิดว่ามันเก่งกว่ามนุษย์แบบทั่วไปนัก

    • มันมีประโยชน์ไม่ใช่แค่กับการสำรวจเฟรมเวิร์กใหม่ แต่รวมถึงภาษาใหม่ด้วย
      ทีมเราใช้ Ruby ซึ่งอ่านง่ายมาก จนไม่จำเป็นต้องเรียนไวยากรณ์จริงจังก็สามารถสั่งให้ LLM เขียนโค้ด แล้วเราเป็นคนตัดสินใจเองได้
      ต่อให้ไม่รู้ Ruby ก็ยังเขียนโค้ดให้อยู่ในระดับที่ทีมยอมรับได้ทันที ทำให้ทำงานได้อย่างมีประสิทธิภาพตั้งแต่แรกแม้อยู่ในสภาพแวดล้อมที่ไม่คุ้นเคย
      (หมายเหตุ: สมาชิกในทีมจะรีวิว Pull Request)

    • ประโยคที่ว่า “เครื่องมือขยายทักษะของตัวเองแบบก้าวกระโดด” นี่ผมเพิ่งรู้สึกชัดมากในสัปดาห์นี้ ตอนทำโปรเจ็กต์เล็กๆ แบบเดิมซ้ำ 10 รอบ
      จุดที่มันแสดงพลังจริงๆ คือการที่ AI ทำของกระจัดกระจายออกมา แล้วผมใส่แนวทางกำกับเพื่อรวมมาร์กอัป สไตล์ และ JS ให้เป็นระเบียบขึ้น (consolidation)
      ในสภาพแวดล้อมอย่างสตาร์ตอัปที่ coding convention ยังไม่แข็งแรง การขอให้มันจับแพตเทิร์นตามที่ต้องการอาจทำได้ยาก แต่ผมนึกภาพออกเลยว่าใน codebase ที่แข็งแรงและเติบโตเต็มที่ ผลลัพธ์จะต่างไปมาก

  • ผมคิดว่าควรเขียนพรอมป์ต์ให้เฉพาะเจาะจงที่สุดเท่าที่จะทำได้ โดยใช้คีย์เวิร์ดเชิงโดเมนให้มาก
    ถ้าคุณขาดความเข้าใจเชิงเทคนิคในภาษาหรือเฟรมเวิร์กนั้นๆ พรอมป์ต์จะคลุมเครือ และ LLM จะเติมช่องว่างนั้นเอง ทำให้ผลลัพธ์ออกมาคลาดจากความตั้งใจได้ง่าย
    ความคลุมเครือนี่แหละคือต้นตอของบั๊ก
    มันคืออีกด้านหนึ่งของ “การขยายแบบก้าวกระโดด”

    • ถ้าคุณแค่พูดว่า “คลาส C ต้องมี tuple constructor” ผมก็หวังว่า Claude จะตอบว่า “เดี๋ยวก่อนนะ…”

  • เวลาอ่านบทความแบบนี้ มันทำให้ผมนึกได้ว่าก่อนมี LLM งานที่ต้องการทำจริงๆ มีมากกว่างานที่ถูกทำสำเร็จอยู่มาก

    • ผมยังคิดว่าคอขวดไม่ใช่เรื่อง ‘การลงมือทำ’ แต่เป็น ‘ไอเดียที่ขายได้ในตลาด’ มากกว่า
      งานที่คนยอมควักเงินจริงๆ มีไม่มากนัก

    • ปัญหาไม่ได้มีแค่งานไม่พอเสมอไป แต่เป็นเพราะคนที่มีทักษะและประสบการณ์นำหน้าซึ่งจำเป็นต่องานนั้นมีน้อย
      ถ้าไม่มีประสบการณ์พัฒนาเคอร์เนล ต่อให้เขียนพรอมป์ต์เก่งแค่ไหน ก็คงยากจะได้ผลแบบเดียวกับเจ้าของโพสต์
      ในทางทฤษฎี ดูเหมือนพลังของ LLM จะทำให้ “ทำให้ไดรเวอร์เก่าทั้งหมดทันสมัย” บนเคอร์เนลใหม่ได้ แต่ในความเป็นจริงจำเป็นต้องมีการกำกับดูแลโดยมนุษย์ที่มีทักษะเสมอ และจำนวนผู้เชี่ยวชาญแบบนี้ก็น้อยมากเมื่อเทียบกับจำนวนไดรเวอร์ที่ต้องดูแล
      มีบทสนทนาและบทสัมภาษณ์ที่ดี ของ Alan Kay และ Joe Armstrong ซึ่งพูดถึงปัญหาที่เกิดจากการที่โค้ดส่วนใหญ่ไม่ได้ถูกพัฒนาขึ้นมาในลักษณะที่สามารถเปลี่ยน target แล้วคอมไพล์ใหม่ได้โดยไม่มีสเปกกำกับ
      ถ้ามีสเปกอย่างเป็นทางการแยกจากตัวโค้ด งานย้ายไดรเวอร์ไปยังเคอร์เนล target ใหม่ก็คงง่ายขึ้นในลักษณะของ “คอมไพล์สเปกใหม่”
      แต่ตอนนี้เราไม่ได้อิงจากสเปก เราอิงจากโค้ดเก่า ดังนั้นในกระบวนการย้ายโค้ดเดิมไปเป็นโค้ดสมัยใหม่ LLM ก็ทำได้เพียงจับแพตเทิร์นของโค้ดที่คล้ายกัน ไม่ได้เข้าใจความหมายจริงหรือรับประกันความถูกต้องได้—เพราะงั้นทักษะของมนุษย์จึงยังจำเป็นเสมอ

  • ผมเคยรู้สึกว่า AI จะช่วยลดกำแพงการเข้าสู่โลก kernel hacking
    และทุกครั้งก็ยิ่งรู้สึกว่านี่เป็นความจริง
    อีกไม่นานการรองรับฮาร์ดแวร์ embedded/ARM อาจกว้างขวางขึ้น และเราอาจได้เห็น OS ใหม่สำหรับอุปกรณ์อัจฉริยะขนาดเล็กที่เบามากด้วย

    • ถ้าใช้ AI ได้ดี คุณสามารถยกระดับฝีมือได้เร็ว
      แต่คนส่วนใหญ่มักไปขอให้ AI ‘สร้างบ้านทั้งหลังให้’ ทั้งที่จริงแล้วใช้มันเป็น ‘ตัวช่วยตีตะปู’ จะได้ผลดีกว่า

  • ผมคิดว่านี่เป็นตัวอย่างที่ดีของนักพัฒนาที่เข้าใจทั้งบทบาทและข้อจำกัดของ AI และใช้งานมันได้เหมาะสม
    โดยเฉพาะความ skepticism (มุมมองเชิงวิพากษ์) ที่ทำให้เขาแยกไดรเวอร์ออกมาเป็นโมดูลต่างหากนั้นน่าประทับใจมาก

  • ผมอยากชี้ “เบาะแสสำคัญ” อย่างหนึ่งที่คนอื่นยังไม่ได้พูดถึง
    เจ้าของโพสต์บอกไว้อย่างชัดเจนว่า “ผมมีประสบการณ์กับ kernel module อยู่บ้าง และใช้ภาษา C ได้ดี ดังนั้นไม่ควรอวยผลลัพธ์ของ Claude เกินจริง”
    นั่นหมายความว่ามันไม่ใช่การถามแค่สามครั้งแล้ว kernel module เสร็จเลยจริงๆ แต่มีการโต้ตอบหลายรอบและแก้โค้ดด้วยมือตัวเองหลายครั้ง
    เขาบอกด้วยว่าถ้าไม่เข้าใจโครงสร้างภายในพื้นฐานของ kernel module ก็คงไม่มีทางทำให้มันทันสมัยได้เลย—นี่คือบริบทที่ต้องจำให้ขึ้นใจ ไม่ว่าจะใช้เครื่องมือสร้างโค้ดแบบไหนก็ตาม
    อีกอย่างคือเขาเขียนว่าความรู้สึกในการร่วมงานกับ Claude Code “คล้ายกับการทำงานกับวิศวกรจูเนียร์” คือสั่งอะไรก็ทำให้หมด แล้วถ้าชี้ข้อผิดพลาดก็ขอโทษหรือชมกลับทันที ซึ่งฟังดูเหมือนสไตล์ประจบมากกว่าจะเป็นวิศวกรจริงๆ
    สุดท้าย เจ้าของโพสต์ยังบอกว่า “ถ้าอยากทำจริงๆ ผมก็ทำงานนี้คนเดียวได้ แต่คงต้องกลับไปเรียนรู้วิธีพัฒนาเคอร์เนลเมื่อ 25 ปีก่อนใหม่”
    ตรงนี้ย้ำอีกครั้งว่าแก่นของงาน modernization ก็คือ “เข้าใจ legacy solution ให้ถูกต้อง และรู้ว่าอะไรคือสิ่งที่จำเป็น”
    ที่สำคัญ การที่ “ไม่ต้องเรียนรู้แล้วข้ามไปได้” ถูกมองว่าเป็นข้อดีก็น่าสนใจมากเช่นกัน

    • ท่าทีแบบแบ่งพวกเฝ้าประตู (gatekeeping) เป็นเรื่องไม่ดี
      ผมรู้สึกว่ามันดีมากที่ agent สามารถอธิบายโปรเจ็กต์ที่ผมไม่รู้จักให้ผมเข้าใจได้
      ไม่นานมานี้ผม clone ซอร์สของ Firefox แล้วใช้ qwen-code ถามเกี่ยวกับฟีเจอร์ AI ของ Firefox และวิธีที่มันถูก implement ซึ่งได้เรียนรู้อะไรเจ๋งๆ มากจริงๆ
      วิธีการเรียนรู้ตอนนี้เจ๋งขึ้นเยอะมาก

  • ผมคิดว่านี่คือการเปลี่ยนแปลงที่ช่วยเพิ่มพลังให้ผู้คนมากขึ้น
    เจ้าของโพสต์ทำ side project ด้วยความหลงใหลมาอย่างยาวนาน และการอัปเกรดเครื่องมือก็เป็นเรื่องที่ดีมาก
    แต่ถ้าสาขานั้นเฉพาะทางเกินไป ชุมชนอาจช่วยสนับสนุนได้น้อย ซึ่งตรงนี้ LLM เข้ามาช่วยแก้ปัญหาเฉพาะทางที่ปรับแต่งเองได้
    กำแพงการเข้าถึงกำลังลดลงเรื่อยๆ และในอนาคต แม้แต่คนที่มีพื้นฐานเทคนิคน้อยกว่าก็อาจแก้ปัญหาเฉพาะทางที่ง่ายกว่านี้ได้ด้วยตัวเอง
    นี่เป็นการเปลี่ยนแปลงเชิงบวกที่ทำให้มีคนกล้าลองมากขึ้น

  • ผมสงสัยว่าหลังอัปเกรดแล้วความเร็วเปลี่ยนไปอย่างไรบ้าง

    • ก็ควบคุมฮาร์ดแวร์ตัวเดิมด้วยไดรเวอร์ตัวเดิม ดังนั้นความเร็วก็น่าจะเท่าเดิม