How not to load-balance connections with accept(), from Phil Harman’s blog.

這裡還有一些利用 LD preload 的技巧.

Popularity: 12% [?]

GDB to MDB Migration Part One, Part Two. from Eric Schrock’s Weblog.

Solaris 的 corefiles 改良成可以包含 process 所有資訊 (library text 和 type information), 而 MDB (and KMDB) 被設計用來作 post-mortem analysis 和 live kernel analysis[1][2].

Coredump debugging 可能是上班以後必備的技巧之一吧 :p

[1] libumem & libutil in Solaris, from zmx.
[2] libuutil and designing for debuggability, from me.

Popularity: 14% [?]

Photographs of Dual Head Display Environment on Solaris 10 x86 with nVidia driver and LG3D on TwinView Part2, from Yasuhiro Fujitsuki’s weblog.

Solaris 10 上用 nVidia 的新 driver 的 screenshot, 有雙螢幕以及 Looking Glass.

如果不知道甚麼是 Looking Glass 的話, 可以參考 screenshot 或是 Demo.

Popularity: 12% [?]

Building, installing OpenSolaris in 100 pictures, from OSNews.

“This site has created a rather large collection of OpenSolaris (Nevada build 16) screenshots.”

Popularity: 13% [?]

The dark side of the source - hostids, from Frank Hofmann’s Weblog.

這篇文章主要是說 Windows XP activation 會抓硬體資訊 (hardware ID), 這就是所謂的反盜版技術 — 產品啟動 MPA (Microsoft Product Activation).

其實很多人對這種 privacy 很重視, 也會對我們造成不便. 比如說將硬碟格式化後, 重新安裝 Windows XP, 我們必須再次執行產品啟動的動作. 而如果因為變更電腦硬體, 導致透過 Internet 啟動無法成功, 我們必須改用透過電話啟動來產品. 市售的 Microsoft 產品提供2次啟動(安裝)機會, 如果要作第3次安裝, 需要打電話至微軟確認. 當然, 我肯定反盜版, 但是對我們生活造成不便是有點誇張.

不過這不是這篇的重點, 軟體如果取得我們硬體的資訊, 然後送給 Microsoft, 那是不是和 Spyware 有點像呢? 只是偷的東西不一樣而己. 好, 這也不是重點, 所以 Frank 帶我們 trace 一下 OpenSolaris 的 sources, 看一下 OpenSolaris 是怎樣取得唯一的 host ID.

大意是說 OpenSolaris 不會取得 hardware-specific information, 他們是利用 modified during installation — Solaris install process simply patches the binary 來取得不同的 host ID, 讓它看起來很像 hardware-specific.

不過好玩的是, 他說 “I cannot show you the source for the install program since the Solaris installation utilities are not yet part of OpenSolaris, but for all practical purposes it’s safe to assume that the install process simply assigns a random number to be the hostid.”

真是無言的結局啊 :p

Popularity: 10% [?]

libuutil and designing for debuggability, from Stephen Hahn’s blog, advices from zmx.

大意是說 Stephen 他們在 Solaris 10 上, 預期會有 multithreaded, present large, complicated images for postmortem debugging 的 daemons, 所以寫下三個 requirements:

1. include Compact C Type Format (CTF) information with each daemon
2. use libumem(3LIB) for memory allocation
3. use standard, debuggable, MT-safe implementations of data structures

但是目前 Solaris 沒有這樣的 data structure, 所以他們開始設計 libuutil (userland utility functions). 讓 modular debugger — mdb (The typical debugger for kernel work in Solaris), 能夠用到這些 debug information.

例如, 任何 link 到 libuutil 的程式, 可以用 mdb 來 attach:

# mdb -p `pgrep -z global startd`
Loading modules: [ svc.startd ld.so.1 libumem.so.1 libnvpair.so.1 libsysevent.so.1 libuutil.so.1 libc.so.1 ]
> ::uu_list_pool
ADDR NAME COMPARE FLAGS
080dcf08 wait_info 00000000 D
080dce08 SUNW,libscf_datael 00000000 D
080dcd08 SUNW,libscf_iter 00000000 D
080dcc08 SUNW,libscf_transaction_entity c2b0476c D
080dc808 dict 0805749c D
080dc908 timeouts 0806ffab D
080dca08 restarter_protocol_events 00000000 D
080dcb08 restarter_instances 0806ccd7 D
080dc708 restarter_instance_queue 00000000 D
080dc608 contract_list 00000000 D
080dc508 graph_protocol_events 00000000 D
080dc408 graph_edges 00000000 D
080dc308 graph_vertices 08059844 D
>

我是不是要試試看在 Solaris 下開發程式了呢? :p

Popularity: 14% [?]

fsync performance, from Gary J’s weblog.

some summary is below:

fsync() is used to ensure that dirty pages that have been written to a file actully go down to disk. The same sort of thing can be done by opening a file using one of the O_SYNC options when a file is opened. fsync() however, allows greater flexibility since the programmer can specify when the synchronisation to disk takes place - perhaps in a separate thread. Anyhow, generally fsync() is goodness and cheap since it only sync’s the data that is dirty.

Since many developers think of fsync() as a ‘free’ system call, often it is called quite indiscriminately and so fsync() performance can really make a BIG difference (See the test results at his weblog).

However there is (or rather was) a subtle problem that shows up when very large files are mapped into the memory of systems with reasonable amounts of memory. The problem is that the file is searched linearly (from beginning to end) from the first page that is mapped in right through to the last.

The good news is that this behavior is changed in Solaris 9 (designed for large systems like the 15/12/25K StarCat range) so that all the dirty pages are put at the head of the list, and we need only search the list until we find the first non-dirty page.

Popularity: 17% [?]