17.2.4. Make Sendmail Adapt to the

17.2.4. Make Sendmail Adapt to the World, Not the Other Way Around
Protocols such as UUCP and BerkNET were already implemented as separate programs that had their own, sometimes quirky, command line structure. In some cases they were being actively developed at the same time as sendmail. It was clear that reimplementing them (for example, to convert them to standard calling conventions) was going to be painful. This led directly to the principle that sendmail should adapt to the rest of the world rather than trying to make the rest of the world adapt to sendmail.

17.2.5. Change as Little as Possible
To the fullest extent possible, during the development of sendmail I didn't touch anything I didn't absolutely have to touch. Besides just not having enough time to do it, there was a culture at Berkeley at the time that eschewed most formal code ownership in favor of a policy of "the last person who touched the code is the go-to person for that program" (or more simply, "you touch it, you own it"). Although that sounds chaotic by most modern-day standards, it worked quite well in a world where no one at Berkeley was assigned full time to work on Unix; individuals worked on parts of the system that they were interested in and committed to and didn't touch the rest of the code base except in dire circumstances.

17.2.6. Think About Reliability Early
The mail system prior to sendmail (including most of the transport systems) wasn't terribly concerned about reliability. For example, versions of Unix prior to 4.2BSD did not have native file locking, although it could be simulated by creating a temporary file and then linking it to a lock file (if the lock file already existed the link call would fail). However, sometimes different programs writing the same data file wouldn't agree on how the locking should be done (for example, they might use a different lock file name or even make no attempt to do locking at all), and so it wasn't that uncommon to lose mail. Sendmail took the approach that losing mail wasn't an option (possibly a result of my background as a database guy, where losing data is a mortal sin).

17.2.7. What Was Left Out
There were many things that were not done in the early versions. I did not try to re-architect the mail system or build a completely general solution: functionality could be added as the need arose. Very early versions were not even intended to be completely configurable without access to the source code and a compiler (although this changed fairly early on). In general, the modus operandi for sendmail was to get something working quickly and then enhance working code as needed and as the problem was better understood.

ผลลัพธ์ (ไทย) 1:

17.2.4 การให้ Sendmail ที่ปรับให้เข้ากับโลก ไม่วิธีอื่น ๆโปรโตคอล UUCP และ BerkNET ถูกนำมาใช้แล้วเป็นโปรแกรมแยกต่างหากที่มีโครงสร้างบรรทัดคำสั่งบางครั้งมอนสเตอร์ที่เล่นโวหาร ตนเอง ในบางกรณี พวกเขาได้ถูกกำลังพัฒนากันเป็น sendmail เป็นชัดเจนว่า reimplementing (ตัวอย่าง การแปลงให้เป็นแบบแผนเรียกมาตรฐาน) พวกเขากำลังจะเจ็บปวด นี้นำไปสู่หลักการว่า sendmail ควรปรับให้เข้ากับส่วนเหลือของโลก แทนที่พยายามทำให้ส่วนเหลือของโลกคล้อย sendmail โดยตรง17.2.5 เปลี่ยนเพียงเล็กน้อยที่สุดอย่างถึงที่สุด ระหว่างการพัฒนาของ sendmail ฉันไม่ได้สัมผัสอะไรไม่ได้จริง ๆ ต้องสัมผัส นอกจากไม่มีเวลาพอที่จะทำ มีวัฒนธรรมที่เบิร์กลีย์ในขณะที่เป็นเจ้าของรหัสอย่างเป็นทางการมากที่สุดสามารถมีนโยบาย "คนสุดท้ายที่สัมผัสรหัสเป็นคนไปโปรแกรม" eschewed (หรือกว่านั้น "คุณสัมผัส คุณเป็นเจ้าของ") แม้ว่าเสียงวุ่นวายตามมาตรฐานอันสูงสุด จะทำงานค่อนข้างดีในโลกที่ไม่มีใครที่เบิร์กลีย์กำหนดเต็มเวลาการทำงานบน Unix บุคคลที่ทำงานในส่วนของระบบที่พวกเขาสนใจในมุ่งมั่น และไม่ได้สัมผัสส่วนเหลือของรหัสพื้นฐานยกเว้นในสถานการณ์ที่เลวร้าย17.2.6 คิดถึงความน่าเชื่อถือก่อนระบบจดหมายก่อน sendmail (รวมทั้งระบบการขนส่ง) เลยแย่มากความกังวลเกี่ยวกับความน่าเชื่อถือ ตัวอย่าง Unix รุ่นก่อน 4.2BSD ไม่มีแฟ้มล็อก แม้ว่ามันสามารถจำลอง โดยสร้างแฟ้มชั่วคราว และการเชื่อมโยงไปยังแฟ้มล็อก (แฟ้มล็อกที่อยู่การเชื่อมโยงเรียกจะไม่) อย่างไรก็ตาม โปรแกรมต่าง ๆ บางครั้งไฟล์ข้อมูลเดียวกันจะไม่ยอมรับในวิธีการล็อกควรจะทำ (เช่น พวกเขาอาจใช้ชื่อแฟ้มอื่นล็อค หรือจะทำให้ไม่พยายามที่ทำการล็อกทั้งหมด), และดัง นั้นไม่ใช่ว่าจะสูญเสียอี Sendmail เอาวิธีว่า จดหมายสูญหายไม่ได้ (อาจเป็นผลของพื้นหลังของฉันเป็นผู้ชายฐานข้อมูล ข้อมูลแพ้อยู่เป็นมนุษย์บาป) ตัวเลือก17.2.7. สิ่งที่เหลือออกมีหลายสิ่งที่ไม่ได้ทำในรุ่นแรก ๆ ไม่ได้ไม่พยายามสถาปนิกระบบจดหมายใหม่ หรือสร้างโซลูชันทั่วไปทั้งหมด: สามารถเพิ่มฟังก์ชันการทำงานเป็นต้องเกิดขึ้น แม้ไม่มีไว้เนิ่น ๆ รุ่นจะกำหนดทั้งหมดไม่ถึงรหัสแหล่งที่มาและที่คอมไพเลอร์ (แต่นี้การเปลี่ยนแปลงค่อนข้างเร็วใน) ทั่วไป operandi modus สำหรับ sendmail ได้รับบางสิ่งบางอย่างที่ทำงานได้อย่างรวดเร็ว และเพิ่มรหัสการทำงานตามความจำเป็น และเป็นปัญหาดีกว่าเข้าใจ

ผลลัพธ์ (ไทย) 2:

17.2.4 ทำให้ Sendmail ปรับให้เข้ากับโลกไม่วิธีอื่น ๆ
เช่นโปรโตคอล UUCP และ BerkNET ได้ดำเนินการแล้วเป็นโปรแกรมที่แยกต่างหากที่มีของตัวเองที่เล่นโวหารบางครั้งโครงสร้างบรรทัดคำสั่ง ในบางกรณีที่พวกเขากำลังได้รับการพัฒนาอย่างแข็งขันในเวลาเดียวกันเป็น sendmail มันเป็นที่ชัดเจนว่าพวกเขา reimplementing (เช่นแปลงให้เรียกประชุมมาตรฐาน) จะเป็นความเจ็บปวด นี้นำโดยตรงกับหลักการที่ว่า sendmail ควรปรับให้เข้ากับส่วนที่เหลือของโลกมากกว่าการพยายามที่จะทำให้ส่วนที่เหลือของโลกที่ปรับให้เข้ากับ sendmail. 17.2.5 เปลี่ยนน้อยที่สุดเท่าที่เป็นไปได้อย่างเต็มที่ในระหว่างการพัฒนาของ sendmail ฉันไม่ได้สัมผัสอะไรที่ฉันไม่ได้อย่างที่ต้องสัมผัส นอกจากนี้เพียงแค่ไม่ได้มีเวลามากพอที่จะทำมันมีวัฒนธรรมที่เบิร์กลีย์ในเวลานั้นคาดเป็นเจ้าของรหัสที่เป็นทางการมากที่สุดในความโปรดปรานของนโยบาย "คนสุดท้ายที่สัมผัสรหัสเป็นไปเพื่อคนว่าโปรแกรม" ( หรือมากกว่าเพียงแค่ "คุณสัมผัสมันคุณเป็นเจ้าของมัน") แม้ว่าเสียงที่วุ่นวายโดยส่วนใหญ่มาตรฐานที่ทันสมัยวันก็ทำงานค่อนข้างดีในโลกที่ไม่มีใครที่เบิร์กลีย์ได้รับมอบหมายให้ทำงานเต็มเวลาในการทำงานบน Unix; บุคคลที่ทำงานในส่วนของระบบที่พวกเขามีความสนใจในและมุ่งมั่นที่จะและไม่ได้สัมผัสส่วนที่เหลือของฐานรหัสยกเว้นในกรณีที่เลวร้าย. 17.2.6 คิดเกี่ยวกับความน่าเชื่อถือในช่วงต้นระบบอีเมลก่อนที่จะ sendmail (รวมมากที่สุดของระบบการขนส่ง) ไม่ได้ชะมัดความกังวลเกี่ยวกับความน่าเชื่อถือ ตัวอย่างเช่นเวอร์ชันของระบบ Unix ก่อนที่จะ 4.2BSD ไม่ได้มีการล็อคไฟล์พื้นเมืองแม้ว่ามันอาจจะมีการจำลองโดยการสร้างแฟ้มชั่วคราวแล้วเชื่อมโยงไปยังแฟ้มล็อค (ถ้าแฟ้มล็อคอยู่แล้วสาย link จะล้มเหลว) แต่บางครั้งการเขียนโปรแกรมที่แตกต่างแฟ้มข้อมูลเดียวกันจะไม่เห็นด้วยกับวิธีการล็อคควรจะทำ (ตัวอย่างเช่นพวกเขาอาจจะใช้ชื่อแฟ้มล็อคที่แตกต่างกันหรือแม้กระทั่งทำให้ความพยายามที่จะทำล็อคที่ไม่ทั้งหมด) และดังนั้นจึง wasn ' ทีว่าเรื่องแปลกที่จะสูญเสียอีเมล Sendmail เอาวิธีการที่สูญเสียอีเมลก็ไม่ใช่ทางเลือก (อาจจะเป็นผลมาจากพื้นหลังของฉันเป็นผู้ชายฐานข้อมูลการสูญเสียข้อมูลที่เป็นบาปมหันต์). 17.2.7 สิ่งที่เหลืออยู่ออกมีหลายสิ่งที่ไม่ได้ทำในรุ่นแรกมี ผมไม่ได้ลองอีกครั้งสถาปนิกระบบอีเมลหรือสร้างแก้ปัญหาทั่วไปสมบูรณ์: การทำงานที่อาจจะเพิ่มความต้องการที่เกิดขึ้น รุ่นแรกมากไม่ได้ตั้งใจแม้จะเป็นกำหนดอย่างสมบูรณ์โดยไม่ต้องเข้าถึงซอร์สโค้ดและคอมไพเลอร์ (แม้ว่าการเปลี่ยนแปลงอย่างเป็นธรรมในช่วงต้น) โดยทั่วไปวิธีการทำงานสำหรับ sendmail ก็จะได้รับสิ่งที่ทำงานได้อย่างรวดเร็วและจากนั้นเพิ่มประสิทธิภาพการทำงานรหัสตามความจำเป็นและเป็นปัญหาที่เกิดขึ้นก็เป็นที่เข้าใจได้ดียิ่งขึ้น

ผลลัพธ์ (ไทย) 3:

17.2.4 . ให้โปรแกรม Sendmail ปรับตัวเข้ากับโลกไม่วิธีอื่น ๆเช่นบริการ UUCP โปรโตคอลและ
berknet ถูกนำมาใช้แล้วเป็นโปรแกรมแยกต่างหากที่มีของตัวเอง บางครั้งก็ติ๊งต๊อง โครงสร้าง บรรทัดคำสั่ง ในบางกรณีที่พวกเขาถูกแข็งขันพัฒนาในเวลาเดียวกันเช่น Sendmail . มันเป็นที่ชัดเจนว่า reimplementing พวกเขา ( ตัวอย่างเช่นเพื่อแปลงมาตรฐานการเรียกประชุม ) ต้องเจ็บปวด นี้นำโดยตรงกับหลักการที่ sendmail ควรเข้ากับส่วนที่เหลือของโลกมากกว่าการพยายามที่จะให้ส่วนที่เหลือของโลกที่ปรับให้เข้ากับโปรแกรม Sendmail

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

17.2.6 . คิดเกี่ยวกับความน่าเชื่อถือก่อน
จดหมายระบบก่อน sendmail ( รวมทั้งส่วนใหญ่ของระบบการขนส่ง ) ไม่ได้สนใจเกี่ยวกับความน่าเชื่อถือ ตัวอย่างเช่นรุ่นของ Unix ก่อน 4.2bsd ไม่ได้มีการล็อคไฟล์ , แม้ว่ามันอาจจะเป็นผลจากการสร้างแฟ้มชั่วคราวและการเชื่อมโยงไปยังแฟ้มล็อค ( ถ้าล็อคไฟล์มีอยู่แล้ว ลิงค์ โทรหาจะล้มเหลว ) อย่างไรก็ตามบางครั้งโปรแกรมที่แตกต่างกันการเขียนข้อมูลไฟล์เดียวกันจะไม่เห็นด้วยกับวิธีการล็อคที่ควรทำ ( เช่น พวกเขาอาจใช้ชื่อแฟ้มล็อคที่แตกต่างกันหรือแม้กระทั่งทำให้ไม่มีความพยายามที่จะทำการล็อคที่ทั้งหมด ) , และดังนั้นจึงไม่แปลกที่จะสูญเสียอีเมล Sendmail เอาวิธีการสูญเสียเมล์ไม่ใช่ทางเลือก ( อาจจะเป็นผลของพื้นหลังของฉันเป็นฐานข้อมูลผู้ชายที่สูญเสียข้อมูลเป็นบาปร้ายแรง ) .

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