Social search: Aardvark invitations

01Apr09

Aardvark is a new, Web 2.0 product aiming to bring social search to the masses: unlike traditional search engines, that crawl and index a massive number of pages, Aardvark acts more like a router: it tries to understand enough of the question to determine its topic (and asks you when it fails), and then offer it to online users, starting with those who have declared an expertise in the given topic.

I have several Aardvark invitations available. Reply if you’re interested!


Filed under: Search, Web 2.0   |  7 Comments

Lie to Me

12Mar09

While bedridden, I serendipitously discovered this amazing new TV series — it does not even have enough user ratings yet — starring Tim Roth as a House-esque face-reader.

Surprisingly thoughtful, well-plotted, and with a diverse range of cases. People who find House too preposterous ought to give this one a try — they’re on Hulu.


Filed under: Uncategorized   |  Leave a Comment

Rawhide on Dell Mini 9

09Mar09

My new netbook arrived on Thursday, 13 days earlier than expected. Dell really need to work on their delivery estimates, but it’s better than having it be late…

This was one day after I came down with a really bad cold — still shrugging it off now. Productivity plummets to no end, but setting up a new computer is a more fun way to while away illness than reading a book (sorry, Orhan Pamuk; I think My Name is Red is your one masterpiece. The others are too meandering, especially when one can’t concentrate well).

The initial plan was to install Rawhide (ambitious!) over the CS department’s gigabit network, using the btrfs file system. This turns out to be unworkable — the r8169 driver mistakes the netbook’s 8101E as a gigabit adapter, whereas it’s only Fast Ethernet. I managed to get a DHCP lease once, on Dell’s Ubuntu installation.

Several network install attempts follow, over a 100 mbps link, using F11 alpha’s boot.iso. These all mysteriously fail, sometimes maddeningly close to completion. Even with ‘maxcpus=0 selinux=0′.

Giving up on this approach, I opted next for a hard drive install: use livecd-tools to put boot.iso into a thumb drive, and copy the ISO image to the drive’s root. It appears that this is insufficient — images/install.img has to be on the drive as well. This allows installation to succeed.

And then disappointment comes.

  • btrfs checksumming makes any RPM transaction mind-numbingly slow
  • Kernel panics. Even with maxcpus=0. This might actually explain the network install failures
  • Kernel panic at boot using newer kernels

So off with btrfs and on with ext4. Too bad; the SSD optimizations in btrfs look nice. One wonders if it’s the early production status, or if it does actually impose a certain amount of computational overhead making it unsuitable to netbooks (or any single-core computers, for that matter. No, hyperthreading does not count).

I’ve had a fully up-to-date Rawhide all of Sunday and it’s a joy to use. 512 MB is rather usable, albeit forcing a certain discipline when it comes to browser tabs. Will put in the 2GB upgrade when the new wireless card arrives, so I don’t have to open the hood twice. Ironically, that card shipped promptly but has since been wandering the limbo of Chinese customs… why is it that the cool electronics products inevitably come from Chinese eBay sellers…

Remaining bugs:


Filed under: Fedora   |  2 Comments

Application bundles: system integration

02Aug08

In my comments on the recent LWN seed “Will LSB 4 Standardize Linux?”, I made the argument in favour of application bundles:

The advantage of bundles is that it contains more metadata than a simple tarball.
Compatibility problems might arise, but at least the application launcher could provide more
meaningful feedback to the user.

Or even integrate with the OS’ version control system, especially now that Linux has
PackageKit, to say “hey, the user wants to run this new bundle that needs libfoo-x.y, install
whatever package is necessary to provide that”.

You’d need a package management system that automatically scans built packages for what
libraries they provide; RPM does that, not sure whether DPKG does.

To provide the context: the discussion was on how application vendors can easily target LSB 4 with a single binary image. My post was in direct response to an argument by another reader, that complicated schemes do not add much real value over tarballs, to which I begged to differ, arguing that the metadata available in bundles make the integration of binary applications much easier.

The issue of binary distribution triggers an allergic reaction from some people in the FLOSS community, a reaction that is, in my opinion, rather unwarranted. Even Debian provides, in their non-free repositories, stub packages that will download binary packages and create a standard .DEB package out of them. There are clear advantages to making binary-only applications more well-behaved, in fact the same argument for having package management systems with graph-based dependency tracking in the first place: dependency, dependency, dependency. When installing/upgrading a package, you’d want all its dependencies to be pulled in automatically. When upgrading a library, you want to make sure that all its dependents will still work. When there is a security vulnerability, you want a non-techie end-user to be notified, preferably within a fixed period of the vulnerability being made public (through periodic updates), or the next time the user launches the application concerned.

There have been attempts to create a one-size-fits-all universal package format, that’s distribution-independent and vendor-friendly. This is a red herring, IMHO, for the same reason that the Unix market splintered in the ’70s and ’80s, and that we have a proliferation of Linux distributions — and multiple independent BSD operating systems, each of them with their own ports tree (DragonFly being an exception in that they share NetBSD’s pkgsrc system). It’s nice to control your own packaging format, or if it’s a shared format (like RPM is), to control the naming conventions, etc.

What application bundles can do is provide the best of both worlds: vendors can ship binary-only bundles that declare dependencies in a least-common denominator format that the LSB can standardize, for example:

<br /><Provides>
  <lib>libbaz-a.b</lib>
</Provides>
<Requires>
  <lsb-version>4.0</lsb-version>
  <bin>convert</bin>
  <lib>libfoo-x.y</lib>
  <lib>libbar-z.w</lib>
</Requires>

The first time the bundle is launched, the launcher can add it to its index of available bundles. If any of the dependencies are missing, the system-native package management (or a meta management infrastructure such as PackageKit) is triggered to install the missing dependencies. The bundles themselves can be placed anywhere (though library bundles — in NextStep/OpenStep/OS X parlance, “frameworks” should probably be placed in pre-determined paths, e.g. /Library/Frameworks, /System/Library/Frameworks and ~/Library/Frameworks).

The only problem is that the system-provided libraries might not be ABI-compliant with the specified LSB standard, for example, libraries written in C++ after a compiler ABI change. There would probably be a need for the native packages to declare their compliance, or non-compliance, with LSB standards.

And one last nice thing about bundles: fat binaries. It’s easy to provide multi-arch bundles, and stripping away unwanted architectures is a simple rm operation.


Filed under: FLOSS   |  1 Comment

Vista: 64-bit usage climbing

02Aug08
We from the multilib-enabled Linux world extend a belated welcome to our Windows-using counterparts
clipped from arstechnica.com



Unlike Apple, Microsoft does not control the hardware that its software runs on. This means that Apple can more easily move all its users to an x64 operating system: all Macs currently have 64-bit CPUs, and Snow Leopard is rumored to be a 64-bit-only release. Windows 7, on the other hand, will still be released in x86 and x64. Microsoft would prefer not to make Windows 7 available on computers with 32-bit CPUs (indeed, Windows 7 Server will be x64-only), but the decision is driven by software compatibility demands.
  blog it

Filed under: Linux, Microsoft   |  Leave a Comment
« Previous Entries