5 System Administration Tools for KDE
Now Anyone Can Host Their Own (Experimental) Google Wave Server
Back in May, when Google Wave first made its debut on the stage of the Google I/O conference, we chronicled what we believed to be the top 6 game-changing features of Google Wave.
While we discussed some big ones such as Wave extensions and its wiki-like interface, the feature that we said “may be the most important aspect of Google Wave” was its open-source nature.
Not only did Google promise to let developers improve the code, but they promised federation for Wave, meaning that anyone could take the Wave code and run their own private or public wave server. Today, Google took the first step towards the full federation of its real-time communication platform by announcing that the developer sandbox version of Google Wave is open for experimental federation.
Let’s be clear: this is a very early stage test of federating the Google Wave code onto non-Google servers. It only affects the developer sandbox, meaning that the preview version of Wave that most people are using is not a part of this test. However, it is a big step in making it a widespread product, rather than only a tool of early adopters. Businesses and individuals can begin testing their own local copy of Wave. This is just the beginning of Google’s legitimate attempt to upend email as the standard for web correspondence and communication.
If you’re a developer with a sandbox account and want to get started, Google has published some installation instructions for a Java version. Be warned though: there will be a lot of changes occurring over the next few weeks, many of them based on developer feedback.
More Google Wave Resources from Mashable
- Testing Google Wave: This Thing is Tidal- The Top 6 Game-Changing Features of Google Wave
- Google Wave: 5 Ways It Could Change the Web
- Google Wave Extensions: An Inside Look
- Could Google Wave Redefine Email and Web Communication?
Reviews: Google, Google Wave
Tags: Federation, Google, Google Wave, Google Wave Federation
"How could Microsoft’s Proposed Browser Ballot be More Awesome?
(Note: This is my personal opinion and doesn’t reflect Mozilla’s official position nor any formal statement from Mozilla)
In my post on October 15, I wrote about the European Commission (EC)’s investigation of Microsoft due to its bundling of Internet Explorer (IE) with Windows, which the EC viewed as potentially harming consumer choice and innovation on the web. Microsoft, to appease the EC, proposed that Windows users be presented with a ballot in which they could choose which browser to install. I said at the time, and in a subsequent post, that creating a ballot would not successfully address the EC’s concerns nor provide a good experience to users. However, since the EC seems to be giving Microsoft the go-ahead to design a ballot, it seems that the best we can do is consider how to design a ballot that causes the least amount of harm to users.
Here are two broad principles that are important in ballot design.
Principle 1: A ballot should be clear and simple
A ballot should present the voter with the information they need to make an informed choice, but no more. The verbal and graphic language on the ballot should be organized so that readers follow a consistent path through the ballot’s information. Many viewing the browser ballot will not be familiar with the browser as a separable element from the operating system, so clear and precise language is vital.
In interaction design, the complexity of a new task can be lessened by leveraging against what the user already knows and expects. For instance, it’s usually best to display the instructions in the top left for western readers, and before the the possible ballot choices (Kimball and Kropf 2002). It is also recommended that the instructions be as close to the first task as possible, because it provides the highest chance that voters will read them (Dillman and Christian 2002 (pdf)).
Other recommendations to make a ballot simple and clear include:
- Instructions written short and simply, and in an active, affirmative style (Sanders and McCormick 1993)
- No unnecessary information or clutter around the choices (Niemi and Herrnson 2003)
- No text smaller than 12pt (Roth 1994), left justification preferred (Dillman 1978), shading and highlighting used to direct the voter’s focus (Kimball and Kropf 2002)
- Ballot items listed in a single row or column (Darcy and Schneider, 1989). Failure to do this is part of what caused the ballot problems in Florida during the 2004 US Presidential election
- Enough spacing between lines to highlight groupings of visual elements (Dillman 2000)
- No ambiguity over which button corresponds to which choice (Kimball and Kropf 2002)
Principle 2: A ballot should be impartial
I wrote in my previous post about how ballot order can influence voters. Another important factor is how much physical space on the ballot each item is designated.
The current design runs into some problems with designated space per item, swayed in favor of IE. For instance, in the current design:
- The user must double-click on an Internet Explorer icon, labeled “Internet Explorer”, to launch the ballot
- The ballot appears within Internet Explorer browser chrome
- Internet Explorer is mentioned repeatedly within the ballot, Bing is shown as the default search engine, and the IE logo appears as a favicon multiple times
The current space allocation for IE is roughly 3.35 times as much as the other browsers.
This space that IE occupies in the top left of the ballot is particularly important because it’s where users begin an eye scan of a new page. As an anonymous source pointed out to me, Microsoft mentions this in their layout guidelines:
“All things being equal, users first look in the upper left corner of a window, scan across the page, and end their scan in the lower right corner. They tend to ignore the lower left corner.But in interactive UI, not all things are equal so different UI elements receive different levels of attention. Users tend to look at interactive controls—especially controls in the upper left and center of the window—and prominent text first”
Improving the ballot based on these principles
In summary, the ballot would be improved by being simpler, clearer, and be presented with equal weight to each browser.
Here’s a version similar to the current proposal but with these principles in mind:
News: Survey in Italy: OpenOffice.org Usage in 50% of Companies, GNU/Linux at 63%
Autumnal Tidings
Many things have happened during these two months but the most important one was arguably the official 2.9.0 release. It's just the first release in 2.9 series and so many things will change (and already have changed since then) but it's still significant as it's our first non bug-fix release since 2.8.0 almost 3 years ago and the first one containing Unicode-related changes as described here, and, in much more details, in the updated Unicode overview in the manual (make sure to read about the changes since 2.8 if you're upgrading). Now you can easily download it and try it out if the idea of using an svn snapshot makes you nervous. Please do let us know about any problems you encounter when porting the existing code working -- it's not too late to do something to make it easier to upgrade to 3.0 but we need to know about the problems in order to fix them!
The rest of the changes were the usual mix of bug fixes (many) and feature improvements (a few). One of them stands out though: the long spoken, discussed, argued and even blogged about unification of the debug and release builds was implemented soon after 2.9.0 release. As with the Unicode changes, we're confident that it's for the better but it is also quite possible that these changes have introduced some problems in the existing projects/makefiles. And again, if you let us know about them, we'd do our best to fix them before the final 3.0 release.
As for the new features:
- 2 of the 3 GSoC branches have been merged into the trunk so now wxRibbonBar and related classes as well as wxFileSystemWatcher are available in it.
- New wxAny class by Jaakko Salli was added. This is a modern, more efficient and safer replacement for wxVariant and the name was chosen because of the similarity to boost::any. It is not used by wxWidgets itself yet but we hope to provide a bridge between it and wxVariant in the future and start using the new class in the API once all the problems with it are ironed out.
- wxInfoBar GUI control was added. Instead of describing it, it is probably enough to show how it looks: there are two test bars in the dialogs sample now which can be shown or hidden using the menu commands but I'll spare you YouTube videos showing the effect and will just paste in three screenshots:
,
(this is the native GTK+ version available with GTK+ 2.18 and later only, with earlier GTK+ it would looks similarly to the other platforms, notably it would show icons and position the buttons horizontally -- I have no idea why does the native implementation stack them vertically which looks rather ugly IMO) and
- Many improvements in wxOSX/Cocoa port. Among cosmetic (but nice) things was the addition of ShowWithEffect() implementation, among less visible ones the addition of more conversions from various NSTypes to wx equivalents which makes developing wxOSX itself simpler. There were also improvements for iPhone (notably OpenGL-related ones) and fixes for 10.6. On a personal note, I started using Cocoa port instead of the Carbon for all new Mac development as I believe that it's in a good enough shape to be used now and prefer to fix any bugs in Cocoa code which will be used in the future and not in Carbon port which won't.
- As usual, wxDataViewCtrl and related classes also received several bug fixed and improvements.
As usual, I won't describe the bug fixes in details but will just say that many of them were fixed both in the trunk and 2.8 branch so we'd really appreciate more testing of the current 2.8 branch in svn as the problem with fixing so many bugs in the stable branch is that this might inadvertently break something else and it would be great to find and fix it before 2.8.11 release rather than after it.
I will omit the statistics section this time as there doesn't seem to be much point, it doesn't change much from month to month, let me know if anybody was interested in it.
Well, that's all for now -- better brief than late.
The Most Influential People In Open Source
Read more of this story at Slashdot.
6 of the Best Free Linux Music Servers
AirFM – Desktop Internet Radio Stations Player
AirFM is a beautiful Adobe Air app that contains around 200 radio stations from all around the world. It has a simple yet eye-candy interface with three main tabs on top, Radio Stations, Radio Player, and Favorites.
Once you start, click Radio stations tab, select any one of the neatly listed categories, and then play the desired radio station. You can also favorite any radio station and they will be added under Favorites tab.
The Radio Player allows you to increase/decrease volume and switch between next and previous radio stations.
At the moment it is in beta and the developer is adding one more feature before releasing the first version to the public. The new feature will be able to tell the total time spend on each radio station. If you want any additional features, don’t hesitate to contact the developer.
Since it is build on Adobe Air it is a cross-platform tool, i.e, it works on Windows, Linux, and Mac. Enjoy!
"Wait For Windows 7 SP1, Support Firm Warns Users
Read more of this story at Slashdot.
Compleat: Programmable bash completion for human beings
Compleat is an easy, declarative way to add smart tab completion for
any command. It's written in Haskell (but requires no programming knowledge).
See the GitHub repository for a quick description, or read on for a
complete explanation.
Background
I'm one of those programmers who loves to carefully tailor my development
environment. I do nearly all of my work at the shell or in a text editor,
and I've spent a dozen years learning and customizing them to work more
quickly and easily.
Most experienced shell users know about programmable completion, which provides
smart tab-completion for for supported programs like ssh and git. You can
also add your own completions for programs that aren't supported—but in
my experience, most users never bother.
At Amazon, everyone used Zsh (which has a very powerful but especially baroque
completion system) and shared the completion scripts they wrote for our myriad
internal tools. Now that I'm in a startup with few other command line
die-hards, I'm on my own when it comes to extending my shell.
So I read the fine manual and started writing completions. You can see the
script I made for three commands from the Google Android SDK. It's 200
lines of shell code, and fairly straightforward if you happen to be familiar
with the Bash completion API. But as I cranked out more and more case
statements, I felt there must be a better way...
The Idea
It's not hard to describe the usage of a typical command-line program.
There's even a semi-standard format for it, used in man pages and generated by
libraries like AutoOpt. For example, here's the usage for android, one
of the SDK commands supported by my script:
android [--silent | --verbose]
( list [avd|target]
| create avd ( --target <target> | --name <name> | --skin <name>
| --path <file> | --sdcard <file> | --force ) ...
| move avd (--name <avd> | --rename <new> | --path <file>) ...
| (delete|update) avd --name <avd>
| create project ( (--package|--name|--activity|--path) <val>
| --target <target> ) ...
| update project ((--name|--path) <val> | --target <target>) ...
| update adb )
My idea: What if you could teach the shell to complete a program's arguments
just by writing a usage description like this one?
The Solution
With Compleat, you can add completion for any command just by writing a
usage description and saving it in a configuration folder. The ten-line
description of the android command above generates the same results as my
76-line bash function, and it's so much easier to write and understand!
The syntax should be familiar to long-time Unix users. Optional arguments are
enclosed in square brackets; alternate choices are separated by vertical
pipes. An ellipsis following an item means it may be repeated, and
parentheses group several items into one. Words in angle brackets are
parameters for the user to fill in.
Let's look at some more features of the usage format. For programs with
complicated arguments, it can be useful to break them down further. You can
place alternate usages on their own lines separated by semicolons, like this:
android <opts> list [avd|target];
android <opts> move avd (--name <avd>|--rename <new>|--path <file>)...;
android <opts> (delete|update) avd --name <avd>;
...and so on. Rather than repeat the common options on every line, I used a
parameter named 'opts'. I can define that parameter to be a sub-pattern,
which will be used wherever <opts> appears:
opts = [ --silent | --verbose ];
For parameters whose values are not fixed but can be computed by another
program, we use a ! symbol followed by a shell command to generate
completions, like this:
avd = ! android list avd | grep 'Name:' | cut -f2 -d: ;
target = ! android list target | grep '^id:'| cut -f2 -d' ' ;
Any parameter without a definition will use the shell's built-in completion
rules, which suggest matching filenames by default.
The source code is on GitHub. I've been using it for just a week and
I'm now writing new usage files for myself almost every day. The README file
has more details about the usage syntax, and instructions for installing the
software. Give it a try, and please send in any usage files that you want to
share! (Questions, bug reports, or patches are also welcome.)
Future Work
For the next release of Compleat, I would like to make installation easier by
providing better packaging and pre-compiled binaries; support zsh and other
non-bash shells; and write better documentation.
In the long term, I'm thinking about replacing the usage file interpreter with
a compiler. The compiler would translate the usage file into shell code, or
perhaps another language like C or Haskell. This would potentially improve
performance (although speed isn't an issue right now on my development box),
and make it easy for usage files to include logic written in the target
language. Another idea for the future: What if option-parsing libraries like
AutoOpt or the Ruby/Perl/Python equivalents generated completion scripts for
every program you wrote?
Final Thoughts
I realized recently that some things I do are so specialized that my parents
and non-programmer friends will probably never get them. For example,
Compleat is a program to generate programs to help you… run programs?
Sigh. Well, maybe someone out there will appreciate it.
Compleat was my weekends/evenings/bus-rides project for the last few weeks (as
you can see in the GitHub punch card), and my most fun side project in
quite a while. It's the first 'real' program I've written in Haskell, though
I've been experimenting with the language for a while. Now that I'm
comfortable with it, I find that Haskell's particular combination of features
works just right to enable quick exploratory programming, while giving a high
level of confidence in the behavior of the resulting program. Compleat 1.0 is
just 160 lines of Haskell (excluding comments and imports). Every module was
completely rewritten at least once as I compared different approaches. (This
is much less daunting when the code in question is only a couple dozen lines.)
I don't think this particular program would have been quite as easy to
write—at least for me—in any of the other platforms I know
(including Ruby, Python, Scheme, and C).
I had the idea for Compleat more than a year ago, but at the time I did not
know how to implement it easily. I quickly realized that what I wanted to
write was a specialized parser generator, and a domain-specific language to go
with it. Unfortunately I never took a compiler-design class in school, and
had forgotten most of what I learned in my programming languages course. So I
began studying parsing algorithms and language implementation, with Compleat
as my ultimate goal.
My good friend Josh and his Gazelle parser generator helped inspire me
and point me toward other existing work. Compleat actually contains three
parsers. The usage file parser and the input line tokenizer are built on the
excellent Parsec library. The usage file is then translated into a
parser that's built with my own simple set of parser combinators, which were
inspired both by Parsec and by the original Monadic Parser Combinators
paper by Graham Hutton and Erik Meijer. The simple evaluator for the usage
DSL applies what I learned from Jonathan Tang's Write Yourself a Scheme in
48 Hours. And of course Real World Haskell was an essential
resource for both the nuts and bolts and the design philosophy of Haskell.
So besides producing a tool that will be useful to me and hopefully others, I
also filled in a gap in my CS education, learned some great new languages and
tools, and kindled an interest in several new (to me) research areas. It has
also renewed my belief in the importance of 'academic' knowledge to real
engineering problems. (I've already come across at least one problem in my
day job that I was able to solve faster by implementing a simple parser than I
would have a year ago by fumbling with regexes.) And I'll be even happier if
this inspires some friends or strangers to take a closer look at Haskell,
Parsec, or any problem they've thought about and didn't know enough to solve.
Yet.
Things To Fix / Tweak After Installing Ubuntu 9.10 Karmic Koala
Everybody posts about applications to install after upgrading to Ubuntu 9.10 Karmic Koala. That's interesting, and some applications in those posts are quite useful. But those are just lists of applications like any other 'Top 10 Ubuntu applications' list.
I'm not saying they are not interesting, I'll even post some links to such posts from other blogs (look at the bottom of the post) I really liked, but to get there, you must firstly fix everything that's not working for you, tweak some things and so on.
Full Story
100 Open Technology Courses That Would Have Saved You a Lot of Money On Tuition [Education]
When I think about all of the money I spent on college tuition only to find that the internet is riddled with free technology courses from prestigious schools like MIT.
To make things easier, OnlineCourses has put together a list of 100 open tech courses and broken them down into 10 categories: Computer Science and Engineering, Computer Security, Programming, The Web, Software, Information Technology, Communication Technology, Technology in Education, Tech Math and Technology and Society.
Looking over the list, about 98% of the courses come from MIT, so you know you are going to learn something valuable. Admittedly, some of the courses are a bit out of date, but they should provide you with a foundation on usefull topics like computer systems engineering, C++, Computer graphics, Flash and Database systems to help you decide whether or not to pursue your education further. Hit the link for the full course list. [OnlineCourses]