Aigarius Blog

According to the Slashdot article and the StopSoftwarePatents.org website itself and on Digg, the anti-software-patent activists are attempting a world-wide event on the 24th of September as a world-wide day against software patents. USA has them via a weird court ruling, Japan has them as well (not sure why), there have been efforts to force software patents on EU, India, Australia and many other countries either by Microsoft lobbies or even via US trade treaty pressure.

While lobbying by local Microsoft branches and their pet companies can be countered locally, like I and many others did in EU a couple years ago (mostly thanks to FFII), trade negotiations are very secretive affairs and it is very hard to lobby there directly. The public needs to be aware of the issue, otherwise the politicians will not be aware of its importance to their voters.

Software patents are a threat to free software as it circumvents the power of GPL and other copyright licenses if enough money is thrown at the lawyers. If a software patent is generic enough, it can easily stop development of a whole class of free software applications on a whim of the patent holder. And there are plenty of granted software patents with a very broad scope (progress bar, anyone?).

I am aware that to get Debian support for such an initiative, a GR is needed, but how about a personal word of support from the DPL or support from the SPI? It is in direct area of interest for SPI - software patents create an ever present threat of legal action against any and all software in Debian (in USA and Japan, at least) and, as the legal umbrella of Debian in the USA, SPI would be a prime target.

What do others think about this?

Popularity: 10% [?]

Smash Lab is a new Discovery Channel series where a team of inventors try to solve an engineering challenge. The premise is quite nice, unfortunately I don’t find the inventors in question to be particularly bright.

In the first episode they try to bomb-proof an existing building using spray-on Rhino Lining and some weird flaps for windows. The result were blown out windows and doors and a semi-stable wall that was crumbled inside. You can’t really stop walls crumbling down after a car bomb right outside. But, the windows could easily be protected with the same type of stretchy plastic covering the glass from both sides in a way similar to Triplex car windshields. That would be much better looking than the window flaps they used. Also, if you’re simulating a car bomb, don’t forget to add nails, screws and/or ball bearing to create shrapnel. Overall: 5/10, can be improved a lot.

In the second episode they tried to use aerated concrete to improve the dividing barriers on highways. Both their designs failed miserably in a multitude of ways - they were hard to produce and failed to stop cars. The best they got was to slow down a heavy bus, but even that did not stop. I would propose a completely different design - an arrestor bed created from easy to manufacture blocks of solid concrete with a rectangular hole inside and a thin slab of aerated concrete on top of that hole. The blocks would be rectangular with a length that is good for transport and deployment. The crucial details are the width, height and internal structure. The height of the block must be surely higher than half the wheel diameter of a largest typical car. The width of the internal hole must such that a typical wheel would fit inside the rectangular central hole of the block after the top of the block breaks in. The wheel must fit both in a parallel and perpendicular fashion thus the width of the block must come to the typical wheel diameter. The blocks would be layed parallel to the road with around 10 blocks separating the traffic lines. If a car would weer onto such lane, the tops of the bricks will break very easily getting the wheels to fall into the hole in the block. The block walls will be much harder and will impact the wheelbase both slowing the car down and steering it so that it would be forced to move in the direction parallel to the traffic flow. In such direction of travel the car will continue to break off tops off the blocks until it slows down enough to fall beneath axle height at which point the concrete will crumble upwards bringing the car to a much faster stop. The car will be unlikely to cross to the opposite traffic because of the diversion effect from the block walls. Overall: 3/10, the inventors failed to achieve anything.

Crosscut of one block

#---------#
#         #
#         #
#         #
#         #
###########

- is aerated concrete
# is solid concrete

Popularity: 10% [?]

In the Latvian l10n community we often deal with the problem of mistranslation of common words such as “file”, “preferences” and “advanced”. There are several words that fit each of those and over the years preferences in the community have shifted back and forth.

I just came up with an idea of making a script that would download all the translations, search for these common words in the source strings and see if any of the common translations and mistranslations are in the translation for that string. Then it could form up a web page with statistics of the mistranslations and possibly even links to specific instances to allow for corrections. It would also find new mistranslations

How other translation teams handle this problem?

Popularity: 19% [?]

A person that I deeply respect and who is very know in Latvian IT society recently said that he often uses a quote of mine in his presentations. I completely forgot that I ever said that, but it sounds very much like what I would say, so I wanted to write it down so that I do not forget about it again:

90% of the people do not understand copyright, the other 10% simply ignore it.

Heh, I must have been optimistic. There is no way that so many people actually understand copyright.

Note: most Debian Developers and FLOSS developers in general are an exception to this rule, but sadly comprise such a small percentage of the population that it means very little from a public policy perspective.

Popularity: 20% [?]

I can’t believe I have not bogged about this before. With all that terrorism threat bullshit, wouldn’t it be nice if there was an airline that would declare itself to be ‘terrorist friendly’ - i.e. all passangers are welcome to come on board with just a simple identity check, no security check, no baggage security check, no delays. You can arrive 10 minutes before departure and just fly away. Wouldn’t that be nice?

A budget company could do that to spare on airport security fees and high-end airline could do it just to spare your time. All flights could be marked private charter for legal reasons.

Can we please return to a world when I can take a bottle of mineral water and a nail clipper on board with me?

Popularity: 20% [?]

After last post about a FHS amendment to address the structure of user’s home folders, I received a lot of comments and there is one very significant thing that can be changed in the proposal - instead of having $HOME/{.data|.cache|.config}/appname structure, to change that to a mandatory $HOME/.library/appname/{cache|config|…} . This version still has all the benefits of the first solution (configuration for an application can be easily identified and erase, and all cache can easily be excluded from backups using “$HOME/.library/*/cache” regexp) and also has additional benefits, main of which is the ability to later introduce the concept of user installed packages. The idea is that it would be possible to support having /bin, /lib and /share subdirectories in these application directories thus making an ability for the whole application to e packed in a single directory and allowing the application to be installed simply by unpacking this directory. I admit that much of this is glanced over from MacOS X world, but I do not think that it diminishes the idea itself.
Some problems appear there - support of these distributed bin folders, support of separate lib folders, handling of application plugins, handling of dependencies, handling of the application menu, upgrading notifications for the user software vs. system software. But nothing there that can not be solved. I feel that this can bring together FHS and LSB by providing something of an API for software being installed by users. Having no registry of the software in this solution allows for some interesting things, for example having multiple versions of one program just by renaming the application folder.
A lot of specification work is required here, therefore I proposed a workshop on this topic in Debconf7. I hope to have something that everyone can agree on and maybe even some code by then, so that after Debconf7 there can be a formal policy amendment proposal.

So there are two questions:

1. Is there something better in $HOME/.cache/appname vs. $HOME/.library/appname/cache ? Any other trade-offs that I have forgot?
2. What do you think about the further idea of users having the ability to install software in their home folders or remove such software in a very simple fashion?

Popularity: 50% [?]

Justification.

Currently there is a huge mess of files and folders that start with a “.” in any users home folder. There is no structure or policy on how applications should choose file and folder names for data that needs to be stored in users home directory. Additionally there is no established consistency between Gnome, KDE and most other applications. Gnome application have part of their configuration information in gconf folder and other part in a gnome subfolder. KDE applications have a complex structure under .kde/. And most other applications either have one file directly in users home folder or have their own dot-folder there.

Problems.

There are two major problems with current ad-hoc approach:

1. Namespace pollution of users home space. In any desktop system “ls -al” in the home folder would be a very lengthy affair. Moreeven this namespace is folded - KDE and Gnome apps live in their own subfolders.
2. Lack of structure in folders makes it much harder to properly understand their purpose. For example, if a user has misconfigured an application and would like to reset it to default settings, it currently could be hard to figure out how to do that. Especially without losing his data in that application.

Proposal.

I propose to implement a policy on where an application can store data and configuration information in users home folder. Such specification would be proposed as an extension for FHS, first implemented in Debian and then promoted for inclusion upstream and in other distributions.

Structure.

I propose a following structure for a users home folder:

• data/appname/ - each application, that stores user data in application-specific format, will have to store this data into this folder. Only configuration information that is essential to load this data would be permitted into this folder (in hidden dot files). For example, Evolution could store emails and email access information here.
• .conf/appname/ - each application that stores any configuration information whould have to store all of it in this folder. GConf will have to also store applications configuration info here. If this folder would be deleted, application must revert to default configuration, but still be able to fully access user data in data/appname/ or other, generic folders (below). For example, if .conf/evolution/ is erased, then on next start-up Evoution should still be able to access all email that is stored in data/evolution/ without any configuration wizards.
• .tmp/appname/ - each application that would need to create temporary files that survive reboot, would put them here. These folders can be safely deleted at any time with no data or configuration loss. For example, Firefox cache information and Nautilus thumbnail cache would have to be here.
• Desktop/ - the desktop folder, just like it is now
• Media folders - (Documents/, Photos/, Videos/, Music/, …) a suggestion of basic document structure for user to use or ignore. Applications dealing with particular media types would default to use files from such folders, but should also cope with working with any other folders on users choice. For example, a screensaver with slideshow function would by default use photos from Photos/, but will have to have a configuration option for user to change that setting.
• Additionally I would propose having a .mounts/ folder where applications could mount user specific media and other mounts, such as FUSE. For example, FUSE could be used for automatic archive introspection.

Benefits

The main benefit for such system for me is twofold:

• SBackup can be configured to exclude .tmp/ and .mounts/ by default thus saving significant space in backups.
• A tool can be made to restore settings and/or data for specific applications in an uniform fashion.

So, any suggestions on the idea and on where this should be best discussed?

Popularity: 100% [?]

Catching up on blogs, emails and Debian mailing lists I see that nothing really important has happened while I was off-line: the dunc-tank caboodle escalated and died down when the majority voted that it was not worth the commotion, some people got upset at some other people and decided stop working on Debian because of that, Mozilla went even more bonkers about its trademarks.

The dunk-tank scandal ended just like I thought it would. As one could imply from my eternal unstable concept, I do not see making releases as a the main thing that Debian contributes to the society - it is more about the integration and cross-empowerment of all the packages that Debian has. In that context, making a release is a not the most important job in Debian, but it need to be done from time to time. Release management combines technical and social challenges - there is not much of novelty in it (I imagine). So, from this perspective, there is nothing bad in money being paid to do this mundane and hard work, if we really, really need to release in a specific time frame (IMHO the only reason to release Debian in 2006, as opposed to 2008, is the Lars tattoo bet). If we return to “release when its ready” paradigm and aim for about one release every 2-3 years (and I see nothing really wrong with that) then paying release manager will not be needed. Money is about getting things done on a schedule. It does not make things good (or bad). It does not make thing important (or not). It make things go by the schedule (unless you pay by the hour). It is the obvious solution to releasing Debian in December. Now two questions need to be answered - will it work? and do we really want to release in December?

The second thing - in any group of 1000 people anyone can easily find a lot of people that he would not love/not respect/disagree with/disregard/hate and be unable to work with. It is no reason to stop working on Debian, unless one does it only to be universally loved. It is inevitable that we will need to learn to do what we like to do without paying attention to the irritations.

And about the trademarks - in Debconf 5 in Helsinki I was giving a talk at the Debian Day, just after I helped to win the first big fight against software patents in EU, and Branden (who was GPL at the time) asked me what do I think Debian should do about its trademarks. Both then and now I strongly think that trademarks and any other litigation inducing concepts (except enforcement of GPL) have no place whatsoever in free software. I think Debian should lead the way and give up the “Debian” trademark. And Mozilla should follow the lead. So what if there is a pron site “Debian chicks”? You will not solve that with litigation anyway (at least not in a year or two) and why should we really care? So what if some one make a distro and calls it SuperDebian? If someone will really think that it is related to Debian but better (especially despite warnings to the contrary), then that someone will really deserve to get the trojan planted in that distro. And again, against a well prepared criminal, litigation will not help much.

So, did I miss anything?

Popularity: 61% [?]

Hmm, I wonder if in the bug squashing parties one can eliminate bugs by hard random hugging?

Popularity: 43% [?]

It would be very good to have a bounty that would pay 100$ to anyone who would find and implement a way to reduce memory use of a fully running Debian Linux + Gnome system (optionally, with all Gnome apps loaded) by one megabyte (as indicated by RAM used in a swapless system - (cache+buffers)) in a way that does not reduce functionality or heavily compromise runtime speed and would be accepted into upstream Gnome.

We need sponsors! That would be one great long term investment in Desktop Linux.

Popularity: 32% [?]