ทำไม X Window System จึงใช้เซิร์ฟเวอร์

25

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

xorg x11 x-server

— Aadit M Shah
แหล่งที่มา

2

ท่อที่มีชื่อจะไม่ง่ายกว่าเพราะท่อนั้นใช้สำหรับการสื่อสารทางเดียวเท่านั้น หากคุณต้องการการสื่อสารสองทางคุณใช้ซ็อกเก็ตมากกว่าไปป์ และจริงๆแล้วระบบใหม่บางระบบใช้ซ็อกเก็ตชื่อ (โดเมน unix) โดยค่าเริ่มต้นแทนที่จะเป็นซ็อกเก็ต TCP ตัวอย่างเช่นบน Ubuntu 14.04, X ถูกกำหนดค่าให้ไม่ฟังบนซ็อกเก็ต TCP โดยค่าเริ่มต้น

— kasperd

5

Unix และ X พัฒนาขึ้นก่อนที่พีซีจะมีประสิทธิภาพและราคาถูกในแบบที่คุณมักจะมีเทอร์มินัลค่อนข้างง่ายจำนวนมากที่เชื่อมต่อกับคอมพิวเตอร์หนึ่งหรือสองเครื่องที่มีประสิทธิภาพมากขึ้น แผนกนี้ดำเนินการกับ X: คุณมี "เทอร์มินัล" - คอมพิวเตอร์ราคาถูกง่าย ๆ พร้อมกราฟิกการ์ด - ใช้งานเพียงเซิร์ฟเวอร์ X และรวบรวมข้อมูลจากเมาส์ / คีย์บอร์ดและวาดหน้าจอ ... โปรแกรมจริง (X- ลูกค้า) ในอีกทางหนึ่งรันบนคอมพิวเตอร์ที่มีประสิทธิภาพอย่างน้อยหนึ่งเครื่องขึ้นไป - ใช้ร่วมกันโดยผู้ใช้ทั้งหมดโดยใช้เทอร์มินัล ดังนั้นการแยก X ออกเป็นสองส่วน (ซึ่งสามารถแยกออกจากกัน) ได้อย่างสมเหตุสมผล

— Baard Kopperud

@ BaardKopperud X Terminals มาหลายปีหลังจาก X Window เริ่มได้รับความนิยมดังนั้นพวกเขาจึงไม่สามารถเป็นเหตุผลว่าทำไม X Window ได้รับการออกแบบในแบบนั้น X เริ่มต้นด้วยเวิร์กสเตชัน Unix ที่ใช้งานมากกว่าเซิร์ฟเวอร์ X

— jlliagre

39

ฉันคิดว่าคุณสังเกตเห็นแล้วว่าจำเป็นต้องมี "เซิร์ฟเวอร์" บางประเภท ไคลเอนต์แต่ละตัว (สภาพแวดล้อมเดสก์ท็อปผู้จัดการหน้าต่างหรือโปรแกรมที่มีหน้าต่าง) จำเป็นต้องแชร์จอแสดงผลกับคนอื่น ๆ ทั้งหมดและพวกเขาต้องสามารถแสดงสิ่งต่าง ๆ โดยไม่ทราบรายละเอียดของฮาร์ดแวร์หรือรู้ว่าใครใช้จอแสดงผล ดังนั้นเซิร์ฟเวอร์ X11 จะให้เลเยอร์ของสิ่งที่เป็นนามธรรมและการแบ่งปันที่คุณกล่าวถึงโดยการจัดเตรียมอินเตอร์เฟส IPC

X11 อาจถูกสร้างขึ้นเพื่อใช้กับท่อที่มีชื่อ แต่มีสองสิ่งใหญ่ที่ชื่อท่อไม่สามารถทำได้

ไปป์ที่มีชื่อจะสื่อสารในทิศทางเดียวเท่านั้น
หากทั้งสองกระบวนการเริ่มวางข้อมูลลงในส่วนท้าย "ส่ง" ของไปป์ที่มีชื่อข้อมูลจะได้รับการรวม

ในความเป็นจริงไคลเอนต์ X ส่วนใหญ่คุยกับเซิร์ฟเวอร์โดยใช้ไพพ์ที่มีชื่อ "ใหม่และปรับปรุง" ที่เรียกว่าซ็อกเก็ตโดเมน UNIX มันเหมือนกับท่อที่มีชื่อยกเว้นว่าจะให้กระบวนการพูดคุยทั้งสองทิศทางและติดตามว่าใครพูดอะไร สิ่งเหล่านี้เป็นสิ่งเดียวกันกับที่เครือข่ายต้องทำและซ็อกเก็ต UNIX โดเมนใช้อินเตอร์เฟสการเขียนโปรแกรมเดียวกันกับซ็อกเก็ต TCP / IP ที่ให้การสื่อสารเครือข่าย

แต่จากตรงนั้นเป็นเรื่องง่ายมากที่จะพูดว่า "จะเกิดอะไรขึ้นถ้าฉันเรียกใช้เซิร์ฟเวอร์บนโฮสต์อื่นที่ไม่ใช่ไคลเอนต์" เพียงแค่ใช้ซ็อกเก็ต TCP แทนซ็อกเก็ต UNIX และ voila: โปรโตคอลเดสก์ท็อประยะไกลที่ใช้ Windows RDP มาหลายสิบปี ฉันสามารถsshโฮสต์ระยะไกลที่แตกต่างกันสี่ตัวและเรียกใช้synaptic(ตัวจัดการแพ็คเกจกราฟิก) ในแต่ละโฮสต์และหน้าต่างทั้งสี่ปรากฏบนจอแสดงผลของคอมพิวเตอร์ในพื้นที่ของฉัน

— Jander
แหล่งที่มา

2

X ใช้ท่อที่มีชื่อในระบบ SysV โดยที่ท่อที่มีชื่อนั้นเป็นแบบสองทิศทางรวมถึง Solaris & SCO Unixes

— alanc

14

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

ไปป์ที่มีชื่อจะไม่ให้คุณประโยชน์โดยอัตโนมัติของความสามารถในการเรียกใช้ผ่านเครือข่ายตามที่ใช้งาน TCP จะทำ แต่ไปป์ที่ระบุชื่อไม่สามารถใช้งานได้บน DOS ด้วย DosExtender ที่รัน Desqview / X (1992) และ AFAIK ก็ไม่ได้อยู่ใน VMS สำหรับการใช้งานเหล่านั้นการสื่อสาร Unix ที่เฉพาะเจาะจงจะเป็นปัญหา

TCP ไม่ใช่ Unix ที่เฉพาะเจาะจงและเป็นไปได้ที่จะให้ไคลเอนต์ทำงานภายใต้ VAX / VMS (การพัฒนา X เริ่มต้นขึ้นในปี 1984) และให้บริการเอาต์พุตไปยังเวิร์กสเตชันกราฟิก UNIX ในพื้นที่ของคุณ จาก "X Window System: การอ้างอิงที่สมบูรณ์ถึง Xlib, X Protocol, ICCCM, XLFD" ¹:

ในช่วงฤดูใบไม้ร่วงปี 2529 ดิจิตอลตัดสินใจใช้กลยุทธ์เวิร์กสเตชันเดสก์ท็อปทั้งหมดสำหรับ ULTRIX, VMS และ MS-DOS บน X แม้ว่าสิ่งนี้จะทำให้เราพึงพอใจ ส่งผลให้เกิดความล่าช้าบ้าง แต่ในที่สุดก็ส่งผลให้การออกแบบดีขึ้น Ralph Swick of Digital เข้าร่วม Project Athena ในช่วงเวลานี้และมีบทบาทสำคัญในการพัฒนารุ่นที่ 11 มีการเผยแพร่รุ่นที่ 10 ครั้งล่าสุดในเดือนธันวาคม 2529

จาก "คู่มืออ้างอิงโปรโตคอล X" ²:

หมวดความรับผิดชอบ

ในกระบวนการออกแบบโพรโทคอล X มีความคิดมากในการแบ่งความสามารถระหว่างเซิร์ฟเวอร์และไคลเอนต์เนื่องจากสิ่งนี้เป็นตัวกำหนดว่าข้อมูลใดที่จะถูกส่งผ่านไปมาผ่านคำขอการตอบกลับและเหตุการณ์ แหล่งข้อมูลที่ยอดเยี่ยมเกี่ยวกับเหตุผลเบื้องหลังตัวเลือกบางอย่างที่เกิดขึ้นในการออกแบบโปรโตคอลเป็นบทความระบบ X Window โดย Robert W. Scheifler และ Jim Gettys ตีพิมพ์ในสมาคมบันทึกธุรกรรมทางคอมพิวเตอร์เกี่ยวกับกราฟิกฉบับที่ 5 ฉบับที่ 2 เมษายน 2529 การตัดสินใจในท้ายที่สุดขึ้นอยู่กับการพกพาของโปรแกรมไคลเอนต์ความสะดวกในการเขียนโปรแกรมไคลเอนต์และประสิทธิภาพ

ก่อนอื่นเซิร์ฟเวอร์ได้รับการออกแบบให้มากที่สุดเพื่อซ่อนความแตกต่างของฮาร์ดแวร์พื้นฐานจากแอปพลิเคชันไคลเอนต์ ...

ฉันจำบทความใน TOG ว่าเป็นการอ่านที่น่าสนใจ แน่นอนว่ามันกระตุ้นความสนใจของฉันใน X และ (นี่คือก่อนที่ WorldWideWeb) ความยากลำบากที่เราวางมือบนข้อมูลเพิ่มเติมจนกระทั่ง O'Reilly เริ่มเผยแพร่หนังสือ X ของพวกเขา

¹ _{X เวอร์ชั่น 11, รีลีส 4, หน้า 2-X, PDF ออนไลน์ได้ที่นี่}
² _{นี่คือหน้า 9 ในรุ่นที่ 2, จัดพิมพ์โดย O'Reilly, ที่ฉันซื้อในปี 1990 มีรุ่นใหม่กว่า แต่ฉันไม่เคยใส่ใจที่จะซื้อ เหล่านี้และพวกเขาเป็น AFAIK ที่มีอยู่ในกระดาษเช่นกัน ฉันไม่คิดว่าพวกเขาเปลี่ยนเหตุผลของการแบ่งความรับผิดชอบ}

— โธ
แหล่งที่มา

2

นอกจากนี้เรายังใช้เทอร์มินัล X เฉพาะที่ไม่มีดิสก์ระบายความร้อนแบบพาสซีฟและเปลี่ยนได้ทันทีซึ่งทั้งหมดนั้นยอดเยี่ยมถ้าคุณต้องการ 100 ที่นั่ง

— Simon Richter

7

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

ทรัพยากรอาจถูกควบคุมโดยเคอร์เนลและแอปพลิเคชันทำการเรียกเคอร์เนลเพื่อเข้าถึง
ทรัพยากรอาจถูกควบคุมโดยกระบวนการเฉพาะ (เซิร์ฟเวอร์) และแอปพลิเคชันติดต่อเซิร์ฟเวอร์เพื่อเข้าถึง

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

ตอนนี้สิ่งทั้งหมดอาจเข้าไปในเคอร์เนลซึ่งก็คือ AFAIK สิ่งที่ Windows ทำ นี่เป็นข้อได้เปรียบของการทำงานที่รวดเร็วกว่า (โดยปกติแล้วการเรียกเคอร์เนลจะเร็วกว่าการติดต่อกับกระบวนการอื่น) แต่ก็มีข้อเสียของการเปิดช่องโหว่ด้านความปลอดภัย เวลา จำกัด การพกพา (ระบบที่ใช้ในเคอร์เนลนั้นเชื่อมต่อกับเคอร์เนลอย่างมาก) คุณจะไม่สามารถพอร์ตไปยังระบบปฏิบัติการอื่นได้อย่างง่ายดายและไม่สามารถทำได้อย่างสมบูรณ์หากคุณไม่สามารถเข้าถึงรหัสเคอร์เนลได้

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

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

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

— celtschk
แหล่งที่มา

สมมติฐาน MS Windows ของคุณคือส่วนหนึ่งเป็นความจริง - บางของโครงสร้างที่จำเป็นสำหรับระบบ windowing คือการจัดเรียงของในเคอร์เนล - แต่มันซับซ้อน สิ่งที่อาจทำให้คุณประหลาดใจเกี่ยวกับ Windows ก็คือสิ่งที่เราเชื่อมโยงกับมันเป็นสิ่งที่เฉพาะเจาะจงมากสำหรับระบบย่อยโหมดผู้ใช้คนเดียว - ระบบย่อย Win32 - บางอย่างเช่น vm เคอร์เนล - และโมดูลผู้บริหารที่เป็นส่วนประกอบ- อยู่ห่างจากสิ่งเหล่านั้นทั้งหมด การแยกนั้นอนุญาตให้ระบบย่อย POSIX แยกทำงานบนเคอร์เนล NT ได้ ลองดู

— mikeserv

1

ในขณะที่ฉันไม่รู้เกี่ยวกับการออกแบบที่เฉพาะเจาะจงนั้นจริง ๆ แล้วการดูรูปในบทความที่เชื่อมโยงฉันเห็นกล่องในพื้นที่เคอร์เนลซึ่งมีคำว่า "ตัวจัดการหน้าต่าง" เนื่องจากการตกแต่งหน้าต่างจริงถูกดึงโดยแต่ละโปรแกรม (ดังนั้นจึงไม่มีอะไรเหมือนกับตัวจัดการหน้าต่าง X11) ฉันสามารถสรุปได้ว่านี่เป็นส่วนประกอบที่ทำสิ่งเดียวกับที่เซิร์ฟเวอร์การแสดงผล X11 ทำ ส่วน Win32 น่าจะเป็นการรวมกันของฟังก์ชันการทำงานของตัวจัดการหน้าต่าง X11 (ซึ่งไม่ได้เป็นส่วนหนึ่งของเซิร์ฟเวอร์ X11!) และชุดเครื่องมือ X11 (ในบริบทของไคลเอนต์ยังอยู่ใน X)

— celtschk

ใช่ - นั่นคือสิ่งที่ฉันหมายถึงโดยเรียงลำดับ / บางส่วน - เป็นเลเยอร์บริการผู้บริหาร - มันเป็นเหมือนบริการชั่วคราวที่ทำงานในโหมดเคอร์เนล แต่เป็นโมดูลแยกต่างหากในตัวของมันเอง ฉันเดาว่านั่นคือเคอร์เนล - ในทำนองเดียวกันลินุกซ์เคอร์เนลไดรเวอร์ไม่จำเป็นต้องรวบรวม แต่สามารถโหลด / ยกเลิกการโหลดแบบแยกส่วนได้ มันเป็นเรื่องแปลกสำหรับ Windows เพราะมันอยู่ภายใต้ wraps อย่างไรก็ตามผมเคยคิดว่ามันเป็นเรื่องที่น่าสนใจ - แต่ผมไม่มีความเชี่ยวชาญ คำตอบของคุณทำให้ฉันนึกถึงมัน

— mikeserv

2

เดิมที X นั้นได้รับการพัฒนาและดูแลโดย MIT และมันเป็นลิขสิทธิ์ของโอเพ่นซอร์ส MIT ไม่ใช่อย่างนั้นมันมีความสำคัญ

ในขณะที่ถูกมองว่าเป็นแบบไม่เคลื่อนไหวให้พิจารณาสักครู่ คุณจะอธิบายทางเลือกในการใช้กระบวนทัศน์ไคลเอนต์ - เซิร์ฟเวอร์ในซอฟต์แวร์ได้อย่างไร และบางทีฉันควรพูดกับ CEO

นี่คือวิธีที่ฉันเรียนรู้ที่จะชื่นชมทางเลือกในวิทยาลัย ในไคลเอนต์เซิร์ฟเวอร์เซิร์ฟเวอร์การจัดการทรัพยากรและโดยเฉพาะอย่างยิ่งทรัพยากรใด ๆ ที่จะต้องได้รับการใช้ร่วมกัน ดังนั้นเซิร์ฟเวอร์ X เป็นกระบวนการที่ให้บริการกับแอพไคลเอนต์แป้นพิมพ์เมาส์และเฟรมบัฟเฟอร์ (หรือคุณเขียนไปยังหน้าจอในระบบของคุณ)

ในขณะที่ไม่ถูกต้องตัวจัดการหน้าต่างมักจะอธิบายออกไปเช่นนี้: มันเป็นเพียงแค่สิ่งที่ใส่มือจับและของประดับตกแต่งอื่น ๆ ในกรอบของแอพและหน้าต่างกล่องโต้ตอบ ฯลฯ

— แดนลาเบล
แหล่งที่มา

0

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

ในขณะที่มีหลายวิธีที่เซิร์ฟเวอร์และไคลเอนต์สามารถสื่อสารได้ตัวเลือกที่ทำโดยX(ไม่คำนึงถึงข้อดีที่ผู้อื่นพูดถึง) นั้นไม่ฟุ่มเฟือย: คุณสามารถเชื่อมต่อกับXเซิร์ฟเวอร์บนเครื่องอื่นและเปิดหน้าต่างบนเดสก์ท็อปของคุณ เดสก์ทอป). สิ่งนี้เคยเป็นเรื่องธรรมดามากในสมัยที่ X พัฒนาขึ้นเมื่อมหาวิทยาลัยและธุรกิจหลายแห่งมีเซิร์ฟเวอร์ Unix และ "X terminal" จำนวนมากที่พูดคุยกับมัน ด้วยการใช้โปรโตคอลการสื่อสารที่พร้อมใช้งานอินเทอร์เน็ต X สามารถใช้งานได้อย่างราบรื่นภายในหรือข้ามโฮสต์

X เป็นสภาพแวดล้อม GUI แรกที่สามารถแสดงหน้าต่างจากเครื่องอื่นที่สอดคล้องกับประวัติของ UNIX ในฐานะผู้ใช้หลายคนแทนที่จะใช้ระบบปฏิบัติการสำหรับผู้ใช้คนเดียวบนคอมพิวเตอร์เครื่องเดียว ฟีเจอร์ UNIX จำนวนมากดูเหมือนจะเกินความจริงหากคุณเป็นคนเดียวที่เคยติดต่อกับคอมพิวเตอร์ของคุณ (ทางกายภาพหรือจากระยะไกล)

— อเล็กซิส
แหล่งที่มา

-1

ฉันเชื่อว่า x-server ได้รับการออกแบบเป็นสถาปัตยกรรมไคลเอนต์ - เซิร์ฟเวอร์เพราะในตอนแรกทรัพยากรการคำนวณนั้นหายากและเมนเฟรมทำหน้าที่ยกส่วนใหญ่ เทอร์มินัล X เป็นเพียงไคลเอ็นต์แบบบางที่เชื่อมต่อกับเซิร์ฟเวอร์ x และแสดงสิ่งที่จำเป็นต้องแสดงต่อผู้ใช้

มันมีประโยชน์มากมาย (ถึงแม้ว่าโปรโตคอลการสื่อสารสำหรับ X จะหนักมากทุกวันนี้) โดยเฉพาะอย่างยิ่งคุณสามารถแสดงหน้าจอเดียวกันบนไคลเอนต์หลายเครื่องการแชร์หน้าจอกับผู้ใช้หลายคนทำได้ง่ายใน X

— Karney Li
แหล่งที่มา

X Terminals มาหลายปีหลังจาก X Window เริ่มได้รับความนิยมดังนั้นพวกเขาจึงไม่สามารถเป็นเหตุผลว่าทำไม X Window ได้รับการออกแบบในแบบนั้น อีกจุดหนึ่ง: X Terminal ไม่ได้เชื่อมต่อกับเซิร์ฟเวอร์ X พวกเขากำลังใช้เซิร์ฟเวอร์ X

— jlliagre