Ideas: Packages, Locales

This year I’m going to try to get back to writing a bit more.  One of my ideas of how to do that is to dump random ideas I have from time to time.

Today here are two ideas that seem good in theory, but will probably require a bit of work to make real, and both can use a bit more design and polish before I’d consider moving forward with them.

Package System Hooks

This idea comes from my experience with both Ruby and Python on Debian systems, but could certainly apply to other languages as well (Perl comes to mind as an obvious one, but there are likely others).


Debian (and most GNU/Linux and other free operating systems) has a package manager (apt in the case of Debian), and it works great.  Most users can and should use their package manager as the gatekeeper to their system.  Even servers get a lot of benefit here, and most system administrators should be rolling their own packages for the meat of their servers just to make their lives easier.

The disconnect comes when you use HLLs like Ruby and Python, which have their own repository/package systems (eg, gems in the case of Ruby). Some of the libraries available via the languages’ systems are also available as packages, but many are not.

The Idea

The idea is that the operating system’s package system can provide a way to include the information from the other package systems.  This would make it much easier to manage all the packages from one source, and it would ease the pain when there’s a system package for a language’s library.

Further, this could even be leveraged for web browser extensions, locales for specific applications, etc.

Ideally, in the case of the browser, the OS package system would need additional functionality for managing per-user packages (so that extensions could still be registered even if they only belong to the current user).

Having this additional functionality available would probably lead to even better interoperability.  For example, a Chromium extension could be registered, and if the user opened Firefox, Firefox could talk to the package manager and then prompt the user to install the same extension for Firefox.

Additionally, data could eventually see the same sort of management available.  Bookmarks could be considered a “data package” that could be decoupled from the browser.

Locales like Google Does Translation

This idea comes from my experience with reading websites with translation tools and localization with my Firefox extension.


One of the triumphs of free software is the ubiquity of localization.  Community-driven software means that users can readily assist in getting high quality translations to their own language out to the rest of the world.

The web itself follows a different model, where third parties like Google offer translation tools.  One of the benefits of the web’s approach is that translation services can provide JavaScript that lets users give translation feedback.  If you visit a page translated by Google, you can click on a translated sentence and offer an improved translation.

The software model pulls the strings out from the code, and these are translated into other languages.  This approach is usually higher quality than the web translations, but it requires volunteers, and it can be cumbersome for people that don’t want to spend too much time.  (My assumption is that the easier you make it for others to help you, the more likely they will do so).

The Idea

The idea is to let the applications themselves have the same kind of “click and write” translation facilities that Google and other translation services inject into the web.  It’s a bit trickier in applications, as the user would have to more explicitly select and translate, but I believe it is technically feasible.  It’s most definitely feasible for Gecko-based applications, and GTK+ applications can probably handle it as well.

The process would be in two parts: suggesting translations, which get spooled by a server, and validation by trusted reviewers.  The fact that validation would only require reading two strings and affirming means that it should be easier to enlist helpers there, and the fact that translators would be drawn from the users without the need for volunteering or signing up means that they would be more likely to send word.

I really like this idea, because it seems (to my mind anyway) to be based on a strong separation of duties that will elegantly allow a solution to a problem.

Bonus Idea

This is an offshoot of the same idea, though it actually occurred to me before this idea.  Transcripts for videos, based on the same sort of behavior.  A user is given a short clip of video and types what they hear, and then later other users are given the same to review.

Prior Art

Obviously these ideas have some precedents in the real world.  I pointed to the Google translation services, but ReCAPTCHA is another example, as is Wikipedia.  Over time I expect to see more examples emerge that use this same pattern, and it will eventually penetrate the governmental models, with better separation of powers and improved checks and balances.

Thanks for taking time to look at these ideas, and I’ll be happy to hear any criticisms you may have.

hyperweb linux

The End of Iceweasel?

Not sure how I missed this, but better late than never.

Some years ago Debian forked the Firefox web browser because of copyright issues regarding the Firefox logo.  There were a few other reasons, but that was the main one.  That’s changed, officially as of March of 2010 (mozilla-central – changeset – 39109:99d80bc3f18b), but apparently the actual license changed prior to that.  The logo is still under trademark, but it is free speech now.

A few scenarios exist:

  1. Iceweasel goes away.  In this scenario an agreement on Debian modifying Firefox is made, and Firefox replaces Iceweasel.
  2. Iceweasel continues as is.  In this scenario the other issues don’t budge, and the status quo is maintained.
  3. Iceweasel and Firefox coexist.  In this scenario there isn’t agreement on the issues, but Debian decides to maintain an official Firefox package without changes anyway.

It’s more likely that either of the first two happen than the third, as it would still require extra work in packaging and bug management for the third to occur, and it wouldn’t have that much benefit.  One of the maintainers of Iceweasel ( Mind Blowing News) seems pretty sure that Firefox will return, but time will tell.

While they’re at it, I wish that they would find a solution to the libPNG mess.


Valve’s Left4Dead: DirectX Curse

Valve Software has released their latest game, Left4Dead.  This is a zombie thriller game and I’d like to give it a try.  I love Valve games and I love zombies, so this should be my favorite game of the year, right?

Well I won’t find out, possibly for years to come.  I play Valve’s games under  Linux (unsupported) via WINE.  WINE’s DirectX support is pretty solid through DirectX 8 and I can play Team Fortress 2, Portal, Counter-Strike: Source, HL2 + Episodes, etc.  They run just fine on my system and I have fun.

As of Left4Dead, Valve has dropped DirectX 8 support.  I look at the game on the WINE AppDB and the word is it runs fine, but slow as a dog.  So I don’t buy it.

This is an example of sales prevention.  Valve already chooses not to support Linux as a gaming platform; their choice.  But now they are cutting off the ability to play their new games via WINE.  Also their choice, but a choice which means that I won’t be giving them my money until I read on the WINE AppDB that things have improved.

And for the record I’ve bought pretty much every Valve game since Half-Life.  I would love to continue to do so.


Viva la Revolucion!

I’m building a new computer, but it won’t have a graphics card. It’s going to have integrated Intel graphics. Therefore it’s going to have an Intel processor. AMD is losing my business because they didn’t perform up to what I consider to be reasonable expectations. I don’t think nVidia performs all that admirably either.

It’s not merely the spirit of linux, but the development model as well, that requires openness. It makes no damn sense to be throttled by a piece of hardware that is essential to the system because its manufacturer refuses to work with the community.

Furnishing documentation is great, but that’s something that should have been done all along. The pace and scope with which many of the internals of a healthy, modern linux system changes demands flexibility that the two major graphics processor manufacturers are apparently unwilling to provide.

Off with their heads. I’ll be posting soon about how the intel integrated graphics perform, and I’m planning to have a rolling three month deadline for evaluating my discrete graphics card options. If at the end of March, June, etc. there is a victor amongst AMD/ATI and nVidia I’ll actually buy a card for the system. Otherwise I’ll continue to use the integrated graphics. So be it.



Just a quick note about the package nullidentd. This is an Ident Daemon that purports to be as light as possible. In the man page you see mention that (and I quote — under OPTIONS):

nullidentd takes only one optional argument, the username to answer with. If this is omitted, nullidentd will reply with the username "foobar". If the username is RANDOM, a random string is generated.

And under USAGE:

nullidentd is typically invoked from inetd. The following is a typical inetd.conf example:
auth stream tcp nowait nobody /usr/sbin/nullidentd nullidentd

What you don’t see is the actual, proper use of adding a specified string or the magic RANDOM string.

The way? Add -u. Fairly straightforward, but undocumented. Even running nullidentd --help lists the usage as “nullidentd [uid].”

auth stream tcp nowait nobody /usr/sbin/nullidentd -u RANDOM

But once you figure it out it runs quite fine, no harm no foul. Still, it ought to announce proper syntax.

(For a quick and easy test, this works like a charm.)