Xin trân trọng giới thiệu với quý vị một sản phẩm cây nhà lá vườn dùng làm blog. Đây là một sản phẩm được thực hiện với phương châm cùi không sợ ghẻ. Sản phẩm có những đặc điểm sau:

• Có thể sử dụng lại dữ liệu của nanoblogger
• Sử dụng ruby, erb, textile, rake, shell (cho calendar và một số thứ).
• Có thể dùng textile !
• Có smiley rồi
• Dùng rake để điều khiển việc phát sinh trang
• Chạy nhanh hơn hẳn nanoblogger

Sản phẩm đang ở giai đoạn bùn lầy, chưa có hỗ trợ Atom, RSS, chưa có lịch. Phần còn lại xài cũng tàm tạm :D.

OLS 2006 đã kết thúc và công bố các tài liệu ở dạng riêng lẻ hoặc theo tập (quyển 1 và 2).

Có một số thú vị trong các tài liệu OLS 2006 năm nay. Đầu tiên là Dự án Nouveau - Open Source 3D acceleration for nVidia cards sử dụng phương thức reverse engineering đã từng áp dụng cho driver r300 của ATI. Chạy thử một chương trình OpenGL đơn giản rồi ghi nhận xem driver nvidia thay đổi những thanh ghi gì. Cực cực khó. Dự án này được đề cập trong Open Source Graphic Drivers---They Don't Kill Kittens.

Một dự án khác cũng qui mô không kém là kboot (trong bài kboot---A Boot Loader Based on Kexec). Sử dụng chính Linux để làm boot loader. Thực ra đây chỉ là boot loader hạng hai, GRUB hoặc LILO vẫn là thằng đưa đầu ra đầu tiên. Tuy nhiên, do có đầy đủ tính năng của Linux kernel nên kboot có thể làm được những chuyện mà GRUB hay LILO không làm được. Ít ra có thể hi vọng là kboot có thể boot từ CD (GRUB chưa làm được). Cái giá phải trả cũng dễ hình dung: phải load kernel hai lần (hai kernel khác nhau). Cắt tấm hình trong tài liệu ra để minh hoạ vị trí của kboot trong quy trình khởi động.

Một dự án khác cũng khá hấp dẫn là XPRESS filesystem - A Reliable and Portable Multimedia File System. Mặc dù cũng dùng database bên dưới để lưu metadata, tuy nhiên có vẻ XPRESS không đi theo hướng WinFS vì bài báo này do toàn dân Samsung viết, mục đích chắc hẳn hướng đến hệ thống nhúng. Một trong những đặc điểm của XPRESS là có khả năng ghi không liên tục. Một bài báo khác cũng khá hay: Towards a Highly Adaptable Filesystem Framework for Linux đề cập đến khả năng đổi filesystem gọn nhẹ.

Có hai bài về SCM là bài GIT---A Stupid Content Tracker và Towards a Better SCM: Revlog and Mercurial. Bài sau đề cập đến cấu trúc dữ liệu cơ bản của Mecurial: revlog. Vẫn chưa rõ revlog với object database của GIT, thằng nào hiệu quả hơn.

Một số bài khác cũng hấp dẫn như OSTRA: Experiments With on-the-fly Source Patching, Roadmap to a GL-based composited desktop for Linux và Startup Time in the 21st Century: Filesystem Hacks and Assorted Tweaks (BootCache).

Chậm quá!

Bắt đầu dùng gmail từ 22/06/2004. Đến nay 27/07/2006. Sau hơn hai năm, có được 12293 mail, 450MB, 16% của 2748MB. Gửi đi 585 lá. Tính trung bình mỗi ngày gửi 0.8 lá, nhận 16.84 lá. Mỗi lá nhận được có kích thước trung bình 37.49KB. Suy ra mỗi ngày tốn cỡ 650KB băng thông để gửi nhận thư. Mỗi tháng tốn mất cỡ 20MB băng thông.

Giờ mà móc POP3 về, kiếm chỗ nào chứa đây trời!

..ày.. for research! Hầu hết các tài liệu đã tham khảo trước đây khi làm vspell vẫn còn nguyên trên Internet! Nếu ai muốn tham khảo, có thể lướt một vòng trên del.icio.us.

Có một cái thăm dò về Git. Hỏi thăm tình hình sử dụng Git, hướng cải tiến Git... Mở từ 23/07/2005 và sẽ kết thúc sau hai tuần.

Kết quả ở đây. Đến nay đã có khoảng 77 người trả lời, đến từ đủ các dự án to dùng như Linux, Wine, Xorg, cairo.. Có một số câu trả lời hơi bị hay. Ví dụ, cái gì giúp nhiều nhất khi học dùng Git? Trả lời: "thời gian".

Phần khó nhất của Git có lẽ sẽ do index nắm giữ. Ngạc nhiên là có một số người dùng Git chỉ cho "công việc". Phần dùng Git có liên quan cho công việc (hoặc cả dự án không có tiền) nhiều hơn các dự không có tiền :) Có một bạn dùng Git trên "Windows XP Linux". Phần dùng Git với Cygwin cũng có một số, có lẽ bản Git-Cygwin cũng không đến nỗi nào. Không rõ là giữa cogito và git cái nào được dùng nhiều hơn. Cũng có thêm một số "porcelain" khác như stgit, qgit..

Git được khen ngợi ở những điểm nào? Hai điểm dẫn đầu của Git là tốc độ và việc dễ dàng tách nhánh, trộn nhánh. Điểm mạnh thứ ba là tính "unix" của Git: chia ra nhiều lệnh nhỏ, mỗi lệnh một việc.

Phần cải tiến Git có đủ ý kiến. Từ tuỳ chọn --undo, libification, native Windows port, partial clone, rename tracking, documentation, xử lý bảng mã trong tên tập tin, giấu mấy lệnh cấp thấp, subproject, quản lý topic branch (mình cũng muốn :D ). Đặc biệt, người thứ 61 viết gần nguyên một trang. Chắc bức xúc lắm :) Tài liệu vẫn là thứ được yêu cầu nhiều nhất. Phần "làm thế nào để git phổ biến" tựu trung vẫn trong 1 chữ: Windows.

Phần còn lại chẳng có gì đáng quan tâm. Để xem tới khi đóng thăm dò còn thêm được người Việt Nam nào nữa không. (Tràn trề hi vọng .. không)

Um.. đúng ra không phải là tác giả mà là người đang quản lý Git - Junio C Hamacho. Đây có lẽ là slide được dùng để trình bày ở OLS. Slide trình bày về nguồn gốc Git, một số nguyên tắc cơ bản trong Git, các đặc tính hay của Git, định hướng tương lai cho Git. Slide có luôn phần transcript bên dưới nên rất dễ hiểu, không cần phải nhìn hình đoán nội dung.

Có một số cái hay, thậm chí cho những người đã biết Git, ví dụ như ".. but don't leave unnecessary cruft around. If it merges cleanly, reset and keep going. Otherwise, rebase". Slide khoe hàng "git bisect", cho thấy thêm bisect không chỉ đơn giản là nội suy tuyến tính vì nó phải hoạt động trên một đồ thị chứ không phải một trục thẳng như đã nghĩ. Ngoài ra còn có dùng git log để tìm ra những commit có liên quan đến conflict (mèn, tuyệt!). Chuyện xem vừa log của commit, vừa thay đổi trong commit (nói gọn lại là xem nguyên cái commit) thì xưa rồi, chả cần bàn.

Về phần tương lai, có lẽ quan trọng nhất là portability (Windows!) và partial repository. Chơi chung với phần portability này là libification. Libification sẽ giúp thống nhất ngôn ngữ, ít ra quy hầu hết về C thay vì một tập hợp của C, Bash, Perl, Python và Tcl/Tk như hiện nay. Libification cũng giúp dễ dàng tạo các công cụ hỗ trợ cho Git hơn.

Về phần Partial Repository, Junio nêu ra hai khía cạnh khá hay: partial về thời gian và partial về không gian. Partial về thời gian hồi trước được bàn cãi tưng bừng, chia ra làm hai loại là shallow clone và lazy clone. Còn partial về không gian thì .. Git làm được không ta? :) Với cách hoạt động của commit và tree object của Git, rất khó để có thể clone một thư mục con và chỉ hoạt động trên thư mục đó (chuyện gì sẽ xảy ra nếu merge?). Công nhận cả hai cái đều khó, rất khó. Hi vọng một trong hai cái partial repository sẽ xuất hiện trong Git 2.0.

Ngoài ra còn có slide về Cogito và một tí StGit ở đây. Nó dùng SuSE BrainShare template. Hmmm...

Sau gần ba tuần soán ngôi Within Temptation, giờ Blackmore's Night đã trở về lại vị trí số 5 quen thuộc.

Có một thay đổi nhỏ khác trong tốp 5: Nightwish vươn lên số 2, đá Apocalyptica. Đúng là cả tháng nay toàn nghe gì đâu không, không có Apocalyptica. Không chừng nên phát động chiến dịch dành lại số 2 cho Apocalyptica :D

Sau Gnumeric, giờ đến Evolution. Ngoại trừ GNOME platform ra, coi bộ các ứng dụng to to của GNOME/GTK+ đều đã có mặt trên Windows: Gnumeric, Gimp, Gaim, Inkscape, Evolution, Dia, Planner. Vẫn thiếu rhythmbox (có lẽ banshee có thể chạy trên Windows). Xem ảnh thì GQview tàm tạm. Xem từ điển có stardict. Thiếu cái editor đơn giản (gvim có chạy trên Windows không cà). Evince không biết có chạy trên Windows hay không - cơ sở của evince là cairo/poppler, hình như đều chạy được trên Windows.

Để thử coi Evolution for Win32 chạy ra sao. Thử với .. Wine coi nó chạy nổi không :D Chắc lại phải khởi động lại dự án mg-win32 quá.

Nói chung dùng preedit mode cũng không đến nỗi nào. Viết blog bằng gtk-xvnkb mát trời :D.

Tuy nhiên, preedit mode gặp vấn đề với epiphany location bar (gõ xong, chưa thoá khỏi preedit mode, kéo xuống chọn search, nhấn Enter thì nó không chịu commit). Đây có thể là lỗi của Epiphany khi cố hack GtkEntry. Sẽ xem lại.

Vấn đề đáng phiền nhất là .. Vim! Các lệnh vim đều là lệnh dạng ký tự đơn. Gõ bằng gtk-xvnkb xong, chẳng biết làm sao nữa vì nó đang .. chờ gõ chữ kế :( Phải gõ bậy thêm cái gì vô nữa cho nó qua lúc hiểm nghèo. Hic. gtk-xvnkb không có phím đặc biệt để kết thúc chế độ preedit và commit mà chỉ đơn giản là gõ và cứ gõ. Khi nào thấy cần thì nó tự commit (để không làm thay đổi thói quen dùng bàn phím của người Việt). Hậu quả ê chề.

Với vim, chắc phải chơi backspace tiếp thôi. Được cái là Gtk+ hỗ trợ lấy surrounding text nên chắc không cần dựa theo buffer mà gõ bậy. Dĩ nhiên cái này cũng không đoán trước được, tuỳ vào thằng sử dụng GtkIMContext. Coi bộ viết riêng một module cho vim để gõ là hay nhất. Vượt qua các trở ngại hết sức lãng xẹt của Vim.

Lâu lắm rồi không viết gì vào chuyên mục hâm. Hèn gì dạo này điên quá. Hâm tí.

xvnkb có nhiều khuyết điểm. Một số có thể kể ra như: dùng biến toàn cục, chơi LD_PRELOAD, không phối hợp đồng đội với gnome-screensaver. Một cách tiếp cận khác là cài đặt xvnkb như là một Gtk+ Input Method module. Cách này giải quyết hết mấy cái khuyết điểm trên. Tuy nhiên, nếu làm theo đúng chuẩn của GtkIMContext thì không có chuyện phát sinh phím xoá lùi. Có thể Unikey đã dùng mánh nào đó để qua mặt (chắc tạo signal gửi ngược cho widget).

Tuy nhiên, thử tuân thủ luật chơi vẫn hay hơn. Thay vì phải phát sinh phím xoá lùi. Ta đưa nguyên một từ về dạng pre-edit. Từ vẫn hiện lên màn hình, nhưng không thực sự được nhập vào. Do chuỗi pre-edit được IM module quản lý nên toàn quyền xử lý, muốn xoá giữa xoá đầu tuỳ thích. Khi nào bảo đảm người dùng không sửa ngược nữa (vd, nhấn khoảng trắng hoặc các dấu khác) thì mới commit chuỗi đó - nhập vào thật sự.

Cách này cũng có cái dở của nó. Do chỉ các chuỗi pre-edit chỉ thấy mà không có thật nên đôi khi gây ngỡ ngàng cho người dùng. Ví dụ, chương trình hỏi y/n. Nhấn y xong vẫn thấy nó trơ ra. Với cách thông thường thì đã có tác dụng ngay. Với kiểu pre-edit thì phải có cách báo cho IM biết chấm dứt chế độ pre-edit. Hơi khó. Nhưng mà những trường hợp đó tốt hơn dùng default IM thay vì dùng IM tiếng Việt, an toàn hơn.

Kẹt cái chuyển đổi IM trong ứng dụng GTK+ cực quá. Cách duy nhất để chuyển là nhấn phím phải, chọn IM. Tạm thời tắt IM cũng được nhưng vẫn bưởi. Thôi kệ thà bưởi mà xài được.

Tạm thời gõ được, mặc dù gõ sai từ a-z. Thử xem tiến được bao xa với cách này.

Nhân việc mò Fedora Core để tìm hiểu vì sao FC lại dùng chữ “System” thay vì “Desktop” trên gnome-panel, ghi luôn vài dòng về cái, gọi bình dân là “đít trâu”, gọi vắn tắt là “distro” và gọi chính thức là “Linux distribution”.

Trên Wikipedia có ghi khá nhiều thứ về “Linux Distribution”. Theo cách nghĩ thông thường thì Linux Distribution đơn giản là đóng gói các phần mềm lại, gom thành một cục, ghi ra CD.

Tuy nhiên sự đời không đơn giản thế.

Nguyên nhân ở chỗ Linux Distribution đứng giữa người sử dụng và nhà sản xuất (“đầu nguồn” - upstream). Do phải đối mặt với người dùng nên Linux Distribution phải là một sản phẩm hoàn chỉnh. Và do các phần mềm tự do thường được phát triển độc lập, các phần mềm này thường không phối hợp tốt với nhau. Những người xây dựng distro phải kiêm luôn nhiệm vụ sửa đổi một phần các chương trình để nó có thể chơi chung hoà bình với nhau. Để dưới mắt người sử dụng, đó là một khối. Công việc này không đơn giản nếu xem xét số lượng các gói phần mềm trong một distro. Do distro đứng giữa những người phát triển phần mềm gốc và người dùng, nên người tạo distro cũng là người nhận phản hồi của người dùng, trực tiếp hỗ trợ người dùng, trực tiếp nghe người dùng chửi bới. Các thông báo lỗi từ người dùng thường được chuyển về tay các distro vì đa phần distro đều đã thay đổi một chút trong các phần mềm, các phần mềm không còn nguyên vẹn như ban đầu, nên có khả năng lỗi là do các thay đổi của distro gây ra chứ không phải của phần mềm gốc. Thậm chí trong trường hợp lỗi là của phần mềm gốc, sau khi đã thông báo lỗi cho người phát triển phần mềm và đã sửa lỗi, thường các distro sẽ tích hợp ngay các bản vá lỗi vào hệ thống của mình mà không chờ phát hành phiên bản phần mềm mới vì áp lực người dùng (số lượng patch dạng này chiếm hơi bị nhiều).

Bởi vậy, distro không chỉ đơn giản là một đóng gói phần mềm. Distro là một phiên bản khác của một loạt các phần mềm, được điều chỉnh lại cho phù hợp với distro đó. Bởi vậy nếu nói “tui đang dùng nautilus”, thì nên nói “tui đang dùng nautilus của fedora” hoặc “tui đang dùng nautilus của suse” vì mấy cái nautilus này không có gì bảo đảm giống nhau. Khối lượng công việc của một distro do đó không nhỏ tí nào. Có thể coi một distro có developer cho tất cả các phần mềm mà nó chứa. Những “distro developer” này sẽ liên lạc với “upstream developer” khi cần (khi thông báo lỗi, cung cấp bản sửa lỗi, thêm tính năng mới…).

Nhân nói tính năng mới, các distro cũng có những tính năng đặc trưng riêng, phát triển cho từng distro và không thể đưa lên upstream đơn giản bởi vì nó đặc trưng cho distro đó. Tuỳ vào tiềm lực của từng distro mà khả năng xây dựng những thứ linh tinh của riêng mình khác nhau. Mấy distro nhỏ nhỏ sẽ hạn chế phần này vì quá tốn kém (về nhân lực).

Phần trên chủ yếu nói về bề nổi của distro, những thứ người dùng thấy. Distro còn có những thứ thuộc về hạ tầng cơ sở. Do bản chất của phần mềm tự do, các phần mềm được phát triển độc lập với nhau, do đó không có sự phối hợp giữa các phần mềm như đã nói ở trên. Điều này dẫn đến một thứ tệ hơn nhiều: không có một hệ thống cơ sở chung cho Linux. Có một số chuẩn mực được đưa ra, ví dụ như FHS, nhằm hướng dẫn các nhà lập trình viết sao cho dễ gắn lại với nhau. Nhưng như thế chưa đủ.

Thử xem xét quá trình khởi động Linux. Linux khởi động bắt đầu từ boot loader như grub hoặc lilo. Sau đó kernel (“linux”) được nạp vào. Linux gọi “init” (gói sysvinit). Từ đây mọi việc bắt đầu mờ ảo. Theo nguyên tắc chung thì init mở /etc/inittab, nhờ đó gọi getty (gói util-linux). Getty gọi login. Login gọi bash. Cũng nhờ inittab, các service sẽ được khởi động. Nếu cần thì xdm/gdm/kdm sẽ được gọi. Nó sẽ gọi X và khởi động một mớ thứ lung tung đằng sau. Và bởi vì quy trình khởi động còn lại hoàn toàn không được xác định, chính các distro phải chọn cho mình một quy trình khởi động (hoặc tạo một quy trình riêng). Đa số theo sysv, một số theo bsd, số còn lại xài đồ cây nhà lá vườn.

Cái quy trình khởi động này dính dáng đến đủ thứ, từ việc mount các partition vào đúng chỗ, nạp kernel module, kiểm tra phần cứng, nạp các dịch vụ hệ thống tối thiểu, đến những thứ linh tinh khác. Cũng chính vì hệ thống khởi động không thống nhất, dẫn đến hệ thống cấu hình đi kèm cũng lung tung. Mỗi người một kiểu. Các phần mềm cũng được thay đổi cho phù hợp với hệ thống cấu hình của từng distro.

Nếu hình dung phần “nổi” (nhìn thấy) của từng distro là các vật dụng trong nhà thì có vô khối thứ ngoài chợ, từ bàn chải đánh răng, giường tủ, khung tranh.. đến cửa các loại, súng ống đạn dược. Các distro đến chợ trời “phần mềm tự do” gom về, sửa lại. Sơn phết tí cho hợp tông ngôi nhà, cưa bớt cho nó thấp đi, dán tem nhãn hiệu… rồi đặt vào chỗ thích hợp. Nếu hình dung phần hạ tầng distro như căn nhà thì phần mềm là mấy cục gạch còn distro là xi măng. Tốn một khối lượng đáng kể xi măng để xây nhà. Vậy nếu bạn không thích xài distro, vô tư. Bạn có thể ra chợ gom các thứ bạn cần, về đục đẽo lại (sẽ mất nhiều tháng đấy). Và bạn sẽ phải tự tạo xi măng (nếu không thích có thể chôm xi măng của distro khác, nhưng chưa chắc phù hợp với bạn). Và sau nhiều tháng trời cưa đục cắt dán, xây rồi đập, đập rồi xây, bạn có được một “hệ điều hành” của chính bạn, dành cho bạn. Nhưng đơn giản hơn nhiều nếu bỏ tiền ra sắm quách một ngôi nhà.

Mà sau khi mua nhà xong, cần phải đem nhà về “gắn” lên nền đất của bạn: installer. :D installer kèm theo package manager là hai phần cũng đặc trưng distro. Tuy nhiên viết dài quá rồi. Mỏi tay rồi, không viết nữa.

Nói tóm lại, distro không phải chỉ đơn giản là “một đông phần mềm gom lại”. Nó cũng là một phần mềm (hoặc nhiều phần mềm). Một thứ phần mềm dùng để gắn kết các phần mềm khác. Distro là một phần của hệ thống phát triển phần mềm tự do. Công sức bỏ ra trong distro chắc cũng chiếm 1/4 trong tổng công sức phát triển một phần mềm. Distro (đặc biệt là các distro lớn) có tiếng nói quan trọng trong thế giới phần mềm tự do, bởi vai trò trung gian giữa người dùng và người phát triển của nó. Không có distro (nói đúng hơn là distro chung) thì chỉ có những siêu cao thủ mới có khả năng sử dụng Linux (nói đúng ra, mỗi thằng đó đã tạo một distro của riêng mình). Sự hình thành các distro là điều không thể tránh khỏi, để lấp đầy khoảng trống còn lại giữa các phần mềm và khoảng trống bao bên ngoài các phần mềm. “Đít trâu” là “siêu phần mềm”.

Phần mềm có “siêu phần mềm” thì đít trâu cũng có “siêu đít trâu” :) Những đít trâu được tuỳ biến lại dựa trên các đít trâu sẵn có, tận dụng mọi ưu điểm của đít trâu hiện có. Đít trâu loại một (đít trâu tầm thường) chỉ có một số như Fedora Core, SuSE, Debian, Gentoo, Mandriva (mặc dù dường như dựa trên Red Hat nhưng đã phát triển độc lập), Slackware ... Siêu đít trâu (đít trâu loại hai) thì vô số. Ubuntu chắc phải xếp vào loại “đít trâu một rưỡi”. Thậm chí còn có cả đít trâu loại ba (như trường hợp Knoppix dùng nền Debian, rồi một loạt các đít trâu khác dùng nền là Knoppix). Vậy tạo một đít trâu dễ hay khó? Dễ òm, remaster knoppix lại là xong, móc FC ra, đổi /etc/redhat-release lại là xong. Khó lắm, mất nhiều tháng, nhiều năm, nhiều công sức.

Chiến tranh lại bùng nổ trên desktop-devel-list. Lần này là Mono/C# và Python. Có vẻ như đưa Python (đại diện trong GNOME là deskbar-applet) vào là một ngoại lệ không hay lắm vì Mono (đại diện hiện thời là Tomboy) cũng dựa vào đó mà cãi. Nếu Gtk# binding vào GNOME, nhiều khả năng một loạt ứng dụng khác như f-spot, beagle, monodevelop.. cũng sẽ vào.

Nếu phải quyết định từ bỏ C, chuyển lên một ngôn ngữ cấp cao hơn, thì .NET là nền tảng tốt hơn Python. Hổng chừng Sun sẽ ra mắt Open Source Java kịp lúc để cãi nhau cho gnome 2.18.

Có một cái trong gói gnome-panel là panel-test-applets

Dạo gần đây sự phát triển X trở nên sôi động với sự xuất hiện của Composite extension và sau đó là dùng OpenGL để tăng tốc Composite. Hai tên tuổi nổi đình nổi đám trong sự kiện này dĩ nhiên là AIXGL và XGL. Nhưng phải nói không dễ gì hiểu được các chi tiết kỹ thuật bên trong của nó với đủ thứ hỗn độn giữa GLX rồi XGL hay XGLX rồi Xegl... Bài Communication between Xorg, Xgl, and an OpenGL client, through libGL and the GLX Protocol có thể giúp làm rõ sự khác nhau giữa các thuật ngữ trong thế giới "ít".

Chộp vài cái hình đẹp đẹp trên trang đó để lưu lại phòng khi trang gốc bị chết. Như trong hình dưới, ta thấy đường indirect rendering đi vòng qua GLX rồi thẳng xuống 2D Card - nghĩa là không có tăng tốc 3D. Nói cách khác, chậm rì.

Giờ chuyển qua hình AIXGL. Ta thấy có một đường nối mới giữa GLX extension và 3D driver. Nhờ đó indirect rendering có thể được tăng tốc nhờ card 3D.

Giờ đến mô hình lý tưởng (mà Xgl hướng đến): X server được xây dựng dựa trên nền tảng OpenGL, thông qua thư viện glitz. Không còn 2D card nữa. Việc chuyển qua hoàn toàn dùng OpenGL có lẽ sẽ tránh được một loạt các khó khăn khi trộn lẫn giữa các thao tác 2D của X với các thao tác của OpenGL.

Mô hình thực sự Xglx đang dùng không đẹp được như vậy vì Xegl chưa xong. Do đó Xgl sử dụng một X server bình thường để thay thế phần glitz và bên dưới. Đồng thời có thêm một đường nối trực tiếp từ Xgl sang 3D driver (Xegl không có đường này).

Túm lại là .. vẫn chưa hiểu gì hết :D

Với Xorg 7.2 (xorg-server-1.1.0), các thay đổi liên quan đến AIXGL đã được đưa vào. Do đó dùng AIXGL cũng không đến nỗi chua lắm. Vẫn phải lấy thêm một số thứ vẫn chưa có trong portage, đặc biệt là mesa. Ngoài ra thì thêm metacity và các gói liên quan của nó. Các gói mới có trong XGL-Overlay của Johannes (Hanno) Böck

Một số cấu hình xorg.conf sau khi cài đặt đầy đủ. Trong phần ServerLayout cần thêm tuỳ chọn

Option "AIXGL" "true"

Dĩ nhiên phải bật composite trong phần Extensions. Trong phần Device thêm

Option "XAANoOffscreenPixmaps" "true"
Option "AllowGLXWithComposite" "true"

Nói chung AIXGL (với metacity) cũng không có gì ghê gớm lắm. Phiên bản metacity mặc định (hỗ trợ composite bằng cách bật tuỳ chọn trong GConf /apps/metacity/general/enable_compositor). Mấy cái cửa sổ cứ rung lên mỗi khi có focus (thậm chí cả desktop), nổ đùng nếu đóng cửa sổ. Khi thu nhỏ cửa sổ thì nó co lại bé xíu ở giữa màn hình rồi nhảy tót xuống taskbar (phóng to thì ngược lại). Mấy cái menu (và cả hộp thoại) hiển thị mờ mờ khá đẹp. Mở menu thì nó bung ra từ từ. Nếu dùng metacity với USE_WOBBLY=1

USE_WOBBLY=1 metacity --replace

thì kéo cửa sổ cũng na ná như kéo rèm. Nó lượn qua lượn lại, lắc lư một hồi mới chịu đi.

Với AIXGL/XGL (và có lẽ hỗ trợ composite nói chung), Xv không chạy nữa. Nghĩa là nếu xem phim, không nên dùng Xv hoặc sẽ không thấy gì cả. Vẫn còn việc phải làm cho AIXGL/XGL. Các cửa sổ trong metacity đôi khi hiện ra không đúng thứ tự trên dưới. gkrellm2 thì cứ đòi nằm dưới (dù đặt là "on top"). Applet lịch trên bảng điều khiển cũng bắt chước gkrellm2 chui tọt xuống dưới. Menu chính của gimp.. nằm đằng sau gimp toolbar :( Tuy nhiên, glxgears lại nhảy lên đầu ngay cả khi đẩy nó ra sau! Với USE_WOBBLY thì tính ổn định giảm đáng kể (hay crash).

Như đã đề cập trong Từ GNU Screen sang Gtk+ Screen, vấn đề cốt lõi là tách ứng dụng khỏi một display (nói dễ hiểu hơn, khỏi một X server) và chuyển sang display khác. Với Gtk+ 2.10.0, gtk-demo đã có thể tự chuyển từ server này sang server khác!

Muốn thử cũng dễ. Cài Gtk+ 2.10.0 vào. Chạy Xnest -ac :1. Mở gtk-demo trên display nào cũng được. Vô phần Change display, thêm display còn thiếu vô (hoặc là :0.0, hoặc là :1.0) xong chọn display đó, nhấn Change. Dùng chuột chọn cửa sổ chính của gtk-demo và .. whoa! :D

Hú hú hú!

Từ www.paldo.org/vala:

Vala is a new programming language that aims to bring modern programming language features to GNOME developers without imposing any additional runtime requirements and without using a different ABI compared to applications and libraries written in C. valac, the Vala compiler, is a self-hosting compiler that translates Vala source code into C source and header files. It uses the GObject type system to create classes and interfaces declared in the Vala source code. It's also planned to generate GIDL files when gobject-introspection is ready.

Có lẽ chưa bao giờ GObject lại xâm nhập vào sâu đến thế, được một ngôn ngữ công khai hỗ trợ!. Có lẽ mình không phải là thằng điên duy nhất trên thế giới này. :D Tuy nhiên nếu có được thêm vài thằng điên như thằng tác giả Vala này (không phải điên kiểu pclouds) thì đỡ biết mấy.

Ví dụ cũng hết sức ấn tượng:

/* Advanced Vala Sample Code */
using GLib;

public class Sample {
    public string name { get; set; }

    public signal void foo ();

    public void run () {
        foo += s => {
            stdout.printf ("Lambda expression %s!\n", name);
        };
        
        /* Calling lambda expression */
        foo ();
    }

    static int main (int argc, string[] argv) {
        foreach (string arg in argv) {
            var sample = new Sample (name = arg);
            sample.run ();
            /* Object will automatically be freed
             * at the end of the block */
        }
    }
}

Từ http://live.gnome.org/Subversion:

MIGRATION CANCELLED :(

CVS cut off was: Friday 14th July 2006 at 23:59UTC

CVS re-enabled: Sunday 16th July 2006 at 03:50UTC

đại loại như 'hết pin', 'hết tiền', 'đến giờ về'... Mấy cái thông báo này có thể hiện bằng notify-send (gói libnotify). Xài cực dễ.

notify-send 'Tiêu đề' # chỉ hiện tiêu đề
notify-send 'Tiêu đề' 'Nội dung dài thoòng' # Hiện nhiều hơn
notify-send -i stock_dialog-warning 'tè le' # Thêm cái icon
notify-send -t 10000 'hát lên nào' # hiện mười giây
notify-send -u critical # hiện màu khác để nhấn mạnh
notify-send --help # RTFM!!!

Theo kế hoạch thì Quản trị GNOME sẽ chuyển từ CVS sang SVN vào 14/06/2006. Giờ này có vẻ như anonymous subversion đã chạy rồi. Tuy nhiên chưa biết quyền ghi vào CVS đã tắt chưa và có thể commit vào SVN chưa. Trên GNOME Wiki cũng có một số thay đổi liên quan đến Subversion.

Chừng nào thì GNOME sẽ chuyển qua dùng Git nhỉ? :D Tính tới thời điểm này cũng chỉ có ba kho Git lớn là Linux kernel, Wine và freedesktop (tính luôn cả Xorg). Thôi kệ, tạm biệt CVS, hế lô SVN cũng là đáng mừng rồi.

Mấy ngày vừa qua, thế giới phần mềm tự do xuất hiện một bóng hồng mới: Elisa.

Elisa là một "media center". Nó là thứ dùng để chơi mọi thứ có thể dùng để giải trí (không tính game) như ảnh, phim, nhạc... Dù bản ra mắt (0.0.1) chỉ đáng gọi là "prototype" chứ chưa được đến alpha, nhưng cũng rất ấn tượng (xem thử ảnh chụp hoặc xem phim luôn). Vậy bản prototype này làm được gì? Ờ.. nó có thể xem ảnh (từng ảnh hoặc slideshow). Ảnh có thể quay qua quay lại. Nó có thể xem phim, nghe nhạc và xem DVD. Elisa đẹp ở mấy cái chỗ màu mè hoa lá hẹ của nó. Ví dụ, duyệt menu to nhỏ như kiểu dockbar của Mac. Khi duyệt phim thì mấy cái ảnh thu nhỏ của phim cũng chạy ầm ầm luôn (dù nhỏ xíu). Có thể xem be bé, nghiêng nghiêng giữa màn hình, hoặc xem toàn màn hình (ẩn các nút đi). Có thể dùng điều khiển hồng ngoại từ xa để điều khiển (đoán thế).

Elisa có thể được coi là mắt xích cuối cùng trong hệ thống multimedia của Fluendo. Fluendo viết ra Gstreamer để xử lý tất tần tất cả thứ có dính đến "multimedia". Xong viết cái Flumotion làm media server, với sự hỗ trợ của Gstreamer. Giờ thêm Elisa đóng vai trò phần tiêu thụ, coi như Fluendo đã có đầy đủ đồ nghề để đi oánh lộn trong thị trường "media center".

Elisa được thiết kế để chạy độc lập. Elisa có lẽ có thể chạy trên Windows, nhưng chạy Windows thì phí của giời. Bởi vì nếu dùng Linux, ta có thể chạy Elisa với một cấu hình thấp hơn so với thông thường. Elisa sử dụng SDL để hiển thị, không phụ thuộc vào X Window. Ngoài Linux, bạn cần thêm Python. Vậy có thể nói ba phần to nhất để chạy Elisa là Linux, GStreamer và Python. Với lượng gói phụ thuộc ít như vậy, có lẽ Elisa có thể chạy trên một hệ thống 128MB (64MB được không cà?) và một CPU kha khá để có thể xem phim và xử lý ba cái màu mè của nó (chắc hổng cần đến P4 đâu). Nếu loại được Python thì hổng chừng còn giảm RAM được một mớ nữa (chắc không giảm CPU vì python chỉ làm chất kết dính, mấy cái phần tốn CPU do gstreamer/cairo.. lo hết rồi). Có một cái máy như thế với TV card, hỗ trợ hồng ngoại. Cộng thêm một bộ điều khiển từ xa và cái TV là thay thế ngon lành cái đầu máy :D

Trích dịch từ "The UNIX-HATERS Handbook"

Sổ tay Những người ghét UNIX

Phần 2 - Chào người mới!

Người dùng máy tính mới (hoặc thậm chí là người thỉnh thoảng dùng) cần một sự hỗ trợ nhất định từ phía hệ thống. Một hệ thống máy tính ít nhất cũng phải cung cấp những tiện nghi sau cho thượng đế của nó:

• Tên lệnh hợp lý, dựa theo tính năng của nó
• Xử lý cẩn trọng với những lệnh nguy hiểm
• Thống nhất và có thể dự đoán được cách các lệnh xử lý tham số và tuỳ chọn
• Tài liệu trực tuyến dễ đọc và dễ tìm
• Trả lời rõ ràng, đầy đủ khi lệnh không hoạt động

Khi Unix đang được xây dựng, nó không phục vụ cho bất kỳ vị khách nào. Những người dùng chính là những người phải xây dựng những phần chưa hoàn tất trong hệ thống. Đáng buồn là không những con người không được mời xây dựng hệ thống mà họ cũng không dự đoán hay lên kế hoạch về nhu cầu sử dụng luôn. Vậy cho nên, nhiều tiện nghi cơ bản, như dội nhà tiêu, sưởi ấm, cửa sổ có thể mở, là cực kỳ khó và đắt đỏ để đưa vào hệ thống. Tuy nhiên những người xây dựng vẫn cảm thấy kinh ngạc với thiết kế của mình, đến nỗi họ không quan tâm nếu phải ngủ trên sàn nhà trong phòng không có bộ dò thuốc lá.

Trong gần suốt lịch sử, Unix là một phương tiện nghiên cứu dành cho các trường đại học và các nhà nghiên cứu. Với sự bùng nổ của các máy trạm giá rẻ, Unix bước vào một kỹ nguyên mới, delivery platform. Dễ xác định được thời điểm của thay đổi này: đó là lúc các nhà sản xuất máy trạm tách trình biên dịch C khỏi bộ phần mềm chuẩn của họ và bán với giá rẻ cho những người không phải lập trình viên. Các báo cáo hoá thạch không nêu rõ cụ thể khoản thời gian, nhưng nó xảy ra hầu hết trong năm 1990. Vậy là chỉ trong vài năm, các nhà sản xuất bắt đầu quan tâm thật sự nhu cầu và đòi hỏi của người dùng cuối, thay vì chỉ có lập trình viên. Điều này giải thích tại sao các công ty bắt đầu viết các giao diện đồ hoạ cho người dùng để "thay thế" cho shell. Không cần đố kỵ những công việc của những công ty này làm gì.

Tên lệnh mờ mịt

Người dùng Unix mới luôn ngạc nhiên với cách chọn tên lệnh trong Unix. Không có một khoá huấn luyện dùng DOS hay Mac nào chuẩn bị cho người dùng trước vẻ đẹp mĩ miều của những cái tên bí ẩn hai ký tự như cp, rm và ls

Những ai đã từng dùng các thiết bị I/O của thập niên 80 sẽ ngờ cái gốc của sự đi lùi này là tốc độ, độ ổn định, và quan trọng nhất là bàn phím Teletype ASR-33, thiết bị phổ dụng vào những ngày ấy. Không giống như bàn phím ngày nay, dựa vào nguyên tắc phản hồi để tính khoảng cách phím, và chỉ cần một lực tác động duy nhất để đóng các tiếp điểm của bàn phím. Phím của bàn phím Teletype cần di chuyển ít nhất nửa inch và cần một lực đủ để chạy một bộ phát điện cỡ nhỏ thường thấy trên xe đạp. Bạn có thể vỡ đốt tay khi gõ những con quái vật này.

Nếu Dennis và Ken có một cái Selectric thay vì Teletype, có lẽ họ sẽ chọn "copy" và "remove" thay vì "cp" và "rm" (Ken Thompson khi bị hỏi sẽ làm gì nếu được làm lại Unix lần nữa, ông trả lời "Tôi sẽ gọi creat là `e'." ). Những rào cản kỹ thuật đó hạn chế khá nhiều sự lựa chọn.

Sau hơn một hoặc hai thập kỷ, tại sao vẫn tiếp tục truyền thống? Tại vì thế lực lịch sử, còn gọi là mã kế thừa và sách. Nếu một nhà sản xuất thay rm bằng, ví dụ, remove thì mọi cuốn sách từng mô tả Unix sẽ không còn áp dụng được trên hệ thống đó, và mọi shell script gọi đến rm cũng sẽ ngừng chạy. Nhà sản xuất đó cũng sẽ ngưng tuân thủ chuẩn POSIX luôn.

Thế kỷ trước, những người gõ nhanh thường làm kẹt bàn phím, do đó các kỹ sư đã chế ra bàn phím QWERTY để cản họ lại. Bàn phím ngày nay không kẹt nữa, nhưng chúng ta vẫn sống chung với QWERTY. Một thế kỷ sau, thế giới sẽ vẫn sống chung với rm.

Tai nạn sẽ xảy ra

Người dùng quan tâm sâu sắc đến dữ liệu và tập tin của họ. Họ dùng máy tính để tạo, phân tích, lưu trữ thông tin quan trọng. Họ tin tưởng máy tính để bảo vệ tài sản có giá trị của họ. Không có niềm tin này, mối quan hệ sẽ trở nên căng thẳng. Unix đã lạm dụng sự tin tưởng bằng cách từ chối bảo vệ khách hàng của nó trước những lệnh nguy hiểm. Và lệnh đặc biệt nguy hiểm là rm, lệnh được sinh ra để hủy hoại các tập tin.

Mọi người dùng Unix mới đều "lỡ" xoá không thể phục hồi một hoặc nhiều tập tin quan trọng. Ngay cả các chuyên gia và quản trị hệ thống cũng "lỡ" xoá nhầm tập tin. Hao phí cho nó, bao gồm thời gian bị mất, công sức bị mất, hao phí phục hồi tập tin, lên đến hàng triệu đô la mỗi năm. Nó là một vấn đề đáng để giải quyết; nhưng không hiểu tại sao các Unix gia lại không làm. Có phải tại thần bất hạnh yêu các công ty quá cỡ?

Các tập tin chết đi và đầu thai thường xuyên dưới mái nhà Unix hơn bất cứ hệ điều hành nào khác. Đây là lý do:

1. Hệ tập tin Unix không đánh số phiên bản tập tin. Tính năng đánh phiên bản tự động cho tập tin sẽ dùng một tên mới hoặc một số mở rộng mới cho một phiên bản mới, nhờ đó giữ lại phiên bản cũ. Tuy nhiên, ghi đè là quy tắc của Unix.

2. Lập trình viên Unix lơ là kiểm tra và thông báo lỗi hết sức ác độc.

   Nhiều chương trình không thèm quan tâm để ý xem tất cả đã được ghi đầy đủ ra đĩa hay chưa. Một số không thèm xem xem tập tin đầu ra có được tạo ra hay chưa. Tuy nhiên những chương trình này rất hăng hái xoá các tập tin đầu vào sau khi đã hoàn tất

3. Unix shell, không phải các lệnh, xử lý bung "*".

   Để shell bung * làm cho các lệnh, như rm không thể kiểm tra an toàn để tránh hạ thủ hoặc đánh cho tàn phế. Ngay cả DOS cũng kiểm tra những lệnh nguy hiểm như del *.*. Tuy nhiên với Unix, chương trình xoá không thể xác định vì người dùng gõ:

   % rm *
   

   hay

   % rm file1 file2 file3
   

   đều như nhau.

   Tình huống này có thể cứu vãn được phần nào nếu lệnh gốc được lưu lại và chuyển cho chương trình. Có lẽ nó có thể được tống vào các biến môi trường.

4. Xoá là mãi mãi.

   Unix không có lệnh "undelete". Với hệ điều hành khác, an toàn hơn, xoá chỉ là đánh dấu các khối của tập tin là "có thể tận thu", chuyển thông tin thư mục của tập tin đó sang một thư mục đặc biệt dành cho "các tập tin bị xoá". Nếu đĩa đầy, tập tin sẽ thật sự bị xoá.

   Hầu hết hệ điều hành dựa theo ý tưởng hai bước, delete-and-purge, để giải phóng đĩa. Đây không phải khoa học tên lửa; thậm chí Macintosh từ 1984 cũng đã có "ném vào thùng rác" và "đổ rác". Tenex còn có trước, vào năm 1974.

   DOS và Windows cung cấp cái giống như là cái bẫy hơn là cái giỏ rác. Nó đơn giản xoá tập tin, nhưng nếu bạn muốn lấy lại thì cũng có công cụ để lấy lại. Nó chạy. Nói cho đúng hơn là đôi khi nó cũng chạy.

Bốn vấn đề này đã được hiểu rõ trước khi có cả Unix. Nhưng chúng bắt đầu bị rơi vào quên lãng nhờ Unix được thế giới chấp nhận như một hệ điều hành "chuẩn".

Chào bạn đến với tương lai.

"rm" là tương lai

Những nguyên tắc trên kết hợp thành những câu chuyện rùng rợn. Những trao đổi trên nhóm Usenet alt.folklore.computers minh hoạ cho trường hợp này:

Date: Wed, 10 Jan 90
From: djones@megatest.uucp (Dave Jones)
Subject: rm *
Newsgroups: alt.folklore.computers

Ai đó nếu có bao giờ định gõ như vầy:

% rm *.o

Và lỡ tay gõ thành như vầy:

% rm *>o

Là sẽ có được một tập tin rỗng mới mang tên "o" kèm theo cực nhiều chỗ trống dành cho nó!

Thực ra bạn có thể thậm chí không có được tập tin o vì tài liệu shell không nói rõ tập tin o được tạo trước hay sau khi xử lý wildcard. Shell có thể là một ngôn ngữ lập trình. Tuy nhiên nó không phải là một ngôn ngữ lập trình chính xác cho lắm.

Date: Wed, 10 Jan 90 15:51 CST
From: ram@attcan.uucp
Suject: Re: rm *
Newsgroups: alt.folklore.computers

Tui cũng gặp một thảm hoạ tương tự nhờ dùng rm. Có một lần tui xoá một tập tin khỏi hệ thống, đại loại là /usr/foo/bin. Tui vào /usr/foo và xoá bằng:

% rm -r ./etc
% rm -r ./adm

.. đại loại thế. Nhưng khi làm với ./bin, tui gõ thiếu dấu chấm. Hệ thống của tui không khoái chuyện đó lắm.

Unix không được thiết kế để sống sót sau khi giết chết thư mục /bin của nó. Một hệ điều hành thông minh sẽ cho người dùng cơ hội để phục hồi (hoặc ít ra cảnh báo nếu người dùng thực sự muốn biến hệ thống thành một đống vô dụng).

Dân hâm mộ Unix coi chuyện lỡ tay xoá nhầm tập tin là bình thường. Đoạn trích sau đây từ FAQ của comp.unix.questions là một ví dụ.

6. Làm sao "undelete" tập tin?

Một ngày nào đó, bạn sẽ ngẫu nhiên dùng một lệnh đại loại như:

% rm * .foo

và nhận ra rằng bạn vừa mới xoá * thay vi *.foo`. Cứ xem đó là kinh nghiệm đầu đời.

Dĩ nhiên, bất kỳ quản trị hệ thống đứng đắn nào cũng sẽ tiến hành sao lưu định kỳ. Hãy liên lạc với quản trị hệ thống để lấy bản sao lưu mới nhất cho tập tin của bạn.

"Kinh nghiệm đầu đời"? Không có một ngành công nghiệp mà nhà sản xuất chấp nhận một thái độ phiêu lưu với một sản phẩm hư hỏng như thế.

Thay đổi cách hoạt động của rm không phải là giải pháp

Sau khi bị rm bụp vài lần, việc đặt alias rm là "rm -i" sẽ xuất hiện, thậm chí thay cả lệnh rm bằng một chương trình để chuyển tập tin nên bị xoá vào một thư mục ẩn, như ~/.deleted. Mánh này làm những người dùng ngây thơ không đánh giá đúng về an ninh.

Date: Mon, 16 Apr 90 18:46:33 199
From: Phil Agre <agre@gargoyle.uchicago.edu>
To: UNIX-HATERS
Subject: xoá

Trên hệ thống của tui, "rm" không xoá tập tin mà nó đổi tên một cách khó hiểu để một thứ khác gọi là "undelete" (không phải "unrm" ) có thể lấy lại.

Lệnh này có lẽ hơi khinh suất khi xoá tập tin, vì tui luôn có thể phục hồi chúng. Chà, không. Lệnh Delete File trong Emacs không làm như vậy, lệnh D trong Dired cũng thế. Cái này, dĩ nhiên, là vì giao thức huỷ xoá không phải là một phần của mô hình tập tin của hệ điều hành, đơn giản chỉ là một cái mánh ai đó đã cho vào một lệnh mà hình như tên là "rm".

Kết quả là tui phải tách hai khái niệm ra khỏi đầu mình, "xoá" tập tin và "rm" tập tin. Và phải tự nhắc mình cái nào trong hai cái thực sự xoá khi cái đầu tui kêu tui "xoá nó".

Vài chuyên gia Unix tiếp tục thảo luận với Phil về sự vô lý rất hợp lý của nó và rằng tốt hơn hết không làm cho rm thân thiện hơn dù chỉ một tẹo. Họ tranh luận rằng, trong khi làm cho Unix thân thiện hơn, thêm vào các tiện nghi cơ bản, thì nó ngày càng tệ hơn. Đáng buồn là họ đúng.

Date: Thu, 11 Jan 90 17:17 CST
From: merlyn@iwarp.intel.com (Randal L. Schwartz)
Subject: Đừng có ghi đè lệnh! (từng là Re: rm *)
Newsgroups: alt.folklore.computers

Chúng tôi xin tạm dừng để chuyển cho bạn thông điệp sau...

#ifdef SOAPBOX_MODE

Vui lòng, làm ơn, làm ơn đừng khuyến khích mọi người ghi đè các lệnh chuẩn bằng các lệnh "an toàn".

1. Mọi người sẽ đặt nó vào .cshrc sai chỗ, để rồi script muốn "rm" tập tin sẽ hỏi xác nhận một cách bí ẩn, và/hoặc làm đầy đĩa trong khi họ nghĩ rằng đã xoá tập tin.
2. Không có cách nào để bảo vệ mọi thứ, những thứ có thể bị lỡ tay xoá mất. Và nếu bạn bảo vệ một cái nào đó, người dùng có thể và sẽ cho rằng "mọi thứ đều có thể phục hồi" (dĩ nhiên là không!)
3. Nếu người dùng yêu cầu quản trị hệ thống (là cái thẻ tui đang đeo) yêu cầu giúp đỡ trên terminal của họ, các lệnh sẽ không hoạt động như bình thường, nghĩa là tệ như quỷ khi bạn cần người dùng đó giúp lại bạn và còn bốn công việc khác trong danh sách "khẩn cấp: cần làm NGAY".

Nếu bạn muốn "rm" có xác nhận, dùng:

% alias del rm -i

VÀ ĐỪNG CÓ DÙNG RM! Shhhh. Sao mọi người ngoan cố thế, hở!?!

#endif

Chúng ta quay trở lại cuộc thảo luận "Tôi hack quá lâu mà chỉ có 0, không phải 1 và 0" như dự kiến...

p>. Một hacker hệ thống khác.

Gần đây, có một yêu cầu trên comp.unix.questions hỏi các quản trị hệ thống câu chuyện rùng rợn nhất của họ là gì. Trong vòng 72 giờ, đã có 300 thông điệp. Hầu hết đề cập mất tập tin theo các cách đã mô tả trong đây. Điều buồn cười là, họ là những người dùng Unix kinh nghiệm, những người hiểu rõ hơn. Thậm chí lạ lùng hơn, cho dù nhiều triệu đô la phá huỷ đã được thông báo trong nhưng thông điệp này, hầu hết những quản trị tương tự đều bảo vệ Unix khi bị tấn công bởi tính "không thân thiện người dùng".

Không thân thiện người dùng? Unix thậm chí "không thân thiện quản trị hệ thống"! Ví dụ:

Date: Wed, 14 Sep 88 01:39 EDT
From: Matthew P Wiener <weemba@garnet.berkeley.edu>
To: RISKS-LIST@kl.sri.com
Subject: Re: "Chỉ một phím"

Trên Unix, ngay cả người dùng giàu kinh nghiệm cũng có thể phá hoại nhờ "rm". Tui chưa bao giờ nghĩ đến việc viết một script rm an toàn vì tui sẽ không xoá lầm. Rồi một ngày nọ, tui gặp vận rủi khi gõ "!r" để lặp lại lệnh từ history list. Thế là rm -r * hiện lên một cách kinh dị trên màn hình của tui, cái lệnh tui đã dùng ở một thư mục khác để dọn dẹp thư mục.

Có lẽ C shell nên dùng tuỳ chọn nohistclobber? Đó là lần duy nhất tui lỡ tay rm hoặc khi đè bất kỳ tập tin nào.

Ngẫu nhiên, một ngày nọ tui nghe một câu chuyện kinh dị của một người dùng ngây thơ chạy rm * để xoá tập tin * đã lỡ tạo ra bằng mail. May cho anh ta, những tập tin bắt đầu bằng những ký tự sau không có quyền ghi, nên lệnh này dừng nhanh chóng.

Không thống nhất một cách thống nhất

Các lệnh có thể đoán được thường dùng các tuỳ chọn giống nhau, dùng đối số tạm gọi cùng thứ tự, và nếu có thể thì cho kết quả giống nhau. Tính thống nhất yêu cầu nỗ lực vào vài phần trung tâm, hình thành chuẩn. Các ứng dụng của Macintosh thống nhất là vì chúng tuân theo sách hướng dẫn của Apple. Không có một phần nào giống như vậy trong các tiện ích Unix. Kết quả là, vài tiện ích bắt đầu tuỳ chọn bằng dấu gạch ngang, vài cái lại không. Vài cái đọc từ standard input, vài cái không. Vài cái ghi ra standard output, vài cái không. Vài cái tạo tập tin dạng world writable, vài cái không. Vài cái báo lỗi, vài cái không. Vài cái đặt khoảng trắng giữa tuỳ chọn và tên tập tin, vài cái không.

Unix là một thử nghiệm để tạo nên một hệ điều hành đơn giản và gọn đẹp hết mức có thể. Nếu coi là một thử nghiệm, nó hoạt động. Nhưng nếu coi là một hệ thống nghiêm túc thì các kỹ sư AT&T đã nói quá về mục tiêu của mình. Để có thể sử dụng được bởi một lượng người đủ lớn, hệ điều hành phải đa năng. Nếu phần cốt lõi của nó không đủ đa năng, người dùng sẽ ghép thêm tính năng vào phần khung nền tảng. Vấn đề thật sự của tính thống nhất và có thể dự đoán, theo đề nghị của Dave Mankins, là Unix không cung cấp cho lập trình viên ngoài AT&T sự hỗ trợ để thực hiện các mở rộng này.

Date: Sat, 04 Mar 89 19:25:58 EST
From: dm@think.com
To: UNIX-HATERS
Subject: Các chú lùn Unix và trò chơi của họ

Các chú lùn Unix thích chơi với sự đơn giản về mặt khái niệm của các lệnh. Cái hầu hết mọi người nghĩ là một tính năng, các chú lùn Unix bao lại thành nguyên một lệnh, với cú pháp đối số và tuỳ chọn riêng.

Cũng không phải là ý tưởng tệ lắm, vì khi không có bất kỳ trình thông dịch nào khác, ai cũng có thể viết một chương trình mạnh bằng cách nối các tính năng này lại với nhau.

Tuy nhiên hơi tệ khi không có ai biến nó thành một hàm thực sự để có thể liên kết với chương trình tự viết, thay vì phải viết bộ phân tích biểu thức chính quy của riêng bạn (cái mà ed, sed, grep và shell đều có, nhưng có chút khác biệt về cách hiểu biểu thức chính quy của từng cái).

Thành tựu lớn nhất về thẩm mĩ của Unix là có một lệnh thực hiện chính xác một tính năng, và làm tốt. Lệnh thuần khiết nhất, "cat", dùng để nối các tập tin và xuất ra output của nó, giờ lại có TUỲ CHỌN.

Triết lý, trong tay của dân a-ma-tơ, dẫn đến những chấp vá lạnh đầu, như sự tồn tại của của hai chương trình, "head" và "tail", trên nguyên tắc là in phần đầu và cuối tập tin, tuỳ chương trình. Cho dù thao tác của hai chương trình là như nhau, "head" và "tail" là hai chương trình khác nhau, của hai tác giả khác nhau, nhận hai tập tuỳ chọn khác nhau!

Nếu chỉ tồn tại duy nhất luật nhiệt động lực học, thì Unix cũng thiếu thống nhất và cùng entropy với những hệ thống khác phát triển qua thời gian, không tốt hơn cũng chả tệ hơn. Tuy nhiên, các khiếm khuyết trong kiến trúc đã giúp tăng độ hỗn loạn và các yếu tố sững sờ. Đặc biệt, các chương trình không được phép xem dòng lệnh dùng để gọi nó, có ngày nó tự thiêu. Shell hoạt động như một lớp trung gian giúp thanh lọc và tổng hợp dòng lệnh cho một chương trình từ những gì người dùng gõ vào. Không may là shell giống như Thanh tra Clouseau hơn Florence Nightingale.

Chúng ta đã đề cập việc shell xử lý wildcard, rằng nó thay thế dấu sao (*) bằng danh sách tập tin trong thư mục. Đây là sai lầm thứ nhất; chương trình nên gọi một thư viện xử lý wildcard. Theo quy ước, chương trình chấp nhận các tuỳ chọn của nó là đối số đầu tiên của nó ngay sau dấu dấu gạch ngang kép (--). Đây là sai lầm thứ hai. Tuỳ chọn và các đối số khác nên là các thực thể tách biệt, như trên VMS, DOS, Genera và nhiều hệ thống khác. Cuối cùng, tên tập tin Unix có thể chứ gần hết các ký tự, bao gồm cả những thứ không thể nhìn được. Đây là sai lầm thứ ba. Những đặc điểm kiến trúc này trộn lẫn với nhau một cách tồi tệ. Shell liệt kê danh sách tập tin theo thứ tự bảng chữ cái khi bung "*". Mà dấu gạch ngang (-) lại nằm đầu bảng. Vậy nên, tập tin bắt đầu bằng dấu gạch ngang (-) sẽ đứng trước khi bung "*". Những tập tin này trở thành tuỳ chọn cho chương trình được gọi, dẫn đến những hành vi không lường trước, sững sờ và nguy hiểm.

Date: Wed, 10 Jan 90 10:40 CST
From: kgg@lfcs.ed.ac.uk (Kees Goossens)
Subject: Re: rm *
Newsgroups: alt.folklore.computers

Thì đây là câu chuyện của một sinh viên đáng thương đã lỡ tạo một tập tin trên "-r" trong thư mục home của mình. Anh ta muốn xoá mọi tập tin không phải thư mục (tui đoán vậy) nên gõ:

% rm *

... và vâng, nó xoá mọi thứ trừ tập tin "-r" đáng yêu... May mắn là hệ thống sao lưu khá tốt.

Vài nạn nhân Unix biến lỗi tập-tin-trở-thành-tuỳ-chọn này thành "tính năng" bằng cách tạo tập tin "-i" trong các thư mục. Nhờ đó khi gõ "rm **" thì shell sẽ biến nó thành "rm -idanh sách tập tin" và, dĩ nhiên, sẽ hỏi xác nhận xoá tập tin. Không phải một giải pháp tồi, chừng nào bạn vẫn chưa quên đặt tập tin "-i*" vào từng thư mục một. Có lẽ nên đổi mkdir để nó tạo luôn tập tin "-i" mỗi khi tạo thư mục. Ờ và sau đó cũng nên đổi luôn ls để nó đừng hiện tập tin kỳ cục này.

Những tên tập tin không tin được

Chúng tôi có biết vài người gõ nhầm khi đổi tên tập tin, dẫn đến tập tin bắt đầu bằng gạch ngang:

% mv file1 -file2

Giờ hãy thử đổi ngược lại:

% mv -file2 file1

usage: mv [-if] f1 f2 or mv [-if] f1 ... fn d1
(‘fn’ is a file or directory)
%

Tập tin không gây vấn đề với các lệnh Unix vì có một chút thống nhất giữa các lệnh Unix với nhau. Ví dụ, tập tin "-file2" là kosher của "trình soạn thảo văn bản chuẩn", ed. Ví dụ này hoạt động tốt:

% ed -file2
4347

Nhưng ngay cả khi bạn lưu tập tin dưới tên khác, hoặc quyết định bỏ cuộc hoàn toàn và không muốn gì hơn là xoá quách nó đi, bạn sẽ lâm vào tình thế như vầy:

% rm -file
usage: rm [-rif] file ...
% rm ?file
usage: rm [-rif] file ...
% rm ?????
usage: rm [-rif] file ...
% rm *file2
usage: rm [-rif] file ...
%

rm hiểu ký tự đầu tiên (dấu gạch ngang) là tuỳ chọn dòng lệnh, nên nó diễn dịch ký tự "l" và "e" cũng là tuỳ chọn hợp lệ. Nó hơi điên một chút khi tập tin bắt đầu bằng gạch ngang, đặc biệt là gạch ngang - kết quả của wildcard, đối xử nó như danh sách tuy chọn, nhỉ?

Unix cung cấp một số giải pháp tình thế để tránh những tập tin dễ gây lỗi trên:

% rm - -file

và

% rm ./-file

Trang man cho rm nói rằng dấu gạch ngang đơn giữa rm và tên tập tin đầu tiên cho rm biết coi mọi dấu gạch ngang cũng là tên tập tin, không phải tuỳ chọn. Vì vài lý do chưa rõ, cách dùng của cả rm và người anh em mv của nó không có liệt kê "tính năng" này.

Dĩ nhiên, dùng nhiều dấu gạch để nói "hãy bỏ qua tất cả các dấu gạch theo sau" không phải là quy ước quốc tế, vì mỗi lệnh tự phân tích đối số của nó chứ không nhờ một thư viện chung. Chương trình như tar hiểu dấu gạch là standard input và standard output. Những chương trình khác thì không thèm quan tâm dấu gạch:

% touch -file
touch: bad option -i
% touch - -file
touch: bad option -i

Làm vui lòng bạn. Làm tan hoang kẻ thù!

Thông thường, lệnh Unix sẽ trả về kết quả có vẻ như hợp tình hợp lý: nó chỉ thế nếu bạn nhận ra rằng nó thật sự bất hợp lý như thế nào:

next% mkdir foo
next% ls -Fd foo
foo/
next% rm foo/
rm: foo/ directory
next% rmdir foo/
rmdir: foo/: File exists

Đây là cách để làm vui lòng bạn bè bạn. Trước hết, một bí mật lớn, hãy làm theo sau:

% mkdir foo
% touch foo/foo~

Sau đó chỉ cho nạn nhân của bạn xem kết quả của thần chú vừa rồi:

% ls foo*
foo~
% rm foo~
rm: foo~ nonexistent
% rm foo*
rm: foo directory
% ls foo*
foo~
%

Để kết thúc vui vẻ, thử lệnh này:

% cat - - -

(Gợi ý: nhấn Ctrl-D ba lần để trở về với dấu nhắc!)

Tài liệu trực tuyến

Mọi người bầu cho tổng thống thường xuyên hơn họ đọc tài liệu bằng giấy. Loại tài liệu duy nhất đáng để tâm là những thứ trên mạng, có thể dùng sau một phím nhấn hoặc một cái nhấp chuột. Tình trạng tài liệu của Unix, và khoảng tài liệu mà lẽ ra phải có, đã giúp nó dành được một phần riêng trong quyển sách này. Vậy hãy dành chỗ để nói về việc hệ thống man của Unix thất bại ở nơi cần nó nhất: những người mới.

Không phải mọi lệnh đều như nhau: vài chương trình được gọi từ shell, vài cái khác là lệnh nội của shell (nói cách khác, một phần của shell). Vài lệnh có trang man của riêng nó. Vài lệnh không. Unix kỳ vọng bạn sẽ phân biết được cái nào là cái nào. Ví dụ, wc, cp và ls là chương trình ngoài shell, có trang man. Nhưng fg, jobs, set và alias (mèn ơi, cái tên này từ đâu ra?) là ví dụ của những lệnh của chính shell và do đó không có trang man riêng.

Người mới được bảo dùng "man lệnh" để đọc tài liệu về lệnh sẽ mau chóng rối loạn khi vài lệnh có tài liệu còn số khác thì không. Và nếu người đó sử dụng một shell khác với shell được mô tả trong tài liệu (nào đó) thì không còn hi vọng le lói nào nữa nếu không có sự chỉ dẫn của một guru.

Thông báo lỗi và kiểm tra lỗi, KHÔNG!

Người dùng mới luôn gặp lỗi, dùng lệnh sai, hoặc dùng lệnh đúng nhưng tham số sai. Hệ thống phải nhận ra những lỗi này và thông báo cho người dùng. Xui xẻo là, các chương trình Unix hiếm khi quan tâm đến điều đó. Ngược lại, Unix dường làm theo cách riêng, tổ hợp các lỗi lại với nhau để có được những kết quả đứng tim.

Trong phần cuối trước, chúng tôi đã cho thấy xoá nhầm một tập tin bằng rm dễ thế nào. Nhưng bạn có lẽ không đánh giá đúng độ dễ dàng để xoá nhầm tập tin, thậm chí không cần dùng lệnh rm.

Để xoá tập tin, thử dùng trình biên dịch

Vài phiên bản của cc thường bụp những người chưa hoàn tất khoá đào tạo bằng cách xoá tập tin đầu ra trước khi kiểm tra lỗi đầu vào.

Date: Thu, 26 Nov 1992 16:01:55 GMT
From: tk@dcs.ed.ac.uk (Tommy Kelly)
Subject: CỨU!
Newsgroups: cs.questions9
Organization: Lab for the Foundations of Computer Science, Edinburgh UK

Tui chỉ gõ:

% cc -o doit.c doit

thay vì:

% cc -o doit doit.c

Khỏi phải bàn là tui mất doit.c.

Có cách nào để phục hồi lại không? (Nó bị thay đổi tùm lum hết hồi sáng này).

:-(

Những chương trình khác cũng có hành vi tương tự:

From: Daniel Weise <daniel@dolores.stanford.edu>
To: UNIX-HATERS
Date: Thu, 1 July 1993 09:10:50 -0700
Subject: tarred and feathered

Vậy là, sau vài lần thử, cuối cùng tui cũng có thể lấy được tập tin 3.2MB bằng ftp qua một đường truyền mưa gió từ châu Âu. Đến lúc để bung nó ra.

Tui gõ:

% tar -cf thesis.tar

... và không nó không trả lời trả vốn gì cả.
Hic.

Có phải là "c" mà không phải "x"?
Đúng

tar có đưa thông báo lỗi vì không xác định tập tin?
Không

tar thậm chí không thông báo vấn đề gì hết?
Đúng

Có phải tar không nén tập tin nào hết?
Đúng

tar có ghi đè tập tin tar với một mớ rác rưởi gì đó không?
Dĩ nhiên. Unix mà.

Vậy tui có cần tốn thêm 30 phút nữa để lấy tập tin mới từ châu Âu lần nữa không?
Dĩ nhiên. Unix mà.

Tuyệt trần. Tui đảm bảo những cái phi-tính năng này đã tác động đến nhiều người. Có quá nhiều cách đơn giản để tránh mất mát: thông báo lỗi, số phiên bản tập tin, kiểm tra lại để bảo đảm người dùng không có ý định ghi đè tập tin... Giống như họ đã phải cố gắng thật nhiều để có thể gây ra những mất mát kiểu thế này.

Lỗi này gây ảnh hưởng đặc biệt với những quản trị hệ thống dùng tar để sao lưu hệ thống. Một quản trị nào đó đã gõ "tar xf ..." vào script sao lưu thay vì phải gõ "tar cf ...".

Ờ đúng đó là lỗi. Băng quay vòng. Ít có quản trị nào nghi rằng tar đang đọc tập tin từ băng từ thay vì phải ghi vào đó. Thực ra, nó có vẻ như chạy đúng bài bản cho đến khi người ta cần phục hồi một tập tin. Rồi ngạc nhiên xuất hiện: băng sao lưu chả sau lưu cái gì cả.

Nhờ thiếu hoặc không kiểm tra lỗi, một lượng lớn các "công cụ của lập trình viên" đã trao cho người dùng chuyên nghiệp vô vàn cơ hội để đánh mất các thông tin quan trọng.

Date: Sun, 4 Oct 1992 00:21:49 PDT
From: Pavel Curtis <pavel@parc.xerox.com>
To: UNIX-HATERS
Subject: So many bastards to choose from…

Tui có một chương trình, cứ gọi là foo, chạy liên tục trên máy, cung cấp các dịch vụ mạng và kiểm tra trạng thái nội tại định kỳ 24 giờ.

Tui cd vào thư mục chứa phiên bản của chương trình. Và vì đây không phải là thư mục phát triển chương trình, tui cũng tò mò muốn biết đang chạy phiên bản nào. Mã nguồn của nó được quản lý bằng RCS, nên theo bình thường, tui định gõ: % ident foo để xem phiên bản của tập tin mã nguồn chứa trong chương trình. (Đừng để ý RCS rõ ràng không phải là thứ dùng chung với "ident". Tui có một con cá to hơn để đập đây...)

Dĩ nhiên là tui gõ nhầm vì mấy ngón tay tui tự động gõ từ "indent" vì nó khoái từ đó hơn "ident" :

% indent foo

Đến đây, phải nói rằng "indent" là tên một chương trình điên khùng của UNIX để làm đẹp các bản in cho C. Cái thằng khỉ đã viết chương trình này không biết có chịu quan tâm kiểm tra xem đầu vào có thực sự là một tập tin C (hay, mô phật, kiểm tra xem nó kết thúc bằng ".c" ) hay không? Tui nghĩ bạn biết câu trả lời rồi. Tệ hơn nữa, thằng khỉ đó quyết định rằng nếu chỉ có một đối số duy nhất để canh hàng thì bạn phải nghĩ rằng mã nguồn sẽ được làm đẹp tại chỗ, ghi đè nội dung tập tin cũ. Nhưng đừng quá lo lắng, thằng khỉ đó biết bạn lo lắng về hư hại nó có thể gây ra. Thế nên nó bảo đảm lưu lại một bản sao nội dung cũ của bạn trong tập tin foo.BAK. Có thật nó chỉ đơn giản đổi tên foo thành foo.BAK? Dĩ nhiên là không rồi. Phải chép từng bit một của foo sang foo.BAK, rồi cắt tập tin foo. Thế mới tốt hơn nhiều so với ghi ra tập tin mới bản đã được làm đẹp. Đồ khỉ gió!

Chắc bạn đã có thể hiểu câu chuyện từ giờ...

Rồi. Vậy là khi chương trình Unix chạy và sử dụng nội dung tập tin chương trình của nó, rất là nhức đầu nếu bạn quậy lung tung với mấy cái bit trong tập tin của nó. Đặc biệt, nó trở nên khoái sụp và không có mấy hi vọng phục hồi lại. Tui mất đứt 20 tiếng đồng hồ để chương trình thay đổi trạng thái.

Đương nhiên, đội khỉ, những người đã (ắt xì) thiết kế ra Unix không để thích độ phức tạp của của một hệ tập tin đa phiên bản, mà lẽ ra đã có thể cứu tui. Và những thằng khỉ đó cũng không tưởng tượng ra phải khoá tập tin khi đang đọc nó, phải không?

Thì có thể chọn một trong nhiều thằng khỉ. Tại sao không giết hết chúng đi nhỉ?

p>. Pavel

Tưởng tượng, nếu sơn tường phát khí chlor khi khô. Nếu dùng ở ngoài trời thì không sao, tuỳ hướng. Nhưng nếu dùng để sơn trong phòng ngủ thì bạn có thể tiêu tùng. Bạn nghĩ loại sơn đó có thể tồn tại bao lâu trên thị trường? Chắc chắn không đến 20 năm rồi.

Chuyện tếu về lỗi

Bạn có cười khi người bồi bàn làm rớt một khay đầy đĩa không? Mấy thằng mê Unix thì có đấy. Chúng là những người đầu tiên cười những người dùng không may, cố hiểu tại sao thông báo lỗi lại không có liên quan gì đến những gì mình gõ vào.

Nhiều người công bố những thông báo lỗi buồn cười của Unix, coi như trò đùa. Những câu sau được phân tán trên Usenet, không có một tác giả cụ thể. Chúng chạy với C shell.

% rm meese-ethics
rm: meese-ethics nonexistent
% ar m God
ar: God does not exist
% "How would you rate Dan Quayle's incompetence?
Unmatched ".
% ^How did the sex change^ operation go?
Modifier failed.
% If I had a ( for every $ the Congress spent,
what would I have?
Too many ('s.
% make love
Make: Don't know how to make love. Stop.
% sleep with me
bad character
% got a light?
No match.
% man: why did you get a divorce?
man:: Too many arguments.
% ^What is saccharine?
Bad substitute.
% %blow
%blow: No such job.

Còn đây là những trò cười với Bourn shell:

$ PATH=pretending! /usr/ucb/which sense
no sense in pretending!
$ drink <bottle; opener
bottle: cannot open
opener: not found
$ mkdir matter; cat >matter
matter: cannot create

Quan điểm Unix

Sau những phần trên, ta có được một bức tranh khá ảm đạm: những tên lệnh bí ẩn mù mờ, hành vi không thống nhất và khó dự đoán, không được bảo vệ trước những lệnh nguy hiểm, tài liệu trực tuyến khó có thể chấp nhận được và sự yếu kém trong kiểm tra lỗi. Những ai ghé thăm Ngôi nhà của Unix không phải để chữa trị. Họ là khách ... FIXME

Triết lý Unix không phải là một lời khuyên bằng văn bản đến từ Bell Labs hoặc Unix Systems Laboratory. Nó là một thứ nguyên tắc không thành văn. Nhiều tác giả khác nhau nêu lên những mặt khác nhau của nó. Life with Unix của Don Libes và Sandy Ressler (Prentice Hall, 1989) làm được một tổng kết rất tốt:

• Nhỏ là đẹp
• 10 phần trăm công sức giải quyết 90 phần trăm vấn đề
• Khi đối mặt với chọn lựa, lựa bất cứ cái nào đơn giản hơn

Theo những bằng chứng kinh nghiệm của những chương trình và tiện ích Unix, một tóm tắt chính xác hơn về Triết lý Unix là:

• Thích chương trình nhỏ hơn một chương trình hoạt động được hoặc hoạt động đúng.
• Một công việc không có giá trị là hoàn toàn có thể chấp nhận được.
• Khi đối mặt với lựa chọn, báo cảnh sát

Unix không có triết lý: nó là quan điểm. Một quan điểm hết sức đơn giản, công việc xong phân nửa thì dễ thương hơn một công việc phức tạp, hoàn thành tốt. Một quan điểm tuyên bố thời gian của lập trình viên quan trọng hơn thời gian của người sử dụng, thậm chí là hàng ngàn người dùng trên một lập trình viên. Đó là quan điểm ca người thiểu số.

Date: Sun, 24 Dec 89 19:01:36 EST
From: David Chapman <zvona@ai..mit.edu>
To: UNIX-HATERS
Subject: killing jobs; the Unix design paradigm.

Gần đây tôi học cách giết một job trong Linux. Lúc đó tui học được rất nhiều thứ về sự thông thái và sức mạnh của Unix. Và tui nghĩ tui sẽ chia sẻ nó ở đây.

Hầu hết các bạn, dĩ nhiên, không dùng Unix. Vậy biết cách giết một job cũng không hữu dụng lắm. Tuy nhiên, một số trong các bạn, như tui, có thể có dịp chạy TeX job định kỳ trên đó, và biết cách giết job là sống còn. Dù gì thì gì, nguyên lý thiết kế của lệnh "kill" được áp dụng hết sức chặt chẽ cho toàn bộ Unix, vậy nói chung biết cũng hữu dụng.

Hầu hết hệ điều hành có lệnh "kill". Vậy Unix cũng có. Trong hầu hết hệ điều hành, lệnh kill sẽ giết một tiến trình. Unix còn hơn thế: lệnh "kill" gửi một thông báo đến tiến trình. Nó minh hoạ nguyên tắc thiết kế thứ nhất của Unix:

• Đưa cho người dùng sức mạnh bằng cách làm cho các thao tác tổng quát

Lệnh kill rất mạnh; nó cho phép bạn gửi mọi thứ thông điệp đến tiến trình. Ví dụ, một thông điệp được dùng để giết chính tiến trình đó. Thông điệp này là -9. -9, dĩ nhiên là một thông điệp số có dấu, minh hoạ một nguyên tắc cơ bản khác trong thiết kế Unix:

• Chọn tên đơn giản để phản ánh tính năng

Trong mọi hệ điều hành mà tui biết, lệnh kill không tham số sẽ kill job hiện thời. Tuy nhiên, lệnh kill của Unix luôn cần đối số job. Chọn thiết kế không ngoan này minh hoạ nguyên tắc thiết kế khôn ngoan khác:

• Tránh trường hợp người dùng lỡ tay phá hỏng mọi thứ bởi những lệnh dài hoặc những xác nhận thao tác nguy hiểm

Có vô số ứng dụng dùng nguyên tắc này trong Unix và được ghi tài liệu cẩn thận, vậy không cần đề cập ở đây.

Trong mọi hệ điều hành tui biết, đối số job của lệnh kill là tên job. Đây là giao diện không thích hợp, vì bạn có thể có nhiều LaTeX job có cùng tên "latex". Vậy "kill -9 latex" sẽ trở nên nhập nhằng.

Như hầu hết mọi hệ điều hành, Unix có lệnh để liệt kê job, tên là "jobs". Kết quả giống như sau:

zvona@rice-chex\> jobs
[1] - Stopped    latex
[2] - Stopped    latex
[3] + Stopped    latex

Nó cho phép bạn gắn một số với một LaTeX job, hiển thị trong ngoặc vuông.

Nếu suy nghĩ của bạn bị ảnh hưởng bởi những hề điều hành ít-nghĩ-chu-đáo hơn, bạn có thể nghĩ rằng "kill -0 1" sẽ giết job 1 trong danh sách. Tuy nhiên bạn sẽ nhận ra rằng nó sẽ cho thông báo đại loại như vầy:

zvona@rice-chex\> kill -9 1
1: not owner

Đối số bên phải của kill là mã tiến trình. Mã tiến trình là một con số như 18517. Bạn tìm mã tiến trình bằng lệnh "ps". Khi đã có mã tiến trình, bạn chỉ cần:

zvona@rice-chex\> kill -9 18517
zvona@rice-chex\>
[1] Killed latex

Chú ý Unix cho bạn dấu nhắc trước khi cho bạn biết job bị giết. (Những gì người dùng nhập vào xuất hiện sau dòng "[1]"). Nó minh hoạ một nguyên tắc khác:

• Không cho người dùng biết nhiều hơn những gì họ cần biết, không sớm hơn lúc họ cần biết. Đừng làm tiêu tan khả năng tiếp thu của họ với thông tin thừa

Tui hi vọng bài thực hành nhỏ này là chỉ dẫn tốt cho bạn. Tui chắc chắn sẽ chạy xa khỏi kinh nghiệm của tui về những nguyên tắc thiết kế Unix hết sức ấn tượng. Sự lịch lãm, sức mạnh và tính đơn giản của lệnh kill trong Unix cung cấp một bài học cho tất cả chúng ta.

Những ai xài trên hai cái shell cùng lúc (đặc biệt là những người dùng screen) thường khó chịu vì bash ghi đè ~/.bash_history thay vì nối thêm vào. Mà thực ra giải pháp cũng đơn giản, thêm một dòng vào ~/.bashrc

shopt -s histappend

dev.gentoo.org nổi hứng chuyển DefaultIndex, ưu tiên cho index.xml trước cả index.html. nanoblogger tạo cả hai tập tin nên hậu quả là khi gõ http://dev.gentoo.org/~pclouds/blog thì nó dùng index.xml thay vì index.html. Cách giải quyết khá đơn giản, tạo tập tin .htaccess với nội dung sau:

DirectoryIndex index.html

Trăm nghe không bằng một thấy:

     Sun Jul  9 21:20:51 2006 >>> media-video/mplayer-1.0_pre8
       merge time: 18 minutes and 25 seconds.

     Sun Jul  9 21:30:33 2006 >>> media-video/mplayer-1.0_pre8
       merge time: 4 minutes and 24 seconds.

Heard Finally Free. There are probably nine months ahead. When will I go free? Desperated and exhausted. Life is just plain crap.

WHEN???

Thực hiện lệnh sau, nếu tên tập tin có khoảng trắng thì xargs chết tươi

find -type d|xargs chmod 777

Có điều lỗi không phải tại xargs. Lỗi (luôn luôn?) là lỗi người dùng, tại người dùng không chịu đọc (man page)

Because Unix filenames can contain blanks and newlines, this default behaviour is often problematic; filenames containing blanks and/or new- lines are incorrectly processed by xargs. In these situations it is better to use the `-0' option, which prevents such problems. When using this option you will need to ensure that the program which pro- duces the input for xargs also uses a null character as a separator. If that program is GNU find for example, the `-print0' option does this for you.

Vậy lẽ ra lệnh trên phải viết như sau:

find -type d -print0|xargs -0 chmod 777

Sleeping Sun của Nightwish (đang đứng đầu bảng xếp hạng) có khả năng sẽ phải cạnh tranh với một đối thủ mới: Forever Shine On của Edenbridge :D

Gặm một khối căm hờn trong cũi sắt,
Ta nằm dài, trông ngày tháng dần qua.
Khinh lũ người kia ngạo mạn, ngẩn ngơ
Giương mắt bé diễu oai linh rừng thẳm
Nay sa cơ, bị nhục nhằn tù hãm
Để làm trò lạ mắt, thứ đồ chơi.
Chịu ngang bầy cùng bọn gấu dở hơi,
Với cặp báo chuồng bên vô tư lự.

Ta sống mãi trong tình thương nỗi nhớ,
Thuở tung hoàng, hống hách những ngày xưa.
Nhớ cảnh sơn lâm, bóng cả, cây già,
Với tiếng gió gào ngàn, với giọng nguồn hét núi,
Với khi thét khúc trường ca dữ dội
Ta bước chân lên, dõng dạc, đường hoàng,
Lượn tấm thân như sóng cuộn nhịp nhàng,
Vờn bóng âm thầm, lá gai, cỏ sắc.
Trong hang tối, mắc thần khi đẵ quắc
Là khiến cho mọi vật đều im hơi.
Ta biết ta chúa tể của muôn loài
Giữa chốn hào hoa, không tên không tuổi.

Nào đâu những đêm vàng bên bờ suối,
Ta say mồi đứng uống ánh trăng tan?
Đâu những ngày mưa chuyển bốn phương ngàn,
Ta lặng ngắm giang san ta đổi mới?
Đâu những bình minh cây xanh nắng gội,
Tiếng chim ca giấc ngủ ta tưng bừng?
Đâu những chiều lênh láng máu sau rừng
Ta đợi chết mảnh mặt trời gay gắt
Để ta chiếm lấy riêng phần bí mật?
Than ôi! Thời oanh liệt nay còn đâu?

Nay ta ôm niềm uất hận ngàn thâu
Ghét những cảnh không đời nào thay đổi,
Nhữnh cảnh sửa sang, tầm thường, giả dối:
Hoa chăm, cỏ xén, lối phẳng, cây trồng;
Giải nước đen giả suối, chẳng thông dòng
Len dưới nách những mô gò thấp kém;
Dăm vừng lá hiền lành không bí hiểm
Cũng học đòi bắt chước vẻ hoang vu
Của chốn ngàn năm cao cả, âm u.

Hỡi oai linh, cảnh nước non hùng vĩ!
Là nơi giống hùm thiêng ta ngự trị,
Nơi thênh thang ta vùng vẫy ngày xưa
Nơi ta không còn được thấy nữa bao giờ!
Có biết chăng trong những ngày ngao ngán
Ta đang theo giấc mộng ngàn to lớn
Để hồn ta phảng phất được gần ngươi
Hỡi cảnh rừng ghê gớm của ta ơi!

Lời bình: Xem ra con hổ này còn xui xẻo hơn cả mình. Tội nghiệp.

Chạy lệnh kiểm tra lỗi gần 2000 tập tin .po với tổng kích thước hơn 60MB không vui tí nào. Mất 5-10 phút cho mỗi lần kiểm tra. Cần một cái máy xịn hơn mới được. Không biết có ai sẵn lòng "tài trợ" một cái PC xịn để .. bắt lỗi chính tả không ta. Kakaka

Mấy cái album mới.. lấy về của Blackmore's Night có tác động rõ rệt. Rốt cuộc Blackmore's Night cũng đã thoát khỏi vị trí số 5 (chắc cũng cỡ mấy tháng trời) để nhảy lên số .. 4! :D

Tuần sau mà móc được The Silent Force Tour, chắc Blackmore's Night lại về với vị trí cũ, nhường số 4 lại cho Within Temptation.

Đừng tưởng mở thì muốn dòm gì là dòm nghen!

:D

Giờ đây Adobe dùng blog để thiết lập kênh liên lạc giữa đội phát triển Adobe Flash Player 9 với cộng đồng Linux