Shortest Horror Joke Just Got Shorter

20. February, 2017

Previously, it was

The last human sits in front of his fireplace. Suddenly, there is a knock on the door.

Now, it’s

Trump says.


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.


Learning Resources

12. February, 2012

Always wanted to brush up your knowledge of quantum physics? Geometry? Linear algebra?

There are two cool resources for you:

If you’re more interested in computer science (theory, operating systems, networks, distributed computing), visit udacity.

For more general topics, go to Khan Academy.

Both are YouTube based services which kind of follow school: You get a video with a presentation about a topic. Both sites then offer additional material, Q&A forums, etc.


One Step Closer to Levitation

20. October, 2011

Everyone has seen the floating-frozen-thingy-over-a-magnet, right?

There have been miniature train models running over simple or more complicated tracks.

This one is slightly different: The configuration allows to adjust the angle and height of the object:

(Source: WIN blog)


Do You Know Your Limits?

17. October, 2011

This interesting talk by Dan Ariely – Are we in control of our own decisions? – got my thinking. Dan says:

We understand our limitations. And we build around it. But for some reason when it comes to the mental world, when we design things like healthcare and retirement and stockmarkets, we somehow forget the idea that we are limited. I think that if we understood our cognitive limitations in the same way that we understand our physical limitations, even though they don’t stare us in the face in the same way, we could design a better world.

(my italics)

I think that is a very important point. Software development is a purely mental process. We take ideas, translate them into code. We’re authors, our audience is a CPU. We write in RAM chips instead of on paper. But basically, we’re translators.

Most software developers know their tools but not their own mental limits. Ask yourself: How much brain power does it take to type on a keyboard? Got your number?

It’s about 30%. When you type yourself, you only have 70% of your brain left to think what you’re typing.

Software development is a craft but it’s not like smithery. We had anvils and fire pits at my school. When you work with yellow-hot glowing steel, a five-pound hammer and an anvil, you learn something with your first strike: This is dangerous, this is hard work, this isn’t as simple as it looks, and how fast you’re going to tire.

How do you do that? Because your brain is wired by millions of years of evolution to know such things. Your muscles are designed to give you feedback: Can I outrun my enemy or do I have to make a stand? Forging steel is built into us. The result will vary with clumsiness but every person in my class was able to hit the steel with a hammer. It takes a day to teach someone to write the most simple program in Java but it takes one sentence to teach them how to flatten iron: “Take one of those hammers and hit it here.”

If driving steel is so simple, why are we so bad at software development?

Well, it’s one of those tasks where one brain tries to achieve two conflicting goals: Write software and at the same time watch itself doing it right. It’s a dilemma. You have 70% tops unless you have trouble at home, worry for your job, are hungry or mad at the guy next door yelling in his telephone. How much of the 70% are you going to give to “write software” and how much to “do it right”?

That said, being a software developer, you’re male (98% chance). Males suck at doing two things at a time and you’re already doing at least two. How much good is adding control to the pile going to do?

Probably not much. So what can you do?

First: Don’t forget that you’re limited. Clear your brain. Heed your limits.

Second: Turn your limits into a foundation. Instead of struggling with them, accept them. Use techniques like Test Driven Development to do one thing at a time: Tests answer the “do it right?” part. When you have the test, you can forget about this and go the “write software” part.

Use you limits. They are tools just like everything else.


Another Reason Against Copyright

10. September, 2011

The EU is about to extend the duration of the copyright for music from 50 to 70 years.

That means recordings (not the music, only the original tapes and records) of the Beatles, Elvis, etc. will generate revenue for another 20 years. Who gets that revenue? The “Big Four”: EMI, Sony Music, Universal Music and Warner Music (72%). Then 24% goes to rich, already established artists like The Rolling Stones, which make up about 20% of all artists. The rest (80%) get 4%.

Revolutions don’t start because people are hungry, they start because there is enough for everyone but most people are starving and they are fed up with a greedy few.

Source:


Patent Trolls vs Common Sense 1:0 Again

11. June, 2011

Microsoft failed in court to relax the rules under which existing IT patents can be challenged. A great loss for everyone, even those who like the status quo.

Remember: i4i (is that “eye for an eye”?) owns patent 5,787,449: “A system and method for the separate manipulation of the architecture and content of a document, particularly for data representation and transformations.”

While the first sentence screams XML, it’s actually about a way to save additional data along with an XML document. Microsoft Word allows you to include any other file in the document, hence they violate the patent. Here is a good analysis.

This doesn’t mean anyone using XML is now prone to a lawsuit by i4i, but it’s still bad news. Why?

The parent was granted in 1998. In the very same year, the XML 1.0 standard was created (see here). This is just an example but patents are filed when the world starts to explore the very same field, obviously. We haven’t seen patents for combustion engines in 1603. And no patent office is going to accept patents for intergalactic FTL drives today.

Patents are filed to protect the investments of big companies. The pharmaceutical industry has to spend many million dollars to create a new medicine. Everything else has already been invents, so only the complex == expensive stuff is left. On this scale, it makes sense to generate billions in revenue since that’s about only one to ten thousand times what you invested. And you make that over many years.

IT is different. While the idea to store additional information along with a document might have been novel in 1998, it’s completely obvious today. The investment of i4i was probably on the scale of a few thousand dollars. Now, they made $290 million just by suing Microsoft.

My gut feeling is that they abuse the system. Pharmaceutical companies take great risks, i4i didn’t. i4i doesn’t sue everyone, they sue the big money. It’s perfectly legal. But is it right?

Here in Germany, we have the term of “Rechtsfrieden” which means “peace of law.” People believe and follow the law because it appears to be just. Violating the peace of law means that someone uses perfectly legal ways to harass someone. Think of a lawyer who got dumped by his girlfriend and now uses all the tiny transgressions we all do to turn her live into hell. She parks where she shouldn’t, he send a photo to the police. She drives a bit too fast, another fine. Talking with her mobile on the wheel. Telling people that she is a serial offender but no details, lest he could get into trouble. This behavior creates the impression on other people that the law can easily be used against them. The trust that the law needs to be efficient is undermined.

From my point of view, patent trolls violate the peace of law. They invest little and try to milk society. The damage is much bigger than the $290 million fine. M$ had to withdraw an entire production of Office products, they had to pay a fortune in lawyer fees, and now every software company using a similar technology is under even more stress than before: i4i just got the money to drive anyone out of business. Because today, almost every software company uses technology like that. It’s so obvious today that no one would even think that there might be a patent for it.

And that’s the fundamental problems around software patents: They don’t make sense on any level.

Other industries have to invest millions of dollars in equipment and thousands of people (in the field, lab workers, people building lab equipment, test subjects) and procedures (clinical or other tests, legal reviews, patent research) to develop new products. Actually producing those products is expensive: You need workers, factories, raw material. And then, you haven’t sold a single unit. So you need transportation, packaging, hygiene environments, storage, advertising, sales points, etc.

To bring a new medicine to market, you need one billion dollars today. That is a huge risk. While I don’t like patents, I can understand that you want all the protection you can get in this case.

Software patents are dirt cheap by comparison. Usually, it takes just one person to have the idea. You need equipment that costs a couple of thousand dollars. Even 1998, computers usually cost less than $10’000. Developing the idea to a real patent is in the same range. You don’t need expensive equipment for that, just determination and a good patent lawyer.

Basically, there is no risk in developing a software patent. If the patent is found void, you also don’t lose much. It doesn’t mean your investment is lost. It doesn’t mean your multi-million dollar factory is ripe for an unexpected amortization. It doesn’t bankrupt you.

On the other hand, a software patent is a great tool to harm society, 100% legal. That $290 million isn’t coming out of the pockets of Microsoft, it’s ultimately coming out of the pockets of their customers. The fine doesn’t benefit society, it goes to the owners of i4i. And rich people don’t share.

The judges in the M$ vs. i4i case argued that the government should set the rules. Which sounds good. But apparently, the members of parliament also don’t understand that we have two completely different sets of problems. When biochemical companies argue pro patents, they ignore the fact that one size only fits all when everyone is the same size.

Conclusion: In my opinion, i4i legally “swiped” $290 million from society. Which is a perfect argument to treat software patents completely different from normal patents.