Lý sự pclouds

Mặc dù vẫn phải tiếp tục chửi rủa Wine vì tình hình ngày càng có chiều hướng đi ngược: bây giờ vừa dùng Wine, vừa đề phòng lỗi của Wine, và nếu gặp lỗi thì phải sửa lỗi của Wine luôn! Tuy nhiên Wine vẫn có một lợi thế hơn hẳn so với Windows: mã nguồn mở.

Vấn đề là thế này. Khi làm gitbox, gặp lỗi hư bộ nhớ, do thằng nào (hàm nào) gây ra thì hoàn toàn không biết. Hàm đó phá hoại một cách triệt để, nhưng lại ném đá giấu tay nên xem backtrace không thể rút ra được manh mối nào. Điều duy nhất có thể rút ra được là vùng heap bị phá hỏng. Do đó nghi ngờ là ghi vượt vùng nhớ cấp phát.

Nhưng làm sao biết chỗ nào ghi vượt? Trong Linux có thể dùng Electric Fence và một số công cụ tương tự. Trong Windows, chẳng thấy cái nào. Tuy nhiên do có sẵn mã nguồn Wine trong tay nên có thể dump cấu trúc heap ra mỗi lần một khối nhớ mới được cấp phát. Lần theo dump, có thể khoanh vùng lại được khoảng lệnh malloc nào bắt đầu phá hỏng cấu trúc heap. Việc còn lại chỉ là xác định chính xác thằng nào (hàm nào) được dùng để gọi cấp phát bộ nhớ ngay trước thời đi heap bị hỏng. Và như thế là có thể khoanh lại vùng nghi ngờ còn khoảng chục dòng lệnh (thay vì cả ngàn dòng lệnh).

Làm sao làm được? Mở mã nguồn Wine ra sửa rồi chạy chương trình với bản Wine "dỏm" mới. Wine do đó không chỉ đơn thuần là lớp giả lập môi trường Windows, mà còn là lớp hỗ trợ tìm lỗi luôn. Wine được dùng như một công cụ để làm instrumenting (hổng biết dịch chữ này).

Windows làm được không? Ờ, chắc được. Những công ty có khả năng tiếp cận mã nguồn Windows như Mainsoft hoàn toàn có thể làm được. Phần đông người dùng còn lại, nếu có tiền thì cũng hoàn toàn có thể, bằng cách... mua các công cụ mấy công ty kia bán ra. Rủi mấy công cụ của mấy công ty kia (hoặc chảnh, hoặc không nắm nhu cầu khách hàng) không đáp ứng nhu cầu thì ngậm bồ hòn làm ngọt. Công nhận mần Windows giàu thiệt. Dân khố rách áo ôm thì khỏi cần nghĩ ngợi làm gì. Cho gì xài đó, hết. Cấm cãi!

Tự nhiên nổi hứng gắn cái clustrmaps vô. Sau vài ngày ra được một kết quả hết sức đáng ngạc nhiên. Hông ngờ cái hẻm heo hút và hết sức nhảm nhí này cũng có nhiều người chú ý dữ vậy. Đề nghị bạn nào đang ở miền trung nước Mỹ, bạn ở Nhật (và một bạn, hình như ở Đức?) khai báo họ tên. Khu vực Hà Nội cũng đề nghị khai báo (trừ bạn Trăn thì biết rồi)

Dán lại bài đầu tiên cho những người lỡ dại ghé qua:

Chào các bạn, trang này cung cấp một số thông tin lảm nhảm của pclouds. Rất buồn vì bạn đã đọc trang này. Vui lòng đừng đọc nữa.

Cám ơn.

Bài này dùng để chửi rủa Windows giải toả căng thẳng khi làm gitbox. Ai khó chịu thì đừng đọc.

Bệnh thứ nhất: không có fork() . Nói cho cùng, Windows cũng có cơ chế copy-on-write, thông qua đó có thể dễ dàng (hoặc ít ra không phải không thể) cài đặt fork(). Vậy mà không làm (chắc theo nguyên tắc "not invented here"). fork dùng ở mức đơn giản (fork-exec) thì tương đương với spawn (hay CreateProcess). Tuy nhiên, những thằng như ash tận dụng fork ở tầm nghệ thuật.

Khi fork, ta có được một tiến trình con giống y chang tiến trình cha (khác biệt duy nhất là giá trị trả về của hàm fork sẽ khác nhau đối với tiến trình con và tiến trình cha). Việc sao y bản chánh này không có ý nghĩa gì lắm đối với mô hình fork-exec vì tiến trình con sẽ bị thay thế bằng một chương trình khác hầu như ngay sau khi fork.

Ash sử dụng fork khi cần phải chạy một shell con. Khi chạy một shell con, thay vì đưa nội (dạng văn bản) của phần cần phải chạy trong shell con, ash fork shell chính. Do shell con là bản sao của shell chính nên có toàn bộ cấu trúc dữ liệu của shell chính. Điều này có nghĩa là shell con không cần phải phân tích lại phần nội dung cần chạy của mình nữa làm gì vì shell chính đã làm dùm rồi. Shell con chỉ cần chạy nó.

Fork có thể xem như một cơ chế IPC một chiều hiệu quả. Nhưng Windows... không hỗ trợ. Khốn nạn!

Bệnh thứ nhì: fcntl với cờ F_DUPFD. Đây chỉ là một phiên bản khác chút đỉnh, một sự pha trộn giữa dup và dup2. Không thèm làm.

Bệnh thứ ba (cái này cần kiểm tra trên Windows để tránh đổ oan vì biết đâu lại là lỗi của Wine): hơi khùng khùng khi phải xử lý file handle bậy bạ. Chỉ cần close(1);close(2);dup2(1,2) là Windows bắt đầu phát rồ. Nó có thể đóng bất tử một file handle đã có để cấp phát làm file handle mới vô tư. Chán!

Bệnh thứ tư: xử lý tham số. Mấy hàm spawn* dễ thương xử lý tham số một cách hết sức dễ thương: bất kể truyền tham số tách rời như thế nào, nó đều gộp chung lại ráo. Để chứa khoảng trắng trong tham số, phải dùng dấu nháy. Mà nháy cũng hết sức dễ giận: hiểu " là dấu bao tham số và \" là dấu nháy thường, hết.

Tóm lại, Windows là một hệ điều hành tuyệt vời, miễn sao có tiền (để mua phần cứng), có lòng vị tha, cộng thêm kiên nhẫn chửi bới Microsoft khi nó không chạy.

Bệnh thứ ba kể trên là bệnh của Wine. Windows vẫn chạy an toàn. Wine còn thêm một bệnh nữa cũng liên quan đến file handling là dup() chạy sai (ít ra là với dup(1)). Lẽ ra phải dùng handle thấp nhất, nó lại không làm theo.

Kể bệnh hai thằng kia rồi, phải kể thêm tội của thẳng Linux (có lẽ cả họ UNIX): mkdir() chấp nhận tham số là tên thư mục cần tạo mà chứa cả các ký tự / thừa phía đuôi. Windows không chấp nhận. Nhưng cái này Windows có lí hơn.

Sau một thời gian dài trời trong mây sáng không gợn một chút sóng, "điểm truy cập" Linksys đã hoạt động trở lại. Nhờ đó có thể nối mạng để lấy mấy tập tin PO về mần. Lạy trời tuần sau đừng có mất sóng nữa. Tính ra đã phải xài bao nhiêu là AP (chùa): winterworm, montanaembassy, ourhome, chris, linksys...

Hôm nay thông báo phát hành swfdec 0.5.0. Blocky.swf, nhờ nỗ lực chơi không mệt mỏi của bạn Bi, rốt cuộc cũng được đề cập (là "ít lỗi hơn", khỉ gió vẫn còn cái Drawing API với GetURL2). Bạn Bi đồng thời "bị" liệt vào danh sách tác giả mà chả phải mất công sức gì nhiều (nhảm quá!). Hậu quả là sắp tới lại phải tiếp tục mần swfdec, có thể là hỗ trợ gettext hay Epiphany gì đó (Epiphany vẫn còn cái lỗi lưu văn bản utf-8 không được nếu lỡ tay chọn bảng mã iso-8859-1, vẫn chưa sửa hay thông báo gì sất). To tát hơn bao gồm precompile AS code cho swf (thành tập tin .so chẳng hạn) để chạy nhanh hơn. To hơn nữa là làm phần "chuyển ngữ", dịch bytecode của swf hiện thời sang AS3 để dùng chung với Tamarin (toooo quá!).

Tuần vừa rồi mần gitbox khí thế. Sau khi lò mò kiếm giải pháp thay thế fork() trên Windows (thằng Windows khốn nạn, sao nó không chịu thêm cái hàm fork cho mình nhờ??), mò mấy cái memory allocator, đọc qua tài liệu kiến trúc Cygwin, quyết định... vứt ráo, cài đặt fork ở cấp ứng dụng. Cái dở là phải sửa ash lại đôi chút, nhưng lại ít code hơn và code ít phức tạp hơn. git-status chạy ngon nhưng git-commit chết (chắc đâu đó có lỗi redirection).

Lâu ngày không gõ VIQR. Giờ gõ lộn tùm lum.

Coi "No time for nuts", giờ biết rằng người đầu tiên rút thanh gươm của các hiệp sĩ bàn tròn không phải là vua Arthur, mà cũng không phải là người. Là con "sóc" Scrat của "The Ice Age". Đồng thời biết thêm thế giới đã tạo ra được cỗ máy vượt thời gian rồi. Có thể đã tạo tới mấy cái. Nhưng mà tạo ra xong, các bác phát minh vội vàng chạy về quá khứ rồi chết luôn (quên đem áo lạnh hay bánh mì gì đó, cũng có thể quên đổ xăng), bỏ cái máy thời gian lại ở đó. Thành ra giờ muốn tìm máy thời gian thì không cần phát minh máy mới làm gì mà... quay ngược thời gian về tìm mấy cái máy đã phát minh! (Đề cử giải hâm của năm)

Linux dạo này lên hương. Sau khi Dell đòi bán máy cài Linux, Lenovo/IBM cũng bon cheo bắt chước. Chưa kể Oracle ra thông báo phát hành bản cho Linux còn các nền khác thì im re. Motorola công bố mã nguồn middleware gì đấy. Mesa 7.0 ra mắt (OpenGL 2.0).

Sau này em lớn lên, em muốn giống như anh Carl Worth. Nhân tiện, anh Carl Worth mà cải tiến được cái driver i915 thì đỡ biết mấy, em đang xài cái đó mà...

Tuần sau lại phải đọc HP7, lấy thời gian đâu ra mần tiếp một lô lốc các thứ cần mần đây trời!!

Lâu rồi không hâm. Hâm tí cho nóng. Nóng rồi nổ. Nổ xong... thôi.

• Phát triển ứng dụng chạy trên môi trường Windows bằng cách... dùng Linux, kèm với một bộ công cụ để biên dịch chương trình Windows từ trong Linux. Gặp khó khăn với Windows API? Chuyện nhỏ. Mở... mã nguồn wine ra xem. Muốn chạy thử? Chạy với wine. (Không biết mình có sờ đến Windows cho đến lúc xong Gitbox không ta)
• Hậu quả của việc dùng lẫn lộn cả Vim và Emacs? Dễ òm. Nhiều lúc gõ đi gõ lại phím tắt của Emacs trong Vim rồi cứ thắc mắc: ủa mình gõ đúng mà sao nó không chạy? (Nhầm phím Vim trong Emacs có may mắn hơn vì nó hiện ra chữ mình gõ)
• Nhân nói về chuyện lộn phím Emacs/Vim, tiện nói luôn một kinh nghiệm: Ai dùng Emacs nhiều sẽ có thói quen gõ Ctrl-X Ctrl-S. Đến khi dùng Vim, quen tay gõ y chang. Khổ nỗi Vim không phải Emacs, không thèm hiểu Ctrl-S mà quăng cho terminal xử lý. Với terminal, Ctrl-S tương đương với ScrollLock, khoá chết bàn phím cho đến khi nhận được Ctrl-Q. Thành ra nếu lỡ tay nhấn Ctrl-X Ctrl-S rồi thấy Vim nó đờ ra, thì gõ thử Ctrl-Q một cái.
• Mấy tuần vừa rồi là tuần của Diablo Swing Orchestra. Chỉ trong vòng một hai tuần, số lần nghe DSO phóng vèo từ không lên hơn bốn trăm, nâng hạng DSO lên 14, ngấp nghe làm ứng cử viên cho tốp mười (năm trăm lần nghe). Một ban nhạc cũng khá giống DSO ở chỗ có mỗi một tập nhạc mà được nghe nhiều là Angtoria. Nhưng Angtoria lên không bằng DSO. Nghe thử mấy bài nhạc mới trong tập nhạc sắp phát hành của Nightwish, thấy Anette vẫn yếu yếu...
• Có hai lỗi đáng đưa vô hàng kinh điển trong lập trình C++. Lỗi thứ nhất không chắc có phải là lỗi trình biên dịch hay không: A và B cùng là tham chiếu nhưng khác kiểu. Gán A cho B. Trình biên dịch lẳng lặng cho qua và cho phép dùng B thoải mái mặc dù B đang trỏ đến vùng nhớ của A và cấu trúc dữ liệu của B hoàn toàn khác A. Hậu quả? Memory corruption (tệ hơn nữa là hoàn toàn mất phương hướng trong việc xác định cái gì hoặc chỗ nào là nguyên nhân gây ra lỗi)
• Lỗi thứ hai kinh điển hơn (gấn giống với việc dùng nhầm dấu "=" với dấu "==" trong phép so sánh trong C). Khai báo hàm virtual trong lớp kế thừa, nhưng khai báo hàm không hoàn toàn trùng khớp (khác nhau chút đỉnh, như thiếu "const"). Hậu quả? C++ cho đó là hàm override, dạng hàm trùng tên chứ không phải là hàm virtual của lớp cha, nên nó... bỏ qua hàm đó mà gọi hàm virtual của lớp cha ngon ơ.
• Trích dẫn hay (dịch lại): "Vậy là tôi mất cái máy của mình. Mất theo nghĩa đen. Tôi có thể ping thấy nó. Nó vẫn chạy ngon lành, trừ việc tôi không thể biết được tôi đã đặt nó ở đâu trong nhà."

Danh sách những người từng tham gia dịch GNOME-VI đã được tập hợp khá đầy đủ ở trang GnomeVi/Credits, bao gồm những người sau:

1. Clytie Siddall
2. Hoàng Ngọc Tú
3. Joern v. Kattchee
4. Larry Nguyễn
5. Lý Trọng Văn
6. Nguyễn Thái Ngọc Duy
7. Phạm Thành Long
8. Phan Vĩnh Thịnh
9. Trịnh Minh Thanh

Ngoài ra còn một danh sách khác, bao gồm những người tham gia dịch bất cứ thứ gì thuộc mã nguồn mở. Danh sách này không bao gồm những người đã liệt kê ở trên vì Thịnh và chị Clytie dịch quá nhiều, ghi hai người này ra thì không biết phải tốn bao nhiêu chữ để liệt kê cho hết những dự án hai người đã dịch. Danh sách bao gồm:

1. Andrew Lynn (Claroline)
2. Bui Huu Manh (GRASS)
3. Cao Thien Phuoc (Plone)
4. Dao Trung Thanh (PHPNuke)
5. Duy Đào (SPIP)
6. Đinh Quang Ninh (Fedora Linux)
7. Ðỗ Xuân Tiến (TinyMCE2)
8. Hàn Thế Thành (TeX)
9. Hà Thanh Hải (Plone, Silva, FCKEditor)
10. Hieu Tran (VnTeX)
11. James Do (Dokuwiki)
12. Jean Christophe André (Debconf)
13. Kỳ Anh (TeX)
14. Lâm Vĩnh Niên (XFCE)
15. Lê Hồng Bội (glibc locale)
16. Lê Văn Nhạc (net2ftp)
17. Markus Neteler (GRASS)
18. Ngô Trần Thủy (libgphoto2)
19. Nguyen Dinh Quan (Xoops)
20. Nguyen Thai Hoa (Moodle)
21. Nguyen Viet Son (phpwcms)
22. Nguyễn Đại Quý (Leafpad, ede, phpmyfaq, moregroupware)
23. Nguyễn Đình Nam (Dokeos, HtmlArea, Webmin)
24. Nguyễn Minh Hương (Pidgin)
25. Nguyễn Thành Nam và bạn bè (OpenOffice)
26. Nguyễn Thanh Quang (Mediawiki)
27. Nguyễn Tiến Hải Bình (Pidgin)
28. Nguyễn Văn Vũ (Pidgin)
29. Pablo Saratxaga (glibc locale)
30. Phạm Mai Quân (Webmin)
31. Phan Anh Dung (m17n-db)
32. Phan Binh Giang (FCKEditor)
33. Phan Manh Dan (Stardict)
34. Thieu Nguyen (VnTeX)
35. Thomas Depraetere (Claroline)
36. Tran Thi Hoang Quyen (Translation project)
37. Trần Thế Trung (Mediawiki)
38. Trần Văn Tuấn (realgroupware)
39. Triệu Ngọc Toàn (Fedora Linux)
40. Trinh Vu Long Giao (vfm — joomlite)
41. Trương Trọng Hoàng (pivot-weblog)
42. Vang Le Quy (yappa-ng)
43. Vũ Quang Trung (Debconf)
44. Bạn jasperlotus (firefox)
45. Ai dịch HacaoLinux nhỉ?
46. Hình như chairuou có dịch cái chi đó, cần kiểm tra…
47. vuhung (KDE)
48. Lê Đình Long có làm gì đó với một cái firewall distro thì phải…

Tổng cộng hơn năm mươi người. Danh sách thực tế có lẽ sẽ nhiều hơn vì danh sách này được lập thông qua Google Code Search mà Google cũng không thông minh cho lắm. Tuy nhiên có lẽ danh sách thực tế cũng không quá một trăm người (không tính những bản dịch, dịch xài riêng).

Dĩ nhiên đóng góp hỗ trợ tiếng Việt không phải chỉ có dịch. Ví dụ như Phạm Thành Nam thu âm để có thể phát tiếng Việt với Festival hay công tác hỗ trợ hậu cần (một loạt các trang web hỗ trợ Linux), Đào Hải Lâm, Phan Kim Long, Trương Mạnh Cường viết các bộ gõ tiếng Việt, Tân Khoa (ĐHSP), Hoàng Tuấn Quỳnh và rất nhiều những người khác viết tài liệu, Nguyễn Thành Biên, Nguyễn Đại Quý hỗ trợ tiếng Việt trong yudit, Hàn Thế Thành tạo bộ phông chữ cho tiếng Việt... Lập cái danh sách hoàn chỉnh này chắc phải dài như cái sớ.

Cái chết của dự án bash2c là sự khởi đầu của dự án GitBox: chuyển busybox qua Windows, miễn sao đủ để chạy Git.

Sau một hồi (tính dài vài tuần, tính thời gian thực tế cỡ vài ngày) hì hục comment hết mấy đoạn code đặc trưng UNIX, tắt luôn mấy cái công cụ có vấn đề, cuối cùng cũng đã có thể tạo ra busybox.exe. busybox.exe hỗ trợ một số lệnh nho nhỏ như basename, cat, cksum, cp, cut, dirname, echo, env, false, head, md5sum, mkdir, mv, od, printenv, printf, pwd, realpath, rm, rmdir, seq, sh, sort, sum, test, tr, uniq, wc, yes. Điểm quan trọng nhất của bản busybox.exe đầu tiên này là hỗ trợ ash shell (mặc dù chả chạy được gì vì chưa cài đặt hàm fork). Kiểm tra sơ bộ cho thấy một số lệnh hoạt động, một số thì không.

Một khởi đầu tốt.

Tiếp theo có hai hướng (làm tuỳ hứng):

• -Kiểm tra và chuyển tiếp các công cụ nho nhỏ của busybox sang Windows.- -Những thứ cần thiết có lẽ gồm date, expr, find, touch, awk, sed, which.-
• ash!

RISC là gì? Ai hỏi câu này có hai lựa chọn:

1. Ngừng đọc tiếp. Nhầm chỗ rồi.
2. Xem giới thiệu trên wikipedia. Nếu không hiểu, quay lại lựa chọn số một.

Thật ra sự phân biệt giữa RISC và CISC ngày nay càng ngày càng mờ mịt. Tuy nhiên do thời gian qua phải sử dụng tập lệnh RISC hơi bị nhiều (ARM và PowerPC) nên rút ra một số điểm khác biệt so với họ CISC (dòng x86 của Intel):

• Tập lệnh RISC khó hiểu hơn x86. Các tên lệnh được hình thành theo quy tắc chứ không đơn giản là một tập các ký hiệu cố định như x86. Lệnh thường được ghép vào đuôi một số chữ biểu thị điều kiện hoạt động của lệnh đó (ví dụ chỉ thực hiện lệnh này khi cờ zero bật...). Bằng cách này ta có thể viết lệnh "if-else" mà thậm chí không cần lệnh di chuyển bộ đếm lệnh (program counter, pc trong RISC và ip trong x86). Đơn giản là viết một lệnh so sánh (để bật cờ). Sau đó viết khối lệnh "true" với cờ đó được bật và khối lệnh "false" với cờ đó bị tắt.
• Thanh ghi trong RISC hầu như là như nhau. Ví dụ như trong ARM, các thanh ghi được đặt tên lần lượt từ r0 đến r15. Nói "hầu như" là bởi vì vẫn có một số thanh ghi đặt biệt, cụ thể là r15 -- program counter. Đặc tả ARM ghi rõ cách hành xử của vi xử lý khi dùng lệnh với thanh ghi này. Các thanh ghi còn lại, trên lý thuyết, có thể sử dụng như nhau. Tuy nhiên trên thực tế, có một số quy ước được đặt ra để dễ quản lý thanh ghi. Do mạng đứt nên không nhớ rõ. Nhưng nếu không lầm thì r14 còn có tên khác là "lr", thanh ghi chứ địa chỉ trở về. Thanh ghi r13 có tên là "sp", stack pointer. Tuy nhiên nếu so sánh với tập thanh ghi của x86 thì thanh ghi trong RISC vẫn "tự do" hơn: x86 quy định rõ nhóm thanh ghi nào có mục đích nào, dùng được với những lệnh gì.
• Mã lệnh RISC luôn có kích thước cố định: 32-bit (dạng thức thu gọn THUMB chỉ cần 16-bit). Ngược lại, kích thước lệnh trong x86 thì vô chừng: NOP, nếu nhớ không lầm, chỉ cần một byte 0x90 trong khi các lệnh khác có thể lên đến 6 byte. Kích thước lệnh cố định là một lợi điểm lớn. Biết trước bao giờ cũng tốt vì có thể tối ưu theo thông tin đã biết.
• 32 bit của một lệnh RISC không chỉ đơn giản chứa mã lệnh (và cờ cần bật để lệnh đó thực hiện cộng thêm các thanh ghi thao tác), nó còn chứa cả một số hằng số. Do giới hạn về số bit, hằng số trong RISC không thể quá to. Tuy nhiên tập lệnh ARM có một mẹo hay khi lưu hằng số: lưu một cặp số gồm cơ số và số lần shift left. Với cách này có thể lưu một số trong một lệnh (dĩ nhiên bit thấp của số này phải là không). Làm cách nào để lưu một số lớn trong lệnh mà bit thấp lại khác không? Giải pháp là dùng hai lệnh: lệnh đầu lưu bình thường (vào thanh ghi chẳng hạn), lệnh sau thêm giá trị các bit thấp vào. Cách làm này giúp tránh truy xuất bộ nhớ chỉ vì cần một hằng số. Ở đây cần đề cập tới một ý của Andrew Tanenbaum (đọc trên wikipedia): 98% hằng số của chương trình chỉ cần dùng 13 bit (và đoán chừng hơn phân nửa có thể lưu thẳng vào lệnh RISC). CISC thường lưu hằng số theo byte, phí hơn nhiều.
• Do tập lệnh RISC đơn giản, vi xử lý RISC dễ thiết kế hơn (ít ra với dân không chuyên). Bằng chứng là mã nguồn verilog cho PowerPC hay SPARC gì đó (và hình như một số CPU RISC khác) có trên mạng. Chưa thấy mã nguồn verilog nào cho CPU CISC.
• Có một điểm hơi phân vân về RISC và CISC. Như bây giờ thì các chỉ thị của Pentium chắc chỉ cần một chu kỳ là xong tất. Chục năm về trước, thời kỳ của 386, trong khi các lệnh đơn giản chỉ cần một chu kỳ là xong, những lệnh phức tạp như nhân chia thường chiếm nhiều chu kỳ. Trong khi đó các lệnh RISC luôn phấn đấu mỗi lệnh một chu kỳ (cũng không khó lắm vì các lệnh đơn giản như nhau). Việc gom tất cả mỗi lệnh một chu kỳ có lẽ sẽ dễ cho thiết kế hơn. So với trường hợp Pentium bây giờ. Giả sử (hay giả bộ) thời gian thực hiện các lệnh đơn giản trong Pentium vẫn ngắn hơn nhiều so với thời gian thực hiện các lệnh phức tạp. Do bây giờ mỗi lệnh của Pentium cần một chu kỳ như nhau, đâm ra phí phạm thời gian khi thực hiện các lệnh đơn giản vì nó vẫn phải chờ cho hết một chu kỳ. Nếu rút thời gian mỗi chu kỳ xuống sát nút thì lệnh phức tạp lại cần nhiều chu kỳ. CISC nói chung là phức tạp!
• RISC có hạn chế là cần dùng nhiều lệnh hơn nhiều so với CISC (một lệnh CISC tương đương vài lệnh RISC). Khắc phục bằng cách tăng cache. (Đến giờ vẫn chưa thông I-Cache và D-Cache của con ARM)
• Tập lệnh RISC nhỏ. Cái này nói hoài. Nhưng cái nhỏ đó có một lợi ích: ít tốn chỗ ("chỗ" ở đây là transitor hay macrocell trong FPGA, vốn giới hạn). Do dư chỗ nên có thể có nhiều thanh ghi hơn, có cache lớn hơn... dẫn đến hiệu suất tốt hơn (Về mặt này thì những tiến bộ về công nghệ đã giúp thu ngắn khác biệt giữa RISC và CISC). Hoặc dư chỗ thì... thôi, chả sao. Càng ít transitor, càng đỡ tốn điện ;-)

Một điểm liên quan đến ARM920T là pipeline. Trước đây vẫn mù mờ về thực sự pipeline có tác động như thế nào. Giờ có vẻ rõ ràng hơn. Như đã nói ở trên, mỗi lệnh được thực hiện trong một chu kỳ. Tuy nhiên do mỗi lệnh cần thực hiện (giả sử) năm công đoạn:

1. Đọc chỉ thị từ bộ nhớ (hoặc cache)
2. Giải mã
3. Đọc dữ liệu từ bộ nhớ
4. Thực hiện
5. Lưu kết quả

Nếu một chỉ thị đã được chuyển qua giai đoạn giải mã thì phần CPU lo bước một ngồi không đình công đòi tăng lương giảm giờ làm. Phí! Vậy phải làm sao để nó cũng phải làm tiếp chứ không ngồi chơi. Để thực hiện, một chu kỳ đã đề cập được chia nhỏ thành năm chu kỳ (xung nhịp tăng gấp năm, tuy nhiên tốc độ vẫn như thế vì giờ đây mỗi lệnh cần năm chu kỳ để hoàn tất). Sau khi lệnh thứ nhất xong chu kỳ đầu, chuyển qua bước hai. Ở chu kỳ kế tiếp, khi lệnh thứ nhất đang giải mã thì lệnh thứ hai được đọc vào và tuần tự như thế. Kết quả? Dù mỗi lệnh vẫn cần năm chu kỳ, hai lệnh được thực hiện cách nhau chỉ một chu kỳ. Và cái chu kỳ này thực chất là một phần năm chu kỳ đã đề cập ở đầu. Nói cách khác, tăng tốc năm lần. Đây chỉ là nói lý thuyết suông, chưa chắc các bước ở trên đều cần thời gian như nhau. Pipeline hình như sau này được cả CISC và RISC tận dụng. RISC tận dụng trước bởi vì lệnh RISC đơn giản, tốn ít chỗ nên dư không gian để làm pipeline. Ngược lại CISC phải thắt lưng buộc bụng (hoặc chờ cải tiến về công nghệ) để có chỗ làm pipeline.

Một điểm khó chịu khi lập trình với RISC là quy ước dùng thanh ghi trong lập trình C của RISC (AAPCS). Để tăng hiệu quả hoạt động, và vì có dư thanh ghi, AAPCS hạn chế dùng stack để truyền tham số. Các tham số đầu tiên (hình như đến 4 hoặc 7 tham số gì đó) sẽ được truyền bằng thanh ghi thay vì lưu trong stack. Dĩ nhiên cách này giúp chương trình chạy nhanh. Bù lại, khi tìm lỗi, ta mất thông tin các tham số đầu do không có trong stack trace.

Để kết luận, hãy xem qua những lãnh vực dùng RISC. Về phần server có SPARC từ Sun và POWER của IBM (Alpha của DEC không biết nên xếp ở đâu). Ở thị trường nhúng (thiết bị nhỏ) thì ARM với MIPS thống trị. Với các thiết bị chuyên dụng nhưng không nhỏ tí nào thì có PowerPC (chào Juniper!). Thị trường duy nhất do CISC nắm giữ là thị trường máy để bàn (và RISC lại thua một lần nữa khi Apple bỏ PowerPC qua chơi với CPU Intel).

Một mục nữa vào wishlist 2008: nếu Playstation 3 mắc quá, hổng chừng kiếm cái Apple (bản PowerPC).

Năm ngoái đã lỡ làm cái Tóm tắt OLS 2006 rồi thì năm nay cũng phải sân si làm thêm một cái. Tài liệu OLS 2007 có tại đây.

Một nhận xét lặt vặt là mặc dù ai cũng biết Linus chuộng KDE và ghét GNOME ra mặt, GNOME vẫn được phần nào đó kernel developer ưa chuộng. Hình chụp trong các bài OLS năm nay toàn là GNOME.

Linux bây giờ không còn là sân chơi cho các lập trình viên đẹp trai vui tính, "làm cho vui". Xem danh sách tác giả các bài viết sẽ thấy toàn là các đại gia trong lĩnh vực Tin học-Viễn thông: IBM, AMD, Google, Nokia, VMware, Intel, Oracle, Red Hat, Novell, NEC, Nortel, Monta Vista... Thỉnh thoảng mới có một vài địa chỉ email "lạ", lạc lõng. Số bài viết xuất xứ từ IBM, Intel và Google đặc biệt nhiều. Về các đại diện của các bản phân phối Linux, chỉ có mỗi Red Hat là được dăm ba bài (Novell hình như một bài), còn lại vắng tanh. Chắc lo đóng gói nhiều quá.

Bài giới thiệu về hỗ trợ Linux với kiến trúc Cell của IBM rất thú vị. Kiến trúc Cell bao gồm một vi xử lý Power cộng với tám "vi xử lý nhí" chung quanh, được thiết kế thiên về tính toán (chắc tại vì đây là kiến trúc dành cho các trò chơi đồ hoạ 3D). Nhìn cách khác, Cell bao gồm một bộ vi xử lý "xoàng" ("có" dual core à) ở trung tâm, điều khiển tám trung tâm súc vật chung quanh. SPE được thiết kế để chịu tải nặng, tính toán kiểu trâu bò (ví dụ, trong khi con Power trung tâm chủ yếu dùng thanh ghi 64-bit, SPE được trang bị hoàn toàn gồm thanh ghi 128-bit. Trung tâm có cache 32KB cho code, SPE có "sơ sơ" 256KB). Phải chi mình kiếm được một con Cell, về vọc lập trình song song sướng phải biết. Mục đầu tiên cho wishlist 2008: nghiêm túc xem xét khả năng của Cell và giá thành của Playstation 3. Tự nhiên thấy yêu RISC quá (mà dạo này hình như làm việc với RISC cũng hơi bị nhiều)

Một bài nói về cách tìm lỗi trong những hệ thống cluster lớn, cỡ Google. Bài viết nhấn mạnh tầm quan trọng của kỹ thuật lần vết (tracing) chứ không theo cách tìm lỗi truyền thống dùng debugger. Lý do đơn giản: lỗi quá phức tạp, khó có thể dùng cách truyền thống. Bài viết đề cập đến cách tìm lỗi race condition, loại lỗi thuộc loại "thoắt ẩn thoắt hiện", nhưng chắc như nấm mọc sau mưa trong những hệ thống cluster to cỡ Google. Bài viết đề cập những kỹ thuật (và ví dụ) nói chung là cao cấp. Đọc hiểu... sơ sơ. Ai tự cho mình là cao nhân, nên đọc để tự kiểm tra trình độ.

Loạt bài về tìm lỗi và công cụ tìm lỗi còn có Frysk (dùng GCJ), tìm hiểu bên trong ltrace (chỉ từng hàm một) và bài sử dụng utrace/uprobe/kprobe. Bài về uprobe cũng đề cập đến SystemTap -- một dự án được coi là đối thủ Linux tiềm năng của DTrace. Sau một hồi âu yếm anh Google, vỡ ra một điều: DTrace vẫn dễ dùng hơn và an toàn hơn SystemTap. Bởi vậy hoặc cài OpenSolaris vào và dùng DTrace, hoặc chấp nhận rủi ro và dùng uprobe/SystemTap.

Các bài khác gồm:

• Nén bộ nhớ cache (hơi bị hàn lâm)
• ACPI in Linux. Ai chưa rõ về ACPI, APM... nên đọc bài này. Không đòi hỏi gì đặc biệt ở người đọc.
• Cool Hand Linux trình bày về quản lý nhiệt độ (bằng ACPI) cho thiết bị cầm tay
• Asynchronous System Calls. Nên đọc để hiểu thêm về chủ đề đang nóng hổi này trong giới lập trình Linux kernel những tháng gần đây. Bài viết trình bày về fibrils, syslets và việc cài đặt lại KAIO (asynchronous I/O) bằng syslets.
• Bài "Keeping Kernel Performance from Regressions" trình bày quy trình kiểm tra, theo dõi hiệu năng của Linux.
• "Breaking the Chains", bài viết "quảng cáo" LinuxBIOS.
• GANESHA -- user-space NFSv4 server. Bài "A New Network File System is Born: Comparison of SMB2, CIFS, and NFS" nói về NFS, SMB/CIFS, SMB2 và network filesystem nói chung. Còn có phần nói về hiệu suất của SMB. Khá bổ ích.

Ngồi đọc kiểm tra bản dịch của chị Clytie, thấy chị cập nhật phần copyright trong các tập tin PO cho mình luôn. Hồi nào giờ vẫn làm biếng, chẳng chịu cập nhật dòng copyright này. Giờ ngó lại thấy... xa xôi quá. "pclouds@gmx.net" với "pclouds@vnlinux.org" vào năm 2002. Hai địa chỉ email này đã chết từ lâu lắm lắm rồi. Không ngờ cái số dịch GNOME của mình tới giờ đã là năm năm rồi. Ráng dịch thêm năm năm nữa rồi về hưu, giao lại chức trưởng nhóm cho người khác. Chả biết lúc đó có ai chịu làm không ta? Hay lại ca bài ca con ếch?

Lại lần ngược thời gian. Bản dịch GTK+ đầu tiên có tên mình là revision 7771, một ngày đẹp trời tháng hai năm 2003 (lại tháng hai!) Theo thông tin SVN thì chính xác là ngày đó cách đây bốn năm, năm tháng. Commit vào glib còn xưa hơn, revision 1935, cách đây hơn năm năm. Pablo commit dùm. Không biết bây giờ Pablo ra sao rồi, có còn làm cho Mandriva không nhỉ?

Commit đầu tiên vào GTK+ cũng đánh dấu ngày đầu bồng bột: thêm dòng copyright của mình rồi xoá hai dòng copyright của hai bác Hoàng Ngọc Tú và Joern V. Kattchee! Theo SVN thì hai bác đã bắt đầu dịch từ revision 4064, cách đây hơn sáu năm. Bản dịch GTK+ đã được cập nhật hơn tám mươi lần trong suốt sáu năm qua (không biết chữ OK đã bị dịch đi dịch lại bao nhiêu lần?)

Xin lỗi hai bác vì đã xoá tên hai bác suốt hơn bốn năm trời. Mấy ngày tới hoàn tất kiểm tra phần dịch GTK+ của chị Clytie, sẽ thêm lại tên hai bác. Sắp tới cũng sẽ làm lại trang live.gnome.org/GnomeVi, liệt kê danh sách những người đã từng đóp góp vào dự án GNOME-VI.

(nhạc dạo đầu tèng teng téng teng, ồ ếch ếch, ếch ơi là ếch)

Thời gian qua có một số sự kiện đáng chú ý. Sự kiện nóng hổi nhất, làm xôn xao giới ếch (và có lẽ cả giới IT nói chung) nhiều nhất là sự ra mắt chính thức của giấy phép GPL-3. Nhìn chung dư luận ủng hộ GPL-3 thì ít mà e dè với GPL-3 thì nhiều. Một số còn cho rằng GPL-3 có thể gây ra "nội chiến". Ít ra qua sự kiện này ta có thể biết được Richard Stallman và FSF nắm trong tay được bao nhiêu dự án (bao gồm các dự án khá quan trọng như gcc, glibc và các công cụ cơ bản của Linux).

Sự kiện có phần ít sôi nổi hơn đến từ Novell. Sau khi Miguel De Icaza phát động chiến dịch cài đặt công nghệ Silverlight dưới tên Dự án Moonlight, Novell lại dành một tuần cho nhân viên Linux của mình làm bất cứ gì mình thích trong giờ làm việc, gọi là Hackweek. Chưa rõ tuần lễ này mang lại kết quả như thế nào, nhưng ít ra qua đó cho thấy nhân viên Linux/OSS của Novell cũng hơi bị đông (qua những gì thể hiện trên blog). Hi vọng sắp tới, Red Hat, Canonical và các công ty khác cũng phát động một phong trào tương tự.

Một sự kiện khác mang tính kỹ thuật nhiều hơn, cũng vừa diễn ra trong thời gian gần đây: Ottawa Linux Symposium. Tài liệu OLS có tại đây. Như năm ngoái, sẽ có một bài tóm tắt dành cho OLS. Tuy nhiên bởi vì tài liệu OLS thuộc loại, nói văn chương là "hàn lâm", nói nôm na là "chữ nhiều, hình đẹp... nhưng đọc không hiểu", nên cần vài tuần để tiêu hoá.

Tin Việt hoá. Chị Clytie gần đây đã khoẻ lại và bắt đầu cập nhật GNOME-VI ồ ạt. Trưởng nhóm GNOME-VI đang cố gắng nhịn lười để kiểm tra các bản dịch của chị Clytie (nhờ đó phát hiện ra một lỗi nhỏ trong Epiphany, chắc tuần sau luộc luôn quá).