Jasa Web Design

Loon: Internet & hot air helium in emerging markets

I’m probably killing my employability at Google by publishing this, but I’m going to try a stab at analyzing the Loon project from technical and commercial feasibility standpoints – naturally falling heavier on the tech side. I’ve been slowly writing this as a draft for a few weeks now, after learning of a project to provide Internet access in emerging markets (as in, the bottom of the pyramid), and taking a look at what various players are doing in this space.

The project

I won’t go into the details too much, you can read all about Project Loon on the official website. The short version: launch free-floating, high-altitude balloons filled with helium and fitted with radios, that provide LTE coverage in a certain area below the balloon’s flight path. There is an uplink to provide backhaul to the balloons, which must be available in all areas where coverage is to be supplied – this means, if the balloon does not have backhaul towards the ground, it cannot provide service. Why this is important other than the obvious I’ll get to later on.

Helium as a source of lift

A flying object needs to achieve lift that is greater than its weight. Basic physics. Airplanes do this by moving air faster over the wing than under it, and the pressure difference causes an upward force called lift. Balloons do this by filling themselves up with a fluid lighter than the fluid outside. Archimedes’ principle takes over, and lift occurs. This is why beachballs float on water, and why hot-air balloons rise – the air inside is less dense than the air outside.

In case of Loon, the fluid inside is helium, which is an order of magnitude less dense at STP than air. This is the gas used in party balloons, and the reason your kid cries when he lets go of the Minion balloon you’ve bought him, and you watch your $5 disappear into the ether. One big issue with helium is that it’s a finite resource. There is only so much available on our planet, as with oil and natural gas. I will not get into the debate of wether we’re running out of helium or not, but focus on the economics for now.

As per Loon’s technical details, a balloon will fly at altitudes between 15 and 26km, and support a payload of 10kg. The balloon measures 12 by 15 meters when fully inflated, which results in an approximate volume of 1,400 m3. A quick calculation using online resources results in an initial helium volume of 25 m3 which expands as altitude increases and atmospheric pressure decreases. A single balloon will fly for around 100 days, so to give year-round coverage in any particular location, 3.6 balloon flights are required, or 90 m3 of helium per year. At current prices, helium costs per year per area of coverage run at $550. This cost is recurring as helium is vented into space when a balloon ends its operational flight.

Continue Reading…

The battle of the Sesame smart locks


I have been following recent events in the smart lock space, particularly in the wake of Sesame (London) stopping their Indiegogo campaign, after Sesame (US) launched theirs a few days earlier on Kickstarter. As a disclaimer, I was briefly involved with Sesame (London) in mid-2014, during which I advised them to implement features and make changes that have since become evident, and implemented by almost all the other smart lock manufacturers – but not Sesame (London). It’s not very often that two genuine, competing products with the same name are launched on crowdfunding sites within days of each other.


Sesame (London), which I’ll refer to as SL from now on for clarity, sprung from a project between Marcus Kjellson and Morten Lund, who had been working on a concept of a deadbolt smart lock for almost two years. It was then renamed Sesame in mid-2014, and launched early 2015 on Indiegogo as a way to gather $75.000 to be used for an initial manufacturing run, as well as finish development. By the time I got involved with SL, the focus had become almost exclusively on aesthetic design, involving big-name architects and designers, and cool materials such as porcelain and bronze. The lock was surrounded by a marketing and design cloud, and in my view, basic functionality and lessons learned from the first wave of smart locks went ignored. I will also refer to Sesame (US) as SU from here onwards.

The first wave

I won’t go into a lot of detail on the first lot of smart locks that started appearing a couple of years ago, as Schuyler Towne has done an excellent job of it already. I will focus on the main gripes as reported by users, and how these are solved, or not, by the “Sesames”.

Smart locks and battery life

A smart lock must, as its essential feature, turn an existing deadbolt (well, any kind, but deadbolts are the easiest to support mechanically) lock from closed to open and vice-versa, upon user command or a schedule. In order to do this, an electric motor with enough torque must be used. In addition, a microprocessor, sensors and RF stack is required to control the device. For example, detecting the position of the tumbler, or implementing the “secret knock” sequence of SU’s lock requires an accelerometer. The RF stack can be Bluetooth LE and optionally Wi-Fi, if external connectivity to the internet is desired. Most first-generation smart locks that could be remote-controlled from the internet featured built-in Wi-Fi chipsets.

The main issue with Wi-Fi is that if it is to be left on 100% of the time, waiting for remote commands, the drain on the battery is huge. The motor only turns every so often, and the microprocessor and sensors can be optimized and feature “sleep” modes, but Wi-Fi must stay on. If you need to save battery, you need to turn it on periodically, or based on events such as a door shake detected by the accelerometer. If you schedule periodic connections, a remote lock or unlock is not instantaneous, voiding some of the benefits of the usual claim of “let people in remotely”.

In comparison, Bluetooth LE uses 49μA at 3V, whereas Wi-Fi uses around 100mA at 1.8V. For this simple reason, my advice to SL was to move Wi-Fi out of the lock completely, into a “hub” that plugs into AC power, and can thus be connected 24/7 to the internet – this was way before any other manufacturer had even announced plans for hubs for exactly this purpose. Any remote commands are instantly sent to the lock via Bluetooth LE, and features such as remote firmware updates are also viable.

SL attempted to fix the battery life issue by implementing a “specially designed lithium battery” which they hoped would last for a year. With Wi-Fi built into the lock, this was unlikely to happen, as has been seen in other locks. The fact that the battery is custom-made, and thus must be ordered from the manufacturer of the lock, is another barrier to adoption. SU fixed this by using lithium CR123A batteries, which is universally available in stores. A rechargeable version of the CR123A also exists, for those not wanting to spend so much on replacements. In addition, SU went straight for a Bluetooth-only lock, with a Wi-Fi hub as an option. August, Lockitron and others have all gone for Wi-Fi hubs too.

Continue Reading…

El calvario de conectarse a Gowex

Como corolario a mi anterior post, donde doy un par de pinceladas al respecto, me he ido a un Pans & Company cerca de casa a probar de conectarme a un hotspot de Gowex. Esta es la experiencia por la que pasa un usuario cualquiera, con un análisis tecnico de fondo. Podéis hacer click sobre cualquier imagen para verla a tamaño completo.

1. Buscando a Gowex desesperadamente

Cuando abrimos nuestra lista de señales WiFi, lo lógico es buscar la que tenga el nombre relacionado con el local en el que nos encontramos. Véase la lista de señales en el Eroski de Sant Cugat:


Parece obvio que la gente de McDonald’s ha pensado como yo, pero Gowex quizás no tanto. PANSGOWEXWiFi no es, a primera vista, muy legible, ni fácilmente identificable con la marca. 100M Wifi Gratis corresponde a 100 Montaditos, cierto parecido también.

2. Portal o berenjenal?

Lo que vemos a continuación es digno de entrar en los anales de la anti-usabilidad, y ser mencionado en las escuelas de diseño como lo que no hay que hacer. Iba a poner flechas rojas, como he hecho otras veces, indicando los fallos y problemas, pero es que el resultado hubiese sido una imagen completamente roja. Problemas de alineación de elementos, espaciado, colores y sus combinaciones, disparidad de tipos de letra y tamaños, irrelevancia…


Como es obvio, muchos usuarios se van a perder en un portal así, sin saber que hacer. Otros acabarán encontrando el botón “Registro WIFI GRATIS” [sic] y entenderán que de algún modo hay que registrarse, para obtener un login que introducir en el apartado de la izquierda (Acceder a internet).

3. Alto! Policía! Esto es un Registro WIFI GRATIS!

Para acceder a internet, Gowex nos pide: nombre, apellidos, login, email, móvil y fecha de nacimiento, así como aceptar los típicos terminos y condiciones. El apartado de login es curioso, ya que en vez de usar la dirección de email del propio usuario, nos crean uno nuevo @gowex.com, lo cual es absurdo.


Los obvios como “pepito” o “stevejobs” estaban todos pillados, así que probé con “marktwain” y funcionó.


Lo más chocante y absurdo del proceso es que para recibir la contraseña, si no hemos proporcionado nuestro número de móvil real (y quién va a hacerlo, con las estafas sobre SMS que corren por todas partes), necesitamos poder recibir un email. Para lo cual necesitamos conexión a internet. Que no tenemos por que no disponemos de un login. El login nos llega por email. Para recibir un mail necesitamos… AAAARGH!!!

Me parece digno de estudio como los directivos y técnicos de empresas del calibre de Pans & Company han pasado por alto cosas como esta, y hayan firmado con Gowex. También parece digno de estudio como inversores, antes de comprar Gowex, no han intentado probar el acceso y no han visto que una empresa con una calidad de producto tan deficiente es inviable.

4. Contraseña? No necesitamos contraseñas!

La incompetencia de los responsables de producto y QA de Gowex queda patente cuando examinamos el email que nos envían (y que no podemos recibir… pero como soy un hacker, me apaño para hacerlo), supuestamente con los datos para acceder a internet mediante el dichoso login:


Donde está la contraseña? WTF? Al final, recurro a la que tenía en un intento de login de hace un par de años, en un mail parecido.

5. Certificando los problemas

Tras el intento de login, nos aparece un error de certificado SSL. Para mis lectores no-técnicos, si veis esto, cerrad la página y no miréis atras. En el caso de Gowex, es un error debido a la incompetencia de los administradores de sistemas, en otros casos puede deberse a intentos genuínos de robar nuestra información confidencial. Si no sabemos distinguir, hay que hacer como con las setas – no comerlas!


6. Por fin online!

Tras saltarnos el error SSL, nos espera otra página que hace daño a la vista, con publicidad irrelevante en cabecera (no debería ser de Pans?). Qué tal es la conexión? Debo decir que al menos, la velocidad se aproxima a los 512kbps que prometen en la modalidad “gratis”:


Esto es mérito parcial de Gowex, ya que depende más del proveedor de banda ancha que de sus sistemas. Con una buena ADSL o fibra, un servicio público de WiFi bien gestionado puede ser más que aceptable aún cuando tiene muchos usuarios activos a la vez.

7. Conclusiones

El servicio WiFi que da Gowex es pésimo, de los peores que he visto. Tan sólo por lo descrito en éste post, cualquier inversor debería plantearse el motivo de que una empresa invertible no haya sido capaz de desarrollar un producto aceptable en diez años de existencia.

Gowex, Jenaro García y Mark Twain

Quien dice la verdad no necesita acordarse de nada” — Mark Twain. Es una de las frases que hace muchos años he incorporado a mi modo de vida.

En el caso de Gowex, iremos viendo cuanta verdad hay en esta cita. El caso del enorme fraude de Jenaro García ha sido ampliamente explicado y comentado en Expansión, WSJ, ABC y muchos más. Los medios son un hervidero de noticias y datos acerca del escándalo.

Una constante que aprecio en redes sociales es el “vale, ahora sale todo el mundo diciendo que ya sabía que Gowex era un fraude“, o “si tanta gente sabía que Gowex era un fraude, por que nadie había dicho nada antes?“. Me doy por aludido, ya que yo tenía claro que Gowex era, como mínimo, una empresa con afirmaciones muy, muy exageradas, desde el año 2007. Al poco tiempo me convencí por completo que se trataba de una empresa inviable y sin posibilidades más allá de comerse ingresos de inversores y subvenciones.

Para los que no conozcan mi background, llevo en el sector de las tecnologías WiFi desde el 2001-2002, y publiqué un libro acerca de la seguridad en redes wireless en 2004. He sido administrador y moderador en foros tan reconocidos en el mundillo como Netstumbler y BackTrack Linux. He fundado dos empresas dedicadas a ofrecer servicios de WiFi público, y asesorado a varias más. Puedo decir que conozco bién el mundo del WiFi en todos sus aspectos.

Tomé contacto con Jenaro en el Mobile World Congress 2007 en Barcelona, mientras hacíamos prospecciones y contactos con posibles partners para Whisher, la empresa de “social WiFi” de la que fuí fundador y CTO. Me pareció una persona un tanto hiperactiva, con ambiciones de “comerse el mundo”, y afirmaciones que me parecían muy exageradas en cuanto a alcance y viabilidad. En una posterior visita a nuestra oficina, nos presentó Gowex, y las diferentes ramas que la componían, como WiLoc (publicidad geolocalizada). En dicha visita, me felicitó por mi artículo en el que descubría que Fon, de Martin Varsavsky, no decía la verdad sobre el número real de hotspots de que disponía su red, y aprovechó para criticar duramente a Martín y su empresa. Todo esto resulta ahora altamente irónico.

La oferta de Gowex en aquel momento era darnos acceso a su red de hotspots en modo roaming, es decir, nuestros usuarios podrían conectarse a los hotspots WiFi de Gowex a cambio de un importe inicial (“setup fee”) y una cuota mensual. El setup fee era de 20.000€, que nos pareció exagerado. Cuando preguntamos sobre su cobertura, número y ubicación de hotspots, Jenaro se volvió esquivo y citó NDAs y motivos obtusos para no revelar exactamente dicha información, tan sólo ofreciendo que tenían “más de 20.000 hotspots”. Escarbando un poco descubrí que realmente lo que tenían era un acuerdo de reventa con WeRoam, un agregador de redes de hotspots con más de 100 operadores adscritos. Al final cerramos un acuerdo con WeRoam directamente, por un precio muy inferior al de Gowex.

Durante los años que siguieron a Whisher, seguí, a veces más de cerca, a veces no tanto, la evolución de Gowex, y sus supuestos éxitos. Todo eran firmas de contratos, nuevas ciudades envueltas en WiFi, cobertura en autobuses y kioskos… Analizando algunos más en detalle, era evidente que la monetización era, como mínimo, dudosa. Véase el ejemplo de los kioskos, donde la gente va a buscar algo y se va, no se queda de pié delante mientras se conecta al WiFi para bajarse un email.

Mi último contacto con Jenaro fue durante el Mobile World Congress de 2012, cuando tras fundar Social & Beyond, una startup que ofrece WiFi a cambio de promoción en redes sociales, estudiamos la posibilidad de llegar a algún acuerdo con Gowex. Lo que nos intentó vender entonces como producto estrella era algo llamado “Diaspora”, un sistema para agregar redes WiFi residenciales mediante un software para smartphones. Esto encendió mis alarmas (se han creado y hundido varias empresas que han intentado hacer lo mismo), y agradeciendo su tiempo, puse tierra de por medio. Llegó incluso a ofrecer comprar un 51% de la empresa, cosa que también rechacé.

El factor tecnológico

Se ha hablado muchísimo sobre lo inviables que eran las cifras de Gowex, desde lo que pagaban por las auditorías hasta el revenue por empleado, superior a Google o Microsoft. Se han publicado artículos en el pasado alertando sobre todo esto, y fueron convenientemente ignorados. La reacción normal a publicaciones contra Gowex era “que haces, loco, atacando a una de las empresas punteras en España, caso de éxito mundial!“. En mi caso, nunca me fijé en cosas como el valor en bolsa, revenues, o cifras publicadas por Gowex. Me bastaba con conectar de vez en cuando a uno de sus hotspots, y ver que sus sistemas y tecnología dejaban mucho que desear. La experiencia de usuario era tan pésima, que me jugaría una buena cena a que el 80-90% de usuarios que intentaban conectar no lo lograban. En un caso extremo, la empleada de una cafetería de Barcelona me dió la clave WPA del router donde conectaban el TPV, diciendo que “el WiFi de Gowex es una basura, nunca funciona y los clientes se quejan, pero no me dejan apagarlo“.

Cuando un cliente necesita 10 minutos y un sinfín de formularios y pasos lentos y tortuosos para conectarse a internet, va a dejarlo estar. Mi experiencia a lo largo de los años me ha convencido de que el camino entre la barrera de monetización e internet, de cara al usuario, debe ser lo más corto y sin fricción posible. Cuando obligas a rellenar algo, sea una clave, PIN o email, se caen del orden del 40% de posibles usuarios. A cada paso adicional se van cayendo más.

La única fuente de ingresos de Gowex, por tanto, eran los contratos en los que el negocio pagaba un setup + fijo mensual, por lo que a Gowex le era exactamente igual la calidad final del servicio. Por lo que ha aguantado Gowex en ciertos comercios, a los directivos de los mismos tampoco parecía importarles demasiado. “Gowex WiFi Gratis” era el mensaje que ponían en la puerta, y como reclamo ya servía.

Por supuesto, también hice mis análisis sobre los mapas de Gowex, llegando a las mismas conclusiones que el informe de Gotham, acerca de la cobertura real de sus hotspots.

Por qué no dije nada

A finales de 2006, publiqué un controvertido artículo en mi blog, en el que hacía un detallado análisis acerca de Fon y sus cifras de hotspots en activo. Mediante un estudio de los propios mapas de hotspots de Fon, llegué a la conclusión de que poco más de 3.700 hotspots de los 20.000 que decía tener la empresa estaban realmente en activo. Dicho artículo provocó la ira de Martín Varsavsky, que publicó una contra en su blog, y me llegaron críticas de todo tipo y por todas vías, en incluso amenazas a mi integridad física. Fon siguió su rumbo, siguió levantando dinero de inversores, y llegó el día en que casi se vino abajo, despidiendo a la mayoría de su plantilla, y re-enfocando el negocio a acuerdos con operadores de banda ancha, para añadir la funcionalidad de hotspot a routers existentes. En cierto modo, salí reivindicado de mis afirmaciones, pero el coste en nervios, stress, y noches sin dormir fue demasiado como para repetir la experiencia con Gowex.

Del episodio Fon aprendí que es más fácil matar o ignorar al mensajero, que hacerle caso e investigar. El caso más patente de lo que yo pasé, pero amplificado mil veces, es el de Harry Markopolos, que estuvo nueve años denunciando el caso Madoff a la SEC y otras agencias gubernamentales, así como medios de comunicación, sin que nadie le hiciese caso, hasta que se descubrió la estafa. Su libro “No one would listen: a true financial thriller” es digno de ser leído, lo recomiendo a todos de los que ahora critican a los que nos callamos lo que sabíamos sobre Gowex.

GNU Radio & Mac OS X – The Adventure

A few days ago my USRP B100 with WBX daughterboard arrived. It is an awesome piece of kit, judging just from how the PCBs are designed and laid out. The online reviews and demos also agree. My first challenge is going to get the USRP up & running with GNU Radio on my 2013 iMac. I say challenge as many online references are for PPC versions of Mac OS, or simply outdated, as an example, Jon Jacky’s page. And it’s from 2010, just three years ago!

So, like I did with Imagick and MAMP, I’m going to try and write a step-by-step, easy to follow guide as I go along. This is going to be a live post, so keep checking every few days for progress!

Day one: brewing the drivers

The lack of up-to-date, complete information on how to drive the USRP under Mac OS is surprising. Given the market share and BSDness of OS X, one could safely assume it would be a more prone target than, say, Windows. My first attempt to install GNU Radio using macports didn’t go down so well, and having suffered dependencies hell before, I went looking for other ways, without giving it a second look. After some Google time, I found a set of Homebrew recipes in titanous’ GitHub, which claims to have been tested on 10.8. The result is that I could start GNU Radio, but I was missing the WX GUI components, and had only f-ugly QT components. I blame myself for not reading the instructions end-to-end, and the instructions for not pointing out that WX GUI had to be installed beforehand. Other stuff was duplicated. Some stuff was missing. As an example, I could not find the “Variable Slider” component used in Balint Seeber’s tutorial on YouTube. As an example of the ugliness, and keeping up with my obnoxiousness when it comes to user interfaces, here is a graphical review of the window resulting from Balint’s first test:







I had also installed, but was missing in the sources, the driver for the USRP, following instructions found somewhere else. After a couple of email exchanges with the good people at Ettus, I was pointed to a promising set of guides, back on macports. These will come tomorrow, though.

Day 2: playing with MacPorts

The pointers given by Balint were this tutorial by Andy Bardagjy on getting the right sdcc version to install, followed by installation of the gnuradio port, and finally setting the Python path variables. As some of this info was a bit old, I checked out the sdcc ticket on trac, and it’s shown as fixed, so I’m attempting to go ahead with 3.0.0. For the record, trying to clone 57740 (v2.9.0) failed upon build, so that’s another reason for attempting to go with 3.0.0.

Installing the USRP driver also went fine, just that the port name has been changed to UHD. My first attempt to install GNU Radio after this appeared to work, but for some reason, gnuradio-companion was nowhere to be seen. Trying to install any of the gnuradio-<whatever> ports resulted in an error informing me that they had been replaced by ‘gnuradio’ with options.

After some more Google time, I found this ticket on the MacPorts trac, that explains the issue, and suggests a fix. I managed to get GNU Radio with gnuradio-companion working, at least visually, by running

sudo port install gnuradio +grc +python27 +qtqui +wxgui

which includes the WX GUI components. But it doesn’t include the USRP sources. So, let’s try this instead (after port clean etc.)

sudo port install gnuradio +uhd +grc +swig +wxgui +qtgui +python27

Now, I can see the UHD USRP sources in Companion! More to come later…

Day 3: getting some results!

Finally, the light at the end of the tunnel starts to appear. The WX GUI objects are now present in Companion, but they are also ugly as hell. Maybe it’s a Mac OS rendering issue, I’ll have a go on Ubuntu to see the difference.

The Guide™

Step-by-step, here is how to get your USRP to work under Mac OS X 10.7 and 10.8. By the time you read this, new versions of the different pieces of the puzzle could have appeared, so I’m not making guarantees.

1. Install MacPorts if you haven’t yet done so. Grab it here.

2. Install sdcc – the bugs that were reported appear to have been fixed, so v3.0.0 is fine:

sudo port install sdcc

3. Install the UHD driver for the USRP, including libusb and Python 2.7:

sudo port install uhd +libusb +python27

When you do this, Boost 1.53 will also be installed, which doesn’t seem to give any problems.

4. Install GNU Radio, with UHD support, GRC (the Companion), the WX and QT GUIs (just in case):

sudo port install gnuradio +uhd +grc +swig +wxgui +qtgui +python27

You may see the following, depending on what you had installed before trying this procedure:

Error: org.macports.activate for port qwt returned: Image error: /opt/local/include/qwt/qwt.h is being used by the active qwt52 port.  
Please deactivate this port first, or use 'port -f activate qwt' to force the activation.

I didn’t really feel like bug hunting any longer, so I just forced it with

sudo port -f activate qwt

and was done with. I’ll rest my case with a short quote from Miguel de Icaza’s post on why he ended up with a Mac instead of Linux. He started the GNOME project and Mono.

“While I missed the comprehensive Linux toolchain and userland, I did not miss having to chase the proper package for my current version of Linux, or beg someone to package something. Binaries just worked.”

The build may finish with a complaint about qwt52 not installing as qwt is already installed (WTF?), but gnuradio starts OK.

Once this is done, you should be able to start gnuradio-companion. In order to use the B100, you need to add, for example, a UHD: USRP Source. Here is an updated example of a WFM receiver, you can download the .grc file here.

WFM Receiver







Off to Abu Dhabi, without Movistar

So these are the rates for calling Spain from Abu Dhabi if you have a Movistar contract SIM:






There’s NO way I’m going to pay 17€ for a 5-minute phone call home once I get there. It’s amazing how screwed up the world of phone carriers is – the same phone call on a Du prepaid SIM will cost me 1.8€. Plus, you can pick up a Du SIM at their Abu Dhabi airport shops as you arrive, they operate 24/7.

Replacing your Mac OS login with a Yubikey

So yesterday I got a couple of normal Yubikey OTP devices (plus one beta NFC version) from Yubico – in a surprisingly quick time!

I’m not going to get into a review of the Yubikey, other than saying it’s an awesome device – there are plenty you can read out there.

While the OTP universe is nice and sweet, allowing you to secure access to a number of services with your physical key, plus a number of second-factor inputs, I wanted one of the keys to function as a simple password entry device for Mac OS. In addition, it would be great if I could use the key to lock my Mac when I leave my workspace unattended, a security policy rarely followed in the real world.

I had been using a piece of software from Rohos Rohos sucks ass, I’ve now installed TokenLock ($2.99 on the Mac App Store, and it works great) to lock my desktop, tied to a simple USB flash drive, but this meant that Rohos had to keep my password stored somewhere, and you cannot call up Rohos whenever you are asked for a password. The sole functionality Rohos provides in this case is password entry whenever an OS password request window comes up.

Enter the Yubikey

Interestingly, you can use Rohos in USB-key mode, by choosing the Yubikey as your USB device – after all, it has a serial number. Once you have chosen the USB device, simply enable “Lock desktop” from the list of actions upon USB removal. After you choose the Yubikey as your USB device in TokenLock’s preferences, when you need to leave your desktop, simply pull the Yubikey out, and it will be locked for you. Of course, you must enable the usual combination of “disable automatic login” and “require password” in OS X’s Security preferences.

For the login part to work, you need to program your Mac’s password into the Yubikey’s first or second slots. I chose the first as I wanted speed over keeping the original OTP configuration. If you want to keep Yubico’s OTP, write the static password to the second slot, you then need to tap the button on the key for 2-5 seconds.

When you arrive back at your workstation, insert the Yubikey, and tap the button – your password will be entered for you, and you’ll be logged in!



NSFW Corporation – a review


So finally I managed to get in the NSFW Corporation beta – after some back-and-forth involving a mysterious bug that caused my email to not make it in the beta on time. I have one word to start off this review: awesome.

It’s hard to describe what it is – my best description, aside from the official line of being “a news-weekly that’s published daily“, is that it’s a mix of witty articles on a variety of topics, complimented with an audio podcast (Lord, do I hate that word – if you have a better one, let me know, Paul!). NSFW is Paul Carr’s brainchild, founded after a string of startup failures and literary successes, and is showing promise. The first literary success is ironically based on the string of startup failures, but I digress.

Two articles from the pilot issue are titled This is Why They Hate Us: The Meat Monster, a funny take on why the rest of the world hates the United States and 10k-kcalorie burgers, and Best Practices For: The New Secret Service, which includes tips such as “An agent should now wrestle his partner to the ground at the first hint of an erection“. It is hilarious and entertaining reading, with a touch of political incorrectness that I witnessed only in UK media while I was living there, plus the right dose of swearing. It’s not called NSFW for nothing.

NSFW Live is the audio part of the site, with Paul and Josh Ellis, a contributor with a deep, movie-trailer voice, which reminds me of Beau Weaver (check out his free In A World ringtone). Josh makes the intro, and the back-and-forth with the guest begins. In the first episode, Patrick Sauer is invited to opine on whether Ron Paul masturbates to ‘Atlas Shrugged‘. A touchy subject if there is one (no pun intended… sort of). The clips last for around 30 minutes, and are highly entertaining.

Once it becomes live to the general public, a yearly subscription will cost $26, which is very good value for money. Right now, content is optimized for the iPad, but you can still read it in a desktop browser such as Safari or Chrome – Firefox was quirky at times, with random Javascript events being triggered for no apparent reason. Maybe it’s Firebug, but I didn’t investigate further.

Grumpy old git – things that could improve

As I’m an anal-retentive asshole when it comes to user interfaces and usability, I have a few constructive criticisms to make. First, on being iPad-optimized, and the very first thing you see when you arrive at nsfwcorp.com – the login form.

Before digging in, one curiosity for those technically-minded: there is almost no “normal” HTML in the site’s source. Each page is a collection of Javascript includes, which generate content dynamically. This has one advantage in being able to adapt to user browser & device specifics without much server-side heavy lifting, for example, by making use of jQuery’s deviceAgent.match (in this case, to send iPhone users to comingsoon.html – bastards!).

So without further ado, here is the Javascript-generated login form:

Nothing really much to it – however, this is the HTML source for the two fields:

<input name="username" id="loginUsername" placeholder="Email" type="text">
<input name="password" id="loginPassword" placeholder="Password" type="password">

So by now you must be thinking “yeah, you really are an anal-retentive asshole, what about those?!“. Simply put, they are not iPad – or more exactly, iOS – optimized. One of the neat things Mobile Safari gives web developers is extra form field tags, which make the device aware of the type of input being sought, so it can adapt the keypad accordingly. This is how the login form looks on an iPad, once you tap on the ‘Email’ field (click for large version):

There are two issues here: first, we capitalize the first letter of the user’s email address, which is not really A Bad Thing™, but doesn’t look pretty. The second, and most important, is regarding usability. By using type=”email” instead of type=”text” in the form field, the user gets to see this:

which is how iOS optimizes itself for email address entry. Depending on your particular concoction of underscores and dashes, this can save you some time. The whole list of supported form types can be found here.

My second irk is the amount of screen space the header graphic takes once you get in:

Of course, you can scroll down right away and see the various articles, but having the titles of the first two cut off doesn’t look that good.

The third issue has to do with scroll position between page transitions. If you scroll down, say about half-way down, and want to read Who’s The Leader Of The Club That’s Made For You And Me (if you’ve seen Full Metal Jacket, the answer is of course Mickey Mouse):

you are dropped just below mid-page into the article, thus:

instead of here:

If you’ve read the article, the answer is, of course, Walt Disney’s head filled with blue water, a sort of eerie Magic 8 Ball.

The final issue has more to do with strategy and people’s spelling abilities – or lack thereof. Allow me to explain: how many of you have typed nswfcorp.com in your browser and have landed in a “server could not be found” page? OMG! Someone has registered that already by the time I’m typing this, I hope it’s not a spammer trying to take advantage of those who cannot spell or type that well, a-la-holders of .cm domains. Or a pissed-off ex-girlfriend of Paul’s who re-directs the domain to goatse or meatspin or worse.

Worry not, as I was typing this, I thought I’d do Paul a favor (OK, maybe he doesn’t give a shit, so maybe not) and register the domain, which I’ll transfer to him for free. When I started Whisher, it didn’t occur to me that a competitor could buy wisher.com (the correct spelling) and redirect it to his own site – a point our first VC painfully reminded me of, and which cost us $30k and convincing the Wisher sisters, owners & operators of a real estate agency in the US, and owners of the domain.

In all, nothing extremely hard to fix – I’m really looking forward to the next issue!




Getting your Facebook App logo icons right

This is a short post distilled from hours of frustration at the mangling of App logos by Facebook. Basically, if you want this:

instead of this:

make sure you flatten your image in Photoshop, and save as a 75×75 pixel GIF, with the dithering applied in “Save for web…”. Otherwise, Facebook will take your nice, transparent PNG and convert it to GIF with whatever dithering they choose, with results usually quite crappy. Feed the right GIF, and no conversion is required nor performed.

Installing Ubuntu on a Soekris net6501

After frustration with FreeBSD’s ports system on a slow box such as the net6501 (it took literally 7 hours and endless “continue” buttons to get subversion installed), I decided to try and install Ubuntu. No clear instructions can be found on the net as to how to do it over a serial terminal, the only option available with the Soekris, so after some mix & match of various hints and pointers, I managed to do it. Here is how.

1. My setup

My particular net6501 is the mid-range version, with a 1GHz processor, 1Gb of RAM, and an internal Transcend 16GB flash drive. I also got the case & power supply, of course.

2. Get the Ubuntu Server ISO

Easy, just grab it here (32-bit version).

3. Create a bootable USB drive

You will need at least a 1GB flash drive, 2GB is recommended. I use Sandisk or other well-known brands, less likely to give headaches. The easiest way to create the bootable USB drive is to use Ubuntu’s own Startup Disk Creator, found under System in your standard Ubuntu desktop distribution. I use Macs so I run mine inside Parallels, with no issues at all.

4. Edit the boot menu configuration

You need to find a file named txt.cfg in your bootable USB drive and open it in a text editor. You will find a line that reads:

kernel /install/vmlinuz

The line after that begins with append – it needs to end up like this:

append console=ttyS0,19200n8 file=/cdrom/preseed/ubuntu-server.seed initrd=/install/initrd.gz

You need 19200 as that is the default speed on the Soekris serial port.

5. Connect a serial cable to the Soekris

A null-modem cable is needed. I use a DB9 adapter male/female adapter and a normal serial cable.

6. Open a serial terminal

The terminal needs to support VT100 emulation. Unfortunately all terminal apps for Mac that support this are payware and suck. I ended up using Hyperterminal in a Windows XP Parallels VM. It was rock solid throughout the procedure.

Set the terminal to 19200/8/N/1, no flow control, VT100 emulation.

7. Connect the bootable USB to the Soekris

The external USB port next to the DB9 will do fine.

8. Boot up the Soekris

Once you see the 5…4…3… countdown, hit Control+P, and then type

boot 81

and hit enter. Check that 81 is your USB drive, it should appear at the start of the boot log in the terminal. Adjust as required. You should now see a boot: prompt, type “install” and enter – an Ubuntu text-based install should follow, continue with the normal setup procedure after this.

That’s all folks – the toughest part was to find the terminal settings for the menu, if you get errors related to unknown video modes, you have not edited the right file or have done so incorrectly. Enjoy!

For the record, apt-get installed subversion on the same box in 30 seconds flat. FreeBSD needs to fix its package management system. Vim on FreeBSD requires over 500 individual file downloads with over 500 fixes/patches to the base version – ridiculous!


Page 1 of 2612345»1020...Last »