• On mine the 5v rail went wobbly & USB devices (including tuners) went troppo & caused BSODs.

• my antec died just after being a month old.

• had a terrible time a few yrs ago where I had around 5 HDDs die on me over a period of a few months. ... after going through absolutely everything the culprit turns out to be the Antec SmartPower 450w

• I feel for you because a similar thing happened to me 18 months ago. I managed to trash five successive HDDs before I realised that a faulty PS was zapping them.

Being a fan of the semantic web, I have a fetish for data syndication between sites. Naturally, then, when I wanted to put some links on my blog, I thought I would manage it using del.icio.us, which would provide an archive of old links, and some snazzy front-ends in the form of browser addons and of course their website.

I use the tag codebad.com:sidebar to identify bookmarks I want to appear alongside my blog.

It's very easy to have your website pull the data from del.icio.us via RSS every few hours, and incorporate that as content on your website! You could in fact probably do some very interesting stuff this way, but just including some links is the most intuitive and appropriate. Here is some code to get you started:

• deliciousparser.py is a fork of feedparser which makes delicious tag representation a bit easier to work with
• delicious_content.py is an example of how to fetch your recent delicious bookmark RSS feed over HTTP, feed them through a filter, and then through a template, which will generate HTML that can be included in your website
• sidebar_template.html is an example of an HTML template

This solution is extremely light-weight and convenient. The templating method I used only employs Python's built-in printf-style string formatting to get the job done, but you could use this technique with any templates.

I think it's a great idea, if not a terribly obvious one. Julian's purpose in his quest is a noble one:

Our solution is to use learnability as a predictor of fun. A good game is one that is not winnable by a novice player, but which the player can learn to play better and better over time, and eventually win; it has a smooth learning curve.

I think if you ignore silly animalistic compulsions like collecting items, finding all the secrets, or acting out fantasies, as well as more legitimate human animal patterns like appreciating beauty in game audio or visuals, or social interaction through gaming (hopefully more like Super Smash Bros than World of Warcraft,) I believe this is an absolutely solid function for measuring game funness.

It's worth noting here that Togelius does not explicitly state that his technique is immediately applicable to video games, only heavily implied. (It should also be noted that by video games I am going to bravely exclude all turn-based games, relegating further discussion to games which challenge one to think fast and exercise their reflexes.)

What's really more important than whether or not the technique is applicable to just video games or just conventional games is whether or not it's applicable to both, because (and I think Togelius would agree) that says something very fundamental about games and what they mean. I say his techniques are indeed applicable to both, but I see some daunting technical hurdles before him if he wants to follow up on his insinuation that he can measure the fun of Pac-Man, and luckily those hurdles are not so nuanced as animalistic compulsions and enjoying artwork.

The problem is that even in a game which discloses 100% of all information in the game at all times, there is absolutely no reason to think this means that the player perceives 100% of information in the game at all times. In order to predict funness for a single person for a single video game, even with perfect knowledge of how well they learn to plan their moves, you need an accurate model of how well they learn basic things and utilize skills like ballistic extrapolation (or whatever movement dynamics are applicable to the game) for predicting collisions (for avoiding enemies and collecting items.) What is probably more nuanced about this is that a lot of the brain hardware is shared between seemingly disparate mental processes: e.g. having to focus more on collision prediction might distract players from path finding.

Those challenges notwithstanding, I believe the technique could provide a few valuable tools to both software and cardboard game publishers.

The first is that you could try to analyze different player types, by which I mean contrasting graduation pathways (simulated using alternate mutational pathways) on players' paths to greatness at a particular game. Pathways may diverge and recombine, or end up at entirely different play strategies for the same game. Never before have I encountered a game that really made room for players who might learn very differently from each other, and I think the application of Togelius' techniques might bring some formal validity and computer-aided design to those brave enough to write the first video game that dynamically tailors its tutorials based on player performance.

The second idea for application of Togelius' technique I'll begin to explain with an excerpt from his article:

A good game is one that is not winnable by a novice player, but which the player can learn to play better and better over time, and eventually win; it has a smooth learning curve. This can be seen as an interpretation of Raph Koster's "Theory of Fun for Game Design", or of Juergen Schmidhuber's curiosity principle.

Togelius' technique teaches an AI to play a particular game, and extrapolates game quality from the smoothness of the simulated player's ascent. I happen to think that there is more interesting and complex data in that learning curve than some scalar representation of its smoothness. I would wager that the technique is capable of simulating direct transfer of knowledge on game mechanics to the player, or if you prefer, instructing the player on how to play.

By examining the influence that each individual characteristic of player behavior has on the success of the simulated player, you could potentially identify different horizons of significance among those behaviors.

For instance, knowledge of some rules for a game may clump together "at the bottom" where the player's performance was the worst, demonstrating a necessity for an instructional component to a game. I don't believe this "kink" in the "smoothness" of the learning curve should be counted among the parts of the curve which represent the experience of playing the game after reading the instruction manual or playing through the tutorial level of a video game. (In fact, if Togelius' could work the generation of tutorial levels into his video games so that the automated player could train on a single challenge at a time before facing them simultaneously, he might iron out that kink in the learning curve data.)

Such a "clumping" analysis technique could be used to analyze the learning curve of existing games, providing game publishers with a new tool to determine what rules need to be part of a rule book. Sure there are certain expressions of game rules which are *required* to be in a rule book to express the full game, but there might be important emergent characteristics of game play appropriate for inclusion in rule books, or tutoral stages in video games.

Aside from the clump at the bottom, I think most games do (or should) have two other kinds of clumps as well, and I think these other two clump varieties may be even more important than anything else I or Togelius have discussed so far. The simpler of the two first: a clump at the top might materialize when even the best player cannot gaurantee perfection all the time. A little chaos element in a game goes a long way if you ask me. If you know you're going to win every time, the game ceases to be fun, and maybe that isn't simply a function of having run out of challenges to overcome, which brings us to our final clump variety..

When I was a child, when Megaman assimilated powers from boss enemies, it wasn't only rewarding because I had just defeated a unique and powerful opponent, or because I had indulged in the compulsion to collect powerups, but because it introduced a new horizon in game dynamics. Even without manufacturing artificial horizons in player strategy by holding out on the player, I believe a fundamentally fun part of games is not just overcoming unique challenges, but uncovering them! The most rewarding elements of game play aren't simply doing something new, but experiencing those Eureka! moments when you figure out something you could have been doing all along. You've discovered something innate, you haven't been given a hand out.

Interestingly I think this is my personal #1 goal when it comes to game design. I am most attracted to games which challenge the player to invent original solutons and offer highly flexible gameplay through a wealth of emergent game dynamics. I'm quite attracted to nerdy games which involve any kind of programming or sequencing causal chains to build complex and original devices that beg the question "Did the game developers even realize I could do this?" Many moons ago I was a big fan of the game Magic: The Gathering which had even named the canon of player strategies that involved complex original solutions made from the emergent properties between many components: the "combo."

I owe a debt of gratitude to Julian for writing the article which inspired me to fully appreciate the mathematical elegance of what it is I love about games, which in a word is: ingenuity.

These instructions will tell you how to use Windows Internet Connection Sharing to extend an Internet connection to a GNU/Linux system when there is another network node that wants the same IP address that Windows ICS does (192.168.0.1.) In my case, I wanted to connect to a WAP+NAT machine that insisted on that same IP address, but I had no wireless adapters for my GNU/Linux system which could get a reception (due mostly to damaged antennae.)

First enable internet connection sharing on the interface you want by right clicking the interface with your internet connection and choosing 'Properties.' Navigate to the 'Advanced' tab and enable 'Share this Connection.'

Next open a command line interface (CLI) by choosing Start Menu/Run, or just hit "Microsoft key"+R. Enter the command 'cmd' and hit enter or 'Ok.'

From that CLI you'll want to enter another CLI with the 'netsh' command. You should now have a 'netsh' prompt. Enter the command 'interface ip' and hit enter. This should have expanded your netsh prompt a bit. Next type 'dump' to get a look at the current settings of your network interfaces. The information dump is delivered in a convenient form: a series of commands you could theoretically copy and paste verbatim, but it makes this guide a little harder to read.

netsh interface ip>dump
# Interface IP Configuration for "Local Area Connection"

set address name="Local Area Connection" source=static addr=192.168.1.1 mask=255.255.255.0
set dns name="Local Area Connection" source=static addr=none register=PRIMARY
set wins name="Local Area Connection" source=static addr=none

# Interface IP Configuration for "Wireless Network Connection"

set address name="Wireless Network Connection" source=dhcp
set dns name="Wireless Network Connection" source=dhcp register=PRIMARY
set wins name="Wireless Network Connection" source=dhcp

popd
# End of interface IP configuration
netsh interface ip>

Those 'name' descriptors in there identify the network interfaces we are to work with. Since my internet connection is through "Wireless Network Connection," I will be making my changes to "Local Area Connection." Next you'll want to use the 'set' command to assign a new IP address to the sharing end (as opposed to the internet end) which will look something like this:

netsh interface ip> set address name="Local Area Connection" source=static addr=192.168.1.1 mask=255.255.255.0

That should be it on the Windows end. Ping google.com or something to make sure your connection is still working! (If you're connecting a Windows system to the net via ICS, you can use a similar procedure to set the IP address on the client system. However the GUI route will work just as well on the client system.)

Onto the GNU/Linux end. Debian and Ubuntu users can edit their /etc/network/interfaces file (read `man 5 interfaces` for more info) so that it has an entry looking something like this:

iface eth0 inet static
address 192.168.1.8
netmask 255.255.255.0
pointopoint 192.168.1.1
gateway 192.168.1.1
post-up echo nameserver 192.168.1.1 > /etc/resolv.conf


Then you can make sure the changes take effect:

# ifdown eth0
# ifup eth0


If you can't or won't use /etc/network/interfaces, you can do things a bit more manually:

# ifconfig eth0 up 192.168.1.8 pointopoint 192.168.1.1
# echo nameserver 192.168.1.1 > /etc/resolv.conf

These instructions will assign the IP address 192.168.1.8 to your GNU/Linux system, but you can just as easily use another address. Be careful to spell pointopoint correctly -- it's POINT O POINT, not POINT TO POINT!!! The error message for that mistake is not very helpful at all!

Try to ping your Windows system to make sure the connection is up. We'll need to alter the kernel routing table next, adding a default gateway (gw) like this:

# route add default gw 192.168.1.1

Now try to ping an IP address out there on the 'net (try 208.67.222.222: an OpenDNS server.) If that's all working, go ahead and modify your /etc/resolv.conf file to match the IP address of your Windows system! It should read something like this:

nameserver 192.168.1.1

Once that's done, you should be able to ping google.com and expect a response! If anything doesn't work, remember to double-check that it's still working from your Windows system before you waste any time thinking you did something wrong on the GNU/Linux end! If something did go wrong on that end, use `route -n` to make sure the routing table looks how you wanted it to. Happy trails!

Vincent Vuntz wrote in October of musings from the User Experience Hackfest primarily (if I may be so bold) to plug an alternative desktop organizational paradigm called activities. From Vuntz' description they seem to be little other than prearranged virtual desktops (virtual desktops are also known as workspaces):

If you look at the current usage of workspaces, you can find out that most people use them to make it easy to switch between various mental contexts. And actually, nearly everybody using a computer has to switch between mental contexts, like read mail, browse the web, do my work, etc.

I too have happened upon a similar and similarly named idea; it is quite an intuitive one to power users, however the similarities between Vuntz activities and the idea I've had are only skin deep. I'd like to focus on a comment written by one "mangler" which articulates my opinion of Vuntz activities quite well:

Activities are not browse web and answer emails.[An activity is] work on a project which includes e.g. using the terminal, browsing around and answering mail, switching hamster applet on and off, chatting with project members in an IRC channel.What I want to know about activities:- How long have I worked on them- What files have I produced- What messages have I exchanged with others (be it mail or irc)

Mangler's comments out the naïve two-dimensional Vuntz activity as a simplistic fantasy of how users use desktops, and suggested some productivity-driven features to boot. I like Mangler's contributions to the notion of activity, but what I'm really hoping is that they suggest more to you than mere productivity-related features,, because maybe you aren't as concerned with productivity as you are with something else.

To this end, activities really ought to be offered as a more generalized framework which other applications and modules can plug into to provide their own facets and functions in the same way that a window manager defines the behavior of windows and decorates them with whatever window mangement controls the user sees fit to have.

To explore what kinds of features you might want to add to your desktop's notion of activities I think we should explore their very nature a little further.

An activity seems to be a more or less informal spatial organization of application windows with the prescribed intent of associating windows relevant to a specific activity.

One difference might be that while most things called virtual desktops can only accommodate windows which appear on one or all virtual desktops in a single session, perhaps something called activities can do away with that limiting spatial metaphor. That is to say: with virtual desktops a window is either tied to your screen or it is tied to one of the rigid partitions in a large expanse of virtual space you call a virtual desktop; perhaps individual activities can be more like a plan describing window visibility and position.

Ok, that may seem a rather shallow difference at first, but it gets messier. Let's consider two very different approaches toward similar (though not identical) user interface-related goals.

First UI approach: custom shells. By which I mean software packages which offer to dump you into a command shell with a modified PATH (for the uninitiated, PATH is a variable that determines which commands are immediately available to the user.) I've encountered packages ranging from compiler toolchains to revision control systems which offered a custom shell as the default mode of interaction with the software. The goals accomplished by the custom shell might be three-fold; the first two involve name collisions: if you desire commands that share names with other known packages (or names which would be impolite to assume domain over) then modifying the PATH environ is an easy route to success. The other goal is convenience, and that's closely related to the second approach to user interfaces I want to discuss.

Second UI approach: graphical user interfaces. Why on Earth would someone trade in the near-limitless power of the command shell for a slower, more limited graphical interface? You can type many more commands than you can fit buttons on your screen, and using menus and moving the mouse around is laborious and unnecessarily slow! The first reason is obvious: it's easier on your primitive human memory. Buttons and menus are like a clickable cheat-sheet of commands you can enter (of course most GUIs even offer hints to help users forgo using that slow mouse, but that is neither here nor there.)

What custom shells and GUIs have in common with one another is activity-centric organization!

The user interface design approach used in every typical graphical application is the same approach we're craving when we follow our noses into the corner of the memesphere where activities live, yet somehow when we all stumble into this intuitive user interface idea, we tend to miss the clear connection between activities and the advent of GUIs.

Let's be clear about one technological reality: most GUI toolkits are application-centric; that is to say that most system processes represented by GUIs have their own windows which are not shared by other system processes represented by GUIs. It's as if we couldn't let the greenbeans touch the mashed potatoes! There are exceptions, of course: Gnome panel applets, Growl alerts, GTK+ plugs and sockets, the near-ubiquitous "tray icons" and NextStep dock applets -- just to name a few; and there are plenty of ways of writing pluggable software which isn't represented by a system process, and can be dynamically loaded by other program code, shared libraries and scripting languages chief among them.

Just examine the anatomy of any graphical user interface to see what I'm getting at with my comparison of GUI and activity. The X-Chat IRC client has different tabs or pages for switching your focus between different IRC channels. It has a text-entry widget for entering messages and commands. It has a list of users in the active channel. It has a box containing the channel topic. The only thing barring us from seeing graphical applications in the same way that we see activities is because of the monolithic application-centric design pattern. How about launchers? In a very legitimate way, the act of starting an application is as much a part of that application as it is a part of the application you used to start it. So a launcher can be seen as a field of limited cooperation between different applications, tied together due to a mere technical limitation into a launcher. Lots of applications are like database interfaces mated with various other tasks: media players, news readers, mail clients. Your web browser is a database of bookmarks, cookies, and browsing history combined with a network transaction layer (GUI representation = "location bar") and an application sandbox environment we call "the web." If you think about it, the underlying databases containing your history and bookmarks never needed to be specific to individual browser programs, and neither did the user interfaces that correspond to them. Apple's Spotlight might just as easily draw up your documents as it might draw up your browser history on any one of your browsers, and my bookmarks are stored on del.icio.us

Activities may be a good idea, but what I'm trying to get across in this article is that we're already using activities: we should focus more on tearing down the barriers between applications than on trying to arrange their windows.

Dylan McCall wrote:

This would benefit particularly if we beefed up file handling to be more sensible, for example remembering what programs were used to work on certain files and providing options for particular "actions" that can be performed on files in a way much like "Open with" but a bit more understandable. In addition, it would help if the shell was more consistent with applications it launches so that "files" in the file manager sense stopped being files and started being documents, graphics and whatnot as they are in their more specialized tools.

Pre-X, Mac OS had this same behavior, and let me just say that it was extremely annoying to me personally, and implementing it is fraught with pitfalls: metadata does not carefully follow files as they get moved around. Every time you move or copy a file it would forget which application you "preferred" (quotes deliberate) to open it with in the same way that it forgets what its thumbnail looks like, except that thumbnails can be recalculated from the contents of the file, whereas your "preferred" viewer/editor application cannot.

I would however like to point out the similarities between a graphical shell that remembers which applications you prefer for individual files, and the custom command shells I mentioned earlier. Perhaps it would be useful to associate file handlers with different activity screens. Immediately what comes to mind is that if you have The GIMP or Photoshop associated with an activity, double-clicking file icons in that activity would prefer to open the file with The GIMP or Photoshop. The same could be said for opening video clips: a regular media player by default, your favorite video editing software from within your video editing activity. The only downside to this seems to be that drag-and-drop has served this purpose perfectly well in the past.

If I may, I'd like to bring this article to an end with a few crazy ideas I've had in the past for desktop organizational paradigms and tools that are quite different

Windows/Portals

Every now and then I remember the realization I had that the popular notion of windows might have been called boxes if desktop environments allowed you to choose an arbitrary rectangle from a GUI and tear it off and display it elsewhere on your screen. Many GUI toolkits allow for widgets to be explicitly set to "tearable" (GTK+ has years on Microsoft in implementing this feature) but those widgets are discrete and really only meant for reorganizing toolbars and menus. Ultimately I think the idea is a bit impractical, but it meets with a certain programmer's sense of efficiency to implement tearable toolbars as a subset of the ability to tear arbitrary rectangles out of GUIs and reorganize them as you see fit!

Infinite Desktop

The Infinite Desktop idea is not much different from the existing virtual desktop/workspace approach. Virtual desktops are a lot like one giant desktop which you can only page in edge-of-screen sized increments. What if you could page in much smaller increments? (Or no increments: smooth scrolling?) What if the dimensions of this virtual desktop had no practical limitation and scrolling vertically was as easy as scrolling horizontally?

Controlling such a large desktop with such small increments seems unwieldy with controls that are conventional for existing virtual desktops, but I think I have a solution to that problem. If you've ever used Mac OS X's zoom feature (made easy by the fact that they had one of the first hardware-accelerated window compositing layers in a popular windowing environment) I hope you noticed the default movement option is much more satisfying than the other option. When you zoom in, your notional desktop is now visually larger than your display is, and you must pan your screen (let's call it a viewport) around to see it all. The obvious user interface for this is to move the mouse cursor beyond the edge of the viewport, intuitively nudging it in that direction, exposing the parts of the desktop you want to access.

The better user interface -- and the default with Mac OS X's zoom feature -- is for the viewport to be positioned within the expanse of the desktop relative to how the mouse cursor is positioned within the expanse of the display.

What that means is that if your cursor is in the corner of your display, then the viewport is showing that corner of the desktop. As you move your cursor in any direction, the viewport gradually pans in that direction, too.

Simple alternatives include holding a key/button combination and dragging the viewport/desktop position relative to the desktop/viewport position. There is zoom control to consider too, but I'll leave that up to you, but not before suggesting that maybe windows can be scaled arbitrarily! Maybe important windows are larger ones, positioned around the periphery of your primary window galaxy. Perhaps notionally-related workspaces / activities are organized into scaled-down collections which you have to zoom in on to use, and which look like the thumbnails of virtual desktop pagers when you aren't zoomed in on them. Perhaps you can also instantiate formal rectangular organizations which can be clicked on to zoom in and lock in so that you are free to mouse without moving the viewport, if that sort of thing bothers you (for many activities, I imagine it might; but there are plenty of ways you can imagine to lock the screen in place, I'm sure.)

Exposé, Dashboard, and the Desktop

The desktop serves, as far as I can see, two functions, be they or be they not usurped by other features which can fulfill the same purposes. First, it's the first thing you see when you login! Perhaps the desktop has never been embraced as the go-to interface for starting new tasks/applications/whathaveyou because beside being the first thing you see, it's also the first thing to become obscured. On the other hand, Microsoft Windows' and the Gnome desktop environment have both had a show desktop feature for over a decade, Mac OS X has had Exposé for many years now. Is the Desktop really any more keystrokes/mouseclicks away from your Start Menu, applications menu, Dock, Gnome Do, run command dialog, Spotlight, or any other interface you use for running programs or opening files?

The primary thing holding back the desktop has been that navigating them is kludgy, they are often unorganized (or if they are organized, they're too organized to serve other legitimate uses) and more often than not they're just a file-folder abstraction for some directory within your HOME directory (with the notable exceptions of icons representing filesystems, removable media, and make-believe places like My Computer.)

Sure, you can add icons for your favorite documents, applications, and URLs on the web, but as I mentioned before, the Desktop has been too kludgy for even most novices to fool themselves into thinking that's a convenient place for them to go. The desktop for most people tends to be a neglected place, at best a rest stop for recent downloads, and the place to access removable media.

I also like Apple's Dashboard (at least in concept -- in implementation it's a ludicrous hog of memory) as an alternative home for applets which are too big or otherwise ill-fit for your Gnome panels / Windows Taskbar / Dock.

Are they a match?

I think they are! As a software developer I appreciate the ease of access of the contents of my desktop (an ordinary directory populated by ordinary files? Can it get any simpler?) but I think the Desktop can be much, much more.

While it may not be the best idea for Apple's target demographic, I think most Linux users would feel right at home with this idea: What if you merged Apple's Desktop Exposé function and Apple's Dashboard reveal function? What if your most commonly use applications, application/Start menu, and a generic run dialog, recent documents/downloads all had a home within an organizational paradigm sitting somewhere between the idea of a Desktop and the idea of Apple's Dashboard?

The Desktop has remained unchanged for a long time in part (I think) because the friendly cluttered meat-world desktop analogy is charming and unintimidating, and is always easy to access for developers. But I propose that it's time to move the Desktop forward. I want to press one key or key combination and have all those things at my disposal. Perhaps this is even where your virtual desktop / workspace pager, or notification backlog belongs. Of course it doesn't really matter what I think belongs there, as long as there's a good applet / plug+socket / docklet framework for it.

MicroID enables anyone to claim verifiable ownership over content hosted anywhere on the web... MicroID is not an authentication or single-sign-on service, just a straightforward method for identifying content ownership...

To verify a user's membership in any (trusted) 3rd party site...

By itself, a MicroID has no inherent meaning, since it is simply a string created from two URIs. Any entity can generate a MicroID even if it has not verified the identity of the resources associated with one or both URIs. Furthermore, a MicroID is easily copied by an entity that did not generate it. Finally, a MicroID is not digitally signed by the entity that generated it and therefore cannot be cryptographically associated with the generating entity.

• Extracting and digesting idioms of interest; things like comments, related blog posts, related videos, related URLs, keywords and tags, favorites / bookmarks / score, etc.
• Merging those idioms pulled from the default data source (the website you're visiting) with data pulled from other data sources.
• Reconciling the differences between the capabilities of the services those idioms are pulled from, and potentially upgrading the user interface provided by the website you're visiting to support their richest potential format (or whatever the user has specified in their preferences.)
• Accepting content pushed by the user in the upgraded format; since the idioms being displayed have been abstracted away from the website you're viewing and its inherent limitations, there's no reason you need to publish to that specification either (I really *really* hate the character limit on YouTube comments)
• Pushing the content to other data sources -- maybe the same video is even on three different video sites -- why should the user be limited from viewing the aggregate data of all three at the same time in the same interface, and participating in discussion with users of all three sites?