ต่อจากกรณีปัญหา กูเกิลเผยช่องโหว่ความปลอดภัยที่ไมโครซอฟท์ยังไม่แพตช์แก้ วันนี้ไมโครซอฟท์ออกแพตช์เรียบร้อยแล้ว โดยรวมเป็นชุดแพตช์ประจำเดือนมกราคม 2015 ตามธรรมเนียมของไมโครซอฟท์ที่จะออกแพตช์เดือนละครั้ง
แพตช์ชุดนี้แก้ช่องโหว่รวมทั้งหมด 8 ตัว โดยมีช่องโหว่ที่กูเกิลเปิดเผยสองตัวคือ MS15-001 และ MS15-003 ที่ไมโครซอฟท์จัดความร้ายแรงเป็น Important ทั้งคู่ (ยังไม่ถึงขั้น Critical)
ในแพตช์ชุดนี้ยังมี MS15-002 ที่อุดช่องโหว่ร้ายแรง (Critical) โดยเป็นบั๊กเกี่ยวกับ Telnet บนวินโดวส์ด้วย
แอดมินทั้งหลายก็อัพเดตกันด่วนครับ
ที่มา - Microsoft, Naked Security
Get latest news from Blognone
Follow @twitterapi
Hiring! บริษัทที่น่าสนใจ
Blognone Jobs Premium
Cloudnone
- สรุปสาระสำคัญและของใหม่จาก Microsoft Ignite 2023 | Cloudnone Special EP
- สรุปของใหม่และสาระสำคัญจาก AWS re:Invent 2023 | Cloudnone Special EP
- สงคราม AI 2024: OpenAI ชิงปาดหน้า Google วันเดียว | Cloudnone EP.17
- Microsoft, Amazon, Google ประกาศตั้ง Data Center ในไทย แล้วไงต่อ | Cloudnone EP 16
- สงคราม GenAI บนคลาวด์ในปี 2024 ไปถึงไหนกันแล้ว | Cloudnone x AWS
Comments
/me กดอัพเดตทันที
/me รอหนูลองยาก่อนครับ
/me ใช้(แอด)มดลองยาก็ได้ครับ ;)
เพราะอะไร Microsoft ให้ความสำคัญเป็น Important หว่า
ตามนี้ครับ
รู้สึกว่าพวกการยกระดับสิทธิ์ของผู้ใช้นี่มันเป็น Critical นะครับ
เพราะพวกแกน Unix ต่างๆเขาให้ Local Root Privilege Escalation เป็น Critical Vulnerability หมดเลย
แต่ 0day นี่ผมยังไม่เคยลองทำเหมือนกันครับ อาจจะต้องใช้ปัจจัยอื่นเข้าช่วยด้วยเลยไม่ใช่ Critical
Patch Tuesday ก็มาตามเวลานี้ตลอด ไม่เก็ทว่าทำไมถึงมีคนด่า
ถ้าอ่านรายละเอียดของแพตช์ MS15-003 จะเห็นว่าบั๊กนี้มีผลกระทบกับ Windows หลายเวอร์ชันมาก ที่ลองนับดูคร่าวๆ ก็ไม่ต่ำกว่า 25 ตัว เอาแค่เวลาที่ใช้ทดสอบว่าหลังจากแก้บั๊กนี้แล้วจะมีผลกระทบอะไรกับ Windows แต่ละตัวมั้ยผมก็คิดว่าใช้เวลาเป็นเดือนนะ
การแก้บั๊กของซอฟต์แวร์มันก็ไม่ได้เหมือนการต่อเลโก้ที่จะดึงอันไหนอันนึงออกแล้วเปลี่ยนอันใหม่ใส่เข้าไปก็เสร็จ คือมันมีกระบวนการซับซ้อนมากมาย อย่างน้อยก็ต้องมีกระบวนการตรวจสอบว่าแก้บั๊กนี้แล้วไม่ไปสร้างบั๊กอื่นเพิ่ม ซึ่งกระบวนการตรวจสอบนี่แหละที่มันกินเวลามหาศาล การไปตีกรอบว่าบั๊กนี้ต้องแก้ให้เสร็จภายในเวลาที่กำหนดบางทีมันก็ทำได้ยาก (ดูอย่างเกม Assassin's Creed Unity ก็ได้ที่ตอนนี้ก็ยังเห็นว่าแก้บั๊กกันไม่หมดเลย)
Google แจ้งบั๊กนี้ให้ Microsoft ทราบเมื่อวันที่ 13 ตุลาปีที่แล้ว และปกติ Microsoft จะออก Security update ทุกๆ วันอังคารที่ 2 ของเดือน (ยกเว้นว่าจะมีบั๊กแบบรุนแรงมากๆ จริงๆ ถึงจะออกแพตช์นอกรอบ) ดังนั้นถ้าจะออกแพตช์แก้บั๊กนี้ใน Security update เดือนตุลาก็ไม่ทันแล้ว ก็ต้องรอเดือนถัดไป ซึ่งก็คือพฤศจิการหรือธันวา แต่ถ้าเราดู Security update ของ 2 เดือนนี้ก็จะเห็นว่ามันมีการแก้บั๊กไปหลายตัวเหมือนกัน ซึ่งก็คือทางทีมแก้บั๊กของ Microsoft มีงานล้นมือที่ต้องออกแพตช์มาแก้บั๊กกันทุกเดือนๆ อยู่แล้ว บั๊กที่ Google พบนี้ก็เป็นแค่ 1 ในบั๊กที่ต้องเอาไปจัดลำดับความสำคัญว่าควรแก้ทันทีหรือรอไปก่อนได้
ถ้าดูจากหน้าเพจที่ Google ประกาศข้อมูลบั๊ก ตอนแรก Microsoft บอกจะออกแพตช์แก้บั๊กนี้ใน Security update เดือนกุมภาด้วยซ้ำ เพราะให้เหตุผลว่ามันต้องมี User interaction ร่วมด้วยถึงจะโจมตีสำเร็จได้ เลยไม่ได้ถือว่าเป็นแพตช์เร่งด่วนที่ต้องเร่งออก แต่ Google ก็เร่งให้ออกในเดือนมกรา Microsoft ก็เลยรีบเข็นแพตช์ออกมาให้ทัน Security update เดือนมกราซึ่งก็คือวันที่ 13 แต่ Google ดันไปเปิดเผยข้อมูลช่องโหว่ซะก่อนที่ตัวแพตช์จะออกมา ซึ่งก็คือก่อนหน้าวันปล่อยแพตช์แค่ 2 วัน คือถ้ามองในแง่ของ Microsoft เองก็ไม่ใช่ว่าจะไม่ใส่ใจหรือไม่ทำแพตช์นะ แค่เค้ารอปล่อยออกมาพร้อมกันทีเดียวเหมือนกับที่เคยทำเพื่อจะได้ไม่เป็นภาระของผู้ดูแลระบบที่ต้องมาตรวจสอบแพตช์ทุกตัวก่อนที่จะปล่อยให้เครื่องต่างๆ อัปเดต เพราะการเปิด Auto update โดยไม่ตรวจสอบแพตช์ก่อนอาจมีผลเสียหายต่อระบบได้ถ้าแพตช์นั้นมีปัญหา ซึ่งก็เคยเกิดขึ้นมาหลายครั้งแล้ว
ที่พิมพ์มายาวๆ นี่ไม่ใช่อะไรคือเห็นในข่าวก่อนมีคนคอมเมนต์กันเยอะเลยว่าทำไม Microsoft รู้แล้วไม่รีบแก้ คือจริงๆ เป็นเพราะการแก้บั๊กแต่ละทีนี่มันอาจไม่ได้ทำง่ายอย่างที่เราเข้าใจครับ
+1020
ที่ด่าหลายๆ ก็คงเพราะไม่เข้าใจ
แต่อีกส่วนก็คงเพราะอคติมันบังตาล่ะครับ
Legacy Code ระดับ 20ปี มันแก้บั๊กได้ง่ายๆแบบนั้นก็ดีสิ
+1024 เขาคงคิดว่ามันง่ายเหมือนใช้ยางลบ ลบรอยดินสอบนกระดาษแล้วเขียนขึ้นมาใหม่กระมัง
มันไม่ได้ง่ายเหมือนใช้ยางลบ แต่ก็ไม่ได้ยากจนต้องใช้เวลาเกิน 90 วันครับ
ถ้าคุณอ่านรายละเอียด bug จะพบว่าจุดที่ต้อง identify/address bug นั้นไม่ได้หายากเลย และก็เป็นบัคของ module หนึ่งๆที่ไม่ได้จำเป็นต้องมาหาผลกระทบของ OS เป็นเดือนๆครับ แค่ทดสอบว่า module นั้นๆทำงานได้ตามต้องการก็พอ (create folder ที่ต้องการได้ไม๊, ได้ privilage ที่ต้องการหรือเปล่า, etc.) ในกรณีนี้ผมยังคิดไม่ออกครับว่าแก้ module นี้แล้วจะให้ผลกระทบอะไรกับ OS เราต้องทดสอบว่า OS เสถียรไม๊ โปรแกรมนั้นโปรแกรมนี้ทำงานได้ปกติหรือเปล่า ทั้งๆที่มันไม่เกี่ยวกันเหรอครับ?
บัคที่เป็นปัญหาในข่าวเก่าคือ MS15-003/CVE-2015-0004 (บัคที่ Google เปิดเผยเมื่อวันที่ 11) ปัญหาคือการให้สิทธิ์ elevate privilege ทั้งๆที่ไม่จำเป็นต้องให้สิทธิ์นั้นในการทำงานบน %USERPROFILE%\, การยินยอมให้ใช้ parent dir(..) ในการอ้างอิงจาก registry hive, และการยินยอมให้อ้างอิงถึง hardlink/symlink ที่เชื่อมไปยัง %USERPROFILE%\ ของคนอื่น (eg. administrator)
เห็นแนวทางแก้ไขไหมครับ? MS ก็ทำแบบนั้นครับ ดูจากไฟล์ที่ได้รับการแก้ไขก็ได้ครับ
ส่วนบัคอีกตัวหนึ่งคือ MS15-001 ซึ่งเป็นบัคอีกตัวหนึ่ง(Google เปิดเผยเมื่อ 29 Dec) ผมไม่ขอพูดถึงละกันครับ เพราะข่าวเก่าไม่ได้พูดถึงไว้
ทั้งนี้เรื่องมันจะไม่เกิดเลยครับถ้า Microsoft ไม่ออกมาโวยตามข่าว
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
ที่เกิน 90 วันมา 2วันนั้น ผมว่าไม่ใช่เพราะมันไม่ทันนะ แต่มันต้องรอรอบของมันเท่านั้นเอง
ສະບາຍດີ :)
ครับ
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
เรื่องว่าทำไมถึงทำไม่ทันภายในกำหนด 90 วัน อันนี้ก็คงต้องถาม Microsoft นะฮะ :P
แต่ในมุมมองของผม บั๊กนี้ Google แจ้งให้ Microsoft ทราบเมื่อวันที่ 13 ตุลาคม ยังไง Microsoft เองก็ไม่มีทางปั่นแพตช์ออกมาได้ทัน Security Update ประจำเดือนตุลาคมที่จะปล่อยในวันที่ 14 ตุลาแน่ๆ แถมตอนนั้นก็ยังมีคิวแพตช์ของเดือนพฤศจิกายนที่ต้องปล่อยอีก กว่าจะตรวจสอบได้ว่าบั๊กนี้มีผลกระทบกับ Windows เวอร์ชันไหนบ้าง ก็ล่อไปเกือบๆ กลางเดือนพฤศจิกายนแล้ว ถ้าดูจากข้อความที่ Microsoft ตอบกลับ Google วันที่ 11 พฤศจิกายน ก็คือขอเวลา 3 เดือนในการทำแพตช์และจะปล่อยอัปเดตในเดือนกุมภา
แต่ Google ไม่ยอม บอกว่าขีดเส้นตายให้แก้ภายใน 90 วัน ซึ่งถ้า Microsoft จะทำแพตช์ให้ทันตามที่ Google กำหนดนั้น คือต้องปล่อยออกมาพร้อมแพตช์ Security Update เดือนธันวา ซึ่งกลายเป็นว่ามีเวลาแก้บั๊กและทดสอบผลกระทบในเวลาแค่เดือนเดียวหรือน้อยกว่า
เท่าที่ดูก็ไม่ใช่ว่า Microsoft จะไม่แคร์เส้นตาย 90 วันนะครับ เพราะก็พยายามขยับแพตช์นี้ให้มาออกในเดือนมกรา แต่เนื่องจากด้วยเหตุผลที่ว่าบั๊กนี้ไม่ใช่ช่องโหว่ระดับที่รุนแรงมากจนต้องออกแพตช์มาแก้ในทันทีทันใด แพตช์นี้ก็เลยถูกรวมไปปล่อยให้อัปเดตพร้อมกันกับแพตช์อื่นๆ ในวันที่ 13 มกราคม
แต่ปัญหาคือ วันที่ 13 มกราคมมันเลยเส้น 90 วันที่ Google กำหนดไว้ เมื่อพอ Google ปล่อยข้อมูลออกมาในวันที่ 11 มกราจึงทำให้ช่องโหว่นี้กลายเป็น 0-day และทำให้ผู้ใช้อีกหลายล้านคนทั่วโลกได้รับผลกระทบโดยไม่จำเป็น ทั้งๆ ที่ถ้ารออีก 2 วันถึงปล่อยข้อมูลช่องโหว่ ก็จะไม่มีปัญหาอะไรแล้วแท้ๆ
คือถ้าเรื่องนี้ Microsoft เพิกเฉย ไม่สนใจทำแพตช์เลย Google เป็นพระเอกแน่นอนครับ แต่ครั้งนี้ Google บีบคอให้ Microsoft ปล่อยแพตช์ออกมานอกเวลาปกติเพียงเพราะแพตช์นี้ตัวเองเป็นคนค้นพบ และไม่ได้สนใจว่าจะเกิดความเสียหายอะไรบ้าง การกระทำแบบนี้ผมมองว่า Google ทำไม่ถูกครับ
เรื่องการเปิดเผยข้อมูลช่องโหว่มันเป็นเรื่องที่ต้องพิจารณากันอย่างรอบคอบครับ เพราะก็ไม่ใช่มีแค่ Microsoft บริษัทเดียวที่ปล่อยอัปเดตออกมาเป็นรายเดือน บริษัทอื่นอย่าง Adobe, Oracle ก็ทำแบบนี้เหมือนกัน การที่นักวิจัยพบช่องโหว่แล้วยื่นเงื่อนไขบีบคอให้บริษัทที่มีกำหนดการออกแพตช์เป็นประจำทุกเดือนต้องเปลี่ยนมาออกแพตช์นอกเวลา มันก็เลยเป็นคำถามว่าการกระทำเช่นนี้มันถูกต้องแล้วจริงเหรอ
Google ก็ทำตามปกติที่ทำกับทุก vendors และกับทุกบัคนี่ครับ และก็กล่าวอย่างชัดเจนว่าไม่สามารถยืดระยะเวลาไปได้ตั้งแต่วันที่ 11 พฤศจิกายน ดังนั้น MS ก็ยังมีเวลา 2 เดือนกับ bug ตัวนี้(Oct>Nov,Nov>Dec)
ซึ่งในเดือน Dec เนี่ย MS เองมี patch แค่ 7 ตัว เป็น Exchange Server ไปซะ 1, MSOffice ไปซะ 3 ที่เกี่ยวกับตัว OS มีแค่ 3 ตัว
อันนี้ผมไม่รู้นะว่าทีม patch นี่แยกกันทำงาน ES ทีมนึง Office ทีมนึง OS ทีมนึงแบบนี้หรือเปล่า แต่การออก OS patch แค่ 3 ตัวแล้วบอกว่างานมันเยอะต้องใช้เวลาสำหรับบริษัทขนาดใหญ่อย่าง MS เนี่ยผมว่ายอมรับได้ยากนะ MS ไม่ใช่บริษัทเล็กๆพนักงานไม่เกิน 100 คน แต่เป็นบริษัทที่ HQ เดียวมีพนักงานประมาณ 40,000 คน ซึ่งผมไม่แปลกใจเลยว่าทำไม WP ถึงพัฒนาได้ค่อนข้างช้าแบบนี้
เรื่องนี้จะไม่เป็นปัญหาเลยถ้า MS อยู่นิ่งๆเหมือนตอน MS15-001 ซึ่งคนก็จะออกมาว่า Google เอง ซึ่งผมเข้าใจว่าธรรมเนียม 90 days แบบนี้ที่อื่นๆก็ทำแบบเดียวกันครับจาก comment ของคุณ mk
เราต้องไม่ลืมว่า Google Project Zero อาจไม่ใช่กลุ่มแรกที่ค้นพบ bug นี้ การกำหนด deadline และทำตาม deadline เป็นส่วนหนึ่งของการกดดันเจ้าของ software ให้รีบแก้ไข bug ครับ
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
ถ้าเอาจริงๆ ผมคิดว่า Microsoft แก้บั๊กเสร็จภายใน 90 วันนะครับ เพียงแต่ที่มันเกินมา 2 วันก็เป็นเพราะต้องรอปล่อยพร้อมกันกับแพตช์อื่นๆ ต่างหาก ถ้า Microsoft ไม่อยากมีปัญหาก็แค่ปล่อยแพตช์ออกมาก่อนโดยไม่ต้องรอเวลา แต่มันก็จะเกิดคำถามอีกแหละว่าถ้าจะทำแบบนี้ก็ไม่ต้องมีแพตช์ประจำเดือนสิ บั๊กไหนแก้แล้วเสร็จก็ปล่อยเลย ซึ่งเอาเข้าจริงๆ การทำแบบนี้มันก็อาจจะดีกว่าการปล่อยอัปเดตประจำเดือนก็ได้ แต่ก็เป็นงานหนักสำหรับแอดมินทั่วโลกที่ไม่สามารถกำหนดแพลนได้ว่าจะทดสอบแพตช์กันเมื่อไหร่ก่อนติดตั้งลงในระบบจริง
การขีดเส้นตายเพื่อกดดันให้ผู้ผลิตรีบปล่อยแพตช์มันก็มีทั้งข้อดีข้อเสียครับ ถ้าแพตช์มันไม่สมบูรณ์ ติดตั้งแล้วเกิดปัญหา ความเสียหายมันก็อาจจะมากกว่าตัวบั๊กเองก็เป็นได้ แต่การเปิดเผยช่องโหว่ 0-day แบบหมดเปลือก มันก็ไม่ใช่เรื่องดีเช่นกัน
การขีดเส้นตายให้ผู้ผลิตปล่อยแพตช์ภายในเวลาที่กำหนด (เช่น 45 หรือ 90 วัน) เป็นสิ่งที่ทำกันโดยทั่วไปก็จริง แต่เรื่องนี้มันก็มีประเด็นด้าน Ethic มาให้ได้ถกเถียงกันอยู่เสมอแหละครับว่ามันถูกต้องแล้วจริงเหรอ เพราะบั๊กบางอย่างมันต้องใช้เวลาแก้กันนาน และการยึดเอาเวลาที่ผู้ค้นพบช่องโหว่กำหนดมาใช้เป็นเส้นตายมันก็อาจไม่สามารถทำได้เสมอไปในทางปฏิบัติ
ในมุมมองของผม ไม่ว่าจะเป็นการกดดันผู้ผลิตให้ปล่อยแพตช์ทั้งที่ยังไม่พร้อม หรือการเปิดเผยช่องโหว่ 0-day แบบหมดเปลือก คนที่ได้รับความเสียหายมากที่สุดก็คือ User ครับ ในกรณีนี้ถ้า Google ต้องการที่จะกดดัน Microsoft จริงๆ ก็อาจไม่ต้องเปิดเผยข้อมูลช่องโหว่แบบหมดเปลือกก็ได้ คือเก็บเฉพาะส่วน PoC ไว้แล้วค่อยรอปล่อยหลังมีแพตช์ แบบนั้นยังจะพอช่วยรักษาความปลอดภัยให้กับผู้ใช้ได้มากกว่า
Holidays
1. Oct 13 = Columbus day
2. Nov 11 = Veterans day
3. Nov 27-28 = Thanksgiving holidays
4. Dec 24-25 = Christmas holidays
5. Jan 1 = New Year day
"2nd Tuesday Patch" Round
1. Oct = Oct 14 --> เป็นไปไม่ได้
2. Nov = Nov 11 (20 วันทำงาน นับจาก Oct 13)
3. Dec = Dec 9 (20+18 = 38 วันทำงาน นับจาก Oct 13)
4. Jan = Jan 13 (20+18+23 = 61 วันทำงาน นับจาก Oct 13) --> เลย Jan 11 ไปแล้ว
รอบ Oct 14 เป็นไปไม่ได้ ส่วน Jan 13 ก็เลยไปแล้ว
ดังนั้นรอบที่ออก patch เป็นไปได้คือ รอบ Nov 11 กับ Dec 9
90 วันที่บอกๆ กันมันรวม ส-อ ซึ่งเป็นวันหยุด ไม่ควรจะถูกเอามานับรวม
ถามว่าออกรอบ Nov 11 เป็นไปได้ไหม บอกได้เลยว่า 20 วันทำงานนั้นยากมากกกครับ
แค่อีเมล์ไปมากับ paperwork ก็หายไปอย่างน้อย 1/3 แล้ว ไม่นับtechnical process ที่เหลือ
ดังนั้นรอบที่เป็นไปได้มากสุดคือ Dec 9
ถ้าจะมาถกกันเรื่องช้าในการออก patch ควรจะเปลี่ยนคำถามใหม่ว่า
"ทำไม MS ถึงออกไม่ทันรอบ Dec 9 นี้ ซึ่งคือ 38 วันทำงานนับจากแจ้งเรื่อง มากกว่า 90 วันอย่างที่ถกกันอยู่"ครับ
โดยรวมแล้วความซวยมันอยู่ที่ ปลายปีวันหยุดเยอะ คนลาหยุดเยอะ MS ออก security patch ตามรอบเท่านั้น และ Nov 11 round เพิ่งเนี่ยปล่อยรอบใหญ่ทุก products ดังนั้น 20 วันแรกน่าจะหืดสำหรับดึง resource และยังไม่รวมถึงว่า patch นี้กระทบทุก OS โอกาสที่จะแก้แล้ว bug ไปโผล่อีกจุดก็มีสูงมาก ดังนั้นเวลาที่ใช้ test ก็เพิ่มขึ้นทวีคูณ
ที่เหลือผมว่าคุณ Bigta ก็พูดไปเกือบหมดแล้ว
+2^10
ชัดเจนดี พร้อมแหล่งอ้างอิง ^^
ที่ว่า Microsoft ไม่ใช่เพราะออกแพทช้าครับ แต่เพราะ Microsoft ไปว่า Google ทั้ง ๆ ที่เขาไม่ได้ผิดอะไร
ไม่ผิดแต่ก็ไม่เหมาะสมแหละครับ Microsoft ถึงออกมาติ Google เนี่ย พอ Google แจ้งออกมา แต่ปรากฏว่าบั๊กมันก็ไม่ใช่ระดับ Critical เลยต้องรอรอบอัพเดทเหมือนตัวอื่นๆ แต่สงสัยกลัวเสียเหลี่ยมเลยออกมาย้ำเรื่อง 90 วันหล่ะมั้ง
มันเป็นเพียงกุศโลบายไว้บีบบังคับให้นักพัฒนาออกแพทแก้ ไม่งั้นจะโดนเผยช่องโหว่สู่สารธารณะ แต่พอครบเวลาตามกำหนด 90 วัน แต่ยังไม่มีแพตแก้ออกมา จะให้ทำยังไงครับ ? กฏจะศักดิ์สิทธิ์ก็ต่อเมื่อบังคับใช้อย่างเคร่งครัด ถ้า Google หยวนให้ทีนี้ใครจะทำตามล่ะ ? นักพัฒนาเขาก็คิดว่าไม่เป็นไร พอถึงเวลาจริงก็ไม่เอาช่องโหว่ไปเปิดเผยหรอก หยวน ๆ กันไป อย่างนี้หรือครับ ?
กฎนี้มีไว้เพื่อให้นักพัฒนาแก้บัคของตัวเอง แล้วทำไมไม่หยวนให้หน่อยไม่กี่วันกับคนที่ใส่ใจจะแก้บัคล่ะครับ?
กฎมีไว้เพื่อทำให้ระบบปลอดภัยไร้ความวุ่นวายหรือลดความวุ่นวายให้น้อยกว่าเดิม ไม่ใช่เพิ่มความวุ่นวายอย่างที่เห็นครับ
ไม่มีนักพัฒนาคนไหนไม่ใส่ใจกับการแก้บัคของตัวเองครับ แล้วถ้าหยวนให้ Microsoft ได้ ก็ต้องหยวนให้คนอื่นได้
นักพัฒนาคนอื่นยังมีปัญหาแบบ Microsoft แต่ก็ยังไม่เห็นได้รับการละเว้นเลยครับ ผมไม่รู้ครับว่าเรื่องภายในมันเป็นยังไง แต่ Microsoft เท่าที่ผมเห็นถูกรายงานบัคไปหลายตัว และถ้าไม่ทันต้องหยวนให้ทุกอันเลยหรือเปล่าครับ ? งั้นจะตั้งกฏ 90 วันมาทำไม ? มีครั้งแรก ก็ต้องมีครั้งที่สอง แล้วก็จะมีครั้งต่อ ๆ ไป คนอื่นเห็นก็จะทำตาม นี่แหละครับที่จะทำให้มันวุ่นวาย
ถ้านัพัฒนาใส่ใจจะแก้บัคผมไม่นับว่ามันเ)็นความวุ่นวาย แต่นับว่าเป็นสังคมที่นักพัฒนาใส่ใจจะแก้บัคมากขึ้นมากกว่า
เสียตังค์ซื้อนี่ครับ ราคาก็ไม่ใช่ถูก ๆ ด้วย MS รวยจากการผูกขาด OS Windows ไปเท่าไหร่
ที่ว่า Windows มีหลายเวอร์ชั่นนั่นก็เป็นเพราะ MS เองที่ทำไมต้องออกมาหลาย version มากมายนัก บางอย่างก็เหตุผลทางธุรกิจ ออกรุ่นใหญ่เพื่อขายราคาแพงขึ้นไปอีก นั่นเพื่อผลกำไรของบริษัทโดยแท้ ดังนั้นไม่ควรมาเป็นเงื่อนไขนะครับ
การแก้บั๊กภายใน 90 วัน มันก็นานมากเกินพอแล้วครับ สำหรับ software เสียเงินที่ต้องรับผิดชอบต่อลูกค้า วัฒนธรรมองค์กรที่ออกอัพเดทเป็นรอบ ๆ วันนั้นของเดือนอะไรนั่นก็ไม่ใช่เหตุผลจะมาแก้ตัวได้เลย เพราะบริษัทฉันเป็นอย่างนี้เพราะฉะนั้นทุกคนต้องเข้าใจเหรอ ทำไม security update ต้องออกเดือนละครั้ง? ทำไมออกถี่กว่านี้ไม่ได้? ไม่คิดว่าเป็นจุดด้อยที่ควรแก้ไขกันหรือครับ
ตอนแรกจะออก patch นี้เดือนกุมภา... โอย... ได้ยินแทบจะลมจับ กับบั๊กความร้ายแรงระดับนี้ นี่บริษัทซอฟต์แวร์ชั้นนำของโลกเหรอเนี่ย...
ผมเข้าใจว่าเรื่องหลักที่ว่าปัญหามาจากมีหลายเวอร์ชัน ไม่ได้หมายถึงรุ่นย่อย แต่หมายถึง Windows Vista, 7, 8, 8.1, สารพัด Server, ARM นะครับ
มันร้ายแรงขนาดนั้นเลยเหรอครับ?
เห็นด้วยกับข้างบน คนออกมาโวยเหมือนครั้ง ShellShock ช่วงนั้นบอร์ดแต่ละที่ลุกเป็นไฟเลยแหละ
90 วัน ก็ราวๆ 3 เดือน ของฟรีก็ว่าไปอย่าง พอจะช่วยแถให้อยู่หรอก แพงก็แพง
นี่มีการไม่ให้นับวันหยุด วันฮอลิเดย์ดั๊ว! กางปฏิทินกันเลยทีเดียว เลอค่า...
ฝั่ง Mac ขาย OS ไปพร้อมอุปกรณ์ การซัพพอร์ตดีกว่า OS ที่ต้องเสียเงินซื้อซะอีก
เคยช้ายังไงก็ยังช้ามิเคยเปลี่ยน ขืนทำงานอย่างงี๊ต่อไปเรื่อยๆ
ระวังจะโดน Chrome OS ของกูเกิลบี้ส่วนแบ่งจนทำให้ Windows OS ไม่มีราคาเหมือนดังเดิมอีกต่อไป
ฝั่ง Office ก็โดนตอดไปเรื่อยๆ จะรับมือยังไงค่ะ?
เอิ่ม OS เสียตังกับความเร็วไม่จำเป็นต้องมาคู่กันนะ
ถ้ามันเร็วแล้วสร้างปัญหาก็ไม่สมกับเป็น OS เสียตังอยู่ดี
คือ คาดหวังอะไรจาก OS เสียตัง แน่นอนว่าความปลอดภัย แต่บนความปลอดภัยมันต้องไม่สร้างปัญหาเพิ่มด้วย