muon.html

The weekend started so well. Through a series of circumstances I went to see Evita at the Neptune Theatre. That was a very enjoyable show.

I got home around 11 PM. I was going to do a quick login and check my e-mail and get to bed by 12.

Unfortunately when I logged in the computer was in a bad state. The screen was covered in popups that kept appearing on their own. The popups were for stupid sites that all seemed to end in muon.html. Even Firefox was popping up extra tabs when I tried to do anything. I couldn't open a command prompt or the task manager. After a couple of minutes Windows defender put up a screen saying it was going to reboot the computer to protect it. Big trouble.

It was difficult to get the computer working well again. I ended up running numerous scans and fixes with windows defender, ad-aware, spybot and hijack this. That cleaned up all kinds of stuff. Finally after I cleared out that bunch of other crud, I followed these instructions to get rid of muon.html. The instructions worked great and now the computer seems to be working properly. As a bonus I got rid of a lot of junk from auto startup that was making it take way to long to start up.

Where did it come from? That's a good question. I noticed that the trouble appeared shortly after my wife downloaded limewire. As part of the work to get rid of the popups I zapped limewire. I hope I never see it again. I noticed that of course limewire is as stubborn as the viruses to get rid of. After the first attempt I got this dumb java message every five minutes about some missing gnutella class. So limewire seems to be built on gnutella - wonderful.

It's annoying because this has happened before. Months ago my wife started using Kazaa. For about a week she got some files she liked. Then the popups, weird error messages, IE start page change, and Google hijacks showed up. That was a lot of work on me to clean up. After Kazaa vanished the popups went away too. I don't know why she thought it would be any different with limewire which is just kazaa by a new name as far as I'm concerned.

I have to use the computer too to log in remotely to work and to just use. If I had the money I'd get a wireless router and my own computer and just use that; let my wife clean up the viruses while enjoying her downloaded stuff.

I don't see the point of downloading music from unknown sources when iTunes is something like $0.99 a song, and Yahoo music is $7 a month.

It's troubling that Firefox was affected by the trouble. In the past stories of trouble in Internet Explorer were like hearing about strife in the Solomon Islands, Sudan or Nepal. Trouble in a faraway land that didn't really affect me. I guess Firefox is popular enough now that the black hats are disrupting it too, which sucks.

I know of people who have suffered with random popups for like months. I was thinking of setting up a removal service to try to make some money off this.

+1 for JProbe

We were doing some performance analysis recently of our application. The application is distributed across a central J2EE AS component, with satellite nodes running under Tomcat connecting to the central J2EE server.

We used JProbe to collect the baseline performance data and locate the hot spots. I have all positive to say about this product. I was focused on the Tomcat part, but the people who used it on the J2EE side also spoke well of it.

For Tomcat, setup was a breeze. It was all simple click through wizards. JProbe has a built in Tomcat module and it works great for Tomcat 5. The setup worked properly the first time I ran it.

The stats it collected were right on. They provided all the data I was looking for. The results were presented in a useful way that allowed me to see the key summary parts while also being able to drill down to the level of detail I needed.

At one point I wanted to focus on CPU utilization in the remote Tomcat servers. I was able to easily reconfigure my JProbe session to measure CPU usage instead of default clock time. It worked just great and quickly isolated some key areas. The areas it found were not the sections we thought were problematic. So JProbe saved us a lot of effort.

Remote control

It's just so impressive what you can do remotely these days. The software is great and the CPUs and networks are now fast enough to make it work quite well. Here are a couple of examples.

Sitting at my home on a weekend I get a call about a support issue.
- from my home PC I connect to a VPN at the Halifax office
- from the VPN I'm able to remote desktop to my work PC. The GUI and everything comes up properly. It is responsive. Close enough to the real thing that I'm able to work without really noticing I'm logged in remotely. Remote desktop is just an awesome piece of work.
- from the remote desktop session I use Funk to connect to another server on a different continent. Again everything is responsive. The mouse works the way you expect. I can copy and paste from computer to computer and it all works easily
- after I Funk'ed into the computer on the other continent I was able to see what they had and do the fix
- the chain is home PC -> office VPN -> office PC -> server on a different continent


Here's another example
- sitting from my home PC I connect to the office VPN
- from the VPN I remote desktop into my work PC
- from remote desktop off my work PC I launch an xterm to a UNIX server in the office
- from the xterm window I ssh into a different UNIX server in the office
- the chain is home PC -> office VPN -> office PC -> virtual xterm session -> virtual ssh session


I just find it remarkable all the layers of indirection, all the encryption, all the network traffic. And it comes up great and is nearly as crisp and responsive as being there.

Remote desktop provides other advantages. Before RDP, when it was busy at the office, I had to be physically in the office to put in the extra hours. This meant I sometimes had to arrive at work horribly early. Or it was disruptive staying late or going in on a weekend. Now I can usually put in the extra time from home and still be able to do other stuff around.

The thing you have to be careful about with RPP is you can get a bit too attached to the office. Like just extending your office day from home after supper every night. It can be a bit "addictive".

It's OK in non-peak times to log in for a few minutes in the evenings and check your late in the day e-mail. Or pick off some small thing that was nearly done when you left. But keep it balanced. Your time away from the office is just that.

EJB is not portable

Remember when Java bragged about being "write once, run anywhere"? Well in EJB land that does not seem to apply.

We did a port of a J2EE application to a new application server. We were able to finish it. I'd say that about 70% of the porting effort was spent on EJB. Around 15% was the GUI servlets. Around 15% was other stuff like documentation and the ant scripts and some J2SE clients.

The servlet stuff went well. There were just a few small things we were doing that were against the servlet spec that the first application server allowed, but the new one didn't. Easily identified and fixed.

EJB was a much different story. So much of it is vendor specific with designed lock in that porting is so much more effort and complicated. It just shows how painful everything is in EJB. It's painful just getting stuff to work on the original application server, let alone porting it to another one.

That's just not the Java way. Originally people liked it and used it because it was portable. When something is painful to port and requires code changes to port like EJB then that is not in the spirit of Java. It may be short term advantageous to application server vendors to discourage porting or make it expensive. But long term it's a bad thing. It undermines the cross platform spirit of Java and comes across as bait and switch.

I've grumbled about EJB before. I just don't get EJB or why people would choose it. It is painful to do anything in. It is so verbose with all the endless and non standard XML files. There are all these code restrictions that annoy and frustrate the programmers. Weird and tedious concepts and terminology in the EJB spec. Bewildering arrays of modes and options. Good luck connecting from an external J2SE program.

At every turn EJB comes across as developer hostile. Without developer support it will have a tough go of it long term. It's no surprise that new competing technologies have emerged and have gained support.

If I was the decision maker and was starting something brand new in Java with no legacy code base then I would not choose EJB. Just stay clear of it entirely and everyone will be happier and better off without it.