Lý sự pclouds

Freud chia tâm trí thành ba phần: phần ego (mày), phần superego (thế giới chung quanh mày) và phần id (thú, hay nói lịch sự hơn là phần "sinh học"). Ta chỉ có thể nhận thức được chút đỉnh của ba phần này, nhiều nhất là phần ego và ít nhất là phần id.

Nhu cầu của superego và id khác nhau. Đến lúc nào đó hai phần này xung đột nhau (anxiety, bao gồm realistic anxiety, moral anxiety và neurotic anxiety). Phần ego cố gắng giải quyết xung đột giữa superego (bao gồm conscience và ego ideal) với id. Nói đúng hơn là ego phản ứng lại với xung đột đó chứ không hẳn là "giải quyết". Có nhiều cách phản ứng khác nhau như denial, repression, asceticism, isolation, displacement, turning against the self, projection, altruistic surrender, reaction formation, undoing, introjection, identification with aggressor, regression, rationalization và sublimation. Cần giành nhiều thời gian hơn để tìm hiểu từng cái một.

Freud coi trọng "sex drive" (không chỉ đơn giản là tình dục). Ông chia đời người thành nhiều giai đoạn, xét về mặt "sex drive": oral stage, anal stage, phallic stage, latent stage, genital stage. Oedipal crisis dùng để giải thích cho phallic stage không thật sự thuyết phục.

Cách điều trị, theo quan điểm của Freud là "make the unconscious conscious".

Phần ego đơn giản hoạt động theo nguyên tắc thực tế, "take care of a need as soon as an appropriate object is found". Có thể đây là lý do mọi người thiên về các hoạt động ngắn hạn, đem lại hiệu quả nhanh bất kể nó sẽ ra sao nếu tính dài hạn.

Phần superego không được nói nhiều. Cần tìm hiểu thêm.

Về phần id. Phần id đại diện cho các nhu cầu của cơ thể. Nó hoạt động dựa trên "nguyên tắc sung sướng" (hay nói cách khác, "sex drive" hoặc libido). Điều khó hiểu là ngoài life instinct còn có death instinct, "unconscious wish to die", "nirvana principle". Vấn đề là khi nào thì death instinct tác động, lúc nào life instinct tác động. Death instinct thể hiện mong muốn sự yên bình, tránh bị kích thích, sự thèm muốn rượu chè hoặc thuốc gây mê...

Tài liệu tham khảo:

• http://webspace.ship.edu/cgboer/freud.html

Số lượng các tổ chức tham gia SoC năm nay đông hơn nhiều so với năm ngoái. Đọc oải quá.

Năm nay Git cũng tham gia với 3 dự án thuộc “tổ chức” Git và 1 dự án thuộc tổ chức Mono:

• GIT library (mở đường cho việc tích hợp GIT vào các ứng dụng khác)
• "C hoá" Git (dễ dàng hơn trong việc chuyển sang Windows)
• Gittorrent, một giao thức tựa tựa như BitTorrent để phân phối Git repository. Chưa coi đặc tả của giao thức này. Nhưng dựa trên mô tả thì giao thức này sẽ giúp ít nhiều khi sao chép toàn bộ repository ("clone"): giảm tải CPU cũng như băng thông mạng cho server.
• Viết lại Git bằng C#. Nếu dự án này thành công, Git sẽ tồn tại với ba phiên bản: bản gốc bằng C (và một số ngôn ngữ khác), bản Java (EGit) và bản .NET.

Gentoo SoC năm nay không có gì hấp dẫn ngoại trừ Collective Maintenance

GNOME SoC có một số như:

• New geometry manager for GTK+ (không còn dùng GTK+ nhiều nên cũng không quan tâm lắm)
• Brave New X11 World (plug and play cho GNOME)
• Integrating Epiphany Bookmarks and Browsing History For GNOME-wide Access
• Simple user-to-user file transfer without configuration in a LAN
• GDM Composited Bling hay GDM màu mè

Mono SoC cũng có vài cái hay:

• Windows.Forms.Designer (không xài nhưng khoái)
• MonoDevelop Debugger
• Adding C/C++ support in MonoDevelop

Pidgin (GAIM) cũng có:

• Telepathy support for Gaim (mặc dù chưa rờ đến cọng lông nào của Telepathy cả)
• Gaim-Text Improvements (quá dễ hiểu. Gaim-text mới chạy một lần là đã bỏ chạy mất dép)
• Vẫn không có video support? To quá chăng? :(

Ruby Central, Inc. cũng có một mớ, nhưng làm biếng coi quá. Ubuntu cũng có tùm lum thứ nhưng cũng như Ruby, làm biếng quá. Không hề có hứng thú gì với Mozilla, PHP cũng như MySQL AB.

Một số dự án lẻ tẻ khác:

• Abiword có Implement annotations
• Một loạt dự án cho LinuxBIOS
• An upstream-friendly l10n Web UI for Fedora
• Designing an educational microprocessor and led display using the same (in verilog).
• (cho mingw) GCC support for Windows-compatible Structured Exception Handling (SEH) on the i386 platform
• GRUB2 CD-ROM Boot Support (chờ cái này lâu quá rồi)
• Pyjamas+gtk - Bringing the GTK's power to the web (hơi tò mò, dự án này ngộ quá, mà lại giống một trong những bài Hâm của mình)
• CHM compiler

Tóm lại SoC năm nay đông hơn (đông dễ sợ) nhưng không có nhiều ý tưởng hấp dẫn. Có lẽ bà con đã thực tế hơn, không còn mộng làm những dự án mà cả năm làm không xong, huống hồ gì mấy tháng cho SoC.

Bài Learning Linux? của Andrew Cowie có một cái đồ thị hết sức trực quan mô tả mối tương quan về độ dễ khi cài đặt và độ dễ khi nâng cấp của các distro. Nói tóm gọn, dễ cài thì khó nâng. Dễ nâng thì khó cài.

Cũng có những ngoại lệ đáng ngạc nhiên. Ví dụ như Slackware và Open Solaris (bản phân phối duy nhất không phải Linux) thà chết chứ không chịu dễ nâng cấp. Một ngoại lệ khác còn đáng ngạc nhiên hơn là Ubuntu dễ cài đồng thời cũng dễ nâng cấp (cùng hàng với Debian nhưng được đẩy xa hơn về bên phải).

Nếu theo đồ thị này mà xét thì Ubuntu là lựa chọn số một cho người dùng mới. Lựa chọn số 0.5 là Open SuSE, dành cho những người dùng chỉ thử một lần cho biết. Lựa chọn số vô cực cho người dùng mới là Gentoo Linux (hí hí vậy mà ta cứ phải làm việc với người dùng Linux mới toanh mới chết ta chứ). Dân mài mòn bàn phím tập trung vào mảng Gentoo, BSD và Debian (chắc cũng nên tính Slackware, Open Solaris và RHEL cho dân kinh doanh).

Dù gì đi nữa, đây là một đồ thị dựa theo ý kiến cá nhân vì thế không nên quá coi trọng làm gì.

Định làm một bài tổng kết tình hình nhân kỉ niệm 15000 lần nghe trên last.fm (bài thứ 15000 là Confide in Me của Angtoria).

Chán chả muốn làm.

(Sao tháng này mình tám dữ vậy ta)

Thảo luận trên Git mailing list lại sôi nổi trở lại sau khi Linus gửi lên một tẹo code nền tảng để hỗ trợ submodule/subproject. Dù gì thì gì, lạy trời hỗ trợ submodule xuất hiện trong phiên bản 1.6.

Ngoài lề, robbat2 đang hăm he hỗ trợ subtree checkout. Submodule và subtree checkout là hai trong số những thứ vẫn còn thiếu nếu so với tính năng của Subversion. Với subtree checkout thì chắc không có gì nổi bật, nhưng với submodule, hi vọng sẽ vượt hơn Subversion. À so với Subversion thì vẫn còn phần gitattributes (hay còn gọi là metadata trong Subversion), mà theo Junio, sẽ là tâm điểm của Git 1.5.2.

Sau một dạo dùng Ruby như thể dùng shell (lập trình gì mà cứ mở irb ra gõ lóc cóc rồi lại tab tab tab), rồi lại cố dùng Python như shell, suy ra cần định nghĩa lại cái gọi là scripting language. Nói một cách đơn giản, scripting language là những ngôn ngữ có thể được dùng để thay thế shell (họ "sờ hoài", bao gồm bash, sh, ksh, tcsh...). Đây là những ngôn ngữ có thể dùng để viết những lệnh ngắn, chạy ngay tức thì ("thông dịch" chỉ là điều kiện cần) và tốt nhất phải hỗ trợ hiệu chỉnh lệnh và auto-complete ở mức độ nhất định vì gõ thẳng như thế thường mỏi tay. Nói ngắn gọn đây là những ngôn ngữ "Press and Play" (bắt chước Microsoft). Những ngôn ngữ dạng này, có thể kể một số như:

• Họ ngôn ngữ "sờ hoài"
• Ruby (Auto-Complete in IRB)
• Python (Dùng tab với Python)
• Họ lisp và functional language
• Smalltalk (vô địch về khoản "scripting", theo kinh nghiệm lần thử Squeak)

Nói thêm, elisp là ngôn ngữ số một xét về khoản nhanh và gọn do có thể viết một hàm trong Emacs sau đó chọn "eval-defun".

Những ngôn ngữ thông dịch nhưng không hề tiện dụng (lý do chủ yếu là thiếu editor) để gõ trực tiếp, và do đó không được xem là "scripting language" gồm:

• Perl
• sed
• TCL (thằng này không chắc)
• PHP
• XSLT
• AWK

Tuy nhiên cũng phải nói scripting language vẫn không thuận lợi trong sử dụng nếu phải viết một lệnh dài, hoặc phải viết một hàm. Nếu shell của scripting language cho phép chuyển sang chế độ điều chỉnh nhiều dòng thì sẽ rất rất tiện lợi (đặc biệt với những ngôn ngữ có khả năng viết chương trình to như Ruby hay Python). Hầu hết shell của các ngôn ngữ đều dùng một thư viện: readline. Vậy, bài tập về nhà: mở rộng readline (và phía scripting language nếu cần) sao cho có thể soạn thảo và kiểm tra nhanh một đoạn code lớn (ví dụ một hàm).

Bài tập dễ hơn (trong trường hợp lười hoặc dốt không làm nổi bài đầu): kiếm cách soạn và kiểm tra nhanh một đoạn code lớn (nhiều dòng), bất kể cách đó có "đẹp", có "chính quy" hay không.

Bài tập khác (làm thêm, cho chết luôn): kiếm ra một cái GUI (GTK+) scripting language theo định nghĩa trên. Việc thiết kế nhanh UI với GTK+ là không khả thi với Ruby hoặc Python (hoặc khả thi nhưng lại không chịu thử, đồ lười!).

I was fool. I thought I could have taken it. I was stupid. Alcohol could not help. I can not.

Running away. Toward Long An province. What was the purpose of life? Nothing. The fuel was going down. I stopped. What was the purpose of life? Nothing. I saw someone going forth and back. What was the purpose of life? Wikipedia was totally crap. There was no purpose of life. The purpose of life was for the society. The purpose of one life was nothing. I was scared. I turned back. I went back. What was the purpose of life? To survive. For what? For something of mine. Well, nothing for the society and something for me. If I could just pretend that had I lost control. If I could have just turned left by accident. If I was dead... What was the purpose of life? To survive for something. Suicidal theories exist for a reason. I'm not dead. I was back in an area that I was getting used to it. What was the purpose of life? To survive for nothing.

What is the purpose of life? You don't have to answer that question. Welcome to hell. Let's hope that the real hell is much better than this. What is the purpose of life? To survive.. for nothing... What is the purpose of life?

Okay. I should not say this. Damn it! Damn the life! Should never take any marriage celebration again...

Tin hành lang, KDE repository vừa được chuyển sang git. Với kích thước to đùng (gom hẳn vô những gói lớn như kdelib, kdemultimedia, kdenetwork...) thì rõ ràng KDE là một thử thách với Git. Và rõ ràng là có vấn đề.

kde.git đã được đưa lên và chờ phân tích.

Có một tập tin chứa danh sách các tập tin cần chép. Cần chép các tập tin đó sang chỗ khác mà vẫn giữ nguyên cấu trúc thư mục, làm sao? Đọc tập tin rồi tái tạo cấu trúc thư mục... thì chậm. Có cách hay hơn là dùng tar. Nguyên tắc là nhờ tar gom tập tin lại thành một cục. Sau đó cũng nhờ tar bung cục đó ra ở chỗ khác. Tuy nhiên ta không cần lưu cục trung gian làm gì do đó không tốn chỗ.

tar -c -T list|tar -x

list là tập tin chứa danh sách các tập tin cần chép (tốt hơn lưu đường dẫn tuyệt đối cho đỡ lộn xộn). Nếu cần xác định vị trí bung thì thêm -C. Có thể dùng cpio thay vì tar.

Sau một thời gian "trằn trọc băn khoăn, tối ngủ ngon lành", quyết định tổng kết những gì ghi nhận được về FPGA để mai mốt lại ngâm cứu tiếp.

FPGA nói ngắn gọn là "lập trình phần cứng" hay "lập trình chip". Nó cũng là "lập trình". Hãy xem xét lập trình ở các cấp độ khác nhau. Ở cấp cao nhất của lập trình, cấp thông dịch, bao gồm các ngôn ngữ như PHP, Python, Ruby... Các chương trình loại này được một chương trình khác chạy và thực hiện từng lệnh một. Thấp hơn một tí là các ngôn ngữ có Virtual Machine (VM) và thực hiện mã giả và Just-In-Time compilation như Java hay .NET. Ở mức này các chương trình sẽ được chuyển từng phần sang mã máy. Đến lượt VM sẽ xử lý các mã giả.

Sau mã giả dĩ nhiên là đến mã thật. Những chương trình thuộc thế hệ cũ như C sẽ được biên dịch trực tiếp ra mã máy, loại lệnh mà CPU có thể đọc hiểu trực tiếp. Đối với các chương trình dùng VM, bản thân VM cũng là một chương trình mà sẽ chuyển mã giả của VM đó sang một tập mã máy và thực thi. Đối với các chương trình thông dịch thì đoạn mã tổng cộng dùng để thực thi to hơn nhiều, bao gồm phân tích cú pháp và gọi các hàm tương ứng với từng lệnh. Với cùng một đoạn lệnh thực hiện cùng một tính năng, đoạn viết bằng C là gọn gàn nhất, được chuyển trực tiếp thành những mã lệnh CPU liên quan trực tiếp đến tính năng cần thực hiện. Với các chương trình dùng VM, đoạn mã lệnh CPU to hơn do là tổ hợp của mã lệnh cho CPU của từng mã giả VM. Với chương trình thông dịch, mã liên quan còn to hơn nữa do dính dáng đến phần phân tích cú pháp.

Như ta thấy, càng đi xuống khối lượng "mã" dùng để thực hiện một tính năng giảm dần, cô đọng dần, tập trung vào cốt lõi của tính năng cần thực hiện. Nhưng! Để ý là mã giả cũng là một tập mã, cũng được phân tích thành một tập các mã thiệt dành cho CPU. CPU cũng có một tập mã, nên trên nguyên tắc các mã lệnh CPU cũng có thể được tách thành một tập các "mã điện tử"!

Không biết có ai đã từng phân vân cách hoạt động của một CPU như thế nào chưa. CPU tuy phức tạp nhưng tất cả các thao tác của CPU đều có thể quy về các phép toán logic và số học. Mỗi khi thực hiện một lệnh, CPU sẽ nhảy qua lệnh kế tiếp. Phép nhảy này, đối với kiến trúc x86, đơn giản là cộng thêm vào thanh ghi IP độ dài của mã lệnh vừa thực hiện (Với ARM còn dễ hơn, cứ cộng 4 vào r15 vì kích thước mã lệnh trong kiến trúc RISC là cố định). Phép nhảy đến một địa chỉ. Phép nhảy có điều kiện có thể quy ra là phép cộng với tích của kết quả biểu thức có điều kiện (trả về 1 hoặc 0) với khoảng cách cần nhảy. Nếu điều kiện là đúng, trả về 1, thì IP được cộng thêm vào, nói cách khác là nhảy. Nếu điều kiện sai, trả về 0, thì IP vẫn giữ nguyên. Như vậy có thể nói hầu hết các phép toán của CPU đều có thể biến thành AND OR NOT XOR với cộng trừ nhân chia. Trong khi cộng trừ nhân chia cũng có thể biến thành AND OR NOT XOR!

Như vậy có thể thấy ta có thể chuyển các một chuỗi mã lệnh cho CPU về một mớ cổng logic nối với nhau (giả bộ thế). Khi đã chuyển về như thế, ta có thể tìm ra những chỗ thừa thãi và loại bỏ bớt các cổng logic không cần thiết sao cho kết quả cuối cùng vẫn giữ nguyên. Làm như thế nghĩa là đã loại bỏ CPU ra khỏi quá trình thực hiện chương trình. Chương trình ban đầu giờ đây biến thành một tập các cổng logic (tạm thời quên đi việc truy cập bộ nhớ và các thiết bị phần cứng khác). Thậm chí ngay cả không tối ưu các cổng logic, ta vẫn giảm được thời gian xử lý do loại phần phân tích lệnh và nhảy lệnh của CPU (cũng giống như công việc của trình thông dịch). FSM (lát nữa nói) của một chương trình cụ thể sẽ đơn giản hơn nhiều so với một CPU tổng quát.

Như mô tả, cuối cùng thì chương trình được "lập trình" không còn sử dụng CPU nữa. Và kết quả chương trình không phải là một tập mã máy mà là một sơ đồ các cổng logic. Vậy cần có một ngôn ngữ để "vẽ" mấy cái sơ đồ mạch đó, bằng chữ (rõ ràng vẽ hình thì rất khó kiểm tra giám sát, mà máy tính lại ngu, không giỏi đọc hình bằng đọc chữ). Các ngôn ngữ này được gọi là Hardware Description Language, phổ biến là VHDL và Verilog. Nếu coi mấy cái sơ đồ logic đó là "mã máy" theo cách nhìn của dân làm phần mềm thì rõ ràng chẳng ai điên đi viết trực tiếp trên mấy cái đó cả (tệ tương đương viết hợp ngữ). Do đó HDL sẽ được dùng để mô tả tổng quát hơn và sẽ có một cái "trình biên dịch" để biến cái mô tả đó thành "mã máy" (dân chip gọi là netlist thì phải).

Như vậy, ta có thể nhìn thấy việc "lập trình phần cứng" đơn giản chỉ là một bước tiếp theo của dây chuyền "thông dịch, mã giả, máy ảo, JIT, biên dịch, mã máy". Mặc dù kỳ dị nhưng vẫn chấp nhận được, từ quan điểm lập trình viên. Quay lại FPGA. Đơn vị cơ bản của FPGA là macrocell tuy nhiên vẫn không rõ macrocell là gì. Nó có vẻ phức tạp hơn cổng logic. Macrocell đối với FPGA cũng giống như mã máy CPU đối với lập trình phần mềm. Đó là nền tảng lập trình. FPGA có một lượng macrocell khá là lớn nên có thể vô tư thiết kế. Khi "lập trình FPGA", ta nối các macrocell này lại với nhau, như thể ta lấy các mã lệnh CPU cho vào danh sách theo một thứ tự nhất định vậy. Mặc dù nối macrocell thì nhiều chân hơn, nối tùm lum hơn là cái danh sách mã lệnh một chiều thẳng đuột của lập trình phần mềm.

Việc ghi "chương trình" vào FPGA được thực hiện thông qua giao tiếp JTAG. Nói đơn giản, JTAG cho phép ta trực tiếp đưa tín hiệu vào các chân của một con chip cụ thể trên board mà không cần quan tâm đến mấy thứ còn lại trên board, như thể ta tháo con chip đó ra và mần thịt riêng mình nó.

Thao tác ở mức phần cứng đòi hỏi nhiều thứ hơn là chỉ "sơ đồ các cổng logic". Một trong những thứ đó là điều khiển chức năng của các chân: liệu chân này là chân vào, chân ra, hay chân gãy (điện trở cao, cấm cả vào lẫn ra)... Làm việc với cổng logic cũng có nhiều cái thú vị hơn lập trình cấp cao hơn. Ví dụ như mạch [flip-flop](http://en.wikipedia.org/wiki/Flip-flop_(electronics%29), xem như một bit nhớ đơn giản. Ngoài ra còn có một khái niệm khác có ở cấp lập trình cao hơn nhưng không tồn tại ở cấp FPGA: việc chạy tuần tự các lệnh. Với mạch điện thì chỉ cần cho điện ở cổng vào là toàn mạch chạy hết, không có cái gì tuần tự hết. Tuần tự được là nhờ hai thứ: flip-flop để ghi nhớ trạng thái và chân xung nhịp đầu vào để hoạt động theo từng xung một. Ta có thể viết mô tả HDL để một mớ cổng logic (hay macrocell gì gì đó) hoạt động khi có xung đồng hồ (một cổng AND là hết) và lưu kết quả vào flip-flop. Ta lại viết một mô tả khác cho một mớ cổng logic hoạt động khi có xung đồng hồ và kết quả của cổng flip-flop vừa lưu là 1 (ví dụ thế). Ở đây một tập các flip-flop sẽ hoạt động như bộ nhớ lưu lại trạng thái cuối cùng của chip. Nhiệm vụ của ta là vẽ ra một máy trạng thái hữu hạn (Finite state machine) trên giấy mô tả các bước thực hiện và sau đó chuyển sang vẽ mạch. À dĩ nhiên là không đến nỗi phải vẽ mạch. Verilog khá dễ viết và dễ hiểu nên cũng không đến nỗi. Verilog cũng hỗ trợ luôn các biểu thức số học và biểu thức logic phức tạp nên càng khoẻ. Ai quan tâm thì đọc tiếp trang 53 cuốn "The Verilog Hardware Description Language, fifth edition" của Thomas và Moorby (ai có cuốn nào hay hơn, chỉ dùm cái).

Với việc có thể biến FSM thành mạch một cách dễ dàng, có thể nói ta muốn làm gì cũng được. Chương trình lớn thế nào cũng biến thành mạch được ("A Turing machine is a finite-state machine associated with an external storage or memory medium." -- Minsky (1967), p. 117) Chạy được hay không là chuyện khác! Bởi vì...

• Bởi vì phần cứng thì mắc hơn phần mềm, không có tiền là không có thử cái gì hết
• Bởi vì không có nhiều công cụ hỗ trợ trên Linux. Chỉ có thể kiếm ra icarus verilog, gtkwave và gplcver. Cả icarus verilog vẫn cần bộ Xilinx Foundation. Còn nguyên bộ Xilinx ISE gì gì đó thì giá trên trời. Lại ca bài ca tiền là tiền nhiều khi không mà có, tiền là tiền nhiều khi có mà .. hổng đủ
• Bởi vì phần cứng có tác động của các yếu tố "cứng" như độ trễ của các cỗng logic, độ lệch của xung nhịp, độ dốc của xung... mà mô phỏng phần mềm thì chưa chắc đúng. Còn dùng thiết bị debug chuyên dụng thì lại ca bài ca "tiền là tiền nhiều khi..."
• Bởi vì lười quá nên biết làm sao. Thôi kệ nó.

Túm lại FPGA là thế. FPGA không phải là thần thánh gì. FPGA cũng là lập trình thôi (dù đỏi hỏi một chút hiểu biết về điện tử). FPGA giúp ta đạt được tốc độ nhanh hơn vì loại cả thằng CPU to vật vã ra. FPGA giúp ta trở nên nhỏ hơn (một con chip chứa cả bầu trời!).Nhưng FPGA vẫn chưa là vô địch. Vô địch là ASIC. Với ASIC, FPGA giúp ta tạo ra sản phẩm rẻ hơn (với điều kiện chế tạo số lượng lớn). Và cho dù có thể dùng FPGA để viết cả CPU, đừng mơ đến việc viết một con CPU (chấp làm ASIC luôn) mà có thể qua mặt Intel :)

Cuối cùng cũng phải dành một dòng để nhắc đến một dự án đầy tham vọng có sử dụng FPGA: Open Graphics Project. Hi vọng dự án thành công tốt đẹp.