n2liquid's sandbox

I’ve just installed Xorg with AwesomeWM (on Parabola). I can use 2 fingers to scroll just fine, which is great.

But I shouldn’t celebrate so soon!

If I leave one finger on top of the touchpad (in order to click) while using the other hand to move the mouse pointer, the driver (or whatever) detects that as a 2-finger scroll gesture as well, locking the mouse pointer to wherever it is.

This is not the behavior in either Windows 8 or OS X. It’s hard not to think… who the hell thought this was OK?

Update: As expected, it was not an AwesomeWM problem. GNOME has the same issue. It’s probably really a bug, misconfiguration, or braindead “feature” in xf86-input-synaptics or libsynaptics.

Update: man synaptics doesn’t mention this behavior, so I’m guessing it’s not configurable. Therefore it really is a bug.

Advertisements

That’s it. I decided to blog about my experiences using the GNU operating system (also known as GNU/Linux). The world needs to know the pain I suffer using these poorly implemented systems.

The GNU Logo

I have dumped Windows from my only personal computer and installed a GNU-approved, 100% free software distribution based on Arch Linux: Parabola.

For the time being, I’ll be using an OS X at work, but I intend to dump it eventually as well.

A few months ago I had purchased 2 Casascius coins – physical coins that hold the keypairs for a Bitcoin address credited with their face value. They look like this:

Tons of Casascius coins

I bought one 1 BTC coin and another 5 BTC coin from Casascius.com. The amount I paid for both (6 BTC) was around $50 (R$ 100,00) back then. I intended to keep the coins, but Bitcoin / Dollar exchange, God knows why, recently inflated a lot, so I just had to sell them… I was also curious to see the honeycomb pattern from the coins’ tamper-evident hologram, so I just went ahead and “peeled” the 5 BTC coin, selling each BTC for around $45 (R$ 90,00), $225 total. So, basically, I “profitted” $200, four times the money I’d put in. Coincidentally, I was struggling with the fact that I purchased an air conditioner this month and wouldn’t be able to save money like I do every month. It cost around $200, so I guess Bitcoin took care of that problem for me. Nice : )

I couldn’t find photos of a tampered Casascius coin on the web before, so I decided to take some and post here. This is the short “peeling” process. If you’re curious, I just used a screwdriver to lift the hologram sticker starting from the corner of the coin:

Coin heads

“Vires In Numeris” means “Strength In Numbers” – that’s due to the fact that, in order for the Bitcoin network to operate and be secure, there must be lots of mining machines from common people like you and me. This is something a person couldn’t do solo.

This is the hologram before I had messed it up.

This is the hologram before I’d messed it up. The small code in the middle of the coin is the public key’s “First Bits” code. It can be used to check if the coin is credited with the appropriate face value (5 BTC in this case) by checking it on the public blockchain.

Tampered hologram – 1

It came out rather easily. Maybe I could have done it just using my nails instead of a screwdriver…

Honeycomb pattern starts to show up. I think it's hard to see on this photo, but it's there.

Honeycomb pattern starts to show up. I think it’s hard to see on this photo, but it’s there.

Tampered hologram – 3

Tampered hologram – 4

Finally, the private key appears in mini private key format (https://en.bitcoin.it/wiki/Mini_private_key_format).

Finally, the private key appears, in mini private key format. Neat, huh?? Showing it is no problem because I already took the BTC in it. You can see the transactions here on Blockchain.info. If the money was still there, you could just copy the private key and steal my money; then you’d be a true cyberbrazuca huehue ❤

Trying to put the hologram back in place doesn't work; the honeycomb pattern appears all over the hologram.

Trying to put the hologram back in place doesn’t work; the honeycomb pattern appears all over the hologram. If you tilt it a little, it becomes even more evident.

In order to exchange the value from the private key into Brazilian Real (BRL), I had to convert the mini private key into a SHA256 hex key. It could then be added to your wallet in most Bitcoin clients. I’ve used blockchain.info/wallet because of its simple usage and because I just wanted to make a quick transaction; if you’re serious about storing your Bitcoins, you better download a desktop client, preferrably one that supports offline wallet backup and operation, like Armory.

Then I sent the Bitcoins to an address on my MercadoBitcoin.com.br account, where I easily exchanged this little amount of coins for a fair price in Brazilian Reais.

I’ll keep the 1 BTC one intact as a souvenir from the start of the cryptocurrency era ; ) All this process, and even Bitcoins themselves, have many flaws or otherwise tricky security issues you must be careful about, but I have hope it will get better as Bitcoins mature. I hope you enjoy the pics.

This public key / private key thing… I don’t get it!

Commenter Ian asks:

I was very confused as to how these work, my questions are:
Do you need to pull the sticker off? and
What is the point of the outside digits if the address is on the inside?

Hi, Ian. I’ll answer your questions in reverse order because they nicely chain together like this:

  1. The outside/inside digits are called, in public-key cryptography, a keypair.The inside digits (called the private key) are used to control the money charged into the coin using the Bitcoin network. With those secret digits, you can take money out of the coin and transfer them to another address. This address is secured by the tamper-evident hologram you see in the images.

    The outside digits (called the public key), on the other hand, cannot be used to control the money. They can only be used to prompt the network how much money is charged into that coin. This gives them a little more substance and is one of the things you should check before accepting the coin to make sure they’re charged with the proper value.

    In order to be sure that the coin really has its face value, you must also look at the hologram, check if it shows signs of tampering, and make sure you trust the manufacturer (in this case, Mike “Casascius” Caldwell). Needless to say, this is a really important aspect of accepting these coins as money, just as much as it’s important to be sure dollar bills are real before accepting them (also by checking their authenticity holograms).

    The public key in front of coins can also be useful when the manufacturer mails you these coins before charging them. The receiver can then poll the network to figure when he has completed the transfer.

  2. Given the observations above, you can make and accept payments using Casascius coins without pulling the sticker off.In order to use the use the coin online, however, you must have access to the private key inside, which allows you to transfer money from the coin. Since the private key is protected by the hologram, you can’t (affordably?) impersonate the coin manufacturer by sealing it again without the charged value, or with a copy of the private key which you could use to steal the money from it after the recipient validates the public key.

I hope that better explains how these coins work.

So, I’ve been working on a pretty small project lately called js-emitter (GitHub). I’m still just trying out some pieces of code, so I haven’t really given the repo’s structure much thought (I’m just editing a single test.js file).

The idea behind js-emitter is to emit (human-readable) JavaScript source-code based on a syntax tree I’m defining for it. Overall it’s pretty simple to implement, except that for human-readable source-code I wouldn’t want it riddled with unnecessary parentheses.

Take the following syntax tree as an example:

// Syntax tree for: (my_callback = fn)()
{
    type: 'call-expression',

    target:
    {
        type: 'assignment-expression',

        assignee:
        {
            type: 'identifier',
            name: 'my_callback'
        },

        assigned:
        {
            type: 'identifier',
            name: 'fn'
        }
    },

    args: []
}

In this case, the parentheses wrapping the call target expression are necessary, otherwise the expression would mean something entirely different: my_callback = fn().

In some other cases, however, they are not necessary. Take this example:

// Syntax tree for: callback_array[2]()
{
    type: 'call-expression',

    target:
    {
        type: 'subscript-expression',

        target:
        {
            type: 'identifier',
            name: 'callback_array'
        },

        subscript:
        {
            type: 'number',
            value: 2
        }
    },

    args: []
}

If parentheses were emitted for the target expression here, it would result in cluttered code: (callback_array[2])().

So I need a way to determine when they are needed as the code is emitted.

Basically parentheses are only needed when operator expressions of lower precedence are being emitted as operands for an operator expression of higher precedence. In order to evaluate this scenario, it will be necessary to add metadata to the generated expressions. Specifically, generated expressions will need a “precedence” property that will be used during composite expression emission to determine whether to add parentheses or not.

Let’s analyze how this solution deals with a complex composite expression:

// Syntax tree for: (a + b) * (c = d)()
{
    type: 'multiplication-expression',

    left:
    {
        type: 'addition',

        left:
        {
            type: 'identifier',
            name: 'a'
        },

        right:
        {
            type: 'identifier',
            name: 'b'
        }
    },

    right:
    {
        type: 'call-expression',

        target:
        {
            type: 'assignment-expression',

            assignee:
            {
                type: 'identifier',
                name: 'c'
            },

            assigned:
            {
                type: 'identifier',
                name: 'd'
            }
        },

        args: []
    }
}

The emitter starts at the multiplication expression. It knows the precedence of a multiplication in JavaScript is 5. It then proceeds to emit both left and right expressions. For the left expression, it knows it has to wrap it in parentheses since the precedence of addition is 6, which is lower than multiplication (ps.: precedence is numbered in reverse order; the higher the number, the lower the precedence). For the right side expression, it knows there’s no need for parentheses since the precedence of the function call operator is 2, which is higher than multiplication.

Inside the call expression (precedence 2), the target expression is an assignment (precedence 17). For that reason, since the assignment expression has lower precedence, it warrants parentheses.

In the end, we did get back to (a + b) * (c = d)(), so it looks like that logic will do.

Fun! I had to write this post in order to get to that conclusion. I was having a block when I started 🙂

I hope I’m not missing anything important here, I’m not sure if some combination of expressions can’t render this logic insufficient…

Time will tell.

Touhou's Sakuya

So, I’ve been waiting for the solution to this GotW for many months. Finally I’m giving up on it and just providing my one, for fun. The solution was longer than I expected.

I’m not sure if this is correct, but this is how I see things. Solution to Guru Question:

– widget & – No ownership acquisition – shared or not – is to be allowed. The function is granted the priviledge of modifying the widget. If no change is ever needed by the function, the reference should be to const widget.

– widget * – Same as widget &, but nullable. Same const recommendations apply to the pointed widget. Making the pointer const doesn’t affect the API semantics in any way, but only the internal (as in “inside the function body”) semantics of the pointer.

– unique_ptr<widget> – Causes transfer of unique ownership. This should be used if the widget is not to be usable by the calling function anymore.

This must not be used if pointers or references are kept to the widget anywhere else outside of the function being called, including the calling site / calling function, unless there are documented API guarantees about the transferred widgets’ lifetime. Since those guarantees are not enforced by the compiler, their reliability (and therefore “dangerousness”) rests upon the API developers’ diligence in keeping the program behavior up to the API documented specifications.

Using const widget would be a bit strange, but OK. It would mean the widget is “frozen” and would not be allowed to change forevermore (until it’s deleted).

Using const unique_ptr would be even weirder, but OK again. It would guarantee that the widget is going to be destroyed just before the function exits, but could nevertheless be used, manipulated, and copied at will during the course of its execution. Keeping another reference to it and using it later in this case is a surefire memory corruption caused by usage of deleted object.

Using const widget would additionally cause the freezing behavior described above.

– unique_ptr<widget> & – Represents a potential transfer of unique ownership. Whether it’s going to happen or not is deferred to the called function body (as opposed to being enforced at the call site), possibly causing it to depend on runtime factors (e.g. if it happens inside an if statement).

The call site might want to check whether its unique handle has been nullified or not after the call.

– shared_ptr<widget> – Represents either copy or transfer of shared ownership.

Copy of shared ownership happens when the argument expression is an lvalue, which implies copy construction of the shared_ptr, and therefore a (thread-safe) refcount increment.

Transfer of shared ownership happens when the argument expression is an rvalue, which implies move construction of the shared_ptr, and therefore no refcount increment. Since no refcount needs to be incremented, no synchronization effort happens in this operation.

Copy should be used when the original ownership is to be kept.

Transfer should be used when the original ownership is not needed anymore (i.e. the calling function does not need to use the widget anymore). This doesn’t mean the widget can’t have shared ownership elsewhere in the program beyond the callee, it’s just that the shared handle at the calling function is transferred to the called function. This is pretty much just an “optimization best-practice” sort of thing to avoid the thread synchronization efforts that happen during copy.

const widget should be used in both cases if the widget is not to be modified by the function being called.

Using const shared_ptr has no bearing on the semantics of the API. It would only affect the usage of the shared_ptr in the function being called (the pointer would not be reassignable, just like naked const pointers wouldn’t).

– shared_ptr<widget> & – Represents a potential copy or transfer of shared ownership. Whether they are going to happen – and also the choice of *which* is going to happen! – is deferred to the called function body, and those may only be determinable during runtime (e.g. if the copy or move happen inside if statements).

In this case, one might want to check whether the shared_ptr wasn’t nullified by a transfer inside the called function before dereferencing it.

const widget also should be used if the widget is not to be modified by the function being called.

Using const shared_ptr & also has no bearing on the semantics of the API. It allows for an interesting optimization described here by Nicolas (I love those guys from Lounge<C++>), however, at the very end of that comment: if the immediately called function doesn’t need shared ownership over the object for itself, but another function it calls does, passing a const shared_ptr & first allows the function to bypass useless refcount updates, cheaply forwarding the shared ownership to functions that actually need it (in other words, taking a shared_ptr). This is possible because you can create shared_ptrs from const shared_ptrs.

A reference to a shared_ptr can also be used when the function is supposed to make changes or otherwise deal with the pointer itself, as pointed out in this StackOverflow answer.

Realistically speaking, I believe it’s highly unlikely there is any practical usage for passing unique_ptr or shared_ptr by reference for potential copies or transfers. If you encounter such a need, you should probably hold on for a second and rethink, since it’s a code smell. There is probably a better way to do it. But if not, well, it works, so go ahead. Just know that people can be confused by these kinds of smart pointer usage, and at the very least use assertions to make sure the pointers aren’t null after the potential moves. And, of course, know what you’re doing.

If you have any questions, ask them in the comments section! Also, if I made I mistake (quite likely since I haven’t really tested any of these assertives), please let me know, too! Kuppo!

Final Fantasy XIII-2 Moggle Artwork

Today I suddenly noticed a way to fix a weakness I’d long known in Chii’s users() access specifier. users() has the pitfall that changing one interface would needlessly force all clients of the class to recompile. So I got an idea to address this issue, and also remove the need for C++’s PImpl / Cheshire Cat idiom in Chii, which I believe is just boilerplate and could be handled by the language.

The idea consists basically in making the compiler break a class header into many smaller interface files (“interface shards”) which client code will import instead of the fat one. If the fat class file is changed, the compiler will regenerate the shards, but will only update those that are needed. The impact on clients depends on the changes made.

If the change was:

  • the public structure of the class (i.e. public variables), then all clients must be recompiled;
  • the private structure of the class, and the size of the class (in bytes) or the alignment requirements change, all clients must be recompiled;
  • the method signature in one of the shards, only the clients of that shard must be recompiled;
  • the addition or removal of a method from one of the shards, only the clients of that shard must be recompiled, but some or all clients may need to be relinked (see the reason why below);
  • the private structure of the class, but the size of the class (in bytes) and the alignment requirements don’t change, no clients must be recompiled (this is where PImpl gets replaced by a language feature; in fact, this also performs better than PImpl since it doesn’t use dynamic allocation, but is still safe in ways that I’m not aware to be possible in C++).

Changes in the number of methods in an interface is tricky because it messes with virtual table offsets of neighbouring interfaces. To avoid recompiling unrelated clients, I’m considering putting the offset to the beginning of an interface on the vtable in an externally linked constant. During link time, I should be able to just link the objects with another one containing the constant. That’s why some clients might need to be relinked, but not recompiled in case of method additions or removals on the class.

I’m crazy to try to implement those things, but I’m really out of time to do that… Anyways, I hope all of this makes sense and is somewhat exciting to whoever is reading.

Introduction

I have recently created an account on MyFigureCollection.net, a really nice site in which you can post and manage collections of action figures you own, favorite and comment others’ photos, etc. It is pretty much a small social network for action figure enthusiasts.

Hatsune Miku and Black Gold Saw (MFC.net banner by Danboard_san)

The site contents truly is amazing, and I’ll certainly actively participate in it once I get a fine camera and more figures.

Overall the site is pretty good and the idea is really nice, but the service is not as good as it could be.

The matter of what is good and what is bad is pretty much personal, and there’s likely people out there who love MFC (no, not that MFC), but the site has a long way to go to suit my tastes in plenty.

For example, I think the site design could be greatly improved. Of course I can use Greasemonkey to do that, but people wouldn’t see it if I sent them links to my profile, so that only solves half the problem.

Another thing is that if I wanted to create some crazy relationships between my images (like saying 3 images have the same pose, only each has a different background and the last one is photoshopped to, say, remove the joints) I would have to resort to linking them in the description.

But I want better.

For a moment I thought about making a similar service with the changes I’d like to see, but I noticed it wouldn’t be worth it. Most people would stay in MFC.net, some would use both, and we would have the redundancy and mess that Orkut, Facebook, Google+ et al introduced.

It then striked me that these kinds of things wouldn’t happen if web federations like we had in Google Wave were more common.

Federated webspaces

Google Wave’s intent was to reinvent e-mail. One of the most important characteristcs of how e-mail works is that it is distributed.

Can you imagine how far behind we would be if we had a single e-mail provider? It could be Hotmail, guys!

The ability to set up a new mail server is something we take for granted, and we think we would be in a ridiculous position if we couldn’t.

And what if we had multiple e-mail providers that couldn’t send messages to each other? If your e-mail ended in @hotmail.com and mine ended in @gmail.com, I would have to create a Hotmail account just to send you a message. How freaking awkward would that be? Insane, isn’t it?

Insane it is, but that’s what we do when I’m on Facebook and you’re on Google+ today.

The creators of Wave obviously knew all this, and since they wanted to make “a better e-mail”, their product couldn’t have such a major setback, so they developed the Federation Protocol: a way to allow waves to cross server borders.

Not long ago, if I remember correctly, there was a big fuss around Facebook and its apparent reluctance in permitting users to interact with other services such as Twitter. Facebook has obviously changed its mind now, but they still don’t want to give users the ability to export their own data.

Also recently, Google decided to ban Anonymous from G+, and there’s been a lot of discussion on whether they should allow codenames to be used in their network. Some guys from Anonymous then decided to start work on their own social network, Anonplus (which, by the looks of it, isn’t going too far, but it is a noble initiative), but integration with other services is sure going to be tough.

There are many reasons to make social networks interact with each other, and it’s pretty much common sense that this is an important feature to have because the very idea of social networks is that people should be able to interact, and people are scattered across many different services.

One way of achieving such interactions is by federating a social network service just like we did for e-mail and Google Wave.

There is a social network called DIASPORA* being developed, whose server anyone can run an instance of locally and participate. This is by far the most promising social network project I’ve seen.

What I find, as a developer, particularly cool about federations, is that it allows nearly limitless personalization and improvement of services without breaking things. If MFC.net had a federation protocol, I would be able to friendly extend it instead of starting everything from scratch as if I hated it entirely. MFC.net is cool, I just want some small improvements here in there. No need for a wholly new service. That’s drastic.

Now, as a person, what I find important about federations is freedom.

If a service like G+ decides to ban me because it doesn’t like the ring of “n2liquid”, or because I’m excited about all the mess Anonymous is causing, I can just take my stuff and go to another server; maybe even my own if nobody likes me, and, in this case, I wouldn’t have to start a new social network project like Anonplus from scratch. I would simply pick something pre-made and put on a server, WordPress-style.

I hope somebody makes an easy-to-use framework for this so that everybody can effortlessly build the web of the future. XMPP is cool, but it’s nothing more than a foundation for such a framework. As it stands, I don’t see many people making simple websites like MFC.net using it for building federated networks.

I hope federations become the rule. It’s not just cool; it can become a pillar of internet freedom.

Cute bouncing pixels

un.ma.i!

Twitter (technical)

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Twitter (personal)

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Get messaged when I post something new!
Just enter your e-mail and hit Follow:

Join 171 other followers

%d bloggers like this: