Archive for the 'GNOME' Category

Novell hack week, day 3

Federico and Tambet came and hacked in addition to Mike and me. Got some stuff done, but not as much as I’d have liked to. The arrachera I had for lunch sort of knocked me out.

I’d better get some sleep now. More tomorrow.

Novell hack week, day 2

Day 2 is at an end, and I’ve spent it learning about C# and Mono tools, looking into how other projects do stuff. I now have a Git repository with a fledgling project structure, and a more solid foundation to work from knowledge-wise.

I feel a little bad for posting that Monodevelop screenshot yesterday. The intention wasn’t to make Monodevelop look bad, but rather to convey the occasional feeling of exasperation you can get when learning to use new tools, moving outside your comfort zone. I was using the older version that comes with openSUSE 10.3, assuming that would’ve been patched to fix most serious issues. I was wrong.

Fortunately, the eminent Mr. Hutchinson pointed me in the right direction - I got a newer version from one of his build service repos, and that works much better, although it still spews a little to the terminal. You can tell a lot of work went into it; this is the first time I’ve felt like I’m using a true IDE on Linux, i.e. the “integration” part actually works.

Mike arrived from Mexico City last night and will be spending the next couple of days here. His tiny new Lenovo X series Thinkpad looks totally sweet, but he spent a lot of time fighting poor wireless drivers. I guess most of us can empathize with that. Tomorrow, Tambet and Federico will hopefully join us, and we can all bask in teh hack week synergy.

Novell hack week, day 1

Novell’s hack week has started. For those of you who don’t know what a hack week is, it’s a work week where we, the programmers at Novell, get to goof around with more or less whatever project we find interesting.

I’ve chosen to start a new project called “Sterling”, the goal of which is to keep better track of my moneys. I’ve used GnuCash to do this for some time, but it’s clunky and overkill for my uses. I want to streamline the process of entering transactions and otherwise keep the complexity down, especially for people like me who know (and care) little about accounting. Indeed, I want the UI to resemble Tomboy’s in many ways:

  • Always running, with a panel applet interface.
  • Desktop-global “new transaction” hotkey.
  • Per-user database, no open/save dialogs.
  • Implicit save on edit.
  • Type-ahead completion of transaction description.
  • Suggesting details of transaction based on similar past transactions.
  • Tagging of transactions for easy cross-sectioning.
  • Simple search-as-you-type view of transaction history.
  • Multiple currencies recognized by their ISO 4217 codes.

Star Trek future features:

  • Currency conversion (use Google?).
  • Multiple registers (similar to books in Tomboy).
  • Export to XML, merge from XML.
  • Remote synchronization (by Zeroconf discovery or specific URI) allowing for shared databases.
  • Desktop search integration.
  • Drop-dead attractive graphs.

In order to make things as difficult for myself as possible, I’ve decided to learn something new and do it in C#/Mono. Of course, I’m already running into trouble…

MonoDevelop got stuck

Strange but true. I miss C, Emacs, Automake already.

openSUSE GNOME Meeting

The openSUSE GNOME team will be holding its first meeting tailored to asia-pacific time zones on Thursday 12:00 UTC, in #opensuse-gnome on irc.freenode.net. If you’ve been left out because of your time zone previously, this is your chance to participate.

At GNOME Summit

I’m at the GNOME Summit. Right now watching the Hotwire talk.

Oh, and since my blog was broken when it mattered, I’m late to the party - but what the hell: openSUSE 10.3 is out! And it’s actually not too shabby, with GNOME 2.20 and all.

The Ongoing GVFS Saga

rainbar.jpg

Spent last week in Stockholm working on GVFS with Alex. We made great strides - pretty much all of the file system operations are now implemented in gvfs-daemon, gvfs-fuse-daemon and the SMB backend. Plenty of work remaining, though.

GVFS Benchmarking

For Novell’s hack week, I wrote some benchmarking code for GVFS. It may not sound that exciting, but performance interests me, and it needed to be done. So far, the results are much better than I feared - for remote URIs, requests are proxied through a daemon over a D-Bus bus, and that had me worried.

In my particular setup, creating a file on a remote SMB share, filling it with 50MB data and reading it back took 16% longer using GVFS calls compared to bare POSIX and a kernel mount, and about twice as much CPU. As expected, for local FS operations the performance is pretty much equal.

There’s also a many-small-files test, in which I suspect GVFS will fare a lot worse, but I haven’t been able to make a good comparison due to some incomplete code paths in GVFS.

The code is on my GVFS branch in the new ‘test’ directory.

GVFS Progress

Alexander Larsson has been hacking like a whirlwind, bringing us the next generation in VFS services for the desktop, GVFS. By now, a lot of the planned functionality is done, and we even have a partially done FUSE frontend which will let legacy apps that can’t or won’t link with GVFS access the user’s mounts under ~/.vfs/.

Alex’ master repository does not have the FUSE module yet, so you can get it from my repository in the meantime.

Unfortunately, the SMB backend is pretty flaky, frequently locking up when reading directory information or file data from remote shares. So if you’re a debugging hotshot and you want to help bring desktop file browsing to the next level, here’s your chance!

GVFS is pretty easy to set up and test:

  • Clone, build, install to $prefix.
  • Make sure you have a working D-Bus setup.
  • Make sure you have the FUSE kernel module installed.
  • mkdir ~/.vfs
  • $prefix/libexec/gvfs-daemon
  • $prefix/libexec/gvfs-fuse-daemon -f ~/.vfs
  • $prefix/bin/gvfs-mount smb://server/share

The new mount should show up under ~/.vfs/, and you can explore it from there.

Cumbia sí, trabajo no

Last week was a pretty busy one. I spent part of it in Mexico City, seeing friends and looking for some computer gear I needed. Everyone’s talking about the new abortion legislation that will legalize the practice in the Federal District (the state that contains a large part of the city). The progressives, although (arguably) losing the presidential election, hold a majority of seats there and have struck back with legalized gay marriage, and now this. The church and other conservatives have, predictably, made a lot of fuss over being dragged into last century. Even the pope has contributed his share of outrage. I say congratulations, DF - it’s about time.

paolita-leo.jpg

Paolita and Leo in the DF

Only two days after the above picture was taken, Paolita suffered a burglary in which she lost most of her computing equipment (read: livelihood). Since she’s an independent contractor, she’s counting on finishing her current job to pay for new stuff.

On Thursday, Leo and I set course for Poza Rica, where we’d been invited to give talks at their FLISOL arrangement. The plan had been for Paolita to come with us, but sadly, the above turn of events left her without the time and money to do so. We started out making good time, but found the highway blocked by a trailer crash, and had to backtrack a couple of kilometers for the “scenic route”. It was slow due to ongoing road work, but at least it wasn’t jammed with cars - apparently we were the only ones with a map.

highway-blocked.jpg

Blocked highway

alternate-route-blocked.jpg

Alternate route

All in all, getting there took about twice as long as we’d hoped, and once in Poza Rica we found that our talks had been postponed to Friday. We got to know the local Linuxeros - an excellent gang.

poza-rica-gang.jpg

Poza Rica gang

From left to right, that’s Leo, Adlair, the waitress, Marco, Christian, Xochitl and Jorge.

Although the event didn’t turn out exactly as hoped, we got to do the talks and there seemed to be some interest. The slides and source for mine are available. It’s a tiny project that illustrates how to get started writing and distributing free desktop software. It’s called “PopoMon”, and is a web-scraping taskbar alert level monitor for the volcano we all know and love, Popocatepetl.

On Saturday I was back home, and on Sunday we were invited to visit our neighbors and friends, Omar and Silvia, at their cabin. It’s located in the woods on the outskirts of Xalapa, less than an hour away by car. Once you leave the city, things change quickly:

xalapa-outskirts-house.jpg

Peace and quiet

xalapa-outskirts-road.jpg

More Xalapa countryside

omar-silvia-cabin.jpg

Omar and Silvia

hp-maru-cabin.jpg

Me and Maru

maru-in-tree.jpg

Maru inside of a big ol’ tree

People were raising and serving fish nearby, using water diverted from a river. We ate some. It wasn’t at all bad.

fish-in-a-pool.jpg

Fish in a pool

fish-in-a-bucket.jpg

Fish in a bucket

Priorities

In addition to the kernel’s per-process CPU and I/O priorities, it would be nice to have memory residency priorities. That way, we could hint the kernel into keeping proportionally more pages of latency-sensitive desktop processes in RAM - like the main menu, the taskbar, the file manager and maybe some applets. Disk cache could have its own priority, a la the swappiness setting in /proc/sys/vm/swappiness. It could be a practical* way to mitigate the “my main menu takes several seconds from click to paint” problem.

* Since I’m not a kernel dev, I’m just guessing here.