Dear Lazyweb,
Does anyone have suggestions on what to use for centralized storage at home? I have a lot of music/photos here piling up and would like to put them on some energy-efficient NAS box. Ideally it would have some sort of of built-in backup solution as well. A lot of the NAS-in-a-box solutions seem to have RAID 1, but that really only helps for HA. I am more concerned with never ever losing this stuff than having it available 24/7.
There has been a lot of buzz lately about the Firefox 3 fsync issue. The work I’m doing these days has me doing a lot of long-running disk-bound activies, so this one hurts me pretty bad. Firefox would stop responding for 30-40s at a time while my job was running in the background, which I think is pretty unacceptable. I have worked around it in the (hopefully) short-term with a LD_PRELOAD hack. I’ve posted it here in case anyone else finds it useful. Just unpack, cd to the directory, and ‘make && make install’ (not as root). A word of warning, though: if it breaks you get to keep both pieces. Kudos to Aaron for adding the ‘make install’ bits to the Makefile 
Ever since zypper came along I hated it. It was slow, buggy, and used a ton of resources.
Well, I installed openSUSE 11.0b3 yesterday and the zypper/libzypp there is massively improved. I don’t think it’s possible to overstate just how much of an improvement it really is. Normally I just make rcd/rug work on whatever new release comes along and continue using that. Zypper and PackageKit are so good now that I’m giving that up. So congratulations to the zypp team — I know they caught a lot of flack in the past, but I think this release will finally put a lot of that to rest.
The other day I looked into switching away from synergy to Mango Lassi. I only use it between two machines, so I figured my use case was simple enough that it should work at this stage. I was not disappointed. I was getting some very strange behavior with synergy and vmware, and Mango Lassi has none of that. Plus it gives an OSD telling you which machine the mouse/keyboard are being used on, which is a nice perk.
Anyway, I was so happy with it that I made packages for openSUSE. You can get it from my build service repository.
Recently I’ve had a couple of ideas for a project (like I need another one of those). The goal would be to make a library which allows applications to easily track their user’s interactions and log them in a central location. Project maintainers/contributors could then look at the collected data to help them make decisions about what they should be spending time on. For instance, a media player might log what types of files are played or if it was synced to an iPod-like device.
As far as technical hurdles go, doing something like this is pretty easy. The main questions I have are around the kind of policies that should exist for such a thing. Obviously, participation should be opt-in. But should it be on a per-app basis, or per-user? Or both? If it is per-app, you would likely get bombarded with a prompt on the first run of every app that uses this system. If that is a small number it might be ok, but hopefully that wouldn’t be the case :). On the other hand, maybe you don’t want certain sensitive applications (email client?) ever sending info.
Then there’s the question of who should have access to the data. My feeling is that the user should always be able to see everything that he has sent. But should he also be able to see everyone else’s individual data? What about the aggregated data? That leads me to the next question. Should there be a cookie that identifies a single user throughout all applications? Or even a cookie per-application? I think having a cookie across all applications would definitely make the data more useful, but I’m not sure if people would be opposed to such a thing. Of course, this leads to yet another question. How do we keep personal information out? I don’t believe there is a technical solution to keep things like this from making its way in. Developers will need to be very careful, and that kind of bothers me. If all of the data on the server is available to everyone then maybe public scrutiny will help keep things in check, but who knows.
These are just a few of the questions I have come up with, and I am sure others can think of plenty more. Is it possible to come up with something that benefits the development community without infringing on user’s privacy? Even so, would users participate? Comments are open.
I was out of town for part of hack week, so I didn’t participate fully like my colleagues. I did get a couple evenings to mess around with something, though. I wrote an installer for KIWI-generated LiveCDs.
It’s still in early development and has lots of hacks to make things work, but it does manage to install a working system onto your machine. The installation itself is really pretty simple. The LiveCD data is in a compressed squashfs image on the CD, and the installer just copies all of that to the disk. Then it just writes out an fstab, installs grub, etc.
As usual, however, the devil is in the details. Things like sound and video card detection are normally done by the YaST installer, so other methods must be used. It might be possible to invoke the relevant bits of YaST from the LiveCD installer to achieve the same effect, but I haven’t looked into it yet. I have everything checked into svn (svn://snorp.net/trunk/opensuse-live), so if you want to try and build a CD everything is there. I will also upload an ISO soonish.
Update: You can download a full ISO based on openSUSE Alpha 5 here.
One of the reasons I wanted to revive rcd was so that I could use it to play with some package management ideas I’ve been kicking around. One of these ideas is a way to reliably rollback changes made during an RPM transaction. That is, actually make RPM transactions transactional.
Recently, a colleague introduced me to device-mapper, a kernel system used for block device redirection. There is a really cool thing that uses it called dm-snapshot, which allows you to redirect all writes to a device into a separate device. What I would like to do is use this to store all of the changes made during an rpm transaction. I think it would just need a bit of patching so that it only stores the changes made by the rcd/rpm process (and children). If anything goes wrong, you can just trash the snapshot data and things are exactly as they were in the beginning. Of course, if it succeeds without problelms, you need to merge the snapshot changes into the original device. This is where things get fuzzy, as dm-snapshot does not have this ability. However, Mark McLoughlin has created a set of patches that add this feature as part of the Stateless Linux project. Sadly, the patches do not appear to be a high priority for the kernel guys right now, so I guess this approach will have to be put on hold.
In any case, a system for performing this rollback stuff would be ridiculously useful in general — not just for package management. It looks like it will be a little more than I can do by myself in a weekend hack, though, so hopefully someone else will carry the torch?
Red Carpet, that is. Yes, that Red Carpet. I’ve taken some time lately to give some love to our old friends rcd and rug (the original rug, not the rewritten one). First I got everything building on a modern distro (openSUSE 10.2). This took more effort than I thought it would, but eventually things worked well. After that, I set out to make rcd more usable with yum services. Here is a list of the main changes:
With the above changes, rcd is once again a joy to use. I would like to get the GUI working again, but there is some kind of threading problem preventing it from running. I would also like to add ftp support, but that is not a top priority.
I know there are probably SUSE users reading this asking “Ok, sounds fine, but is it fast?”. While it may not be the fastest thing out there, I think you will be surprised at the results (I was). Here are a few simple benchmarks from normal usage scenarios:
First, lets look at the number of services I currently have added:
% rug sl # | Service URI | Name ---+-------------------------------------------------------+------------ 1 | http://go-mono.com/download-stable/suse-102-i586?r... | mono 2 | http://software.opensuse.org/download/FATE/openSUS... | fate 3 | http://ftp.suse.com/pub/suse/update/10.2/?name=upd... | updates 4 | http://download.opensuse.org/distribution/10.2/rep... | suse-nonoss 5 | http://download.opensuse.org/distribution/10.2/rep... | suse-oss 6 | http://packman.inode.at/suse/10.2?remote_only=1;na... | packman 7 | http://software.opensuse.org/download/home:/cybero... | cyborg 8 | http://software.opensuse.org/download/X11:/XGL/ope... | xgl 9 | http://software.opensuse.org/download/Beagle/openS... | beagle 10 | http://software.opensuse.org/download/games:/actio... | games 11 | http://software.opensuse.org/download/Virtualizati... | virt 12 | http://software.opensuse.org/download/home:/kraxel... | kvm
So 12 services, and the package count is almost 21000. 22500 if you also count the ones in the rpm database. How long does it take to load all of those?
Cold filesystem cache, daemon is sleeping:
% time rug ping > /dev/null rug ping 0.17s user 0.02s system 1% cpu 13.735 total
14 seconds to respond isn’t terrible, considering the cold filesystem cache. Now that the kernel has it cached, though, how long does it take?
Warm filesystem cache, daemon is sleeping:
4.5, not bad. Definitely in the tolerable range, I’d say. Of course after the daemon is awake, commands respond immediately. That is maybe the only good thing about rcd being a daemon — subsequent commands are instant, where other tools (yum, smart, etc) have to load the package metadata again. Memory usage after rcd wakes up is about 28MB, so that is not too bad either (it is a little over 1MB when sleeping).
Packages for recent SUSE distros are available in the build service. It has had a hard time keeping up recently, though, so you may run into a problem or two with rug. Sources can be found in gnome svn in the yummy branch of the various modules (rcd, rug, libredcarpet).
Also, yes, I am sick sick person.
I just tried out Avant Window Navigator for the first time, after seeing Neil’s latest blog entry. It’s pretty slick, and worth trying if you have xgl/aiglx/whatever. I also wrote a Banshee plugin which makes the current track cover appear in the dock.
You can get the plugin here. Just drop the dll into ~/.gnome2/banshee/plugins.
