Lý sự pclouds

Em... hổng biết. Nhưng em có một gợi ý nho nhỏ cho bác dotnetgen là ngay cả Microsoft, sau biết bao năm trời, vẫn không xác định được "đại diện cộng đồng nguồn mở" (để kiện, đoán thế), vậy bác nghĩ bác đủ khả năng tìm câu trả lời?

Nếu bác không tìm được thì em trả lời dùm cho (kệ, coi như để phước con cháu): em nè. Bác muốn gì thì tìm em, em... ấy bác luôn :D

Ban đầu định làm "nhẹ nhàng từ tốn", chuyển xvnkb thành gvnkb theo từng bước nhỏ:

1. Gỡ bỏ cơ chế LD_PRELOAD khỏi xvnkb, chuyển sang GtkIM
2. Cho phép tạo nhiều GtkIMContext (xvnkb được thiết kế để hoạt động một mình một cõi, không phù hợp với mô hình IM của Gtk+)
3. Gỡ bỏ các bảng mã thừa (nếu rảnh)
4. Hỗ trợ preedit
5. Hỗ trợ các đầu vào khác thay vì chỉ GtkIM (như thông qua SCIM hay dùng XEvIE extension)

Kế hoạch... tan nát vì xvnkb mang đậm "dấu ấn thời gian", nhìn lé con mắt bên phải, lòi con mắt bên trái. Cả hai mắt đều "say goodbye" một đi không dám trở lại. Thôi quyết định quay về mớ code cũ gtk-xvnkb (cũng hơn một năm rồi).

Lắm chuyện. Vậy tại sao cần tách nhánh xvnkb trong khi xvnkb chạy tốt?

• xvnkb chạy không tốt lắm với phần còn lại của hệ thống, ví dụ như xscreensaver hay gnome-screensaver không có cách nào tắt xvnkb hoặc xác định xvnkb có chạy không để báo người dùng
• LD_PRELOAD không chạy với các chương trình suid
• xvnkb không thân thiện lắm với laptop
• Thích sửa bánh xe (nói tốt lành là "một nỗ lực để đưa xvnkb đến gần hơn các hệ thống IM hiện đại như IIIMF hay SCIM")
• Âm mưu đen tối: âm thầm đưa gtk-xvnkb vào Ubuntu, Fedora và OpenSuSE! j/k lolz

Vậy kế hoạch mới là tiếp tục hoàn thiện gtk-xvnkb. gtk-xvnkb là một mớ lùng nhùng móc từ đống code xvnkb ra, một thử nghiệm "tiền khả thi" trước khi tiến hành gvnkb. Nhưng xem ra hàng mẫu vẫn tốt chán. Mà gtk-xvnkb cũng khá mi nhon do đã gỡ hết mớ tàn dư lịch sử của xvnkb (gtk-xvnkb chỉ hỗ trợ Unicode, hết). Vậy ngu gì không mần tiếp gtk-xvnkb. gtk-xvnkb chỉ hỗ trợ preedit, khá bất tiện với những người dùng vim hay đã quen với cách xoá lùi của xvnkb và x-unikey. Sắp tới có lẽ nên thêm lại tính năng xoá lùi. Ngoài ra gtk-xvnkb cũng không thể tắt/bật với phím nóng như xvnkb. Hmm... cũng một mớ việc.

Không chừng sẽ móc vnkb-applet vào làm bộ mặt cho gtk-xvnkb. Một công đôi chuyện: khỏi phải làm mặt mới, lại cứu được vnkb-applet (đã tắt thở từ lâu).

TB. Vẫn còn cục TeXlive, quậy từ bản 2006, đến giờ sắp hết 2007 mà vẫn chưa ra "TeXtoo". Phải cầm lòng không hó hé gì mỗi khi có comment mới trên bug 168177. Oé…

Chừng nào thì người dùng có thể cài đặt bộ gõ tiếng Việt như thế này?

sudo apt-get install xvnkb

Chán. Mò trên mạng toàn là tài liệu chỉ dẫn biên dịch (hoặc xvnkb hoặc x-unikey) trong khi người lơ tơ mơ thì làm sao biết mà biên dịch? Chưa kể thiếu đủ thứ gói lăng nhăng, từ make, gcc đến libc6-dev, xorg-server-dev... Mà chẳng lẽ cài một mớ gói vô chỉ để biên dịch xvnkb ??

Chừng nào mới có một người chịu khó đóng gói xvnkb hoặc x-unikey và đưa vào Ubuntu? Hoặc ít ra không đóng gói thì cũng réo bọn Ubuntu dev làm dùm chứ?

Kể cũng lạ. Mấy món khó xài như Gentoo hay FreeBSD thì hỗ trợ xvnkb ngon, trong khi không thật sự quan trọng vì mấy thằng xài mấy cái đó thằng nào cũng đủ khả năng tự cài hết. Còn mấy thằng "thân thiện người dùng" thì bắt bà con cài tay.

Zeroconf còn được biết đến với nhiều tên khác nhau như bonjour, link-local service discovery, multicast dns... Tóm ngắn gọn là dùng một hệ thống hỗ trợ zeroconf hết sức là sung sướng.

Hệ thống đó bao gồm avahi và các ứng dụng hỗ trợ avahi (nautilus/gnome-vfs, pidgin, nss-mdns, epiphany, rhythmbox, ekiga...). Được gì? Mở nautilus ra, gõ vào địa chỉ network: ta có được danh sách các máy có thể kết nối (thông qua webdav, ftp hoặc sftp). Giống như Windows share. Mở epiphany ra, ta có ngay danh sách các trang web hỗ trợ zeroconf trong bookmark (cần cái nào thì export service trên máy đó). Có thể dùng avahi-discover để xác định danh sách máy. Cần mần gì đó với một máy nào đó? Dùng tên <tên máy>.local (nhờ nss-mdns). Thích chít chát? Tạo tài khoản Bonjour (iChat) với Pidgin rồi tha hồ chát chít mà không cần quan tâm trên đời này có cái IM server nào. (Windows cần cài đặt thêm "Bonjour for Windows" của Apple). Vino (VNC) cũng tự quảng cáo qua zeroconf nên có thể kết nối từ xa mà không cần phải hỏi địa chỉ máy. Muốn chia sẻ nhạc? Mở rhythmbox lên và bật DAAP. Muốn nói chuyện với hàng xóm? Dùng ekiga. Còn thiếu mỗi video streaming nữa là đủ (có thể quảng bá qua dạng bookmark như đã đề cập với epiphany)

Tóm lại bất cứ hệ thống Linux nào khi xuất xưởng đều nên hỗ trợ zeroconf từ đầu. Như vậy sẽ rất tiện lợi cho người dùng. Có thể quy mô vài trăm máy với cấu trúc mạng phức tạp thì Zeroconf vô nghĩa. Nhưng với quy mô nhỏ vài máy, nối nhau bằng hub hoặc switch thì zeroconf là trên cả tuyệt vời.

Hôm nay chơi thử hai game được giới thiệu trên linuxhelp.blogspot.com là FizzBall và Runes of Avalon. Phải nói là không tệ (trừ khoản chỉ được chơi demo).

Cả hai game đều là dựa trên các game cũ. Runes of Avalon, do là một cuộc phiêu lưu, nên tập hợp nhiều game nhỏ trên đường đi giúp con nhỏ gì đó chống một con nhỏ hắc ám khác. Game dựa trên tetris, xếp tranh, tìm chữ (nhanh mắt). Chơi cũng được. Dữ liệu ảnh và âm thanh đều ở dạng có thể dùng lại được (png và ogg). Cấu trúc trò chơi có lẽ cũng không mất công mất sức nhiều để lấy. Xém chút xíu là nổi máu cracker lên rồi, vì đang chơi thì nó không cho chơi nữa. Nó bảo hết giờ và phải mua mới cho chơi tiếp. Cũng may kịp thời suy xét (một, hết crack lâu rồi; hai, quên cách crack rồi; ba, có crack trong Linux bao giờ đâu).

FizzBall "nhí nhảnh" hơn nhiều. FizzBall về cơ bản là ping-pong hồi xưa, nhưng được làm lại trong bối cảnh khác: nông trại. Game hết sức phù hợp cho những người muốn giảm stress nhẹ nhàng: phá thùng, bắt súc vật, rung cây... Game này có lẽ sẽ đắt hàng hơn nếu làm lại trong một bối cảnh khác phù hợp hơn với dân IT bị stress: công ty. Ví dụ quăng chuột phá máy, đập bàn, chọi sếp... FizzBall giấu dữ liệu, tuy nhiên cũng không khó nhận ra PNG nằm trong các tập tin .dat.

Tóm lại là chơi được. Dĩ nhiên nếu game tương tự nhưng GPL hay gì đó đại loại thế thì tốt hơn.

Bài này được đưa vào phần Mánh và mẹo vì nó có một chút mẹo và mánh. Nhưng thật ra phần mẹo nhỏ xíu vì chủ yếu nói về cách hoạt động của ClearCase.

ClearCase là một hệ thống quản lý mã nguồn, cùng nhóm với CVS, Subversion, Git, SourceSafe... ClearCase chắc giống SourceSafe nhất vì quản lý theo từng tập tin và dùng cơ chế checkout/lock.

Khác với đa số các hệ quản lý mã nguồn, phần working directory của ClearCase có thể liên kết với nhiều "kho", gọi là "vob", thay vì một. Cái "working directory" trong Clearcase gọi là "view". Có hai loại view là dynamic view và snapshot view. Snapshot view giống như CVS, các tập tin được lấy về máy ở một phiên bản nhất định và sẽ không thay đổi tới khi được "update".

Dynamic view, ngược lại, là một ổ đĩa mạng. Nếu đứt mạng thì có lẽ dynamic view sẽ hết hoạt động. Các tập tin trong dynamic view có thể thay đổi vào bất kỳ lúc nào, tuỳ thuộc vào những quy tắc xác định phiên bản tập tin trong "config spec". Nói tóm gọn, dynamic view được update tự động, liên tục trong khi snapshot view phải update bằng tay.

Lệnh để thao tác với clearcase là "cleartool" hay "ct". Còn có một số lệnh khác nữa nhưng quan tâm nhiều chỉ thêm nhức đầu. Để được trợ giúp về một lệnh nào đó, dùng ct man <lệnh>. Trên Windows, đa số có thêm phần GUI. Để dùng GUI thì thêm tham số "-gra" (graphical) vào. Để liệt kê danh sách vob, dùng "ct lsvob". Để tạo view mới, dùng GUI cho gọn. Khi tạo view, ta cần tạo config spec cho view đó để xác định các quy tắc chọn phiên bản cho từng tập tin trong view.

Config spec là một trong những điểm đặc trưng của ClearCase, khác hẳn với các hệ khác. Config spec cơ bản như sau:

element * CHECKEDOUT
element * /main/LATEST

Diễn dịch config spec ở trên là: "Đối với bất kỳ tập tin nào (dấu *), nếu đã được checkout (ký hiệu CHECKEDOUT) thì dùng tập tin đã checkout (phiên bản đã thay đổi trên máy tính). Nếu không thì, đối với tập tin bất kỳ, lấy tập tin đó ở phiên bản mới nhất (ký hiệu LATEST) trong nhánh /main". Có nhiều config spec phức tạp hơn nhưng sẽ nói sau. Các lệnh để thao tác config spec bao gồm "ct catcs", "ct setcs", "ct edcs".

Như đã nói, ClearCase quản lý theo tập tin. Giống như SourceSafe, ClearCase dùng cơ chế checkout/lock. Để được quyền sửa tập tin bất kỳ, tập tin đó phải được checkout. Có hai loại checkout là reserved checkout (lệnh ct co) và unreserved checkout (lệnh ct co -unre). Các lệnh này là lệnh viết tắt, viết đầy đủ thì dài hơn, nhưng cũng không cần thiết. Không thể có hai người cùng reserved checkout cùng một tập tin (với unreserved checkout thì không thành vấn đề). Và hình như chỉ có reserved checkout mới được quyền checkin (lưu vào kho) bằng lệnh ct ci (xác định checkin message bằng tham số -c hoặc nó sẽ hỏi checkin message). Nội dung tập tin checkout được ký hiệu là "CHECKEDOUT" trong config spec như trong config spec ví dụ ở trên. Để bỏ checkout, dùng ct unco. Các lệnh đề cập trong đoạn này đều cần tham số là tập tin/thư mục cần thao tác.

Để tìm các tập tin được checkout, dùng ct lsco. Xem ct man lsco để biết thêm chi tiết. Để liệt kê tất cả các tập tin mình checkout trong view hiện thời, dùng

ct lsco -avo -cview -me

ClearCase không chỉ quản lý phiên bản tập tin mà cả thư mục. Để thêm/xoá tập tin, cần phải checkout thư mục chứa tập tin đó. Sau đó dùng ct mkelem để tạo một tập tin mới hoặc ct rmelem để xoá tập tin. Lưu ý là ct rmelem sẽ xoá tập tin đó thật sự trong kho (tất cả các phiên bản của tập tin đó), chứ không đơn giản là "xoá tập tin khỏi thư mục trong phiên bản hiện thời". Để làm điều này, dùng ct rmname. Khi đưa tập tin mới vào kho với ct mkelem, nó sẽ tạo ra một tập tin rỗng. Tuy nhiên do đã có một tập tin của người dùng rồi, ClearCase sẽ không ghi đè tập tin đó bằng tập tin rỗng của nó. Tập tin rỗng của clearcase được gọi là "eclipsed" - nó bị che bởi tập tin của người dùng. Để thấy điều này, dùng ct ls (giống như "ls" nhưng hiện thêm các thông tin riêng của Clearcase). Cách giải quyết là di chuyển/đổi tên tập tin của người dùng. Ngay sau đó một tập tin rỗng cùng tên sẽ xuất hiện - tập tin được quản lý bởi ClearCase. Checkout tập tin đó ra rồi chép đè nội dung tập tin của người dùng vào, sau đó checkin nếu muốn. Sau khi thêm/xoá/đổi tên tập tin... cần checkin thư mục chứa tập tin đó.

Một trường hợp đặc biệt là sau khi đã có tập tin A, ta xoá A đi ở một thời điểm nào đó. Sau đó ta muốn thêm A trở lại. Clearcase sẽ không cho phép dùng ct mkelem A hai lần. Thay vào đó ta phải móc cái xác cũ của A lên, checkout nó ra và thay đổi nội dung. Việc "móc xác A" được thực hiện bằng ct ln. Giống như "ln" trong Linux tạo liên kết giữa hai tập tin, ct ln tạo liên kết giữa hai phiên bản của tập tin. Cần phải xác định phiên bản cuối cùng chứa A của thư mục đã từng chứa A, sau đó móc nó lên

ct ln .``/main/1/A A

"." là thư mục hiện tại (tại vì giả định đang đứng trong thư mục chứa A). Quên nói, để xác định một tập tin/thư mục ở một phiên bản nào đó, dùng /path/to/file``/branch/to/file/revision. Riêng đối với thư mục, có thể nối thêm phần tên tập tin mà thư mục đó chứa nếu muốn xác định tập tin trong thư mục đó.

Để theo dõi sự phát triển của một tập tin, ClearCase có ct annotate để cho biết dòng nào thuộc về phiên bản nào, ct lsh để liệt kê tất cả các phiên bản, ct lsvtree để xem mối liên hệ giữa các phiên bản (nên xem bằng GUI), và dĩ nhiên cũng cho phép so sánh giữa các phiên bản khác nhau (dùng GUI).

Để quản lý nhánh, ClearCase có hai khái niệm là "branch type" và "branch". Branch type là một trong số các "type" khác nhau (ct lstype). Để tạo được branch A thì vob đó phải có branch type A trước. Tạo branch type bằng lệnh ct mkbrtype. Branch của Clearcase không phải nhánh phẳng mà là nhánh phân cấp. Ví dụ ta đang ở nhánh /main, ta có thể tạo nhánh /main/A...

Việc tạo branch được xác định thông qua config spec, sẽ nói sau trong phần bàn về config spec. Để tìm các tập tin thuộc về một branch type A, dùng

ct find -avo -branch A

Đến phần merge. Lệnh chính là ct findmerge. Cần phải xác định phạm vi thư mục cần merge, phiên bản cần merge, thao tác thực hiện sau khi đã tìm ra các tập tin cần merge... Nói chung phức tạp. Để merge từ nhánh A sang nhánh khác (mọi tập tin) thì dùng

ct findmerge -all -fver .../A/LATEST -print # kiểm tra danh sách
ct findmerge -all -fver .../A/LATEST -c 'message' -co # checkout
ct findmerge -all -fver .../A/LATEST -merge # merge

Phần trên coi như đủ để một người dùng Clearcase có thể sử dụng Clearcase trong các công việc bình thường, trừ việc tạo view vì cần phải viết Config spec. Config spec có lẽ là một trong những phần quan trọng nhất. Config spec xác định phiên bản của các tập tin trong view và cách tạo nhánh mới. Ngoài việc có thể xác định chính xác phiên bản cần lấy về như config spec ví dụ. Có thể xác định chính xác một phiên bản cho một tập tin, ví dụ:

element /path/to/blah /main/2

Lệnh trên nói rằng với tập tin/thư mục /path/to/blah thì dùng phiên bản 2 trong nhánh /main. Cú pháp tổng quát của lệnh element là:

element <mẫu xác định tập tin> <nhánh và phiên bản> [tuỳ chọn bổ sung]

Mẫu xác định tập tin thì đơn giản. Hoặc xác định đường dẫn tuyệt đối, hoặc tương đối. Có thể dùng dấu * và ? để xác định nhóm tập tin... Phần <nhánh và phiên bản> bao gồm hai phần là nhánh (ví dụ /main) và phiên bản tập tin (một con số). Có một "phiên bản đặc biệt" là LATEST, dùng để nói rằng "lấy phiên bản mới nhất". Nếu phần <nhánh và phiên bản> đơn giản là CHECKEDOUT thì dùng tập tin đã checkout.

Phần tuỳ chọn phía sau có khá nhiều thứ nhưng thứ thường dùng nhất là xác định phiên bản mới nhất trước một thời điểm nhất định (chặn trên). Ví dụ:

element * /main/LATEST -time 16-Jul-2007.03:00

sẽ chọn phiên bản mới nhất trước ngày được xác định (16/7).

Quên nói là config spec được áp dụng từ trên xuống. Nếu luật đầu không dùng thì nó sẽ dùng đến luật kế tiếp...

Để tiết kiệm công sức, thay vì gõ:

element /path/to/a /main/LATEST -time 16-Jul-2007.03:00
element /path/to/b /main/LATEST -time 16-Jul-2007.03:00

ta có thể gõ:

time 16-Jul-2007.03:00
element /path/to/a /main/LATEST 
element /path/to/b /main/LATEST 

Nghĩa là tất cả những lệnh sau lệnh "time" đều được thêm đuôi "-time...". Một số lệnh khác cũng tương tự, như lệnh "mkbranch" sắp nói.

Để tạo nhánh mới A cho một phần tử nào đó (với điều kiện đã tạo branch type cùng tên rồi), ta dùng:

element /path/to/a /main/LATEST -mkbranch A

Giả sử /path/to/a đang ở nhánh /main, khi thực hiện luật đó, nó sẽ tạo nhánh /main/A. Tuy nhiên luật đó chỉ để tạo chứ không có xài. Nên nếu viết đầy đủ thì phải ghi

element * CHECKEDOUT
element /path/to/a .../A
element /path/to/a /main/LATEST -mkbranch A
element * /main/LATEST

Mấy cái trên thông dịch là:

• Nếu có tập tin checkout, dùng tập tin đó
• Nếu /path/to/a có trong nhánh A (bất kể là /main/A, /blah/blah/A hay gì đi nữa, ... nghĩa là cái gì cũng được), thì chọn phiên bản đó.
• Nếu /path/to/a có trong nhánh /main thì chọn phiên bản mới nhất trong nhánh đó, đồng thời tạo luôn nhánh A cho tập tin đó
• Lấy phiên bản mới nhất trong nhánh /main cho tất cả các tập tin khác

Nếu nhớ không lầm thì sau khi tạo nhánh, ClearCase sẽ đọc lại config spec. Nghĩa là tạo nhánh xong nó sẽ bỏ qua tất cả các luật bên dưới và quay lại từ đầu. Ở đó nó sẽ bỏ qua luật đầu tiên (vì chưa có checkout) mà dùng luật kế là sử dụng tập tin trong nhánh vừa tạo. Dĩ nhiên trong thực tế không ai đi xác định từng tập tin như vậy nên config spec thường giống như sau:

element * CHECKEDOUT
element * .../A
mkbranch A # thêm -mkbranch A cho tất cả các lệnh bên dưới
element * /main/LATEST

Tóm lại, tạo nhánh trong Clearcase khá phức tạp. Bù lại trong cùng một view có thể có nhiều nhánh khác nhau cho các tập tin khác nhau.

ClearCase còn có một tính năng khác liên quan đến "configuration record" dùng để tái sử dụng object, đỡ biên dịch. Vụ này nó dùng chung với clearmake (thay vì make). Thông qua clearmake và CR, Clearcase có khả năng "gọi" những object từ máy khác về máy mình (gọi là "winkin") nếu như đã có người biên dịch cùng tập tin đó rồi. Tính năng này mặc dù hay nhưng đòi hỏi tất cả các máy dùng ClearCase phải nối mạng. Nếu một trong các máy rời khỏi mạng thì... chà không nên nghĩ tới. Nói chung là phức tạp, không thèm quan tâm. Các lệnh liên quan là "ct catcr", "ct diffcr".

Ai đọc tới đây mà đầu óc vẫn còn tỉnh táo thì có thể tự hào hoàn tất khoá ClearCase "cơ bản đến hơi cao". ClearCase cơ bản là thế. Xài dĩ nhiên dở òm. Nhưng biết làm sao.

Nhân bài High and low và bài Where have the universities gone?, nhận ra rằng hoàn cảnh Đại học Việt Nam không phải là cá biệt.

Không biết nên vui vì ĐHVN không cá biệt, hay nên buồn vì tình hình chung?

Có lẽ nhiều người cũng đã biết đến X Composite Extension do thời gian qua XGL, AIGLX, Compiz, Beryl được nhắc đến khá nhiều, khắp nơi. Tuy nhiên XComposite vẫn còn một số hạn chế (ngoài chuyện cần card đồ hoạ và driver hỗ trợ 3D). Bao nhiêu hạn chế thì không biết, nhưng ít ra biết một cái hạn chế khá to: XComposite không chơi chung với các ứng dụng OpenGL khác.

XComposite, xét một mặt nào đó cũng là một ứng dụng OpenGL, ngang hàng với tất cả ứng dụng OpenGL còn lại. Chính xác thì phải nói Composite Manager là ứng dụng OpenGL, không phải X Composite Extension. Gì thì gì, do cũng ngang hàng cả nên chả thằng nào nể thằng nào. Các ứng dụng OpenGL coi XComposite không ra gì và qua mặt XComposite để ghi trực tiếp lên màn hình. Kết quả nói chung là không đẹp.

Hạn chế này sắp được khắc phục. Xem thêm bài viết của Kristian Høgsberg. Cái hình nói chung không có gì ấn tượng, trừ khi đã từng thử chạy glxgears với XComposite.

:http://www.flickr.com/photos/pclouds/1055823570/

Có lẽ cũng mất một khoảng thời gian nữa trước khi mọi người có thể tạo ra được một cái hình giống như vậy. Tuy nhiên đây là bằng chứng cho thấy hạn chế "hơi bị to" của XComposite đã được khắc phục.

TB. Truy cập trực tiếp phần cứng (đồ hoạ) sẽ luôn là điểm yếu của XComposite. Ngoài OpenGL, Xv cũng sẽ không chạy (không biết XvMC thế nào).

TB2. Nhắc mới nhớ Nouveau. Mà thôi có con i945 quậy cũng được rồi.

Trước đây đã có lần đề cập đến Vala. Cứ tưởng thằng tác giả điên, ai dè nó tỉnh. Ngó lại danh sách các tính năng của Vala là phát sướng:

• Interfaces
• Properties
• Signals
• Foreach
• Lambda expressions (tạm biệt callback functions)
• Type inference for local variables
• Generics (bái bai C++ template)
• Assisted memory management
• Exception handling
• C code generation
• No additional library required (liếc liếc Mono/Java, đá VM)

Phần tiền xử lý cho "signals" thì Qt đã làm từ lâu lắm lắm rồi (moc). Do vậy ý tưởng của Vala không phải mới. Cái hay của Vala là tận dụng triệt để những tính năng mới trong các ngôn ngữ lập trình hiện đại mà vẫn bảo đảm không thêm bất kỳ ràng buộc nào. Cả Java và .NET đều thua ở điểm này vì cần VM riêng. Ngay cả D, tuy không cần VM nhưng vẫn cần một bộ thư viện chuẩn mới (Phobos thì phải). Dĩ nhiên Vala cũng cần một bộ thư viện chuẩn cho riêng nó. Nhưng nó không tạo từ đầu mà tận dụng đồ có sẵn: hệ thống thư viện GLib/GObject.

Khác với D, Vala không phát sinh mã máy trực tiếp mà tạo ra mã C trung gian. Điều này có vài cái lợi:

• Người dùng không cần trình biên dịch đặc biệt để biên dịch chươn trình viết bằng Vala, chỉ cần trình biên dịch C (chắc chắn có trên mọi hệ thống UNIX).
• Không cần đầu tư nhiều công sức. Phần việc nặng nhọc chuyển mã và tối ưu được đẩy về phía trình biên dịch C (ở đây là GCC). Nếu làm như D làm luôn phần việc của GCC thì khối lượng công việc rất lớn và chưa chắc tạo được kết quả tốt như GCC (um.. không xét GDC ở đây)
• C không quá khó hiểu. Ai không biết Vala vẫn có thể xem mã C để hiểu chương trình làm gì.

Do ràng buộc "No additional library required", Vala không thể đem đến những tính năng "hoành tráng" như .NET và Java. Vala tập trung giải quyết chủ yếu hai vấn đề:

• Giảm công sức lập trình, hạn chế gõ đi gõ lại (một vấn đề hết sức đau... tay, đặc biệt khi phải lập trình với GtkTreeView).
• Tăng cường kiểm tra các ràng buộc về ngữ nghĩa. Đây là một điểm yếu của Gtk+ bởi vì không được hỗ trợ mạnh từ phía ngôn ngữ (C). C++ kiểm tra ràng buộc tốt hơn hẳn C. Tuy nhiên dùng C++ nhiều quá dễ nằm mơ gặp ác mộng.

Nhìn một mặt nào đó, Vala giống như "C+++". Vala giải quyết một số vấn đề của C mà C++ giải quyết như kiểm tra ràng buộc, generics, exceptions. Trình biên dịch C++ thuở ban đầu, nếu không lầm, cũng giống như Vala: chuyển mã C++ sang mã C. (Hình như ObjC vẫn theo đuổi giải pháp này?). Tuy nhiên khác với C++, Vala không nhắm đến một ngôn ngữ tổng quát dùng cho mọi tình huống. Vala được thiết kế chuyên biệt để hoạt động trên nền GObject. Vala nằm đâu đó ở giữa GPL (General Purpose Language) và DSL (Domain Specific Language), trong khi D hoàn toàn là GPL. Do định hướng rõ ràng, Vala có thể áp dụng những tính năng mà C++ không thể làm được. Do quy mô thu hẹp, Vala không mất quá nhiều công sức như D. Do mục đích của thằng viết mấy dòng này là lập trình C với GTK+, Vala là lựa chọn lý tưởng (tạm biệt D!).

So sánh giữa Vala và những ngôn ngữ động như Python, Ruby hay Perl? Dĩ nhiên không xét đến tính năng "động" ở đây vì Vala dù gì cũng là C, không so với Python, Ruby, Perl được. Không rành Python lắm. Nói bừa. Vala chắc chỉ thua Python khoản thư viện. So với Ruby thì khá khó nói vì điểm mạnh của Ruby là động (động kinh khủng). Cả Perl, Ruby, Python đều hỗ trợ các kiểu dữ liệu cao cấp (như hash table, dynamic array) ở mức ngôn ngữ. Với nền tảng GLib, Vala cũng có thể làm được điều này, nhưng không biết có làm hay chưa. So với Perl thì chắc Perl (và Ruby) vẫn hơn Vala về xử lý văn bản. Perl và Ruby khá mạnh về "scripting" (chỉ thua shell chút xíu). Điểm này Vala cũng không thể so kè được.

Những ngôn ngữ như Vala đang làm mờ dần ranh giới giữa "công cụ" (trình biên dịch...) và "thư viện". Nói cho cùng, cả hai đều phục vụ cùng một mục đích: giảm công sức phát triển phần mềm. Không biết Jürg Billeter có định hỗ trợ kiến trúc "ngôn ngữ mở" cho Vala hay không. Nghĩa là bản thân lập trình viên có thể điều chỉnh thêm bớt một chút tính năng trong Vala để phù hợp với chương trình đang phát triển. Nếu được như vậy thì coi như Vala ăn đứt tất cả các thằng còn lại (trừ C là ngôn ngữ nền của Vala).

Hi vọng Vala sẽ được áp dụng rộng rãi trong GNOME, giúp giảm sử dụng Mono hay Python. Gì thì gì, Python vẫn chậm, Mono vẫn to, C vẫn là ngon nhất.

TB. Nổ thế đủ rồi. Vala, gì thì gì, cũng mới có 0.1.x. Vala chưa đủ hoàn thiện và mạnh mẽ như mong đợi. Hoặc đợi tiếp (cỡ hai năm). Hoặc "muốn ăn thì lăn vào bếp".

Cuối cùng cũng cài được cái XP. Thằng MicroXP xem ra cũng được. ISO dưới 100MB, cài xong chiếm cỡ hơn 200MB. Vậy là không cần phải vô công ty để có XP kiểm tra gitbox rồi.

Tình thế đảo ngược. Hồi trước ta chạy XP là đồ xịn, chạy coLinux bên trong. Giờ ta chạy Gentoo là đồ xịn, chạy MicroXP bên trong (với VirtualBox). VirtualBox chạy thấy cũng mượt. Hoặc tại VirtualBox ngon, hoặc tại máy mình mạnh quá, hoặc tại mình bèo quá không biết ngon là gì. Khả năng thứ ba là lớn nhất.

Khổ. Chỉ vì phát triển phần mềm tự do mà phải... xài đồ lậu :( Chán thật.