udev已經幾乎是每個os裡必備的機制了，但其佔用了相當的資源，包括開機時，更佔去了好一部份的開機時間。很明顯的，在資源較少的embedded system，不太可能使用這樣的一個東西。
替代品是busybox的mdev，意思是mini udev。mdev需要透過 kernel的hotplug event來完成device node的增減。通常以mdev -s來啟動，設定檔是mdev.conf。啟動時會去掃描/sys/block和/sys/class裡的 dev檔，並根據其指的的major/minor number建立device node，因此在啟動mdev前當需要先把/sys mount起來囉!
[轉載請註明出處] http://kezeodsnx.pixnet.net/blog
作者: kezeodsnx
簡介
framebuffer (fbdev)的特色是與硬體無關的抽像層，用來在console做圖形的處理，好處是不需要如Xwindow這些loading很大的東西來完成圖形化的display。目前來說，包括gtk，qt都可直接操作framebuffer，而不需透過X-windows。意思是在一些resource相對珍貴的embedded system，可以享受到gtk的library，直接對framebuffer做render (GtkFB)，而不用透過X-windows這麼龐大的東西。然而，bottleneck是performance，但DirectFB解決了這個問題，它提供了硬體加速的framework。
在kernel 2.1.x的開發，最早是在intel平台上的一個不同的console driver (bitmapped graphical consoles)，這也是開機看到的那隻企鵝第一次出現。開啟framebuffer，除了kernel要把console driver build-in外，在bootloader加上vga mode的參數 (解析度跟bpp)，此時指定的參數就固定了，不能再改。
原作：劉旭暉 轉載請註明出處 http://blog.csdn.net/colorant/
增訂：Rider
Google 的Android平台到20020227為止，應用部分還是以二進制的 Binary形式發佈的，其编譯的目標平台 ARM926EJ-S的CPU是屬於ARMV5T的版本，所以ARMV4架購的CPU平台無法使用其二進制代碼。關於這點，可以参考下面這篇文章，Benno在此做了詳細的理論分析和代碼測試：http://benno.id.au/blog/2007/11/21/android-neo1973 . 不過依照目前現階段情形除了原本基於ArmV5或以上的架構的平台可以實際運行Android外，亦可在 ARMV4 上面運行了，詳細操作步驟請參考文章最下面 Benno’s 的一些連結資訊，他有 release 一些 patch 可以供 porting 實驗之用。
Android Official Download：
Kernel, emulator, development tool 等下載點： http://code.google.com/p/android/downloads/list
[轉載請註明出處] http://kezeodsnx.pixnet.net/blog
作者: kezeodsnx
ABI
ABI，application binary interface，應用程式和作業系統的"low-level interface"。意思是，ABI有一套規則，如果遵循這個規則產生出的object，就能在相對應的系統上正確的運作。這個規則包括了data type的size，alignment，calling convention，function參數傳遞與回傳值，system call的調用等。很明顯的，這跟平台很有關係。比如說，不管用哪一個compiler，只要能生出符合ELF格式的binary，就可以在Linux上跑，或呼叫其library。
而EABI，embedded-application binary interface則規定了embedded software program的規則。跟一般的作業系統的主要差異為: 應用程式可以使用privileged instruction，dynamic linking不是required，更簡潔的stack frame用以省下memory。
[轉載請註明出處] http://kezeodsnx.pixnet.net/blog
作者: kezeodsnx
引言
常覺得某些人總是總不好某些事嗎?為什麼高鐵可以虧這麼多錢?每個月繳那麼多健保費，一年也沒看幾次醫生，卻只看到天文數字的健保黑洞。每次要坐火車，總擔心買不到票，也不見什麼時候看過台鐵賺錢的新聞。是不為也還是不能也?
利用shell來做事時，也有類似的情況。但基本上電腦世界講究的是邏輯，因此沒有什麼不為的情況，而是不能。有趣的是，解法可以一樣--換人做做看!
[轉載請註明出處] http://kezeodsnx.pixnet.net/blog
作者: kezeodsnx
引言
又是認證，使用linux，似乎比較常談到認證的問題。想了一想，其實是linux在認證方面做了比較多方便使用者的設計與機制。用windows時，開機開半天，有問題重開機，遇到藍底白字也不會抱怨，IE要密碼就敲，因為自古以來都是這樣的"理所當然"。這是否表示為使用者想的愈多，反而讓使用者困擾呢?相同的思考下，限制使用者是否比讓其選擇更能提高接受度呢?
簡介
生活 (4)