พอทำงานพัฒนาไปสักพัก ผมมักมีเรื่องให้ต้องแชร์ไฟล์กันชั่วคราวอยู่บ่อย ๆ
ยกตัวอย่างเช่น ต้องการแชร์ไฟล์ภายในเครื่องอย่างรวดเร็ว (เช่น AI checkpoint หรือข้อมูลสำหรับเทรน เป็นต้น) ซึ่งไฟล์พวกนี้มักมีขนาดใหญ่ ทำให้การส่งผ่านบริการคลาวด์เดิม ๆ ช้า และเซิร์ฟเวอร์ Python เองก็บางครั้งล่ม(?) จนน่ารำคาญ เลยอยากได้ local file server ที่เปิดแชร์ชั่วคราวผ่าน Curl/Wget ได้ จึงทำขึ้นมาครับ
ถ้าพูดถึงจุดเด่น ก็มีหลัก ๆ อยู่ประมาณ 4 ข้อ
ข้อแรก รองรับหลายแพลตฟอร์ม – อันที่จริงข้อนี้ก็ทำมาเพื่อให้ตัวเองสะดวกด้วย แต่สำหรับคนที่สลับไปมาระหว่าง Linux กับ Windows อย่างผม ความอยากใช้คำสั่งเดียวกันนี่ตัดใจไม่ได้จริง ๆ…
ข้อสอง Web UI – มีเว็บเซิร์ฟเวอร์ขนาดเล็กสไตล์ Apache ฝังมาให้เป็นค่าเริ่มต้น โดยทำให้ผู้ใช้สามารถดาวน์โหลดไฟล์จากโฟลเดอร์ที่แชร์ไว้ หรือเปิดดูไฟล์บางประเภทที่เบราว์เซอร์รองรับได้ทันที (เช่น html, txt เป็นต้น)
ข้อสาม ไม่ต้องติดตั้ง runtime เพิ่มเติม – ตอนแรกก็เคยพิจารณา express server เหมือนกัน แต่ผมใช้ LXC บ่อย จึงรู้สึกว่าการต้องติดตั้ง runtime อย่าง Node เพิ่มต่างหากมันไม่สะดวก อีกทั้งบน Windows เวลาจะเปิด VM ก็ต้องมานั่งตั้งค่าใหม่ทุกครั้ง ซึ่งก็น่ารำคาญเหมือนกัน
ข้อสี่ เซิร์ฟเวอร์ไฟล์ขนาดไม่เกิน 5MB – ตัดทุกอย่างออก เหลือไว้แค่ “การส่งไฟล์” เลยทำให้ขนาดไฟล์จริงไม่เกิน 5MB (ตัวที่ใหญ่ที่สุดคือ Linux x86 4.12MB ตามบิลด์เวอร์ชัน 1.0.0)
โปรแกรมนี้เป็นตัวที่ผมใช้งานจริงอยู่แล้ว และจากที่ผมสร้างเองใช้เอง พบว่ามันสะดวกมากเวลาต้องแชร์ไฟล์ ISO, รูปภาพขนาดใหญ่ หรือ PDF แบบชั่วคราวภายในเครือข่ายภายใน
ตัวอย่างการแชร์โฟลเดอร์ : ./saibius –file ./share
เว็บไซต์ : https://saibius.com/
GitHub : https://github.com/saibius/docs
P.s ขายอยู่ที่ราคา 4,900 วอน แต่จะแจกคีย์ฟรีให้ 10 คนแรก
หากเข้าไปที่ลิงก์ https://saibius.com/redeem?key=SAIBIUS-2026-R1 ระบบจะกรอกให้อัตโนมัติ :)
20 ความคิดเห็น
ดูเหมือนจะเป็นพวกเดียวกับ copyparty นะ
สวัสดีครับ
หวังว่าคุณกำลังมีวันที่ดีนะครับ?
ช่วงสุดสัปดาห์ผมมีธุระอยู่ เลยมาตรวจดูช้าไปหน่อยครับ..
จุดประสงค์พื้นฐานคือออกแบบมาให้คล้ายกับ Copyparty ครับ
ตอนพัฒนานั้นผมยังไม่รู้ว่ามีโปรเจกต์แบบนี้อยู่ และเพิ่งมาทราบจากคอมเมนต์ต่าง ๆ ครับ
ถ้าจะพูดถึงความแตกต่างที่ผมมองไว้
ในยูสเคสของเรา มีหลายครั้งที่ต้องใช้งานบนเซิร์ฟเวอร์เครือข่ายภายใน
ซึ่งติดตั้งรันไทม์เพิ่มเติมได้ยาก จึงทำให้บนอุปกรณ์ที่ใช้แชร์สามารถใช้งานได้โดยไม่ต้องพึ่งรันไทม์แยกต่างหาก (เช่น Python runtime, แพ็กเกจเพิ่มเติม ฯลฯ) ซึ่งเป็นจุดเด่นครับ
บนเซิร์ฟเวอร์ส่วนใหญ่จะมี Python ติดมาอยู่แล้ว แต่ในสภาพแวดล้อมของเราเป็นแบบที่รันด้วยแพ็กเกจน้อยที่สุดเท่านั้น เช่น LXC ดังนั้นส่วนนี้คงขึ้นอยู่กับสภาพแวดล้อมและยูสเคสของแต่ละที่ครับ
ต่อจากนี้ Saibius จะพัฒนาต่อไปเรื่อย ๆ ครับ
ขอบคุณที่ให้ความสนใจครับ
ขอให้เป็นวันที่ดีนะครับ :)
มีแผนจะรองรับสภาพแวดล้อม termux บน Android ในอนาคตด้วยไหมครับ?
เวลาที่ต้องส่งไฟล์จาก Android ไปยังสภาพแวดล้อมอื่น ถ้าใช้ croc ได้ก็จะใช้ croc แต่ถ้าต้องเข้าถึงผ่านเว็บเบราว์เซอร์หรือ
curl,wgetก็ปกติจะใช้ Copyparty เป็นหลัก แต่ถ้าจะแชร์แบบง่าย ๆ ตัวนี้ก็ดูน่าสนใจเหมือนกันครับสวัสดีครับ!
หวังว่าคุณกำลังมีวันหยุดที่ดีนะครับ?
ในอัปเดตย่อย 1.0.0.11 ที่หลายคนรอคอย ได้เพิ่มบิลด์สำหรับ Termux (Android) แล้ว!
อัปเดตนี้เผยแพร่เมื่อวันที่ 12 กุมภาพันธ์ และใช้เวลาสักพักกับการปรับเสถียรภาพ จึงเพิ่งได้เข้ามาตอบตอนนี้ครับ
ต่อจากนี้ Saibius จะพัฒนาต่อไปเรื่อย ๆ ครับ
ขอบคุณที่ให้ความสนใจ
ขอให้เป็นวันที่ดีครับ :)
โอ้ ขอบคุณสำหรับข้อมูลครับ!
สวัสดีครับ!
คืนนี้สบายดีกันไหมครับ?
เรามีแผนจะปล่อยอัปเดตย่อย 1.0.0.11 ที่หลายท่านรอคอย พร้อมเพิ่มบิลด์สำหรับ Termux(Android) ครับ
แม้จะล่าช้ากว่าที่คาดไว้เล็กน้อย แต่เราได้ยืนยันแล้วว่าสามารถทำงานได้ตามปกติบนเวอร์ชันล่าสุดของ Play Store
ขณะนี้กำลังเตรียมการเพื่อให้ปล่อยได้อย่างปลอดภัย รบกวนรออีกสักนิดนะครับ!
ต่อจากนี้ Saibius จะพัฒนาต่อไปอย่างต่อเนื่องครับ
ขอบคุณที่ให้ความสนใจครับ
ขอให้มีวันที่ดีนะครับ :)
สวัสดีครับ
คืนนี้สบายดีกันไหมครับ?
ในสภาพแวดล้อม Android termux ที่คุณบอกมา ตอนนี้ยังไม่ได้มีการทดสอบอย่างเป็นทางการ แต่ได้รวมไว้ในแผนสำหรับการพัฒนาและทดสอบเพิ่มเติมในภายหลังแล้วครับ
พอการทดสอบเสร็จเรียบร้อยแล้ว ผมจะรีบมาตอบกลับให้เร็วที่สุดครับ :b
แล้วก็ขอบคุณมากครับที่แนะนำเครื่องมือดี ๆ อย่าง Copyparty กับ Croc ไว้ให้รู้จัก คงต้องไปศึกษารายละเอียดของเครื่องมือพวกนี้เพิ่มเติมเหมือนกัน...
ต่อจากนี้ Saibius จะพัฒนาต่อไปเรื่อย ๆ ครับ
ขอบคุณที่ให้ความสนใจครับ
ขอให้เป็นวันที่ดีครับ :)
สำหรับการแชร์เอกสารเว็บภายในบริษัท ผมใช้เว็บเซิร์ฟเวอร์แบบบิลต์อินของ Python ครับ
สวัสดีครับ
ขอให้เป็นช่วงบ่ายที่ดีนะครับ?
ผมคิดว่า Python web server ก็เป็นเครื่องมือที่ดีมากจริง ๆ ครับ!
จริง ๆ แล้วฝั่งเราก็เคยอยู่ในสถานการณ์ที่ใช้ web server แบบ built-in ของ Python เหมือนกัน แต่ทางเราต้องจัดการไม่ใช่แค่เอกสารเว็บเท่านั้น ยังรวมถึงข้อมูลสำหรับฝึก AI และไฟล์ checkpoint (
.safetensors,.ckptเป็นต้น) ด้วย จึงพบว่ากับไฟล์ขนาดหลายร้อย GB ถึงหลาย TB บางครั้งการเชื่อมต่อก็มักหลุดหรือไม่เสถียรครับสำหรับเรื่องนี้ เราก็มีการใช้งาน NAS เป็นทางเลือกอยู่เหมือนกัน แต่สำหรับไฟล์ขนาดใหญ่มาก ๆ การส่งตรงจากอุปกรณ์ที่เก็บไฟล์ไว้เลยก็เร็วกว่าการอัปโหลด > เซิร์ฟเวอร์ > ดาวน์โหลดอยู่ดี เลยเป็นที่มาของโปรแกรมนี้ ดังนั้นจริง ๆ แล้วเครื่องมือที่เหมาะกับสภาพแวดล้อมของตัวเองที่สุดน่าจะดีที่สุดครับ
ขอให้เป็นวันที่ดีนะครับ :)
ถ้าใช้เพื่อจุดประสงค์แบบนั้นก็น่าจะเป็นตัวเลือกที่ดีนะครับ มีฟีเจอร์เข้ารหัสไหมครับ? มีความสามารถในการเข้ารหัสตอนจัดเก็บ และถอดรหัสตอนแชร์หรือเปล่าครับ?
สวัสดีครับ! ขอบคุณสำหรับคำถามดี ๆ ครับ
ในเวอร์ชันปัจจุบัน ยังไม่รองรับ "ฟีเจอร์การเข้ารหัส" และ "ฟีเจอร์การจัดเก็บ / การเข้ารหัส" ที่คุณกล่าวถึงครับ
จริง ๆ แล้วเราเคยพิจารณาเรื่องนี้ในช่วงเริ่มพัฒนา แต่เนื่องจากเป็นเครื่องมือที่ออกแบบมาเฉพาะสำหรับ "การส่งไฟล์ชั่วคราวภายในเครือข่ายภายใน" และในสภาพแวดล้อมที่มีการแชร์ข้อมูลขนาดใหญ่ ภาระจากการเข้ารหัสอาจส่งผลต่อความเร็วในการส่งข้อมูล
จึงน่าเสียดายที่ต้องตัดฟีเจอร์นี้ออกไปครับ
ในกรณีของเรา หากจำเป็นต้องใช้การเข้ารหัส เรามักจะใช้ฟีเจอร์การจัดเก็บแบบเข้ารหัสของ NAS เป็นหลักครับ
ขอบคุณที่ให้ความสนใจ Savious ครับ
ขอให้เป็นวันที่ดีครับ :)
[อัปเดต] แจ้งให้ทราบว่าคีย์ฟรีหมดแล้ว
ขอบคุณทุกท่านสำหรับความสนใจอย่างล้นหลาม!
ณ วันที่ 22 มกราคม 2026 เวลา 13:10 คีย์ฟรีทั้งหมดได้ถูกใช้หมดแล้ว
[คีย์ที่หมดแล้ว]
คีย์ฟรีชุดแรก (R1), U1 และ C1 ที่แจกเพิ่มเติมภายหลัง
ด้วยแรงสนับสนุนจากทุกท่าน เราจะพัฒนา
Savius ให้ดียิ่งขึ้นต่อไป
ขอบคุณครับ
[อัปเดต] ขอบคุณสำหรับความสนใจอย่างมาก!
คีย์ฟรีชุดแรกถูกใช้หมดอย่างรวดเร็ว และบางท่านพบข้อผิดพลาดในการ Redeem
เราได้แก้ไขปัญหาแล้วและมอบเพิ่มอีก 20 คีย์
https://saibius.com/redeem?key=SAIBIUS-2026-U1
https://saibius.com/redeem?key=SAIBIUS-2026-C1
หากท่านพบข้อผิดพลาดจากโค้ดก่อนหน้านี้ กรุณาลองใหม่อีกครั้งด้วยโค้ดใหม่!
รู้สึกว่า selling point ยังไม่ค่อยชัด เลยขอฝากฟีดแบ็กไว้ครับ/ค่ะ ความจำเป็นของเว็บ UI ยังถูกอธิบายได้ไม่ค่อยน่าเชื่อเท่าไร ถ้าเทอร์มินัลเป็นอินเทอร์เฟซหลัก ก็สามารถรันแอปที่เปิดไฟล์ที่รับมาด้วยคำสั่งได้ทันทีไม่ใช่หรือ เช่น
firefox <html_file>หรือcat <text_file>น่าจะลดขนาดไบนารีลงได้อีกพอสมควร ถ้าจะทำให้เป็นมิตรกับ GUI มากขึ้น การเพิ่ม shortcut ลงในเมนูคลิกขวาของ explorer หรือ finder บนแต่ละแพลตฟอร์มก็น่าจะดีเช่นกัน ถ้าถอดเว็บ UI ออกได้ ก็น่าจะถูกนำไปเปรียบเทียบกับ https://github.com/schollz/croc ได้ครับ/ค่ะ เป็นเครื่องมือที่ผม/ฉันใช้เป็นหลักอยู่พอดี โดยไม่ต้องมีรันไทม์แยก การส่งภายในเครื่องก็เร็วพออยู่แล้ว และยังรองรับการส่งระยะไกลแบบ relay p2p พร้อม e2e encryption รวมถึงรองรับการส่งต่อจากจุดเดิม (resume) ด้วยขอบคุณสำหรับฟีดแบ็กดี ๆ ครับ!
ดูเหมือนว่าการเพิ่มส่วนช็อตคัต GUI จะเป็นสิ่งที่ดีครับ
ก่อนอื่น ผมขอตอบในประเด็นที่คุณกล่าวมานะครับ
ความจำเป็นของ WebUI
แม้ว่าเทอร์มินัลจะเป็นอินเทอร์เฟซหลัก แต่โปรแกรมนี้ถูกออกแบบมาให้สามารถแชร์ให้สมาชิกทีมอย่างนักการตลาด นักออกแบบ และคนอื่น ๆ ที่ไม่คุ้นเคยกับสภาพแวดล้อมเซิร์ฟเวอร์หรือเทอร์มินัลใช้งานได้ด้วย ดังนั้นเราจึงตั้งใจจะใช้ WebUI เป็นจุดแตกต่าง
ส่วนที่เกี่ยวกับการเปิดไฟล์
โปรแกรมนี้โดยพื้นฐานแล้วเน้นไปที่ "เซิร์ฟเวอร์แชร์ไฟล์ชั่วคราว" จึงไม่ได้สั่งรันแอปพลิเคชันที่ใช้เปิดไฟล์นั้นโดยตรงครับ โดยปกติแล้วนามสกุลไฟล์ที่เราใช้กันมักมีกรณีที่หลายโปรแกรมใช้ร่วมกันสำหรับนามสกุลเดียวกัน
ความแตกต่างจาก CROC
หากจะพูดถึงความแตกต่างที่ใหญ่ที่สุดจากเครื่องมือที่คุณกล่าวถึง ก็น่าจะเป็นการรองรับ Zero-Copy และการปรับแต่ง dynamic buffer ให้เหมาะสม (ปรับขนาดบัฟเฟอร์ตามไฟล์) ครับ เครื่องมือนี้เองก็เคยใช้ HttpRange เพื่อรองรับ IDM (หรือ FDM) เป็นพื้นฐานอยู่แล้ว
ฟังก์ชันช็อตคัตที่คุณพูดถึงดูเป็นไอเดียที่ดีมากครับ ผมจะลองศึกษาเพื่อให้สามารถนำไปปรับใช้ในการอัปเดตครั้งถัดไปได้
ขอให้เป็นวันที่ดีนะครับ! :)
พารามิเตอร์ที่ไม่มีแฟล็ก
--fileไม่ควรถูกมองว่าเป็นทรัพยากรที่จะแชร์เหรอ?ขอบคุณมากสำหรับฟีดแบ็กดี ๆ!
เกี่ยวกับแฟลก
--fileพวกเราก็รับทราบประเด็นนี้อยู่เช่นกัน และในเวอร์ชันแรกเริ่มนั้นสามารถแชร์ไฟล์ได้แม้ไม่ต้องใช้แฟลกอย่างไรก็ตาม ระหว่างกระบวนการเบต้าเทสต์ มีข้อกังวลว่า "ด้วยลักษณะที่ไฟล์ถูกแชร์ได้ทันที ผู้ใช้อาจเผลอแชร์พาธที่ไม่ถูกต้องจากคลิปบอร์ดผ่านการคัดลอกและวางโดยไม่ได้ตั้งใจ" จึงได้เพิ่มขั้นตอนการป้อนข้อมูลอีกหนึ่งชั้น และ ณ ตอนนี้จึงเปลี่ยนมาให้ต้องระบุแฟลก
--fileอย่างชัดเจนอย่างที่คุณบอก ในแง่ความสะดวกก็เห็นด้วยว่าการให้ทำงานได้โดยไม่ต้องมีแฟลกอาจจะดีกว่า เรากำลังทดสอบต่อเนื่องว่าจะปรับสมดุลระหว่างความปลอดภัยกับความสะดวกอย่างไร
ฟังก์ชันให้ละแฟลก
--fileได้ตามที่คุณเสนอ น่าจะเป็นไอเดียที่ดีขอบคุณสำหรับไอเดียดี ๆ ครับ :)
ขอให้มีวันที่ดีครับ :)
ผมไม่แน่ใจว่ากลุ่มผู้ใช้เป้าหมายของเซิร์ฟเวอร์นี้คือฝั่งนักพัฒนาหรือผู้ใช้ทั่วไป ถ้ากลุ่มเป้าหมายเป็นนักพัฒนา การป้องกันการวางพาธผิดก็ดูเป็นภาระที่เกินจำเป็น แต่ถ้าเป็นผู้ใช้ทั่วไป ก็มีความไม่สะดวกที่ต้องเปิดหน้าต่างคำสั่งแล้วพิมพ์แฟล็ก
--fileเอง ถ้าไม่มีแฟล็ก--fileก็จะต้องยอมทิ้งวิธีที่แชร์ได้ทันทีด้วยการลากโฟลเดอร์จากตัวสำรวจไฟล์ไปวางบนไฟล์ปฏิบัติการ เพื่อความสะดวกจึงอาจนึกถึงการเพิ่มเมนูเข้าไปในเมนูระบบ แต่เมนูลัดนั้นจะได้ใช้สักกี่ครั้งต่อเดือนกัน?ขอบคุณสำหรับข้อเสนอแนะเพิ่มเติมครับ
อย่างที่คุณกล่าวไว้ ผมคิดว่านี่เป็นส่วนที่ไม่อาจมองข้ามได้ ทั้งในแง่การใช้งานของนักพัฒนาและความสะดวกสำหรับผู้ใช้ทั่วไป
อย่างไรก็ตาม ในตอนนี้เรามองว่าการคงเวิร์กโฟลว์ที่เสถียรของผู้ใช้เดิมไว้เป็นลำดับความสำคัญก่อน
ไอเดียที่คุณเสนอมา เช่น "ละเว้นแฟลก" หรือ "ปรับปรุงอินเทอร์เฟซ" จะนำไปพิจารณาอย่างรอบคอบในช่วงการอัปเดตครั้งใหญ่ในอนาคต โดยอยู่บนพื้นฐานที่ไม่กระทบความเข้ากันได้ย้อนหลัง
ขอบคุณที่ให้ความสนใจครับ
CROC ที่คุณพูดถึงเป็นเครื่องมือที่ยอดเยี่ยม แต่ฝั่งอุปกรณ์ผู้รับก็จำเป็นต้องติดตั้ง CROC และต้องสามารถใช้บรรทัดคำสั่งได้ ขณะที่เครื่องมือของพวกเรารองรับ Wget/Curl พร้อมทั้งมี webUI จึงทำให้เพื่อนร่วมทีมที่ไม่ใช่นักพัฒนาก็ใช้งานได้ง่ายผ่านเบราว์เซอร์อย่างเดียว
ขอบคุณมากสำหรับไอเดียเรื่องทางลัด! ผมเองก็ลืมไปเหมือนกันว่าฟีเจอร์แบบนี้สามารถทำได้
ขอให้เป็นวันที่ดีครับ :)