3 คะแนน โดย GN⁺ 22 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Hardcore IndieWeb คือแนวทางที่เก็บต้นฉบับคอนเทนต์และ HTML/เว็บแอสเซ็ตที่พร้อมเผยแพร่ไว้บนอุปกรณ์ของตัวเอง โดยไม่ฝากอัตลักษณ์และสิทธิ์ควบคุมคอนเทนต์ไว้กับผู้ให้บริการ
  • หากใช้ กระบวนการเผยแพร่แบบยุค 1990s ที่พรีวิว HTML ในเบราว์เซอร์ก่อนแล้วค่อยอัปขึ้นโฮสต์ ก็สามารถดูแลเว็บไซต์ได้โดยไม่ต้องมี CMS, SSG, เฟรมเวิร์ก, CLI หรือค่าสมาชิกรายเดือน
  • ต้องมีเพียงโปรแกรมแก้ไขข้อความ เครื่องมือ SFTP และเว็บโฮสต์เท่านั้น โดยบน NearlyFreeSpeech.net สามารถรันเว็บไซต์แบบสแตติกได้ในราคา $0.01 ต่อวัน และเติมเงินเริ่มต้นที่ $0.25
  • สามารถจัดการหน้าแลนดิ้ง โพสต์เดี่ยว คลังบทความ และ Atom feed เป็นไฟล์โดยตรง ปรับโครงสร้างและดีไซน์รายหน้าได้ และ ส่งเฉพาะไฟล์ที่เปลี่ยนแปลง
  • แม้โฮสต์เดิมจะหายไป ก็ยังย้ายเว็บไซต์ที่เสร็จสมบูรณ์ไปลงที่อื่นได้ทันที แต่ยิ่งเพิ่มเครื่องมือมากเท่าไร ก็ยิ่งมี dependency มากขึ้น ดังนั้นเงื่อนไขของการรักษาความเป็นอิสระคือ ต้องมีทั้งต้นฉบับในเครื่องและเวอร์ชันที่เผยแพร่แล้ว

ความเป็นอิสระที่ Hardcore IndieWeb ต้องการ

  • IndieWeb คือแนวทางเชิงปฏิบัติที่มุ่ง เป็นเจ้าของอัตลักษณ์และคอนเทนต์บนเว็บด้วยตนเอง และหลุดพ้นจากการควบคุมภายนอกของบริษัทต่าง ๆ
  • บริการบล็อกแบบสมัครสมาชิกก็อาจช่วยให้เข้าร่วม IndieWeb ได้ แต่ถ้าคอนเทนต์ยังอยู่หลัก ๆ ในฐานข้อมูลและเซิร์ฟเวอร์ของคนอื่น ก็ยังไม่อิสระอย่างสมบูรณ์
    • ถึงจะส่งออกเป็นฟอร์แมตแบบเปิดได้ ระหว่างที่ยังใช้บริการอยู่ก็ยังควบคุมคอนเทนต์ได้ไม่เต็มที่
    • วิธีนี้เหมาะกับคนที่ต้องการความเป็นอิสระและการควบคุมคอนเทนต์อย่างสมบูรณ์ มากกว่าคนที่พอใจกับบริการเดิมอยู่แล้ว
  • Hardcore IndieWeb นำหลักการ IndieWeb เดิมมาใช้ร่วมกับเกณฑ์ที่ชัดเจนเรื่อง การควบคุมและการย้ายระบบได้
    • หากคอนเทนต์ไม่ได้อยู่บนฮาร์ดไดรฟ์ของตัวเองเป็นหลัก ก็ยากจะบอกว่าควบคุมได้อย่างสมบูรณ์
    • หากไม่มีสำเนา HTML และเว็บแอสเซ็ตที่เผยแพร่แล้วอยู่ในฮาร์ดไดรฟ์ ก็ถือว่าเว็บไซต์ยังไม่พร้อมย้ายได้อย่างสมบูรณ์
  • หากบริการปิดตัวจนส่งออกข้อมูลไม่ได้ ต่อให้มีกรรมสิทธิ์คอนเทนต์ในนาม ก็อาจเข้าถึงหรือย้ายออกไม่ได้
  • แม้อยากออกจากบริการเพราะพฤติกรรมของผู้ให้บริการ ก็อาจต้องหาบริการอื่นที่รองรับฟอร์แมตส่งออกเดิม หรือแปลงคอนเทนต์และเปลี่ยนเครื่องมือกับขั้นตอนใหม่
  • หากมีทั้งต้นฉบับคอนเทนต์ในเครื่องและเวอร์ชันที่เผยแพร่เสร็จแล้ว ก็ยังรักษา การควบคุมและการย้ายระบบได้ ในสถานการณ์เหล่านี้

ขั้นตอนเผยแพร่เว็บแบบยุค 1990s

  • Hardcore IndieWeb ใช้วิธีเผยแพร่ที่เรียบง่ายแบบยุคแรกของเว็บ
    1. เขียนคอนเทนต์บนฮาร์ดไดรฟ์
    2. พรีวิวในเว็บเบราว์เซอร์
    3. ถ้าพอใจแล้วค่อยอัปโหลดขึ้นเว็บโฮสต์ และทำซ้ำเมื่อจำเป็น
  • นอกจากโดเมนแล้ว สิ่งที่ต้องมีคือ โปรแกรมแก้ไขข้อความ, เครื่องมือโอนไฟล์, เว็บโฮสต์ เท่านั้น
  • ไม่จำเป็นต้องมี environment สำหรับเขียนโปรแกรมหรือ IDE, เฟรมเวิร์ก, เชลล์, เครื่องมือ CLI หรือค่าสมาชิกรายเดือน
  • แม้ต้องมีความรู้ HTML แต่สามารถเรียนจากแหล่งข้อมูลอย่าง HTML for People ได้ และเริ่มต้นได้ด้วยแท็กไม่กี่ตัวกับการคัดลอกวาง
  • SaaS, CMS, SSG, ภาษา markup และระบบเทมเพลตที่ซับซ้อนเป็นเพียงตัวเลือก วิธีตรงไปตรงมาที่เผยแพร่ไฟล์เองยังใช้งานได้ดี

เครื่องมือและโฮสติ้งที่ต้องใช้

  • โปรแกรมแก้ไขข้อความใช้ตัวไหนก็ได้ ขอเพียงบันทึกไฟล์ลงดิสก์ได้
  • สำหรับการโอนไฟล์ ต้องมีเครื่องมือที่รองรับ SSH หรือ SFTP
    • FileZilla เป็นตัวเลือกที่รองรับหลายระบบปฏิบัติการ
  • แนะนำ NearlyFreeSpeech.net เป็นโฮสต์สำหรับเว็บไซต์สแตติก ซึ่งรันได้ในราคา $0.01 ต่อวัน
    • Adam Newbold ใช้บริการนี้มาตั้งแต่ปี 2008
    • สามารถเติมเงินเข้าบัญชีเริ่มต้นที่ $0.25 และเพิ่มเว็บไซต์แบบ static, non-production ได้
    • เมื่อเลือกชื่อเว็บไซต์ในแท็บ Sites จะดูข้อมูลล็อกอินสำหรับโอนไฟล์ได้
    • มีซับโดเมนฟรีให้ และสามารถเพิ่มโดเมนส่วนตัวได้ในแท็บ Domains
  • NearlyFreeSpeech ไม่ใช่ข้อบังคับ จะเลือกเว็บโฮสต์อื่นที่ให้บริการโฮสต์ไฟล์สแตติกพื้นฐานก็ได้

เตรียมเว็บไซต์เดิมและ HTML

  • หากเว็บไซต์หรือบล็อกเดิมเป็น HTML อยู่แล้ว ก็เริ่มได้ง่ายทันที
  • ถ้ากำลังใช้งานในฟอร์แมตอื่น ก็อาจส่งออกหรือแปลงเป็น HTML ได้ตามแต่ละบริการ
    • ถ้าเป็นบล็อกขนาดใหญ่ ควรใช้เครื่องมือแปลงจะเหมาะกว่า
    • ถ้าขนาดเล็ก ก็อาจย้อนดูโพสต์แล้วสร้างไฟล์ HTML เองทีละไฟล์ได้
  • หลายคนอาจชอบ Markdown แต่ HTML คือภาษาของเว็บ และบางครั้งจัดการด้วย HTML ล้วนก็ง่ายกว่าการต่อสู้กับ Markdown parser
  • ถ้าเริ่มออกแบบเองยาก ก็สามารถดาวน์โหลดดีไซน์และเทมเพลตฟรีอย่าง HTML5 UP มาแก้ไขได้

ไฟล์ที่ประกอบเป็นบล็อก

  • บล็อกทั่วไปประกอบด้วย หน้าแลนดิ้ง, โพสต์, หน้าคลังบทความ, ฟีด และสามารถจัดการเองได้โดยไม่ต้องใช้บริการบล็อกเฉพาะทาง
  • หน้าแลนดิ้ง

    • จะวางโพสต์ล่าสุดทั้งหมดหรือบางส่วน หลายโพสต์ หรือคอนเทนต์ที่ไม่ใช่โพสต์ก็ได้อย่างอิสระ
    • หากต้องการแสดงโพสต์ล่าสุด ก็เพียงคัดลอกเนื้อหาแล้วเพิ่มลิงก์ไปยังหน้าแยกของโพสต์นั้น
    • หากต้องการเก็บ 5 โพสต์ล่าสุด ก็เพิ่มโพสต์ใหม่ไว้ด้านบนและลบโพสต์เก่าสุดด้านล่างออก
    • เพราะไม่มีข้อจำกัดจาก CMS, SSG หรือ template engine จึง เปลี่ยนโครงสร้างและการนำเสนอ ได้ในทุกหน้า
    • ชื่อไฟล์ของหน้าแลนดิ้งต้องเป็น index.html และวางไว้ที่ web root
    • web root ของ NearlyFreeSpeech คือ /home/public
  • โพสต์บล็อก

    • หนึ่งโพสต์คือหนึ่งเว็บเพจ โดยอาจคัดลอกไฟล์ของโพสต์ก่อนหน้าแล้วเปลี่ยนเป็นชื่อไฟล์เฉพาะกับเนื้อหาใหม่
    • โครงสร้างไฟล์บนดิสก์จะสะท้อนเป็น URL จึงจัดโฟลเดอร์ให้ตรงกับรูปแบบที่ต้องการได้
    • หากต้องการใช้พาธ /blog/ ก็สร้างโฟลเดอร์ blog ไว้ใน web root
    • สามารถใช้ชื่อไฟล์แบบ slug เช่น the-best-lunch-i-ever-had.html
    • หากวาง index.html ไว้ในโฟลเดอร์ของแต่ละโพสต์ ก็สามารถซ่อนนามสกุล .html จาก URL ได้
    • เมื่อจัดการโพสต์เป็น ไฟล์ HTML อิสระ แทน Markdown หรือรายการในฐานข้อมูล ก็สามารถให้แต่ละบทความมีสไตล์ หน้าตา เลย์เอาต์ และเอกลักษณ์ต่างกันได้
    • ธรรมเนียมที่ทุกโพสต์ต้องหน้าตาเหมือนกันนั้นเกิดจากเครื่องมือเผยแพร่สมัยใหม่ แต่สำหรับ HTML ที่ทำเองไม่จำเป็นต้องยึดตาม
  • หน้าคลังบทความ

    • สร้างโฟลเดอร์ชื่อเช่น archive แล้ววาง index.html ไว้ข้างใน จากนั้นเขียนรายการโพสต์
    • จะเรียงลำดับหรือจัดโครงสร้างแบบใดก็ได้ และยังเน้นโพสต์ที่ชอบไว้ด้านบนของหน้าแยกต่างหากก็ได้

จัดการ Atom feed ด้วยตัวเอง

  • RSS feed ไม่ใช่ระบบพิเศษอะไร แต่เป็นไฟล์ที่เก็บไว้บนดิสก์ จึงแก้ไขโดยตรงด้วยโปรแกรมแก้ไขข้อความได้
  • สามารถคัดลอก feed ตัวอย่างจาก หน้า Atom ของ Wikipedia) แล้วเริ่มต้นเป็นไฟล์ feed.xml
    • Atom ใช้ร่วมกับ RSS ได้และมีการรองรับอย่างแพร่หลาย
    • เปลี่ยนค่าอย่าง example.com, <title>, <subtitle> ให้เป็นโดเมนและข้อมูลของตัวเอง
    • สร้าง <entry> สำหรับแต่ละโพสต์ที่จะใส่ในฟีด แล้วกรอกวันที่ เวลา ชื่อเรื่อง และสรุป
    • ใน <id> ให้สร้าง UUID ใหม่จาก UUID Generator
  • เมื่อตกแต่งฟีดเสร็จแล้ว สามารถนำไปวางใน W3C Feed Validation Service เพื่อตรวจว่าพาร์สได้หรือไม่
    • หากพบข้อผิดพลาด บริการตรวจสอบจะแสดงจุดที่ต้องแก้ไข

การเผยแพร่และอัปเดต

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

เส้นแบ่งระหว่างความย้ายระบบได้กับเครื่องมือเพิ่มเติม

  • เพราะเว็บไซต์ที่เสร็จสมบูรณ์อยู่ในคอมพิวเตอร์ของตัวเอง ต่อให้โฮสต์เดิมหายไปก็ยังอัปโหลดขึ้นโฮสต์ใหม่ได้ทันที
  • ไม่ต้องคอยจัดการช่องโหว่ความปลอดภัยร้ายแรงของซอฟต์แวร์บล็อก หรือ dependency ของ SSG และยังควบคุมทุกด้านของคอนเทนต์ได้โดยตรง
  • เพียงคงขั้นตอนนี้ไว้ ก็สามารถดูแลเว็บไซต์ที่อิสระอย่างสมบูรณ์ต่อไปได้
  • แม้จะเพิ่มเครื่องมือและขั้นตอนเพื่อช่วย workflow ได้ แต่ ทุกครั้งที่เพิ่มเครื่องมือหนึ่งชิ้น ก็เพิ่ม dependency ใหม่หนึ่งอย่าง
  • ตราบใดที่ต้นฉบับคอนเทนต์อยู่บนอุปกรณ์ของตัวเอง และมีสำเนาทั้งเว็บไซต์ที่พร้อมเผยแพร่ครบถ้วน ก็ถือว่าตรงตามเงื่อนไขของ Hardcore IndieWeb

อิสระจากการจัดการ HTML โดยตรง

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

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

 
ความเห็นจาก Hacker News
  • ผมโฮสต์เว็บไซต์แบบสแตติกบน GitHub Pages และ Cloudflare Pages ฟรีมาตลอดและพอใจมาก ต่อให้จ่ายเงินให้ NearlyFreeSpeech สุดท้ายก็ยังต้องพึ่งโฮสต์ของบุคคลที่สามอยู่ดี เลยรู้สึกว่าการโฮสต์เองไม่มีคุณค่าอะไรมากนอกจากความพึงพอใจทางเทคนิค
    สิ่งสำคัญคือสามารถจัดการทรัพยากรอย่าง HTML และรูปภาพได้โดยตรงในฐานะไฟล์ธรรมดาบนดิสก์ ด้วยการเชื่อมกับ Git ก็มีแบ็กอัปภายนอกไปด้วย และพอ push ไปที่ master จาก VS Code ก็เผยแพร่ได้ภายใน 30 วินาที สะดวกกว่า FTP/SFTP แบบเก่ามาก

    • GitHub Pages และ Cloudflare Pages มีข้อดีคือเว็บไซต์มีโอกาสอยู่ได้นานกว่าผู้ดูแลเอง ถ้าโฮสต์เอง สักวันก็ต้องหยุดแน่นอนจากโดเมนหมดอายุหรือบัตรถูกยกเลิก เว้นแต่จะมีแผนส่งต่อ แต่บริการฟรีอย่างมากก็แค่มีความเป็นไปได้ว่าจะหายไป
    • ความต่างระหว่างการจ่ายเงินแล้วได้เป็น ลูกค้า แทนที่จะเป็นสินค้า นั้นใหญ่พอสมควร
    • บล็อกของผมก็ใช้วิธีเดียวกัน: https://gigatexal.blog
  • NearlyFreeSpeech ก็เป็นบริการที่ดี แต่ก็ไม่ได้เป็นอิสระอย่างแท้จริง หากอยากเข้าใกล้ความเป็นอิสระที่สุดโดยไม่ต้องมีโครงสร้างพื้นฐานอินเทอร์เน็ตเป็นของตัวเอง ก็สามารถเปิดพอร์ตจากบ้านหรือรันเว็บไซต์เป็น Tor hidden service ได้
    ตั้งค่าพอร์ตใน torrc ก็ไม่ได้ยาก แต่ผู้เข้าชมก็ต้องใช้ Tor Browser ด้วย และอธิบายยากว่าเว็บไซต์อยู่บน ‘ดาร์กเว็บ’ นะ ทั้งที่มันรันจากฮาร์ดแวร์ที่เราครอบครองอยู่ที่บ้านและยังซ่อน IP ของเซิร์ฟเวอร์ได้ด้วย เลยแปลกใจที่ฝั่งเว็บอิสระยังไม่ใช้กันแพร่หลายกว่านี้ และยังสามารถรีไดเร็กต์โดเมนปกติไปยังที่อยู่ .onion ได้ด้วย
    Beaker Browser ที่เคยให้สร้างและโฮสต์เว็บไซต์จากในเบราว์เซอร์โดยตรงเลิกพัฒนาไปแล้ว แต่ถ้ามีเครื่องมืออย่างปลั๊กอินสร้างเว็บไซต์สำหรับ Tor ก็น่าจะช่วยให้แพร่หลายขึ้น

    • บริการ .onion เปิดใช้งานได้ง่าย ปลอดภัยกว่าเว็บทั่วไป และรันบนโทรศัพท์มือถือได้ด้วย
      Nanogram: https://gitlab.com/here_forawhile/nanogram
      Spreadsheet Server: https://gitlab.com/here_forawhile/spreadsheet
      Library Server: https://gitlab.com/here_forawhile/libraryserver
      Torum: https://gitlab.com/here_forawhile/torum
    • Tor Browser รองรับ Onion-Location และ Alt-Svc เพื่อให้ค้นพบที่อยู่ .onion ได้จากอินเทอร์เน็ตปกติ โดย Onion-Location ให้เว็บไซต์ HTTPS ปกติประกาศ Onion service ของตัวเอง ส่วน Alt-Svc จะค้นพบและสลับไปใช้โดยอัตโนมัติโดยไม่ต้องให้ผู้ใช้ทำอะไรเพิ่ม
      ในอนาคตก็อาจมีความเป็นไปได้ของการเชื่อมต่อ Onion ที่อิง DNS หรือ DNSSEC ด้วย: https://onionservices.torproject.org/research/proposals/usab...
    • อย่าปล่อยให้ความสมบูรณ์แบบกลายเป็นศัตรูของสิ่งที่ดีพอ ในความเป็นจริงที่เรายังต้องพึ่งผู้ให้บริการเครือข่ายและผู้ผลิตอุปกรณ์ NearlyFreeSpeech จึงเป็นทางประนีประนอมที่ความเสี่ยงต่ำ ไม่เคยมีประวัติเอาความเชื่อใจของผู้ใช้ไปใช้ในทางที่ผิด และค่าใช้จ่ายก็แทบจะเล็กน้อยมาก
    • Tor ไม่ใช่เบราว์เซอร์ แต่เป็น บริการ ส่วน Tor Browser เป็นเพียงแพ็กเกจอำนวยความสะดวกที่รวมเบราว์เซอร์เน้นความเป็นส่วนตัวกับบริการ Tor เข้าด้วยกัน ดังนั้นบนเซิร์ฟเวอร์แบบเฮดเลสก็สามารถรันเว็บไซต์ Tor ได้โดยไม่ต้องมีเบราว์เซอร์
    • เหตุที่ hidden service ยังพบไม่มาก เป็นเพราะมันเรียกร้องความพยายามจากผู้เข้าชมมากเกินไป ความต่างด้านการเข้าถึงระหว่างการบอกว่า myfirstnamelastname.com กับการส่งที่อยู่ .onion แบบสุ่มยาว 56 ตัวอักษรพร้อมให้ติดตั้ง Tor Browser บนมือถือด้วยนั้นใหญ่มาก
  • อุปสรรคใหญ่ที่สุดในบริบทนี้คือ ชื่อโดเมน ที่จำเป็นต่อการเป็นเจ้าของคอนเทนต์ ซึ่งถึงจะถูกก็ยังมีค่าใช้จ่ายราว 6 ดอลลาร์ต่อปี เว็บไซต์แบบสแตติกนั้นโฮสต์ฟรีได้จากหลายที่มาก และสำหรับบุคคลทั่วไป ฟรีเทียร์ของ CDN ก็เพียงพอแล้ว
    สิ่งที่สำคัญกว่าการโฮสต์เซิร์ฟเวอร์เองคือการเป็นเจ้าของโดเมนในฐานะตัวระบุที่ไม่ซ้ำกัน ส่วนโดเมนนั้นจะชี้ไปที่ไหนสำคัญน้อยกว่ามาก

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

    • นี่เป็นยุคที่มีคนจำนวนมากไม่รู้ด้วยซ้ำว่าไฟล์คืออะไร ดังนั้นการสืบทอดแนวคิดแบบนี้จึงสำคัญ
    • น่าเศร้าที่ทั้งอินเทอร์เน็ตกลายเป็นสัตว์ประหลาดที่ถูกโฮสต์และควบคุมโดยบริษัทยักษ์ใหญ่ไม่กี่แห่ง จนต้องมีแนวคิดใหม่อย่าง IndieWeb ขึ้นมา การโฮสต์ไฟล์ไม่ควรเป็นสิทธิพิเศษ แต่เดิมทีควรใกล้เคียงกับสิทธิพื้นฐานของมนุษย์ด้วยซ้ำ
      เทคโนโลยีสำหรับโฮสต์เองยังมีอยู่เหมือนเดิม แต่กรอบความคิดได้เปลี่ยนไปเป็นแบบคลาวด์ล้วนแล้ว
    • สมัยก่อนแค่ใส่ไฟล์ไว้ในโฟลเดอร์ public_html ก็มีเว็บไซต์ส่วนตัวได้ทันที ไม่ได้หมายความว่าต้องเขียน HTML ด้วยมือตลอดไป แต่ตอนนั้นมันเป็นวิธีเข้าร่วมกับเว็บที่รวดเร็วและเป็นธรรมชาติ
      บัญชี Unix ยังมี finger ให้ดูว่าเพื่อนออนไลน์อยู่ไหม และมี talk หรือ ytalk ให้คุยกันแบบแชตระหว่างบุคคลด้วย แม้เพื่อนจะนั่งอยู่ที่เทอร์มินัลข้าง ๆ ก็ยังรู้สึกเหมือนเวทมนตร์
    • อยากรอให้เด็ก ๆ ได้รู้จัก ฮาร์ดแวร์ กันก่อน
  • ถ้า NearlyFreeSpeech ที่จ่ายวันละ 0.01 ดอลลาร์ถือว่าเป็นการดำเนินการแบบ "อิสระ 100%" ก็ดูเหมือนไม่ต่างจาก static hosting ของ Vercel, Netlify, GitHub, Cloudflare มากนัก
    ในบทความไม่ได้บอกว่าทำอย่างไรเมื่อต้องการฐานข้อมูล แบบฟอร์มฟีดแบ็ก พรีวิวโซเชียลมีเดีย หรือการปรับแต่งให้เหมาะกับเสิร์ชเอนจิน หรือบางทีการไม่มีสิ่งเหล่านี้อาจเป็นเงื่อนไขของ "เว็บอิสระ" ก็ได้

    • บน NearlyFreeSpeech สามารถใช้ PHP และฐานข้อมูล ได้
    • ถ้า NFS กับ Vercel ไม่ต่างกันมาก ก็น่าจะมีผู้ใช้แบ่งกันคนละครึ่ง เลยสงสัยว่าทำไมคนส่วนใหญ่ถึงเลือก Vercel
    • NFS ให้สภาพแวดล้อม Linux เต็มรูปแบบที่ติดตั้งหลายภาษาโปรแกรมมาแล้ว จึงรองรับ เว็บไซต์แบบไดนามิก ด้วย แต่มีค่าใช้จ่ายสูงกว่า
    • เคยมีคนโดน บิล Netlify มูลค่า 100,000 ดอลลาร์ จากแพ็กเกจฟรีด้วย
  • ต้องการโดเมนสำหรับเว็บไซต์งานอีเวนต์ และ Infomaniak ก็ให้พื้นที่เก็บข้อมูล 10MB มาพร้อมโดเมนด้วย จ่ายราว 5 ยูโรต่อปีก็มีทั้งโดเมนและเว็บไซต์แล้ว ถือว่าไม่เลว

  • ผมทำปลั๊กอิน JavaScript สำหรับคอมเมนต์ที่เก็บข้อมูลทั้งหมดไว้ใน Git repository https://github.com/est/req4cmt ถ้าบริการ Git รองรับ HTTP ก็ใช้ได้ และมันรันบน Cloudflare Worker แบบฟรี การสำรองข้อมูลและย้ายระบบก็จบด้วย git clone และ push
    ยังมีโปรเจ็กต์ทางเลือกแทน Twitter ที่อิง Git ด้วย: https://github.com/est/gitweets
    เดโมอยู่ที่ https://f.est.im/ และรองรับคอมเมนต์ด้วย Git notes ทั้งหมดนี้ฟรีล้วน ๆ เพราะใช้ Cloudflare Workers และ GitHub Pages

  • sdf.org มีประโยชน์สำหรับนักพัฒนาที่อยากเรียนรู้ระบบ Unix ด้วยตัวเอง ที่จำได้คือมีบัญชีเชลล์ NetBSD Unix ให้ใช้ฟรี และสามารถใช้พื้นที่เว็บกับฟีเจอร์เพิ่มได้ด้วยการบริจาคครั้งเดียวจำนวนเล็กน้อย
    ชื่อที่ใช้ล็อกอินจะกลายเป็นซับโดเมนของพื้นที่เว็บ จึงควรเลือกให้ดี

  • ดีใจที่เว็บไซต์ที่อ้างแบบนี้ไม่ได้โฮสต์อยู่บน Cloudflare หรือ GitHub Pages

    • GitHub Pages เป็นโฮสติ้งฟรีที่ให้ทั้งโดเมนและ SSL ไม่มีการคิดค่าบริการเพิ่ม และแนวโน้มระยะยาวก็ดูดี ถ้าไม่อยากปวดหัวกับเว็บไซต์แบบสแตติก ผู้ให้บริการรายใหญ่อย่าง GitHub และ Cloudflare ก็ดูจะเหมาะที่สุด
    • ผมแนะนำ GitHub Pages บ่อย แต่ก็เคยเขียนวิธีโฮสต์ด้วย Raspberry Pi ในห้องนอนด้วย: https://joeldare.com/private-analytics-and-my-raspberry-pi-4...
    • ขอบคุณที่ Cloudflare ยังคอยพยุงเว็บไซต์ละเมิดลิขสิทธิ์เหล่านั้นไว้
    • Vercel กับ Netlify ก็เหมือนกัน
  • ผมชอบ เรียนรู้และเป็นเจ้าของกระบวนการ มากกว่าจะยึดติดกับเครื่องมือใดเครื่องมือหนึ่ง ใช้เครื่องมืออย่าง Pandoc สร้าง HTML จากฟอร์แมตที่อ่านเขียนง่ายอย่าง Markdown เรียนรู้วิธีอัปโหลดหรือซิงก์ HTML, CSS, JavaScript ไปยังบริการโฮสติ้ง และเรียนรู้การเป็นเจ้าของโดเมนกับการชี้ DNS ไปที่ GitHub Pages หรือ Cloudflare Pages ก็พอ
    แบบนี้จะไม่ต้องผูกติดกับเครื่องมือ บริการ แพลตฟอร์ม หรือบริษัทใดบริษัทหนึ่ง และสามารถย้ายไฟล์คอนเทนต์ไปที่อื่นได้ทุกเมื่อ กระบวนการแปลง Markdown ต้นฉบับเป็น HTML ก็สามารถทำอัตโนมัติด้วย static site generator ได้
    การรู้ HTML มีประโยชน์และสนุก แต่ไม่จำเป็นต้องเป็นเงื่อนไขบังคับของการ "ดูแลเว็บไซต์อย่างอิสระ 100%" จะรันบน GitHub กับ Cloudflare ฟรีเดือนละ 0 ดอลลาร์ก่อนก็ได้ แล้วถ้าบริการปิดหรือเริ่มคิดเงิน ค่อยย้ายออกก็พอ

    • ประเด็นสำคัญของบทความคือ ถ้าเก็บโพสต์เป็น ไฟล์ HTML แยกแต่ละไฟล์ แทนที่จะเป็น Markdown หรือรายการในฐานข้อมูล ก็จะมอบสไตล์ หน้าตา เลย์เอาต์ และเอกลักษณ์เฉพาะให้แต่ละหน้าได้ สามารถหลุดจากกรอบบล็อกหน้าตาเหมือนกันไปหมดที่เครื่องมือเผยแพร่สมัยใหม่สร้างขึ้น และทำให้ทุกโพสต์แตกต่างกันได้
    • HTML เป็นฟอร์แมตที่มนุษย์อ่านและเขียนได้ง่าย แม้ก่อนจะมีเครื่องมือที่เหมาะสม คนที่ไม่ได้เรียนวิทยาการคอมพิวเตอร์ก็ยังจัดการ HTML, JavaScript, CSS ในโปรแกรมแก้ไขข้อความโดยตรง และถ้าเป็นเว็บง่าย ๆ ก็ไม่ได้ยาก
      ถ้าต้องการเป็นเจ้าของกระบวนการและความเป็นอิสระอย่างแท้จริง ก็ต้องเข้าใจและใช้งานภาษาเว็บเหล่านี้ได้ด้วยตัวเอง static site generator อย่าง Nikola สะดวกก็จริง แต่ถ้ายังไม่เข้าใจผลลัพธ์ที่มันสร้างหรือแก้ไขเองไม่ได้ ก็ยังถือว่าพึ่งพาเครื่องมือของบุคคลที่สามอยู่ดี