Bittornado's btlaunchmany script manages all the torrents in a directory, which is quite convenient - grab .torrent's and drop them in that dir and they'll automatically get handled.
There is also a curses version, btlaunchmanycurses, but it didn't do exactly what I wanted. I wanted to run the btlaunchmany script as a daemon, save its output to a log, and then have a simple interface to periodically log in and view status with.
Anyway, pretty basic ncurses script: btstatus.
I've uploaded a new fglrx we've just received from AMD that should now work with xserver 1.5.
Please test and if you find issues, report them via:
ubuntu-bug fglrx-installer
Thanks and enjoy!
Posted in Ubuntu Submitted by bryce on Tue, 2008-10-14 21:38.
bryce's blog | 6 comments
Based on a comment on my last blog entry, I thought I'd elaborate a bit more specifically about -ati in Intrepid.
Thanks for the update! There seem to be quite a few regressions with the ati driver on intrepid... will these receive any special attention in the next few weeks? This is especially needed I think because fglrx will probably not be available at release time.
Hmm, I'd need to know more specifically what you're seeing as regressions - overall to me it feels like a lot of issues have been laid to rest. Compared to the -ati in Hardy, I'd rate the Intrepid -ati to be considerably more stable. It's not perfect, but it's a lot better.
Of course, many times bugs aren't in the X driver, but rather are in mesa, and I think some of the changes in it have introduced problems. However, we've just recently moved to the (hopefully much more stable) mesa 7.2 release. But let's ignore mesa for this blog post.
One thing you might check though. In Hardy, because -ati was so buggy we blacklisted it from compiz for a lot of cases (such as laptops). In Intrepid, due to the improvements, we've been able to drop all the blacklisting. However, that doesn't mean 100% of those issues are fixed. So it's possible (esp. if you're using an ati laptop), that it *seems* like there are more regressions, when really it's just that you didn't have compiz by default before, but do now.
Also, I suspect a lot more people are using -ati now, that may have used -fglrx in the past. The AMD/ATI documentation release stimulated a lot of development work to add longstanding missing features (like 3D capabilities), and to enable support for 5xx/6xx series cards. The lack of these things would have forced people to use the proprietary driver in the past, but with these improvements -ati has become "good enough" for more people. So I could imagine some people are "seeing regressions" whereas in reality maybe they're just remembering -fglrx.
Anyway, those are just guesses without knowing specifics.
Now, historically if you look back to Feisty, that was released right before the AMD/ATI docs were put out, and the 6.6.3 -ati driver included there was considered quite stable, but much more constrained in its functionality. For people with older ATI cards that only care about 2D functionality and don't need xrandr, that 6.6.3 driver was actually quite good, and -ati users still make use of that version when the current one is just too buggy. In Gutsy, we moved to the 6.7 series, which included xrandr and some 3D functionality that made compiz work for many people (but break horribly for others...) We gave -ati a lot of focus during Gutsy, pulling in patches from git, giving Alex ample feedback, and working hard to stabilize it. For Hardy, we pulled back a bit in the interest of stability; compiz blacklisted -ati on laptops, since our testing found there was just way too many random crashers. I'd wanted to put more time into stabilizing -ati, but decided to mostly focus on -intel; I think the -ati in Hardy may have been better overall than the one in Gutsy, but it didn't reach the level of stability that I would have liked for Hardy.
In Intrepid, I've switched gears and focused more of my time on -ati than other drivers. We've been able to remove the -ati blacklisting as discussed above. I've added a quirk system and put in a variety of hardware-specific fixes. So I really think the driver is more stable and more functional than in Hardy, but I'm open to discussion.
One of the major tasks I completed for -ati during Intrepid is reading through every single xserver-xorg-video-ati bug report, and upstreaming all the reports that were reported adequately. Sadly, this amounted to a fairly small number - it's crazy how often people fail to include basic info like Xorg.0.log, lspci, or backtraces and/or haven't re-checked against Intrepid; unless I can reproduce the bug myself, without this basic info we can't troubleshoot or upstream the bug - just plead the user attach the info.
So, for those who are seeing issues, the ball's sort of in your court at this point to make sure the problem is adequately reported (see http://wiki.ubuntu.com/X for a bunch of troubleshooting resources I've written that will be of value.) I've been keeping an eye out for responses to bugs; there probably isn't enough time to fully troubleshoot the bugs at this point, but if an upstream-approved patch comes to light I can certainly look at bringing it.
One new thing I've added in Intrepid are apport hooks for the major X packages. So now you can run `ubuntu-bug xserver-xorg-video-ati`, and it'll take care of attaching all the necessary files and stuff for reporting -ati bugs.
Meanwhile, my plan going forward is to shift focus from specific -ati bug work, to instead set up a driver build system, to build older and newer debs from the -intel and -ati git trees. This is something that's been on my todo list for a long while, but other stuff has kept taking precedence; since we're in freeze now, this seems like a good point to turn attention to this. I made a static prototype a while back to test out the concept just for -intel, and it proved itself nicely for analyzing driver regressions; there's a lot of issues I need to sort out in order to automate the builds and to expand it to cover -ati and maybe other packages, but I'm hoping with a few week's solid focus to make it quite useful.
Posted in Ubuntu Submitted by bryce on Thu, 2008-09-25 19:11.
bryce's blog | 7 comments
We're nearing the beta freeze for Intrepid. Some stuff I've been working on lately...
Fix for bad gradient banding on -ati - In testing some newer hardware with newish ATI chips, there's a noticeable issue with gradient rendering (see screenshot). It's quite noticeable with the Ubuntu background image, but can also be reproduced easily in Inkscape or Gimp. I coded up a patch to use dithering to minimize the banding. Having to use dithering on this very new hardware seems less than optimal, but at least it looks ok.
Documenting Quirks - The -intel driver has a nifty quirk system, which has been a boon with Ubuntu. Because Ubuntu has so many users, it gives us a huge range of hardware coverage, so once I understand a given quirk, it's pretty straightforward to locate relevant bugs in Ubuntu's bug tracker and send quirks in for them. I've written up quirk documentation explaining each of the issues these fix, the symptoms to look for, and what to include in bug reports for requesting them.
-ati AGPMode quirk system - The -ati driver doesn't have as sophisticated of a quirking system as -intel, but since it proved so handy, I coded a quirk system, that handles quirking based on AGP incompatibilities between a given ATI gfx card and the host bridge. Hopefully the contribution will be taken upstream; meantime it's in Ubuntu's -ati tree (and directions for testing and requesting quirks are in the quirk docs).
-ati bug squashery - During Hardy development, I focused pretty intently on bugs with -intel, bringing the total count in Launchpad from 160 down to 100 by the release. This time around, I've been trying to do the same with -ati; we started from a bit higher point than -intel, but I'm optimistic that the remaining 45 or so can be knocked out by release.
Reworking Failsafe-X - With displayconfig-gtk being retired, I decided to go back to the blackboard and reinvent our failure handling code. Originally, many people needed to hand configure things in xorg.conf, and errors in doing so could drop you into the failure mode (the infamous blue gdm screen). Since that was a pretty common failure mode, the failsafe X handler was designed specifically for handling that case. However, upstream changes to make X auto-configure itself rendered much of this obsolete pretty rapidly.
These days, most people don't need anything in xorg.conf, and the original use case has been greatly reduced (yay!) The remaining failure use cases tend to be pretty scattered across the board, and not easy to solve with a universal tool.
So, I'm taking more of a "toolbox" approach in Intrepid. Instead of a sophisticated GUI, there's just a series of simple menus for easily reconfiguring or troubleshooting. It now shows you the exact error message(s) it ran into in the first dialog, which I hope helps make errors more obvious. The default option is to just use the VGA mode, just one time (so if someone's in a hurry or finds the system scary, it will at least help get them into a functioning Ubuntu without having to think about it or risking permanent breakage). There's an option to just exit to the command line, or to view/archive Xorg and gdm log files for bug reporting, or even just popping open xorg.conf in a text editor. In Jaunty I hope to expand on this with an xorg.conf validator based on x-kit, and an automatic bug reporter (but I need logic to filter out non-bugs, false-positives, and user-errors first).
Non-functioning hotkeys - A large chunk of time this month went into investigating hotkey issues, particularly around the sleep/battery keys. That involved into digging through 'acpi-support', which I'm wondering if we need to just drop and go with straight HAL/pmutils. There are a ton of outstanding patches from Debian that we don't have, and even with them I think it may redundant. It's too late in Intrepid to do much more than duct tape, but for Jaunty this is going to need a lot of focus.
Posted in Ubuntu Submitted by bryce on Wed, 2008-09-24 00:01.
bryce's blog | 8 comments
It's great seeing all the new people joining the MOTU ranks. It's made me wonder, what tool improvements might make the process even easier? Sounds like a decent topic for a blog post so here we go...
1. Quell unnecessary warnings: When learning packaging you run into a bewildering number of warnings. There's several that occur normally (like the one about 'user-defined field Original-Maintainer') that are completely innocuous - indeed for properly maintained Ubuntu packages the things they warn about *should* be there. Old timers know what can be ignored and what can't, but for the sake of newbie MOTU's suppressing these would eliminate potential confusion.
2. Automatic switch selection: debuild is a great tool, but mastering its command line options is not terribly intuitive. Sometimes you want "-uc -us -i -S", other times "-sa -S", in a few cases you need the -v flag. I often wonder if this could be reworked such that fewer switches need to be mastered by automatically figuring out what's intended. Even just eliminating one or two switches would help a lot. For instance, for Ubuntu-specific packaging I wonder if the -v flag (needed for merges) could be made to work automatically for Ubuntu packages.
3. Patch packager/debuilder: One of the major tasks a packager does is to obtain an applicable patch from somewhere and incorporate it into the package. For basic patches that don't need to be reworked, most of the steps seem like they could be simplified to a single step - 'apt-patch *.patch' - which would take care of the details of figuring out what patch system is in place (adding an appropriate one if not), adding the patch, copying in the changelog description, updating the maintainer field, selecting an appropriate version number, and so on.
4. Better pbuilder: pbuilder is an awesome tool for cleanly building debs, but takes a lot of time to get it set up "just right" - ccache, multi-arch/multi-dist building, cronjob updates, local mirroring, etc. Certainly some of this comes down to personal preferences and thankfully there is a good paint-by-numbers guide to set it up, but it would be very helpful to new MOTUs if there was a more powerful default that sets up most of these "best practices" automatically. This could help make it easier for people to assist with backports for instance.
It'd also be wonderful if pbuilder would print out the paths/names of the .debs it builds. Currently, having to find them in /var/cache/pbuilder/.../result/ is annoying.
5. debdiff builder shortcut: debdiff's are great ways of communicating package changes, and are reasonably easy for developers to generate. But currently, given a debdiff, it takes a lot of steps to turn that into a .deb, involving apt-get source, patch, debuild, pbuilder. Imagine if, coupled with the improvements from #4 above, we could reduce this to *one* step, like 'apt-build *.debdiff' (or maybe $package could be inferred). This would make it much easier for people with minimal packaging know-how to turn proposed patches into packages they can test with.
6. Launchpad/pbuilder integration: Now off into blue sky territory. Given all of the above, it ought to be possible to have a script scan launchpad for patches, automatically package and build them (either/both against the current ubuntu version, or the upstream tree), and provide a link to the .deb in the bug comment. This would help testers by quickly providing packages they can download and build. It saves the packager/developer the trouble of uploading the debs themselves.
Of course, imagine going even one step further - when launchpad spots that the upstream bug report has gone to fixed state, scan it for a patch, svn/git id, or whatever, pull a patch, and automatically build it so folks can start testing it immediately. This would give bug reporters a huge benefit to linking bugs to upstream bug trackers. It would also facilitate a lot more testers who would try out experimental .debs, but would not be likely to build them themselves.
Posted in Ubuntu Submitted by bryce on Mon, 2008-09-15 20:25.
bryce's blog | 3 comments
For Ubuntu 8.04 one of the projects I helped work on was a new xrandr-based screen resolution tool.
Unfortunately, Xorg currently requires you to specify the "Virtual" option in xorg.conf in order to do dual-head, if the combined desktop would be larger than the default maximum. This is nearly always the case, so it meant that in practice Screen Resolution couldn't setup multi-head displays for you.
Alberto Milone developed a Python xorg.conf reader/writer called X-Kit. Using this backend, we've been able to hook in a script that will detect when you need to adjust your Virtual setting, and offer to take care of it for you.
Here's some screenshots:
[1] [2] [3] [4] [5] [6] [7]
Eventually, upstream will be eliminating the need to manually specify "Virtual", so maybe by Intrepid+1 we'll not need this extra package, but for now it'll enable this (IMHO important) feature to work.
screen-resolution-extra and X-Kit are uploaded but haven't been promoted to main yet, so stay tuned for now.
Posted in Ubuntu Submitted by bryce on Tue, 2008-08-26 23:56.
bryce's blog | 15 comments
mpt wrote on Why Free Software has poor usability, and how to improve it. A good read, but a few comments:
On incentivizing usability, he suggests stronger incentives in the form of design awards and a bounty system. I suspect neither would be adequate. I'd suggest identifying a handful of "good" designers who have voluntarily made successful enhancements to some program, and interview them for what motivated them. I'll bet it was something other than the lure of fame or money! Whatever it was, seek to maximize THAT.
On inviting design input, I sort of tend to agree that in general people often don't realize they CAN contribute to open source projects, until someone invites them. However, the approach I'd suggest for fixing this is a bit different. This is an approach I've used extensively on Inkscape and other projects:
Watch for a user offering extensive criticism or suggestions for improving the UI that are well thought out and expressed. Often these guys can be recognized as the one complaining that no one is listening to him. ;-) Next, teach them how to make the changes to the program directly.
mpt would point out that "designers ain't coders", however really these changes tend to be pretty easy. Sometimes, if the program uses Glade or other XML formats for defining the UI, the work doesn't require any programming experience - and usually doesn't require even recompiling the program.
Even in cases where the UI changes need to be coded, the code tends to be fairly easy work as far as coding goes, often achievable by just copying and adjusting other similar code.
You don't need to be fluent in a foreign language to get around in a foreign country - often just knowing a few dozen typical words in the language (thank you, hello, please, toilet, how much, etc.) can suffice. Similarly, a UI designer doesn't need to know all the ins and outs of coding; just knowing the syntax for making buttons, adding menu items, and swapping out icon images can get you a LONG way towards your goals.
Further, an approach we've used quite effectively in Inkscape for people that even the above is too hard, is to encourage them to work up their ideas or proposal as a mockup, using Glade, Gimp, or even Inkscape. This gives something that other users can peer-review. A lot of issues can be worked out this way, before any coder comes near it.
On workflows and workloads, care needs to be taken to avoid proposed solutions that require the core developers to do something beyond what they're already doing. The reason is simple: They're too busy, and your proposed workflow will just bottleneck on them. Often they're still working on "it doesn't work", rather than "it doesn't work as well as it could." It's better if you can construct the bulk of your workflow to operate autonomously from any core developer involvement, or put off required involvement to as late in the process as possible.
In general, it occurs to me that many of mpt's ideas could be achieved by creating a team ala freedesktop.org, which works at a level above and outside particular open source projects. Such a group would focus on creating tutorials and specifications, creating shareable code to solve specific classes of issues, and so on.
Submitted by bryce on Mon, 2008-08-04 23:52.
bryce's blog | 5 comments
Yesterday I reviewed all of our launchpad-gm-scripts scripts in light of Launchpad's recent UI changes. I was a bit surprised to see half the scripts work fine, but disappointed that half show some breakage.
I fixed my buttontags script, which was not able to apply tags, and filed bugs 245042 and 245048 for the other two bugs caused by the Launchpad update.
As well, since I expect we are likely to experience future sudden Launchpad interface changes, I've written up a TESTING file to hopefully help folks doublecheck the scripts still work in such situations. Wish there was some way these tests could be done prior to new Launchpad UI updates, but lacking that we'll just have to beg forgiveness for the inevitable breakages.
If you're not yet using the Launchpad greasemonkey scripts, here's a quick plug for them, and list of what they do:
lp_buttontags.user.js - Shortcut for applying several standard tags on bugs
lp_highlight_me.user.js - Highlights your items on the +milestones page
lp_karma_suffix.user.js - Displays user's karma next to their username. Handy to spot new users vs. experienced ones.
lp_patches.user.js - Stars attachments which are patches
lp_stockreplies.user.js - Mechanism for storing and applying a set of stock replies (which you can define) to bugs, updating status dropdowns, etc. as well.
lp_workflowreports.user.js - Identifies workflow reports.
Posted in Ubuntu Submitted by bryce on Fri, 2008-07-04 01:39.
bryce's blog | 2 comments
A number of people have contacted me with comments on my post yesterday about Document vs. Stream UI approaches.
Of particular note is a wiki Rudd-O has set up on Streams vs. Documents. If you find the concept interesting, you might find that a useful place to collaborate with others.
JL Dugger also shared some thoughts with me on Dataflow Languages. I wasn't familiar with the term, but the concept is one I've seen and used previously. I don't think it's necessary to write apps in one of these data flow languages - you can probably model that style of data flow processing in *any* language - but looking at how those languages are designed could probably give a ton of good implementation strategies. Another commenter echoed this with a quite informative discussion about 'functional reactive programming'.
Indeed, I think a lot of the ideas here are covering ground many others have thoroughly tread before. A few people pointed out various technologies and tools that already exist for doing stream oriented stuff; again though, my point is not that we *can't* handle streams, but rather that we already are doing lots of stream stuff, but the OS is not giving the support it should. Someone mentioned a not-yet-released Microsoft project called LiveMesh. (Personally, I long, long ago got worn out by MS products that take a great concept and implement only about half of it - with no way for me to get in and hook up the remaining bits myself, but to each their own.)
kyb outlined some thoughts about task streams with workflow aspects - something I totally agree with and have thought quite a bin on myself. I like the idea of prioritizing streams by work style type ("casual"/"concentrated"/"in the zone"). I myself find when working on bug triaging, that I deliberately break down my work in this fashion - in the mornings when I'm fresh I'll work on a handful of bugs that require a lot of thought, but in the evenings when I'm tired I prefer doing simpler triaging (typically going through and requesting bug reporters attach their Xorg.0.log's *grin*).
Both kyb and enobrev emphasized the need to be able to collate different kinds of streams (email, web urls, SMS, etc.) which may require indexing them into some neutral form, and then assigning various metadata properties to aid in organizing them, prioritizing them, determining if they must be seen or can age and expire, etc. Totally agreed.
Another user inquired about tracking changes on a collaborative SVG document in Inkscape. Glad you asked! :-) For a few years now we've been maintaining an experimental thing Ted Gould thought up called 'inkboard', an online whiteboard which allows multiple inkscape instances to interface to each other by communicating document changes through the jabber protocol. We don't ship it turned on by default, but if you rebuild inkscape from source, you can just pass configure the --enable-inkboard to flip it on. (We learned a lot of hard lessons in this; working effectively with streams is a lot more complex in practice than you realize.)
One comment pointed out that Google Apps, etc. provide these services on the server. I knew someone would inevitably bring up Google Apps. ;-) Web services obviously play a HUGE role in streams. Ignoring the open/closed issue here for now, my point is really that rather than consign my kick ass powerful desktop machine to being essentially just a dumb terminal, the underlying OS ought to get more involved in all these streams going around. Browsing lists, viewing bug reports, etc. etc. through firefox is operating at sluggish Comcast network speeds; we deserve the ability to do all this stuff at CPU speeds!
Also, a point I hope to get into in a future blog post is that an issue we have is that there are too many different UI's, and unfortunately with web services, the situation isn't much better. For instance, I love the Netflix UI approach, but it's completely different from GMail or Flickr (which also have great UI's optimized for their own purposes). Anyway, I'll leave that whole discussion for later.
This would be a good spot to mention an extremely interesting Desktop session at UDS2008 I enjoyed sitting through about UI integration of single-sign-on for web services. Ted Gould is maintaining a set of blueprints on the topic. The Ubuntu desktop team has some very intriguing plans under way.
Posted in Ubuntu Submitted by bryce on Wed, 2008-06-25 18:26.
bryce's blog | 4 comments
The other day I was trying to figure out what was making my desktop computer run so slow. This was pretty unusual on Linux. Way back when I used to use Windows, I'd encounter such things due to running too many programs, so of course I looked at what was running.
But these days I don't really run that many intensive applications. I hardly ever use spreadsheets, presentation tools, word processors, or so on like I used to. Really the only things visible in my task bar were Firefox and Terminal. Killing off Firefox made no difference. And even more oddly, rebooting had no effect - within minutes my load average was up in the 20-30's.
Of course, the culprit was that I had a bunch of automatic cron jobs scheduled to occur at the same time. Reordering the timings got the system back on track.
But this led to an epiphany moment.
This was my *desktop* machine. The last time I'd seen this cron job I/O blocking madness was on servers. What was I doing with so many cron jobs on a *desktop*??
I looked at the individual cron jobs, and found that each and every one of them had something to do with my job. Disabling any one of them would reduce my work productivity. I could no longer do without one of these silly cron jobs than I could have done without Microsoft Excel a decade ago.
And then, as I looked around my desktop at the other things running on it - internet radio, IRC chat, mutt - that I noticed that I hardly ever use traditional "document-centric" applications. Everything running had something to do with dealing with _streams_ of information.
The realization sank in at that point, that our computer UI paradigm really stinks for what we actually use our computers for.
The prevailing UI paradigm today is built around the notion of document authoring. It expects that the main thing you do is create spreadsheets, word documents, presentations, and so on. There is a task bar to remind you of what documents you're editing, there is cross-application cut and paste so you can put pieces of one document into another. You can place documents on your desktop surface itself, so you can organize your work. You can define which applications to use for which types of docs. You can set up a default printer to put your documents to hard copy. You can set up system-wide fonts to use in documents. You can put icons to apps and even documents onto your panel. And on and on.
Occasionally, some of that is actually useful to me. But most of the time, for most of the work I do, it's all irrelevant. To pick one example, I used absolutely none of that in order to write this blog post.
Really, what I mostly do today is stream management. And I suspect this is true for the vast majority of people. I don't deal with writing documents, but with changes to documents. I put comments onto things. I slap patches onto things. I tweak the states of things. Once in a rare while I may author a completely new thingee, but even there I usually end up working with it as a stream of changes that I build up over time (and usually in collaboration with a few other people who stream changes to me).
Thinking about user interfaces this way, it occurs to me that there are a LOT of different kinds of streams. Streams of emails. Streams of spam to take *out* of my email stream. Streaming radio broadcasts. Streams of bug reports. Streams of software updates to apply. Streams of chatter on IRC. Streams of youtube video URL's from friends and family to check out. Streams of updates to my weather applet. Even my todo list is more like a stream of things coming in and going out, than like a static document I can print and save and be done with.
Each one of those silly cron jobs bogging down my computer were critically important for me, because THEY were the tools I used for helping me stay atop all these streams. They summarized my bug streams in various ways. They filtered my email streams into more organized sub-streams. They flagged tasks (and took care of certain tasks for me). They took care of updating the tools I used day to day.
It's weird that for all the document tools at my fingertips, it's a stodgy old *server* tool that is helps my productivity the most. I wonder how non-technical people not knowledgeable about crontab and scripting deal with such things?
This all got me to a key question... Since the purpose of our desktop UI is to make our work easier and more efficient, then if today's knowledge workers are, like me, more stream-oriented than document-oriented, then doesn't it stand to reason that we ought to re-think our UI design to optimize it for making stream management easier and more efficient? How would such optimization be done? How would such a UI look and feel? What kinds of toolkits would be needed?
![[2]](http://bryceharrington.org/ubuntu/ScreenRes/screens-2.png){kind=link}
![[3]](http://bryceharrington.org/ubuntu/ScreenRes/screens-3.png){kind=link}
![[4]](http://bryceharrington.org/ubuntu/ScreenRes/screens-4.png){kind=link}
![[5]](http://bryceharrington.org/ubuntu/ScreenRes/screens-5.png){kind=link}
![[6]](http://bryceharrington.org/ubuntu/ScreenRes/screens-6.png){kind=link}
![[7]](http://bryceharrington.org/ubuntu/ScreenRes/screens-7.png){kind=link}