« March 2008 | Main | May 2008 »
Got to love science:
Men who said they had sex twice a week had a risk of dying half that of the less passionate participants who said they had sex once a month, Dr. Davey-Smith’s team said.
via Justin Mason.
So, print a couple of copies of the study before you leave for the pub/bar tonight. You got science on your side now.
Yesterday, Rui pointed me to two applications/services that immediately found a place in my Applications folder.
The first is Yuuguu. Its a screen sharing application that just works. You install the client (Windows, Mac. You can also use the web server), create a free account and add your friends (by email address). That's it. You can now share you entire desktop with any of your friends. Essential for those support calls you get from your family members.
The second one is PortMap, a free application from the CodingMonkeys (of SubEthaEdit fame). It allows you to open services running on your desktop when you are sitting behind a NAT gateway. It will use NAT-PMP or UPNP to map a public port to your private address.
PortMap is the end user application. They also made available the Framework they created around the code that does this magic. I should point out that Leopard has this functionality built-in (point from João Pavão, the Cocoa guru at hand).
I'm a big fan of DevonThink. I've used the Pro version for two or three years now, to store my web clippings, my own personal Google.
Yesterday, I read through the Evernote review at AppleInsider and it looks like it could be event better. My favorite feature is the bookmarklet that lets you select part of a web page inside Safari, and send to the Evernote server.
I love this combination: a web service to store all this data, and a companion desktop application to ingrate perfectly with my environment.
I'm not a expert on MySQL, but I spent a better part of this past night optimizing a server, and I've collected some notes. This is mostly targeted at InnoDB-based tables.
To change this settings, you should edit your my.cnf and update them in the mysqld section. See the MySQL System Variables manual page for more information. Please remember to keep a good working backup of your previous my.cnf. Better yet, include your my.cnf in your source control tree. I assume that you already have tested backups of your data...
So, do this steps:
innodb_buffer_pool_size;innodb_flush_method=O_DIRECT;echo 0 > /proc/sys/vm/swappinessecho 'vm.swappiness = 0' >> /etc/sysctl.confThese are the basic settings that I pay attention to. Of course there is much much more settings that you can tune (transaction-isolation and innodb_flush_log_at_trx_commit come to mind), but the things above will cover most of what you need.
After this, you should also use the mysqlreport tool. It requires more investment on your part, understanding the data, but its very thorough.
Finally, install Maatkit and get used to the tools it provides. They are essential if you are using replication.
My favorite XEPs of last year where PIP (XEP-0223) and PEP (XEP-0163). These two made Publish-Subscribe (XEP-0060) trivial to implement on XMPP clients, and pave the way for rich-presence clients.
One problem was that open-source servers did not implement PIP/PEP. Recently this has changed, with both Openfire and ejabberd having decent implementations. Other servers, though, are still MIA.
Also of note, GTalk does not supported it yet. This is a bit of a problem due to his visibility in the XMPP community.
So if you do implement it in your client (and I think you should, really), it seems that you have to keep using the current protocols for avatar (for better or worse XEP-0054 plus XEP-0153) and server-side storage (XEP-0049).
There is something that servers could do to improve this situation though. There is a small change that would give client authors even more good reasons to implement PIP/PEP today.
If private storage and vCards are implemented on top of PIP and PEP, we could have the best of both worlds.
From the point-of-view of current clients, nothing will change: they will still use XEP-0049 to set and get their private storage nodes, and they will still use XEP-0054 to publish and retrieve their vCard. But at the same time, each private storage item would also be available in a PIP node, and the user vCard would be available in a PEP node.
This would allow PIP/PEP-capable clients to announce support for vcard-temp+nofity namespace in their disco response, and get instant notifications of vCard changes. Also, announce storage:bookmarks+notify and clients that only support version 1.0 of XEP-0048 will immediately support version 1.1.
This could be a easy way to increase supply of nodes, to see if we can reach critical mass sooner, in the move to a pubsub-world.
In case you missed it, check your Software Update, there is a important Safari upgrade in there.
I classify this as "important" not because of the security fixes included, but because Mail.app is now working properly again.
With the last Safari 3.1, I stopped being able to paste plain text inside a mail message. I would copy something from TextMate or a Terminal window, and when I pasted it into a Mail.app message window, the line breaks would be lost.
This is most likely related to the same bug that Gruber complained about.
Anyway, Safari 3.1.1 fixes it, so I would strongly recommend that you upgrade to it.
A friend of mine was complaining that he could only upload a file to my server at 2Mbytes/sec with his FIOS link at home. Some people have interesting "problems".
Anyway, I send him my /etc/sysctl.conf that I have on my Mac for quite some time without any problems, and with significant gains in network performance on my local LAN (specially for other computers with Gigabit ethernet).
net.inet.tcp.mssdflt=1440
kern.ipc.maxsockbuf=800000
net.inet.tcp.sendspace=400000
net.inet.tcp.recvspace=400000
Stick those lines in your /etc/sysctl.conf and they will be active every time your Mac reboots. Make sure you place them on all your Macs. To activate them right now, run this:
sudo sysctl -w net.inet.tcp.mssdflt=1440
sudo sysctl -w kern.ipc.maxsockbuf=800000
sudo sysctl -w net.inet.tcp.sendspace=400000
sudo sysctl -w net.inet.tcp.recvspace=400000
You should see network a better network throughput immediately.
There is a fifth setting:
net.inet.tcp.sockthreshold=0
but I admit not to fully understand the implications of his use. Apparently without it, the sendspace/recvspace settings would not work, but my tests tell me the oposite. I'll update this when I do know if/when to use the one.
For reference, a local FTP transfer to a 100Mbit server was not using all of the bandwidth. With just the first line, I was able to saturate the server link. With all the lines, over a gigabit ethernet link, I was able to reach 35Mbytes/sec between two Macs. Without: a meager 6Mbyte/sec.
All the gory details are available in a study by the Pittsburgh Computing Center.
Update: sorry, miss-typed the values, remove the extra zero.
I've been a bit under the weather this week. Something inside not quite right, nothing major.
But after seeing the stupid internal Microsoft Vista SP1 video, I feel the need to rush to the bathroom and throw up. I don't believe that anybody really expect this sort of "inspirational" video to pump up your sales team, do they? It's like the monkey dance all over again.
I'm a fan of Bruce Springsteen (I was a very impressionable teenager in the 80's, so sue me) and I fell that some sort of lawsuit is in order here.
iCal has an option to extract birthday dates from the Address Book and create a calendar.
Maybe I'm missing something but given that there seems to be no way to set a default alarm on those items (like 1 day before or on the day itself), isn't this a very stupid feature? I mean, I don't live inside my iCal, it might work for people who do, but I don't.
I guess I need to publish the calendar to some service that lets me add the alarms... Oh well...
Andy Lester wrote an article a couple of days back about rethinking the CPAN interface. The key part of the argument is:
We don't want to "make CPAN easier to search." What we're really trying to do is help with the selection process. We want to help the user find and select the best tool for the job
I though a bit about this and my own CPAN usage over the years. I've started with Perl around 91 or 92 so I've used it a bit.
I don't know the answer for this one, but I would start with the Perl module version of the iusethis site: each person could select the list of modules that they use.
This first approach would start shuffling modules to the top.
You could then ask each person to classify why are they using the module. This is the hard part because you would need to come up with a classification scheme, like the one we still have for CPAN module, actually. It will never be perfect but I prefer to have 10 or 20 common things like "Parsing XML", or "Sending MIME email" than nothing.
An optional improvement would be to have a 4 or 5 level rank, inside your own module list, to allow you to say that, DBI is much more important than CPAN::Mini.
Another layer would be some sort of social angle. This is not to make the site look hype and fresh, but to help find new modules. I could watch a couple of persons I trust and see what are the modules they are using and the most recently added. Instead of looking through 50+ modules updates per day, I just see a filtered list of potential targets.
A final twist - a aging digg-like system: I can "This saved my bacon today"-vote on any module, but my vote would only be counted for a month, giving rise the the Bacon Savers list.
But as always, you need a carrot to make all those perl programmers compile their module list. There are two immediate carrots that I can see:
cpan to do the heavy lifting.Anyhow, this are my €.02 to the conversation.
Well, the kid is out of the bag.
Congratulations to all the the Carmo house (or at what is left of the house, thanks to the wonderful species that are contractors).
Anyway, after two kids myself, I enjoy seeing new parents, in a sadistic kind-of-way.
Unfortunately Rui has already set some pretty harsh rules, ruling out any kind of Perl adventures. Thats just not fair, he could learn so much with Uncle Melo (and now thats an even scarier picture in Rui's mind...).
Sleep, that's for kids.
Remember when Plazes appears a couple of years ago? Quickly the got a lot of mac addresses geo-referenced.
Now you can go through all that work again, but this time to improve the service that Skyhook provides to his customers, like Apple with the "Locate me" button. Just fill this form and be happy.
Speaking of Plazes and mac addresses, now you can map you location using Plazes with a mac address or any other unique network identifier, like a bluetooth ID, or the mac address of an appliance or office server, or a GSM tower ID. Its all due to the love of the new plazes.net site.
I wonder if Apple will add a "Improve my location" button to the Maps application. You could tell the service, "No, I'm actually here", the iPhone/iPod Touch would scan the near by mac addresses, GSM IDs and send them to Plazes and Skyhook.
This would be an interesting App to develop with the new SDK, if anyone is looking for an idea.
From The economics of high-end prostitutes:
Spitzer spent more than $80,000 on high-end prostitutes in one year. That's a lot of bank withdrawals.
I would say that its a lot of deposits, but hey.
Apparently this is not a April's 1st joke. Nor is this.
I would think that the Mozilla guys to be a bit pissed at Epiphany for dropping Gecko, but hey, meritocracy, right?
Speaking of GitHub, they are now open for business.
With the official launch they enabled a couple of features that had been discussed in the past: commit comments (I still don't know if I like them or not), and integration with Campfire and Lighthouse (although you can also roll-your-own integration using their hooks).
One feature though, was not on the roadmap, and its a beauty: an network graph visualizer.
Its a great view across several repos, and it works very well. As far as I know there is no tool on the desktop that gives the same view. Not even gitk.
Most excellent.
I usually like chromatic articles about language design and his work in Perl6. As an example, just yesterday he committed a 20% improvement on the Rakudo build time.
But last week, he wrote the following about GitHub:
A centralized repository for a distributed version control system! Why didn't I think of that?
I think that he is way off base on this one.
Distributed version control systems are not incompatible with a centralized repository. You can use them with a centralized repository and most projects will still keep a central point for coordination of releases. In the Linux kernel project, for example, that central point is Linus tree.
The difference between a centralized VCS like Subversion and a DVCS is that you are not forced to use a centralized repository, and if there is one, its just a social decision, not a technical one.
I certainly agree that almost any project will want a "central" repository in the sense that you want to have one canonical default source base that people think of as the "primary" source base.
But that should not be a technical distinction, it should be a social one, if you see what I mean. The reason? Quite often, certain groups would know that there is a primary archive, but for various reasons would want to ignore that knowledge: [cut]
But even for smaller projects, the usual and recommended setup is:
git init a directory somewhere;Basically, you work on your own local repositories, you keep a public version of this repository somewhere online, and others pull from this one. Usually, unless you are on the same LAN you don't pull directly from each other private repos. You can do it sure, but its just not common, mostly because people usually work behind firewalls or NATs.
So GitHub (and Gitorius, and repo.or.cz) is a place to have the public versions of your repos.
And a very good one at that.
The 1.6.0 release of Cairo moved the Quartz back-end from experimental to supported.
This is very good news for me because some nice Perl modules for charts use Cairo.
If you are using FF3 betas on a Mac, you're already using Cairo by the way.
Update: an article from one of the authors.
Eh:
To get a sense of just how expensive even such a limited fiber rollout can be, consider than telecom provider KPN in the Netherlands will expand from 1,350 local exchanges to around 28,000 in order to launch VDSL service. That's a lot of trench digging and cable laying to bring the fiber further into the neighborhood, making this a nontrivial upgrade.
Thats what I call an upgrade... 26k new POPs. I still remember all the trouble it gave the ISP I worked at in 98' to upgrade from 10 to 50 POPs.
oh, the fun.
Some friends complain that I talk a lot about Git, so to even out a bit, I'll talk about my current favorite Website.
Yes, amongst all the sites I know or visited, there is one that takes the title "Current favorite", in the singular form.
Its Freebase. Its a Wikipedia with a decent database schema. You can query it in much richer ways, like "Directors of $10M+ companies who have starred in movies" (the query for this can be seen on the left, as "Show this query in MQL"), or "Graduates of Stanford born since 1960 who are board members of companies".
Lately a couple of articles on their blog caught my eye (in reverse chronological order):
If you want a quick tour, checkout a recent Freebase screencast.
After that, check out the cool toys^H^Hols other people have written using Freebase.
Recommended.
I admit: I still don't see what is all the fuss about Twitter.
Twitter is like a selective (your followers only) shout command of old Moo's, but it seems to me to be a drain on productivity. If you think IM can be bad, well, you haven't seen nothing yet.
But I'm still there trying to get it. I wonder if there is really something to get at all.
For now, I cut my following list to about 30 people who are either close friends, or with whom I work constantly. I've also included a couple of so-called-A-list-bloggers that I read. This and going to the settings page and disabling the @ messages cut down the twittering to an acceptable level.
Lets see how this works out for me.
Last February, Google's Android Team shocked the XMPP world by having the gall of saying that they where moving to a Binary encoding of their GTalk API in the M5 release.
Of course this sent shock waves through the XMPP community, not because they where totally wrong, but because they didn't have the vision to solve it.
We of course understand that they have their hands full (of vapor, some bad mouths would say...) getting the platform in shape for the late 2008 release, and the XMPP.. err, sorry, GTalk protocol is not a top priority.
Well, today Android users around the world can rejoice because once again, the XMPP Standards Foundation has risen to the challenge and unveils to the world the solution to the "verboseness" problem, by introducing the breakthrough Binary XMPP protocol.
This has been in development for quite some time, taking long hours of (sometimes) heated discussion. The goal is to have something that nobody could ever accuse of being verbose (the symbol count is extremely low, and the meaning is clear from the start), but at the same time remain compressible for those extreme cases where bandwidth is at a premium (we tested, and we have code to prove it: a Binary XMPP stream can be compressed to 2% of its original size). We know of clients that live in five-sides-shaped-buildings that, with their hard 9600 baud limits, will be the first to use this.
Its been a great ride, and it feels me with immense joy to be able to put my small signature as a co-author of this spec. Of course, my part is extremely small when you have the documentation genius of Peter Saint-Andre, and Fabio Forno strict guidelines and requirements, as co-authors. Its been a pleasure to work with both on this. And I should also thanks the important Kevin Smith contributions.
And now time to rest. SRV records are up at simplicidade.org domain, and Fabio's CM is running also.
PS: and yes, now you know why the prolonged silence around here.
PPS: for those who have moved on, the code is also available on GitHub.
