Lý sự pclouds

.. lại tiếp tục những gì còn dở dang. Công bố mở màn chiến dịch “Tí: giảm cân” (nối tiếp thắng lợi Việt Thảo và thất bại Ú).

"Tí: giảm cân" có một mục tiêu cực kì mờ mịt, hậu quả để lại của "Ú". Bao gồm giải quyết triệt để vấn đề tràn số và khả năng tiêu hoá vspell-text. Đồng thời đánh giá sử dụng danh mục từ words-vi.

Một mục tiêu ăn theo, nhằm "thư giãn" trong lúc bắt chuột là thêm từ loại cho words-vi.

Ngày chính thức kết thúc chiến dịch: mùng 10. Ngày dự định thực sự kết thúc chiến dịch: đâu đó hết tháng 2.

Phần còn lại ai cũng biết: tiền là tiền nhiều lúc có như không. Mới đăng ký Terpinus với vspell lên ohloh. Nếu tính theo giá thị trường (Việt Nam) 200 USD một tháng thì mình kiếm được cỡ 300 USD từ Terpinus và cỡ 5000 USD từ vspell. Ai mua hông tui bán tuốt!

Mấy cái nhận xét của ohloh về vspell hết sức vui.

Established codebase

The first lines of source code were added to vspell in 2003. This is a relatively long time for an open source project to stay active, and can be a very good sign.

A long source control history like this one shows that the project has enough merit to hold contributors's interest for a long time. It might indicate a mature and relatively bug-free code base, and can be a sign of an organized, dedicated development team.

Note: The source code for vspell might actually be older than the source control history can reveal. Many projects begin by duplicating a large amount of source code from an existing, older project. You can usually tell whether this is the case by looking for a rapid rise in the amount of code early in the project's history.

Nó phán vspell là "good sign". Cũng may nó kịp đính chính

Decreasing year-over-year development activity

Over the last twelve months, vspell has seen a substantial decline in development activity. This could mean many things. This may be a warning sign that interest in this project is waning, or it may indicate a maturing software base that requires fewer fixes. It's also possible that development on this project has branched to a new source control repository somewhere else.

Ohloh makes this determination by comparing total number of commits made by all developers during the most recent twelve months with the same figure for the twelve months before that. The number of developers and total lines of code are not considered.

Phải nói là chu kỳ phát triển của vspell là chu kỳ của vũ trụ. Mỗi năm vspell chỉ được phát triển vài lần. Nếu tính theo "tuổi vũ trụ" thì vspell chỉ có vài tháng tuổi thôi :D

Mới nhìn đúng là hay thật. Không còn ranh giới giữa máy thật và máy ảo nữa. Nhưng nhìn kỹ thì không hay lắm. Metacity (đoán chừng cả các wm khác) không hiểu các cửa sổ Windows trong máy ảo. Hậu quả là tuy nhìn đẹp thật nhưng xài chẳng ngon hơn. Hay tại mình chơi đồ Windows nên hỗ trợ không tốt? Biết đâu máy ảo Linux lại tích hợp tốt hơn.

Ngoài lề, timestamp đang tiến lên một bước để quản lý luôn công việc (thay vì chỉ quản lý cách sử dụng thời gian). Vẫn làm theo kiểu bottom-up, khó xài thì lại sửa. Nhiều khả năng Cùi Bắp sẽ ra đi (hoặc nhập chung với timestamp) bởi vì cái sự blốc bliếc do Cùi Bắp đảm nhiệm cũng không còn khác mấy so với "todo" của timestamp, chỉ hơn mỗi phần vẽ vời.

Ngoài lề tiếp, đành phải đau lòng quyết định tuần sau không nghe Persephone nữa. Nghe suốt tuần này rồi. Nghe nữa nghiện mất. Kỉ lục chứ chả chơi. Tuần sau lại quay về Tristania?

Hic.. lỡ iu Persephone rồi é é.. Mình dễ mềm lòng quá. Lạy trời Hades không kiếm mình tính sổ.

TB. Nghe Persephone riết, hôm nọ buộc lòng phải quay lại với metal, mới thấy cái ảnh hưởng phụ của Persephone: nghe Perfect Element của POS(Pain of Salvation) phê... lòi... đê mê...

Mấy tuần đầu năm chứng kiến những sự kiện động trời trong làng OSS, như chuyện MySQL dọn nhà qua sân sau Sun, rồi chuyện Trolltech chuyển giấy phép Qt sang GPLv3... Làng bùm bùm chách cũng có một sự kiện hấp dẫn không kém.

Điểm lại những ban nhạc nổi bật trong thời gian qua. Năm 2004 là thời kỳ của gothic/symphonic metal với Nightwish, Within Temptation và ban nhạc của lâu đài và những câu chuyện cổ tích Blackmore's Night (chấm dứt giai đoạn hard rock, tiền 2004). 2005 đến lượt Dream Theater, Queensryche, Metallica cùng với Apocalyptica lên ngôi, sự quay lại của heavy metal và progressive metal. 2006 xuất hiện một loạt các tên tuổi, trong đó hai ban nhạc tiêu biểu cho giai đoạn này là Draconian và Lacrimosa. Ảnh hưởng của hai ban nhạc này kéo dài đến nửa đầu 2007. Nửa sau 2007 xuất hiện đám cưới của súng và đạn (Diablo Swing Orchestra), cùng sự trở lại của Tristania và Alanis Morisette. Có thể nói dòng nhạc gothic metal vẫn chiếm vai trò chủ đạo, gần đây có thêm hơi hướng doom metal và darkwave.

Quay lại 2008, sự kiện chấn động đầu năm 2008 là phát hiện Persephone, thêm một kiều nữ trong những dòng nhạc ít ai nghe. Cũng Darkwave như Lacrimosa, nhưng Persephone không sặc mùi kim loại, không gào thét, không vật vã. Không mạnh mẽ như Nightwish. Không hận đời như Tristania hay Angtoria. Không u sầu, bế tắc kiểu Draconian. Một Persephone nhẹ nhàng, lắng đọng. Một Persephone như gió thoảng mây bay. Một hương vị lạ sau nhiều tháng nhiều năm sắt thép hoá hai cái lỗ tai.

Dự đoán âm nhạc 2008. Không khó đoán lắm gothic metal vẫn tiếp tục duy trì sự thống trị của mình. Hai dòng nhạc khác nhiều khả năng sẽ làm mưa làm gió trong năm nay: Doom Metal và Darkwave. Các ban nhạc neoclassical cũng có thể lên tiếng chút đỉnh, nhưng không nổi trội.

Quy trình phần mềm cá nhân PSP(Personal Software Process) chia ra nhiều cấp độ, trong đó cấp thấp nhất là PSP0.0 và PSP0.1: quản lý thời gian.

Bỏ qua các công cụ "tiên tiến" đang có trên mạng. Viết một cái mới nhằm đáp ứng một số đặc điểm hết sức đặc biệt của cái thằng đang gõ những dòng này:

• Nhanh, không muốn tốn thời gian chọn chọn, nhấn nhấn...
• Hoạt động hiệu quả ở chế độ terminal
• Dạng thức lưu trữ đơn giản, dễ xử lí
• Tích hợp hệ thống ở những chỗ hợp lí

Timestamp ra đời nhằm đáp ứng nhu cầu hết sức bức xúc này. Timestamp là một ứng dụng, tuy không nhỏ lắm, nhưng khá đơn giản do viết chủ yếu bằng bash và perl. Với timestamp, ta có thể ghi chú lại một số thời điểm đặc biệt trong ngày, như lúc bắt đầu làm một chuyện nào đó và khi kết thúc. Vậy với timestamp, ta có được một "bản báo cáo thô" các hoạt động trong ngày.

Với các bản báo cáo thô này, vào cuối tuần, ta có thể xử lý tự động (hiện giờ vẫn theo phong cái CLI(Command Line Interface) tuy nhiên tương lai hổng chừng có GUI), tách ra thành các khoảng thời gian tương ứng với từng công việc, gán nhãn cho các công việc... và đếm coi mất bao nhiêu thời gian làm mỗi việc.

Qua thống kê, tính từ ngày 1/4 đến nay bạn B tiêu hết

• 1.43 giờ để bờ lốc
• 9.91 giờ để code cóc cóc mà không kiếm ra xu nào
• 2.21 giờ để vọc lăng nhăng, như thử tái tạo lỗi, vọc Solaris...
• 4.16 giờ để đọc tài liệu

Dĩ nhiên một lượng lớn thời gian không theo theo dõi là đọc thư và tin tức. Khoảng này chiếm hơi bộn. Tổng cộng, hai tuần nay bạn B sử dụng khoảng 18.21 giờ một cách không-vô-bổ-lắm. Tương đương mỗi tuần 9 tiếng hay mỗi ngày 1.3 giờ. Nếu cứ mần theo đà này thì cái WL2k8 nên cắt bớt còn 1/4.

Cách làm này có điểm khác chút đỉnh so với cách làm truyền thống ở chỗ nó theo kiểu làm từ dưới lên chứ không phải từ trên xuống. Theo đúng "quy trình", trước hết phải có danh sách công việc, sau đó mới làm. Còn theo quy trình ngược này thì kệ bà cái danh sách khỉ gió đó, thích làm gì cứ làm, miễn sao nhớ ghi lại. Ghi lại xong cuối tuần tổng kết thống kê sau.

Một điểm khác nữa là PSP tính quá kỹ, đến từng phút. Timestamp không được thiết kế để tính kỹ cỡ đó. Nói chung sai số trong khoảng mười phút trở lại là chấp nhận được. Để hạn chế quá lệch giờ (do quên nhập chẳng hạn), timestamp có khả năng chặng screensaver và lưu lại thời điểm screensaver được kích hoạt cũng như được tắt, khoảng giữa dĩ nhiên là không ai xài.

Tuy nhiên cũng có một cái dở là timestamp không thể hoạt động nếu thiếu cái máy tính. Các hoạt động "ngoài trời" coi như khỏi theo dõi. Tuy nhiên do "hoàn cảnh" nên thời lượng ngắm nắng cũng không nhiều, khỏi lo.

TB. Thông số timestamp trong giờ hành chính cho thấy bạn B hình như chơi nhiều hơn làm :P Thôi kệ. Trời biết, đất biết, mình biết. Miễn sao sếp không biết là ngon.

(lẽ ra phải là "Phim phim phim" nhưng đọc sai riết quen)

Điểm giống nhau giữa các phim:

1. “You’re my knight in shining armor”
2. Bài “Let go” chơi ở khúc cuối Garden State được chơi lúc Graham vào quán gặp Amanda trong The holiday
3. Natalie Portman (Garden State) và Andie MacDowell (Groundhog Day) có… cái mặt giống nhau. Bài thứ hai Phil Connors chơi trong buổi tiệc có khúc đầu giống “One Of These Things First” trong Garden State.
4. Cách uốn giọng “maybe” của Andie và “I might” của Gwyneth Paltrow… giống nhau
5. Cũng là Jude Law

Tin tức đầu năm dồn dập đổ về từ "tiền phương" Rubinius. Evan Phoenix đã làm cho irb chạy được và đang đặt đích nhắm Rake. Nếu Rake chạy thì sẽ có thể tính tới chuyện thử Cùi Bắp trên Rubinius. Rake dính thêm một phụ thuộc khác là Rubygems mà Eric Hodel đang sắp làm cho chạy. Đây là một bước tiến quan trọng trong việc tiến tới "self hosting cấp 2", có thể biên dịch, kiểm tra rubinius... mà không cần có MRI(Matz Ruby Implementation).

Hôm trước cũng táy máy vọc thử rake với rubinius. Kết quả hơi sốc. "rake --tasks" chạy tức thời trên MRI trong khi với Rubinus, nó mất đâu cỡ mười phút! Chắc có cái gì đó sai, nhưng không có thời gian lẫn trình độ để tìm hiểu thêm. Commit aebc5b4f của Eric làm cho shotgun cứng đơ, nên chưa thử code mới nhất được.

Năm ngoái JRuby lên hương. Không chừng năm nay tới lượt Rubinius.

Do không có thời gian nên không dại gì tự điểm lại các sự kiện nổi bật trong năm vừa qua. Sau hai tuần, tổng kết 2007 của LWN đã được công khai trên mạng. Sau đây là những sự kiện (theo chủ quan) đáng chú ý:

• The Nouveau driver pledge chứng tỏ nhu cầu cần có một trình điều khiển bo mạch đồ hoạ NVIDIA hoàn toàn mở.
• Linux Driver Project tăng tốc tầm ảnh hưởng của Linux
• The Beryl and Compiz projects agree to merge
• Emacs 22.1 is released kết thúc năm năm chờ đợi (hay lâu hơn?)
• Btrfs is revealed hứa hẹn một tương lai tươi sáng cho các hệ tập tin trên Linux
• GPLv3 is released kết thúc một giai đoạn đầy tranh cãi thời “tiền GPLv3”, mở ra thời kỳ “hậu GPLv3” với khá nhiều dự án lớn chuyển quan sử dụng giấy phép mới này
• The purchase of the CUPS project by Apple is announced với việc Apple trở thành người giữ bản quyền của CUPS
• Novell is ruled to be the owner of Unix chấm dứt mối đe doạ SCO
• The GNOME project celebrates its tenth anniversary
• Microsoft’s bid for fast-track of its proposed OOXML standard fails
• AMD announces a plan to open up documentation for ATI graphics chipsets mở đường cho Linux 3D
• The SCO Group files for chapter 11 bankruptcy nối tiếp sự kiện SCO thất bại trong việc tranh giành ngôi chủ nhân UNIX
• The OSI approves two Microsoft licenses
• The OpenSolaris developer preview is released, thành quả đầu tiên của dự án Indiana
• The OLPC XO laptop goes into mass production
• Perl 5.10 is released kèm theo ăn mừng Perl tròn hai mươi tuổi

Năm 2007, nhìn từ bảng tổng kết của LWN, là một năm đầy sóng gió với đủ các vụ kiện tụng, đồng thời cũng lắm bất ngờ, từ những bất ngờ từ giới sản xuất như AMD đến những thành tựu về phần mềm. Tuy nhiên có vẻ LWN cũng bỏ sót một số thứ, như Moonlight, Android hay IcedTea (và dĩ nhiên Ruby 1.9).

Lập trình (đúng hơn là sửa lỗi) nhiều khi cần biết cái hàm đó ai gọi nó, gọi khi nào, nó nhận được những tham số gì... Nếu số lời gọi hàm ít ít thì may ra còn dùng gdb, đặt breakpoint. Còn nhiều thì cách tốt nhất vẫn là theo dõi lời gọi hàm bằng cách lưu thông tin ra đâu đó khi chương trình chạy. Sau khi chạy xong thì mở ra xem và ngẫm.

Kỹ thuật này hay được gọi là "instrumentation", đại khái là quan sát một chương trình đang chạy (chương trình có thể được điều chỉnh đôi chút để hỗ trợ quá trình quan sát) và ghi nhận các thông số khi chạy. Ở lĩnh vực này thì hiện nay DTrace nổi tiếng nhất. Kẹt nỗi chưa cài Solaris nên chẳng thể dùng. Linux có SystemTap, nhưng chưa thể dùng cho các ứng dụng bình dân (chỉ dùng cho kernel).

Một kỹ thuật bình dân để theo dấu lời gọi một hàm nào đó là dùng macro trong C. Đại loại như sau:

#define myfunc(a,b,c) instrumented_myfunc(a,b,c,__FILE__,__PRETTY_FUNCTION__,__LINE__)
int instrumented_myfunc(int a, int b, int c, const char *file, const char *func, int line)
{
  fprintf(stderr,"%s:%s:%d\n", file, func, line);
  return myfunc(a,b,c);
}
...

#undef myfunc
int myfunc(int a, int b, int c)
{
...
}
#define myfunc(a,b,c) instrumented_myfunc(a,b,c,__FILE__,__PRETTY_FUNCTION__,__LINE__)

Nói ngắn gọn là dùng macro để lấy thêm thông tin về vị trí gọi hàm và in thông tin đó ra. Kỹ thuật này tuy đơn giản nhưng mỏi tay, đặc biệt khi phải theo dõi nhiều hàm.

Một kỹ thuật khác là sử dụng hỗ trợ từ trình biên dịch, ở đây là gcc. GCC có tuỳ chọn -finstrument-functions, cho phép ta cài vào một đoạn mã của riêng ta ở đầu và cuối mọi hàm. Thông số truyền vào là địa chỉ hàm được gọi (callee) và địa chỉ hàm gọi hàm "đang quan tâm" (caller). Với một số xử lý, ta có thể chuyển địa chỉ này thành tên hàm, ví dụ như dùng addr2line. Điểm dở của addr2line là không hỗ trợ thư viện động. Điểm dở của -finstrument-functions là khó giới hạn phạm vi hàm cần theo dõi.

etrace minh hoạ cách tiếp cận này. Một điều không đề cập ở trang etrace là ptrace.c có thể được biên dịch thành thư viện động và được nạp thông qua LD_PRELOAD, do vậy chỉ cần biên dịch chương trình với -finstrument-functions là đủ, không cần phải biên dịch cả ptrace.c gộp vào chương trình.

Một giải pháp khác, hơi cổ lỗ sĩ là dùng strace với ltrace. strace cho phép theo dõi các lệnh gọi kernel (syscall). Còn ltrace cho phép theo dõi các lệnh gọi đến các thư viện động. ltrace có cái dở là những lệnh gọi nội bộ trong thư viện thì nó không theo dõi được.

Một giải pháp khác nữa là tận dụng gdb, với một cái script tên là callgraph. Dùng gdb có cái ẹ là nếu chương trình đang trong giai đoạn phát triển và dùng các thư viện động riêng, cần phải thiết lập LD_LIBRARY_PATH cho đúng (mỏi tay).

Thêm hai giải pháp “nặng cân” khác là frysk và chronomancer. Do quá nặng nên miễn bàn ở đây.

Nói tóm lại có một số hướng có thể dùng:

• Tận dụng gdb hoặc một debugger khác (callgraph)
• Chuyển đổi code (như dùng C macro hoặc -finstrument-functions, nhưng phải làm sao tiện hơn)
• Tận dụng hỗ trợ từ kernel như uprobes trên Linux (frysk), ptrace (strace và lstrace) hay DTrace trên Solaris
• Tận dụng valgrind (chronomancer)

Tiếp nối truyền thống WL2k7, WL2k8 là một phiên bản có điều chỉnh chút đỉnh cho phù hợp với hoàn cảnh mới:

• Bảo đảm chất lượng dịch GNOME-VI
• Phần "khoa học máy tính" trong 2008 sẽ là Vala, Parrot, LLVM và Ruby (Rubinius).
• Phục hồi Kanji
• Bảo đảm DejaVu hiện tiếng Việt tốt và đẹp, đủ khả năng thay thế corefonts của Microsoft
• Hỗ trợ gõ tiếng Việt trên X/GTK+ (gtk-xvnkb, vnkb-applet, kêu gọi bọn chúng hỗ trợ GTK+ Input Method tốt hơn)
• Ruby On Rails, phần JS. Hoàn tất punbbonrails
• Tiếp tục quậy Flash/swfdec khi có điều kiện
• VSpell 1.0!!!
• Không làm ngoài giờ (mà không có lương). Cân bằng giữa việc có lương và việc không có lương.
• Áp dụng PSP(Personal Software Process)
• Có thể dùng Planner trong công việc (thay Microsoft Project)
• G-Gem, Git-box, lscreen
• Hỗ trợ GTK+ cho VirtualBox
• Không xài điện thoại di động
• Không ghi thêm gì nữa vào wishlist
• Có thể làm được mọi thứ trong wishlist!

Bạn hoàn toàn chưa biết gì về FOSS(Free Open Source Software) và muốn tìm hiểu về nó? Hãy bắt đầu với Open Sources: Voices from the Open Source Revolution.

Cuốn sách là một tổng hợp bài viết của những nhân vật có máu mặt trong giới FOSS, giúp bạn khám phá các khía cạnh khác nhau về FOSS. Sách đề cập sơ lược về sự ra đời của FOSS, sự khác nhau giữa Free Software và Open Source Software. Một trong những tác giả của phần mở đầu này là quản lý về OSS của Google. Phần kế tiếp của ESR(Eric S. Raymond) đề cập đến khía cạnh con người: hacker, lịch sử phát triển của hacker. Đọc để biết hacker trong thế giới FOSS ra sao, nó khác thế nào với "tin tặc". Trình bày về Free Software và dự án GNU do cha đẻ của dự án này thực hiện. Để đối chiếu với khái niệm Free Software, ba phần trình bày về Open Source Software sẽ nói rõ hơn về OSS, về khía cạnh kinh doanh của OSS và một ví dụ cụ thể.

Những ai quan tâm cụ thể về Linux có thể đọc phần Linus viết về Linux. Phần này đụng chạm đến một trong những cuộc khẩu chiến kinh điển của giới máy tính, trong lĩnh vực hệ điều hành: micro-kernel và monolithic kernel. Có kiến thức cơ bản về kỹ nghệ phần mềm? Nên đọc so sánh các khái niệm của kỹ nghệ phần mềm truyền thống so với cách OSS.

Larry Wall có một bài rất hay về tính cách của lập trình viên Perl, nhưng có lẽ nó cũng đúng cho những người phát triển OSS nói chung (hoặc thậm chí rộng ra giới phát triển phần mềm nói chung). Tuy nhiên công nghệ phần mềm là một thứ gì đó không đi chung đường với nghệ thuật hay nói nhẹ hơn là sáng tạo. Nó ràng buộc, o ép. Nó làm cho giới phát triển phần mềm trong ngành công nghệ phần mềm bị nhìn như có vẻ hơi ngu ngu (thực hư chưa chắc).

Larry đưa ra ba đặc tính của dân lập trình: lười, nóng và ngạo mạn. Đồng thời lại đề cập ba đặc tính ngược lại, theo kiểu "mâu thuẫn là tất yếu". Một bài viết hay và vui.

Là người đã từng bị hỏi nhiều lần "OSS là gì?", đã từng cố gắng giải thích, cố gắng tổng hợp bao nhiêu năm kinh nghiệm để đưa ra một cái nhìn tổng quát, có thể nói bây giờ không cần phải cố gắng như thế nữa. OSS là gì? Cứ đọc "Open Sources: Voices from the Open Source Revolution" trước đã, sau đó chúng ta sẽ có chuyện để nói.

Vala được thiết kế theo kiểu "đứng trên vai người khổng lồ" glib. Vala có một điểm yếu là phát triển không được chặt chẽ lắm. Phần kiểm tra ngữ nghĩa của Vala cũng yếu. Điều này là hậu quả tất yếu của việc đẩy việc về cho C, bởi ngữ nghĩa của C so với mã máy, rõ ràng phức tạp hơn rất nhiều. Có một cái dự án nhảm nhí trên Google (vala-benchmarks) nhằm so sánh tính hiệu quả của Vala với C và Mono. Bởi vì Vala nói cho cùng cũng chỉ là vỏ ngoài hình thức để phát sinh mã C, phần "overhead" (không biết dịch) của Vala không nhiều (và dễ dàng bị loại bỏ nhờ trình biên dịch C). Ở đây không nói overhead do glib (đặc biệt là gobject) gây ra bởi các ứng dụng viết bằng C cũng vẫn gặp phải. GObject overhead cũng gây không ít tai tiếng. Nó là một trong những lý do GTK+ 2.0 chạy chậm hơn hẳn và tốn nhiều bộ nhớ hơn so với GTK+ 1.2. Mặc dù đầu ra C của Vala không được đẹp lắm, nhưng lập trình viên vẫn có thể đọc được. "Thư viện chuẩn" của Vala chính là hạ tầng GNOME: Glib, GTK+... nên người mới gặp rất ít khó khăn. Nhận định tương lai: Vala sẽ tiến xa nếu trình biên dịch Vala tốt hơn trong việc chẩn đoán lỗi. Nói cho cùng, mục tiêu của Vala là để lập trình viên C đỡ phải gõ nhiều, dễ sai.

Kế đến là "ngôn ngữ huyền thoại" Perl6. Perl6 đi theo con đường truyền thống: viết Parrot VM bằng C, dựa vào PIR (Parrot Assembly) để tạo trình biên dịch perl6 mini NQP, sau đó dùng NQP để viết Perl bằng Perl. Hồi trước tệ hơn nhiều, viết trình biên dịch Perl trực tiếp bằng PIR. Điểm yếu truyền thống của cách truyền thống: đòi hỏi một người am hiểu về PIR để viết, và đòi hỏi vững C để sửa Parrot. Perl6/Parrot hơn Vala một điểm là đã có đặc tả ngôn ngữ rõ ràng. Trong khi Vala có vẻ theo chân Ruby, cần đến đâu thay đổi ngôn ngữ đến đó. Nhận định: hi vọng cuối 2008 sẽ có perl6 alpha. Một thứ hi vọng mờ mịt đối với một ngôn ngữ chắc cũng gần chục năm thai nghén.

Ngôn ngữ cuối cùng cũng có họ hàng với Perl: Ruby, hay nói đúng hơn là bản cài đặt Rubinius. Rubinius hiện thời là một mớ Ruby và C. Phần VM của Rubinius có thể gọi là "da Ruby, xương thịt C". Trình biên dịch Ruby (trừ phần parser) được viết bằng Ruby và phát sinh Rubinius bytecode. Thư viện Lightning được dùng, nhưng không phải để phát sinh mã động kiểu JIT, mà để hỗ trợ cài đặt FFI(Foreign Function Interface). Như vậy đến khi hoàn chỉnh, tốt độ của Rubinius có thể tương đương với Ruby 1.9 (cũng có bytecode VM là YARV). Nói đúng ra việc tự cài đặt lại hầu hết các hàm cốt lõi của Ruby bằng chính Ruby thì cũng khó để đánh bại bản viết bằng C (Ruby 1.8.6). Để làm được việc này, cần đẩy mạnh tối ưu hoá ở trình biên dịch và công đoạn tối ưu hoá này tốt hơn giao cho LLVM thay vì đội Rubinius phải tự gánh. Một điểm hay khác là do thư viện chuẩn viết bằng Ruby (trừ những phần không thể như giao tiếp với tập tin), các máy ảo Ruby khác như YARV, JRuby, IronRuby... tận dụng để xử lý, tránh phải viết lại thư viện cho mỗi phiên bản, tăng tính tương thích giữa các phiên bản. Rubinius chắc chắn sẽ ra mắt vào 2008. Vấn đề là liệu Rubinius có kịp đạt mức tương thích 100% với Ruby 1.8.6 và đuổi theo Ruby 1.9 trong tương lai hay không? Nhận định: có lẽ.. có thể vào cuối 2008 hoặc đầu 2009.

Lựa chọn:

• Lập trình "nặng" thì Vala
• Lập trình nhanh thì Ruby
• Lập trình "vừa vừa" đẩy qua Perl
• Có tiền thì thuê người làm, khỏi chọn lựa mắc công