pt_deny_attach still works

I was concerned that it wasn’t working properly when I was trying a ::tick-100 /execname == “iTunes”/ { @[ustack()] = count() }, which is kind of useless, and all I received was a bunch of errors involving invalid addresses.
However, it seems to be working…

himitsu:/Library/Extensions# gdb --pid=$(ps -fe | grep '[i]Tunes' | grep -v Helper | awk '{print $2}')
GNU gdb 6.3.50-20050815 (Apple version gdb-960) (Sun May 18 18:38:33 UTC 2008)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin".
/Library/Extensions/15971: No such file or directory.
Attaching to process 15971.
zsh: segmentation fault  gdb --pid=15971
himitsu:/Library/Extensions# kextload pt_deny_attach.kext
kextload: pt_deny_attach.kext loaded successfully
himitsu:/Library/Extensions# gdb --pid=$(ps -fe | grep '[i]Tunes' | grep -v Helper | awk '{print $2}')
GNU gdb 6.3.50-20050815 (Apple version gdb-960) (Sun May 18 18:38:33 UTC 2008)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin".
/Library/Extensions/16048: No such file or directory.
Attaching to process 16048.
Reading symbols for shared libraries . done
Reading symbols for shared libraries .................................................................................................................................................... done
0x943114a6 in mach_msg_trap ()
(gdb) quit
The program is running.  Quit anyway (and detach it)? (y or n) y
Detaching from process 16048 thread 0x20b.
himitsu:/Library/Extensions#

First week into the use of Firefox3

It’s great. simply prettier and a lot more usable than Firefox 2. The awesome bar (the address bar) kicks ass. Much easier to use than the previous one. Bookmark management has been improved. The look and feel is nicer. I even ‘kind of‘ prefer the subtle dialog box improvement which turns up at the top of the form, which is like a wide series of websites that perform the same thing themselves.
This definitely has replaced my web browsers in Windows and Linux. There’s a very high chance that it will replace Safari on the Mac. The only niggle I have is that it doesn’t store your passwords in the Mac keychain, which I still feel is the better place to have them.
Damn the electric fence…

gravatar URIs

Short and simple: http://en.gravatar.com/avatar/<md5 hash of email address>?.
e.g. echo -e ‘bob@email.com’ | md5sum gives: c961431faea38ed65bfd982cf2e31bd0.
Optional add-ons are size (s=<Number of pixels>), content rating (r=<g, pg, r, or x>), and default (d=<escape encoded URI of an image or one of identicon, monsterid or wavatar>).
great place to do something akin to the ‘imitate a lotus notes password entry trick’.

Why no flash for the iPhone

I’m just wondering why there’s this aversion to flash from Apple. Is it that developers of flash applications depend on mouseover events that simply are not suitable for a non-mouse environment?
Possibly? Probably? I don’t know.

Collation information for en_ locales…

Lazy lazy leopard. All the collate definitions seem to point to ascii based sorting in english locales.

himitsu:/usr/share/locale% ls -l en_*/LC_COLLATE
lrwxr-xr-x  1 root  wheel  29 21 Feb 16:19 en_AU.ISO8859-1/LC_COLLATE@ -> ../la_LN.ISO8859-1/LC_COLLATE
lrwxr-xr-x  1 root  wheel  30 21 Feb 16:19 en_AU.ISO8859-15/LC_COLLATE@ -> ../la_LN.ISO8859-15/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_AU.US-ASCII/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_AU.UTF-8/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_AU/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  29 21 Feb 16:19 en_CA.ISO8859-1/LC_COLLATE@ -> ../la_LN.ISO8859-1/LC_COLLATE
lrwxr-xr-x  1 root  wheel  30 21 Feb 16:19 en_CA.ISO8859-15/LC_COLLATE@ -> ../la_LN.ISO8859-15/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_CA.US-ASCII/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_CA.UTF-8/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_CA/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  29 21 Feb 16:19 en_GB.ISO8859-1/LC_COLLATE@ -> ../la_LN.ISO8859-1/LC_COLLATE
lrwxr-xr-x  1 root  wheel  30 21 Feb 16:19 en_GB.ISO8859-15/LC_COLLATE@ -> ../la_LN.ISO8859-15/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_GB.US-ASCII/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_GB.UTF-8/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_GB/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_IE.UTF-8/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_IE/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  29 21 Feb 16:19 en_NZ.ISO8859-1/LC_COLLATE@ -> ../la_LN.ISO8859-1/LC_COLLATE
lrwxr-xr-x  1 root  wheel  30 21 Feb 16:19 en_NZ.ISO8859-15/LC_COLLATE@ -> ../la_LN.ISO8859-15/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_NZ.US-ASCII/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_NZ.UTF-8/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_NZ/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  29 21 Feb 16:19 en_US.ISO8859-1/LC_COLLATE@ -> ../la_LN.ISO8859-1/LC_COLLATE
lrwxr-xr-x  1 root  wheel  30 21 Feb 16:19 en_US.ISO8859-15/LC_COLLATE@ -> ../la_LN.ISO8859-15/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_US.US-ASCII/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_US.UTF-8/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE
lrwxr-xr-x  1 root  wheel  28 21 Feb 16:19 en_US/LC_COLLATE@ -> ../la_LN.US-ASCII/LC_COLLATE

The ‘sorting rule’ for irish is:

--
-- Irish Gaelic alphabet:
--
-- Aa (Áá), Bb, Cc, Dd, Ee (Éé), Ff,
-- Gg, Hh, Ii (Íí), Jj, [Kk], Ll, Mm,
-- Nn, Oo (Óó), Pp, Qq, Rr, Ss, Tt,
-- Uu (Úú), Vv, Ww, Xx, Yy, Zz
--

i.e. Case insensitive, and accented characters after non-accented characters (case insensitive). Surname sorting is even more fun, but I would not expect ls to do that. Finder sorts correctly in this case, but that seems to be due to the fact that it uses the Unicode Collation Algorithm. Shame, I would have preferred both to use the same mechanism.

Bad mac on the sorting front

Well linux and solaris get it correct, but it looks like the little old mac can’t sort things lexicographically (even when it claims in the manpage that it does).

On Linux/Solaris:

~/x% locale
LANG=en_IE.UTF-8
LC_CTYPE="en_IE.UTF-8"
LC_NUMERIC="en_IE.UTF-8"
LC_TIME="en_IE.UTF-8"
LC_COLLATE="en_IE.UTF-8"
LC_MONETARY="en_IE.UTF-8"
LC_MESSAGES="en_IE.UTF-8"
LC_PAPER="en_IE.UTF-8"
LC_NAME="en_IE.UTF-8"
LC_ADDRESS="en_IE.UTF-8"
LC_TELEPHONE="en_IE.UTF-8"
LC_MEASUREMENT="en_IE.UTF-8"
LC_IDENTIFICATION="en_IE.UTF-8"
LC_ALL=
~/x% ls
a  B  c

On the Mac:

himitsu:~/x% locale
LANG="en_IE.UTF-8"
LC_COLLATE="C"
LC_CTYPE="en_IE.UTF-8"
LC_MESSAGES="en_IE.UTF-8"
LC_MONETARY="en_IE.UTF-8"
LC_NUMERIC="en_IE.UTF-8"
LC_TIME="en_IE.UTF-8"
LC_ALL=
himitsu:~/x% ls
B  a  c

According to the spec:
The following environment variables shall affect the execution of ls …

LC_COLLATE

Determine the locale for character collation information in determining the pathname collation sequence.

Sad little mac does not sort by the locale’s character collation specification (case insensitive, in case you missed it).

open -h(uuuh?)

On windows we have start for launching documents and applications. On gnome we have gnome-open which opens documents and applications. On the mac we have the ‘open’ command. Open -a launches the specified application (based on the app paths). Open on it’s own launches a document with the registered preferred application. Then there’s ‘open -h’.

% open -h unistd.h
unistd.h?
[0]	cancel
[1]	all
[2]	/System/Library/Frameworks/Kernel.framework/Headers/libsa/unistd.h
[3]	/System/Library/Frameworks/Kernel.framework/Headers/sys/unistd.h
[4]	/usr/include/sys/unistd.h
[5]	/usr/include/unistd.h
Which header(s) for "unistd.h"? 5

It opens up header files. I mean WTF?

paranoia got the best of me…

Having broken my iPod, I decided to change the root password from the default of ‘alpine’ to something more sensible. I logged in and changed the root password using the passwd command. More fool me, apparently as the springboard kept restarting on me.
I still had ssh access (and root login worked). I made sure that the user/group listings were set to 0 for the mobile user in both the passwd and master.passwd files. Then I made sure that all the entries in passwd had an asterisk for the password and the entry in the master.passwd file contained the output from perl -e ‘print crypt(“yournewpassword”, “/s”), “\n”‘. All is good again! I think…
Update: later, things were still not working properly so I restored and just manually put in the entry for the account rather than trying to convince it to work. Oh well, practice makes imperfect I suppose.

Bizarre wireless issue

Leopard’s wireless access is a bit of a problem. This morning it decided to connect to the one base station in the office that is transmitting it’s ssid (down stairs, in the lab). There are two other base stations in the office, each of which does not transmit their ssid (one about 5 feet from me) but does it pick up the base station that’s the closest? nooo, it picks the one that transmits it’s ssid.
There’s no way to force Leopard to bind to a particular base station is there? I think I can do this with windows, and I know I can do it with the N95. The options for the Mac are quite limited. I feel like I’m trapped in a particularly well implemented Gnome environment 🙂

Several GSODs later…

Well, the mac doesn’t get BSODs it gets a slightly differently colored grey screen of death. Thankfully I had saved before yanking out the plug for the external monitor. It greyscreened on me with the multi-lingual press the power button for a few seconds message on-screen.
I mean really guys, this is grade-A simple stuff, people should be expected to plug these things in and out on a regular basis so it shouldn’t be a kernel panic level issue when something goes wrong in that case.
At least you get a ‘graceful’ video driver restart when things go horribly messy on that platform (unlike XP where you just have a brick).