Nobody reads the fine print (for mobile widgets anyhow)

I've gotten used to skim the legalese things that you agree to upon any account creation, etc. You know, those things that have a textbox next to them and the submit button is disables until you check them.

Anyhow -- here is a nice piece from jil.org, a developer portal for mobile widgets. I used to do Konfabulator (now Yahoo) widgets long ago and I though I should see what's with these new "mobile" widgets. (The terms PDF is here ).

   7.  JIL’s right to use User Content
         1. With the exception of personal information, you hereby grant JIL a perpetual, unlimited, royalty-free, worldwide, non-exclusive, irrevocable, transferable license to run, display, copy, reproduce, publish, bundle, distribute, market, create derivative works of, adapt, translate, transmit, arrange, modify, sub-license, export, merge, transfer, loan, rent, lease, assign, share, outsource, host, make available to any person or otherwise use, any widgets or other content you provide on or through the Developer Site or which you send to JIL by e-mail or other correspondence including, without limitation, any ideas, concepts, inventions, know-how, techniques or intellectual property contained therein, for any purpose whatsoever and in any manner (“User Content”). JIL shall not be subject to any obligations of confidentiality regarding any such information unless specifically agreed by JIL in writing or required by law. You represent and warrant that you have the right to (a) grant the license set out above and to (b) upload the User Content on the Developer Site. You acknowledge that the license set out above includes the right for JIL to make the User Content available to a Sponsor and other entities with which JIL has contractual arrangements for further distribution of the User Content.

Now, this paragraph starts like a standard paragraph on many sites where they basically say the want to be legally allowed to display your product. So they need to be able to host, distribute and market the widget. Sounds nice. Obviously their partners need to be able to do that too. Ok, pretty standard so far...

But here is the interesting part: they want to be able to modify your widget and create derivative works! So this is not the standard "hosting" agreement -- you are actually granting them a license on your source code to do as they please. If you combine this with the fact that every agreement of this kind (and obviously JILs too) has some indemnification clause, you get an interesting situation.

An interesting software would be one to track all these agreements. I think that by the end of your lifetime, it would be pretty scary to look at the dependency graph all these agreements have created between you and sites/companies, partner companies, merged companies, owners of bought companies.

In other words, if we define this "agreement distance" in the spirit of the Erdos number , I'd say that over a 30 years span the agreement distance becomes 1 for any reasonably active individual with any other major company or website.

OSGi has won

Although NetBeans' module system was on-par with OSGi, greater industrial support meant OSGi always looked like a better pick to outsiders.

Starting a while back I saw OSGi as the clear winner. Especially when Glassfish 3, an major Sun project picked OSGi instead of the NetBeans Module system, it was obvious OSGi was winning even inside Sun (although they were reluctant towards giving OSGi a too big stake in the upcoming Java 7 module system).

In the meantime NetBeans is getting native support to run OSGi bundles as well as getting ready to run inside an OSGi container.

Oracle wanted a common IDE extension API starting at least 2002 when they sumitted JSR 198.

Now, owning Java and NetBeans itself, they have it really easy to define the roadmap for both.

I estimate that NetBeans will be able to run inside an OSGi container by the end of 2010. We'll also see official NetBeans plugins distributed as OSGi bundles instead of NetBeans modules. In the end the NetBeans module system might become a deprecated subsystem.

--
Note: This is just my take at technology analysis. I have no inside information obtained via my NetBeans Dream Team membership or from Oracle.

Interesting banking factoid from Romania

Like anywhere in Europe, all bank deposits are guaranteed if the bank goes under, within a limit.

For a company account, that limit was until not too long ago 20.000 euro. Now, the limit has been raised to 50.000 eur.

See the chart bellow for an idea on how the limit has been raised. It kinda shows the evolution of the Romanian economy as well as the panic at the beginning of the finance crisis.



What seems surprising to me is that if you have a company with, let's say, 1 million eur in deposits, you would need to open accounts to 20 banks and spread your money.

If you have 2 million euro you are out of luck in this regard, because you would need 40 banks and Romania only has about 30 officially registered banks. (Of course, with 2 million euro in cash you would be one really happy camper.)

I wonder how a big company like Apple is handling this, given they had a few billion dollars in cash reserves last I checked.

Slicehost as a build server

I'm using a Slicehost server for over an year now to host my build server and my slice seems to be getting slower.

Here is the graph for one of the projects:

The build initially took about 30 minutes, then I had a period where I jumped to about 70 minutes. This lag was entirely my unit-test and after some refactorings I took is down again to about 30 minutes, which is decent.

Now take a look at another project:

The difference is that the project took all long about 40 minutes, and now I have spikes of 3-4 hours !

What's the catch: well, the first project is taking so long during unit tests since I have a lot of GUI tests, where the code has to sleep and give the interface time to repaint, etc. So, although the time is 30 minutes, it's mostly waiting for the GUI (inside an Xvnc instance) to paint.

The second project though does a massive build where I just produce JARs and don't run any unit tests. It's massively IO-bound.

So, the way I see it, in the past 2 months or so the machine I'm running my VPS on, has been getting slower doing IO request.

IO has always been a problem with my limited VPS experience. First, I got rid of this by moving from the 256mb slice to the 512mb slice since apparently I was just trashing the swap file.

But now, I'm not so certain it's a RAM issue anymore. The 2nd compilation just needs to touch the disk so it doesn't matter how much RAM do I add, after the minimal amount needed for ant and javac.

I'm starting to think I should move the build server onto an EC2 instance. This way I could use a smaller slice just to run Hudson, but do the actual building onto a bigger EC2 instance. I'm not certain it will be cheaper though.

Later edit: The discussion here is continued with my post about using EC2 instances as build servers.