Older blog entries for audriusa (starting at number 16)

29 Oct 2010 (updated 29 Oct 2010 at 21:08 UTC) »

Be with it, with this Mac and these foggy talks about Java deprecation on that platform! Mac OS makes 5.0 % of all visitors on Ultrastudio.org when Linux makes 9.9 %, graph here. Seen who has "failed on desktop". Also, maybe Roman with Mario will get IceTea as a better replacement of the proprietary Apple Java virtual machine.

First Google-Oracle discussions and now this. Likely it was the most unlucky time throughout the history of Universe to launch the Java applet portal.

4 Sep 2010 (updated 4 Sep 2010 at 10:01 UTC) »

Today is near one month as our Ultrastudio.org, encyclopedia with Java applets (code reviews, service side build and approval workflow) is online. During this time, the site has grown from the initial 14 applet "seed set" about 50 applets at the moment, each of them having explaining article next to it. Some articles reuse Wikipedia material, but many are differently written, aiming for short, clear introduction rather than full of coverage. The numbers are not that big, and actually only tiny fraction of even very promising topics is covered, but the site already gets in average about 154 page views per day (excluding spiders and all Switzerland). Many applets have been launched. Ultrastudio.org is currently heading the "top 5 %" rating list at Jars.com. This seems enough for the project of our age and profile.

Great to have IceTea plugin that makes such projects possible.

Today I checked SourceForge after a long gap and discovered that StableUpdate that I started years ago is alive, has two developers without me and gets code contribution. It is really impressive to see such things happening. Your code can live without you! Not the first time I see it yet always impressive.

Java Applets in Wikipedia - that do you think?

Wikipedia is making a call for strategic proposals, and one of them is to allow Java applets for visualization. I decided to post a blog as this may be interesting for us. JFreeChart would rock there!

15 Jun 2009 (updated 15 Jun 2009 at 18:58 UTC) »

Nice evening today: come I to "Nord See", order something tiny. Suddely the waiter brings to me the big top range meal, smiling sweetly and saying "this is for you ... ". I look surprised but assume maybe some marketing activities. Exactly when I finish the same waiter runs back away, shouting "... when you have NOT been ordering this, you must say so!!!!". That should I do? "But the taste is really good" - reply I with the expression of the canibal in my face ,- "I will pay, no problem". Why to spoil the mood so raised, not so expensive after all. Reminds me.

13 Jun 2009 (updated 15 Jun 2009 at 19:04 UTC) »

Have recently finished the practical part of "Advanced Operating Systems" in ETH. More a hobby - like activity, lots of time have passed since I have been a student the last time. Step by step, over half a year each student have implemented a tiny working system on the top of L4 microkernel for NSLU2. It even has its own ELF loader. At times I started to think that it may be interesting to put a java virtual machine on the top of L4 as the first (root) task. In L4, the root task can do many things that the ordinary program cannot do. Most interesting it can map and remap pages, so we can have chunks of memory appearing from nowhere in virtual space. Or extrafast moving by remapping (while it may be difficult to see as these pages are 4 kb at least and must be aligned). If some other task (normal L4 executable) wants to do such things it can only do via requesting root task to do this. Context switches and so on.

L4 also has quite pretty threads, and each thread can have individual mappings. For instance, they can have each its own stack exactly in the same place of the address space. But in general it is a very tiny kernel; apart maps, threads and interprocess pipes there is almost nothing more there. This is not because of incompleteness, it is more a kind of concept.

However drivers seems being a biggest problem, even if we restrict interface to the network alone. It was a not so bad network driver for the NSLU2 chipset in the provided package, but the problem is that this hacker-loved slug seems no longer in production. Some German groups try to run existing Linux drivers under L4 in some emulation mode.

Interesting to see, the CPU cache matters a lot in java, also. If we have something like buffer[a] = buffer[0] for a really long buffer and various different a, it may be up till twice slower then buffer[a] = buffer[a-1]. This is something important to note. There are C guys ready to crucify everyone that says java can be tried in high performance computing, using they own knowledge about caches.

Some days ago I have tried my Dell Latitude D830 together with Fedora 10 Cambridge, and was really surprised how far have everything advanced since relatively hard times of getting Fedora 8 Werewolf working. There is really reasonable difference now when Cambridge seems having absolutely no problems with the laptop - not only wireless and suspend work but even the monitor video output switches flawlessly where needed during presentation. Fedora community have done a great thing once again!

So, the following configuration is supported by Cambridge no worse than Mac hardware by Mac OS: Intel Core 2 Duo T7800 with GMA X3100, Dell Wireless 1490 802.11a/g, 1680 x 1050 resolution.

24 May 2008 (updated 24 May 2008 at 15:46 UTC) »
Thoughts from JavaONE
This year I first time visited JavaONE in San Francisco, hopefully not the last.

It is really very good conference with a lot of things happening. I was impressed on talks about Glassfish, Spring and many other FOSS related things. I was less impressed noticing that some hands - on labs expect a single particular OS running on your laptop as some self - evident thing. But I believe that this is because the software under demonstration is so new and the gaps will be closed in the future. Also, the current status of the PhoneME seems a kind of mess: from one side, it "runs everywhere and is very easy to port", from the other side it is not obvious even where to download the official port for ARM processor. Likely there is a reason why many people with mobile devices seem running JamVM+GNU Classpath and stay happy.

We have also seen Dalibor who is now working for Sun. It was an interesting experience to have a conversation with him in a place so far from Zurich where we both have spent so many time in the past.

"GNU hackers flatten Sun's professionals with they java.util.BitSet" - sounds not so bad. Some simple comparisons show that our BitSet runs roughly 24 % times faster than Sun's 1.6.0 implementation. Sun takes back on HashSet, however - this one is slower in GNU Classpath, more or less by the same percent. See the posted Advogato article for details.

I am not sure why our BitSet is faster. Deciding from OpenJDK, both implementation use the array of long's to keep the data. From the other side, the overall code is so different that it is difficult to say, who makes the benefit. The history of GNU BitSet spans over seven years (1998 - 2005) and have seen many contributions. The main authors of this class seem Jochen Hoenicke, Tom Tromey and Eric Blake.

I have checked near all java.util classes but the remaining differences seem for me too small to be considered seriously. I am, however, happy to discover that GNU Classpath is very far indeed from being universally worse than OpenJDK at any single line of code. The detailed 'class versus class' check may discover more interesting differences.

7 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!