Facebook "Open Compute Project" nothing but hot air
There has been a lot of fuzz about facebook's Open Compute Project, and it seems to
originate mostly from journalists without much technical skill.
Did anyone actually bother to check what they released? You can find
mechanical designs and simple
specification data sheets. More or less every vendor is publishing that kind
of information, or at least there are common form factors that are specified
(like ATX, eATX, mini-ITX, ...)
It is sad to hear that they are 'openwashing' themselves (like BP is
greenwashing itself). Specifically, the following portions are not "open":
- Any type of electrical schematics (mainboards, power supply, ...)
- Any type of detailed data sheets or programming manuals on the electronic components used
- Gerber files of the PCBs
So what this really is all about is: Facebook advertising this is our new
mechanical form factor, now we want all of you to adopt it, so we can buy
Go home, facebook. Come back if you have something _really_ open.
Following up on my GSM MAP archeology project
In the past weeks, I have been blogging
about the work I've been doing in trying to recover the earlier versions of the
GSM MAP ASN.1 files in order to support it from my own Osmocom Erlang MAP code.
After having gone through the tiresome exercise of implementing a custom MS
Word for DOS file parser to extract the ASN.1 definitions from the
3GPP-published DOC files, I tried to feed them into the Erlang asn1ct code
Unfortunately this didn't work, as the old MAP ASN.1 references very old ITU-T
TCAP from 1988. So I went to the ITU website. There again a similar story.
From their asn1 website section, you can only get the TCAPMessages
from 1997. If you want an older format, like the Q.773 from 1988, you can
download a PDF file. Most of that PDF file is actual text. But the ASN.1
sections are included as an image, so there is no way how you can copy+paste
So there I went, and manually typed in those few pages of ASN.1 source code.
After I was finished, I thought I had finally done enough. Writing a
word-for-DOS parser, typing in pages of ASN.1 manually. What more can there
be? I should be able to finally generate Erlang code for decoding and encoding
the respective messages.
But it would be too simple if it was that easy. The 1988 TCAP as well as the
old MAP specifications use the ASN.1 "MACRO" construct to define the individual
MAP operations. However, as it seems the MACRO construct had been deprecated
in 1994 by the ISO in charge of ASN.1. Successive ISO specs for ASN.1
have completely remove the MACRO construct as similar results can be achieved
with newly-introduced information objects. So of course, the Erlang
asn1ct (as well as other free software ASN.1 tools) does not support such an
So here I am in the year 2011, unable to use information available in the
public ITU-T and ETSI/3GPP specifications to build a GSM MAP protocol
implementation that can deal with the messages that you encounter on real-world
SS7 links. I guess there are now the following different approaches to proceed:
- write a converter that translates MACRO into OBJECT
- manually convert the old MAP specs from MACRO to OBJECT
- add MACRO support to current-day ASN.1 tools
- find some old ASN.1 code generators that still support MACRO
All in all, this is a really dissatisfying situation, and I would say it is a
failure of the standardization bodies to provide useful versions of their
specifications. You cannot remove operations and associated message types from
a specification, while in real life even 15 years later a whole number of users
still use messages according to those (now removed) definitions. Meanwhile, the
old specs are getting useless, because you not only deprecate but completely
remove a language construct of the formal specification language used.
This renders the idea of having a formal specification useless. If I first
need to write my own converters or manually convert that very same formal
specification, errors can be introduced in the translation/conversion process,
just as much as errors could have been introduced in manually writing encoding
and decoding routines based on a non-formal-specified protocol like most of the
IETF / Internet protocols.