Straight, simple, question: how many people would like to try out a GNOME Shell Live distro?

They say that’s the next-big-thing(tm). Do you agree?

Anyway, there are a lot of things boiling  in my pot, some I’ll start blogging about in the next days, others are expected to be ready to be eaten before the end of September: Sabayon 5.4, Entropy improvements, Molecule features.

While the Sabayon project is constantly looking for new developers and people joining our devel mailing list, I am at the same time looking for new customers!

In one hand, you have the need of making your code fast enough. Which task is even more complex if you are using an interpreted language (for reasons out of the scope of this blog post). On the other hand (:D) there is the very important requirement of keeping your code human readable.
Languages, in general, have several “syntax levels” basing on developer’s skills. Newbies tend to stick to what is the standard way of writing, say, a for loop, while more skilled people are able to exploit all the potential of the language by using very exotic “code constructs”. Again, I don’t want to get into any particular language here, I just want to explain the trade-off that a developer, especially a FLOSS one has to accept when writing software.

It’s obvious that the two things, performance and readability, don’t play nice together. And the former, causes wannabe-developers to have hard times understanding how a particular function works. The worst case here is that the same developers will give up ahead of time. This is one of the reasons why the faster and more complex a codebase is, the harder is to start contributing to it.

There are two reasons that bring developer to choose performance over readability anyway: the former brings them an orgasming sensation of owning the whole World. And writing obfuscated code is just another way to tell the world how c00l someone is (l33t). Unfortunately, most of the times people doing that are right. Because it’s the only way to get applications working without annoying users with high wait times.

“In a perfect world, there wouldn’t be no need for caching”. Myself.

Yes, caching is a perfect example of the trade off between readability and performance. Caching a particular data retrieval code, increases its complexity, by the need of validating, tainting, generating, removing, (etc), cached data.

Many of us do FLOSS coding for the ultimate glory of just doing it. Learning, filling empty days with something to do or simply because we need to feel important for somebody else (I’m pointing the finger to you, behated [my opposite of beloved] library developers).
A rainy Sunday is still a rainy Sunday, and most of us find the couch and afternoon naps quite boring.

Here comes the problem. Developer Joe has a boring afternoon to fill, so he starts thinking about how to improve the API of his library that, accidentally, hundred of thousands users are happily using and find fine as it is.

He starts coding and messing with it and, since he’s a free mind, he doesn’t have to respect any API deprecation rules that most companies (for example) have in place for morons like him. Of course, there is no roadmap, Joe just woke up in the morning and decided to change everything. He also has the excuse that he’s not paid and doesn’t give a fuck about supporting users. He just wants to show how good he can be writing code (hoping to get hired by Google, IBM or Oracle — thank god the guy [Developer Joe is a creation of mine] knows ubuntards and doesn’t expect Canonical to hire him after a mission-impossible phone interview where the hardest task was trying to figure out what the interviewer was about to say).

So, it happens that a small change in the API, causes a small change in the ABI, that eventually, causes its shared object name to get bumped from libjoe.so.1 to libjoe.so.2. The little tiny small invisible change Joe did, for sake of speed and architectural cleanliness (OF COURSE! IT HAD TO BE DONE (sarcasm)) breaks other 35 applications and in general around 425 shared objects that were linking against it, requiring their developers to understand what Joe did, voiding all the testing their applications got until now and eventually+hopefully making the program working again with the new libjoe, spending the next two weekends (oh, they don’t have anything else to do, too).

It’s a perverse game that will never stop.

What’s the moral? Unknown people will indirectly break your application someday, and it’s not a security flaw, it’s just because they were getting bored.
Any solution? Yes, don’t use lame fuck people’s libraries.

It seems that my previous blog post caught the interest of many readers, so I’ll try to continue to blog about coding quality and best practices and, consequently about QA in software engineering. Please don’t take what I write personally, I have a strong sense of homour (humor — for American readers) after all.

At the same time, I kindly ask people emailing me to be patient, I’ll answer you in 48/72 hours, and not immediately, during my vacation. This is vacation DAY 0, and it’s rainy outside, yay! (/sarcasm)

A few months ago I had to study a programming language that is a failure itself (besides it’s the best of them, probably the most modern one): OCaml. There is some coolness in it, but it’s still a functional programming language, so it really sucks nowadays, and don’t tell me the fairytale about automatic unit testing and crap like that, it’s just bullshit (sorry for being so rude).

So, why am I talking about all this? Simple, when I code using Python or C/C++, I take advantage of the fact that I can pass pointers to functions across functions themselves (as arguments). Well, every time I do that, I end up with an odd feeling: is my code readable? Is my code getting closer to spaghetti style? Unfortunately yes. Being able to pass functions across stack frames is cool and very handy at a first sight, but you’re going to pay the consequences in the long run, because your code will become harder to read and to maintain.

So please, use the mantra in subject with caution, in an event-driven model, passing callbacks over is good and generally accepted, any other use of it, in non-functional programming, is just very bad.

My today’s coding quality pill ends here. More will come about that. As you may have seen, I don’t want (for now) to get too much technical, I leave the exercise to you.

Out-of-bound accesses to memory is the easiest way to buffer overflow exploits, think about NULL terminated array of chars (which represents a string in C), what happens if your logic doesn’t stop at the 0×00 (blame wordpress) element? If you know a little bit about how the “C function call convention” works low level (in ASM code) you would realize that writing stuff outside variables boundaries causes indefinite results, one of those is rewriting the return address of the function, which is saved on the stack along with other information (such as local variables and function arguments, which are local variables too).

Theoretically this is not possible with higher level languages that do memory bounds checking or on systems where some exotic technique is used to mitigate the issue. Well, anything the computer runs is at some point, ASM code (which turns to be a simple mapping between a mnemonical string and a bunch of nonsensical (:D) bits). So what you’re doing is just moving the matter down the queue, which means trusting your high level language interpreter. If a security flaw is discovered in say, Python or Java, this can potentially affect any application using the given language.

I do agree that this is much better, from an engineering POV, because the issue is limited to a single piece of code, to a library rather than to several potential spots in your application.
Anyway, this is not really the point of my today’s blog post and I apologize for this. The point here is: using memory and type safe languages doesn’t cover you from as dangerous as the ones above bugs. File access race condition (TOCTOU), unsafe temporary files creation, weak input validation, XSS, SQL injection, taint propagation issues. So, if your software has to guarantee a certain security level, or if you take privacy to hearth, or you just have to run it inside a privileged environment (or with privileged permissions). Just think about all this twice, and start doing a security review of your code.