Google's built-in page previews — reason for releasing Chrome?

Leave a reply

After all the years we’ve had Firefox plugins to insert page previews into search results, Google finally added their own. They dubbed it “Instant previews”. These previews are vertically larger than what any of the plugins did before, they include enlarged select portions of text relevant to your query, and they appear only when you click on a search result text (not on the link). After that, you can just hover the mouse above search results.

So what I wonder is: could it be that Google embarked on a journey to build a hyperfast browsing experience in order to provide a better search experience? Or was Chrome really just a part of a larger scheme to collect customer data and statistically analyze it, as was thought previously? I’m not sure; probably it was “let’s build a browser first” and then “what can we use the browser for?” — but the idea that Chrome might be the developed in order to alleviate performance issues that using some other browsers might create running on Google’s servers does not strike me as impossible. This way, they can generate previews without creating a horrible, horrible impact that using some other browser might create.

I just wonder when we’ll be able to see the codebase they use for creating the previews, and will they even release it, considering that WebKit’s LGPL (derived from KHTML’s LGPL) does not require source code release unless the binaries are released; even then, if libs are dynamically linked, source code release is required only for modified library binaries. Still, having a free, usable off-screen rendered WebKit would be very useful. But oh — there is already such a thing, for example Origyn Web Browser (site seems down, here’s a wikipedia link)

Which XMPP technologies to use?

1 Reply

I’ve been writing a piece of software in order to perform a major upgrade of ZATEMAS, a specialized web app suite I’m a co-author on. Since there is a small community of users on it that might interact better if they had an opportunity to do so, I came to an idea to provide them with an instant messaging client built right into the browser, similar to Facebook Chat, Meebo Bar and Gmail Chat. I’ve picked XMPP as the protocol; better known as Jabber, this is the same protocol Google Talk uses.

Examining various options took a while. I’ve looked at Meebo Bar, and concluded that it doesn’t fit my use case, since I want users to be automatically logged in on a local XMPP server.

I’ve examined several clients. In the process, I’ve learned a bit about BOSH (the standardized method for using XMPP over HTTP), about Apache’s mod_redirect, and a bit about rules for doing cross-domain xmlHttpRequests in Javascript.

The only serious contender for the throne of the best open easily deployable web-based XMPP client is JWChat. This is a venerable old client which creates a popup and behaves much like a typical desktop IM client. This means it was unsuitable; there is no easy way to embed it in a page, yet preserve its state upon page switching.

This is actually the biggest problem I came upon. There seems to be no XMPP client nor library written in Javascript that can trivially handle page switching (which means destroying entire Javascript context); you cannot trivially serialize their state. Which is why I’m proud to announce a custom-made client, Z-XMPP. It’s already available for preview on https://bitbucket.org/ivucica/zxmpp, and will soon be available for preview on ZATEMAS. Its license is currently a custom one, hand-written, and most definitely not satisfying any open source/free software definition. That will change soon, as soon as I pick the right license.

That brings us to the other part of the XMPP stack. Which server to pick? Which BOSH connection manager to pick?

There are, really, two contestants in my arena when it comes to a server. First one is a veteran of XMPP, ejabberd. ejabberd is written in Erlang, and is massively scalable. It’s trivial to install and configure in Debian, and it supports a lot of cool features out of the box. It supports something called “shared rosters”, which basically means you can create groups in people’s contact lists that you, as the admin, can enforce to contain whomever you want. You can force people, for example, to see everyone else working in the company. This is a critical feature for ZATEMAS, just as is so-called “external authentication”. What I’m missing here is: external auth does not support fetching any attribute apart from basic operations with passwords (is it correct? please change it!), and vCard cannot be created from command line, only updated. This means I cannot trivially set people’s real names during an update run.

Obviously, ejabberd has flaws, and I cannot easily update it since Erlang is a language fundamentally different from any other I worked with.

So the second contender is a server I discovered only tonight. It’s Prosody, an extremely lightweight XMPP server written in Lua by a bunch of very friendly folks. I really like the attitude and personal approach the principal author of Prosody has, but that’s not all. Server’s source code looks extremely well organized, the server is quite featureful, and most importantly, it’s written in a language that mere mortals can understand. I’m not a big fan of Lua, but I can read it, and I can update it, especially when it’s so well written as Prosody seems to be.

I’m currently not very familiar with Prosody, but the fact that I managed to set it up very quickly and that it starts up momentarily… well, I think that we can hack a ZATEMAS-based external authentication module into it! Also, I think I might be able to better add my own debug functions, to easily see what I did wrong while developing my client.

Both ejabberd and Prosody come with a BOSH connection manager (the thing that translates HTTP requests into a continuous XMPP stream; a continuous XMPP TCP stream is something you cannot achieve from the web). So why another one?

Well, perhaps you want to log into Google Talk!

Yep, folks, that’s what PunJab allows: have your BOSH-based client log into any XMPP server. I must say I like PunJab; it’s written in Python. Despite that, its internals seem a bit less clear than Prosody’s, yet still manageable. PunJab does its job and does it extremely well.

So there you have it. Perhaps we’ll soon have an opportunity to talk about how to install Z-XMPP instead of just talking about why and how I’m working on an IM service 🙂

Until next time!

Is there a growing interest in GLDM?

2 Replies

Google Analytics says I’ve recently been getting some hits from Google with keywords “gldm login”. GLDM is my login manager which I left in a half-finished state last year; it’s free/libre/opensource software and can be picked up at http://sf.net/projects/gldm/. If you’d like to help, talk to me at gldm+blogpost@vucica.net.

What is GLDM?

Idea behind GLDM was to provide a solid backend for authentication with a well-designed API for dropping in custom-developed graphical themes. That is, the idea was that GLDM would be the backend (with some nice themes/theming engines coming with it), but that people would easily be able to develop their own theming engines. It’s supposed to be an alternative to XDM, GDM and KDM — that is, it’s a login screen for Linux.

Its target is a home user; thus, GLDM does not care for and does not suppot stuff like XDMCP. It’s also probably a little bit less secure, until someone security-conscious comes around and fixes that.

Acronym stands for Graphical Liberty Display Manager, to say that one is able to create the GUI with whatever technique that person wants, as long as it’s somewhat pluggable into the C++ code. It’s also a play on OpenGL Display Manager, but since I didn’t code a single theme that uses OpenGL, it would be a bit of a misnomer, especially since it was intended that you really don’t need to have anything to do with OpenGL.

At the same time, you could; one might design a beautiful 3D island, with ocean having reflection, refraction and other cool shader-based effects. Then, on top of that, adding flying letters or user icons during login, which are reflected in the water below.

In essence, GLDM should be a “Compiz for the login screen”!

Almost all “common home users” would love that; it might help convert people to GNU/Linux, or other UNIX based systems. Who knows — perhaps even Canonical would take GLDM as the default login manager. (Oh, human dream…)

So what if you are getting hits? What do we care?

It surprises me that this unfinished piece of software is getting my poor little blog some hits. It surprises me that it’s getting hits straight from Google. It surprises me that this is happening despite absolutely no chatter on the interwebs about this software. It surprises me that I’ve received no inquiries about it.

It confuses me about what I should do next: should I go back to developing GLDM a little bit (a bit troublesome since I’m a Mac user now)? Will interest go up? Is this perhaps just a Google having a glitch, a cough, giving me hope where there is none?

I’m really not sure. Well, I think it GLDM might still be resumed; there still isn’t a “Compiz for the login screen”, and the barrier to entry for potential theme developers might still be significant. GLDM could be the solution by offering simple, simple API for authentication, while allowing the developer to just plug in their existing code into GLDM to get authentication services.

Running Windows XP from physical BootCamp partition on triple-boot Macbook

Leave a reply

Warning: Attempting to boot from physical partition may damage data on your disk, both inside the partition you’re trying to boot from and off of it. Consider yourself warned!

I’m apparently running a somewhat unusual setup for a Mac user: MacOS, Linux and Windows.
$ sudo fdisk /dev/rdisk0
Password:
Disk: /dev/rdisk0 geometry: 30401/255/63 [488397168 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: EE 1023 254 63 - 1023 254 63 [ 1 - 409639]
2: AF 1023 254 63 - 1023 254 63 [ 409640 - 322003488] HFS+
3: 83 1023 254 63 - 1023 254 63 [ 322675272 - 59155896] Linux files*
*4: 07 1023 254 63 - 1023 254 63 [ 382093312 - 106303488] HPFS/QNX/AUX

To create a VMDK to access the fourth physical partition, containing Windows, I use the following command:

$ sudo VBoxManage internalcommands createrawvmdk -filename BootCamp.vmdk -rawdisk /dev/disk0 -partitions 4
In VirtualBox I also have to turn on APIC IO and pick ICH6 as the HDD controller. Partition also must be unmounted before booting.

Attempting to boot this results in an error. Windows’ bootloader sees us as having a three-partition setup, which is blatantly incorrect. One can edit BOOT.INI and tell Windows to use partition (3) instead of partition (4).

[boot loader]
timeout=3
default=multi(0)disk(0)rdisk(0)partition(4)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(4)\WINDOWS="Microsoft Windows XP Professional " /noexecute=optin /fastdetect

multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="Microsoft Windows XP Professional on partition 3"
multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="Microsoft Windows XP Professional on partition 3 - fast" /noexecute=optin /fastdetect
This results in a blue screen of death.

Creating a VMDK with VMware Fusion, then using its [name]-pt.vmdk file results in a successful boot. First clue is that VMware Fusion created a 32256 byte file, while VirtualBox created a 512 byte file. Googling reveals that 32256 is the size of the MBR. Hence, it could be that VMware simply copied 32256 bytes, as opposed to 512 bytes that VirtualBox took!

$ sudo dd bs=1 count=32256 if=/dev/disk0s4 of=BootCamp-pt-dd.vmdk
32256+0 records in
32256+0 records out
32256 bytes transferred in 0.203430 secs (158561 bytes/sec)
$ cmp -l BootCamp-pt-dd.vmdk BootCamp-pt-vmware.vmdk
451 356 55
467 257 55
483 203 55

So that isn’t the case, but the differences are much smaller than they could be.

So, brave souls, anyone have any idea what the differences might be? Using non-free VMware Fusion to be able to boot physical partition, when all that separates us from success is measly three bytes, is so… undignified.

Grab my .vmdk files; “old” is VirtualBox-generated file, “vmware” is VMware generated file (that works on my setup), and “dd” is file copied with DD.

BootCamp-pt-old BootCamp-pt-vmware BootCamp-pt-dd

Ah-ha! Further examination (at 1:46 CET 🙂 ) revealed that those three bytes, at correct offsets 1C2, 1D2 and 1E2 are partition type identifiers, and were all changed to 2D. That’s the only difference from the dd-captured data! This means perhaps even 512-byte bootsector change would suffice. But that’s a subject for another post. Have fun — try fixing your [name]-pt.vmdk file with a hex editor and post results in comments 🙂

*sigh* must … go … sleep … (2:13 CET)

These lines of code create a working BootCamp VMDK for me, when I have four partitions on my physical hard drive. Playing with physical partitions is dangerous — consider yourself warned before you run these. And of course, running both dd and fdisk on physical partitions is always dangerous; luckily we run fdisk on a file here, but still…

sudo VBoxManage internalcommands createrawvmdk -filename BootCamp.vmdk -rawdisk /dev/disk0 -partitions 4
sudo dd bs=1 count=32256 if=/dev/disk0 of=BootCamp-pt.vmdk # 32256 == mbr size
sudo chown `whoami` BootCamp*
sudo

echo "setpid 1
2d
setpid 2
2d
setpid 3
2d
write" | fdisk -e BootCamp-pt.vmdk

Additionally you need to set /dev/disk0s4 to be writable to your user (which means you’ll probably make it writable to everyone). Since this is even more dangerous, and a horrible, horrible security practice, I won’t put down the command to do this; easiest way to do it has something to do with changing mode to 777 to the mentioned file.

(Note! As of July 22nd, while playing with setting up booting of physical Ubuntu 12.04, I got the equivalent of BootCamp-pt.vmdk that was 37376 bytes long. Changing the dd command accordingly did not help with the problems I was having, but it didn’t seem to harm either.)

Once again: All in this section applies to having four partitions! All in this section can be dangerous!