Okay, okay, the pun is bad. But still. If you managed to enter Google Plus, and was a user of Google Wave before, the similarities are insanely obvious. And I'm pretty sure I understand better now what happened to Google Wave.

In one of my previous entries, I ranted about how Google let Wave died. But I was wrong. They didn't let it die, they had an internal struggle within Google about where to go and what to do.

I'm pretty sure that was happened is the following: Google Wave was seen by some as the "new e-mail" standard, and they were trying to establish protocols and make it as open as possible so to let others to integrate with them, just as I described before, but others were seeing Google Wave as a good candidate for Google's social platform, given how they went to integrate a lot of social widgets into it, and how they tried to let it as closed-source as possible. And, yes, gmail being the second major Google product, why would they want to kill it ? But Orkut being a failure, they needed something to compete with Facebook.

So of course, these two conflicting ideas weren't possible. Which is why they "let Google Wave go", into the open, as an Apache project, so it may very well become the next e-mail platform. But internally, people continued working from the original Google Wave design, and pushed the social aspect even further. That project eventually became Google Plus. There's really no doubt about it: that is the vision some of the Googlers had when they saw Google Wave as a social network, and not as a communication platform. And quite frankly, it's great. I'm now grateful that they turned away from Google Wave, letting it grow outside of Google, and that they created Google Plus instead. This is a major, awesome upgrade from the Facebook+Twitter experience. It feels good and the sensation of control over your data is fantastic.

Good job Google, and good luck.

A few years ago, I remember posting very angry comments about Rani Assaf's "IPv6 is just a gadget" post. Not so long after, his company introduced IPv6 natively for their customers. A few days ago, the last /8 IPv4 blocs got allocated, marking the end of the IPv4 allocation. I guess it wasn't that much a gadget, huh ? Even though the IPv4 sub-allocation is pretty poor (only roughly 14% of the addressable space is actually in use, if I'm not mistaken), the increasing complexity of the addressing space really makes life difficult.

Without even talking about the fact that IPv4 has a lot of flaws that IPv6 natively corrects. I've heard various comments claiming that this isn't so bad, that solutions exist to still use IPv4 nontheless, etc. But I'm happy to see that things are still moving towards IPv6 in general, as even the Obama administration is in favor of IPv6.

Anyway, don't worry. This blog will continue to run even if you don't have IPv4 connectivity anymore: 

Yay!

One of the very first post I've made was talking about encryption, and how to fail it. Okay, that was a very easy encryption, but the base principles remain the same: don't be stupid, aka, know what you're doing. Well, I'm joining the bandwagon here, but it seems Sony's programmers didn't really try to understand their crypto handbook, and implemented it without really knowing what they were doing. As a result, all of the private keys for the PSP and the PS3 (including the one hardcoded in the CPU die) are leaking with simply two signatures made with them.

Good job, really.

Source: fail0verflow

As you may have heard, google is letting google wave going down. Now I know that there's already a lot of people who gave their analysis about this, but I'd like to voice a different way to put it.

I'd like to quickly talk about something that's really, really awful.

I just bought a Cybershot WX1 camera from Sony. The camera itself is very nice, very small, very fast, quite powerful, loaded with features, etc. Now have a look at the camera itself. Look at the way the flash and the lens are placed.

Now look at this picture. This is a picture I took in my room, of my wall, with the zoom at 1x, in complete dark, using the flash. Notice the black portion at the bottom left. This isn't the shadow of my finger or what. This is the shadow of the lens itself.

The Sony engineers who slapped together this piece of crap didn't even see that, when taking a picture with the flash on, the lens itself would interfere with the ray of light from the flash itself. To me it just means they haven't even tested the product. I mean, seriously ? How could you ship such a product without testing something as basic ? Or maybe they didn't care ? I don't know. I'm tempted to ask for a return for a "defective product", as this is obviously defective to me.

The title of this article is actually something I wrote on the corner of the whiteboard at work. We've recently had a few issues which all dealt with stack abuses. We added some instrumentation to help us, and I thought about sharing that a bit.

Here is a little trick that saved my life a few month back when I was dealing with a virtual pure function been called.

In a program I wrote, I had a very very rare bug where the code would crash in a completely improbable way. I finally figured out that it was due to abort() beeing called, and that was crashing the all other threads in random place. Now, where did that call come from was the big question. With one lucky crash dump, I was able to find that it was due to a virtual pure call, obviously due to a boggus cast.

By default, it seems that the virtual pure handler in gcc just call abort, making it hard to debug. The trick I used to find the actual bug was to override the default virtual pure handler:

extern "C" {

static int __cxa_pure_virtual() __attribute__((noinline, used));
static int __cxa_pure_virtual()
{
    assert(0);
    return 0;
}

}

That way, every time a virtual pure function will be called, it will assert instead of simply aborting, giving way more useful information about what's happening.

For the people who know me, this is just a repost of a very old article I wrote. I just think this is the perfect spot for it. I'm just changing the wording a bit, but this is essentially the same thing.

As I said during the opening post, Yazoo and I are quite into Reverse Engineering, which is usually called "Hacking". While this word is always causing some controversy, we claim to be on the right side of the line.

That being said, we still receive a lot of mail and queries so we can teach people how to hack, or shorter, so we can write some so-called tutorials. We always denied such requests. This article is attempting to explain why. The main, short-hand reason is "because any hacking tutorial can only be crap", but I hope that I can point to the full reasons why this methodology doesn't work at all. Don't read this as a real attempt to teach you how to hack, but as an attempt to explain why usual tutorials just can't work.

Picture the situation. You've just spent 2 days trying to figure out a bug that randomly crash your application. You've nailed it down to a memory corruption somewhere, and you finally find that it's due to an out of bound access to an array. A single little assert you have saved you hours of heavy debugging...

In my previous entry, I've been ranting about compiler bugs. I finally discovered that it's absolutely RedHat's fault. Their compiler is a bug pit of hell. I ran the latest gcc testsuite on it, and on Debian's compiler in order to compare. I've stopped after finding 15 bugs in the first batch of basic test, which is like one tenth of the whole list of tests. This is just not acceptable. RedHat's compiler is deliberately buggy, maybe for the sake of "Backward Compatibility", but that's bullshit, especially since we're always writing crossplatform code. We're expecting that a piece of code that compiles and runs fine on one platform would also compile and run fine on a similar one. Which isn't guaranteed by RedHat. I'm now officially boycotting RedHat. Don't use their compiler, and don't use their distribution, because it's compiled with this compiler as well, so you can't possibly trust it at all. Don't bother with RedHat, it's a waste of time and money.

For your interest, here's a list of all the basic gcc bugs I've found active in RedHat's compiler. Again, this is not an exhaustive list, as I got fed up seeing all of these.

19606 28778 32244 33779 34971 35456 35472 36013 36077 36093 36137 36691 38151 38819 40404

UPDATE:

Well, it seems a retail 4.1.2 has them too. Well, not all of them. So I'd need to cross-check them. Well, whatever... RedHat's gcc still has more.