Lý sự pclouds

(Coi như bài này được viết vào một ngày nào đó của tháng 2 năm 2007)

(Cấm thằng K$ đi post bậy bạ lung tung)

Vào một ngày xấu trời tháng hai, học kỳ hai năm lớp bảy, ta lượm được đâu đó cuốn "Pascal cho mọi người". Ma xui quỉ khiến làm sao ta lại đọc cuốn sách đó, để giờ đây lãnh nhận hậu quả đau thương...

Mười hai năm, kinh qua Pascal, C, C++, Assembly (x86 và ARM), Perl, Python, Ruby, PHP, TCL, Visual Basic, C#, Erlang, Javascript, Java, Objective C, Smalltalk (Squeak), Bash, TeX, Bison, Lex... (một số đi qua đời ta rồi... dông mất, dấu ấn còn lại chỉ có mỗi cái tên).

Ta từng mần DOS (cả COM và EXE), Windows (NE format cho Win 3.1 rồi PE cho các thế hệ sau). Ta nhớ hồi cái máy 386 nhà ta ngừng thở. Ta vào phòng vi tính ĐHBK viết... virus. Con virus đó mừng sinh nhật một người. Người đó giờ ở đâu không biết. Nếu trí nhớ ta không lừa ta, ngày đó là 13/2. Còn con virus chắc ngủm củ tỏi từ lâu lắm lắm rồi. Ta vẫn nhớ ta thích dạng thức COM lắm, vì nó... chả có gì cả ngoài quy định rằng tập tin sẽ được nạp vào offset 0x100 (hoặc một con số khác).

Ta nhớ debug.com.

Ta nhớ, sau bao năm tháng miệt mài trui luyện Pascal, ta quyết định học hai khoá Pascal cơ bản và Pascal nâng cao ở ĐH Tổng hợp, để xác định xem khả năng ta ở mức nào. Ta nhớ hình như sau hai khoá này, ta không còn học thêm bất cứ khoá học nào khác.

Hồi ấy ta viết chương trình to lắm bằng Pascal (chẳng rõ ta viết cái gì, hình như toàn là game). Ta phải dùng đến cả overlay trong Pascal.

Ta vẫn nhớ hồi ta học ở ĐH Tổng hợp, mạng ĐH vẫn dùng Novell Netware (dù ta chẳng biết gì). Ta khám phá ĐH Tổng hợp từ những ngày ta còn ngồi ghế Lê Hồng Phong. Giờ đi qua khu trung tâm tin học của ĐHTH vẫn thấy lưu luyến.

Ta vẫn còn tấm chứng chỉ Tin học Quốc gia (bằng B). Chứng chỉ tin học cao cấp nhất của ta cho đến tận bây giờ.

Ta nhớ ta đã từng vọc Direct X thuở Direct X còn mới toanh (hoặc ta tưởng thế).

Ta đã phải luộc lên luộc xuống MFC. Đến nỗi giờ đôi khi vẫn thấy bóng dáng "MFC pattern" đâu đó trong mớ mã nguồn ta vẫn phải ngày ngày ngồi đọc. Thuở ấy đọc trên PC World chữ "framework" vẫn không hình dung ra nó là cái gì. Giờ nghe đến framework là chán chả muốn nghe tiếp.

Nhắc đến PC World, ta nhớ ta đọc được PC World từ những số đầu tiên (hình như số đầu năm 94). PC World những năm đầu rất hay, càng về sau càng dở. Quảng cáo thì nhiều, giá thì tăng. Đến lúc PC World chuyển sang bìa cứng, thì ta nói lời tạm biệt với PC World. Từ ngày tạm biệt PC World, hình như lượng sách/báo giấy ta đọc cũng giảm dần về con số không (không tính đọc chùa trong nhà sách, mà số lần đọc chùa cũng giảm dần qua ngày tháng).

Ta đã từng chạy xuống tầng hầm của Windows (DDK) rồi bỏ chạy lên vì khó bỏ bu. Khó vì thiếu cái gọi là "Mã nguồn Windows". Cũng có thể khó vì cái kiến trúc "micro-kernel" của NT (Vào lúc đó còn chưa biết phân biệt các loại kernel, vì có biết "kernel" là gì đâu).

Ta nhớ, vào thời Internet chưa phổ biến như ngày nay, ta hăm hở chạy vào nhà sách Xuân Thu, đọc chùa sách về đồ hoạ, tìm hiểu về định dạng GIF. Ta nhớ hình như hồi ấy ta disassemble mấy cái game để tìm hiểu cách lấy hình trong game cũng hơi bị nhiều. Hồi đó lấy được một tấm hình "mát mẻ" trong game Tây du ký. Dĩ nhiên lần disassemble kinh khủng nhất là móc cái thuật toán của caro.com, cài vào chương trình ta rồi... đem nộp cho thầy giáo. Không hiểu sao thằng caro.com nó chơi hay thế mà chương trình ta nó chơi dở tệ. Hổng chừng nhờ chơi caro.com nhiều quá nên ta lên tay chăng?

Nhắc đến kinh nghiệm disassemble, giờ ta vẫn sùng thằng vietkey. Ta tưởng hắn có mánh khoé nào hay lắm khi chỉ cần một chương trình exe duy nhất là chạy được mà không cần dll đi kèm (hook toàn hệ thống trên Windows thuở ấy buộc phải dùng dll). Ta hăm hở đi disassemble để tìm hiểu tại sao. Ta đọc qua những dòng assembly cực kỳ phức tạp. Cuối cùng ta phát hiện ra, hắn dùng... UPX (hay một chương trình đại loại thế) để nén file exe. File đó chứa cả file dll mà hắn bung ra quăng vào thư mục system của ta mà ta không hay biết. Ta giận hắn từ đó.

Ta nhớ ta cũng đã từng "Việt hoá" Windows 3.1 bằng cách sửa String table. Thế mới thấy cái số dịch thuật nó đã gắn liền với ta từ lâu lắm lắm.

Ta vẫn nhớ ta không thích xài Delphi và "Pascal hướng đối tượng". Ta nhớ là ta... vẫn không thể nhớ vì sao ta ghét. Ta không xài Kylix khi Borland chuyển Delphi qua Linux. Không hiểu sao thằng bạn mập của ta nó cứ Delphi là số một. Khổ thân ta, nó lập trình giao tiếp phần cứng mà cứ Delphi tiến tới.

Ta nhớ ta có một thư mục chép đầy virus (mà chẳng mấy khi chịu đọc). Hậu quả là ta phải hạn chế quét virus trên máy mình vì nhỡ ra nó xoá cái kho virus của ta thì khổ. Chẳng biết cái kho virus đó giờ nó đã đi đâu về đâu.

Ta nhớ hồi đó ta dùng Excel macro để viết hàm chuyển số sang chữ. Buồn thay Excel macro cũng vào hạng đi qua đời ta rồi dông mất. Giờ ta chẳng biết gì hơn ngoài hai chữ "Excel macro". Nói về khoảng "dông mất", ta nhớ hồi xưa ta cũng biết dùng Word (ta còn xài cả Quattro trong DOS). Tuy không trùm nhưng ít ra cũng biết. Giờ ta chẳng biết xài Word bao nhiêu :(

Ta nhớ ngày xưa ta không công nhận khái niệm "ứng dụng web". Ta ghét nó lắm. Cho đến một ngày ta học PHP. Rồi tay ta nhúng chàm.

Ta nhớ ta đã phải đọc MSDN rất nhiều. Ta nhớ ta ghét mô hình COM lắm vì nó phức tạp và khó hiểu. Giờ ta vẫn ghét (ghét cả IPC nói chung). Tiếng Anh ta khá lên có lẽ cũng nhờ giai đoạn ta vùi đầu vào MSDN (và khoảng thời gian ta luyện Linux HOWTO), bởi vì có bao giờ ta học tiếng Anh cho ra hồn đâu. Tiếng Anh của ta giờ vẫn te tua như cái mền rách vì cái tội không chịu học hành nghiêm chỉnh.

Bỏ lại Windows sau lưng (giờ mấy thấy mình sai lầm, biết vậy hồi xưa ngu gì bỏ), ta chuyển sang Linux. Đến giờ này đã đụng đến hầu hết các thành phần trong Linux (trừ một số cục cực kỳ khó xơi như xorg, gcc, kde...). Phần này ba năm nữa ta sẽ viết tiếp nhân kỷ niệm mười năm một ngày, một ngày còn ngu dại gấp ngàn lần ngày ấy tháng hai, ngày ta mua đĩa Red Hat Linux 6.2 để mừng thi đậu Đại học. Ta nhớ ta chẳng học được bao nhiêu từ Đại học.

Ta nhớ hồi làm bài miễn thi, ta viết trò xếp gạch trong Linux với SDL. Xong ta biên dịch lại trên Windows (không rõ hồi ấy ta đã biết cross-compile chưa). Chương trình chạy tuyệt vời. Máy Windows 98 của ta thử tuyệt vời. Ta đem nộp. Máy thầy giáo ta chạy Windows NT. SDL nó phản ta, nó không thèm chạy. Ta vẫn không hiểu tại sao nó không chạy. Hình như lần đó ta phải đi thi.

Ta nhớ năm đầu Đại học ta hăng hái vào thư viện trường để đọc về OpenGL và Linux. Đó là thời gian chăm chỉ nhất trong suốt 4 năm "học đại" của ta.

Ta nhớ ta vẫn không hiểu gì nhiều về "design pattern". Trong khi mấy đứa bạn ta thuộc làu design pattern và các nguyên lý phát triển phần mềm. Ta dốt lắm. Ta chỉ biết làm theo cách cảm tính của ta.

Ta nhớ ta chẳng biết gì cả về mạng trước khi dùng Linux. Hậu quả còn lại là mỗi khi cần lập trình mạng trên Windows, ta lôi sách... UNIX ra đọc rồi ráng suy đoán thử xem nó giống thế nào với winsock.

Ta nhớ, sau biết bao năm trời dùng C++, ta mới đọc được cuốn C++ Library Reference và hai cuốn về STL. Từ đó ta mới mở mắt ra rằng những gì ta biết trước đây về C++ toàn là những thứ trong C++/MFC. Từ đó ta mới biết đến STL, những ưu điểm vượt trội của STL cũng như ác mộng thông báo lỗi liên quan đến template.

Ta ghét viết CV bởi vì nhìn lại, ta chẳng có gì để viết vào cả (chẳng lẽ ta cho vào CV cái bằng tin học đã hết hạn từ lâu của ta?). Ta đã làm được rất nhiều. Nhưng ta không thể ghi cái gì cả. Vì nó chẳng có nghĩa lí gì cả với bất cứ ai, trừ ta.

Mười hai năm, giờ chỉ là con số không. Một cộng một bằng không do... tràn số. Ta già thật rồi.

Ta vẫn là ta.

Sau gần một tháng mày mò châm chọc swfdec. Cuối cùng cũng chạy được blocky.swf trên swfdec. Kết quả là sửa 7 tập tin, xoá 33 dòng, thêm 122 dòng. Hổng hiểu sao không có cảm tình lắm với gnash. Thành ra giờ cái flash nào không chạy với swfdec thì đem swfdec ra mần tiếp, không kiểm tra với gnash.

Phần còn lại để có thể chạy blocky.swf hoàn hảo trên swfdec bao gồm:

1. Mần lại createEmptyMovieClip và drawing API (chủ yếu ba hàm lineStyle, lineTo và moveTo)
2. Cài đặt action GetURL2
3. Mần toàn bộ lớp Sound

Theo tin hành lang từ Benjamin Otte thì để cài lớp Sound, cần phải tái cấu trúc swfdec lại một chút. Thành ra nhường hắn phần này. Vụ createEmptyMovieClip và drawing API, có lẽ sẽ dựa trên SwfdecGraphicMovie thay vì SwfdecSpriteMovie. GetURL2 dành cho phần "ghi điểm". Chơi dở quá thành ra cũng chẳng cần ghi điểm làm gì, để từ từ tính.

Một lập trình viên giỏi là một lập trình viên có thể tìm lỗi chương trình không cần dùng debugger (cố tình không dịch debugger). Có nhiều kỹ thuật khác nhau để có thể tìm lỗi. Kỹ thuật dùng debugger là một trong những lựa chọn dở nhất (phụ thuộc vào debugger, trở nên lười suy nghĩ, và có rất nhiều trường hợp dùng debugger để "nhảy từng bước" là không khả thi). Bởi vậy, đừng dùng debugger!

Nói đi cũng phải nói lại. Debugger cũng hữu dụng trong một số trường hợp nhất định. Debugger thuộc hàng cây đa cây đề trong giới Linux, gdb, vẫn là lựa chọn số đầu tiên.

Nói về gdb, một số lệnh thường dùng bao gồm:

• run (r ), dùng để chạy chương trình. Đối số của run sẽ được dùng làm đối số cho chương trình cần chạy.
• continue (c ), chạy tiếp. Điểm khác biệt với run là run sẽ luôn chạy lại chương trình, còn continue thì chỉ chạy tiếp phần còn lại.
• quit (q), thoát. Đơn giản dễ hiểu.
• next (n), chạy từng lệnh một.
• step (s), chạy từng lệnh. Nếu lệnh đó là một hàm thì nhảy vào hàm đó (next nhảy qua hàm đó).
• finish (fin), chạy đến hết hàm đang chạy, rất tiện để nhảy ra sau khi dùng step.
• until (u) số dòng, chạy cho đến dòng đã ghi (hoặc chạy luôn nếu chương trình không bao giờ đến dòng đó)
• (không gõ gì cả), chạy lại lệnh đã chạy cuối cùng.
• break (b), đặt breakpoint. Tham số truyền vào có thể là số dòng, hoặc tên hàm, hoặc tên tập tin:số dòng.
• list (l) dùng để xem mã nguồn, ở một dòng nào đó, hoặc xem một hàm nào đó. Đối số giống như breakpoint. Gõ list không tham số sẽ hiện ra mã nguồn quanh dòng đang chạy. Gõ lần nữa sẽ hiện mã nguồn của những dòng kế tiếp và cứ thế tiếp tục. Khi đang dừng ở một dòng lệnh mà không nắm được ngữ cảnh, cứ gõ "list" (không tham số)
• print (p) in giá trị. Tham số là một biểu thức dạng C. Thậm chí đưa lời gọi hàm cho print, nó cũng chịu luôn (nó chạy hàm đó và in kết quả)

Một lưu ý là gdb cũng hiểu Tab nên cứ nhấn Tab nếu có thể. Mớ lệnh trên đủ để tự nhận là đạt "gdb-thủ sơ cấp". Trình độ trung cấp bao gồm thêm một tí lệnh:

• help
• info, disable, enable, delete. Tập lệnh này áp dụng cho khá nhiều thứ. Với những gdb-thủ đai sơ cấp thì những lệnh này áp dụng cho breakpoint. Tên sử dụng với những lệnh này là breakpoints (có sờ). Để hiện danh sách breakpoint, dùng "info breakpoints". Để xoá một breakpoint, dùng "delete breakpoints số thứ tự breakpoint". Tương tự.
• display (d). Nhận đối số như print. Điểm khác biệt là display sẽ in kết quả sau mỗi lệnh gdb. In hoài. Không như print chỉ in một lần rồi thôi.
• backtrace (bt). In stack frame hiện thời.
• attach, nhận process id. gdb sẽ debug chương trình đó.
• detach, ngược lại với attach.

Ở mức trung cấp, gdb-thủ phải biết tự đọc help, tự mày mò info page, từ hỏi anh Google. Cấm có hỏi ai khác.

Sau khi hỏi anh Google xong mới nhận ra là gdb thuộc loại của hiếm. Hảo thủ cũng hông nhiều. Đành phải è cổ ra đọc manual. Phần sau thuộc loại học thuộc lòng trả bài (không phải kinh nghiệm chinh chiến như phần trên).

Các gdb-thủ trung cấp dạn dày chinh chiến đa phần đều đau tay vì gõ nhiều (cho dù chỉ gõ chữ viết tắt). Bởi vậy cần phải biết về lệnh set logging và show logging, dùng để lưu những lệnh mình gõ lại, mai mốt xài sau. Một phím khác cũng nên nhớ là Ctrl-o có tính năng tương tự Ctrl-r trong bash. Nếu các symbol có ký hiệu đặc biệt (như dấu ngoặc) thì có thể bao symbol trong nháy đơn và dùng TAB.

• Tập lệnh liên quan đến thread bao gồm thread, info threads và thread apply chả bao giờ biết xài.
• Lập trình với fork thì cần biết thêm set follow-fork-mode, info forks, fork, attach/detach fork.
• break... if
• tbreak (break dùng một lần rồi bỏ)
• rbreak, break với biểu thức chính quy.
• Dùng watchpoint để dừng tại một điểm nào đó nếu thoả điều kiện. Watchpoint không cần cho biết vị trí cần theo dõi vì nó sẽ theo dõi mọi nơi. Tập lệnh bao gồm watch (ghi), rwatch (đọc) và awatch (cả đọc và ghi)
• Dùng catchpoint (catch và tcache) để xử lý C++ exception.
• next, step với tham số (số lần chạy)
• Xử lý signal với handle
• frame để nhảy lòng vòng trong stack frame. Lệnh hỗ trợ gồm up và down.
• backtrace full
• edit để sửa mã nguồn
• forward-search, search và reverse-search để tìm trong mã nguồn.
• dir để thêm thư mục mã nguồn
• info line để tìm số dòng của một symbol nào đó.
• disassemble, nexti, stepi, info registers
• Lưu snapshot bằng "checkpoint".
• Lên đến trình độ "gdb cao thủ", gdb-thủ sẽ nhận ra một lệnh "khác" mà dân xài debugger vẫn thường dùng như lệnh next: start. Lệnh này chạy như run, nhưng dùng lại ở hàm main. Chán!
• Lệnh shell: shell và make, path, cd, pwd.
• Xem bộ nhớ bằng "x", lưu giá trị trong bộ nhớ với dump hay append, phục hồi với restore
• set print pretty on
• set print object on
• Biến nội bộ của gdb bắt đầu bằng $ (show convenience)
• Xử lý macro với macro expand, info macro...
• Đặt tracepoint để lưu "log": trace và collect, passcount, actions, while-stepping, tstart, tstop, tstatus, tfind, tdump
• whatis để in kiểu của symbol
• add-symbol-file
• gdb -tui
• Có thể thay đổi dạng xuất của lệnh print bằng "print /F" trong đó F là: x (dùng hoài), d, u, o, t, a, c, f.
• Phần phía sau của print là một biểu thức. Nó có thể là một mảng với định dạng "{ELEMENT, ELEMENT... }". Dùng để coi phần sau là một mảng (đặt sau biến, theo sau là số phần tử). Dùng::để xác định theo tập tin hoặc hàm theo dạngFILE::VARhoặcFUNC::VAR. Ép kiểu bằng {TYPE}`.

Để đạt đến trình độ "gdb siêu cao thủ", cần phải biết thêm remote debugging, debug trên target khác.

Tóm lại có thêm hai lí do để không dùng debugger:

• Khó dùng
• Cao cấp quá :P

Xin biểu dương tinh thần làm việc không mệt mỏi nghị lực kiên cường của bạn [Lông Trăn](http://ngonngu.net/bNb/. Ít ra nhờ bạn Trăn mà GNOME-VI) vẫn còn thoi thóp.

Nhân tiện tự biểu dương tinh thần hỗ trợ "xém xíu mỏi" của bạn Bi (chắc chuẩn bị đổi tên từ Bi Cờ Lao sang Bi Còn Lười quá).

Nhắn nhỏ bạn Trăn, dạo này chị Clytie đang tiếp tục dịch KDE. Bạn Trăn có còn rảnh thì xem lướt qua một lượt coi cần sửa chỗ nào. Mong bạn Trăn giữ gìn sức khoẻ sau này còn... dịch tiếp. Chúc bạn Trăn sớm lấy vợ sinh con, dạy con học chữ Việt để dịch phụ bố. (Nếu dạy vợ được luôn càng tốt, nhưng vụ này hơi khó)

Bi Chia Lít-đờ (Bi cheerleader).

Không hiểu tại sao không nhận được tin kqemu (qemu accelerator) công bố mã nguồn hồi tháng hai :(

Thử VirtualBox với install-x86-minimal-2007.0-r1.iso (thử với BeleniX không chạy, mà chắc ISO dỏm, boot thật còn không chạy). Nói chung chạy cũng được. Kiểm tra khả năng với:

time od /mnt/cdrom/image.squashfs|grep a > /dev/null

image.squashfs có kích thước khoảng 46MB nhưng do dùng od để chuyển sang dạng hex (ascii) nên kích thước sẽ tăng lên đáng kể (khoảng 180MB với gần 3M dòng). Kết quả: real 17.4s, user 1.82s, sys 15.59s. So với vmware, kết quả tương ứng là: real 15.124s, user 0.54s, sys 14.56s. Phải nói là ấn tượng!

VirtualBox tuy vậy cũng thua vmware vài chỗ:

• Không hỗ trợ truy cập physical device
• Vụ autograb hơi khó chịu, cách lấy lại keyboard/mouse bằng Right-Ctrl cũng khó (chưa quen)
• UI dùng Qt :( Đây là ứng dụng đầu tiên đòi Qt trên máy này.

VirtualBox hơn VMWare một chỗ:

• Open-source, công nghệ virtualization bây giờ mở ra trước mắt. Thích chọc phá gì thì vô tư.

Vụ VirtualBox bản GPL không hỗ trợ RDP không dính dáng gì đến mình cả. Hi vọng GPL developer sẽ sớm hỗ trợ VNC (đơn giản hơn).

Kết luận:

• Nếu không vì sử dụng bản Windows XP (physical device) thì đã bái bai Vmware rồi. Đằng nào setup vmware để chạy thẳng XP cũng không xong (BSOD). Thôi bai vmware quách cho rồi.
• Khuyến khích sử dụng VirtualBox (trừ khi đòi hỏi hiệu năng ở mức tốt nhất)

TB. Một hệ điều hành dùng phần mềm tự do giờ còn thiếu gì nữa nhỉ? Autocad, 3D editing software, Flash authoring tool, flash player (/me ôm swfdec hack tiếp), một vài cái driver... ôi trời vậy là ngon rồi.

À còn thiếu một cái quan trọng Xilinx synthesis, flash writer cho Xilinx FPGA.

Bắt chước bạn Lông Trăn làm cái sơ kết sáu tháng đầu năm. Trước hết là phần ... tin thời sự. Nhóm năm ban nhạc dẫn đầu đã có thay đổi đáng kể khi hai ban nhạc thứ tư và thứ năm cùng nhau bứt phá. Blackmore's Night nhảy từ thứ tư sang thứ hai, vượt qua cả Nightwish và Apocalyptica. Within Temptation cũng không chịu kém khi nhảy... ngược từ thứ năm xuống thứ sáu, nhường chỗ cho thành viên mới: Draconian. Apocalyptica xuống là có lí vì cũng lâu rồi chả nghe Apocalyptica. Nightwish dạo này cũng ít nghe. Nightwish vừa mới tuyển nữ ca sĩ mới Anette thay cho Tarja. Một phút chia buồn, tưởng nhớ Nightwish-cũ. Anette tuy hay, nhưng giọng yếu yếu. Việc Draconian nhảy vào tốp năm cũng không có gì đáng ngạc nhiên: Draconian là một trong những ban nhạc được nghe thường xuyên nhất trong gần một năm trở lại đây.

Tán phét xong. Vào đề. Thực ra phần tán phét cũng thể hiện ý đầu tiên: lười. Sáu tháng đầu tiên được đánh dấu bằng một phong thái lười hết sức đặc trưng. Kế hoạch còn ngập đầu mà ngày nào cũng ... hứa hôm sau sẽ làm. Lạy trời lạy phật sáu tháng cuối năm bớt lười đi.

Nếu lấy wishlist ra mà xét thì nói chung cũng hổng tệ lắm:

• Đọc sơ qua về XComposite
• Không coi được D nhưng ngó qua được cái Erlang
• Mò được vài chữ Thái
• Thò tay vọc swfdec tùm lum
• Emacs yêu thương hết sức được nâng niu chiều chuộng (trong công ty)
• Phần "điện tử", có coi chút đỉnh verilog. Vẫn phân vân không biết có nên sắm Spartan 3E starter kit hay không.
• Sắm cái Laptop

Một số cái khác tạm gọi là "thành tích" không có trong wishlist:

• VxWorks
• ClearCase
• Biết xài (sơ sơ) router dòng E của Juniper

Phần không hoàn thành trong wishlist thì nhiều. Cái đầu tiên không hoàn thành là "Không ghi thêm gì nữa vào wishlist". Wishlist được bổ sung thêm một số thứ như:

• Chuyển busybox sang Windows (bash2c bị huỷ từ trong trứng nước)
• Học tiếng Thái
• MinGW-Git
• Verilog, Erlang (kiếm cái gì đó để làm)
• lscreen
• Epiphany extension: Google Gears, chụp ảnh trang web, tab history
• OpenSolaris (hoặc dtrace)
• (Chờ nhớ ra ghi tiếp)

Trong wishlist tình trạng những mục te tua nhất như sau:

• GNOME-VI tiếp tục bị bỏ bê toàn diện. Lý do: Lười.
• dev-ruby: bụi bám đầy. Lười.
• Kanji: thấm được vài chữ rồi lại trôi theo gió theo mây.
• TeXlive: chắc để sang năm là vừa.

Tổng kết chung:

• Đặc điểm: lười toàn diện.
• Tiến độ: nếu không tính mấy cái mới thì tiến độ chấp nhận được. Nếu tính đến chuyện wishlist tiếp tục được tăng cường theo thời gian thì coi bộ tiến độ dưới mức trung bình.
• Giải pháp: đi ngủ, kệ nó.

Động lực

Git trên Windows. Git đã chạy trên Windows với kho mingw.git. Tuy nhiên có một số vấn đề:

1. Cài đặt phức tạp, cần phải có MSYS và bash. Việc dùng lẫn lộn các môi trường giả lập POSIX trên Windows có thể dẫn đến rất nhiều vấn đề nhức đầu. Ai đã từng cài cả Cygwin và MSYS chung, chắc cũng có cảm nhận chút đỉnh về điều này. Như vậy viết buộc sử dụng MSYS sẽ hạn chế tầm sử dụng của Git nếu người dùng đã cài đặt sẵn một môi trường giả lập POSIX khác. (Mà nói chung Cygwin là may rồi. Xài MKS Toolkit nó dở dở ương ương còn khổ hơn)
2. Không tương thích hoàn toàn với Git chính gốc. Bản Git MinGW đòi hỏi đặt cố định đường dẫn cho sort và find để tránh dùng nhầm "hàng hiệu" của Windows. Những thay đổi dạng này chắc chắn không thể đưa vào Git. Như vậy khả năng đưa Git MinGW vào Git gốc coi như mờ mịt.
3. Giải pháp chuyển tất cả các lệnh của Git từ bash sang C là không thực tế. Các lệnh mới thường được viết bằng bash cho nhanh. Đến khi ổn định thì may ra mới chuyển sang C. Thời gian từ khi lệnh mới xuất hiện ở dạng bash đến khi chuyển thành C thường rất lâu. Nếu cứ đợi chuyển sang C thì dân Windows mới xài "ngon" thì coi như người dùng Windows trở thành công dân hạng hai.

Mục tiêu

Chuyển toàn bộ các lệnh Git bằng bash sang C, tự động.

Phạm vi

Giải quyết cả ba vấn đề nêu trên. Với vấn đề thứ nhất, dự án này chỉ loại bỏ phụ thuộc vào bash và MSYS. Tập lệnh POSIX vẫn cần phải cài đặt trên Windows. Tập lệnh này đã được chuyển sang Windows từ lâu nên cũng không phải vấn đề gì lớn. Hai vấn đề còn lại giải quyết triệt để. Phần còn lại của vấn đề (tập lệnh POSIX) có thể được giải quyết trong dự án (tưởng tượng) "chuyển busybox sang Windows". Một trong những đề tài Hâm hết sức hâm.

Tóm tắt phương pháp

Điều chỉnh bash để có thể mượn tay bash phân tích bash script, sau đó xuất ra dạng XML thô. Viết một chương trình đọc XML và chuyển sang C. Viết một thư viện (chôm phần nhiều từ bash) để cài đặt chung với mã nguồn C được phát sinh ở trên. Thư viện này cài đặt các hàm nội bộ của bash, các biến toàn cục, quản lý tiến trình... Có thể coi thư viện này là "libbash". Do mục tiêu là các lệnh Git, thư viện này không bắt buộc phải hoàn chỉnh, chỉ cần đủ để chạy những lệnh của Git.

Khả năng thành công

Chà.. Phần khó nhất sẽ là cài đặt thư viện libbash. Có thể một số tính năng đặc trưng của POSIX (như signal) sẽ gặp nhiều vấn đề. Tuy nhiên để chạy các script bash đơn giản thôi thì có thể khả thi. Hơn nữa do không đòi hỏi phải "tương thích hoàn toàn" với bash nên khả năng thành công cao hơn. Cuối cùng, cùng lắm thì các script có thể được điều chỉnh để chạy chung với libbash nên giảm rủi ro thêm tí nữa. Kết quả cuối cùng: khoảng 70%. Nếu mần ngày mần đêm thì may ra trong hai tháng. Nếu mần đêm không mần ngày thì kéo dài đến năm sau.

Việc cần làm

Đánh giá xem busybox (với cả shell ash của nó) có đủ để chạy Git không. Nếu được, đánh giá tiếp khả năng chuyển đổi busybox sang Windows. Nếu mọi thử ổn, huỷ dự án này, chuyển sang dự án Hâm Bình Phương: Chuyển busybox sang Windows.

Có vẻ như busybox chạy với Git cũng ngon. Tạm ngừng dự án, kiểm tra khả năng chạy trên Windows của busybox.

Chi tiết

Như đã nói. Công việc sẽ gồm ba phần. Phần thứ nhất là sửa bash để xuất ra dạng XML (dễ đọc hơn so với bash script). Phần này... coi như xong. Không làm hoàn chỉnh nhưng có thể xuất ra các tập tin xml hợp lệ cho tất cả các script của Git.

Phần hai là đọc XML và phát sinh C. Phần này giao cho Ruby. Việc chuyển từ XML sang C cũng không đến nỗi cực khó. Chỉ cần đảm bảo không sai cú pháp C là ổn (đặc biệt cần chú ý các chuỗi). Phần này cùng lắm hết tuần xong ... sơ sơ. Đủ để có cái vọc với libbash.

Phần cuối cùng, libbash! Đỉnh cao công nghệ và cũng là vực thẳm tâm hồn. Xem xét sơ bộ đầu ra XML của bash, có thể thấy ngay phần lượng giá biểu thức cơ bản cần phải tách ra từ bash. Biểu thức cơ bản ở đây bao gồm expression expansion, variable assignment, command execution. Cục to nhất sẽ là expression expansion. Nếu tách được cục này ra coi như hoàn thành được 30-40% công việc. Variable assignment không khó. Nếu không nhầm thì git không dùng khái niệm array variable của bash, đỡ phải cài đặt. Phần command execution cũng bèo, trừ mỗi chuyện cài đặt các lệnh nội bộ của bash.

Nói về các lệnh nội bộ của bash, có hai lệnh rất đáng ngại là eval và source. eval đòi hỏi libbash phải có khả năng phân tích cú pháp bash (điều không thể trừ khi tham vọng làm libbash hoàn chỉnh). Lệnh này được sử dụng không nhiều trong Git. Lệnh thứ hai là source. Xét về nguyên tắc, source sẽ mở tập tin mới và gọi eval. Bởi libbash không hỗ trợ eval nên source chết. Vậy không cài đặt source ở mức libbash mà chuyển lên xử lý ở hai tầng đầu: bash2xml và xml2c. Nếu xml2c bắt gặp "source" thì sẽ gọi bash2xml để mở tập tin đó và xử lý luôn. Giải pháp này dĩ nhiên không hoàn hảo nhưng chấp nhận được: Git chỉ "source" git-sh-setup.

Phần còn lại của libbash, xử lý vòng lặp, các lệnh rẽ nhánh... không thành vấn đề. Vấn đề là thời gian và kiên nhẫn. Cả hai cái đều thiếu trầm trọng. Chán!

NSFW là viết tắt của "Not safe for work". Cái này ai cũng biết. Nhưng còn một cách viết tắt khác (mới biết). Trong trường hợp self-employed (dịch là sao cà, tự thuê?) thì nó chuyển thành "Not safe for wife". Thú vị ở chỗ so hai câu lại với nhau thì "wife" tương đương với "work". Ở công ty thì ta "work", ở nhà thì ta "wife". Wife là work mà work cũng là wife. Cái nào là thiệt, cái nào là giả? Công việc cũng là vợ, hay vợ cũng là công việc?