Bored with your GNOME looks?

If you are a GNOME user, uou can do a lot worse than using the Humanoid-Dark-OSX theme.

What is astounding is that even if you consciously try NOT to emulate OSX on your GNOME desktop, it still works

Get it here.

When you have a hammer all programming problems look like nails …

A little while ago I blogged about my experiences with the Ruby programming language. I got an email, which I believe raises some valid points (and of course adds a couple more points why you should learn Ruby, which obviously is a Good Thing TM). But before we start, please take a look at the following Paul Graham articles, as he expresses some of my points in a much much more eloquent way.

The Python Paradox

Beating the Averages

Without further ado, let’s see what the reader cared to comment:

One of the reasons people should learn less mainstream languages, such as SmallTalk, Lisp, Haskell and so on is so that they can recognize limitations and capabilities of current mainstream languages. There’s not that much new in Ruby, nor in C#.

I wholeheartedly agree. Although the Amiga Persecution Complex can be quite prevalent (as in “Why we are not programming in Objective-C, after all John Carmack (who shares the same initials as Jesus Christ and when it comes to programming he is probably more important stated that it was his favourite programming language)”?), spending some time and doing some archeology can pay off significant dividends, especially from the fields of functional programming and whatnot, areas that are usually associated with academia and all the false connotations that come with it. So dust-off that Ocaml book today.
Because they never took the time to learn other languages besides mainstream ones, they don’t understand what the fuss is about and dismiss it as open source zealotry.

Here is a point that I wholeheartedly agree. It is quite funny seeing languages such as C# trying to incorporate features (or to put it more colloquially “tack-on”) that have been doing the rounds for years in some not-so-leftfield languages. So, more often than not, a couple of language revisions down the road, they end up using features that were chastising in the first place. Additionally, a pattern that is often observed is that due to lack of exposure to different technologies, they can be sitting at a gold mine and not realizing that ;).

They also don’t understand the power of an open community working around programming tools because they have never experienced it… I like my languages to come with code, a real community and to run everywhere, thank you!

Amen and write back soon!

Get FLACed!

I usually do not brag about personal possessions but I bought some high-end headphones and courtecy of some flac encoding later, i was re-enjoying some of my best tracks in a totally new way (like ive been hearing it from some crappy tapes and mp3s)…

Get FLACed!

Isn’t it great …

… when “leaked” exploit source code is

• Cleanly formatted, following a clean proper coding style, proper variable naming conventions, the works
• Properly commented, including “THIS IS PROPRIETARY SOURCE CODE OF JIMBOB HACKING CREW”
• Has a comprehensive listing of members, often including email addresses etc
• (last but not least), the word “PRIVATE” are repeated every 10 lines or so ….

More on the hypocrisy of Information Security to come … Perhaps making fun of the script kids and the fame seekers is an easy target. So, for the next “Isn’t it …” line of posts, we will be making fun of our friends, the IT security industry (to use a cliche, “modern age snake oil merchants”. And yes, it will be a “name and shame” game, so keep watching this space.

Don’t you just love it ….

When zines and tutorials continue to ignore what has been going on for the past three years or so. and still repackage “smashing the stack for fun and profit” from like 2 gens ago?

The Shock Rockers of the IT Security Industry

Shock Rock: borderline musical idiom. The performers usually play something relatively extreme as compared to the mainstream of the contemporary music. The main stimuli is visual, as shown in the various acts live performances (or “shows”). Usually, the music is not that good and most of these bands prove to be nothing more than a one trick pony. The amount of shocking acts in public permitted by law is deterministic, the genre is quite unpopular now as most of what is to be seen has been shown already back in the 80s. “How is this related to the IT Security industry?”, the astute reader might remark?

Today I had the dubious pleasure to use a port scanner made by a known security company. I will give no names but trust me you have heard this one and maybe bought a book from them or two. It is your typical win32 software, version X.Y, with X being much much greater to 1 (therefore, been revised and improved with every iteration. Running a portscan towards a firewalled VM, it reported filtered ports as open, while nmap was displaying them as closed or filtered. At first I thought that there was something wrong with my firewall configuration. Upon further investigation, when the tool was trying to make a simple connect() scan, reporting timed out ports (-j DENY) as open.

If you are familiar with Bruce Schneier, in his “Secrets and Lies” book, introduces the “snake oil” merchants. Unfortunately, even with a slightly more security educated IT community, frauds like them described in the book can often be encountered in the field. Like our pals from [CENSORED]. Hey guys, is it too much to ask that your connect() portscanner (with a version greater than 1, mind you) at least expects the presence of a firewall someplace? I am sure that quite a lot of pimping goes into your books, I would not know. I have bought one of your books back in 2001 something and it was a terrible waste of money and time. To cut a long story short, you have a bunch of clueless posers with a good PR department charging the hell outta their clients and presenting themselves as authorities within the IT security industry. Unfortunately, the shock rock effect of their material, the overestimation of how “them pesky hackers are out there to get YOU“, soon will wear off and those morons will be exposed for the frauds they are.

Happy Birthday Lixtetrax

Looks like the idea to separate the blogs payed off! I have the other usual place for personal stuff and this one for thins a bit more techie (says on the tin).

So, a year and some change, how does it looks? Well, generally there are the cash-cow posts (that get linked from the craziest of places), a couple of big-hit for a day or so wonders and the rest stay relatively obscure.

So, lixtetrax is not going away anytine soon. At first I was a bit disappointed with the lack of traffic and comments but slowly, persistence paid off.

What is the aim of this blog? Is it to make a book out of it? Is it to pimp my trade? Is it going to be just an RSS aggregator with a couple of lines here and there?

NO!

It will stay about as it is now, a bit longer piece in long irregular intervals. Having a target of say X posts per week, is not applicable in our example. Quality over quantity.

Bugs / KLOC ratio is useless (OR How to avoid snake oil merchants)

For the past few months, there is a lot of talk about software security metrics, even a book is out One very common metric is the identified bug per (kilo, mega, whatever is applicable to the size of your code base) lines of code. This method is seriously flawed. Why the astute reader may ask? Let’s demonstrate by example. Consider the following (rather contrived) C snippet

/* for the sake of argument let's assume that msg is controlled by the user and is gotten securely */

printf(msg);

/* ... rest of the program ... */

/* then someplace after our evil printf call */

printf(msg);

So Mr. Johnny Security Consultant gets a fat fee to run his favorite static analysis tool. The tool correctly states that there are two format string bugs. If the program is 100 lines of code, then we get a bug/LOC ratio of  0.02. Each of this bug might potentially lead to a complete application compromise.

Mrs Jane Outsourcer then steps in and does a bit of refactoring

/* this is contrived but it does demonstrate the point */

void myprintf(char *msg) {

printf(msg);

}

/* a bit within main() */

myprintf(msg);

/* a bit later in the code */

myprintf(msg);

Johnny charges yet again his fat fee and is happy to write in his report that the application now contains only one critical bug and the ratio has drop to 0.01.

Is the application any safer? No!

Is it easier to fix? In our example, perhaps.

Will a run of the mill static analysis tool fail to state that the application has still two vulnerable points? Yes

Using pure bugs/LOC can lull the development team into a false sense of security, especially if the program is not something trivial like the one above. Software security is a weakest link model, an application containing one critical vulnerability is not safer than one containing ten critical vulnerabilities.

So next time someone tries to sell you some software and spouts some statistics in your face, you will have a counterpoint.

Two war stories to show that the Greek IT market is doomed

(a quick intro: when I read this one, I really had to post about it)

War Story #1:

Navigate here

Check the prices for India. Check the cost of life in India. Check the average market rate for a Greek IT developer. Check the difference between cost of life in India and in Greece. QED

(yeap, I know that the prices quoted there include man in the middle fees, but still it looks pretty grim).

War Story #2:

Talking to a friend, he confided that once his company was needing to buy a software costing appx. 120K for a 5 seat license. The software vendor did a ROI analysis. When they got informed about the cost of developers, they exclaimed “Wow, Greece is cheaper than India!”.

So, dear IT managers. You do not pay well. In fact, you pay a bit better than India. You demand unpaid overtime. Don’t be alarmed when all the guys worth their salt either move out of the Greek job market or get snatched by the major players. Also, don’t be alarmed when you see that given your current skill field, you cannot get any innovative or highly paid projects, been stuck to the good ole fetch the data from backend, format it and present it $2000 t best projects. And for the love of God, don’t be alarmed when your company will die in a few years or become a “mpakaliko”.

Why constant overtime is bad for your IT company

(Some meta-info: after all these technical articles, I have decided to take a sidestep into the managerial aspect of things.)

Some managers still go by the good old “if you make your personnel work overtime, all the time, you will finish sooner”. By the same account, some people still believe that the Earth is not round. The overtime will eventually kill your company and here is why I believe so:

• People have lives. Even if you insist on hiring ambitious, single persons, they will be quickly fed up with it. If the employees have a family, you can forget about them.
• If you pay overtime, the costs mount. If you do not (legally) pay overtime, the personnel will soon feel ripped off (as in “Hey, those 4 extra hours a day kinda halve my paycheck”). If you do not pay overtime (the illegal version of it), you might have (and IMHO, you should) legal trouble.
• IT work is not like an assembly line. If you force a person to work say 12 hours a day, it does not mean that he will perform 24 man-hour work in 2 workdays. Chances are that overall fixes that will be required, will take a lot more than the extra day the poor fella “saved” your company.
• Even if the pay is good, persons will quickly fed up. After all, what use are money if you do not get to enjoy them? Even if they stick to it in a “come on, two more months of this and I get the new car”, trust me, they will leave, which leads us to…
• High turnaround. If your people are fed up with you and they have a relatively up to date skillset, prepare to say “Buh-bye” to them. Once a competitor approaches them with reasonable terms, off he goes one person who might know more for your day to day operations than your average middle manager.
• Speaking of managers, constant overtime is a sign of bad management. Even if you choose to ignore the above, if your sales people have no input from the workforce and systematically underestimate the time that is required for a given project, is bad management. If your managers have the slave-driver mentality, it is bad management. “Lowballing” projects is bad management. Hire an extra guy, even a Jr one will take some load off the other persons.
• If you still require overtime, then do the world a favor. Fire all your managers and hire competent ones. If something cannot be done in a normal 40 workweek but needs to be done within a week, you’re out of luck. Perhaps you will get away with it a few times but when you will not, it will hurt.
• While you are at it, why don’t you go ahead and fire some of the HR people? A stick in the mud (or a dick in the team) will hurt your productivity. Hiring only “cheap” persons will not save you money, as it is more likely than not that they will stall and waste time.
• 8 hours of work are usually enough for most day to day operations. Instead of asking people to work more hours, try to implement some in-house productivity measurement and have people work more those 8 hours instead. Try to identify problems in your processes and performance bottlenecks and eliminate them ASAP.
• [edit] If people do not have the time to do their own research (you did bother to hire people that do at least a bit of research in their own time, don’t you?) soon they will stagnate. OJT can only get your people so far, a bit of extra boost is needed. And yeah, if your people are working 50 hour workweeks, you can’t seriously expect them to devote hours in the weekend.

Fortunately, while I have faced most of the above, I do not have to face them now so I consider myself lucky. This is not the case with everyone and while this is no Joel’s, read it