Search Results: "cas"

1 December 2005

Matthew Palmer: A trace mixin for Python

Although I am by means an expert Python programmer, I do dabble -- at the moment, I'm dabbling fairly heavily in a project for work. I had need, as you do on occasion, for a call trace (I called this method, it returned X, I then called this other method, it returned Y, and so on). Astoundingly, I got no answer when I asked on #python, as I would have expected this sort of thing to be a gimme -- even possibly including it as a core language feature. But nary an answer was forthcoming. Searches for mixins or magic function calls which might solve my problem were similarly fruitless. I resigned myself to manually sticking print wrappers around the function calls of interest, but that got old real fast (especially after I spent about a half-hour chasing my tail because I'd forgotten to return the return value after I printed it). As usual, my subconscious saved the day. On the train home this afternoon, I suddenly had a brainwave, and the code which I've reproduced below appeared almost fully-formed at my fingertips. It's times like this that I really enjoy programming. Now, of course, someone will pop up and say "oh here it is over here", or "you just set the __trace_me_baby__ attribute on your object", but I can console myself with the fact that I know a lot more about grubby Python internals than I did before. The code: (a pre-saved version is also available).
# tracemixin.py
#
# A python mixin to trace the calling of methods.
#
# Copyright (C) 2005 Matthew Palmer 
#
#   This program is free software; you can redistribute it and/or modify
#   it under the terms of the GNU General Public License as published by
#   the Free Software Foundation; either version 2 of the License, or
#   (at your option) any later version.
#
#   This program is distributed in the hope that it will be useful,
#   but WITHOUT ANY WARRANTY; without even the implied warranty of
#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#   GNU General Public License for more details.
#
#   You should have received a copy of the GNU General Public License
#   along with this program; if not, write to the Free Software
#   Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
#   or see http://www.gnu.org/licenses/gpl.html
#   
"""
A mixin class to permit the tracing of method calls on an object.
This class, when mixed in, overrides the default operation of method calls
so that requests to call methods which have been listed in the
self._traced_methods list will be printed with their arguments and return
values.  Also included is a simple call depth indication, using indents.
Tracing of particular methods can be turned on and off on a per-object basis
by simply including or removing the method's name in the _traced_methods
list on the particular object.  Whole classes can be traced by setting
the list as a class attribute.
To include this class, simply make it the first class name in the list of
parent classes when defining a new class, like so:
class Something(TraceMixin, RealParentClass):
You could probably leave the TraceMixin in your production code, although
it'll slow execution down by a bit.
Complete usage example:
from tracemixin import TraceMixin
class RandomTask(TraceMixin):
	def x(self):
		print "X!"
	
	def y(self, arg):
		print "%s Y!" % arg
		self.x()
x = RandomTask()
x.x()
x._traced_methods = ['x', 'y']
x.y('why?')
Output:
X!
::y(why?)
why? Y!
  ::x()
X!
  =>None
=>None
"""
class TraceMixin(object):
	_traced_methods = []
	_depth = 0
	def __getattribute__(self, attr):
		if attr in object.__getattribute__(self, '_traced_methods'):
			self.method = attr
			attr = '_trace_proxy'
		return object.__getattribute__(self, attr)
	
	def _trace_proxy(self, *args):
		realmethod = object.__getattribute__(self, self.method)
		if realmethod and realmethod.__class__ == self._trace_proxy.__class__:
			print "%s::%s(%s)" % (self._depth*'  ', self.method, ', '.join(args))
			self._depth += 1
			rv = realmethod(*args)
			self._depth -= 1
			print "%s=>%s" % (self._depth*'  ', rv)
			return rv
		else:
			raise AttributeError

Steve McIntyre: Post a bug!

Filip complained that the unofficial sarge amd64 jigdo files didn't work for him. That's fine. But if you want other people to notice the bug and fix please report it properly! In this case, I spotted his blog post and investigated. I think I've fixed the problem now Filip...

Joey Hess: money

I've followed AJ's experiment in funding free software development with his AJ Market with interest and have thrown money in the pot once or twice for some of the projects I care about. It's an interesting approach. I'm too lazy to do anything like that, or rather, I'm already paid sufficiently to work on free software that doing a joeyh market would too much resemble work. However, I did decide to try something I've seen done occasionally, since I also wonder how that works out -- I added a paypal donations button to the website for one piece of free software. Just as a test, to see if it annoys anyone, and if anyone bothers clicking on it. I chose alien since it's well known, regularly used by a suprisingly large number of people and even appears on the first page of otherwise quite amusing results on a google search for "alien". (I suppose that adding google ads to the page would generate more money, but in a probably less interesting way.) Unlike AJ, I won't promise that clicking on the link will motivate me to work on anything. In fact, the most likely use of any money I get from this will be to pass the buck along to the AJ market or something similar.

Dirk Eddelbuettel: Mail broken

Comcast, in their infinite wisdom, decided to RBL block (at least one of) Debian's mailhost(s), master.debian.org. As essentially all my mail is forwarded from Debian to Comcast, mail traffic was affected. At first, I noticed dropped posts from mailing list subscriptions relative to the list web archives. I posted the suggested noticed to the Comcast RBL admins, so far to no avail other than a to yield a more complete stop. The mail forwarding has been disabled for now, and I am dealing with this more manually. If you tried to contact me in the last few days and have not gotten a response, please resend your mail. I should now be in a position to receive it. Sorry for any inconveniences. Offers of better mail hosting would be gladly accepted, of course.

29 November 2005

Clint Adams: Pink drinks

Remember, jwzfan, if no one quotes you, you probably haven't said a thing worth saying.
<jwzfan> Clint: someone seems to have missed the sarcasm in my internet expression. Perhaps I should have suffixed it with LOL

John Goerzen: NiMH Rechargable Batteries and Charger Review

I've been using NiMH batteries for quite a few years now. Ever since my first-ever digital camera came with a free AA charger and four free rechargable NiMH batteries. I'm still using that charger, and it's been almost 10 years. I have a few complaints about my existing charger. It won't charge AAA batteries, and it doesn't have a discharge feature. Without that, it can be difficult to avoid shortening battery life due to the memory effect which even NiMH batteries are susceptible to. Also, it charges batteries in pairs, which can result in various charging problems when dealing with batteries of uneven charge or uneven storage characteristics. Also, many of my batteries were old. So, I set out to find a better charger, and to find the best current NiMH batteries. The Charger A little Googling revealed a very useful page at Steve's Digicams. They suggested the Lacrosse BC-900 Advanced Charger. I ordered this unit from Thomas Distributing and must say it is a very slick unit. It has four main modes: charge, which does a simple charge-until-full; discharge, which will discharge then charge a battery; refresh, which discharges then charges the battery repeatedly until no increase in capacity is measured; and test, which checks the condition of the battery. The charging and discharging current is fully configurable. I opt for a gentle, slow 200 mA charging current. But others can increase it to many times that. The BC-900 has a built-in temperature cutoff circuit, so it will pause charging if your batteries are about to overheat. The BC-900 can charge up to 4 AA or AAA batteries simultaneously. Each battery is charged individually, and each battery can have its own mode and charging/discharging current set. The unit comes with some starter NiMH AA and AAA batteries, plus a carrying case for batteries and the charger. Thomas Distributing also added four more free AA NiMH batteries (nice). Batteries I found the Great Battery Shootout site to help with choosing batteries. I eventually chose Maha Powerex batteries and have been happy with them as well. They come in various different capacities (including some larger than are listed on the shootout page) and Thomas Distributing had good prices. Hope this helps if you're planning on using rechargable batteries.

28 November 2005

NOKUBI Takatsugu: RssCast

I maed some debian packages for Galatea/GalaTalk. The apt line is the following:
deb http://www.daionet.gr.jp/~knok/debian ./
deb-src http://www.daionet.gr.jp/~knok/debian/source ./
Then I made a Ruby script named "RssCast", to convert RSS feed into mp3 files with text-to-speech engine. The code is in http://www.daionet.gr.jp/~knok/trac/trac.cgi/file/trunk/rsscast/rsscast.rb. It requires festival and lame (ah, it's painful...). And if you want to convert Japanese text, also needs sox, jtext2wav.rb script and galatalk from the arove apt line. Unfortunately, I couldn't make Podcasting feed yet.

David Welton: Open source economics - the conundrum

I think I agree with Ian Holsman's analysis of this article on "How to make money from open source" - actually I would go a bit further. Ian says that you don't need to be a committer to make money from open source. Indeed, in some ways the big question in terms of "open source economics" has been how to more tightly couple the people doing the valuable work with some percentage of the rewards - at least enough to let them keep hacking. While it's evident that open source works, and that there are big economic benefits involved, it's a tough nut to crack in terms of renumeration for people working on stuff. Selling software is, if nothing else, a really simple mental model that is very easy to grasp - you write software, you sell it. If it's good, people buy it and you can either reinvest that money, or take it as profit. Open source software that scratches an itch has immediate benefits to the author, especially if the author manages to get other people on board to help out. But the category that's not really covered is the group of people writing something "out of the blue" because they think it's a cool idea. If it is, and it takes off, they really aren't guaranteed anything at all for their troubles. I don't see too many ways around this while still playing by the rules of the game. There are some clever ideas like dual licensing, but they aren't applicable everywhere. I suppose you could declare software a public good and get the government involved in its production, but I'm not very enthusiastic about that... In any case, it's an interesting topic, and perhaps some day clever entrepreneurs will find better ways of financing the production of open source software.

Tollef Fog Heen: Fakecat (re)licencing

Jose Carlos Garcia Sogo writes that I've not put a licence on my fakecat plugin for pyblosxom. This has now been fixed. Also, please do send me patches even in the cases where I have forgotten to licence it appropriately.

David Moreno Garza: Venezuela

I was in Venezuela last week.
 
Something special happened. No, it is not only that I was able to see my beloved girl; it is not that the free software community and free software efforts and project rock. No, something very personal and special.
 
I arrived at Maiquetía (roughly, international airport of Caracas) from Maracaibo around 9 pm. At around 10 or 10:30 I was on my way to the hotel on a van where they pick up and down people on the airport-hotel-airport basis. I was waiting for my early flight to Mexico City the next day (on Sunday, at 8 am).
 
On our way to the hotel, I asked a lady sitting next to me: "So, how far away from Maiquetía is Caracas?". "Around 40 or 45 minutes", she said. Ah, nice, next time I come to Venezuela I definitively should go to Caracas, I thought.
 
"You're Mexican, aren't you?". "Yes", smiling. "I'm going to Mexico tomorrow", she said, also smiling. "Are you in the Mexicana 8 am flight?", I asked, being curious. And she was. We talked a bit more and apparently she was coming also from Maracaibo on my same flight, now that's a coincidence. "It is my first time in Mexico tomorrow", so it was mine in Venezuela.
 
Arriving to the hotel, we checked in and went to rooms. On the morning, at the next day, I found her on the hotel-airport van again. I thougth she was going to be already on the hotel, specially since I was late for almost an hour, but no, she was there. "So we are late, eh?", she asked me. "I think so".
 
After exhausting militar revision (four times, with four different soldiers:  Political relationship between Mexico and Venezuela is not healthy nowadays), I documented my baggage. The lady was in the executive line and I was with mortals. She was pregnat, also. The lady on the desk gave the boarding pass (at that point we were supposed to be already on the gate, one hour before time) and pointed me another desk where I was supposed to pay airport taxes. Now, that is scary, since I was not carrying too much on bills or coins. I arrived to the desk: "how much is it?". "105'000 bolívares", around 50 USD. God dammit, I was only carrying 45'000 and my credit cards are broken. At that sudden time, I was already thinking I should be spending a couple more days to get that fucking cash and pay for the change of flight, etc. Or... I could ask for help to the lady. What do I lose if she says no?
 
- Mrs, I have a real problem, and I need help. Anyway, I will truly understand if you are not able to do it, but I'd much appreciated it.
- What happen? 
- I need to borrow 60'000 Bs from you, please, please. I don't have enough to pay for the taxes and my credit cards are completely broken, I didn't think on taxes when spending money on anything else before.
- Don't worry, let's go to the ATM.
 
There. There I go. That completely unknown nice lady helping me to not lose my flight.
 
- But I have to go first to a Internet center to make a transaction online to be able to get cash from the ATM.
- Yeah, of course, I'll go with you- What else could I do?
 
She took the cash off and went together again to the taxes desk. She gave me the money and we both paid. Only 15 or 20 minutes were left for the flight to departure and we were trying to do things fast. Fortunately, we both did it since more cops and soldiers were making inspections just on the airplane's door.
 
When she was on the line I went to the phone booths to make a call home.
 
- Mom, I need you to bring 300 pesos when you go pick me up to the airport. Long story.
- No problem.
 
And the lady was not there anymore, I was unable to see her again (probably because she was on executive or because she was an angel :-). When we landed, I didn't see her again on the plane, in the lines, in the police line, etc. I have no idea how that happened, but it happened.
 
She will be awarded with twins :)
 
She was wearing a David's shield on her neckless, by the way.
 
 

Kai Hendry: Mail musings

I use Gmail to filter my mail. This has been the case since June 2005. I usually have about 1000 SPAMs in the SPAM mailbox. Recently I’m up to almost 1500. Sigh. I noticed alioth was spammed pretty bad. That’s one reason. I get quite a quite a few SPAM in my inbox which I need to manually send to the SPAM folder. That’s getting worse. Thankfully no HAM is found (knock wood) nowadays in Gmail’s SPAM folder. There was a monster thread over at Linux Users Victoria about Microsoft Exchange. For some odd reason the LUG doesn’t want the mailing list archived. Anyway I made a bit a of a tangent on the thread when I recommended people and companies outsource their mail to external hosts. The savings can be incredible. Though if employees send a lot of attachments, it can be quite painful.
Especially as Australia is using “Pay as you Go” style Internet. Setting up mail servers nowadays is too hard. In my (contracting) experience most offices are incapable of running their own mailservers. Currently I have a painful problem with my Debian (unstable) T30 laptop with Debian’s default exim4. Mail seems to get frozen if I don’t find a net connection within a couple of days when writing email offline. Finally here is a cheerful link of computing pictures to ease the pain.

27 November 2005

Aigars Mahinovs: Do you want to hear the most incredible "it's not ...

Do you want to hear the most incredible "it's not a bug - it's a feature" story ever?

After shooting hundreds of megs of RAWs with my Canon 350D last couple of weeks, I noticed a very strange thing - importing this large amount of files from my camera into F-Spot took ages. F-Spot ate memory in tens and hundreds of megabytes and never returned it back to the system. Well I blamed it on Mono and went searching for a better way. Then I found out that command-line C program gphoto also take the same horrific amount of memory to import my photos. I saw that to download 900 Mb of photos (~250 photos) photo memory use went up to ~910 Mb (2 Mb were shared). Luckily Linux managed to swap out part of gphoto, so I could finish the download with my 512 Mb of real RAM and a 1 Gb swap file. I googled and founds tens of bug reports on this - first of them as early as December 2004. Ouch.

Well - let's see what the problem is, shall we? Some bugreports reference a bug in gphoto's SourceForge bug tracker where a users reports that downloading a 250 Mb video file takes 250 Mb of RAM and developers reply that unfortunately that is the limitation of current infrastructure and it is very hard to fix. Bumer.

But wait! He says that downloading ONE file takes a lot of RAM. This limit should not exist when downloading multiple files - we should be able to drop information about previous file as soon as we start downloading the next one, right?

Ok, lest see, what really is going on there. Downloading source of gphoto. Looking at it. Seeing a lot of mess. After around 10 minutes I start to understand that there is a table of option names and functions and the real job is doe by command line parser who calls a function as soon as he encounters a proper parameter on the command line. :P After 3 more minutes jumping around the code I finally get to a function that gets called to download a single file. Looks pretty easy:
Looks all fine and dandy so far. However I see the memory use that suggest that this last operation does not happen as it should, so I search for the gp_file_unref() function. I do not find it in gphoto source, but as I soon figure out - it is in libgphoto2. The function is pretty straight forward - the reference count of the structure is reduced by 1 and if it has reached 0, the structure is freed from memory via gp_file_free() function.

Hmm, I wonder what will happen if I replace gp_file_unref() with gp_file_free() in gphoto? After a quick compile and installation (I thank the Gods and all DD's for the wonders of "debuild -us -uc && sudo dpkg -i ../gphoto*.deb") I ran gphoto again. Wow, it now only consumes 8-16 Mb of RAM and not 900. The files downloaded fine, but in the end glibc made a lot of fuss about "double free". What does that mean? It means that someone managed to get a reference to our MemoryFile and didn't give it back. Naughty boy!

We only call three functions using that pointer, so it should not be hard to trace them trough the source to see what they do. The gp_file_new() function looks good, it sets reference count to 1 always. gp_get_file is more complex - I get to crawl through a lot of strange redirects to all levels of gphoto architecture. At one point I get a bit alarmed as I see a local variable called ref_count, but then I see that the code just stores reference count there for safekeeping while data is copied from another object and right after that copy reference count is put back safely. After all that I get to the end of the gp_get_file function, just a couple thing left - cache the result, clean up and return the file. Wait a minute ....

CACHE?!?!?!!

$(&@($^@#$(^@&^$(#&$@#(&$(@#$&!^&$^@*!(&$#(@& !!!!!

It appears that someone thought that it is a good idea to use a gig or so of my RAM for cache, just in case if I would like to download the same photos the second time around in the same program call. IT IS NOT!

Results: one line patch, one NMU building for upload, one *very* long bug in upstream bug tracker, one developer quite upset and not too convinced about the correctness of free software ways any more :P

26 November 2005

Andres Salomon: save the world

This article cracked me up; specifically, two lines of it. “‘The agreement signed today will defend Somalia’s territorial waters, defeat the pirates and put an end to the illegal fishing and poaching of our precious natural marine resources,’ Prime Minister Mohamed Ali Gedi said.” “Defeat the pirates” sounds like something out of a video game or cartoon. That could’ve just as easily been about killing Shredder, defeating the Foot Clan, and saving April O’Neil. “‘We will end the piracy very quickly, there is no question about that,’ said Mr Casini.” This company is clearly the answer that the RIAA and MPAA have been looking for!

Anthony Towns: The NIv2 Plot

So having found time to catch up satisfactorily on the implementation, time to get back into the blogging. After working out what you actually want to do, the next step in implementing stuff, in my book, is to make sure you fully understand the context of the stuff you’re trying to change. In this case, the “unapproved” queue concept comes from some thoughts from quite a while ago that come under the heading “NIv2” for “new incoming v2”. For reference, the original “new incoming” was the switch to separate queues for new, byhand, and accepted packages, which was followed by a notable update shortly after to make accepted autobuilding possible. That setup works, but has a few problems. One is that packages sit in accepted for quite a while (up to a full 24h), and occassionally in that time it can become inappropriate to actually add the package to the archive – for instance if it’s a build of a package that’s then removed from the archive. This results in an UNACCEPT, and requires manual intervention, since potentially it can result in weird inconsistencies, such as bug closures. Another is that files in the various queues aren’t tracked in the database, which can result in files (particularly upstream tarballs) being lost or left behind, and also requires some unpleasant special casing in the code. A final concern is that one of the bigger time sinks in the daily pulse is the apt-ftparchive scan, which is actually just doing work that’s already been done in order to allow packages in accepted to be autobuilt. Put all those concerns together with the ones mentioned last week, and you get the impetus for NIv2. The principle of that is to put stuff in the queue into the database properly, simplify it, extend the queuing support to deal with different queues, and move stuff from accepted directly into the pool every quarter hour, though only pushing to buildds that frequently, leaving updates of Packages files and mirror pushes to still be daily, or every few hours or whatever. This is what that bit looked like in the dak TODO:
[hard, long term] unchecked -> accepted should go into the db, not a suite, but similar. this would allow katie to get even faster, make madison more useful, decomplexify specialacceptedautobuild and generally be more sane. may even be helpful to have e.g. new in the DB, so that we avoid corner cases like the .orig.tar.gz disappearing ‘cos the package has been entirely removed but was still on stayofexecution when it entered new.
Obviously, it needed to get defined a little more clearly than that to work out how much the changes for the security queues I’m interested in depend on the other changes, and what they actually mean in detail. After some IRC discussion we came up with more or less the following summary of what NIv2 actually means:
How NIv2 should work. q/accepted goes away; once packages are accepted, they get added straight into the pool and the database. At this point they’re added to a micro-suite for the buildds, and so apt-ftparchive can cache the package contents; and a symlink tree is made up so incoming.d.o works. The micro-suite might or mightn’t be a fully fledged suite in the database. Presumably it wouldn’t be visible in dists/ though. The micro-suite probably should contain packages uploaded to unstable for X hours, where X is 48 or 2x pulse-interval or similar. This means UNACCEPT is impossible and apt-ftparchive takes less time in cron.daily. q/byhand and q/new get new friends: q/sec-embargoed, q/sec-unembargoed, q/stable-updates. Rather than checking for “byhand” entries, or a lack of overrides; uploads get diverted to those queues if they’re uploaded to security or stable, and get moved out of there when a security team member or stable RM (ie, Joey) runs an amber/lisa-esque command. This means sec-embargoed and sec-unembargoed need to be autobuilt. This also means that proposed-updates can be a full suite, and point releases can be a matter of (a) adding proposed-updates to stable; (b) removing old versions from stable; (c) removing packages that have to be dropped; and users can put “stable + proposed-updates” in their sources.list reasonably sanely. This also means that REJECTs from accepted (security) or the archive (p-u) aren’t needed. It means the queue ends up looking like:
    unchecked      [uploads go here, insecure]
    holding        [secured]
    new            [waiting NEW processing]
    byhand         [waiting byhand processing]
    stable-updates [waiting stable RM approval]
    done           [.changes files for accepted packages]
    reject         [.changes, .reason and rejected stuff]
    bts_version_track [data for BTS]
with q/accepted disappearing and q/proposed-updates and q/old-proposed-updates being replaced by the stable-updates / oldstable-updates queues.
One of the nice parts about this is that it breaks down fairly neatly into three sets of changes: supporting additional queues, removing the accepted queue, and tracking queue stuff in the database. It does make those changes more or less dependent though – the new queues need to be autobuilt in the way accepted is at present; so it makes sense to add the queues before removing accepted so as not to lose the queue autobuild support. The above actually can be simplified a little further – instead of managing a microsuite for changes since the last update, it’s possible to add accepted packages directly to the real suite; and generate the Packages files needed for autobuilding by querying packages accepted to unstable in the last 24 or 48 hours, simply by adding a field to track upload time for binaries as well as sources. In any event, this thus makes generalising the queue autobuild support the next challenge.

25 November 2005

Simon Law: Montr al geeks


Casa Magica
Originally uploaded by sfllaw.
There's this artists collective on St-Laurent, across from La Sala Rossa. They call their place Casa Magica, and it's really quite groovy. They've got this cozy living area with an open plan. The kitchen is separated from the living room with a tiled countertop someone built themselves. It's decorated in that way with splashes of paint, splashes of light, and furnishings that look like they grew there. I showed up at this place to meet some people in the Free Software world. I've been in Montr al for about a year and I still don't know very many hackers in the city. So when I got invited to Les 24h SQIL, I decided to show up and meet some people. I went up St-Laurent to a non-descript red door with a poster about SQIL on it. "This must be the place," I thought as I tried the door. Upstairs, I was greeted by a living room full of random people: some sitting in front of computers, some chatting away, and one guy fiddling with a projector. I wandered around in a state of confusion until I was introduced to Robin. Robin Millette seems to do a lot of work for FACIL, which is an organisation for promoting free content in Quebec. He introduced me to a bunch of people, like Simon Raven whom I helped with finger-ldap. I met Fran ois from Quebec City, who was interested in Nitix. There was Nicolas who is a Java developer that writes web-based applications. And other people like Alex, Yan, Marco and Matthieu who seemed nice but I can no longer remember what they do. I returned later in the week to Robin's birthday party where I happened to meet Fabien, who is a consultant that does work on Firefox and Yannick who's a Ph.D. student at McGill. We had a good time talking about quantum computing and how to design a programming language for quantum computers. Good geeky times were had.

Andres Salomon: metablogirctasticfunk

<dilinger> sucker
<Clint> you just wait until you’re infested with mp3s
<dilinger> i wear my mp3 collar
<dilinger> it has my name and phone number engraved on it, too. in case i get lost.
<Clint> have you had your shots?
<dilinger> yes. i’ve been spayed and/or neutered, too. i highly recommend it; it was an enlightening experience
<Clint> you should blog about that There, done!

Uwe Hermann: Improbulus - Creative Commons Song

Note: This is actually an entry for my music podcast, but I'm cross-posting this to my blog as well, as I think it deserves a broader exposure! Now, here is a really special song I'd like you to listen to. This is a great song (aria!) by Improbulus which is about the Creative Commons movement. The song itself is Creative Commons licensed, of course, as well as the lyrics (the "libretto" is you want). Quoting from the original site, the song is an
Operatic ode to Creative Commons, to the tune of Puccini's O Mio Babbino Caro!
The lyrics:
This is Creative Commons:
Something that you've created
Somebody else can copy
Spreading the word about you
You see, they're free to copy
But they must give you credit
And others then can copy
Giving you credit anew
And if they make some money so must you - you profit too!
Isn't that fair, and how?
So get Creative now...
It's a wonderful promotional song for Creative Commons, and it sure has the potential to become sort of the hymn of the Creative Commons movement/culture, if you ask me. (found via consumingexperience.blogspot.com) Song: Improbulus - Creative Commons Song (2:33 min, 2.4 MB)
License: CC-by-nc-sa 2.5
Source: archive.org

24 November 2005

Mike Hommey: Hard Disk s hard life

I knew that hard disks had a limited time-life park/unpark-wise, but I didn’t know that was that bad. I always thought that because of ext3’s commit every 5 seconds, disk would never spin out and park the head. I was wrong. It seems that whether or not the disk is accessed, every put here the time it is for your disk minutes, it does park and unpark the head. Well, at least on laptop disks, because it seems this is not the case for desktops. My 3 year-old vaio, which is now this web server, has a Load_Cycle_Count of 580465 for 9775 Power_On_Hours, which is about 1 load cycle per minute.
My 1 year-old vaio, has a Load_Cycle_Count of 83718 for 4043 Power_On_Hours, which is about 1 load cycle every 3 minutes. While I managed to actually stop the load cycles to occur on the older vaio, with hdparm -B254, nothing actually stopped it on the newer one. I tried to change some other parameters with hdparm -S but nothing did work. I still have to take a look at the BIOS, though. Now, the question is : why the fuck are the heads parked/unparked every little while even when accesses occur ? Is it a conspiracy so that laptop disks won’t last forever ? Well, at least, I’ve never experienced a hard disk failure in 12 years of using computers with hard disks. For how long ?… [Note: the Dell laptop provided by my company, running Windows XP (which also has a somewhat journalled filesystem and commits the journal every few seconds) has around 24000 load cycles for about 800 hours of use, which is 1 load cycle every 2 minutes, so this is not a Linux issue.]

Aigars Mahinovs: Cosplay warm-up


Cosplay warm-up
The opening of AnimeFest went great - there were few cosplayers and a huge lot of general public. Anime is on the high.
The fest was opened by two cute girls - one of them was speaking in Latvian and the other in Russian. At first they were translating each others lines both then they diverged and even started a small dispute. You had to know both languages to "get" the joke, but I think most of the people in Latvia do know Russian enough for that.
The opening program consisted of "Howl's Moving Castle" - a truly wonderful anime movie from the same director as the "Spirited Away". A great fairy tail as expected from Studio Ghibly.
Also:

My blog is worth $5,645.40.
How much is your blog worth?

I have no idea why, but I would like to check out half of it, please :)

Matthew Palmer: Key Signing and The Identity Problem

Yet another thread on keyring updates in Debian has gotten me thinking about key signatures, what they really represent, and other associated topics. For those of you who might not know what I'm talking about, a brief primer. Before someone can be admitted as a Debian Developer, they have to have an OpenPGP key (practically, a GPG key) signed by a current Debian Developer. That is, someone who is currently a DD has looked at a photo ID, compared the photo to the face offering a key fingerprint, and compared the name on the ID to the name on the key. If they all match, we have a signature. The other qualification for becoming a Developer is going through a process designed to determine whether you have the required competencies. Since this testing process is conducted electronically, not face-to-face, the primary means of identifying the person behind the answers is via the OpenPGP key they used throughout the process. So, what do we have out of this process? Two things, that I can determine: So, the problem at issue is this -- what do you do when you lose control of that key? You lose it, or it gets compromised, or it expires (whoops!), or whatever. For all intents and purposes, when you lose control of your key, you no longer have an identity, in Debian terms. Generating a new key (and hence identity) is straightforward -- a quick invocation of gpg and you're away. Unfortunately, all that gets you is a pile of bits. There's nothing that intrinsically links you to that key. That's what other people's signatures on your key is for. Then, it comes time to get Debian to accept your new key as belonging to you. This is a lot harder than trying to convince the RTA (DMV.en_AU('New South Wales')) to give you a replacement drivers' licence. Why should it be? You're doing effectively the same thing -- "I am $FIRSTNAME $LASTNAME, give me my (licence upload privileges)". The difference is that, in the Debian case, all of our identity is effectively tied up in the key we use to go through NM. The person behind the key is somehow secondary to that whole process. So when the key completes NM, we record it in the "people who can upload" keyring. When a new key (which is prima facie completely untrusted) should be put into the keyring, we need to ensure that it is qualified. How can that key prove qualification? Well, we can send the new key through NM (dear ghods, no!) or refer to the source document (as it were) -- the human being. We're looking for consistency between the person between the two keys. That's trickier than it looks at first glance. Why? The big one is the non-uniqueness of $FIRSTNAME $LASTNAME (or even $FIRSTNAME $INITIAL $LASTNAME, for those so blessed). Google for yourself one day, and you'll see what I'm talking about. Anyone who has the same name as you could, at first instance, pretend to be "you" (for some values of, anyway). It might seem fairly unlikely, but there are two DDs with easily-mistakable names, out of a pool of 1,000 or so. The probabilities are not in our favour on this one. Then, of course, there's fake IDs, which are a whole other ballgame. How does the government get around the problem of name clashes and identity-theft-by-ID? By using other metadata about you to more uniquely identify you. Your date of birth, street address, perhaps even a general physical description -- all of these can help to disambiguate all of the identically named people out there. Debian can't use that, though, since that metadata isn't initially collected, and so it can't be rechecked later. This does suggest a bit of a solution, though. I said that Debian doesn't collect that info, but that's not entirely true. There is an optional repository of Developer contact details stored for other DDs to access, so we've got something to work from. The Developer updates their own details (whatever they feel comfortable entering). But, of course, people signing your key need to know about all that before they sign the key, so they can check (for example) your residential address and date of birth on your photo ID. You might ask "but how is the info the developer themselves entered accurate?", and that's a good question. The answer is that the legitimate developer entered that info, so if someone with the same name matches that data, then it's reasonable that it's still the same physical person. It's not a real good solution, though. Not all developers enter full metadata (and I can understand why they don't want to). People also often forget to update their details, too, which could quickly cause all sorts of problems. What is a good solution, then? We could always go with a bit of biometrics -- if there was any solution that was sufficiently cheap, reliable, and distributed enough to be used to identify 1,000 developers distributed across the globe to a reasonable standard of reliability. I'll wait for a minute while you finish laughing and wipe your eyes dry. I have to say, I'm stumped. I'd hoped, while writing this, that by the time I was finished I would have worked something out. But nope, it's a problem that's way beyond me. But I think I've got a much clearer handle on the problem space, so with a bit of luck, my subconscious (or someone else's) will eventually produce a sensible answer.

Next.

Previous.