Ask HN: มีโปรเจกต์ไหนบ้างที่ถูกยุติหรือปิดตัวเร็วเกินไป? เพราะอะไร?

• คำถามและคำตอบเกี่ยวกับโปรเจกต์ที่หายไปเพราะมาก่อนกาล หรือเพราะตลาดยังไม่พร้อม

  แค่อยากรู้เฉย ๆ น่ะ ใครจะไปรู้ว่าใครจะนำมันไปใช้ หรือจะมีใครพัฒนาสิ่งใหม่จากไอเดียนี้ต่อยอดบ้าง

---

ระบบปฏิบัติการ Plan 9

• ระบบปฏิบัติการแบบกระจายของ Bell Labs ที่เคยถูกมองว่าเป็น ทายาทตัวจริงของ Unix แต่ล้มเหลวในการทำเชิงพาณิชย์

  • ขยายปรัชญา "ทุกสิ่งคือไฟล์" ไปสู่ การแชร์ผ่านเครือข่าย ด้วยการออกแบบที่ล้ำสมัย
  • มี ฟีเจอร์ UI ที่เป็นเอกลักษณ์ เช่น mouse coding, nested window manager, Plumber
  • เหมาะอย่างยิ่งกับ สภาพแวดล้อมแบบกระจาย ที่เชื่อมมือถือ เดสก์ท็อป คลาวด์ และ IoT แต่กลับไม่ถูกรับไปใช้

• สาเหตุของความล้มเหลว

  • วงการอุตสาหกรรมเมินเพราะ ปัญหาไลเซนส์ และคดีความ
  • ไม่สอดคล้องกับช่วงเวลาที่คอมพิวเตอร์แบบรวมศูนย์กำลังเสื่อมลง และ คอมพิวเตอร์ส่วนบุคคลกำลังผงาดขึ้น
  • ถูกวางตำแหน่งให้เป็นเพียงระบบปฏิบัติการเพื่อการวิจัย จึง ไม่สามารถฉวยโอกาสจากยุค .com บูมได้
  • Bell Labs ถูก ขายต่อหลายครั้ง หลังรายได้จากธุรกิจโทรศัพท์ของ AT&T ลดลง
  • Version 3 เคย ขายในราคา $350 ต่อเครื่อง แต่ใช้ได้เฉพาะงานที่ไม่ใช่เชิงพาณิชย์
  • จนถึงปี 2004 ก็ยัง ไม่ได้เปิดเป็นโอเพนซอร์สอย่างแท้จริง

• มรดกที่ทิ้งไว้

  • โปรโตคอลระบบไฟล์ 9P ยังคงถูกใช้ใน WSL2, ระบบนิเวศ VM และ Kubernetes
  • มีโปรเจกต์ฟอร์กที่ ยังคึกคัก อย่าง 9front
  • Plan 9 Foundation กำลังดูแล โค้ดโอเพนซอร์สและสิทธิ์ต่าง ๆ

โปรเจกต์ที่ตายไปของ Google

• ประสบการณ์จากผู้ใช้ที่ จากเดิมใช้ผลิตภัณฑ์ Google 30~40 ตัว เหลือเพียง 3~4 ตัว

  • Google Picasa: เครื่องมือจัดการภาพถ่ายแบบโลคัลที่ เร็วและดีมาก
  • Google Hangouts: เหยื่อของ กลยุทธ์แอปแชตที่สับสน
  • G Suite Legacy: ยกเลิกคำสัญญา "ฟรีตลอดไป" แล้วเปลี่ยนเป็นแบบเสียเงิน
  • Play Music: เคยอัปโหลดไฟล์ MP3 หลายพันไฟล์ แต่เมื่อบริการปิดก็เกิด การสูญเสียข้อมูล
  • Google Finance: เคยมีฟีเจอร์ติดตามหุ้น แต่ถูกยกเลิก
  • Google NFC Wallet: Apple ครองตลาดด้วยฟีเจอร์เดียวกัน
  • Chromecast Audio: แม้ ทำหน้าที่เดียวได้ดีมาก แต่ก็ถูกยกเลิก

• Google Reader: การตัดสินใจทางธุรกิจที่แย่ที่สุดครั้งหนึ่งในประวัติศาสตร์

  • ทั้งที่เป็นบริการที่ระยะยาวแล้ว แทบไม่ต้องบำรุงรักษามาก แต่กลับถูกปิด
  • มีฐานผู้ใช้ที่ทรงอิทธิพลจำนวนมาก เช่น ผู้ก่อตั้ง, CTO, VP of Engineering
  • ทิ้งบทเรียนให้ทั้งวงการว่า อย่าเชื่อใจผลิตภัณฑ์ของ Google
  • การปิดบริการสะท้อนวัฒนธรรมองค์กรที่วัดผลงานจากการ ประหยัดเงินได้หลายล้านดอลลาร์

Adobe Flash / Macromedia Flash

• แพลตฟอร์มสร้างสื่อมัลติมีเดียที่ แม้ผ่านไป 15 ปีแล้วก็ยังไม่มีเครื่องมือไหนมาแทนได้จริง

  • ทำเกมและงานมัลติมีเดียได้ ง่ายเหมือนต่อบล็อก Lego
  • มีชุดเครื่องมือที่ใช้งานเข้าใจง่ายอย่าง MovieClip และไทม์ไลน์แอนิเมชัน
  • แม้จะถูกแทนที่ด้วย HTML Canvas แต่ คุณภาพของเครื่องมือยังเทียบกันไม่ได้

• เหตุผลที่ iPhone ฆ่า Flash

  • ฮาร์ดแวร์ในปี 2007 มี ปัญหาด้านประสิทธิภาพและกินแบตเตอรี่มาก
  • Flash อาจกลายเป็น ทางลัดหลบระบบนิเวศแอป
  • มีความเสี่ยงที่จะทำให้ iPhone ถูกมองว่าเป็น "สินค้าขยะ"

• สถานการณ์ปัจจุบัน

  • Adobe Animate รองรับ การส่งออกแบบ JS/Canvas แต่ไม่เหมือนต้นฉบับ
  • มีอีมูเลเตอร์อย่าง Ruffle ที่รันคอนเทนต์เก่าบางส่วนได้
  • Roblox ทำหน้าที่ คล้ายกันอยู่บ้าง แต่ก็จำกัดกว่าและเป็นเชิงพาณิชย์มากกว่า

โปรเจกต์ที่ล้มเหลวของ Microsoft

• Silverlight: เว็บปลั๊กอินที่ใช้ C#

  • ใช้ C# เต็มรูปแบบแทน JavaScript ได้
  • มี UI แบบ vector-based ที่รับรู้ DPI, pattern แบบ MVVM และการ bind สองทาง
  • เปิดทางให้ นักออกแบบและนักพัฒนาทำงานร่วมกัน ผ่าน Expression Blend
  • เรนเดอร์ได้ เหมือนกันทุกประการในทุกเบราว์เซอร์
  • iPhone ทำให้ Silverlight ล่มสลายไปพร้อมกับ Flash

• Midori: ระบบปฏิบัติการความปลอดภัยแบบ capability-based

  • พัฒนาไปไกลถึงขั้นรันโค้ด Windows ได้ แต่ ถูกยุติเพราะการเมืองภายใน
  • ผลงานวิจัยจำนวนมากถูก ผนวกรวมเข้าไปใน .NET
  • มีคนมากกว่า 100 คนถูกใส่เข้าไปในโปรเจกต์นี้ในฐานะ โครงการรักษาพนักงานเก่ง ๆ ไว้

อื่น ๆ

• Copland ของ Apple (ต้นแบบ MacOS 8)

  • MacOS รุ่นทันสมัยที่ ไม่มีบรรทัดคำสั่ง
  • มีฟีเจอร์ที่ อาจทำให้การเปลี่ยนผ่านสู่มือถือทำได้ง่ายขึ้น
  • เปิดตัวไม่ได้เพราะ ฟีเจอร์บวม และความไม่เสถียร
  • มีข่าวลือว่าถูก จงใจทิ้ง เพื่อสร้างความชอบธรรมให้การเข้าซื้อ NeXT ของ Apple

• Songsmith: สร้างดนตรีประกอบอัตโนมัติจากเมโลดี้

  • ตั้งแต่ปี 2009 ก็มีฟีเจอร์ ตรวจจับคอร์ดแบบเรียลไทม์และสร้างดนตรีประกอบ แล้ว
  • เป็น ผู้บุกเบิกของเครื่องมือดนตรี AI อย่าง Suno และ Udio ในปัจจุบัน
  • แม้วิดีโอโปรโมตที่ดูแคมป์จะทำให้มัน กลายเป็นมีม แต่เทคโนโลยีกลับยอดเยี่ยมมาก

การเสื่อมถอยของ Heroku

• ความสำเร็จมาจาก ความเรียบง่ายและความโฟกัส ในช่วงแรก

  • มี ภาษาเดียว, แพลตฟอร์ม deploy เดียว, ฐานข้อมูลเดียว
  • ลดความเหนื่อยล้าจากการต้องตัดสินใจให้เหลือน้อยที่สุด
  • ถ้ามี AI เมื่อ 15 ปีก่อน มันคงมีประสิทธิภาพมากขึ้นด้วย ข้อมูลการเรียนรู้ที่สม่ำเสมอ

• สาเหตุของความล้มเหลว

  • หลัง Salesforce เข้าซื้อ ก็เพิ่ม แบนเนอร์แบรนด์ขนาดใหญ่ จนผู้ใช้ไม่พอใจ
  • การมาของ Docker และ Kubernetes ทำให้ถูกแทนที่ได้
  • การ ยกเลิก free tier ทำให้ลูกค้าจำนวนมากหนีออกไป
  • มีปัญหาการ ใช้คอมพิวต์ฟรีในทางที่ผิด จากกระแสคริปโต

• สถานการณ์ปัจจุบัน

  • ผู้ใช้บางส่วนยังคง ใช้งานใน production
  • Vercel, Coolify และ Dokku มอบ ประสบการณ์คล้ายกัน

ReactOS - การทำ Windows NT ขึ้นใหม่

• แม้จะ พัฒนามาเกือบ 30 ปี แต่ก็ยังอยู่ในสภาพที่ใช้งานจริงไม่ได้

  • Wine + เคอร์เนล + ความเข้ากันได้ของไดรเวอร์อุปกรณ์ + เป้าหมายที่ขยับตลอดเวลา
  • ต่อให้ Windows 10 ใกล้หมดซัพพอร์ต ก็ยัง ไม่สามารถเป็นทางเลือกได้

• สาเหตุของความล้มเหลว

  • ซอร์สโค้ดของ Windows ไม่ได้มีเอกสารดีพอหรือเข้าใจได้ง่าย
  • ตามหลัก clean-room reverse engineering คนที่เคยเห็นโค้ด Windows จะร่วมพัฒนาไม่ได้
  • แม้ซอร์สโค้ด Windows XP จะรั่วออกมา ความคืบหน้าก็ยัง ช้าเหมือนเดิม
  • Wine, Proton และเทคโนโลยี virtualization กลายเป็น ทางเลือกที่ใช้งานได้จริงกว่า

Delphi และ Pascal

• ภาษาโปรแกรมที่ เหมาะกับการศึกษาอย่างยิ่ง

  • มี คอมไพเลอร์ที่เร็วมาก จึงเหมาะกับการเรียนรู้แบบลองผิดลองถูก
  • มี ระบบชนิดข้อมูลที่สะอาดเรียบร้อย (ไม่ซับซ้อนเท่า Rust)
  • ซื่อสัตย์ต่อการสอนแนวคิดพื้นฐานของการเขียนโปรแกรม โดย ไม่พึ่งฟีเจอร์เฉพาะทางของภาษา

• สถานการณ์ปัจจุบัน

  • Delphi ยัง ออกรุ่นต่อเนื่องถึงเวอร์ชัน 13
  • มี Lazarus เป็น ทางเลือกโอเพนซอร์ส
  • Python เข้ามา แทนในฐานะภาษาสำหรับการศึกษา แต่ระบบชนิดข้อมูลกลับชวนสับสน

ฮาร์ดแวร์ที่ล้ำหน้าแต่ล้มเหลว

• MicroChannel (IBM): สถาปัตยกรรมอุปกรณ์ต่อพ่วงแบบ channel-based

  • นำ แนวคิด channel ของเมนเฟรมมาสู่พีซี
  • สามารถรัน channel program แบบง่ายได้
  • ล้มเหลวในตลาดเพราะ ไลเซนส์แบบผูกขาด
  • แม้ปัจจุบันทุกระบบจะมีฟังก์ชันคล้ายกัน แต่ก็ยัง ไม่มีอินเทอร์เฟซที่เป็นหนึ่งเดียว

• Motorola 680x0: โปรเซสเซอร์ที่เกือบจะกลายเป็นรากฐานของยุคไมโครคอมพิวเตอร์

  • เปิดตัวในปี 1978 แต่ MMU ออกช้าเกินไปมาก
  • เคยเป็น หัวใจหลัก ของ Amiga และ Macintosh รุ่นแรก ๆ

• Optane persistent memory: เทคโนโลยีที่ลบเส้นแบ่งระหว่าง RAM กับ storage

  • สามารถ ทำให้โครงสร้างข้อมูลคงอยู่ถาวรได้โดยตรง
  • ไม่ต้องบูตหรือเปิดแอปใหม่ สามารถ กลับมาทำต่อจากจุดที่หยุดได้ทันที
  • แม้จะล้มเหลวเพราะ แพงเกินไป แต่ในเชิงเทคนิคถือว่าปฏิวัติมาก
  • สะท้อน ความอดทนที่ไม่พอของผู้ตัดสินใจทางธุรกิจ

• Lytro light-field camera: กล้องที่ปรับโฟกัสได้หลังถ่าย

  • เก็บ ข้อมูลทั้งหมด ไว้ก่อน แล้วค่อยตัดสินใจเรื่องโฟกัสภายหลัง
  • น่าจะเข้ากันได้อย่างสมบูรณ์กับ เทคโนโลยีสมัยใหม่ อย่าง Gaussian splat และ Meta Ray-Ban
  • แต่คุณภาพภาพยัง ไม่ถึงระดับที่ช่างภาพมืออาชีพต้องการ
  • น่าจะควรเล็งตลาด ของใหม่แปลก ๆ แบบ Polaroid/Instax มากกว่า

ข้อถกเถียงเรื่องเทคโนโลยีเว็บ

• ความล้มเหลวของ XHTML

  • พยายามแก้ความวุ่นวายของ HTML ด้วย การ parse แบบเข้มงวด
  • แต่ HTML5 กลับ ทำให้แม้แต่ความหมายของ HTML ที่เขียนผิดก็กลายเป็นมาตรฐาน
  • กฎของ Postel นั้นผิด: การ parse แบบผ่อนปรนก่อช่องโหว่ด้านความปลอดภัยและปัญหาความเข้ากันได้
  • หลักการ "หยุดที่ข้อผิดพลาดแรกแล้วแสดงข้อความผิดพลาด" น่าจะดีกว่า

• ข้อโต้แย้ง: เหตุผลจริงที่ XHTML ล้มเหลว

  • IE6 ไม่รองรับ application/xhtml+xml
  • จำเป็นต้องรองรับ IE6 นานเกือบ 15 ปี
  • JSX และ JSON ก็มี ไวยากรณ์เข้มงวด แต่ก็ยังประสบความสำเร็จ
  • ภาษาแบ็กเอนด์ทั้งหมดก็ใช้ ไวยากรณ์เข้มงวด
  • ปัญหา ไม่ใช่อุปสรรคในการเริ่มต้น แต่เป็นเรื่องการรองรับของเบราว์เซอร์

• ความจริงของ HTML

  • การ ใส่เครื่องหมายคำพูดของ attribute ผิด อาจทำให้ทั้งหน้าไม่เรนเดอร์
  • มันควรเป็นฟอร์แมตที่ คนทั่วไปก็เขียนได้
  • HTML คือ รูปแบบเอกสาร ไม่ใช่ชุดคำสั่ง
  • PDF, ZIP, CSV ก็อ่านไฟล์เสียหายได้ (เพราะข้อมูลสำคัญกว่าฟอร์แมต)

โซเชียลเน็ตเวิร์กและการสื่อสาร

• Google Wave: แสดงภาพอนาคตได้ แต่เป็นการปฏิวัติที่มาเร็วเกินไป

  • มี การแปลแบบเรียลไทม์ การรวมระบบส่งข้อความหลายแบบ และฟีเจอร์มากมาย
  • มันเป็น โอเพนซอร์สเต็มรูปแบบ
  • แต่ UI ที่ซับซ้อนเกินไปทำให้ "เธรดอัปเดตสดที่ซ้อนกันหลายชั้น" ดูล้นมือ
  • เคยรวมฟังก์ชันที่วันนี้กระจายอยู่ใน Slack, JIRA และอีเมลเข้าด้วยกัน

• Vine: วิดีโอสั้นที่มาก่อน TikTok

  • ตั้งแต่ปี 2013 ก็โตได้ในระดับ ใหญ่มากพอสมควร แล้ว
  • Twitter หยุดมันเพราะ ไม่รู้จะทำรายได้อย่างไร
  • TikTok เปิดตัวเพียง ไม่กี่เดือนหลัง Vine ปิด
  • ทั้งที่แค่ใส่ แบนเนอร์โฆษณาในวิดีโอสี่เหลี่ยมจัตุรัส ก็พอแล้ว แต่กลับพลาดโอกาส

• Skype: วิดีโอคอลที่แม้แต่คุณย่าก็ใช้ได้

  • ง่ายเหมือนโทรศัพท์ แต่ถูกกว่าการโทรต่างประเทศ
  • เคยเป็นซอฟต์แวร์ P2P ที่ยอดเยี่ยมที่สุด
  • ถูกแทนที่อย่าง น่าผิดหวัง ด้วย Microsoft Teams
  • ตั้งค่าฮาร์ดแวร์ภายนอกยาก, มี ปัญหาความเข้ากันได้, และไม่มีบริการทดสอบเสียงแบบเดิมแล้ว

ระบบปฏิบัติการ

• Maemo/MeeGo: โมบายล์ลินุกซ์ที่ Nokia ควรผลักดัน

  • N9 เป็นอุปกรณ์ที่ยอดเยี่ยม แต่กลับออกมาแค่รุ่นเดียว
  • มีครบทั้ง แฮ็กได้, ดูดี, ปลอดภัย
  • ทุกวันนี้มันอาจกลายเป็นหนึ่งในสองโมบายล์ลินุกซ์กระแสหลักที่ ไม่ใช่ Android หรือ iOS ก็ได้
  • ยังมี บางส่วนสืบต่อไปใน Sailfish OS

• BeOS: ระบบปฏิบัติการที่ปรับให้เหมาะกับมัลติมีเดีย

  • แค่ต้องเลื่อนลงไกลกว่าจะเจอการพูดถึง BeOS และ Amiga ก็น่าประหลาดใจแล้ว
  • กำลังมีการทำใหม่แบบ from-scratch ในชื่อ Haiku OS
  • เร็วและตอบสนองไวอย่างเห็นได้ชัด กว่า Linux+X+Qt+KDE

• OS/2: โศกนาฏกรรมที่เกิดจากความร่วมมือของ IBM กับ Microsoft

  • เป็นระบบที่มี API ยอดเยี่ยม
  • หากเปิดซอร์ส Workplace Shell และโค้ด SOM ก็อาจถูกนำไปใช้กับระบบปฏิบัติการอื่นได้
  • ถูกใช้งานใน ตู้ ATM ของธนาคาร อยู่ยาวนานโดยไม่ถูกแฮ็ก

เครื่องมือพัฒนา

• Quartz Composer: การเขียนโปรแกรมเชิงภาพแบบ node-based ของ Apple

  • เป็นสภาพแวดล้อม visual programming แบบ patch-based
  • การมอนิเตอร์อุปกรณ์ USB ทำได้ด้วย เพียง 3 โหนด
  • หลังปี 2016 ก็ หยุดอัปเดต และใน OS รุ่นใหม่ หลายโหนดพังไปแล้ว
  • ควรถูกประเมินใหม่จากความนิยมของ การเขียนโปรแกรมแบบ node-based ใน Blender และ Unreal Engine

• Atom code editor: ตัวที่เกือบเป็นทางเลือกแทน VS Code

  • เป็น ทางเลือกกระแสหลัก ที่ GitHub สร้างขึ้น
  • หลัง Microsoft เข้าซื้อ GitHub ชะตาของ Atom ก็แทบถูกตัดสินแล้ว
  • เป็นโปรเจกต์ ต้นกำเนิดของ Electron
  • นักพัฒนาชุดเดิมกำลังพัฒนา Zed editor อยู่

• Non DAW: DAW ที่แยกตามหน้าที่

  • แยกแต่ละฟังก์ชันเป็น แอปพลิเคชันอิสระ
  • เวลาใช้เฉพาะสิ่งที่ต้องการ ก็ ไม่ถูกรบกวนจากฟังก์ชันอื่น
  • ใช้ตัวอย่างเพียง 25 บรรทัด เพื่อแนะนำทุกคอนเซปต์
  • นักพัฒนาหลักถูก Microsoft จ้างไปทำ งาน Rust OSS

ภาษาโปรแกรม

• Elm: ภาษาฟังก์ชันนัลที่ยังไม่สมบูรณ์และไม่ได้พัฒนาอย่างคึกคัก

  • การ ลบ custom operator ทำให้โค้ดพังทั้งหมดและเสีย momentum
  • Elm Architecture แข็งตัวเกินไปจนเป็นปัญหา
  • มี ทางเลือก อย่าง F# (Fable), ReasonML, OCaml (Bucklescript), Haskell และ PureScript

• Opa: Next.js แบบยึดชนิดข้อมูลเป็นหลักในปี 2012

  • เป็น เฟรมเวิร์กฟูลสแตกที่มี type ตั้งแต่ก่อน TypeScript
  • ออกมาในช่วงที่ตลาดยัง ลังเลกับ Node.js ฝั่งเซิร์ฟเวอร์
  • ไลเซนส์ AGPL เป็นหมัดน็อก, ต่อมาจะเปลี่ยนเป็น MIT ก็ ไม่มีโอกาสครั้งที่สองแล้ว

• Austral: ภาษาที่มีความคิดชัดเจนและความเป็นต้นฉบับ

  • มีสเปกที่ให้ความรู้สึก ชัดเจนอย่างแปลกประหลาด
  • ผู้เขียน ไม่ได้ทำงานกับมันอย่างจริงจังอีกแล้ว
  • สำหรับโปรแกรมเมอร์สายงานอดิเรก มันขาดทั้ง คอมมูนิตี้และอีโคซิสเต็ม

• Ceylon: ภาษา JVM ของ Red Hat

  • ต้อง แข่งขัน กับ Groovy, Kotlin และ Scala
  • มีทั้ง anonymous union type, comprehension และระบบโมดูลที่เหมาะสม
  • มอบสิ่งที่ มากกว่าแค่น้ำตาลไวยากรณ์บน Java
  • แต่ แพ้การแข่งขันกับ Kotlin และถูกปล่อยทิ้งใน Eclipse

ความล้มเหลวเชิงพาณิชย์

• Google Stadia: แพลตฟอร์มคลาวด์เกมมิง

  • สร้าง แพลตฟอร์มสตรีมมิงที่แข็งแรง ขึ้นมาได้
  • แต่ล้มเหลวเพราะ ไม่มีเกมที่น่าสนใจพอ
  • แค่มี เกมจำนวนน้อย ที่หาได้จากที่อื่นอยู่แล้วนั้นไม่พอ

• Fire Phone: สมาร์ตโฟนของ Amazon

  • เล็งตลาดที่ แทบไม่มีอยู่จริง
  • มองย้อนกลับไปก็ น่าเหลือเชื่อที่เคยคิดว่ามันจะสำเร็จ

• Project Ara: สมาร์ตโฟนโมดูลาร์ของ Google/Motorola

  • เป็นสมาร์ตโฟนที่ ปรับแต่งได้
  • น่าเสียดายที่เราไม่ได้เห็นการ พัฒนาต่ออีกสักไม่กี่รอบ
  • แต่มันก็น่าจะ หนาเกินไป ที่จะแข่งขันได้

ฐานข้อมูลและแบ็กเอนด์

• RethinkDB: ฐานข้อมูลแบบเรียลไทม์

  • ล้มเหลวระหว่างพยายามขยายขอบเขตไปสู่ Horizon BaaS
  • แม้ในเชิงเทคนิคจะยังอยู่ภายใต้ Linux Foundation แต่ momentum หายไปแล้ว
  • คอนเซปต์ดั้งเดิมนั้น ยอดเยี่ยมมากสำหรับงานเดโม แต่กรณีใช้งานใน production จริงมีน้อย

• Yahoo Pipes: เครื่องมือผสาน RSS และ data flow

  • แสดงให้เห็นว่า อินเทอร์เน็ตควรมีหน้าตาแบบไหน
  • การ เชื่อมเครื่องมือต่าง ๆ เข้าหากัน ยังไปได้แค่ระดับ Unix pipe
  • แม้ Zapier และ n8n จะเป็นตัวแทนยุคใหม่ แต่ ก็ไม่ได้ให้ความรู้สึกแบบเดียวกัน
  • มี Node-RED, Apache Camel และ Apache Nifi เป็น ทางเลือกฝั่งองค์กร

โปรเจกต์อื่น ๆ ที่น่าสนใจ

• Sandstorm: แพลตฟอร์มเว็บแบบกระจายในปี 2014

  • ตั้งอยู่บน แนวคิดของ BitTorrent
  • ทั้งโค้ดเว็บไซต์และข้อมูล กระจายศูนย์อย่างสมบูรณ์
  • เคยมีศักยภาพที่จะ ผสานเข้ากับเว็บไซต์เดิมได้
  • แต่กลไก Grain (การแยกข้อมูล) ทำให้แอปเดิมปรับตัวยาก
  • น่าจะควรทำตลาดกับการ พัฒนาแอปใหม่บนแพลตฟอร์มตั้งแต่ต้น มากกว่าการพอร์ตแอป

• Keybase: โซเชียลเน็ตเวิร์กบนพื้นฐานการเข้ารหัส

  • มอบทั้ง การเข้ารหัสที่แข็งแรงและการยืนยันตัวตน
  • หลังถูก Zoom ซื้อ ก็ แทบจะหยุดพัฒนาไปโดยปริยาย
  • FOKS คือโปรเจกต์ใหม่ของนักพัฒนาชุดเดิม

• del.icio.us: บริการโซเชียลบุ๊กมาร์ก

  • ใช้ แชร์บุ๊กมาร์กกับคนที่รู้จักจริง
  • มี การติดแท็กหมวดหมู่ที่มีประโยชน์
  • ถูก Reddit และ Twitter เข้ามาแทนที่
  • แม้ Pinboard จะให้ บริการคล้ายกัน แต่การดูแลที่ไม่ดีและมุมมองทางการเมืองของผู้ก่อตั้งทำให้ผู้ใช้ทยอยหนีไป

[soonil]

เป็นเทคโนโลยีที่ชวนให้นึกถึงความหลังนะ

[roxie]

อา.. โปรเจกต์ Keybase พับไปแล้วเหรอ??

[click]

ฉันเคยใช้ Vine บ่อยมาก ถ้ามันอยู่รอดมาจนถึงยุควิดีโอสั้นได้ ก็คงทำเงินได้ไม่น้อยในฐานะผู้บุกเบิกวงการคอนเทนต์สั้น

[unknowncyder]

Beriz Webshare?.. จำได้ว่าตอนเด็ก ๆ ถึงจะไม่มีความรู้เลยก็ยังใช้งานได้ค่อนข้างง่ายและสะดวกนะ

[chicol]

ไม่มี Cyworld แฮะ..

[GN⁺]

ความคิดเห็นจาก Hacker News

• คือระบบปฏิบัติการ Plan 9 ซึ่งเป็นระบบที่ใกล้เคียงกับการเป็นทายาทของ Unix มากที่สุด โดยต่อยอดปรัชญา "ทุกสิ่งคือไฟล์" ไปอีกขั้น ทำให้แชร์ไฟล์ผ่านเครือข่ายและสร้างระบบกระจายได้ง่าย ใน Plan 9 การเข้าถึงทรัพยากรระยะไกลทำได้ง่ายและเสถียร ขณะที่ระบบอื่นต้องติดตั้งซอฟต์แวร์ที่เข้ากันได้ไม่ดีสำหรับแต่ละกรณีการใช้งาน นอกจากนี้ยังมีฟีเจอร์ UI ที่ล้ำสมัย เช่น การแก้ไขข้อความแบบอิงการโค้ดด้วยเมาส์, ตัวจัดการหน้าต่างแบบซ้อนกัน, และ Plumber ที่รันคำสั่งตามแพตเทิร์นข้อความได้ทั้งระบบ ด้วยสถาปัตยกรรมแบบกระจาย มันน่าจะเหมาะอย่างยิ่งกับยุคปัจจุบันที่อุปกรณ์มือถือ เดสก์ท็อป คลาวด์ และ IoT เชื่อมถึงกันทั้งหมด แต่ความจริงเรายังอยู่กับระบบปฏิบัติการที่ไม่ได้ถูกออกแบบมาแบบนั้น ปัจจุบันยังมีฟอร์กอย่าง 9front ที่มีชีวิตอยู่ แต่ต้นฉบับจาก Bell Labs ได้หายไปแล้ว สาเหตุของการล่มสลายคือปัญหาทางกฎหมายต่างๆ (ไลเซนส์ คดีความ ฯลฯ) ทำให้อุตสาหกรรมนำไปใช้ช้า ประกอบกับในช่วงที่ควรต้องการ distributed OS ผู้คนกลับนิยมคอมพิวเตอร์แบบ local มากกว่า และมันยังเป็นที่รู้จักแค่ในฐานะระบบปฏิบัติการเพื่อการวิจัย จึงใช้ประโยชน์จากยุคดอตคอมบูมได้ไม่เต็มที่ สุดท้ายการสูญเสียแหล่งรายได้ของ AT&T การขาย Bell Labs และการจากไปของสมาชิกแกนหลักก็มีผลด้วย

  • สาเหตุความล้มเหลวที่ใหญ่ที่สุดของ Plan 9 คือไม่เหมือน Unix ตรงที่ผู้ขายฮาร์ดแวร์ไม่สามารถรับไลเซนส์ในราคาถูกแล้วนำไปแก้ให้เข้ากับฮาร์ดแวร์ของตัวเองได้อย่างอิสระ Bell Labs พยายามขาย Plan 9 เป็นซอฟต์แวร์เชิงพาณิชย์ในราคา 350 ดอลลาร์ และด้วยเหตุนี้อุตสาหกรรมจึงไม่รับไปใช้อย่างจริงจัง ผมเคยย้ำเรื่องนี้ไว้หลายครั้ง แนะนำให้อ่าน: ลิงก์1, ลิงก์2, ลิงก์3

  • โปรโตคอลไฟล์ซิสเต็มของ Plan 9 ยังมีชีวิตอยู่ภายใน WSL2

  • สงสัยว่าทำไมระบบตระกูล Unix อื่นๆ ถึงไม่รับเอาปรัชญา "ทุกสิ่งคือไฟล์" มาใช้อย่างจริงจัง

  • Plan 9 แก้ปัญหา symbolic link ได้แล้ว

• กราฟิกอินเทอร์เฟซ Photon ของ QNX ก็ดีมากเช่นกัน แม้จะเน้นระบบเรียลไทม์ แต่ก็มีฟังก์ชันอย่าง widget และ gauge ที่ดี รวมถึงรองรับเว็บเบราว์เซอร์ถึง 2 ตัวโดยไม่มีอาการหน่วง ให้ความรู้สึกเหมือนเป็นระบบปฏิบัติการเรียลไทม์ของแท้ และ Mac OS 8 ที่เรียกกันว่า Copland ก็พยายามทำ Mac OS ดั้งเดิมให้ทันสมัยขึ้น พร้อมรักษาธรรมเนียมที่ไม่มี command line เอาไว้ เมื่อไม่มี command line การติดตั้งและตั้งค่าทุกอย่างก็จำเป็นต้องง่ายและสอดคล้องกันทั้งหมด และถ้ามีช่วงเปลี่ยนผ่านสู่มือถือ มันก็น่าจะย้ายไปได้อย่างลื่นไหล จริงๆ แล้วมีเวอร์ชันให้ดีเวลอปเปอร์ใช้งานด้วย แต่เพราะ Apple ต้องเข้าซื้อ NeXT จึงพับโครงการ Copland ไป อีกอย่างหนึ่ง แนวคิดระบบปฏิบัติการแบบ transaction processing ก็ล้ำมาก มันทำงานแบบ CICS ของ IBM คือเรียกโปรแกรมขึ้นมารันแล้วจบไป ซึ่งตัดกับความจริงที่ว่า Unix และ Linux โดยพื้นฐานเป็นระบบแบ่งเวลาใช้งานผ่านเทอร์มินัล ต่อมา IBM MicroChannel ก็พยายามนำข้อดีของช่องสัญญาณเมนเฟรมมาสู่ PC แต่ล้มเหลวเพราะนโยบายกึ่งผูกขาด ทุกวันนี้แม้แทบทุกระบบจะใช้แนวคิดคล้ายกัน ก็ยังไม่ได้ทำหน้าที่เป็นอินเทอร์เฟซรวมที่ช่วยให้ OS ง่ายขึ้น และ CPU ที่มี hypervisor ทำงานได้อย่างเหมาะสมก็เช่นกัน เมื่อเทียบกับระบบ IBM VM ในอดีต x86 เต็มไปด้วยชั้นต่างๆ ที่เป็นการแก้ขัดทั้งนั้น ซีรีส์ Motorola 680x0 ควรจะเป็นรากฐานของยุคไมโครคอมพิวเตอร์ แต่ MMU ออกช้าเกินไปจึงพลาดโอกาส Modula-2 และ 3 ก็ค่อนข้างดี แต่ Oberon ล้มเหลว และ DEC ก็ล่มไปพร้อมกัน สำหรับ XHTML นั้น HTML5 กลับทำให้ข้อผิดพลาดกลายเป็นสิ่งที่เป็นทางการ จนกฎการ parse ผ่อนปรนเกินจำเป็น แค่โฆษณาหรือโค้ดภายนอกมีแท็กปิดไม่ครบเพียงตัวเดียว ทั้งหน้าก็พังอย่างไร้ความหมาย สุดท้ายยังมีนวัตกรรมอย่าง Word Lens ที่แค่ยกสมาร์ตโฟนขึ้นมองโลกก็แปลด้วย machine translation และประมวลผลแบบออฟไลน์ได้ แต่พอถูกรวมเข้า Google Translate ก็หายไป

  • ขอแก้ข้อเท็จจริงเกี่ยวกับโครงการ Copland หน่อย โครงการนี้มีปัญหาการจัดการอย่างร้ายแรง และยังใส่เทคโนโลยีใหม่ๆ เข้ามาแบบไร้การควบคุม จนเกิด feature creep และความเสถียรตกต่ำอย่างหนัก ถ้าลองใช้ build ที่รั่วออกมา จะพบว่าแค่ฟังก์ชันเดสก์ท็อปพื้นฐานก็ค้างและแครชบ่อยมาก ภายใน Apple เองในปี 1996 ก็สรุปแล้วว่า Copland ไม่มีทางออกได้ จึงเริ่มพิจารณาไลเซนส์ OS ภายนอกและลงเอยด้วยการซื้อ NeXT ไม่ใช่ว่าล้ม Copland แล้วค่อยซื้อ NeXT แต่เป็นเพราะ Copland อยู่ในสภาพที่ไม่มีทางปล่อยได้เลย จึงจำเป็นต้องตัดสินใจแบบนั้น

  • เคยหมกมุ่นกับ XHTML อยู่ช่วงหนึ่ง แต่ก็เจอประสบการณ์ว่าถ้ามีแท็กตัวเดียวปิดผิดในส่วนที่อยู่นอกการควบคุมของเรา เช่น โฆษณา ทั้งหน้าจะไม่แสดงอะไรเลยนอกจากข้อความ error ใหญ่ๆ วิธีแบบ “แสดงส่วนที่เหลือด้วย Times New Roman” ก็ไม่ใช่ทางออกที่ใช้ได้จริง ถ้าสุดท้ายต้อง parse HTML อยู่ดี ก็ไม่ได้ต่างจากเดิม ในฐานะคนชอบความเนี้ยบ ผมเขียนโค้ดฝั่งตัวเองให้สมบูรณ์แบบได้ แต่ในโลกจริงคนส่วนใหญ่ทำงานแบบคร่าวๆ XHTML อาจดูสมเหตุสมผลในเชิงตรรกะ แต่ในทางปฏิบัติแล้วเป็นแนวทางที่เป็นไปไม่ได้เพราะธรรมชาติของผู้คน

  • คุณอาจชอบสไตล์ที่เข้มงวดแบบ XHTML แต่กรอบที่ไม่ให้อภัยไม่เหมาะกับเอกสารเว็บที่ถูกแชร์อย่างกว้างขวาง ต่อเนื่องจากนั้น ถ้าจะแบ่งรูปแบบไฟล์ออกเป็นสองแบบคือ: (1) วงจรเปิดที่ผู้ใช้ไม่สามารถติดต่อผู้สร้างได้ (HTML, pdf, zip, csv ฯลฯ) ซึ่งข้อมูลสำคัญกว่าฟอร์แมต จึงต้องอ่านแม้ pdf หรือ zip จะเสีย และ (2) วงจรปิดที่ผู้ใช้ควบคุมผู้สร้างได้ (เช่นซอร์สโค้ดโปรแกรม) ที่ยอมรับ parser แบบเข้มงวดได้ XHTML เป็นโมเดลที่ใช้ได้เฉพาะกับแบบ (2) แต่ HTML คือแบบ (1) ถ้าไม่ใช่สภาพแวดล้อมที่ปิดโดยเนื้อแท้ เช่น เอกสารภายในองค์กร ก็ยากจะใช้ XHTML

  • ผมวิจารณ์แนวทางของ HTML5 ที่ยอมให้ข้อผิดพลาดแท็กผิดๆ ผ่านไปอย่างใจกว้าง รูปแบบอื่นส่วนใหญ่มักหยุดที่ error แรก แต่ HTML เป็นข้อยกเว้น ผลคือเกิดช่องโหว่ด้านความปลอดภัยมากมายและทำให้ยากขึ้นสำหรับนักพัฒนาทุกคน แนวทาง parsing ของ HTML5 ดูเหมือนจะไหลไปในทิศทางที่คนซึ่งต่อต้าน Internet Explorer ที่ฝังตัวอยู่กับของเดิมไล่ตามอุดมคติมากเกินไป หรือไม่ก็จบลงด้วยการจดบันทึกบั๊กในนามของมาตรฐาน RFC ที่เกี่ยวข้อง

  • การบังคับให้ปิดแท็กให้ “ถูกต้อง” มีแต่จะเพิ่มกำแพงการเข้าสู่ภาษา สมัยก่อนคนเขียน HTML ด้วยมือต่อให้พลาด อย่างน้อยก็ยังมีอะไรขึ้นบนหน้าจอ ทำให้หลายคนยังกล้าลองต่อไป แต่ภาษาโปรแกรมจริงๆ มักพ่น error message ที่น่ากลัวจากความผิดพลาดเล็กน้อยจนคนเลิกง่าย ภาษายุคใหม่พัฒนาขึ้นมากอย่าง Rust แต่ในยุค XHTML ความผิดพลาดเล็กๆ ก็ไม่ได้เข้าใจได้ง่ายเลย

• ขอยก Google Wave ตอนแรกผมดูเดโมของ Chris DiBona แล้วรู้สึกว่ามันสุดยอดมาก มีทั้งการแปลแบบเรียลไทม์ การรวมระบบส่งข้อความหลายแบบ และยังเป็นโอเพนซอร์สพร้อมฟีเจอร์เจ๋งๆ เต็มไปหมด แต่ Wave ที่เปิดตัวจริงกลับเป็นเวอร์ชันที่ถูกลดทอน และตลาดก็เมินมันไป น่าเสียดายมาก ทุกวันนี้ยิ่งรู้สึกถึงช่องว่างของ Wave เมื่อจบลงด้วยการต้องใช้ JIRA, Slack, อีเมล และเครื่องมืออื่นแทน

  • Google Wave มี tech stack ที่ยอดเยี่ยม แต่พลาดหนักในด้านการออกแบบ UI มันปฏิบัติต่อ Wave ไม่ใช่ในฐานะเอกสารเดียว แต่เป็นรายการย่อยหลายชิ้น ทำให้ดูซับซ้อนอย่างเดียวและทำลายข้อดีของมันไป

  • ตอนดูเดโมผมก็ทึ่ง แต่พอคิดต่ออีกหน่อยก็สรุปได้ว่าน่ากลัวมาก เหมือน Slack ที่ต้องคอยเช็กอัปเดตแต่ละแชนเนลทีละอัน แต่ Wave ซับซ้อนกว่านั้นมาก จึงรู้สึกทันทีว่าไม่มีทางตามทันแน่

  • เทคโนโลยีของ Wave น่าทึ่งมาก แต่ถ้าย้อนดูวิดีโอเดโมอีกครั้งก็จะเห็นว่ามันไม่ใช่ผลิตภัณฑ์ที่ดีนัก มันพยายามเป็นผลิตภัณฑ์ all-in-one ที่ครอบทุกอย่าง แต่ไม่สำเร็จ กลับกัน เทคโนโลยีเหล่านี้ถูกกระจายไปใช้ในผลิตภัณฑ์ Google หลายตัว และเราก็ได้เห็นว่าการมี UI แยกตามฟังก์ชันนั้นเข้าใจง่ายกว่ามาก

  • มันเหมาะมากสำหรับการแชร์จัดการเรื่องอย่างแผนท่องเที่ยวกับเพื่อนๆ รวมถึงการคุยกันแบบเฉพาะกิจที่มีทั้งเอกสารและลิงก์รวมอยู่ด้วย รูปแบบของ Wave ใช้งานได้ผลดีมาก ตอนเริ่มต้นผมถึงกับสร้างปลั๊กอินจัดการเซิร์ฟเวอร์เองเพราะรู้สึกเหมือนได้เห็นอนาคต: Wave-ServerAdmin ผ่านมา 16 ปีแล้ว ดูเหมือนถึงเวลาต้อง archive มันเสียที

  • ผมเคยโหลดเซิร์ฟเวอร์ Wave แบบโอเพนซอร์สมาลองคิดว่าจะทำเป็นผลิตภัณฑ์อะไรได้ไหม แต่ข้อจำกัดใหญ่ที่สุดคือมันเก็บข้อมูลถาวรไม่ได้ ในมุมผมจึงไม่มีอนาคตเลย และปฏิกิริยาของคนในทีม Wave ก็ดูเหมือนยังอยู่ในโลกฝันและไม่เข้าใจความจริง ถึงอย่างนั้นก็ยังเป็นคอนเซปต์ที่เท่มาก

• Adobe Flash / Shockwave ต่อให้เวลาผ่านไปหลายสิบปี ตอนนี้ก็ยังไม่มีเครื่องมือไหนที่ทำเกมหรือมัลติมีเดียได้ง่ายเท่านี้ มันเตือนให้เห็นว่ามนุษยชาติไม่ได้พัฒนาไปในทิศทางเดียวเสมอไป บางครั้งเราก็สูญเสียสิ่งมีค่าบางอย่างไปตลอดกาล

  • มันทำให้มือใหม่สร้างเกมได้ง่ายมาก จนทั้งวงการเกมมีไอเดียสดใหม่หลั่งไหลออกมา ตัวอย่างเช่นอินดี้ดีเวลอปเปอร์อย่าง Zachtronics ก็เปิดตัวด้วยวิธีนี้ ในอีกด้านหนึ่ง เกม Flash แต่ละเกมมักมาพร้อมโฆษณามหาศาลและเมนูนำทางที่ทำด้วย Flash แบบหยาบๆ ครั้งหนึ่งถึงขั้นที่เว็บไซต์ร้านอาหารแทบทั้งหมดเป็น Flash เลยก็ว่าได้ โปรแกรมเล่นวิดีโอแบบ Flash ก็เป็นฝันร้ายบน Linux และยังเป็นตัวการสำคัญที่ทำให้เบราว์เซอร์รองรับวิดีโออย่างเหมาะสมช้าลง

  • Flash เป็นหายนะของเว็บ มันเป็นกล่องดำที่ซูมก็ไม่ได้ เลือกข้อความก็ไม่ได้ กดย้อนกลับก็ไม่ได้ รู้สึกเลยว่าการตายของมันคือผลงานที่ดีที่สุดของ Steve Jobs

  • Godot ใกล้เคียงมาก เรียนรู้ง่าย รองรับทั้ง 2D และ 3D และส่งออกไป HTML5/webasm รวมถึง OS หลักๆ และมือถือได้กว้างขวาง มันยังไม่สมบูรณ์แบบ แต่ช่วงไม่กี่ปีที่ผ่านมาพัฒนาแบบก้าวกระโดด และดูเหมือนกำลังมาถึงจุดเปลี่ยนใหญ่แบบเดียวกับ Blender

  • ต่อให้ Adobe แก้ปัญหาความปลอดภัยได้หมด Apple ก็คงจะฆ่ามันอยู่ดี ความสำเร็จในวงกว้างของ Flash เป็นภัยคุกคามต่อ Apple และแม้กระแส HTML canvas จะซาลงไปนานแล้ว จนถึงตอนนี้ก็ยังไม่มีตัวแทนที่ให้นักออกแบบสร้างงานอินเทอร์แอกทีฟสวยๆ โดยไม่ต้องสมัครสมาชิก แล้วฝังใช้งานได้ทุกที่

  • ปัญหาคือ Flash ถูกใช้อย่างพร่ำเพรื่อเกินไป ที่บริษัทมีแอปหนึ่งยืนกรานใช้ Flash จนถึงท้ายที่สุด พอไปหาสาเหตุก็พบว่าเขาทำเส้นคั่นแนวนอนธรรมดาในหน้าเว็บด้วย Flash เมนูดรอปดาวน์แบบ Flash, splash screen ในเว็บรถยนต์ ทั้งหมดนี้คือการใช้ผิดที่ผิดทาง มันต้องรอจนเข้าสู่ยุคมือถือถึงจะตายได้ และตอนนั้นแทบไม่มีใครเสียดายมันนัก

• ยังมีบริการของ Google อีกมากมายที่เห็นได้ใน killedbygoogle.com ครั้งหนึ่งผมเคยใช้ 30~40 บริการ แต่ตอนนี้เหลือแค่ 3~4 อย่าง Google Picasa ใช้งานแบบ local ได้เร็วมาก ส่วน Google Hangouts ทำให้สับสนเพราะมีแอปแชตหลายตัว G Suite Legacy เคยบอกว่าฟรีตลอดชีพแต่สุดท้ายก็เก็บเงิน เลยย้ายออกจาก Google Google Play Music ผมอัปโหลด MP3 ไว้หลายพันเพลง พอบริการปิดก็ไม่คิดจะอัปใหม่ Google Finance กับ NFC Wallet ก็เลิกใช้เพราะความเชื่อถือในข้อมูลพังไป Chromecast Audio ทำหน้าที่เดียวที่ผมต้องการได้พอดี แต่พอได้ข่าวยุติการผลิตก็รีบขายไป และผมเพิ่งมารู้ตอนใช้งานอยู่ว่าแม้แต่ Chromecast เองก็ถูกฆ่าไปแล้ว

  • Google Reader ก็ยังน่าเสียดายไปตลอด มันคงไม่ได้มีค่าใช้จ่ายในการดูแลสูงขนาดนั้น และเป็นฟังก์ชันที่ต่อให้ปล่อยไว้นานโดยไม่แก้ก็แทบไม่มีใครบ่น ไม่ว่าเมื่อก่อนหรือตอนนี้ RSS ก็ยังใช้งานแบบเดิม

  • เพลงที่อัปโหลดไว้ใน Google Play Music ไม่ได้หายไปทั้งหมด ถ้าคุณย้ายไป YouTube Music เพลงทั้งหมดจะถูกย้ายตามมาโดยไม่ต้องอัปโหลดใหม่

  • Chromecast Audio ยังทำงานได้ดีอยู่ เพียงแต่ไม่ได้ขายอีกต่อไปแล้ว ผมเลยยังคอยมองหาของมือสองอยู่เสมอ

  • ระบบจดจำใบหน้าของ Picasa ล้ำยุคมาก และแพ็กเกจออฟไลน์ก็ดีจริงๆ น่าเสียดายที่เวอร์ชันสุดท้ายมีบั๊กที่ทำให้ face tag สลับแบบสุ่ม จนการจำแนกรูปครอบครัวหลายพันรูปใช้การไม่ได้ Digikam แค่พอทำหน้าที่คล้ายกันได้ แต่ยังห่างไกลจากการเป็นตัวแทนที่ดี

  • น่าสนใจที่ Google ปิด Google Notebook ไป แล้วอีกหลายปีต่อมากลับสร้าง Google Keep ซึ่งมีฟังก์ชันแทบจะเหมือนเดิม

• กล้อง light-field ของ Lytro น่าประทับใจในเชิงเทคนิคและออกมาสองผลิตภัณฑ์แล้ว แต่ความละเอียดก็ยังไม่ถึงระดับที่ช่างภาพมืออาชีพต้องการ อย่างไรก็ตาม ด้วยการมาถึงของสื่ออย่างจอ light-field ของ Meta Ray-Ban และ gaussian splats ตอนนี้เหมือนเรากำลังเข้าสู่ช่วงเวลาที่ใช้ข้อมูลจากเซนเซอร์ได้มากขึ้น นอกเหนือจากเรื่องเทคนิค ตลาดกล้องความละเอียดต่ำแต่มีเอกลักษณ์อย่าง Polaroid หรือ Instax ก็ยังใหญ่มาก ดังนั้น Lytro รุ่นแรกแม้จะใส่เครื่องพิมพ์มาเลยก็คงไม่เป็นปัญหา

  • light field บันทึกภาพโดยผสมพิกเซลจากหลายระดับความลึกของโฟกัส ดังนั้นเชิงโครงสร้างแล้วผลลัพธ์จึงต้องมีความละเอียดต่ำกว่ากล้องปกติ การผลิตไม่ใช่เรื่องยากนัก แต่ข้อจำกัดทางฟิสิกส์น่าเสียดาย

  • เดี๋ยวนี้ดูเหมือนสมาร์ตโฟนก็ทำฟีเจอร์นี้ได้บางส่วนแล้ว ยังจำได้ว่าตอน Lytro ออกมานั้นตื่นเต้นมาก

• หน่วยความจำถาวร Optane มีคุณค่าเชิงนวัตกรรมตรงที่เก็บข้อมูลได้โดยตรง ทำให้ไม่ต้องบูตหรือโหลดแอปก็กลับมาใช้งานต่อได้ทันที มันล้มเหลวเพราะแพงเกินไป แต่จริงๆ ก่อนหน้านั้นก็มีข้อจำกัดชัดเจนอยู่แล้ว อย่างไรก็ตาม กระแสนี้ยังไม่หายไปหมด เพราะยังมีสิ่งอย่าง memory snapshot ของ VM และ container ของ macOS

  • ผมเชื่อมั่นในเทคโนโลยี 3dxpoint อย่างมาก มันเป็นเทคโนโลยีที่สั่งสมมาหลายสิบปี แต่ฝั่งธุรกิจไม่มีความอดทนพอจะรอให้โลกตามมันให้ทัน

  • วิธีคิดแบบระบบเดิมยังติดกับการแบ่ง RAM กับดิสก์ จึงยังไม่พร้อมรับฮาร์ดแวร์ใหม่อย่าง Optane ถึงอย่างนั้น ในโลกเซิร์ฟเวอร์ก็เริ่มมี use case บางอย่างเกิดขึ้น และโครงการวิจัยที่เกี่ยวข้องก็มีจำนวนมาก

  • Optane น่าทึ่งมากในเชิงเทคนิค มันเกือบจะลบเส้นแบ่งระหว่างแรมกับดิสก์ได้ และคุณอาจใช้เมมโมรีทั้งหมดได้จากสติ๊กอันเดียว

  • ผมใช้งานเคอร์เนลบนไดรฟ์ Optane จริงๆ เพื่อสัมผัสประสบการณ์บูตทันที

  • ไม่ใช่แค่เรื่องราคา แต่ ecosystem รองรับยังแพร่ไม่พอ และวิธีคิดเดิมก็ยังไม่พร้อม มันใกล้กับโมเดลแบบสภาพแวดล้อมอิงอิมเมจ (live image) มากกว่า คล้าย Lisp ยุคแรกหรือ Smalltalk ผมเองก็ยังมีระบบที่รองรับเฟิร์มแวร์กับ Optane ความจุต่ำอยู่ ความจุไม่มากและติดกับ OS เก่า แต่ก็น่าลอง ถ้าแรมเยอะพอก็พอเลียนแบบแบบ suspend/resume ได้ เมื่อรวมกับการพัฒนาของ SSD ความต่างด้านความเร็วก็แทบไม่มีแล้ว เหลือเพียงเรื่องความทนทานอย่าง TBW และก็ยังสามารถผสมใช้ทั้งสองแบบได้

• เครือข่าย Ricochet เป็นระบบเฉพาะตัวมาก ในยุคสายโทรศัพท์มันให้อินเทอร์เน็ตไร้สายแบบ packet mesh ที่เร็วระดับ ISDN ทุ่มเงินไป 5 พันล้านดอลลาร์เพื่อสร้างเครือข่ายใน 23 เมือง แต่แทบไม่มีลูกค้าเลยและปิดตัวลงในปี 2001 การตลาดมุ่งไปที่ "มืออาชีพสายโมบายล์" แต่กลับมองข้ามตลาดตามบ้านที่จริงๆ ต้องการอินเทอร์เน็ตที่เร็วกว่า ทุกวันนี้ femtocell ของ 5G มีแนวคิดทางกายภาพคล้ายกัน แต่ยังขาดทั้ง redundancy และแนวคิด self-routing

  • Ricochet เป็นระบบที่เจ๋งและมาก่อนกาลจริงๆ แนะนำให้อ่านความเห็นของ Joel Spolsky ด้วย: รีวิวโมเด็ม Ricochet Wireless

  • ผมรักโมเด็ม Ricochet มากจริงๆ มีความทรงจำกับการถือ Ricochet รุ่นที่สองและ PowerBook ไปนั่งคาเฟ่ใน Palo Alto แล้วท่องเว็บที่ 56k กับเปิด ssh session ทุกวันนี้ยังน่าจะมีมันอยู่ในกล่องที่ไหนสักแห่งในบ้าน และยังคิดอยู่เลยว่าจะลองต่อแบบ star mode เล่นๆ ดีไหม

  • ผมใช้โมเด็ม Ricochet ที่ซานฟรานซิสโกช่วงปี 98~99 สิบปีต่อมา iPhone ก็เปิดยุค 3G และพัฒนาสมรรถนะไปไกลมาก ถ้าลองถามว่าถ้า Ricochet อยู่รอด ชีวิตผมจะดีขึ้นไหม ผมกลับรู้สึกว่าความก้าวหน้าทางเทคโนโลยีไปมาในทิศทางที่ถูกต้องกว่ามาก

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

• Midori ของ Microsoft เป็น OS ที่มุ่งด้านความปลอดภัยแบบอิงสิทธิ์ มีข่าวลือว่ามันพัฒนาไปไกลจนรันโค้ด Windows ได้ด้วย แต่ก็มีเรื่องเล่าว่าถูกยกเลิกเพราะการเมืองภายใน มันเหมือนเป็นบรรพบุรุษของ Fuchsia วิกิ Midori

  • Midori น่าสนใจมาก บล็อกของ Joe Duffy น่าจะเป็นข้อมูลที่ละเอียดที่สุดเท่าที่มี: บล็อก Midori. ภายใน Microsoft ก็มีคนมองว่ามันเป็นทั้ง moonshot และโครงการรักษาคนเก่ง มีวิศวกรอาวุโสมากกว่า 100 คนทุ่มลงไป งานวิจัยบางส่วนถูกนำไปใช้กับ .NET จึงไม่ได้หายไปทั้งหมด

  • ผมไม่รู้ว่าข่าวลือเรื่องรันโค้ด Windows มาจากไหน เพราะเอกสารที่เปิดเผยทุกฉบับบอกว่า Midori ตั้งใจจะไม่เข้ากันกับโค้ดเดิมโดยสิ้นเชิง อาจมีบางคนฝันถึงการย้ายภายในอยู่บ้าง แต่ตัวการออกแบบนั้นเป็นระบบใหม่แบบถอนราก ไม่มีทางเปลี่ยนผ่านแบบเดิมได้

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

  • ไม่ทราบว่าคุณรู้จัก Genode(genode.org) หรือไม่ มันอยู่ในพื้นที่คล้าย Midori และยังพัฒนาอย่างคึกคักอยู่จนถึงตอนนี้

• Yahoo Pipes ดีมากสำหรับการสร้าง RSS feed และ workflow แบบกำหนดเอง ทุกวันนี้มีตัวแทนอย่าง Zapier หรือ n8n แต่ผมชอบ Pipes เป็นพิเศษ และก็เห็นด้วยกับการรำลึกถึง Google Reader เช่นกัน

  • แนะนำให้อ่าน archive นี้มาก: ประวัติของ Pipes มีบทความย้อนความจากทีมพัฒนาจริงอยู่ในนั้น

  • Yahoo Pipes คืออนาคตที่อินเทอร์เน็ตควรเดินไป ถึงผ่านมาหลายสิบปีแล้ว การเชื่อมเครื่องมือเข้าหากันแบบนั้นก็ยังทำได้แค่ระดับ unix pipes แบบพอถูไถ

  • ผมไม่เคยใช้เอง แต่ทุกครั้งที่ได้ยินคนเล่าย้อนถึง pipes ในแง่ดี ก็สัมผัสได้เลยว่ามันต้องเป็นเครื่องมือที่ยอดเยี่ยมจริงๆ ไม่แน่ใจว่าสิ่งที่ตายไปคือ Pipes เอง หรือเป็นอินเทอร์เน็ตมวลชนที่อิงมาตรฐานเปิดและโปรโตคอลแบบเปิดต่างหาก

  • ผมรัก Pipes มาก ผมรวมคอนเทนต์จากหลายเว็บไซต์ด้วย pipes จัดรูปแบบมัน แล้วดึงเข้า php blog ผ่าน RSS แต่ละเว็บค่อยๆ เลิกสนับสนุน RSS ทีละแห่ง ทำให้ Pipes หมดความหมายและจบลงในที่สุด อยู่พักหนึ่งผมใช้ไลบรารี Python ชื่อ riko เพื่อทำสิ่งคล้ายกันโดยไม่มี visual editor และมันก็กลายเป็นจุดเริ่มที่ทำให้ผมย้ายจาก PHP ไป Python

  • ถ้าอยากชุบชีวิตแนวคิดของ Yahoo! Pipes, Node-RED(nodered.org) คือจุดเริ่มต้นที่ดี มันเป็นโอเพนซอร์ส มี API แข็งแรง สั่งสมประสบการณ์มานานกว่า 10 ปี และมี backend ที่มั่นคง ผมเคยใช้ทั้ง Browser-Red ที่หยิบเฉพาะ frontend ของ Node-RED มา และ Erlang-Red ที่สร้าง backend ด้วย Erlang จริงๆ แล้ว Node-RED ต่างจาก Pipes ตรงที่ทุก node มี input port เดียวหรือไม่มีเลย ขณะที่ Pipes รับสาย input ได้หลายเส้น ส่วน frontend ถ้ารู้ jQuery ก็เรียนรู้ได้ง่ายมาก ถ้ามีคำถามเกี่ยวกับ Node-RED หรือ flow-based programming ก็ติดต่อมาได้เสมอ