April | 2012 | Dark Views

How To Disable IPv6 In Ubuntu

30. April, 2012

If you’re getting errors from squid or your web browser with some weird IP address, chances are that squid is trying to connect to a server which supports IPv4 and IPv6.

To disable IPv6 on Ubuntu (also Kubuntu), add this line to the end of /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6 = 1

Restart your computer or reload sysctl.conf by executing: sudo sysctl -p

To check, run: ip a | grep inet6

When IPv6 is disabled, this will give no output.

Source: Quick Tip: How To Disable IPv6 In Ubuntu For Better Internet Speed

3 Comments | Software | Tagged: IPv6, Kubuntu, Ubuntu | Permalink
Posted by digulla

Rob Williams: More Reasons Why Software is Hard

27. April, 2012

Interesting read: More Reasons Why Software is Hard

Leave a Comment » | Software | Tagged: Kanbaan, Project Management, Scrum | Permalink
Posted by digulla

Patently Unpatentable: Multi-Language Movies

14. April, 2012

Not DVDs, in the movie theater: Each visitor get to enjoy the movie in their home language.

How?

Anyone has a mobile phone today, right? The audio system of the theater will only play the background sound, all the voices are transmitted via WLAN to each individual phone.

People can then listen to the voices of the actors with their own headphones.

Additional bonus: No audible ringing and everyone can tune the volume of the voices to their liking.

Leave a Comment » | Fun | Tagged: Mobile phone, Movie theater, Patently Unpatentable, Wireless LAN | Permalink
Posted by digulla

Why OSGi Qualifiers Aren’t Working

13. April, 2012

If you don’t understand how OSGi bundles get versions: You’re not alone.

On paper, the rules are pretty simple and straightforward.

In reality, the rules are broken by many Eclipse bundles because the tools don’t help to enforce them (Alex Blewitt wrote two great posts about that: “Why OSGi qualifiers aren’t working” and “Using Humans to solve a Tooling problem“). It’s not a rare problem either. Alex found 10% of the bundles got a new qualifier but didn’t actually change. That doesn’t take bundles into account which did change but the version wasn’t bumped.

When I started on an automated converter to turn Eclipse bundles to Maven artifacts, I hit the same problems. Some bundles get rebuild for no apparent reason, some have changes but the version wasn’t bumped.

This causes some problems. First of all: Which of those two qualifiers is “bigger”? “v20120119-1537” or “xx-20120301-1000-e37-RELEASE”?

And if you think that’s probably a mistake: That’s the qualifier for org.eclipse.jdt.core.source. It’s one of the core bundles for Eclipse. If even the JDT people don’t get it right, there isn’t much hope.

When building something with Maven, you have something similar: SNAPSHOT versions. But unlike Eclipse,

Maven forces you to drop the SNAPSHOT when you build a release
Maven replaces the string “SNAPSHOT” in the version with a build timestamp. This gives a consistent version scheme.
There are tools that check for SNAPSHOT versions
Maven can’t mix SNAPSHOT and releases in a repository (so you’re less likely to accidentally pollute your build or, worse, the build of someone else).

Unfortunately, OSGi have abandoned -SNAPSHOT versions for R5.

But maybe we can fix the problem on the Eclipse side. If you care, support Bug 376718 – Strip qualifiers for release builds.

Leave a Comment » | Uncategorized | Tagged: Eclipse, OSGi | Permalink
Posted by digulla

When Eclipse Won’t Start

13. April, 2012

There can be a couple of reasons why Eclipse refuses to start: Corrupted workspace, broken plugins or conflicting plugins. This blog post is about the last category.

How do you know that you’re affected? Start Eclipse with the command line option -debug. If there is a huge gap between “Time to load bundles” and “Starting application”, you’re on.

Start Eclipse in a debugger and set a breakpoint in org.eclipse.osgi.internal.module.ResolverImpl.findBestCombination(ResolverBundle[], ResolverConstraint[][], int[], List<ResolverConstraint>).

The interesting information is in the variable bestConflictBundles. This is basically a list of bundles that cause some kind of trouble. Usually, this is a bundle which has the singleton flag set but of which are two versions in the plugins folder (or in the plug-in list, if you started Eclipse from another instance of itself).

If you started Eclipse from itself (using a launch configuration), the solution is to open the “Debug Configurations…” editor, select the “Plug-ins” tab:

This tab has several interesting options: You can type (part of) a plug-in ID into the filter field to narrow down the huge list. If the list isn’t active, select “Launch with: plug-ins selected below only” above.

That way, if you want to disable all of BIRT, type “birt” and then click “Deselect all” to the right.

Next stop is the “Validate Plug-ins” button in the bottom left. This opens a dialog with all the problems the current selection has. This dialog isn’t modal! That means you can keep it open while you (de-)select plugins from the list. If your screen is big enough, you can move it so you can see the list and the “Validate” button. That way, you never need to close the dialog.

Otherwise, Alt+V is your friend.

In my example, the org.eclipse.jpt.jpa.db plug-ins cause trouble. As you can see, I pulled them out with a short text in the filter. Now, I can get rid of them with a single click on “Deselect all”. Validate … okay, things for worse.

But I don’t need anything from JPT for my tests, so I get rid of the whole lot. Validate … “No problems were detected.”

Sweet.

Leave a Comment » | Software | Tagged: Eclipse, Launch configuration, Startup | Permalink
Posted by digulla