As with most articles that put a Windows user in front of a GNU/Linux box and the GNU/Linux box isn't decided as the emphatic winner, The Great Ubuntu-Girlfriend Experiment is making the rounds. Reading the responses to these articles is tedious because their are just so many, so, I'm responding separately.

By and large I find these sorts of usability experiences enlightening and useful. Rather than bog myself down in the finer points of the debate about which of Windows, OS X, and Ubuntu GNU/Linux sucks the least, I prefer to focus on the flaws discovered that are very clearly flaws. In a lot of cases, the most experienced of us have simple solutions to them. The problem with these solutions is that they are mostly invisible and it's hard to find out about them without the right expert around. I will present some of my ideas on what the things that are clearly weaknesses and the solutions I'd like to see to the problem.

( Read more... )

I think I could make myself a big name in the open-source world if I put together an awesome visualization for the blog and mailing-list drama that all of these developers share. I know I love to follow it and read about it. Looking at kerneltrap.org and LWN the articles that follow developer arguments are the ones that I flock to.

Yesterday's post of mine transformed into a rather well-written article by Jonathan Corbet. I don't think I can write as well or put it together as well, but, a visualization would be nice. When you look at the framing of that article there's a distinct time-line wrapped amongst it that is lost. Neither the full article or the mailing list threads can seem to capture it.

Then there are other developing dramas that have no centralized place to watch them unfold. Such is the disadvantage to blogs, and the nature that drives RSS feeds.

Ryan Paul of Ars Technica fame wrote this article about GTK+ 3 development. Personally, I loved it. Thomas Wood, however, didn't agree. Ryan, being a member of the GNOME community and a blog watcher, didn't take these comments silently. Thomas, wanting to have the last word, defended himself against Ryan's attack of sorts. Seems both of them have a standing issue with the other's use of language, but, Thomas doesn't seem to like the threats of less coverage coming from Ryan over the whole matter.

These sorts of flows interest me a lot, and, I wonder how they might be transformed into something more visible and trackable. At the very least, what if I forget about this? These things are often settled quietly amongst blogs and, I think, this may actually be a core source of where so much misinformation comes from. We tend to assume that the heavy visibility of the whole matter makes the truth obvious. Ultimately though, there's a flood of information that's not easy for people to follow, even if they know exactly where to find it.

Kerneltrap thread archive

From: David Miller <davem@...>
Subject: Re: Reporting bugs and bisection
Date: Apr 14, 1:43 am 2008

From: David Miller <davem@davemloft.net>
Date: Sun, 13 Apr 2008 23:39:59 -0700 (PDT)

> I wrote or merged in ~10 bugs in the last hour, for example.

Bug fixes!  I meant "fixes" I swear!

That's quite a Freudian slip if I ever saw one.

Overall what we're looking at is a fairly classic debate between process vs. quality vs. code contribution. Looking at the individual pieces and steps, the conversation doesn't seem to be going anywhere. Miller and others don't want to be bogged down and think they are on the wrong track. Morton just wants to keep everybody on the right track and nobody else seems to agree that there's a problem.

I like conversations like this that manage to stay civil because they keep attention on the problem. People are pulling out data, solving problems, and doing everything they can to convince Morton that there isn't a problem. This, is a good thing. It's the sort of bureaucracy that the lkml represents: No process, but lots of arguing and attention to keep things going. That passion drives it. Somewhere I imagine Morton smiling as all of these developers jump on to fix bugs and prove him wrong. Maybe he wasn't right in the first place, but, if more bugs get fixed, should he even care?

http://gould.cx/ted/blog/Green_Windows

It seems everybody and their mothers are trying to do email the exact same way, or pick a paradigm I just don't care for.

Gmail and the Conversation

Gmail started with a wonderful idea: People often think of emails with each other as a conversation. You have all of the emails under a certain subject header grouped together in one continuous view. For times when you're talking to just one or two people, in order, this is fantastic. If it becomes more complicated than that it's just plain bedlam.

I'm on a number of mailing lists which have huge amounts of traffic and people respond to emails as they see them. This means I essentially get a random mixture of responses all simply ordered as they arrived in my inbox or as they were sent from the other person's. Take into account how YahooGroups! will sometimes send emails out in random order and it's just impossible to sort.

Because of how hard it is to comprehend where you are inside of these conversations, it encourages people to top-post, as that leaves the most of the previous message in tact. This, in my opinion, is probably the worst thing that can be done. Gmail uses a few ingenious methods to cut the cost of top-posting when trying to read the emails, but an important caveat is that we're still punishing everybody in the world that doesn't use gmail with these ridiculously huge emails.

Threading Done Mostly Right

For most things I prefer threaded views. It scales much better than conversations. Also, I rarely interact in threads where only two or there people are speaking.

YahooGroups! actually has one of the better thread views that I've seen. Gmane uses a threaded view that's just as functional and more spartan. I tend to like the way that YahooGroups! summarizes posts, but I understand wanting to use the gmane style view for huge mailing lists.

The Last Vestiges of Failure

I like the threaded view, but what's the biggest problem with it? Thread views seem to be entirely dependent on what the other person sending the email is doing. If they have a broken mailing client that doesn't mark the new post properly, then your entire thread view is fragged.

A much worse example is when you just have people that don't know what they're doing and rather than sending a fresh email to a list, they hit reply not realizing that some people's clients care who their replying to. This results in either strange and entirely off-topic posts, or brand-new posts that are buried in a thread from six months ago.

What do I want?

In something like Thunderbird, we shouldn't have this problem. All of the information is stored inside of a local mbox, so why can't I just move emails around to associate them between threads? This would mean that at least I can reorganize when the list gets too long or pull out somebody that sent a re: Blah [was: Mrah] that gets lumped in with the original thread. Maybe I want them lumped in? Who knows, but sometimes the engine is wrong and needs help.

The other thing that would be nice is some sort of flag to bring new emails straight to the top that seem to be to dead threads. We have spam detection and scam detection. Why aren't we also detecting potentially incorrect email listing? Chances are that a new email to a thread that's a year old doesn't belong. There could easily be a tweakable metric based on email volume to help decide how quickly a thread should be considered dead. On some lists I'm on, a thread is dead after a week.

Here's the beginning of a thread about the OpenBSD bcw driver copying code directly from the bcm43xx drive in linux: http://marc.info/?t=117571775000002&r=4&w=2

Let me summarize some points from this:

1. bcm43xx code was copied. The developer working on bcw accidentally committed code segments over multiple commits that were exact duplicates of bcm43xx code.
2. In taking this action, the developer of bcw relicensed GPL'd bcm43xx code into an ISC license which essentially only requires a dissolution of warranty notice. This is a violation of the GPL, and the developer did not have the right to do this.

That's really all that's important from this thread, but it is massively long. Theo seems to harp on the following points:

1. The bcm43xx developer is a jerk for bringing this up publicly.
2. The bcm43xx developer is calling the bcw developer a thief and shouldn't be.
3. The Linux/GPL community can't be trusted to work with us because they were ass-hats about the Atheros driver.

Firstly, it's hard to call the linux-wireless list public beyond its specific community.

Secondly, by the terms of the GPL, the bcw developer that committed this code is a thief. The GPL community is just generally more forgiving about these sorts of things. In many ways, we are less tolerant of *BSD taking our code because their adherents highly devalue our license because of its restrictions. Also, *BSD becomes a gateway for corporations to take GPL'd code and incorporate it into their products.

In that last sense, it's much worse for a person who prefers the GPL to dual-license than somebody that prefers BSD. BSD is often pushed by people that want you to do "anything" with their code, so why should they care?

On the last point, the only person that's been entirely unreasonable in this is Theo. He really does creatively snip emails and constantly shift the subject. I do agree with people that he spent a lot of time insulting bcm43xx developers in order to obfuscate that the bcw developer actually did something wrong. Theo also spent a lot of time upset that the bcw driver needed to be deleted to solve this problem. Well, that's what happens when you copy code illegally and post it to a "public" place.

In the end, this thread tells me something I've always known: Theo is a selfish asshole that doesn't respect the efforts of other projects and their opinions on anything related to copyrights and licensing. I don't think he necessarily needs to change because that leadership style seems to work for the community that's built around it. In the end though, it's ridiculous to hear him claim that anybody else is getting in the way of cooperation. I would put him at the top of the list.

As an aside, as angry as I am at Theo right now, I think he does have a point about how Linux developers shouldn't accept NDAs to make GPL'd drivers without specs being released. Although, that doesn't justify Theo's team taking GPLd drivers and relicensing them in a way incompatible with the GPL. Yes, Theo, it is possible for you to be partially right and partially wrong. This is something you need to realize.

This is mostly in response to a post from Joe Shaw on Planet Gnome.

He's right about one thing, yes, 'svn ls -v svn+ssh://svn.gnome.org/svn/beagle/tags | sort' is more annoying to type than 'cvs log', but it doesn't give you any less power.

"
This will give you the same info:

       2963  ?                    Nov 01 15:12 BEAGLE_0_2_12/
       3015  ?                    Nov 20 15:29 BEAGLE_0_2_13/
       3124  ?                    Dec 14 13:36 BEAGLE_0_2_14/

And you can diff between the tags, but you can’t easily diff the individual changes. That is something I am going to miss."

Yes, you can easily diff the individual changes, without having to deal with the tags directory. You get the log for the the main branch this tag comes from between those revisions.

I believe Joe knew the file he was trying to deal with annotating a single file. Let's call this file Blah.cs. When looking for the changes between 2.13, and 2.14, he could use the following command:

svn log -r 3015:3124 svn+ssh://svn.gnome.org/svn/beagle/trunk/Blah.cs

This would give the changelog for the differences between those two versions. You can even use that -r argument with annotation. It leaves a dash for each line that was changed outside of the range so you can see just what changed within the scope of your commits.

In essence, these tags are no weaker, they're just different. You should never really use your tags directory other than to checkout old releases and get a list of when you tagged your trunk.

Duke Nukem Forever really has taken a long time: http://duke.a-13.net/

It's been too long since a real update here. I'm going to start setting myself some schedules and such, but work is pretty hectic. News for the day is that I've set up a mugshot account. Feel free to add me and track my life more than google already lets you do so.

This Sunday I'm going to put some more time into Crack-Attack! I have a few things that need to get done before 1.1.15. Turns out that there is no automatic rate limiting so we'll just use however much bandwidth you have! This is unacceptable. I need to add a --rate switch so people can tune this. There are some other things I'd like to do, but the release will *never* come out if I don't just get this done and push it out the door.

I'm also redesigned the council web pages for One World by Night. That's certainly been fun to work on, and I'm not as finished as I should be. Doesn't really matter though because I'm not a real time-line. Not my hope is to get that done in January.

There's also the oft-forgotten Railsvine. Nobody else seems interested in it, but I still want to get this done. It's been set aside for so long now. I would really like help with it, but I'm not finding there are a lot of people that see the utility. Hopefully I can make it more generic one day and get some appeal from other game types. Anybody out there with ideas?

For a school project I did a mod of cube which was rather simple. It just added some GUI features and changed combat to be power-level based in a manner similar to AnimeMod. One of the harder to use abilities was one where you would teleport a short pace and automatically face your opponent. I want to revisit that mod and make this leave an "echo" of your character behind to confuse the enemy. Otherwise it was just too easy to realize what had happened and shoot at the new location. I should also have to clean up the push code so you don't get stuck in pixel walls, but that didn't happen as often as we thought it would.

My preferred file browser is emelFM. You can check it out at emelfm.sf.net. It's written in GTK+, the old one. There is an effort to port it, which is called emelFM2.
I was thinking about this a little bit. I don't really like the new one. It comes with basically the same features, but it just doesn't feel the same. It doesn't feel as easy to use. I doubt this is a function of gtk+2, but something about it just doesn't sit well.
Then I realized, I'd rather see it done in fltk. gtk+2.0 isn't a light toolkit at all. It offers a lot of features and functionality, but I think these are contrary to emelFM. emelFM caters to the same sort of "just the metal" crowd that fltk does.
I don't know if I'm the one to do this, but I've been interested in learning fltk off and on. This may be just the experiment to push me in that direction.

I'm still working on getting a real website together, but Railsvine has been accepted by Sourceforge.net for hosting. You can find the initial source code release there! I'll be making more updates to actually inform people of how to use features as soon as possible.

http://sourceforge.net/projects/railsvine

Work

I have a job now with a company called Intercept Technologies. They make the PCB software Pantheon and Mozaix. It's a fun job. Pays the bills. Unfortunately, it's so distracting from these free pursuits.

Crack-Attack

We have a new active developer! His name is Bj0rn. He apparently also works on The Mana World. Overall I've been pleased with how active he is and the good bit of knowledge he brings from working on other projects, even at the infrastructure level. I've always felt in the dark while maintaining crack-attack because it is really the first project I ever tried to do this with.

Not to long ago, he apologized for being another potentially inactive developer. In my mind, this is okay. Since we're all too busy to work on it all of the time, at the very least all of the effort should be put in one place.

The 1.1.15 release is on hold because an ENet upgrade broke x86-64 again.

Taunts and Sound

Some time ago, when the sound patches were first introduced, Webb and I were joking about adding sounds for combo levels. This eventually evolved into actually having the AI player throw out taunts a la DDR.

This was put mostly on the back-burner until some friends of mine suddenly became excited at the idea of recording their voices. Long story short: I'm getting people to record taunts and such for crack-attack. Hopefully they'll be funny and add some immersion to the game.

Ruby on Rails

Railsvine has been accepted at sourceforge. I have yet to upload anything because I'm working on putting in the license headers. When that's done, it will be there for the world to see!

I'm also getting specs from the head coordinator of OWbN as to what he would need to use this as an organization wide database.

In that same vein, I think I've volunteered myself to redo the council pages in Ruby on Rails. I think that I take on too much.

It seems that no matter where I go, KDE is the only desktop environment with a fuzzy clock. This is unacceptable! Thus, I have implemented my own method for determining a fuzzy string based on the time. I've integrated it to some degree with the orageclock panel-plugin for Xfce4. Either way, here is a generic C method to find the fuzzy time. I release this into the public domain, because everybody should be allowed the fuzziness!

Update: There was a bug in the fuzzy clock! It is now fixed. I had twelve at the end of the hour array rather than at 0 where it belonged.

Update: Another bug. I forgot to actually use the next hour. How did I miss that one?

#include 

We need to get 1.1.15 squared away for release!

===========================
Crack-Attack! 1.1.15 CVS 01
===========================

It's time to begin testing for a new release.

Over the 1.1.15 development cycle we changed the networking code to use
ENet[1]. This has two important implications:
1) 1.1.15 is not backwards compatible with any other versions of
crack-attack at all.
2) We need people to test the new code to death!

We've narrowed down a lot of bugs in it so far, and generally we've been
pleased with how much less lag their is involved in a game. Who knows
what else could go wrong though? Help us find out!

This is an important milestone because, using ENet, we'll be able to
begin work on features like a better interface for connecting, and
showing both player's screens in a networked game.

If you'd like to be more involved, check out the tasks page to submit
ideas and find a good place to start:

https://savannah.nongnu.org/task/?group=crack-attack

The Crack-Attack! 1.1.15 CVS O1 packages are available here:

Linux Autopackage
http://download.savannah.nongnu.org/releases/crack-attack/crack-attack-1.1.15-cvs-01.x86.package

Windows Installer
http://download.savannah.nongnu.org/releases/crack-attack/Crack-Attack-1.1.15-cvs-01-Setup.exe

Sources
http://download.savannah.nongnu.org/releases/crack-attack/crack-attack-1.1.15-cvs-01.tar.gz
http://download.savannah.nongnu.org/releases/crack-attack/crack-attack-1.1.15-cvs-01.tar.bz2

[1] http://enet.cubik.org/

Hope you like it!

Andrew Sayman

Years ago I wrote a patch for Gaim to properly handle showing the idle status for all of the presences a jabber contact has. It has finally been accepted.

I stopped using Gaim some time ago in favor of Gajim, so it's a little funny to see this patch go in now. Maybe I'll take a look at doing more work for that some time since I'm waiting to see where the notification python libraries and the API for NetworkManager go.

Federico talks about throttling repaints on motion events.

This seems like a solution that will only solve the problem for motion events. Maybe that's the only time it applies, but I wonder if another approach would work better.

Specifically, rather than taking repaint() as a command, it simply suggests that the widget should be redrawed. Some other timer which is linked with the vertical refresh checks the widget and then calls the paint procedure if need_repaint or some other such flag is set. This way, no matter how many events are called, we will only redraw the widget when it's useful to do so.

The obvious problem with this is synchronization. We could easily run into the problem of the data structures being altered while trying to redraw, which would be a horrible thing. Thinking about the usage of the code, we know that whenever repaint() is called the widget is -- supposedly -- in a drawable state.

We can think of this much the way schedule() is used in the kernel. Whenever schedule() is called, we assume that it's a valid point to pre-empt because all of the code should be prepared for a new process to run at that point.

Rather than having repaint() set a flag and having a separate drawing loop, we modify repaint() to only run when another flag is set called vert_refresh. vert_refresh can be set by something that monitors the vertical refresh on the monitor. If vert_refresh is true, we will repaint the widget immediately when repaint() is called. If not, we won't redraw until the next call to repaint().

This has its own problems. In particular, if we're outside of motion events, there may not be enough calls to repaint() and we'll lose an update unexpectedly.

One potential way to deal with this is to add a separate call called repaint_aligned() which uses this new alignment behavior. This can be used while motion events are still happening, and then a final repaint() can be called when the mouse_released event happens (i.e., there will be no more motion events).

Comments?

This semester has turned out to be one of my busiest ever. I'm only taking 12 hours of classes, the minimum I can take, but they all schedule stuff to be due at the same time. As a result, my projects have fallen to the wayside. After graduation, these are the things on my To Do list.

Crack-Attack

The ENet code is working, but my Windows build environment was trashed again. Webb and I need to package this up and get it out of the door. What's most frustrating about this is that the code is 100%. It's really just the packaging that's screwing us, but that's turning out to be the hardest part.

Gajim

Nkour seems to have left the Gajim project, leaving me without my mentor. I still do what I can to keep up with the notify code. When I finish, I'm going to be working on connectivity with NetworkManager and also make the connection errors non-blocking. They'll appear through the notification-daemon, and not go away until you click them, but won't stall out the whole application! This is a must.

Railsvine

I need to get back onto this project. It's an online character database which behaves very similarly to Grapevine. This is about 40% complete, but the roadmap ahead is obvious. I still haven't given some others access to the code base. That is a bad thing which I will correct in due time.

Jabber Status Bot

I've wanted to do a jabber bot for a while, and I've finally come up with what it can do. I'll connect the bot to information about the Status of characters in the LARP that I play at. This way characters can query somebody else's status at almost any time!

I'll probably do this in Ruby or Python. I have yet to decide if I'll handle it as a D-BUS service that connects with Gajim, or just have it as a standalone application or daemon. If I do it as a daemon, I think it will be more useful to others. OTOH, I know how to hook into Gajim and this will keep me invested in the project.

I find myself increasingly thinking about the utility of using Jabber to help me communicate between my two computers. Gajim has a dbus framework for sending messages and such. I'd like to set up a notification system where other things can pass the notifications across to me on other resources. I suspect this would be an interesting extension to notification-daemon that would be fun to implement and could be useful.

Mostly these ideas started up after reading the article about using an iPod to steal data from a company. On that same page is an AIM bot that can be used to remotely manage your system. I would really like to make a Jabber bot to do the same thing. The most immediate and obvious problem is the lack of encryption on the commands.

Really, the other question is "Why not use SSH?" Well, I do use SSH. The problem is that SSH doesn't work really well for notifications. I'd like to be informed of events without having to constantly look at the screen. Really, I want a shell with a setup where when a command finishes it messages me about it and does a notification popup. I think this could be done with a bash script and would help massively with asynchronous, multi-tasking activities.

As a Gentoo user, I think it would be awesome to initiate an update remotely and receive messages back when it succeeded or failed, especially considering how long that process can take sometimes.

The same thing would be useful for BitTorrent and other downloads when I'm away from my core computer.

We're nearly done with the ENet-cvs branch. We're gonna make this the main branch and release soon, and it'll be great.

I've recently discovered Planet GNOME, and I love it. We're currently running into a bug in crack-attack with GIOChannels which was discussed some time ago along there by Joe Shaw. This helped us out, but we're running into a problem where some of our output is tailored specifically for consoles. This is causing a lockup in the child process while trying to play.

Enter Mac Crack Attack. Some time ago I found out about these guys, and I still want to find a way for our projects to combine. The problem is that I don't have a Mac and can't get the ENet branch working.

Now, to the solution they've offered me. Six weeks ago that project starting moving messages from being handled by cout/cerr to a class called Alert. I'm not a fan of their implementation, but this seems like the perfect solution to my problem.

In Game.h and a few other places, there are lots of macros that are used to output information to the console. The main purpose of the macros was to be able to define them to null for Windows. Well, we need more than that. I'm going to head through these and define the macros to point to a new Alert of Output class. That way we can let the game process know a bit more about what it's outputting to and decide what to send.

Thank you Daniel Aarno, or whoever initiated those changes in Mac Crack Attack.