Lý sự pclouds

Khỏi mắc công phải xem từng tấm trên OSDir

Git commit hình thành một "cây commit". Tuy nhiên không ai nó rằng git repository chỉ có thể chứa duy nhất một cây commit (một gốc).

Với các SCM khác, initial commit sẽ tạo ra commit gốc duy nhất và sẽ là cội nguồn của mọi commit. Với git, có thể cho chung nhiều cây commit vô cùng một git repository. Sự khác biệt là với SCM thường, để quản lý nhiều bộ mã nguồn trong cùng repo, ít nhất intial log sẽ được share chung. Nếu không dùng branch mà dùng cấu trúc thư mục để quản lý các bộ mã nguồn khác nhau thì làm rối đội hình và đặc biệt khó chịu với những SCM quản lý toàn bộ SCM chứ không phải chỉ xử lý từ thư mục đang đứng về sau. Nếu dùng branch, như đã nói, sẽ dính một số log ban đầu. Ngoài ra cách này cũng chả đẹp đẽ gì.

Nhưng tại sao không dùng hai git repository riêng thay vì 1? Ờ có một số trường hợp hack trên hai thư mục khác nhau của cùng project. Hai phần tuy không liên quan trực tiếp đến nhau nhưng thuộc cùng một project. Nếu tách làm hai repo riêng thì repo dễ đi lạc. Vậy cứ gom vô một cho chắc.

Tống nhiều cây commit vào git cũng chẳng khó khăn gì. Cứ push vào một nhánh mới trên git repo là xong. Dĩ nhiên cũng nên cẩn thận với mấy cái "branch" vì đó là đầu mối để lần ra mọi thứ.

GIT_DIR=repo git init-db
cd r1
git push ../repo refs/heads/master:refs/heads/repo1
cd ../r2
git push ../repo refs/heads/master:refs/heads/repo2
# Giờ có thể vô tư móc repo1 hoặc repo2 tuỳ thích

Lệnh git help <command> hiện trang man của lệnh git tương ứng. Vậy mà trước nay ta miệt mài gõ man git-blah..

Start mDNSResponder lên, xong có thể dùng mDNSPublish để đăng ký các dịch vụ của mình, ví dụ:

mDNSPublish 'Bi Ếch Ếch Hắc' _ssh._tcp 22

Có thể dùg mDNSBrowse để kiểm tra kết quả

mDNSBrowse _ssh._tcp

Nếu start mDNSResponder lên trước khi mở nautilus thì có thể thấy những dịch vụ này trong network:. Ngoài ra có thể browse thử dns-sd://dns-sd.org xem cho vui.

Nautilus chỉ hiểu ba dịch vụ là _sftp-ssh._tcp, _webdav._tcp và _ftp._tcp. Rhythmbox dùng thêm một cái là _daap._tcp

Có thể vọc chơi để hiểu cách hoạt động của "dns-sd://host"

dig ANY _ftp._tcp.dns-sd.org
dig ANY 'Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org.'

Xem thêm DNS-SD Support in gnome-vfs

jabberd tuy hỗ trợ PAM và có thể dùng pam_krb5 để xác thực. Tuy nhiên thực tế cho thấy vẫn phải thêm user vào /etc/passwd thì pam_krb5 mới hoạt động.

Thay vì phải xử lý thằng pam_krb5 thì dựa trên source của pam_krb5 để viết krb5 auth backend cho jabberd luôn :D.

Kết quả là jabberd có thể hỗ trợ Kerberos tốt. Ebuild và patch nằm trong mg-experimental.git.

Eye Of Gnome (EOG) không thể mở ảnh trên smb://, bởi vì nó đọc mỗi lần 65536 byte. Trong khi đó theo Bug 326104 thì do giới hạn của SMB/CIFS protocol. Giảm 65536 xuống 65535 thì chạy tốt.

Sao cứ tìm ra lỗi trước khi tìm ra bug thông báo lỗi :( . Chán quá

These are customizable hotkeys (through GConf):

• Alt-Space: Activate window menu
• Alt-F4: Close window
• Alt-F9: Minimize window
• Alt-F7: Begin move
• Alt-F8: Begin resize
• Ctrl-Shift-Alt-{Left,Right,Up,Down}: Move focused window to the {left,right,upper,lower} workspace
• Alt-Tab: Switch windows
• Ctrl-Alt-Tab: Switch panels
• Alt-Esc: Cycle windows
• Ctrl-Alt-Esc: Cycle windows
• Ctrl-Alt-d: Show desktop
• Ctrl-Shift-Alt-{Left,Right,Up,Down}: Switch to the {left,right,upper,lower} workspace
• Alt-F1: Show panel menu
• Alt-F2: Show Run dialog
• Print: Take fullscreen screenshot
• Alt-Print: Take window screenshot

Vậy là Cairo đã chính thức chia tay CVS (giờ chỉ còn read-only) và chuyển sang GIT:

git://git.cairographics.org/git/cairo

GNUPod cũ hơn 0.98.2 phát sinh tên tập tin dài hơn 55 ký tự (giới hạn của Apple iPod) dẫn đến một số bài không phát được. 0.98.2 đã sửa lỗi này.

Cập nhật 20 file. Vẫn còn hơn 40 file nữa, mà 2006.0 sắp ra rồi :(

gdp.git

Vậy thôi, dùng XEvIE thay vì dùng LD_PRELOAD

GTK+ từ phiên bản 2.2 đã hỗ trợ multi-head, cho phép hiển thị ứng dụng GTK+ trên nhiều X Server cùng lúc. Khả năng này dẫn đến một điều hết sức thú vị: tách một cửa sổ của ứng dụng khỏi server này, chuyển sang server khác. Vậy chuyện gì xảy ra nếu ta chặn lỗi của X khi đứt kết nối (hành vi mặc định là chấm dứt chương trình) và chuyển toàn bộ cửa sổ sang một server giả khác (vd Xnest hoặc Xfake)? Ta có được tính năng của GNU Screen cho các ứng dụng GTK+ :)

Tuy nhiên, đời không đẹp như mơ. Một vấn đề từng được thảo luận là chuyện security. Tưởng tượng, một thằng nào đó tự động ngắt ứng dụng ra khỏi server của mình rồi chuyển sang server của nó! Bug 153351 lo chuyện này. Nhưng ngoài chuyện security ra vẫn còn một vấn đề kỹ thuật: bug 85715. Hiện thời hình như chỉ có gtk-demo là chuyển qua lại giữa các server ok :(

PS. Nhờ đó tìm ra CryoPID - A Process Freezer for Linux :D

Gần hết các tính năng của WM có thể được thực hiện thông qua EWMH mà không cần can thiệp trực tiếp vào Metacity (trừ cái window menu). Có lẽ có thể cải tiến chút đỉnh để hỗ trợ mạnh hơn trong việc sắp xếp các cửa sổ, để Metacity thực hiện trọng trách cơ bản của WM thôi: màu mè border, quản lý workspace, window state.

Một cái gì đó giống giống chương trình vẽ hình như Dia/Inkscape, mỗi hình vuông là một cửa sổ, kéo thả thoải mái... Có lẽ transparent để thấy các cửa sổ bên dưới luôn (nếu có composite). Cũng có thể chơi tác động trực tiếp kiểu HIG. Cho phép tạo cửa sổ "hút" cửa sổ khác, tạo snapping line...

Woa... Chắc năm sau xong.

Cài đặt thử chương trình như minh hoạ trong Bug 120204. Phần chuyển workspace tạm ổn. Phần điều khiển tình trạng cửa sổ chưa ổn lắm nếu nó nằm ở workspace khác (EWMH không nói gì đến chuyện điều khiển liên workspace, đúng hơn là EWMH không quan tâm workspace nên chuyện không chạy cũng dễ hiểu). Phần (quan trọng nhất), điều khiển nhiều cửa sổ cùng lúc, chưa làm :(. Vẫn cần phải hack metacity hoặc đề nghị metacity developer mở đường vô window menu.

Trước khi đi xâm nhập thực tế, vẫn còn một điều phải nắm vững: Index. Khác với các SCM thông thường chỉ có "working directory" và "repository", Git có thêm một lớp đệm ở giữa: index.

Index là gì? Index có thể coi như là "working directory" nhìn từ phía Git. Index chứa tree object và các blob object liên quan của thư mục đang làm việc. (Yep, các object (blob/tree) được tạo ra và đưa vào Git trước cả khi commit vào repository). Khi thực hiện commit, những object này sẽ được gắn với một commit object mới và lưu commit object này vào "kho object" của Git (kèm theo điều chỉnh refs/heads).

Tuy nhiên, cần lưu ý Index không tự động đồng bộ với thư mục làm việc. Đây là chỗ gây khó khăn khi chuyển từ các SCM khác qua Git. Git không quan tâm đến working directory mà chỉ quan tâm đến "index" của nó. Khi commit, nó sẽ dùng index, trong khi SCM thường sẽ kiểm tra nội dung working directory. Để cập nhật index, lệnh git-update-index được dùng.

Vậy thay vì cách commit thông thường. Với git, sau khi đã thực hiện các sửa đổi trên working directory. Ta cần phải cập nhật "index" từ working directory trước. Khi cập nhật index, các object mới sẽ được tạo để lưu giữ nội dung working directory ở thời điểm đó. Sau khi kiểm tra bảo đảm "index" chứa thông tin đã cập nhật, ta mới có thể "commit".

Sau khi cập nhật index xong, nếu tiếp tục thay đổi working directory, các thay đổi đó sẽ không được tự động cập nhật vào index, cũng có nghĩa là nếu gọi commit, những cập nhật mới nhất đó sẽ bị bỏ qua. Cần kiểm tra lại xem nội dung của index có thực sự là nội dung mình muốn hay không.

Túm lại, sửa working directory thoải mái, sau đó "cập nhật index" để biến working directory thành blob. Sau đó, khi commit, các blob này được gộp với một commit object mới để hình thành một commit. Nội dung commit không phải bao giờ cũng giống y hệt nội dung working directory, cần kiểm tra lại index để đảm bảo điều đó.

Trăm nghe không bằng sờ được. Thử tạo một repo mới dùng Git. Nội dung ban đầu như sau:

+-a
+-b
+-c
  +-aa

Nội dung của a và c/aa là:

Hello A!

Nội dung của b là:

Hi B!

Do dùng SHA1 để vẽ thì hơi kinh dị nên sẽ dùng tên ngắn hơn.

Commit với log là "initial commit".

Sau khi đã gõ điên cuồng những lệnh git kinh dị, ta sẽ được một đồ thì như sau:

Như trong đồ thị, ta có hai tree object. Tree 2 là con của tree 1. Đồng thời ta chỉ có hai blob object thay vì ba vì nội dung của a và c/aa là giống nhau. Commit 1 trỏ đến tree 1, gốc của repo. Xong initial import :)

Bây giờ sẽ đổi nội dung c/aa thành:

AA, not A!

rồicommit với log "Wrong!". Ta được gì?

Ta được hai tree object mới: T3 và T4, một blob mới B3 và dĩ nhiên một commit object C2. Do nội dung của c/aa thay đổi nên một blob mới B3 được tạo để chứa nội dung này. Do nội dung thư mục T2 thay đổi (trỏ đến B3 thay vì B1) nên T4 được tạo. Do nội dung T1 thay đổi (trỏ đến T4 thay vì T2) nên T3 được tạo ra. Cuối cùng T3 được gắn với C2. Xong.

Bây giờ thử "tách nhánh". Giả định C2 là "master". Ta tách một nhánh khác từ C1. Xoá c và chuyển c/aa thành z. Ta được như trong hình. Một điều đáng chú ý là do a và z cùng nội dung nên dùng cùng một Blob object, chỉ khác cái tên.

Đấy, Git chỉ có thế!

Git có một số khái niệm cần nắm trước khi nhào vô vọc Git thật sự.

Trước hết là "object". Git quản lý tất tần tật là object. Object được xác định bằng mã SHA1. Một tập tin là một object (chỉ phần nội dung tập tin) - blob object. Một thư mục cũng là một object - tree object. Tree object chứa blob object (đúng ra là SHA1 của blob), ngoài ra có thể chứa SHA1 của tree object khác để hình thành cây thư mục đa cấp. Bản thân blob object chỉ chứa nội dung tập tin, blob object không có tên (filename), không có thuộc tính truy cập... Những cái này sẽ được chứa trong tree object, cùng với SHA1 của blob object. Tương tự, tree object của không có tên, tên thư mục con sẽ do tree object cha ghi nhận. Đến đây, bằng blob và tree, ta có thể xây dựng được cấu trúc thư mục. Để ý rằng do blob object không có tên, nên nếu hai thư mục trỏ đến hai tập tin có nội dung giống hệt nhau thì cả hai sẽ cùng trỏ đến một blob object thay vì hai, tiết kiệm được không gian và khá giống với hard-link của Unix filesystem.

Object là không thể thay đổi. Một khi đã tạo ra thì sẽ giữ nguyên như thế mãi mãi. Đây là một trong những đặc tính quan trọng, bảo đảm nếu hai thư mục cùng trỏ đến một blob object thì cũng không sợ ảnh hưởng gì nhau, vì blob object luôn luôn là chỉ đọc

Vậy làm sao lưu các thay đổi của tập tin/thư mục? Đơn giản là khi thay đổi tập tin/thư mục thì .. tạo object (blob/tree) mới :) Git không nhắm đến việc tiết kiệm ổ cứng vì Linus lý luận rằng đĩa cứng bây giờ rẻ quá. (Thật sự Git cũng có cơ chế để tiết kiệm - packed objects, nói sau)

Vậy, khi import vào repository thì tất cả các tập tin/thư mục sẽ được biến thành object, có một mã số SHA1 để nhận diện. Sau khi thay đổi mã nguồn, thêm mới tập tin, xoá tập tin ... Thư mục hiện thời sẽ được biến thành object một lần nữa (cái nào không đổi thì dĩ nhiên sẽ tận dụng object đã có, cái nào xoá thì đơn giản là không link đến object đó từ tree object, object đó vẫn tồn tại và không bị xoá. Object khi đã tạo ra thì tồn tại vĩnh cửu, bất biến

Coi như hầu hết các thao tác của một hệ thống SCM bình thường (thêm xoá sửa) đã giải quyết. Những phần linh tinh khác như diff, do đã lưu được đầy đủ các object, chỉ cần lôi đầu đúng object và diff là xong. Còn thiếu một cái: log message khi commit.

Để quản lý commit, một loại object mới được dùng: commit object. Commit object chứa một số thông tin khi commit (người commit, tác giả của commit -- Git phân biệt người tạo ra thay đổi và người commit những thay đổi đó vào repo, ngày giờ commit, ... và SHA1 của tree object tương ứng với lần commit đó). Như vậy, từ commit object, ta lấy được tree object của thư mục gốc của repo. Từ tree object này, ta có thể lấy được các blob object - các tập tin, hoặc các tree object khác - thư mục con. Ngoài ra, commit object còn chứa SHA1 của commit object cha. Nhờ đó ta có thể xâu các commit object lại với nhau. Từ commit mới nhất, có thể lần ngược thời gian để tìm lại những commit cũ, các tập tin thư mục tương ứng với các commit cũ.

Do Git quản lý bằng object, định danh bằng SHA1 nên không có khái niệm "revision" như Subversion. Với Subversion, mỗi lần commit thì revision của repo tăng 1. Với Git, mỗi lần commit, ta nhận được 40 chữ lạ hoắc nhằm xác định commit đó.

Đến đây, hệ thống SCM đã hoàn tất :). Việc còn lại là developer phải "chịu khó" nhớ SHA1 của commit mới nhất. Từ commit object này có thể lấy ra source code mới nhất, tiến hành sửa đổi rồi commit với commit object cha chính là commit object này. Do việc theo dõi 40 con số mỗi lần commit không vui vẻ gì nên một tập tin được tạo ra để quản lý dùm con số này: .git/refs/head/master (tương ứng với trunk của Subversion hoặc HEAD của CVS) là một tập tin chứa SHA1 của commit object mới nhất. .git/HEAD là liên kết trỏ đến một tập tin trong .git/refs/heads, xác định commit object của thư mục đang làm việc.

Nếu refs/heads/master dùng để quản lý nhánh master thì tại sao lại không dùng cách tương tự để quản lý các nhánh khác? refs/heads thực chất chính là các commit đỉnh của các nhánh. Dễ thấy Git bây giờ đang quản lý một đồ thị một chiều của các object, liên kết với nhau từ commit object đến tree object rồi đến blob object. Việc commit chỉ là nối thêm các object mới vào đồ thị đã có. Nếu biết được SHA1 của một commit object thì có thể thực hiện một commit mới dựa trên commit đó, nói cách khác - tách nhánh từ commit object đó (dĩ nhiên nếu chỉ có một commit object trỏ đến commit object cha thì không cần gọi là nhánh làm gì). Việc tách nhánh chỉ là ghi nhớ SHA1 của điểm tách nhánh, tạo một tập tin mới trong refs/heads chứa SHA1 của commit object đó, để lần sau có đường mà mò lại.

Một đối tượng cuối cùng, không quan trọng lắm, là tag object. Thực chất, với SHA1 của commit object, ta xác định được mã nguồn tại một thời điểm chính xác. Và vì các object là không thay đổi nên một khi có được SHA1, ta sẽ luôn luôn tái tạo lại được chính xác cây thư mục ở thời điểm commit. Mục đích của tag cũng chỉ có thế. Tuy nhiên do SHA1 không thân thiện cho lắm nên tag object được tạo ra. Tag object chứa SHA1 của 1 commit object và một số thông tin bổ sung (vd, chữ ký ...). SHA1 của tag object được lưu trong refs/tags để tham khảo về sau.

Thế. Git về cấu trúc cơ bản chỉ có thể :)

Bye bye Bazaar, hello mg.git!

Làm sao cài gitweb lên d.g.o đây :( Được voi đòi tiên ..

Từ RockFanClub:

Nghe xì-lô gật tựa Mê-tồ

:D

Một điểm yếu của Distributed SCM là mỗi khi clone (mirror), ta phải lấy hết về toàn bộ repository - trong khi với Centralized SCM, ta chỉ cần lấy về "snapshot" của một revision nào đó. Với những thứ đồ chơi to kềnh càng như Wine hay kernel thì chuyện móc toàn bộ repo về không thú vị cho lắm. Shallow clone của git đang lăm le luộc điểm yếu này. Một khi shallow clone hoạt động thì chẳng còn lý do gì để ngó đến Subversion hay CVS nữa ;)

PS. Bzr cũng đang định làm một tính năng tương tự, gọi đúng theo thuật ngữ của Centralized SCM: "checkout" tuy nhiên vẫn chưa thấy gì.

Từ GIT mailing list, tính tới nay có hai ông bự dùng Git là Linux kernel và Wine. Ngoài ra Cairo cũng đang lăm le chuyển qua Git. Chưa kể X.org cũng đang máu Git. Cho tới nay có lẽ Git là distributed SCM được dùng nhiều nhất (kế đến chắc Bazaar/Arch với Ubuntu đứng sau lưng). Git và Bzr cũng là hai DSCM phát triển tích cực nhất (ít ra là nhiều chuyện nhất).

Xem ra cũng tới lúc chuyển qua Git rồi ..

:D

Nghe nhạc:

gst-launch-0.10 filesrc location=đường dẫn ! decodebin !  alsasink

Xem phim:

gst-launch-0.10 filesrc location=đường dẫn ! decodebin name=d { d. ! alsasink } { d. ! queue ! ximagesink }

Mở một lúc 9 phim, sắp đầy màn hình rồi ngồi ngắm .. cpu tăng lên 80% :D

Có thể thay ximagesink bằng xvimagesink nhưng chỉ có thể xem một phim bằng xvimagesink, phần còn lại phải coi bằng ximagesink. Muốn chỉ xem, không nghe:

gst-launch-0.10 filesrc location=đường dẫn ! decodebin ! ximagesink

Chỉ nghe, không xem:

gst-launch-0.10 filesrc location=đường dẫn ! decodebin ! alsasink

Hiện visualization cho nhạc:

gst-launch-0.10 filesrc location=đường dẫn ! decodebin ! goom ! ffmpegcolorspace ! xvimagesink

Chưa biết làm sao vừa nghe nhạc, vừa coi visualization :(

Sau một khoảng thời gian dài ngưng không phát triển ở phiên bản 0.8.8, gần đây Rhythmbox bắt đầu phát triển tích cực :)

The last message was received 2.65 hours ago at 08:07 on Feb 07, 2006
3 messages so far today, 5 messages yesterday
8 messages so far this week, 44 messages last week
46 messages so far this month, 149 messages last month
1622 messages since the first one, 2.08 years ago, for an average of 11.21 hours between messages

là một chuỗi ngày dài ngồi ngắm feature và chờ nó được cài đặt... ôi .. ếch ơi là ếch ..

GNOME Mockups nửa giống Windows, nửa có mùi Mac ...

emerge mplayerplug-in
vi /etc/mplayerplug-in.conf # uncomment và sửa lại cho phù hợp

Hổng hiểu sao thằng Epiphany hơi khùng khùng (chắc tại build với mozilla) dùng plugin trong /usr/lib/mozilla/plugins trong khi plugin chỉ được cài trong /usr/lib/nsbrowser/plugins và /opt/netscape/plugins :(

Đọc hết chương 10 GStreamer Application Development Manual (0.10.1.1), chỉnh ví dụ mẫu của nó lại để làm mp3 player. Kết luận, làm mp3 player dễ òm. Thậm chí chẳng cần làm cũng có thể phát mp3 mát trời:

gst-launch-1.0 filesrc location=đường dẫn tập tin mp3 ! mad ! alsasink

:D

PS. Không biết làm sao để chạy với GStreamer 0.8 (vì có bao giờ dùng GStreamer trước đây đâu mà biết), đành phải cài GStreamer 10.0 vô và đọc manual tiếp trong khi đợi biên dịch :(

Some notes after reading the source.

• Handshake

  # Use wsdev.audioscrobbler.com for testing purpose
  wget 'http://ws.audioscrobbler.com/radio/handshake.php?version=1.1.5&platform=Linux&username=myusername&password=my md5-encoded password&debug=0'
  # The result
  session=BLAHBLAH
  stream_url=http://streamer1.last.fm/last.mp3?Session=XYZ
  subscriber=0   
  framehack=0
  base_url=ws.audioscrobbler.com
  base_path=/radio
  

• You can now listen to your music from stream_url

• For metadata, use:

  wget 'http://$base_url$base_path/np.php?session=$session'
  # And you get
  streaming=true
  discovery=-1
  station=Global Tag Radio: Rhapsody
  artist=Finntroll
  artist_url=http://www.last.fm/music/Finntroll
  track=Under Varje Rot Och Sten
  track_url=http://www.last.fm/music/Finntroll/_/Under+Varje+Rot+Och+Sten
  album=Visor Om Slutet
  album_url=http://www.last.fm/music/Finntroll/Visor%20Om%20Slutet
  albumcover_small=http://images.amazon.com/images/P/B00009QRCB.01.THUMBZZZ.jpg
  albumcover_medium=http://images.amazon.com/images/P/B00009QRCB.01.MZZZZZZZ.jpg
  albumcover_large=http://images.amazon.com/images/P/B00009QRCB.01.LZZZZZZZ.jpg
  trackduration=197
  trackprogress=51
  radiomode=1
  recordtoprofile=1
  

• To control, there are some commands such as 'love', 'ban', 'skip', 'rtp' (record to profile), 'nortp' (no record to profile):

  wget 'http://$base_url$base_path/control.php?session=$session&command=your command&debug=0'
  

• To change station (another lastfm:// url)

  wget 'http://$base_url$base_path/adjust.php?session=$session&url=your lastfm:// url, including lastfm:// prefix'
  

• There are also 'get.php' which I guess it is used for searching.

So this protocol is not really difficult. Just need someone to stand up and write the code down. PS. There are already a bug for Last.FM support in Rhythmbox :)

Phải chạy Qt static linked Last.FM Player để nghe :( Thêm cái Todo mới, viết Gtk+ Interface cho Last.FM

Dạo một vòng kho nhạc Rhythmbox. Mk sao mà nhiều bài trùng nhau quá. Loại hết một mớ. Hèn gì cái kho nó lên đến 18GB :P Hết đĩa rồi :(

Từ Banking on Open Source in Europe

The arguments given in the conference were no big surprise to anyone who has been involved in Open Source for the last few years: freedom of choice, being able to adapt and change the software, support for standards, flexibility, better quality through the open development process and the possibility of community involvement - to name a few.

Sau gần 7,8 năm gì đó từ ngày "pclouds" ra đời, quyết định chấm dứt dùng "pclouds" như danh xưng mà thay vào đó dùng tên thật.

Biết đâu mai lại có một nghị quyết mới, chuyển lại dùng "pclouds" kaka :D