Talkwards

I’ve just had the rather unsettling experience of trying to deploy a new jar file (one I recompiled after some changes). This file were to be deployed on a rather old set up of Java 1.4.2. On first try everything broke with the classic “Unsupported major.minor version 50.0″.

So I went back to the drawing board. I installed java 1.4, and made sure my development Tomcat was running it. Then I did some research and found out how to make Eclipse compile 1.4 compliant code. I started and I got the same error still.

Once I figured out what was wrong I realized I was an idiot (Doh!). The error I’ve gotten wasn’t for any file part of the jar I was trying to deploy but for “index_jsp”. The thing is my Tomcat compiled my JSP:s into class files and never looked at them again until they were changed. I am sure there’s several ways to solve the problem, I just went and deleted the files in the “work”-directory (those pertaining to my Context).

The preferences window for setting source and target versions for Java compilation

Now over to how to make Eclipse code projects to a certain Java version.

There are two values you will want to keep track of. The source version and the target version. The source version tells what version your source code is written in. Whereas the target version tells what version of Java you want your class files in.

If for instance you have a project written in Java 1.4 source style, but you have to run it on a Java 5 you’d set the source version to 1.4 and the target to 1.5. You are now compiling Java 1.4 source into Java 5 class files.  Unfortunately you’re not able to do the opposite, compile Java 5 source code into Java 1.4 class files.  This is probably due to API incompatibilities, Java 5 has a larger API than Java 1.4.

Now, in Eclipse you have two settings in three places that controls the source and target versions of your compilations. Under Window->Preferences->Java->Compiler (Eclipse 3.4) you’re able to set the versions for the whole IDE.

When you create a new project you’re able to determine what version of Java (source and target you want) and right clicking on a project and choosing Properties->Java Compiler, you have the same dialog as before.

You set the target level in the select box “Compiler compliance level”, and optionally by unchecking the “Use default compliance settings” you’re able to change the target (“Generated .class files compatibility”) and source respectively.

If you experience other problems you may want to “clean” your project(s). Cleaning a project means all compiled files are removed and all source files are recompiled (something the IDE will do by itself when you change compilation versions, but if you want to be sure, you can do it manually). This is done by choosing Project->Clean. In the dialog you can chose to clean all projects or just those you select.

Opening a site Google has listed as spreading malicious software via the browser.

What is an SQL-injection. How can it affect my site. How does it happen and how can I avoid it?

Since Firefox (2 and 3) and MSIE 7 started using Google’s (and others) system for blocking sites that produce harmful web pages the problem with SQL-injections have been put on the spot.

What happens is that an attacker hacks a site by placing their own SQL-code into the database of the victim system. Instead of just performing a DOS (denial of service) attack bringing the whole site down by for instance deleting all the tables or doing something else harmful to the site the attacker plants client side browser code in the database making all visitors run client side code that will infect their computer with a virus. This virus may do everything from listening in on traffic between the client (web browser) and bank applications, to connecting the client system to a botnet.

Needless to say, the SQL-injection attack has become a problem not so much for the owner of the originally defunct site as for the visitors to said site. (Although users of the web should not underestimate the consequence of a good virus protection, system update policy and secure browsing policy).

Since the owner of the vulnerable software won’t notice any detour from business as usual (and neither will most infected clients), nobody is the wiser to the problem.

This is why Google (and others) have started evaluating (and flagging) sites with bad content, and why Firefox and MSIE (and probably others) have started blocking them.

Read entire article.

You may have thought GNU/Linux was written by idealistic Unix Gurus camped up with a bunch of Jolt-Colas in their mom’s basement, but a recent report from the Linux Foundation states the opposite. Since Linux kernel version 2.6.11 in Mars 2005 the number of developers has grown from 483 to 1,057 in version 2.6.24 (January 2008). However, the number of sponsoring companies has also grown from 71 to 186 in the same time.

The major contributors aren’t Mom’s Basement Inc. either. Companies like Novell, IBM, Intel, SGI, Oracle, Google and HP rank among the 20 largest contributors (counted in number of sponsored changes, and here sponsoring means paying employees to program those changes).

This is just the Linux kernel (some 8.5 – 9 million lines of code). However, the Linux kernel in itself is of little use to anyone. You have to add the GNU part of GNU/Linux, consisting of commands like fdisk, aspell, bison, ghostview, and wget to that, and you’ll be looking at a much larger number of lines of code. If we go even further adding programs from other projects (like the Mozilla project’s FireFox web browser, or the OpenOffice suite) more lines of code are added (for exact numbers see ohloh.net), and we’re still talking about programs supported by large companies (IBM, Sun, etc).

To sum it all up: no, GNU/Linux is not being written by enthusiasts in the basement anymore. It’s being written by large corporations for competitive reasons. Hardware manufacturers wants to make sure Linux will work on their hardware, software companies can be anything from Linux distribution owners (Red Hat, Novell, MontaVista), use embedded versions of Linux in their consumer hardware (Sony, Nokia, Samsung), or for other reasons (for instance Volkswagen uses Linux for in-car networking between different components).

Once upon a time a CD was large. Huge. You used it to save lots and lots of data.

Then came MP3s, movies, digital cameras with millions of pixels and suddenly the CD was small. And the DVD came, and for a while it was large… I don’t think it ever was huge.

Today I would have to use more than 300 4.4 GB DVDs to save all my data, and that only includes the data on hard drives. Making back-ups becomes a question of selecting what to back-up and what to leave for chance. A real pain.

But there might be light at the end of the tunnel.

Researches at the Technical University of Berlin claims they’ve managed to put up to 500 GB of data on a CD/DVD-sized disc

This is (layman’s interpretation) done by using holograms. The disc is transparent (wonder how that will work with labeling?) and uses ten layers of data (to compare with blu-rays that use two, and ordinary DVDs that use one). Anyway, sometime around 2010 they might be able to fit as much as 1 Terabyte to a CD-sized disc.

That’s probably the same time as hard drives comes in 10-20 Terabyte sizes, and soon after the 1TB DVD will once more be insufficient.

Wheehoo…