OpenSolaris VPS

SSD's are flash based drives (a more advanced version of the one you might find in a digital camera) connected to SATA interfaces. There are no moving parts and hence are faster than HDD's but slower than RAM. SSD's fit in the middle and have benefits of both.

SSD's have very low seek time (no moving parts), the amount of time it takes to go find the data on the storage media. This is what gives them the edge over HDD's, but they are still connected to a SATA interface, limiting it to the same throughput as a SATA HDD. SSD's are especially great for random IO.

There are two kinds of SSD's: SLC and MLC. SLC is a single-cell, storing 1 bit in each memory cell. MLC is a multilevel cell, storing 2 or 3 bits in a cell. MLC's have more capacity but the catch is: SSD's are generally slower at writes, they need to clear the cells (pages) before writing to it. It is a two step process for writes.

SSD's prices are dropping a lot. Expect to see more of them in the coming years. They also save on power and are great for laptops!

In servers, and especially ZFS file systems, SSD's come especially handy.

This is something that is not documented. If you do "pkg list" in OpenSolaris 2009.06, there is a column with header "UFIX". This stands for:

U -> upgradable
F -> frozen
I -> incorporated
X -> excludes

Apache 2.2 (Apache's APR actually) has a bug in the OpenSolaris 2009.06 (including Entic.net's OpenSolaris VPS servers) release. The symptom is the web server goes unresponsive and hangs after some time.

We ran Apache in a single thread, in the foreground (httpd -f httpd.conf -X), and then used our trusty PID provider in DTrace to get a stack trace, that looks something like this:

0 80992 apr_atomic_inc32:entry
0 83055 atomic_inc_32_nv:entry
0 83401 port_getn:entry
0 85371 _portfs:entry
2 83394 ___errno:entry
2 80993 apr_atomic_dec32:entry
2 83062 atomic_dec_32_nv:entry
2 83394 ___errno:entry
2 83394 ___errno:entry
2 80853 apr_pollset_poll:entry
2 83124 __div64:entry
2 83121 UDiv:entry
2 83125 __rem64:entry
2 83120 UDivRem:entry
2 80992 apr_atomic_inc32:entry
2 83055 atomic_inc_32_nv:entry
2 83401 port_getn:entry
2 85371 _portfs:entry 

Thanks to some great folks over at Sun, we've gotten a workaround that fixes this. The final fix won't be available until APR is upgraded or until build 124.

Our web site makes use of the Yahoo! User Interface, YUI for short. We happened to be searching for a good book on YUI, and we find it interesting that Google Book search lists this book in 20th rank.

Nearly all other searches with other providers show this book in the top spot: Barnes&Noble BookFinder Amazon and Google.

I would expect Google to be very good with search technology and has made billions of dollars on it. So, why does this specific search end up being at the "bottom". YUI does compete with Google's own Web 2.0 framework.

Is Google censoring (or rather, controlling data) or does this mean that Google does not have a good search engine? What if they were censoring? Maybe it is time to start using Bing? Comments?

Domain names are resolved by DNS name servers. These name servers resolve a given domain name from right to left. When you goto the domain "entic.net", the following queries are done, in order:

root@tail:~# dig +trace www.entic.net

; <<>> DiG 9.3.6-P1 <<>> +trace www.entic.net
;; global options:  printcmd
.			147403	IN	NS	L.ROOT-SERVERS.NET.
.			147403	IN	NS	D.ROOT-SERVERS.NET.
.			147403	IN	NS	K.ROOT-SERVERS.NET.
.			147403	IN	NS	B.ROOT-SERVERS.NET.
.			147403	IN	NS	C.ROOT-SERVERS.NET.
.			147403	IN	NS	M.ROOT-SERVERS.NET.
.			147403	IN	NS	J.ROOT-SERVERS.NET.
.			147403	IN	NS	H.ROOT-SERVERS.NET.
.			147403	IN	NS	E.ROOT-SERVERS.NET.
.			147403	IN	NS	I.ROOT-SERVERS.NET.
.			147403	IN	NS	G.ROOT-SERVERS.NET.
.			147403	IN	NS	A.ROOT-SERVERS.NET.
.			147403	IN	NS	F.ROOT-SERVERS.NET.
;; Received 500 bytes from 66.151.145.33#53(66.151.145.33) in 1 ms

net.			172800	IN	NS	a.gtld-servers.net.
net.			172800	IN	NS	b.gtld-servers.net.
net.			172800	IN	NS	c.gtld-servers.net.
net.			172800	IN	NS	d.gtld-servers.net.
net.			172800	IN	NS	e.gtld-servers.net.
net.			172800	IN	NS	f.gtld-servers.net.
net.			172800	IN	NS	g.gtld-servers.net.
net.			172800	IN	NS	h.gtld-servers.net.
net.			172800	IN	NS	i.gtld-servers.net.
net.			172800	IN	NS	j.gtld-servers.net.
net.			172800	IN	NS	k.gtld-servers.net.
net.			172800	IN	NS	l.gtld-servers.net.
net.			172800	IN	NS	m.gtld-servers.net.
;; Received 491 bytes from 199.7.83.42#53(L.ROOT-SERVERS.NET) in 10 ms

entic.net.		172800	IN	NS	ns1.everydns.net.
entic.net.		172800	IN	NS	ns2.everydns.net.
entic.net.		172800	IN	NS	ns3.everydns.net.
entic.net.		172800	IN	NS	ns4.everydns.net.
;; Received 176 bytes from 192.5.6.30#53(a.gtld-servers.net) in 80 ms

www.entic.net.		7200	IN	CNAME	entic.net.
entic.net.		86400	IN	NS	ns1.everydns.net.
entic.net.		86400	IN	NS	ns2.everydns.net.
entic.net.		86400	IN	NS	ns3.everydns.net.
entic.net.		86400	IN	NS	ns4.everydns.net.
;; Received 190 bytes from 208.76.62.100#53(ns1.everydns.net) in 1 ms

The queries are done in this order, as shown above:

"." -> "net." -> "entic.net." -> "www.entic.net."

You ask a DNS server for information about ".", you get back a list of servers mapped it. You then ask these servers for information about "net.", you get back another list. You then ask those list of servers for information about "entic.net.". This process follows, until we get back the final IP address information for www.entic.net. Note, the "." information is built into the DNS servers (e.g. called the ROOT cache).

There you have it, a quick summary of a trace of a domain lookup done by servers all over the world.