compromised via blind SQL injection (!)

April 13, 2011 1 comment (the official site for the MySQL database) was compromised via (shocking!) blind SQL injection. A post sent today to the full disclosure list explaining the issue and dumping part of their internal database structure.

Vulnerable Target :
Host IP :
Web Server : Apache/2.2.15 (Fedora)
Powered-by : PHP/5.2.13
Injection Type : MySQL Blind
Current DB : web
It seems their customer view application was used as the entry point. This is where the attackers were able to list the internal databases, tables and password dump. If you have an account on, we recommend changing your passwords ASAP (especially if you like to reuse them across multiple sites).

What is worse is that they also posted the password dump online and some people started to crack it already. Some of the findings are pretty bad, like the password used by MySQL’s Director of Product Management, it is only 4 numbers long. Multiple admin passwords for were also posted.

The folks at MySQL have yet to say anything about this attack, but we will post more details as we learn more about it.

Categories: IT News

Leave comments, earn aQuote!

April 12, 2011 Leave a comment

aQuoteLeave comments to our blogs, adding some contact info and we will give to ten of you free promotional codes of the “aQuote” app!

For more information about the “aQuote” app visit the official blog at

aQuote’s blog

Categories: Promotion

Amazon’s profits are small publishers’ losses

April 11, 2011 Leave a comment

Each time Linen Press sells a book through Amazon, it costs the company more than £2

Linen Press, my imprint, is probably the smallest independent publisher in the UK, dwarfed by giants like Macmillan with their multiple imprints and worldwide sales. I publish four or five books a year by women writers. I’m not interested in celebs or footballers or chefs. I’m looking for beautifully-crafted writing, hidden and minority voices and bold experiments. From the slush pile, I pick manuscripts that show unusual promise but need so much editing that they stand no chance of instant acceptance by the big publishers.

So why do I groan when an order for a Linen Press book comes in from Amazon?
I should be grateful that I’ve been given the same space as the big boys to display my covers and my reviews. I should say thank you for the sale. But I don’t. Because each time I sell a book on Amazon, I lose money.
Amazon don’t tell their customers how much they take from a small publisher like me, nor do they advertise the fact that I have to pay the postage on the books sent to them.
Linen Press books cost £4 a copy to produce, for several reasons. Firstly, because the small print runs of 1,000 books that I commission aren’t cost-effective. Secondly, because I want to produce books that are visually stunning and pay a brilliant designer to do that. And thirdly because I pay a better-than-average copy editor, because if you skimp at this stage, you end up with typos and a bad reputation. Linen Press produces classy books; anything less would be a compromise. I have just published three novels about colonialism by Nigerian, Indian and British authors. I’m gambling on unknown writers here, so this venture is a financial risk before I even get to the Amazon sales. The books are big in every sense of the word. The RRP is £11.99. The postage is £2.50. On my website I sell the books for £8.99, so I’m not ripping you off; I’m just trying to persuade you not to buy from Amazon.

Here are the scary sums:
Amazon takes 60% of my RRP (in the book trade, the bigger the sales outfit, the bigger the discount they demand from the publisher: Amazon 60%; Waterstones 50%; independent bookshop 35%). On a £11.99 book, Amazon’s takings are££7.20. Mine are £4.80.
Out of this comes £2.50 to pack and post the book to Amazon, and the author’s royalties on a heavily discounted book reduced to 50p. My writers lose out on an Amazon sale, too. That leaves 82p for Linen Press, but the book cost £4 to produce. So I lose £2.18 on every sale by Amazon.

Of course, the big publishers can produce their books much more cheaply because they print them in their thousands, and have in-house design and PR staff. They can afford those coveted places on the piled-high tables and the 3-for-2 deals at Waterstone’s. I can’t.

For all its vast catalogue, Amazon’s market domination is is actually reducing choice by squeezing out publishers small publishers who are prepared to take risks.

I avoid looking into the abyss of financial disaster. I’m trying to remain upbeat. If Linen Press lands a bestseller that is reprinted and wins the Orange prize and sells in thousands and is translated into several languages and is made into a Hollywood film with Kiera Knightley and Colin Firth …

But the best I can hope for, realistically, is a mixture of Amazon, bookshop and website sales with Linen Press just scraping by for another year with modest debts.

Categories: E-commerce

Book Review : The Mythical Man Month

April 9, 2011 Leave a comment

The Mythical Man Month and Other Essays on Software Engineering is another true classic book by Frederick P. Brooks in software engineering and software project management. It documents some of the common pitfalls in software development. The technologies mentioned in the book might be obsolete but the lessons are not. The book was first published in 1975 with a second anniversary edition in 1995. It is required reading in many software engineering and computer science university courses. The title comes from the incorrect assumption that men and months are interchangeable. The No silver bullet chapter is also as relevant today as ever.

Excellent value for money and good fun to read. Also a good present for your team leader/project manager 🙂

The Mythical Man Month and Other Essays on Software Engineering

Categories: Book Review

Commodore 64 lives again!

April 9, 2011 Leave a comment

The C64, a legend of the 8bit era, is set to return – with brand new insides!

It was one of the most successful home computers of the eighties and now it’s making an unlikely comeback. A new version of the Commodore 64 is set to be released this summer, featuring entirely modern innards including a 1.8ghz dual-core Intel Atom D525 processor, Nvidia Ion 2 graphics chipset, 2 GB of DDR3 memory and your choice of a DVD or Blu-ray drive.

Best of all, the revived machine will feature exactly the same design as its 8bit predecessor, right down to the beige body and chunky keyboard (you can see more images on the Commodore USA Facebook page). The old cartridge port and joystick interfaces will be gone, though, replaced with HDMI and USB connections. Users will also be able to install Windows 7, although the machine will ship with Linux and will eventually get its own Commodore OS 1.0, complete with an emulator to play classic C64 titles. The new device is apparently on sale now, and orders are being taken at the price of $595 (£364), although at the moment, the company’s website seems to be struggling to cope with the amount of interest a PC in a brown plastic box is generating.

Although the original Commodore Business Machines declared bankruptcy in 1994, the brand has passed through a number of hands in the subsequent years. It is now jointly shared by the creator of the new C64, Commodore USA, as well as Commodore Holdings and Commodore Gaming, which builds high-spec PCs.

But the big question is, which classic C64 titles should be updated along with the machine?

Categories: IT News

Why we all sell code with bugs

April 7, 2011 Leave a comment

Creating quality software products means knowing when to fix bugs and when to leave well alone, writes Eric Sin.

The world’s six billion people can be divided into two groups: group one, who know why every good software company ships products with known bugs; and group two, who don’t. Those in group 1 tend to forget what life was like before our youthful optimism was spoiled by reality. Sometimes we encounter a person in group two, a new hire on the team or a customer, who is shocked that any software company would ship a product before every last bug is fixed.

Every time Microsoft releases a version of Windows, stories are written about how the open bug count is a five-digit number. People in group two find that interesting. But if you are a software developer, you need to get into group one, where I am. Why would an independent software vendor – like SourceGear – release a product with known bugs? There are several reasons:

· We care about quality so deeply that we know how to decide which bugs are acceptable and which ones are not.

· It is better to ship a product with a known quality level than to ship a product full of surprises.

· The alternative is to fix them and risk introducing worse bugs.

All the reasons are tied up in one truth: every time you fix a bug, you risk introducing another. Don’t we all start out with the belief that software only gets better as we work on it? Nobody on our team intentionally creates new bugs. Yet we have done accidentally.

Risky changes

Every code change is a risk. If you don’t recognise this you will never create a shippable product. At some point, you have to decide which bugs aren’t going to be fixed.

Think about what we want to say to ourselves just after our product is released. The people in group two want to say: “Our bug database has zero open items. We didn’t defer a single bug.”

The group 1 person wants to say: “Our bug database has lots of open items. We have reviewed every one and consider each to be acceptable. We are not ashamed of this list. On the contrary, we draw confidence because we are shipping a product with a quality that is well known. We admit our product would be even better if all these items were ‘fixed’, but fixing them would risk introducing new bugs.”

I’m not suggesting anybody should ship products of low quality. But decisions about software quality can be tough and subtle.

There are four questions to ask about every bug. The first two are customer ones, and the next two are developer ones.

1) How bad is its impact? (Severity)

2) How often does it happen? (Frequency)

3) How much effort is required to fix it? (Cost)

4) What is the risk of fixing it? (Risk)

I like to visualise the first two plotted on a 2D graph, with severity on the vertical axis. The top of the graph is a bug with extreme impact (“the user’s computer bursts into flames”) and the bottom one has very low impact (“one splash screen pixel is the wrong shade of grey”).

The horizontal axis is frequency: on the right side is a bug that happens very often (“the user sees this each day”) and on the left, one that seldom happens.

Broadly speaking, stuff gets more important as you move up or to the right of the graph. A bug in the upper right should be fixed. A bug in the lower left should not. Sometimes I draw this graph on a whiteboard when arguing for or against a bug.

Questions three and four are about the tradeoffs involved in fixing the bug. The answers can only ever make the priority of a bug go down – never up. If, after answering questions one and two, a bug does not deserve attention, skip the other two. A common mistake is to use question three to justify fixing a bug that isn’t important. We never make unimportant code changes just because they’re easy.

Every code change has a cost and a risk. Bad decisions happen when people make code changes ignoring these two issues.

For instance, our product, Vault, stores all data using Microsoft SQL Server. Some people don’t like this. We’ve been asked to port the back end to Oracle, PostgreSQL, MySQL and Firebird. This issue is in our bug database as item 6740. The four questions would look like this:

· Severity: People who refuse to use SQL Server can’t use Vault.

· Frequency: This “bug” affects none of our users; it merely prevents a group of people from using our product.

· Cost: Very high. Vault’s backend makes extensive use of features specific to Microsoft SQL Server. Contrary to popular belief, SQL isn’t portable. Adapting the backend for any other database would take months, and the maintenance costs of two back ends would be quite high.

· Risk: The primary risk lies in any code changes made to the server to enable it to speak to different backend implementations of the underlying SQL store.

Obviously, this is more of a feature request than a bug.

Example: Item 10016. Linux and MacOS users have problems over how end-of-line terminators show up. Last October, we tried to fix this and accidentally introduced a nastier bug that prevented users creating new versions of a project. So the four questions for 10016 would look like this:

· Severity: For a certain class of users, this bug is a showstopper. It does not threaten data integrity, but makes Vault unusable.

· Frequency: This bug only affects users on non-Windows platforms, a rather small percentage of our user base.

· Cost: The code change is small and appears simple.

· Risk: We thought – wrongly – that the risk was low.

If testing had told us that the risk was higher than we thought, we would have revisited the four questions. Because the frequency is relatively low, we might have decided to defer this fix until we figured out how to do it without breaking things. In fact, that’s what we ended up doing: we “undid” the fix for Bug 10016 in a minor update to Vault, so it’s now open again.

Contextual understanding

Not only do you have to answer the four questions, you have to answer them with a good understanding of the context in which you are doing business. You need to understand the quality expectations of your market segment and what the market window is for your product. We can ship products with “bugs” because there are some that customers will accept.

I know what you want, and I want it too: a way to make these decisions easy. I want an algorithm with simple inputs to tell me which bugs I should fix and in what order.

I want to implement this algorithm as a feature in our bug-tracking product. Wouldn’t it be a killer feature? In the Project Settings dialog, the user would enter a numeric value for “Market Quality Expectations” and a schedule for the closing of the “Market Window”. For every bug, the user would enter numeric values for severity, frequency, cost and risk. The Priority field for each bug would be automatically calculated. Sort the list on Priority descending and you see the order in which bugs should be fixed. The ones near the bottom should not be fixed at all.

I’d probably even patent this algorithm even though, in principle, I believe software patents are fundamentally evil.

Alas, this ethical quandary is not going to happen, as “Eric’s Magic Bug Priority Algorithm” will never exist. There is no shortcut. Understand your context, ask all four questions and use your judgment.

Experienced developers can usually make these decisions quickly. It only takes a few seconds mentally to process the four questions. In tougher cases, gather two co-workers near a whiteboard and the right answer will probably show up soon.

Categories: Theory

Image to Text

April 6, 2011 Leave a comment

A picture is worth a thousand words, which means that it is some tens of thousands characters! That’s exactly what image to ascii tools do. Back to the early ages of computers, it was a way to create simple graphics using the available textual characters. It was an art, but know it is a technique that it is implemented from the

Categories: Uncategorized