Dat werkte, maar echt handig was het niet: AppleTalk is behoorlijk traag en wordt door Apple zelf niet meer serieus onderhouden. Mac OS X kan er nog mee overweg omwille van de communicatie met oude systemen, maar bij de UNIX-variant die het besturingssysteem feitelijk is, hoort natuurlijk NFS.

Vorige week verving ik de dualboot-setup (Fedora Linux en Windows XP Pro) op mijn desktop door de nieuwe Ubuntu, en besloot ik het nog een keer te proberen, en dit keer met meer succes.

Voor wie met de materie worstelt, lees verder!

Installeer eerst een NFS server, bijvoorbeeld vanuit een terminal:

sudo apt-get install nfs-kernel-server

Configureer dan je shares. Open /etc/exports in je favoriete teksteditor:

sudo vi /etc/exports

De algemene syntax is simpel:

/share host(option1,option2)

Waarbij host staat voor de client(s) die je toegang wilt geven, bijvoorbeeld in de vorm van een hostname, een ip-adres of een compleet subnet.

De precieze syntax is te vinden in de manpage voor exports(5). Belangrijk is in ieder geval de 'insecure'-optie. Mac OS X verbindt met NFS via hogere poortnummers, wat NFS-servers doorgaans niet toestaan tenzij je dat expliciet instelt. Denk, voor schrijftoegang, ook aan de optie 'rw'.

NFS kent geen wachtwoordauthenticatie, maar kijkt naar de UID en GID van gebruiker van de client. Stemmen die overeen met die van de eigenaar van de share, dan heeft de gebruiker normale toegang.

Elders op internet (ik ga niet linken) wordt daarom wel geadviseerd om je UID op je Mac te veranderen. DOE DAT NIET OF WEES VOORBEREID OP GROOTSCHALIG PUINRUIMEN!

De juiste manier om dit op te lossen is via mapping. Je kunt de NFS-server opdragen om client-ID's te vertalen naar andere ID's.

De simpelste configuratie vertaalt iedere client naar dezelfde UID en GID. Welke ID's de server kiest, is gelukkig in te stellen. Gebruik daarvoor de volgende drie opties:

all_squash - vertaalt de ID's van iedere client naar dezelfde waarden
anonuid=n - zet het UID op n
anongid=n - dito voor GID

De UID/GID van de eigenaar van mijn share zijn 1000/1000, dus /etc/exports ziet er op mijn server als volgt uit:

/share host(rw,insecure,all_squash,anonuid=1000,anongid=1000)

Exporteer dan je shares vanuit een terminal met:

sudo exportfs -ra

Of start of herstart de NFS-server met:

sudo /etc/init.d/nfs-kernel-server restart

Verbindt vervolgens vanuit de Finder op je Mac (Appeltje-K) met je NFS-server (nfs://server/share). Een kind kad de was doen.

iTunes is een fijn ding, maar (1) ik zou willen dat er een Linuxversie was, en (2) de documentatie laat veel te wensen over.

~ $ mkdir beatles
~ $ cd beatles
~/beatles $ mkdir john
~/beatles $ mkdir paul
~/beatles $ cd ..
~ $ mkdir stones
~ $ cd stones
~/stones $ mkdir mick
~/stones $ mkdir keith


Maar gewoon:

~$ mkdir -p {beatles/{john,paul},stones/{mick,keith}}

(Deze en andere tips via IBM)

Een doodsimpele manier om filters te omzeilen, maar toch hebben spammers lang gewacht om deze methode toe te passen. Plaatjes rondmailen kost immers veel meer bandbreedte dan traditionele spam. Dat ze nu toch massaal hun toevlucht nemen tot deze methode, is in zekere zin dus een overwinning voor spambestrijders: tekstgebaseerde filters zijn zo goed geworden, dat ze zich niet meer om de tuin laten leiden door de wartaal waar de eigenlijke boodschap bij tekstgebaseerde spam doorgaans in verstopt wordt.

Maar een Pyrrhusoverwinning is het wel, want ondertussen stromen onze mailboxen vol met troep, die ook nog eens veel meer diskruimte in beslag neemt dan tekstgebaseerde spam. Gelukkig vond ik deze slimme tip om Thunderbird de image spam te laten herkennen. Werkt - met enige aanpassing - ook in Mail.app (Mac), en waarschijnlijk de meeste andere mailclients.


<xsl:template match="header">
(...)
<script type="text/javascript" src="foo.js">
<xsl:comment></xsl:comment>
</script>
</xsl:template>


Output:

<script type="text/javascript" src="foo.js"><!----></script>


(Aan deze steen heb ik me de afgelopen jaren méér dan eens gestoten, dus ik post het maar even hier, zodat ik het nooit meer vergeet (en voor Google). Het zijn de laatste dagen bij mijn huidige werkgever (waarover later meer), en ik heb het erg druk met de afronding van mijn bezigheden. Dan kun je dit soort stomme bugs er eventjes niet bij hebben.)

Ook irritant: IE converteert relatieve naar absolute URI's. Dus object.getAttribute("href") levert niet de tekstwaarde van het href-attribuut op ("example.html"), maar het volledige adres ("http://www.example.com/example.html"), ook als die helemaal niet in je code staat. Een extra parameter (object.getAttribute("href",2)) lost dat op.

Dat u even weet waar ik het toch zo druk mee heb.

Wat ik nog niet wist, is dat dergelijke stijlregels in de developer builds van Firefox en Mozilla (1.8a3 en hoger) ook per site, en zelfs per URL in te stellen zijn.

Om bijvoorbeeld de titels van alle postjes op deze site (en alleen op deze site) in het rood weer te geven, stopt u deze CSS in uw userContent.css:

@-moz-document domain(log.alamagordo.org) {
	h2 {
	     color: #f00 !important;
	}
}

Dat opent enorm veel mogelijkheden. Je kunt zo bijvoorbeeld niet alleen advertenties zelf van pagina's verwijderen, maar ook de lege tabelcellen waar ze in stonden. Tot nu toe kon dat niet, omdat er geen methode was om de tabellen van site www.example.com wél te weren, en die van www.example2.com niet. De grote witte gaten midden in de content van menige krantenwebsite behoren straks dus tot het verleden.

Ik vond elders op het web al een heel nuttig truukje om berichten in GMail weer te geven in een letter met een vaste breedte, in plaats van het (proportionele) standaardlettertype. Daardoor is het eindelijk mogelijk getabuleerde code te mailen, zonder dat de leesbaarheid verloren gaat:

@-moz-document domain(gmail.google.com) {
	div.msg div.mb {
		    font-family: monospace !important;
		    font-size: 12px !important;
	}
	textarea.tb {
		    font-family: monospace !important;
		    font-size: 12px !important;
	}
}

Het schijnt de bedoeling te zijn dat Firefox 1.1 deze methode ondersteunt. Tot die tijd werkt het alleen in recente testversies, en ontbreekt goede documentatie. U vindt meer informatie in bug 238099 en dit bericht op een mailinglijst van het W3C.