unflyingobject

A really lazy way to add search to your RW page:

<div id="gsearch">

<form action="http://www.google.com/search">

    <input type="text" name="q"/>

    <input type="hidden" name="hl" value="en"/>

    <input type="hidden" name="sitesearch" value="http://homepage.mac.com/filipp"/>

    <input type="submit" value="Search with Google"/>

</form>

</div>

I think you could actually cook up something nice with a Google developer account and XMLHttpRequest...

When using script.aculo.us with XSLT (XML to XHTML), don't include like this:

<script src="javascripts/scriptaculous.js" type="text/javascript">

This is because scriptaculous.js uses document.write () to include the components and that' apparently verboten when using XSL. The symptoms are weird too:
* Safari will acts as if all was OK, except Ajax.Request won't work
* Firefox/Gecko-based browsers will just hang on loading the document (an invinite "Reading") and you'll notice some class name related errors in the JS log.
In other words, the correct way to include, is by all the files separately and in the right order:

<script src="javascripts/effects.js" type="text/javascript"></script>

<script src="javascripts/builder.js" type="text/javascript"></script>

<script src="javascripts/dragdrop.js" type="text/javascript"></script>

...

About 6 months ago, me and my mother wanted to start building our family tree. It quickly became apparent that the Mac software scene is sorely lacking in this area. Most of the mature apps were either dated, didn't support Unicode (quite frankly an unacceptable flaw in a genealogy app) or were just too cumbersome to use. Family was cute, but lacked some important features (like any kind of textual backup or export).

Genealogy could be fun and educating at the same time. So I thought why not throw something together myself (having had some data modelling experience at school). The XCode project was called "Sugupuu" (Estonian for "family tree"). The model part was easy thanks to Core Data (you only really need one entity and a recursive relationship to get started), but the undertaking ground to a halt because of my lack of graphics programming experience. Life went on and the whole idea quietly faded into the background.

And then a few days ago it hit me - why not do the same thing, only for the web - as a nice Web.2 app. It would be heaps more useful like this as well! So I got back on it - first ported the data model to MySQL - which quickly turned out to be a dead end (flat tables != good for trees). Then I moved to a completely XML-based model

XML makes me want to smoke crack. On the one hand it's this wonderful, easy-to-use and approachable grammar that gets you high on thinking you can describe anything, but when you really get down to it, you notice that that's all it is - a grammar. Most practical "standards" just frustrate the heck out of you. XSLT is a perfect example - turning XML into an XHTML document - everything sort of works until you (for example) start using JavaScript. DTD's are awful and Schema, for all my purposes, total overkill. And then come the browser incompatibilities...

SVG is another one - looks fantastic on paper (still rooting for as the "swf killer"), has been "around" for quite a while, yet you still need an ancient discontinued plugin to take advantage of some of it's nicer features. Lame. It seems wherever you look in the XML-space you always wind up with weird and undocumented behaviour.

RSS is a nice exception to this - an XML application that's truly easy to use and behaves like you would expect it to. Maybe that's one of the reason's it's become so popular too (it's actually usable!).

If I had to make a list of technologies I've wasted the most time fussing with, XML would probably take the cake. Only to eventually switch to something else, or drop the project completely.

The problem is, I really like this idea of a Web.2 genealogy app, so I'm not giving up. I sincerely hope this doesn't turn into vaporware...

* Snapshots. This feature was the reason people originally thought it was behind Time Machine.

"A snapshot is a read-only point-in-time copy of a filesystem which takes practically no time to create and uses no additional space at the beginning. Any snapshot can be cloned to make a read-write filesystem and any snapshot of a filesystem can be restored to the original filesystem to return to the previous state."

Because this is implemented on the fs level, it's very fast and totally transparent.

* Dynamic striping. ZFS not only promises much improved consistency, but also performance. Dynamic striping allows to write to all devices in a "pool" simultaniously.

Here's a nice 10-point list of the advantages and a Flash animation of ZFS in action.

Boot support is not actually implemented in the FS. Because it's such a low-level thing, it has to be implemented in the actual hardware (ROM). This is definitely something that will set the PPC and Intel Macs apart one day since the Intel machines have EFI which is a modern programmable BIOS that Apple will probably one day update to support booting from ZFS.

Stumbled across this cool project while browsing through Apple's Software downloads section. From the project's homepage:

Software for Starving Students is a free collection of programs organized for students (but available to anyone). We've gathered a list of best-in-class programs onto one CD (one disc for OS X, one for Windows), including a fully-featured office suite, a cutting-edge web browser, multi-media packages, academic tools, utilities and more.

I think this is a terrific idea. In this broadband world it's easy to assume that everyone knows exactly what to download and where, but it's not the case. At our school, there's plenty of people who don't have broadband access so burning something like this at school to install at home would be extremely useful.

The past few days have been weird. Got a really great idea for writing a hwmond replacement called servermond that would allow you to use at least some of the functionality of Server Monitor on any hardware. So far so not good. Getting the SSL decryption to work to reverse-engineer the Server Monitor protocol has been unsuccessful due to, quite frankly, lack of tools. ssldump won't compile straight, tried the macports version but that won't run. Finally managed to install ettercap (which seems like an awesome piece of engineering) but it hasn't helped me yet... This made me think why there's still no Mac native front end to any of these powerful free programs.

Plus, the cigarette addiction's kicking in again. I've been off it for about a year now but the past 5 days I've felt like I quit last weekend or something... Weird.

But to not feel totally unproductive, I've decided to roll out the first public version of Itch - my little Python script for XChat Aqua. Named thus not only because there were a few itches that I wanted to scratch in XChat, but also because it's my first ever Python script (and itchi means "one" in Japanese). Itch features:

• 
  
• Simple iTunes and QuickTime Player announcement. /np send nick will try and dcc the current tune to nick.
• 
  
• /away management (hitting /way toggles you away with a timer) with logging
• 
  
• Hardware (ioreg) and software (system_profiler) monitoring and specs. Just try /hw and /sp for the possible switches. These are not echoed to the channel.
• 
  
• iTalk. This was actually pea's brilliant idea. /isay will convert anything you say into "i-talk". iFor iExample iLike iThis.
• 
  
• Finally, /day will show you what's happened today in history (data from /usr/share/calendar/calendar.*)
• 
  

There's a few other features that I want to add in there, but the existing ones were "stable" enough to release it into the general public. I consider it my little Christmas present to the Mac IRC population. ;-)

Q: Is it possible to read the hardware sensors from the Terminal, without any 3rd party help?
A: Yes it is.
Q: Mmkay, but how?
A: I'm glad yo asked. With ioreg and a few extra utilities, like awk:

ioreg -n IOHWSensor | awk -F "=" '/\"current-value\" = (\d*)|\"location\" = (\d*)/ { print ($2); }'

That will output:

 3031040

 "HDD BOTTOMSIDE"

 3309568

 "CPU TOPSIDE"

 3440640

 "GPU ON DIE"

 80033

 "CPU CORE"

 307429376

 "REAR MAIN ENCLOSURE"

 1900544

 "BATTERY"

As you can see the numbers don't make any sense. And this where the amazing "Mac OS X System Internals" comes in. In chapter 10.7 "A Programming Tour of the I/O Kit's Functionality" (page 1307) we find that the values should be bit shifted right by 16. So here's another example, in Python, with the bit shift applied:

import commands

ioreg = commands.getoutput ('/usr/sbin/ioreg -n IOHWSensor')

k = re.findall ("\"location\" = \"(.*?)\"", ioreg)

v = re.findall ("\"current-value\" = (\d*)", ioreg)

   

aDict = dict (zip ([lower (el) for el in k], [int (el) >> 16 for el in v]))

Giving us the temps in centigrade:

{'gpu on die': 52, 'battery': 29, 'cpu topside': 49, 'rear main enclosure': 4732, 'cpu core': 1, 'hdd bottomside': 46}

This code also wraps the results in a nice Python dictionary. 'rear main enclosure' is obviously the RPM of the only fan this machine has.

Here's the output from running the shell command on a G5:

476

 "CPU T-Diode"

 107

 "CPU Current"

 823

 "CPU Voltage"

 124

 "Slots Power"

 2097152

 "DRIVE BAY"

hw_prefs machine_type

Many thanks to all the people who helped me piece this one together!

This one is easy, but so important but used so rarely that you have time to forget it. How to build a table programmatically with a certain number of columns, with only one while - loop:

<table style="border: 1px solid black">

$i = 0;
$col = 4;
$val = 20;
$table = null;

while ($i < $val)
{
        $i++;
     $table .= '<tr>' + ($i % $col == 0) ? "<td>$i</td></tr>" : "<td>$i</td>";
}
print ($table);
?>

</table>

value = 0

def setValue():

    value = 1

setValue ()

print value

What's that gonna print? That's right - 0. Must use global instead:

value = 0

def setValue():

    global value

    value = 1

setValue ()

print value

It's actually the exact same with PHP:

$value = 0;

function setValue () { $value = 1; }

setValue ();

print ("value: " . $value);

My brain tells me that if something's been defined previously, then we should be referencing that thing instead. It's not like I'm explicitly using different namespaces in - and outside my function. Like with JavaScript.

useradd.sh and freplace.sh. The first is a simple CLI utility for creating users and the second finds and replaces files.

> ./useradd.sh 

Usage: sudo useradd.sh [-u uid] [-g group] [-a] [-c] [-d home] [-s shell] [-rn realname] name

-a makes new user an administrator.

> ./freplace.sh

Usage: freplace.sh [-sb] [-o owner:group] -d indir target replacement

Replaces target in directory indir with replacement. Has a few extra features as well. Both are still pretty basic, but serve a purpose and I'll probably keep updating them. Handle with care.

1) To allow only FTP access to a share (AFP/FTP/SMB):

$ sharing -e sharename -s 010

2) All the configuration files are in /Library/FTPServer/Configuration
3) "man ftpaccess" had some useful info on the different chrootType values:

chroot_type standard | homedir | restricted

            Sets  the type of restricted environment the user is under when he

            logs on.  standard Allows users to  access  the  ftp  root,  their

            homedir,  and  sharepoints.   homedir  Allows  users to access the

            their homedir and  sharepoints.   restricted  restricts  users  to

            their own home directory.

and they all work with serveradmin:

$ serveradmin settings ftp:chrootType = "HOMEDIR"

via erki.lap.ee.

I've been struggling with building universal (fat) binaries on OS X for quite a while now. Finally decided to sit down and figure this out. In a situation with many variables, it's often good to stop and try to "crystallise" the problem at hand. What better way to do this than with a Hello World - if that won't compile and link, then why should anything else, right?

#include <stdio.h>



int main (void)

{

        printf ("Hello, world!\n");

        return 0;

}

Then we compile:

> gcc hellow.c -o hellow

> ./hellow 

Hello, world!

> file hellow

hellow: Mach-O executable ppc

So far so good. Now let's see if we can make a fat binary out of this sucker:

> gcc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 hellow.c -o hellow-fat

> ./hellow-fat 

Hello, world!



> file hellow-fat 

hellow-fat: Mach-O fat file with 3 architectures

hellow-fat (for architecture ppc):      Mach-O executable ppc

hellow-fat (for architecture i386):     Mach-O executable i386

hellow-fat (for architecture ppc64):    Mach-O 64-bit executable ppc64

Hmm, that wasn't so bad. I guess here is where the "fat" in "fat binary" comes from:

> ls -lhS hellow*

-rwxr-xr-x   1 filipp  filipp    44K Dec 12 13:45 hellow-fat

-rwxr-xr-x   1 filipp  filipp    13K Dec 12 13:46 hellow

-rw-r--r--   1 filipp  filipp    80B Dec 12 13:21 hellow.c

Well, that turned out to be a useless experiment. At least I know that my cross-compiling support works now...

OK, so this one started with a rather ominous message in /var/log/mailaccess.log:

Dec 11 15:33:47 gw mbpath[4439]: DBERROR: critical database situation

Stopped the server, tried a db rebuild. Nothing. Noticed a "no space on device" error, indeed df confirmed it. On to finding what's taking up the room:

gw:/Library/Logs root# du -hc -d 1 /              

  0B    /.Trashes

1.5K    /.vol

318M    /Applications

1.5K    /automount

3.5M    /bin

  0B    /cores

2.0K    /dev

  0B    /Groups

1.8G    /Library

2.0K    /Network

 21M    /opt

 45G    /private

2.2M    /sbin

112K    /Shared Items

1.1G    /System

9.0M    /Users

1.6G    /usr

5.7G    /Volumes

 56G    /

 56G    total

Could it really be the logs? Yups:

gw:/Library/Logs root# du -hc /private/var/log/samba/log.*

68K    /private/var/log/samba/log.nmbd

624K    /private/var/log/samba/log.smbd

44G    /private/var/log/samba/log.smbd.old

44G    total

Yikes! Deleted log.smbd.old and thanks to some avid GNU/Linux users, was able to get things working again:

gw:~ root# nano /etc/smb.conf

[global]

        bind interfaces only = true

        interfaces = en1 192.168.0.1

        hosts deny = all

        hosts allow = 192.168.0.1/24

OK, so you've got trillions in the bank and you're taking orders for your next big cash cow. You set up a website, with the product packaging, marketing text and compulsory generic humanoid photo, then you have your graphics team come up with the necessary buttons and icons:

No, wait, that can't be right. That little icon looks just like:

...THE FRIGGIN WORKGROUP MANAGER ICON! And it doesn't just look like it - it is the same one. Converted to GIF and different filename. What the hell is wrong with M$?! I just can't understand why they still can't hire decent designers. You can get a fantastic icon set for less than 50 USD!!! I'm sure this is just another silly mishap, but given the company's track record in "such things", it's kind of a touchy subject. But maybe some people will never learn...

Stumbled across this bit of interesting information. Two interesting points - first, it's possible to embed thermal sensors onto a memory DIMM:

"In order for the Mac Pro to maintain a safe operating temperature of the FB-DIMMs, the AMBs for each FB-DIMM must provide a functional temperature sensor."

This is thanks to the SPD (Serial Presence Detect) chip that's on every DIMM that also supports the I2C protocol.

Second, the Mac Pro will spin up it's fans to maximum rev if it can't find the sensor:

"The Mac Pro will run the fans at full speed when detecting FB-DIMM's without a functional temperature sensor, which will maximize cooling on the FB-DIMM's."

BBEdit's probably my most important tool. Even though an editor is such a basic thing that it's almost kind of silly to be attached to one, you just get used to it over time and it's nice to constantly be finding new features and ways to use a tool.

I can easily have upwards of 20 documents open simultaneously - sometimes part of the same project, mostly not. This makes you weary of actually closing the app because what if you want to pick up exactly where you left off? Well, luckily, like so many things in life, this problem too can be solved with a little bit of AppleScript:

property theDocuments : {}



tell application "BBEdit"

  if (count of document) is greater than 1 then

    set theDocuments to file of every document as list

  else

    open theDocuments

  end if

end tell

Just run that after and before every session you want to restore. If you have documents open, it'll save them, if not, open the ones you had open the last time. It's very crude but gets the job done for now. Naturally they don't work with Trasmit links etc because those are just temporarily open.

Properties are wonderful in AS because they are reinitialised only when the script is compiled. That makes them perfect for any kind of "temporary" persistent storage.

Sending cookies - you can do it with file_get_contents () - just look at the stream functions' constants (the context parameter). But I found out it's much easier using the curl plugin (which isn't always available, btw, but neither is file_get_contents ()):

$c = curl_init ($url);

curl_setopt ($c, CURLOPT_VERBOSE, 1); // For testing

curl_setopt ($c, CURLOPT_COOKIE, "variable=value");

curl_exec ($c);

It's that simple. An awesome tool for creating all kinds of site parsers.

You can stitch one together with the following components:
Apple's X11 + AquaTerm + Gnuplot 4 + Octave

It's all here.

I developed my initial idea sometime in 2004. It was supposed to become a search-based file browser prototype and I was really excited about it. The idea wasn't totally my own actually - Kadri was the one who asked the first question why file management has to be so hard. For the "average user" it shouldn't matter where something is or what it's extension is - it should "just work". We decided that folders could actually be saved search queries. I actually got some time to parade this idea around until 6 months later - Apple introduced Tiger for the first time and you already know the rest...

My next plan was to build a knowledge base application. This was born out of a practical need for documenting experiences in the service shop I used to work for. The idea was great - make a Core Data -based app with an iTunes/Outlook Express-like UI that'd make entering information really simple and fast. Add tag support for indexing and automatic categorisation and a little check-box in the preferences that would allow you to share your knowledge to the local sub-net. And then I discovered Yojimbo. It's basically the same thing sans the sharing and cataloguing. Since I had already started to work on this, I decided to keep going and concentrate on the theory part. The subject is quite interesting and while there's a lot of info out there on ontologies, little (or actually none at all) practical P2P examples/applications exist. But then my greatest fear realised - I got bored. Being a geek, I'm used to and enjoy building things. I can't sit behind a paper for days and just write specs and explanations, knowing that this will all only work on paper... So I sent them my ideas and BareBones was kind enough to answer and analyse my ideas and give some insight into their design decisions. Thanks!

So I changed the topic once again. The working title is "Anatomy of Digital Video". It's a handbook for anyone dealing with the inner workings of video and file formats and I think it's pretty good and useful. I hope it was a good move - if nothing else, I've been able to write 10 pages in the first week, which is twice as much as I was able to conjure up in 6 months with my previous topic. There will also be a practical side to this. A QuickTime -based playback app that does playlists, batch-encoding and subtitles.

And the moral of all of this? Long-term projects are hard, especially for a "starter" like myself. Working alone certainly has it's merits, but it can also be very stressful and error-prone. If you do (or have to) take on a big project yourself, by all means, do it, but try to "keep it interesting" for yourself. Trust your instincts - if you feel that the topic is "hot", get a prototype out as fast as possible. Concentrate on the core idea and leave all the polish for a later time. Document as you go.

JavaScript - Associative Arrays Considered Harmful

The reason I stumbled across this was that Apple's QuickTime Embedding JS has this problem. The symptoms look crazy - you'll have other JS code inside your embed tag. This happened to me when using Prototype. The fix is easy - just replace "new Array ();" on line 165 with "new Object ();"