Planeta GNOME Hispano
La actividad Hispana de GNOME 24 x 7

05 de junio de 2017

Almería bid for hosting GUADEC in 2018

Well, «Alea iacta est». The deadline for biding to host GUADEC 2018 closed 4th Jun. And we proposed Almería.

GUADEC is the annual developers conference in the European zone, but with common attendants from Asia and North-South America, of the GNOME Project. This is another step to promote Almería as an international technology place and to estimulate new local techies, approaching students and proffesionals to world-class development communities and to the ethos and practice of opensource development. In the age of a «Github portfolio» as a CV resume for developers, the practice in opensource development it’s probably the best to train new programmers, to enhance their employability, and the learning of development practices along veteran programmers and mature communities. And it’s important to show how opensource software is a key component for our digitally connected society.

Again our legal instrument, absolutely key to these activities, is the UNIA CS students association at the University of Almería. The same association I helped fund in 1993 lives a new golden age thanks to a new group of entusiast members. Their support and collaboration made possible to host PyConES 2016, which, as far as we know, has been the biggest software development conference never made in our city. This conference has been a moral milestone for us and now we feel we can, at least, be hosts of other world-class conferences with the appropiate quality. And another key component of these proposals is the current university campus endownment and the support of the present university gobernm team to which we are grateful for their help and support. This is another step to increase the projection of the University of Almería as an international knowledge hub.

Finally I want to express my hope to do a significative contribution to the GNOME project, which I’m related to for more than a decade. Hopefully for 2018 I would have updated my pending GNOME packages in Fedora 🙈

So, here it is, the Almería candidacy to host GUADEC 2018.

22 de mayo de 2017

Online-pasahitzen segurtasun politikak. Oinarrizko gomendioak

Pasahitzen inguruan, askotan entzun dut kexu hau: “ezin ditut hainbeste pasahitz gogoratu!”. Jakin badakigu zein den horren ondorioa: webgune ezberdinetan pasahitza aukeratzerako unean, burua asko nekatu nahi ez eta pasahitz berdintsua aukeratzea ( superpasahitza, ikusietaikasi!, hegoakebakibanizion2002…). Agian gidoia, azpimarra edo zenbaki sinple bat erantsiz. Edo alderantziz idatzi. Bai, badakit noizbait hori egin duzula. Ez, azkenengo puntua ez, denak.

Enpin, beste estrategia aurreratuago bat maila ezberdinetako pasahitzak erabiltzea litzateke. Alegia, babestu nahi dudan hori oso garrantzitsua bada, pasahitz sendo bat aukeratuko dut: _?=superpasahitzasinkronikopatologikoa2014! . Ez bada hain garrantzitsua, zerbait errazago: -IkusiEtaIkasietaOndoEntzun-. Eta gainontzeko webgune guztietarako, pasahitz ziztrin bat: emoiztazumuxutxuemaitie 🙂

Horrela, pasahitz bat esku zikinetan eroriz gero, beno, ez da munduko ezer onik galtzen. Baina ondo pentsatu: zer gerta daiteke? zure izenean bidalitako mehatxuak, mezu -oso- iraingarriak zabaldu, pribatutasun falta… Eta hori guztia kontutan izan gabe batzuetan “maila altuko” pasahitza beste webgune garrantzitsu batetan erabili duzula, edo hainbat webgunetan.

Ez baduzu pasahitzak sortu eta kudeatzeko politika sendo bat, zure pasahitzak ez dira inolaz ere sendoak. Are gehiago, zure eta zure inguruko segurtasuna ahultzen ari zara pasahitz bat berrerabiltzen duzun guztietan. Eta bai, ziur asko zure pasahitza, jada, cracker-en eskuetan egongo da. Ez al duzu sinisten? Zuk-zeuk proba dezakezu hemen. 3752 miloi kontuen pasahitzak daude bertan. Edo kasurik hoberenean, hash-ak. Baina hash baten esanahia eta zergatian ez naiz orain sartuko, beste artikulu batentzako utziko dut. Demagun zuzenean pasahitzak direla. Zure kontua bertan agertzen al da?
Nirea bai, 14 ALDIZ, leku ezberdinetan. Eta ez da nire errua izan ez bakar batean. Nire kontua kudeatzen zuten enpresek ez zuten, ikusten denez, hain ondo kudeatu.

Orduan, zer egin? Alde batetik, ez errepikatu pasahitzak. INOIZ. Beste aldetik, pasahitz sendoak hautatu. Eta azkenik, pasahitza-kudeatzaile bat erabili.

Pasahitz sendoak erabili

Noski, pasahitz sendoak erabiltzeak ez dituzula errepikatuko suposatzen du alde batetik. Eta bestetik, asmatzeko errazak ez direnak aukeratuko dituzula: hainbat karaktere ezberdin, letra larri eta xeheak uztartuz, ikurrak eta zenbakiak erantsiz. Nahiko luzeak. Adibidez:

f"E7`zUpsK<T/rX=

(16 karakterez osatutakoa). Nik asmatu dut txurro hori? Ez, http://passwordsgenerator.net/ webgunetik hartu dut. Ausaz aukeratzen ditu zuk esandako irizpideak betetzen dituen pasahitzak. Horrelako webgune asko daude, aukeratu nahi duzuna, edo zuk-zeuk asmatu pasahitzak.

Pasahitz-kudeatzaileak erabili

Aurreko pasahitza gogoratzea posible bada ere (nemonikoak erabiliz: fruit ” EGG 7 ` zip USA park skype KOREAN TOKYO / rope XBOX = ) ez da erraza. Eta ezin baditugu errepikatu (EZ! Ezin ditugu errepikatu!). are gutxiago. Orduan zer? Pasahitz-kudeatzaile bat erabili. Asko daude merkatuan, online, lokalak, software jabeduna, software librea... Ez dizut burua nekatu nahi. Nik erabiltzen dudana gomendatuko dizut: KeepassX. Software librea da (GPL), plataforma anitzetan dabil (Win, OSX, Linux). Erraz ikasiko duzu erabiltzen baina hona hemen argibide batzuk.

KeepassX aplikazioak bi fitxategi nagusi erabiltzen ditu: datubasea eta gakoa. Datubasean zure erabiltzaile/pasahitz/webgune hirukote guztiak gordeko ditu. Datubasea zifratu egingo du (inoiz galdu egiten baduzu, ez da ezer gertatuko, datuak zifratuak baitaude). Zifratzeko AES algoritmoa erabiltzen du (Advanced Encryption Standard, AES). Algoritmo hori simetrikoa da, alegia, pasahitz bat behar du zifratzeko eta pasahitz bera deszifratzeko. Segurtasunaren aldetik oso algoritmo sendoa da, lasai erabili dezakegu.
Beraz, KeepasX erabiltzen dugun guztietan gure pasahitzen datubasea deszifratzeko pasahitz nagusia eskatuko digu. Hori da, pasahitz sendo bat buruz ikasi eta gogoratu beharko duzu. Baina soilik bat.

Beste segurtasun neurri gisa gako fitxategi bat eskatu ahal dizu (defektuz horrela egiten du). Beraz, 2FA (Two Factor Authentication) edo bi faktoreetan oinarritutako kautotze prozesu bat erabiltzen duela esan dezakegu: alde batetik zuk dakizun zerbait behar du (pasahitza) eta bestetik zuk duzun zerbait (key edo gako fitxategia).

KeepassX aplikazio lokala da. Eta jada entzun ditut zure kexuak: “nik hainbat ordenagailuetan egiten dut lan, nola kudeatuko dut dena modu lokalean egiten badu lan?” Trikimailu bat erabiliko dugu hemen: KeepasX-ek behar dituen fitxategiak (datubasea edoeta key fitxategia) Dropboxen utzi. Gogoratu, zifratuta daude. Edo segurtasun neurri sendoago bat jarraituz: datubasea Dropboxen utzi eta key fitxategia USB batean (poltsikoan edo motxilan eramaten duzun USB horretan 😉

Esandakoa, erabili nahi duzun aplikazioa eta segurtasuna politika, baina mesedez, ez berrerabili pasahitzak.

PRO-TIP: KeepassX erabiltzea aukeratuz gero, ez dituzu online pasahitz sortzailerik erabili behar. Aplikazioak berak eskainiko dizkizu ausaz sortutako pasahitz sendoak.

03 de mayo de 2017

WebKitGTK+ remote debugging in 2.18

WebKitGTK+ has supported remote debugging for a long time. The current implementation uses WebSockets for the communication between the local browser (the debugger) and the remote browser (the debug target or debuggable). This implementation was very simple and, in theory, you could use any web browser as the debugger because all inspector code was served by the WebSockets. I said in theory because in the practice this was not always so easy, since the inspector code uses newer JavaScript features that are not implemented in other browsers yet. The other major issue of this approach was that the communication between debugger and target was not bi-directional, so the target browser couldn’t notify the debugger about changes (like a new tab open, navigation or that is going to be closed).

Apple abandoned the WebSockets approach a long time ago and implemented its own remote inspector, using XPC for the communication between debugger and target. They also moved the remote inspector handling to JavaScriptCore making it available to debug JavaScript applications without a WebView too. In addition, the remote inspector is also used by Apple to implement WebDriver. We think that this approach has a lot more advantages than disadvantages compared to the WebSockets solution, so we have been working on making it possible to use this new remote inspector in the GTK+ port too. After some refactorings to the code to separate the cross-platform implementation from the Apple one, we could add our implementation on top of that. This implementation is already available in WebKitGTK+ 2.17.1, the first unstable release of this cycle.

From the user point of view there aren’t many differences, with the WebSockets we launched the target browser this way:

$ WEBKIT_INSPECTOR_SERVER=127.0.0.1:1234 browser

This hasn’t changed with the new remote inspector. To start debugging we opened any browser and loaded

http://127.0.0.1:1234

With the new remote inspector we have to use any WebKitGTK+ based browser and load

inspector://127.0.0.1:1234

As you have already noticed, it’s no longer possible to use any web browser, you need to use a recent enough WebKitGTK+ based browser as the debugger. This is because of the way the new remote inspector works. It requires a frontend implementation that knows how to communicate with the targets. In the case of Apple that frontend implementation is Safari itself, which has a menu with the list of remote debuggable targets. In WebKitGTK+ we didn’t want to force using a particular web browser as debugger, so the frontend is implemented as a builtin custom protocol of WebKitGTK+. So, loading inspector:// URLs in any WebKitGTK+ WebView will show the remote inspector page with the list of debuggable targets.

It looks quite similar to what we had, just a list of debuggable targets, but there are a few differences:

  • A new debugger window is opened when inspector button is clicked instead of reusing the same web view. Clicking on inspect again just brings the window to the front.
  • The debugger window loads faster, because the inspector code is not served by HTTP, but locally loaded like the normal local inspector.
  • The target list page is updated automatically, without having to manually reload it when a target is added, removed or modified.
  • The debugger window is automatically closed when the target web view is closed or crashed.

How does the new remote inspector work?

The web browser checks the presence of WEBKIT_INSPECTOR_SERVER environment variable at start up, the same way it was done with the WebSockets. If present, the RemoteInspectorServer is started in the UI process running a DBus service listening in the IP and port provided. The environment variable is propagated to the child web processes, that create a RemoteInspector object and connect to the RemoteInspectorServer. There’s one RemoteInspector per web process, and one debuggable target per WebView. Every RemoteInspector maintains a list of debuggable targets that is sent to the RemoteInspector server when a new target is added, removed or modified, or when explicitly requested by the RemoteInspectorServer.
When the debugger browser loads an inspector:// URL, a RemoteInspectorClient is created. The RemoteInspectorClient connects to the RemoteInspectorServer using the IP and port of the inspector:// URL and asks for the list of targets that is used by the custom protocol handler to create the web page. The RemoteInspectorServer works as a router, forwarding messages between RemoteInspector and RemoteInspectorClient objects.

23 de abril de 2017

De vuelta a Linux: Ubuntu GNOME en MacMini y MacBook Pro

Después de mucho postergarlo, finalmente decidí dejar Mac OSX y volver a Linux.  Son varios los motivos y puedo decir tranquilamente que OSX no es para nada un mal sistema, de hecho para un usuario como yo es una excelente combinación de la potencia y flexibilidad de Unix con la disponibilidad de aplicaciones mainstream nativas en el sistema.

Pero yo quería otra cosa.

Ubuntu GNOME y Eclipse

Ubuntu GNOME y Eclipse

Con Linux me había acostumbrado a poder modificar lo que yo quisiera del sistema. Usándolo todos los días tiendo a aburrirme y en OSX como mucho podía cambiar el fondo de pantalla y el color de la barra superior, del resto prácticamente nada.

Por otro lado, para el tipo de uso que le doy al computador las herramientas en Linux están mucho más a la mano, en OSX están a través de brew o macports pero siempre son ciudadanos de segunda clase. Ni hablar de tratar de compilar PHP para que use SQL Server, Oracle y cosas por el estilo. Incluso algo tan simple en Linux como poder escribir unidades NTFS puede volverse un infierno en OSX.

En fin, al momento en que quise cambiar el look & feel de OSX para que fuera obscuro y así descansar más la vista y no pude, y al mismo tiempo el anuncio de Canonical de abandonar Unity fue el empujón que necesitaba para dar el paso. Ah! Y ya que estaba desconectado del desarrollo de GNOME por mucho tiempo, este review de Ubuntu GNOME me entusiasmó mucho más.

Y aquí estoy, escribiendo desde Ubuntu GNOME en mi computador principal.  Primero hice unas pruebas en mi portátil, cuya configuración la puedo armar en cualquier momento desde cero. Lo usé unos días y me convenció completamente, todo el hardware fue soportado sin hacer nada especial, incluso unos audífonos bluetooth que no funcionan en OSX sí funcionaron en Linux. Para qué decir del software, fue como sentirme de vuelta en casa con el añadido de que GNOME es quizás el mejor sistema de escritorio que he usado.  Ojo, antes que los Apple fan se me tiren encima, si no lo han probado no tienen como opinar. Sólo al usarlo te das cuenta de que en GNOME han hecho un excelente trabajo.

Advertencia

Antes de que me digan “ah no, es que yo uso la aplicación X” vamos a ser claros, cada uno usa el sistema que más le acomode y eso depende mucho de las aplicaciones que uno necesite para su trabajo diario. En mi caso tanto OSX como Linux me sirven, por lo que la elección de uno u otro sistema corresponde a otros factores, como los descritos arriba.

Para entender el caso, esto es lo que uso frecuentemente: Java SDK, Android SDK, Android NDK, Eclipse, GNU tools (build tools, bash, etc), MySQL PHP, un navegador, Dropbox, GIMP. En menor medida: Utilidad para analizar el uso del disco, monitores de sistema (temperatura, uso de recursos), etc.  Como pueden ver, todas estas herramientas están disponibles en ambos sistemas operativos, nativamente en Linux y a través de diversos mecanismos en OSX.

Seguramente hay algunos que quieran hacer la prueba o solucionar algún problema o duda respecto a instalar Linux en hardware de Apple, así que en el resto del artículo dejaré documentado lo que he ido ajustando en el sistema.

Instalación

Para no llenar de imágenes este post, a través de links dejaré screenshots de referencia. La instalación inicial se resume en los siguientes pasos:

Una vez instalado el sistema, se reiniciará el equipo y partirá con Linux.  Si quieren partir con OSX, usen nuevamente la combinación CMD+X a menos que les aparezca el menú de rEFInd. (A mi a veces me ha aparecido, a veces no).

Temperatura, ventiladores y uso de CPU

Con un sistema recién instalado lo primero que notarán es que el equipo se calienta. Eso es porque falta instalar una utilidad que controle el ventilador. Como preferencia personal a mi me gusta ver el uso de CPU y temperatura en el panel, así que vamos a instalar todo de una.  En un terminal:

sudo apt-get install lm-sensors cpufrequtils macfanctld tlp

Se trata de:

  • lm-sensors: permite obtener información de temperatura y velocidad de rotación de los ventiladores
  • cpufrequtils: permite ajustar la forma en que la CPU cambia de velocidad. La idea es que sólo use una alta velocidad sólo cuando sea necesario
  • macfanctld: con la información de temperatura, esta utilidad controla automáticamente la potencia de los ventiladores. Si la temperatura sube, aumenta la potencia de los ventiladores, y al bajar, reduce la potencia.
  • tlp: Se encarga de aplicar ajustes para reducir el uso de batería en portátiles

No se preocupen que en ningún caso usarán estas herramientas directamente, a menos que quieran modificar su comportamiento.  Lo normal es que instalen alguna aplicación de escritorio que usará estas herramientas para controlar el sistema.  En mi caso instalé extensiones de GNOME shell que entregan información de uso en la barra superior y permiten realizar ajustes del sistema en forma gráfica.  Mis elegidas fueron:

cpufreq

CPUFreq GNOME Extension

Al instalar estas aplicaciones pude entender un problema que siempre tuve con OSX en mi MacMini, y es que el equipo se calienta demasiado, al punto en que la tarjeta WiFi comenzaba a fallar. El MacMini en general es MUY silencioso a menos que esté trabajando en forma intensiva, y esto es simplemente porque el ventilador no comienza a funcionar sino hasta que la temperatura es muy alta.  Por lo tanto, en general el equipo andaba con alta temperatura pero en silencio.  Al instalar macfanctld lo primero que llama la atención es que el ventilador parece estar andando siempre, pero es simplemente porque la configuración de origen está hecha para mantener el sistema andando a temperaturas razonables, y para eso tiene que usar constantemente el ventilador.

Por lo tanto queda la opción de a) alta temperatura y silencio o b) baja temperatura y ventilador andando.  Como ahora estamos hablando de Linux, basta modificar el archivo de configuración de macfanctld para ajustarlo como uno quiera.  Se puede definir la velocidad de rotación mínima y dos temperaturas: La temperatura mínima en donde el ventilador estará en su potencia mínima definida, y la temperatura máxima en donde el ventilador funcionará a toda su potencia.

freon

Freon GNOME Extension

Sin tener datos exactos, pero recordando cómo funcionaba esto en OSX podría estimar los valores que estaba usando en mi equipo. Si quisiera resumir todos los valores tenemos:

  • OSX en MacMini: 1500RPM, min 80º, max 90º (estimado)
  • Ajustes originales de macfanctld: 2000RPM, min 45º, max 55º (macfanctld.conf)
  • Mis ajustes de macfanctld: 1800RPM, min 60º, max 70º (personalizado)
  • Config actual un poco más tibia pero más silenciosa: 1800 RPM, avg 70º – 80º, periferia 50º – 68º

Ahora el ventilador se mantiene más activo, pero ya no me quemo al tocar el macmini.

Para los que tengan este problema y estén usando OSX, entiendo que hay aplicaciones que permiten ajustar estos valores también, sólo que yo no supe de eso hasta que instalé macfanctld.

Dark theme

Lo que gatilló el cambio con fuerza fue contar con un escritorio obscuro para descansar la vista, y Ubuntu GNOME viene preparado para hacer ese cambio de una forma muy sencilla. Simplemente deben abrir la Herramienta de retoques de GNOME Shell y en Apariencia activar Tema obscuro global y luego en Tema -> GTK+ poner Adwaita-dark.

GNOME Dark settings

GNOME Dark settings

Java y Eclipse

Si bien Ubuntu incluye Eclipse, es una versión relativamente antigua.  Personalmente prefiero instalar la última versión de Eclipse desde el sitio oficial e instalar JDK 8 de Oracle.

Primero deben instalar JDK8 con los siguientes pasos gracias a WebUpd8:

sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java8-installer

Para instalar Elipse, descargan el instalador, lo descomprimen y ejecutan. Presentará varias opciones de instalación, yo seleccioné Eclipse for Java Developers.

Ajustes adicionales de Eclipse

Eclipse a secas no tiene todo lo que suelo ocupar, asi que en Ayuda -> Eclipse Marketplace siempre instalo las mismas extensiones a las que ahora se agregan aquellas para obtener un aspecto obscuro.  Una funcionalidad no muy conocida del Marketplace es que pueden marcar extensiones como favoritas, para que sea más fácil instalarlas en un Eclipse nuevo, simplemente abren los favoritos y ponen “Instalar todo”.

Mis extensiones favoritas de Eclipse son:

  • Eclipse C/C++ IDE (CDT)
  • PHP Development Tools (PDT)
  • Android Development Tools (ADT)
  • Subclipse
  • Eclipse Mooonrise UI Theme
  • Eclipse Color Theme
  • Eclipse Data Tools Platform (DTP)

Las últimas dos ayudan a darle el aspecto obscuro. Una vez instaladas van a Preferencias -> Apariencia -> Tema y seleccionan Moonrise Standalone.  Luego en Preferencias -> Apariencia -> Colores seleccionan el que sea de su agrado. Yo estoy usando Gedit Original Oblivion.

Eclipse en Ubuntu GNOME

Eclipse en Ubuntu GNOME

Música

Para no duplicar mi biblioteca de música, importé los archivos directamente desde mi antigua librería de iTunes.  Inicialmente podía ver la partición de OSX en Archivos -> Otras ubicaciones, pero la carpeta /Users/fcatrin/Music no tenía permisos de lectura. Para solucionarlo inicié en modo rescate de OSX (CMD+R), entré a mi carpeta personal via terminal y apliqué:

chmod 755 Music

Luego reinicié y agregué la carpeta en Rhythmbox

Biblioteca iTunes en Rythmbox

Biblioteca iTunes en Rhythmbox

De origen no viene incluido un ecualizador, pero hay uno disponible a través de plugins. Acá pueden encontrar ese y otros bastante interesantes: Installing rhythmbox 3.0 plugins … the easy way!

Android

Para Android un par de problemas al intentar levantar un emulador:

Primero no me dejaba crear una máquina virtual (AVD), fallaba al crear la tarjeta SD.  Eso fue porque la utilidad que crea la tarjeta SD es de 32 bits y requiere bibliotecas de 32 bit que no son instaladas como parte del SDK. La solución es sencilla:

sudo apt-get install lib32stdc++6

El segundo problema fue la aceleración de video que no queda lista para llegar y usar.  Se requiere instalar glxinfo y actualizar una biblioteca del SDK copiando la que ya tienen en el sistema.  Se reduce a:

sudo apt-get install mesa-utils

cd ~/android-sdks/tools/lib64/libstdc++/
rm libstdc++*
ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 .

Con eso quedará instalado glxinfo, y actualizada libstdc++ apuntando a la que está instalada en tu sistema.

Otros ajustes

Hay otros ajustes que se pueden hacer al sistema para que quede más sintonizado con los sitios web existentes, el idioma local, entre otros. En esta lista están:

  • Instalar los paquetes de corrección ortográfica al español
  • Instalar las fuentes de Microsoft
  • Instalar fuentes adicionales
  • Instalar Dropbox.
  • Ajustar campos de texto en Firefox

Para el primero y segundo basta con:

sudo apt-get install ttf-mscorefonts-installer aspell-es myspell-es

Para el tercero, descargar y abrir los archivos TTF incluidos. Se abrirán con el instalador de fuentes.

Para Dropbox pueden ir al instalador de aplicaciones Software que se encuentra en los iconos de la derecha y buscar por Dropbox. El sistema descargará e instalará Dropbox automáticamente.

Dropbox muestra un ícono de actividad en la barra de notificaciones que no existe como tal en GNOME, pero para variar, hay una extensión que la habilita, se llama TopIcons Plus.

En cuanto a los idiomas, usualmente escribo en inglés y en español indistintamente, lamentablemente Firefox sólo permite usar un idioma a la vez. Hay una forma de unir los archivos de corrección ortográfica como un solo idioma pero no lo he hecho aún.

En Evolution fueron más flexibles y se puede configurar más de un idioma al mismo tiempo.

Al usar un tema obscuro en Firefox se puede tener problemas con los campos de texto, ya que a veces los sitios modifican sólo el color defondo o sólo el color del texto y quedan invisibles porque asumen que el fondo es blanco.  Acá hay varias opciones para solucionar el problema de campos de texto en theme obscuro, personalmente me quedé con agregar un archivo userContent.css.

Creo que eso es todo por ahora, seguramente iré agregando más detalles en este post. Espero quedarme con Linux por un buen tiempo.

Finalmente: Tal como lo recordaba, los fonts en Linux se ven mucho más suaves y definidos que en OSX.

21 de abril de 2017

Loa: Recuerdos del pasado

Después de mi post sobre Programando en los ’90 aparecieron varios sansanos con más recuerdos de esa época, y me acordé de una joyita que tenía guardada hace años y que al parecer ya desapareció de la red.  Les dejo acá la transcripción integra:

From utfsm!not-for-mail Mon Jul 28 18:30:21 1997
Path: utfsm!not-for-mail
From: edo@ce2usm.valparaiso.cl (Eduardo Romero U.)
Newsgroups: usm.general,usm.cachureo
Subject: Loa: Redescuerdos del Pasado
Date: 11 Jul 1997 20:21:18 GMT
Organization: Utfsm Amateur Radio Group.
Lines: 201
Distribution: local
Message-ID: <5q64ju$sj3$3@manutara.inf.utfsm.cl>
NNTP-Posting-Host: ce2usm.valparaiso.cl
X-Newsreader: TIN [UNIX 1.3 BETA-950824-color PL0]
Xref: utfsm usm.general:878 usm.cachureo:859

Para mas estrugarse las lagrimas, un recuerdo de los annos mozos del VM.
Saludos
Edo.
=========================================================================
From:         Francisco Javier Fernandez M <FFERNAND@LOA.DISCA.UTFSM.CL>
Subject:      Curso de redes

Hiya!
    Se han dado cuenta de los mensajes del curso de redes. Hay que hacer
notar que han evolucionado.
    Quien no recordara esos estupidos mensajes como

subject: nada
"Esto es una prueba... chao"

subject: (vacio, porque la inteligencia no les da pa saber que es subj)
"Hola, soy nuevo y me llamo XXX estoy en ing. civil en xxx .. chao amigos"

subject: REDES
"LES LLEGA ESTE MENSAJE"

    Notese la estupidez cronica mostrada en los mensajes. Es como cuando
un idiota se para frente a un microfono, pone cara de burro mascando
limones , sopla 3 veces (ni 2 ni 4, tiene que ser 3) y dice "1 2 3
probando probando"
    Ademas andan con sus libritos de redes pa' toas partes.

weon:    "De donde vienes?"
aweonao: "Del curso de Redes Internacionales" Lease con voz
          de cuico y cara de imbecil
weon:    "Ahhhh" (cara de idiota al cubo) "Y que es esa wea?"
Aweonao: "La verdad es que no te lo podria decir en pocas palabras
          pero es una wea mas chora que la cresta. Ademas me van a dar
          un diploma que me va a servir para mi curriculum"
weon:    "Shuta! que capo eres. Me podrias invitar a la sala IBM pa ver
          como es la weaita" (cara de tarupido {tarado+estupido})
aweonao: "Pero no faltaba mas viejo, por supuesto"

     Aweonao lleva a weon a los VM. Aweonao no pesca su cuenta I5bit0xx
o redintxx pero weon se mete todos los dias a los tarros, se hace de
n amigos, se hecha el semestre y se cambia a ejecucion.

    Y esta historia es ciclica. Llueven los aweonaos y los weones.
Pero no todos son iguales. Tambien hay aweonaos que no se sacan el 55
en la prueba y no les dan cuenta .. (o no J...s C....y ?)

Tambien hay weones que le cambian la password, emocionadisimos por
usar el nuevo comando DIRM PW y despues se les olvida y se cuelgan
del timbre para preguntarsela al op.

Tambien estan los que usan el Chat para conversar y le mandan
mensajes weones al operador y mandan un CMD UCHCECVM Q SYS al relay...

Ademas, revisando unas consolitas, hemos visto que hay weones
que mandan el tipico "Hola, me llamo xxx. Estas ocupado(a)?"
a maquinas como MAILER, TCPIP o VTAM.

Primera fase: El prehistorismo vmniano
      Se caracterica por ejecutar comandos como DIR, no sacarle
el pito a las teclitas, usar el contraste y brillo a maximo para
cagarse los ojos, buscarle como loco la disketera al terminal y
preguntar "Pa que es esa tapita?" ... "Y esta perillita?"

Segunda fase: Edad media
        Wow! nuestro amigo descubre que la perillita es para el
volumen del beep. Aqui se pasa horas y horas weiando con el
pitito. Nuestro habil amigo descubre el DISCADOC (y se entretiene
mas encima ! como sera de weon). Busca algun nodo de estados unidos
y se pone a mandar CPQ N como loco. Busca su victima y empieza con
esos tipicos "Hello, are you busy?" (notese ... weas ya es bilingue)
     En esta etapa ya empieza a traer amigos para que vean lo pulento
que es, y a la polola tambien a ver si se exita con la wea.
       Pero luego ... Oh! descubre el relay

Tercera fase: Como hacha pa'l relay:
       Esta fase es cronica. Empieza a divagar por el relay y no lo
saca nadie del terminal. Manda fotos pa' EEUU y le llegan postales.
Su satisfaccion es inmensa, y llega a un cuasi-orgasmo cuando
hay linea por la uchcecvx, por que sabe que podra jugar con el relay.
       Nuestro amigo ya deja el discadoc. Pero recuerda que en su
casa tiene un sinclair Z80. Aqui empiezan los dialogos a consultoria.

weon: Tell consulte Necesito ayuda
Imsg: Consulte not in cp directory
weon: Tell consulta Ahh! entiendo, estas ocupado, verdad?
Imsg: Consulta not loged on
weon: Tell consulta Oye! no tienes porque decirme weon!
.... y se repite el ciclo

       Por fin se da cuenta de lo que hacia y se caga de la risa.
Lo primero que hace es contarsela a otro como que "A un amigo le paso"
       Computin descubre el listserv. WOW! que impresionante!
De nuevo a la carga con el DISCADOC (fascinado). Se mete a
20 o 30 listas. El reader se le llena y en vez de conversar por relay
se la pasa todo el dia leyendo correo.

Weon: "Esto se acabo!"
weon: pur rdr all
weon: tell listserv signoff * (netwide

Cuarta fase: Weas descubre internet
      Si Bitnet era la raja, esto la cago! Lo primero es el irc.
El irc es fundamental, ya que es la primera vez que usa el comando
HX, que sera el mas usado en su estadia en los VM. Porque se
queda colgado 20 veces al dia. Aqui conoce el tipico.:

weon: DIN DON DIN DON DIN DON
op:   SI?
weon: Buenos dias. Soy xxx de la cuenta xxx y soy tan idiota que se
      ma quedo pegada la cuenta. Le puede hacer un force , plis?
op:   Okay.  BEEEEEEEP (que pito mas desagradable)

       Luego entra al fascinante mundo de FTP. Se pasa horas cagandose
los ojos frente al SIMTEL LISTING. Wevea y wevea hasta que trae
todos los archivos que se le antojan. (en este momento aprende que es
un disco temporal y que con un disco de 10 Mb te llega un warning
del op).
     Y llegamos al telnet! aqui empieza lo bueno. A mister weveta
le dan todos los ataques de hacker y hace un telnet al primer host
que pilla y sucede lo siguente

Dick SUN/OS SYSTEM INC. vers 1.3 release 4.7
login: root
password: root    (wow! notese la habilidad)
login incorrect

login: root
password: sun/os. (y jura que se va a meter!)
login incorrect

login: root
password: pico   (aqui le sale el chilenismo)
login incorrect

Connection closed by foreign host

       Si ustedes creen que se chorio, estan equivocados. Aprieta
PF1 y sigue dandole.
       Luego siguen estupideces varias como gopher, archie, whois, etc.

Quinta fase: Weas programador
       Weitas se aburre de ser un simple usuario, y motivado con
modificar 500 veces el profile , quiere aprender rexx.
       Aqui conoce a Mitzio. Un hito en programacion, hackeo, weveo,
replys y derecho de autor de programas y manuales.
       Aprende un poco de rexx y el primer programa que hace no le
funciona.
weas:   "Mitzio! No funciona!"
Mitzio: "Mmmm pero si es re facil. te falta solo un strip(arg*var(parse
         (a-2||fr"cp log"Execio34) exit(0):
weas:   "Ahh . como no se me ocurrio antes"
.... y asi sucesivamente.

Sexta fase: VM? buah!
         Esta fase es crucial. Aqui weas tiene que decidir si se queda
en los vm o se mete a otras plataformas.
         Va a los Ps y se encuentra con la paternal figura de C. Libano:
C.L.:  "Usted es mechon"
weas:  "Si, de ing. ejec en xxx"  (con una cara de orgullo tremenda)
C.L.:  "FUERAAAAAAAAA!!!!"
weas:  "Pero .."
C.L.:  "FUERAAAAA!"
weas:  "Okay. Salvo este archivo y me voy"
C.L.:  "Fuera... AHORA!"

         Y se va ...
         Pero baja un piso y se mete a informatica. "Chucha los
terminales ricos" (refiriendose a los wyse) . Y no resiste a
meter el nombre de su cuenta en el LOGIN: que lo llama a
probar. Pero. se da cuenta que no tiene cuenta abajo. Oh! desilucion
         Pregunta a un gallo con cara de esperar que compile su
mega programa en C.
weas:  "oye, yo tengo cuenta en los ibm, no sirven aca"
gallo: "Ja! ja! Esto es UNIX compadre, ubicate"
weas:  "Que e' esa wa?"
gallo: "Como?, no sabes? El sistema operativo del futuro, viejo"
weas:  "Ahh, fijate que yo se Msdos y VM/SP"
gallo: "Ah! de veras que eso se usa alla arriba, en Jurasic Park"
      Y weas mira la pantalla y ve que para un misero directorio
el gallo hace un ls -la & (obviamente el & tiene que ir. Cuando
se ha visto un informatico que no deje procesos en backgroud
pa puro weiar)
       Weas se trauma. Dice que esto no es para el.
       Y sigue en su cuenta de Vm. Seguiran los FTP, los
Telnets, las conversaciones de relay...
       Un dia llega a su terminal y ve que redintxx no esta en
el directorio de cp. Cae en un profundo trauma y muere.

P.d.: Otras innovaciones de weones son: Los que se meten al circulo
      de radioaficionados y ocupan la CE2USM. Los que se meten al
      encuentro de estudiantes y ocupan la EIEI. Idem con la IEEE
      Tambien algunos se consiguen la cuenta de un profe, el profe
      se va de la USM y siguen con cuenta per secula seculorum
     (o no J...o Z....a ?)

Sin mas que agregar

    Hawk

 

Programando en los ’90

Programar siempre me ha sido entretenido pero difícil. No me malentiendan, puedo lograr buenos resultados pero eso no implica que sea fácil, sólo que soy lo suficientemente porfiado para seguir adelante hasta lograr lo que quiero hacer. El poder convertir en real algo que antes sólo existía en la imaginación es una de mis principales motivaciones, y si esto plantea algún desafío técnico interesante, mejor aún.

Creo que uno de los motivos por los que ya no me entusiasma por ejemplo entrar a la programación de videojuegos, es que ahora tienes libertad para hacer cualquier cosa, y básicamente lo que se trabaja es el gameplay y el contenido. A mi en realidad lo que me llamaba la atención era el desafío técnico, como por ejemplo tratar de hacer un port de un juego de arcade al Atari (800): Cómo usar adecuadamente los 4 colores por línea, o los cuatro canales de sonido, o sacar el jugo a su CPU de 1.79Mhz con apenas 3 registros.  Recuerdo que podía pasar una tarde entera trabajando en una “rutina” de assembler en un cuaderno hasta llegar a su mejor versión.  Era una época en que una simple optimización podía significar que algo fuera factible o no.

 

2017-04-20 22.06.15

Reproductor de música FSTR

 

Bueno, eso era en los ’80 y reservaré ese relato para un próximo articulo de Prince of Persia para Atari.  Ahora vamos a ir “no tan lejos” pero sí a una época que ya no existe y que creo que sería difícil imaginar para quien no la vivió, y para los que la vivimos se nos ha ido olvidando con el tiempo.  Ahora es tan simple aprender algo que no nos acordamos de cómo se hacían las cosas cuando no existía stackoverflow, no había a quién preguntar y peor aún, no había documentación de ningún tipo.

Internet a inicios de los ’90

La primera mitad de los ’90 es una época que recuerdo con mucho cariño, se comenzaba a hacer accesible tener computadores más potentes y comenzaba a haber algo de información disponible para aprender a programarlos, por ejemplo en la biblioteca de la UTFSM podías encontrar algunos libros de Intel sobre la programación x86 y lo más importante, algo de código fuente para mirar en algunos rincones de Internet.

 

Intel 286 programming

iAPX 286

 

A ojos de hoy eso suena muy natural, pero era muy diferente a lo que tenemos hoy en día.  De partida el acceso a Internet no existía en las casas, sólo en las  universidades,  y siendo mechón como yo… ni siquiera podías usar internet en la universidad.  Entonces, no era llegar y escribir en un buscador lo que andabas buscando, no señor! No había tal buscador, ni siquiera tenías un navegador, la información estaba principalmente en servicios de grupos de noticias (usenet / newsgroups) – imaginen algo como un foro universal de internet de sólo texto – y sitios de descarga por ftp que se usaba por linea de comandos.  Para buscar, existía una aplicación llamada Archie que buscaba archivos, entonces sólo si el sitio contaba con un índice decente, podías llegar a encontrar algo.

 

tin

Newsgroups en Usenet (via TIN)

 

Ahora, como Internet no era tan grande como en la actualidad, los sitios que tenían información sobre programación de PC eran pocos y por lo tanto muy conocidos. Había un repositorio en especial que estaba replicado en varios servidores de FTP, se llamaba Simtel y era un paraíso.  No sólo había código fuente para mirar, sino que también documentación! Todo eso disponible al alcance de un comando GET.  El problema era que no podías llegar a ese punto si el acceso a esos sitios estaba bloqueado o peor aun, eras mechón como yo.

Siendo mechón en la UTFSM a inicios de los ’90

Y es aquí donde creo que por primera vez hablaré en público de las historias no contadas de mis tiempos en la UTFSM, cuando sabías que el conocimiento estaba disponible, sólo que no lo podías alcanzar. Esto era más o menos entre 1993 y 1994, y la UTFSM pagaba por tráfico internacional por lo que éste estaba permitido sólo para alumnos que tuvieran ramos o actividades que lo justificaran. El acceso para el resto de los alumnos era sólo a las réplicas nacionales en donde estaban los newsgroups (saludos a chile.comp.pc), pero no estaba Simtel.  Entonces algo había que hacer.

Aparte de no tener acceso a Simtel por estar en redes internacionales (que divertido suena eso ahora), estaba el inconveniente de que si llegabas a conseguir algo de información, sólo te podías llevar una copia en la mente, porque no podías pasar esa información a diskettes – ni hablar de pendrives, aun faltaban varios años para que siquiera inventaran el puerto USB. El único acceso era un terminal de texto monocromo en donde al menos podías descomprimir y leer los archivos in situ. Dado el estado de la tecnología todo era archivo de texto, incluso las revistas, así que bastaba con eso.  Aún así, persistía el problema de llegar a Simtel.

 

Terminal-wyse50

Terminal de texto Wyse 50

 

Los laboratorios de “investigación”

Y es aquí en donde aparecen los amigos de siempre: Luis Cueto, Max Celedón, Cesar Hernández.  Ellos por estar en cursos superiores tenían otros amigos que tenían acceso a otros laboratorios, en donde se hacía “investigación” y por lo tanto sí tenían acceso a los nodos internacionales.  Entonces, desde ahí se podía llegar a Simtel, pero tampoco había forma de llevarse archivos a la casa para estudiarlos con calma, ya que eran terminales de IBM conectados a un mainframe, al que sólo tenía acceso un grupo selecto de operadores – capa blanca incluida – a los que tenías que llamar con un timbre para que te mataran un proceso si éste se caía… cosa que ocurría habitualmente dado el número de veces que se escuchaba sonar el timbre famoso.

 

2bb5fd362fb409376af3b0108f19982f

IBM: Nunca los vi, pero es para hacerse una idea

 

Y es aquí donde entra a jugar la audacia de Max. La maquinaria de descarga de información funcionaba de la siguiente forma:  Max, Luis o César se conseguían una cuenta de IBM con algún amigo “investigador”, eso nos permitía usar ese laboratorio para llegar a Simtel siempre y cuando estuvieras dispuesto a suplantar presencialmente al verdadero dueño de esa cuenta. Yo no era de los valientes puesto que era muy joven para darme cuenta de que los usuarios de ese laboratorio no se caracterizaban por sus habilidades sociales, por lo que difícilmente te preguntarían el nombre. Esas cuentas iban muriendo pero Max siempre aparecía con una nueva, cuentas con nombres como i5elo200 o i5esp101 eran algunas de las regalones, e incluso Max tuvo una propia más tarde, i5mceled.

 

Captura de pantalla 2017-04-20 22.28.05

Inicios en la comunidad MSX con cuenta de “alguien”

 

Una vez encontrados y descargados los archivos en ese laboratorio IBM, tenías que pasarlo a tu cuenta Unix en el laboratorio que no tenía acceso a los nodos internacionales, pero sí tenían disketteras. Transferir los archivos era fácil porque esos laboratorios estaban conectados, y mientras no revisaran los logs del servidor ftp de Unix no habría problema.  Una vez con los archivos en la cuenta, venía el paso final que era pasar esos archivos a diskette.

Pidiendo favores a los verdugos

El último paso era pasar los archivos a diskette, y el más complicado porque tenías que pedírselo a una persona. Y no era a cualquier persona. En una zona especial del laboratorio Unix (labsw para los amigos), había un grupo de unas 4 personas que estaban tras un vidrio, intocables, omnipotentes, omniscientes. Esa división no era antojadiza, eran los únicos con acceso a todos los nodos de internet y a las estaciones de trabajo Unix de la época. Mientras los alumnos regulares como uno usaban un terminal de texto, ellos usaban equipos con 128MB de RAM, pantallas de 21 pulgadas, discos duros gigantes y mouse con puntero láser, cuando lo normal en las casas era tener 1MB de RAM, pantalla de 14 pulgadas y mouse con bolita.  Sí señor, ellos eran unos elegidos – literalmente porque había que postular al cargo – y tenían el poder de cerrar tu cuenta en cualquier momento (omnipotente) y saber todo lo que estabas haciendo (omnisciente).

 

Sun SPARCstation

 

Sí, a ellos tenías que pedir que te copiaran a diskette los archivos que obtuviste desde nodos prohibidos, usando cuentas que no eran tuyas, suplantando a personas que ni siquiera conocías. Y algunos de ellos eran famosos por ser de malas pulgas, con varias víctimas a quienes se les cerró la cuenta por mucho menos. Siempre recordaremos con cariño al famoso Arcadia, de quien no daremos detalles para proteger su verdadera identidad.

Pero esto no era problema para Max, a su modo de ver las cosas, bastaba con decir que necesitabas copiar una tarea de tu cuenta Unix a un diskette y listo.  Su apuesta era que el ayudante no se iba a dar el trabajo de revisar los archivos, sólo era cosa de usar los nombres adecuados, y así era como el archivo tarea.zip podía incluir los artículos de optimización y gráficos de Michael Abrash y nadie se enteraría.

Y así fue!

Con el tiempo, comenzamos a descargar información de hardware de PC para aprender a programar la VGA, Adlib, Soundblaster, llamadas a la BIOS, llamadas a DOS, luego comenzó a surgir información más interesante aún como partes no documentadas de la VGA, el famoso ModoX, smooth scrolling, algoritmos de sonido, hacking, se pueden imaginar el paraíso que eso significaba para alguien que antes sólo contaba con el manual de usuario del PC.

Y como sucede muchas veces – sino pregúntenle a Penta y SQM – con el tiempo agarramos confianza y comenzamos a descargar tablaturas, demos (de la demoscene), juegos shareware, música en formato MOD, MIDI… todo era tarea. Tarea, tarea, tarea.

Pinche aquí para ver el vídeo

La bienvenida

Hasta que un día, Max llegó al laboratorio Unix y ahi lo estaba esperando Arcadia junto al resto del olimpo. Pero no estaban solos, ya que con ellos se encontraba el ser superior (literalmente): Horst von Brand dueño y señor del laboratorio Unix, fundador y prócer de ése y otros imperios. Si Horst quería hablar contigo era porque habías hecho algo muy bueno, o muy malo. Siendo éste último nuestro caso.

Tal honorable bienvenida tenía un propósito claro y preciso: Presentar ante Max los logs de transferencia de todas las “tareas” a la fecha, que ya sumaban megas y megas internacionales, multiplicados por su equivalente monetario.  Según cuenta la historia, gran porcentaje del millonario costo por transferencia de datos de toda la universidad se debían a nuestras “tareas”.

 

227518_1030506880700_7197_n

Con Max en el verano de 1994

 

El resto de la historia sólo la conoce Max y el comité de bienvenida.  Por supuesto, su cuenta fue cerrada y a la larga la mía también, pero por otros motivos que podré contar en un nuevo post.

i5esp101@loa, i5meceled@loa, hydefus@inf, human@inf nunca los olvidaremos.

Y qué hice con toda la información descargada? Todo lo que pude y quise! Desde algunos experimentos como rutinas de reproducción de mods que nunca fueron utilizadas, hasta una aplicación para reproducir músicas de MSX (computador de 8 bits) en nuestros PCs.  Incluso las rutinas de sonido que pude ver en esa época me ayudaron años después a hacer DeFX – que más tarde me llevó a tvnauta – y después resucitó como MusicTrans.  Las partes en C de MusicTrans y RetroX le deben mucho a lo que aprendí en esos años también.

Cuando uno recuerda lo que costaba aprender a programar en ese tiempo comparado con lo que tenemos hoy, no hay excusas si quieres hacer algo interesante, las respuestas están al alcance de un click!

PD: Muchos detalles han sido omitidos para facilitar la lectura. Algunos eventos o especificaciones pueden ser no tan precisos, lo serían si no hubiese esperado 20 años para escribir este post.

Como teaser, les dejo un demo de la aplicación de música, a la que le dedicaré un próximo artículo.

Pinche aquí para ver el vídeo

16 de abril de 2017

Sobre OSL-UNIA

Por puro descuido no he hablado aqui del trabajo que estamos haciendo en la Oficina de Software Libre de UNIA para la Universidad de Almería. En parte es otra de mis bravuconadas burras, otro intento de forzar la máquina social con aspiraciones de progreso. Por otro creo realmente que es una actividad interesante, otro paso para contribuir a la modernización de la Universidad de Almería y la expansión de conocimientos y aptitudes para los estudiantes de informática y otros estudios tecnológicos en esta universidad. También creemos que nuestra aproximación es relativamente novedosa, aunque hay mucho más que podría hacerse.

En la práctica las actividades que estamos llevando a cabo consisten en:

  • prácticas de empresa curriculares
  • congresos

y en cuanto a congresos, llevamos una racha magnífica:

y hay algún otro más en consideración.

En ningún caso nada de esto podría ser realidad sin el compromiso de la asociación UNIA y el apoyo de la propia Universidad de Almería.

Otra líneas de trabajo que debemos desarollar son:

  • cursos y talleres de tecnologías opensource;
  • promover la participación de estudiantes en convocatorias como Google Summer of Code; se da la buena fortuna de que en Almería hay dos proyectos software que participan como anfitriones: P2PSP y MRPT;
  • promover la participación en concursos universitarios de programación como el certamen de proyectos libres de la UGR y el concurso universitario de software libre;
  • promover que prácticas de asignaturas, proyectos de fin de grado y de doctorado se realicen como proyectos opensource o, aún mejor, en comunidades de desarrollo ya existentes.

Si tenéis interés en saber más o participar dirigíos por favor a nuestro subforo de discusión.

En fin, estamos trabajando en ello.

21 de marzo de 2017

Cómo hacer un backup de tus mensajes de Telegram

Supongamos que quieres hacer un backup de los mensajes de un grupo (canal, supergrupo, conversaciones privadas, usuarios, whatever…) de Telegram.  Puede haber distintas razones para ello: simple copia de seguridad para estar tranquilo, porque vas a irte de un grupo, porque van a cerrar el mismo… o, como en mi caso, con fines estadísticos.

Hasta donde yo sé, Telegram no ofrece herramientas directas para esta labor, pero al usar un protocolo abierto y bien documentado, hay gente que se ha pegado el curro de implementar aplicaciones cliente desde cero. Una de esas aplicaciones es tg, escrita en C, software libre y ejecutable desde la línea de comandos. tg es “simplemente” un cliente de Telegram, pero ofrece -entre muchas otras funcionalidades interesantes- la opción de ser ejecutado en modo servidor. De esta forma, mediante scripting, nos será posible obtener toda la información que tengamos almacenada en esta plataforma de mensajería instantánea. Pero no adelantemos acontecimientos 🙂 Lo primero será compilar esta bestia, cosa nada fácil (al menos en OSX, donde estoy ahora mismo).

Descargamos tg y seguimos los pasos de compilación e instalación. En resumen:

git clone --recursive https://github.com/vysheng/tg.git
cd tg

En OSX necesitarás instalar dependencias usando brew como sistema de gestor de paquetes:
brew install libconfig readline lua python libevent jansson
Verás multitud de warnings relacionados con posibles conflictos de versiones (sqlite, readline, SSL…). Brew nos avisa de que OSX ya viene con algunas de esas librerías instaladas y que si queremos usar o compilar las de brew tendremos que cambiar las variables de entorno (PATH, LDFLAGS , CFLAGS, PKG_CONFIG_PATH). Bueno, por ahora haremos caso omiso a esos warnings. Y pasamos al siguiente paso:

./configure

Idealmente te debería mostrar un mensaje de que todo va bien.

Y llegamos al make, donde seguramente obtengas un error indicando algo similar a:

lua-tg.c:664:27: error: unused function 'get_peer' [-Werror,-Wunused-function]

Un error en la línea get_peer. Si es el caso, tendrás que aplicar este parche, así:

patch < lua.patch
Patching file lua-tg.c

y volver a ejecutar el make. Si todo va bien, obtendrás un mensaje como el siguiente y de premio, el ejecutable telegram-cli en la carpeta bin.

La primera vez que ejecutes tg tendrás que asociarlo con tu número de teléfono. No olvides indicar el prefijo +34 si estás en España. Te llegará un PIN de verificación al teléfono (a través de un mensaje Telegram). Es el PIN que deberás indicar en la línea CALL correspondiente.
u026627:bin juanan$ ./telegram-cli
Telegram-cli version 1.4.1, Copyright (C) 2013-2015 Vitaly Valtman
Telegram-cli comes with ABSOLUTELY NO WARRANTY; for details type show_license'.
This is free software, and you are welcome to redistribute it
under certain conditions; type
show_license' for details.
Telegram-cli uses libtgl version 2.1.0
Telegram-cli includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)
I: config dir=[/Users/juanan/.telegram-cli]
[/Users/juanan/.telegram-cli] created
[/Users/juanan/.telegram-cli/downloads] created
phone number: +34XXXXXXXXX
code ('CALL' for phone code): XXXXX
User Juanan Pereira updated flags
User Juanan Pereira online (was online [2017/03/20 14:15:45])

Ahora dispondrás de multitud de comandos (teclea help para ver la lista completa). Puedes probar que todo ha ido bien tecleando comandos como get_self, para obtener información sobre tu cuenta en Telegram, contact_list para ver un listado con el nombre de tus contactos o channel_list para ver el nombre de los canales y grupos a los que estás suscrito.

Es interesante remarcar que tg dispone de autocompletamiento en la línea de comandos (soporte readline), por lo que basta con teclear las primeras letras del comando y pulsar TAB para que rellene el resto. Para salir, teclear quit.

Para poder cumplir con el objetivo marcado al comienzo de este post (backup de los mensajes de un grupo) necesitaremos instalar un script que maneje tg de forma automática. Se trata de telegram-history-dump, escrito en Ruby:

git clone https://github.com/tvdstaaij/telegram-history-dump

Debemos asegurar que disponemos de una versión reciente de Ruby (>= 2.0).

ruby --version
ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16]

Ahora podemos decidir hacer backup de todo o sólo de algunos grupos en concreto. Yo sólo necesito backup de un super-grupo, así que edito el fichero de configuración del script config.yaml e indico en la sección [backup_supergroups] que quiero sólo el grupo “MI_GRUPO”. En el resto de secciones, indico null.

Para finalizar, lanzamos tg en modo servidor:

./telegram-cli --json -P 9009

(escuchando en el puerto 9009 e intercambiando mensajes en formato JSON)

y ¡por fin! lanzamos el script de backup:

u026627:telegram-history-dump juanan$ ruby telegram-history-dump.rb
I, [2017-03-20T14:27:23.381792 #24590]  INFO -- : Attaching to telegram-cli control socket at localhost:9009
I, [2017-03-20T14:27:23.849295 #24590]  INFO -- : Skipping XXX dialogs: .....
I, [2017-03-20T14:27:23.849485 #24590]  INFO -- : Backing up 1 dialogs: "MI_GRUPO"
I, [2017-03-20T14:27:23.849783 #24590]  INFO -- : Dumping "MI_GRUPO" (range 1-100)
I, [2017-03-20T14:27:24.854833 #24590]  INFO -- : Dumping "MI_GRUPO" (range 101-200)
I, [2017-03-20T14:27:25.860089 #24590]  INFO -- : Dumping "MI_GRUPO" (range 201-300)
I, [2017-03-20T14:27:26.864448 #24590]  INFO -- : Dumping "MI_GRUPO" (range 301-400)
I, [2017-03-20T14:27:27.869046 #24590]  INFO -- : Dumping "MI_GRUPO" (range 401-500)
I, [2017-03-20T14:27:28.872592 #24590]  INFO -- : Dumping "MI_GRUPO" (range 501-600)
I, [2017-03-20T14:27:28.977374 #24590]  INFO -- : Finished

Tras unos segundos (veremos el progreso en la terminal donde tengamos lanzado telegram-cli) obtendremos el resultado en la carpeta output/ . Si disponemos del comando jq (si no, lo instalamos con brew install jq) podremos visualizar el JSON resultante cómodamente así:

cat output/json/MI_GRUPO.jsonl | jq

Espero que os haya sido de interés 🙂

 

20 de marzo de 2017

WebKitGTK+ 2.16

The Igalia WebKit team is happy to announce WebKitGTK+ 2.16. This new release drastically improves the memory consumption, adds new API as required by applications, includes new debugging tools, and of course fixes a lot of bugs.

Memory consumption

After WebKitGTK+ 2.14 was released, several Epiphany users started to complain about high memory usage of WebKitGTK+ when Epiphany had a lot of tabs open. As we already explained in a previous post, this was because of the switch to the threaded compositor, that made hardware acceleration always enabled. To fix this, we decided to make hardware acceleration optional again, enabled only when websites require it, but still using the threaded compositor. This is by far the major improvement in the memory consumption, but not the only one. Even when in accelerated compositing mode, we managed to reduce the memory required by GL contexts when using GLX, by using OpenGL version 3.2 (core profile) if available. In mesa based drivers that means that software rasterizer fallback is never required, so the context doesn’t need to create the software rasterization part. And finally, an important bug was fixed in the JavaScript garbage collector timers that prevented the garbage collection to happen in some cases.

CSS Grid Layout

Yes, the future here and now available by default in all WebKitGTK+ based browsers and web applications. This is the result of several years of great work by the Igalia web platform team in collaboration with bloomberg. If you are interested, you have all the details in Manuel’s blog.

New API

The WebKitGTK+ API is quite complete now, but there’s always new things required by our users.

Hardware acceleration policy

Hardware acceleration is now enabled on demand again, when a website requires to use accelerated compositing, the hardware acceleration is enabled automatically. WebKitGTK+ has environment variables to change this behavior, WEBKIT_DISABLE_COMPOSITING_MODE to never enable hardware acceleration and WEBKIT_FORCE_COMPOSITING_MODE to always enabled it. However, those variables were never meant to be used by applications, but only for developers to test the different code paths. The main problem of those variables is that they apply to all web views of the application. Not all of the WebKitGTK+ applications are web browsers, so it can happen that an application knows it will never need hardware acceleration for a particular web view, like for example the evolution composer, while other applications, especially in the embedded world, always want hardware acceleration enabled and don’t want to waste time and resources with the switch between modes. For those cases a new WebKitSetting hardware-acceleration-policy has been added. We encourage everybody to use this setting instead of the environment variables when upgrading to WebKitGTk+ 2.16.

Network proxy settings

Since the switch to WebKit2, where the SoupSession is no longer available from the API, it hasn’t been possible to change the network proxy settings from the API. WebKitGTK+ has always used the default proxy resolver when creating the soup context, and that just works for most of our users. But there are some corner cases in which applications that don’t run under a GNOME environment want to provide their own proxy settings instead of using the proxy environment variables. For those cases WebKitGTK+ 2.16 includes a new UI process API to configure all proxy settings available in GProxyResolver API.

Private browsing

WebKitGTK+ has always had a WebKitSetting to enable or disable the private browsing mode, but it has never worked really well. For that reason, applications like Epiphany has always implemented their own private browsing mode just by using a different profile directory in tmp to write all persistent data. This approach has several issues, for example if the UI process crashes, the profile directory is leaked in tmp with all the personal data there. WebKitGTK+ 2.16 adds a new API that allows to create ephemeral web views which never write any persistent data to disk. It’s possible to create ephemeral web views individually, or create ephemeral web contexts where all web views associated to it will be ephemeral automatically.

Website data

WebKitWebsiteDataManager was added in 2.10 to configure the default paths on which website data should be stored for a web context. In WebKitGTK+ 2.16 the API has been expanded to include methods to retrieve and remove the website data stored on the client side. Not only persistent data like HTTP disk cache, cookies or databases, but also non-persistent data like the memory cache and session cookies. This API is already used by Epiphany to implement the new personal data dialog.

Dynamically added forms

Web browsers normally implement the remember passwords functionality by searching in the DOM tree for authentication form fields when the document loaded signal is emitted. However, some websites add the authentication form fields dynamically after the document has been loaded. In those cases web browsers couldn’t find any form fields to autocomplete. In WebKitGTk+ 2.16 the web extensions API includes a new signal to notify when new forms are added to the DOM. Applications can connect to it, instead of document-loaded to start searching for authentication form fields.

Custom print settings

The GTK+ print dialog allows the user to add a new tab embedding a custom widget, so that applications can include their own print settings UI. Evolution used to do this, but the functionality was lost with the switch to WebKit2. In WebKitGTK+ 2.16 a similar API to the GTK+ one has been added to recover that functionality in evolution.

Notification improvements

Applications can now set the initial notification permissions on the web context to avoid having to ask the user everytime. It’s also possible to get the tag identifier of a WebKitNotification.

Debugging tools

Two new debugged tools are now available in WebKitGTk+ 2.16. The memory sampler and the resource usage overlay.

Memory sampler

This tool allows to monitor the memory consumption of the WebKit processes. It can be enabled by defining the environment variable WEBKIT_SMAPLE_MEMORY. When enabled, the UI process and all web process will automatically take samples of memory usage every second. For every sample a detailed report of the memory used by the process is generated and written to a file in the temp directory.

$ WEBKIT_SAMPLE_MEMORY=1 MiniBrowser 
Started memory sampler for process MiniBrowser 32499; Sampler log file stored at: /tmp/MiniBrowser7ff2246e-406e-4798-bc83-6e525987aace
Started memory sampler for process WebKitWebProces 32512; Sampler log file stored at: /tmp/WebKitWebProces93a10a0f-84bb-4e3c-b257-44528eb8f036

The files contain a list of sample reports like this one:

Timestamp                          1490004807
Total Program Bytes                1960214528
Resident Set Bytes                 84127744
Resident Shared Bytes              68661248
Text Bytes                         4096
Library Bytes                      0
Data + Stack Bytes                 87068672
Dirty Bytes                        0
Fast Malloc In Use                 86466560
Fast Malloc Committed Memory       86466560
JavaScript Heap In Use             0
JavaScript Heap Committed Memory   49152
JavaScript Stack Bytes             2472
JavaScript JIT Bytes               8192
Total Memory In Use                86477224
Total Committed Memory             86526376
System Total Bytes                 16729788416
Available Bytes                    5788946432
Shared Bytes                       1037447168
Buffer Bytes                       844214272
Total Swap Bytes                   1996484608
Available Swap Bytes               1991532544

Resource usage overlay

The resource usage overlay is only available in Linux systems when WebKitGTK+ is built with ENABLE_DEVELOPER_MODE. It allows to show an overlay with information about resources currently in use by the web process like CPU usage, total memory consumption, JavaScript memory and JavaScript garbage collector timers information. The overlay can be shown/hidden by pressing CTRL+Shit+G.

We plan to add more information to the overlay in the future like memory cache status.

21 de febrero de 2017

Compilando phantomjs para ARM

Solución: Crear un fichero de SWAP https://www.cyberciti.biz/faq/linux-add-a-swap-file-howto/

y seguir compilando siguiendo la guía de la propia web de Phantomjs.

Done! Puedes descargar el binario desde este repositorio GitHub.

10 de febrero de 2017

Accelerated compositing in WebKitGTK+ 2.14.4

WebKitGTK+ 2.14 release was very exciting for us, it finally introduced the threaded compositor to drastically improve the accelerated compositing performance. However, the threaded compositor imposed the accelerated compositing to be always enabled, even for non-accelerated contents. Unfortunately, this caused different kind of problems to several people, and proved that we are not ready to render everything with OpenGL yet. The most relevant problems reported were:

  • Memory usage increase: OpenGL contexts use a lot of memory, and we have the compositor in the web process, so we have at least one OpenGL context in every web process. The threaded compositor uses the coordinated graphics model, that also requires more memory than the simple mode we previously use. People who use a lot of tabs in epiphany quickly noticed that the amount of memory required was a lot more.
  • Startup and resize slowness: The threaded compositor makes everything smooth and performs quite well, except at startup or when the view is resized. At startup we need to create the OpenGL context, which is also quite slow by itself, but also need to create the compositing thread, so things are expected to be slower. Resizing the viewport is the only threaded compositor task that needs to be done synchronously, to ensure that everything is in sync, the web view in the UI process, the OpenGL viewport and the backing store surface. This means we need to wait until the threaded compositor has updated to the new size.
  • Rendering issues: some people reported rendering artifacts or even nothing rendered at all. In most of the cases they were not issues in WebKit itself, but in the graphic driver or library. It’s quite diffilcult for a general purpose web engine to support and deal with all possible GPUs, drivers and libraries. Chromium has a huge list of hardware exceptions to disable some OpenGL extensions or even hardware acceleration entirely.

Because of these issues people started to use different workarounds. Some people, and even applications like evolution, started to use WEBKIT_DISABLE_COMPOSITING_MODE environment variable, that was never meant for users, but for developers. Other people just started to build their own WebKitGTK+ with the threaded compositor disabled. We didn’t remove the build option because we anticipated some people using old hardware might have problems. However, it’s a code path that is not tested at all and will be removed for sure for 2.18.

All these issues are not really specific to the threaded compositor, but to the fact that it forced the accelerated compositing mode to be always enabled, using OpenGL unconditionally. It looked like a good idea, entering/leaving accelerated compositing mode was a source of bugs in the past, and all other WebKit ports have accelerated compositing mode forced too. Other ports use UI side compositing though, or target a very specific hardware, so the memory problems and the driver issues are not a problem for them. The imposition to force the accelerated compositing mode came from the switch to using coordinated graphics, because as I said other ports using coordinated graphics have accelerated compositing mode always enabled, so they didn’t care about the case of it being disabled.

There are a lot of long-term things we can to to improve all the issues, like moving the compositor to the UI (or a dedicated GPU) process to have a single GL context, implement tab suspension, etc. but we really wanted to fix or at least improve the situation for 2.14 users. Switching back to use accelerated compositing mode on demand is something that we could do in the stable branch and it would improve the things, at least comparable to what we had before 2.14, but with the threaded compositor. Making it happen was a matter of fixing a lot bugs, and the result is this 2.14.4 release. Of course, this will be the default in 2.16 too, where we have also added API to set a hardware acceleration policy.

We recommend all 2.14 users to upgrade to 2.14.4 and stop using the WEBKIT_DISABLE_COMPOSITING_MODE environment variable or building with the threaded compositor disabled. The new API in 2.16 will allow to set a policy for every web view, so if you still need to disable or force hardware acceleration, please use the API instead of WEBKIT_DISABLE_COMPOSITING_MODE and WEBKIT_FORCE_COMPOSITING_MODE.

We really hope this new release and the upcoming 2.16 will work much better for everybody.

02 de febrero de 2017

Going to FOSDEM!

It’s been two years since the last time I went to FOSDEM, but it seems that this year I’m going to be there again and, after having traveled to Brussels a few times already by plane and train, this year I’m going by car!: from Staines to the Euro tunnel and then all the way up to Brussels. Let’s see how it goes.

FOSDEM 2017

As for the conference, I don’t have any particular plan other than going to some keynotes and probably spending most of my time in the Distributions and the Desktops devrooms. Well, and of course joining other GNOME people at A La Bécasse, on Saturday night.

As you might expect, I will have my Endless laptop with me while in the conference, so feel free to come and say “hi” in case you’re curious or want to talk about that if you see me around.

At the moment, I’m mainly focused on developing and improving our flatpak story, how we deliver apps to our users via this wonderful piece of technology and how the overall user experience ends up being, so I’d be more than happy to chat/hack around this topic and/or about how we integrate flatpak in EndlessOS, the challenges we found, the solutions we implemented… and so forth.

That said, flatpak is one of my many development hats in Endless, so be sure I’m open to talk about many other things, including not work-related ones, of course.

Now, if you excuse me, I have a bag to prepare, an English car to “adapt” for the journey ahead and, more importantly, quite some hours to sleep. Tomorrow it will be a long day, but it will be worth it.

See you at FOSDEM!

30 de enero de 2017

@firma ahora es AutoFirma

Esta nota es sólo de interés para españoles interesados (necesitados) en relacionarse con la administración pública española. En realidad apenas es un recordatorio de que, hasta donde he comprobado, la anteriormente conocida como cliente @Firma (o Afirma) en sus últimas versiones se denomina AutoFirma.

La respuesta a la consulta al Observatorio eAdmon tampoco me ha sido clara.

No queda nada claro en ninguna de las referencias que he encontrado, pero lo que me ha dado luz en el asunto es repasar el código fuente de AutoFirma.

Repaso de mi búsqueda:

Conclusión: vamos, que casi seguro que sí, que lo que antes se llamaba @Firma (o afirma según el caso) ahora se llamaría oficialmente AutoFirma aunque el repositorio de desarrollo sigue siendo el mismo.

Dicho todo esto por si a alguien le es útil esta info cuando esté dando tumbos desde los buscadores. Que ojalá les sirva.

PS: Finalmente el Observatorio eAdmon me ha dado un poco más de luz, confirmando mi suposición:

25 de enero de 2017

«¡Brindis por Ceres!»

Parece que fue ayer cuando la FMNT-RCM solicitó la inclusión de su certificado raiz en el sistema de distribución de certificados raiz de CA CA/Browser Forum de su oficial autoridad de certificación (CA en inglés) en España CERES. Bueno, en realidad no fue ayer, fue el 26 de mayo de 2008:

pero lo que sí fue ayer 25 de enero de 2017, es la resolución exitosa del procedimiento:

Sólo ha tomado 3167 días para una de las instuciones más importantes de España y uno de los proyectos de migración a la economía digital más importantes del país que ha sido la obligada, y convengo que necesaria, adopción de las prácticas de comunicaciones digitales seguras al menos en la relación con las administraciones del estado. Pero para el usuario la experencia ha sido con frecuencia frustrante y el que más y el que menos hemos padecido problemas: desde la no inclusión de serie en el software que usamos del certificado raiz a las endiabladas configuraciones de los servicios de cada administración que con frecuencia hacían incompatible una configuración de tu navegador entre ellas. Y todo ello sin contar con la peor experiencia aún que ha sido la de la adopción del DNIe. Personalmente hace tiempo que renuncié a usar el DNIe.

¿Tan difícil era hacerlo antes? Estoy convencido de que se trata de un proceso muy riguroso pero, diablos, estamos hablando de la Real Casa de la Moneda, no de cualquier departamento escondido. Estamos hablando del certificado raiz que, en teoría, debería usar la Agencia Tributaria, que podemos concluir que como recaudador tiene las más imperiosas necesidades en mantener el mejor, más accesible y económico portal electrónico con el ciudadano aunque sólo sea para el mayor beneficio de las arcas del estado. Tanto es así que para ser más operativo la Agencia Tributaria a partir de cierto momento adoptó los certificados emitidos por Camerfirma, que si bien son reconocidos por el estado son gestionados por el Consejo Superior de Cámaras de Comercio que entiendo es una entidad semi privada.

Por muy prestigiosa y loable entiendo que Camerfirma no es una organización completamente estatal y en mi opinión, aparte de la apreciación estética por la incongruencia, es el epítome de los problemas del desarrollo e implantación de la administración electrónica en España, a pesar de los recursos aportados y el esfuerzo bienintencionado de los funcionarios que han puesto todo su corazón en un avance tan importante.

Aunque tampoco todo el monte es orégano, como puede apreciarse en el certifcado usado en la Aplicación Web Prestadores de Servicios de Certificación:

En fin, bueno es si bien acaba, que 3167 días no son nada.

Las comparaciones son odiosas

Y bueno, sí yo también, como diría República Gorila sí que estoy un poquito lleno de odio y sí, podemos intentar comparar la duración de diferentes procedimientos de admisión a través del servicio Bugzilla de Mozilla:

Y por brevedad sólo elegiremos algunas firmas reconocidas oficialmente en España:

Camerfirma

  • Entrada 562395
  • registro: 2010-04-28
  • resolución: 2010-12-02
  • duración: 219 días

Agencia de Tecnología y Certificación Electrónica

  • Entrada 653761
  • registro: 2011-04-29
  • resolución: 2011-07-31
  • duración: 94 días

Consorci AOC (CAtCert)

  • Entrada 707995
  • registro: 2011-12-06
  • resolución: 2012-01-17
  • duración: 43 días

EDICOM

  • Entrada 550521
  • registro: 2010-03-05
  • resolución: 2010-03-29
  • duración: 130 días

En fin. La lista no es exhaustiva aunque me ha parecido comprobar que hay varias AC reconocidas que o no han pasado por el proceso o sencillamente siquiera lo han solicitado. En cualquier caso felicitamos al campeón de nuestra somera investigación, el equipo de CATCert que ha sido capaz de resolver en 43 días lo que a nuestra referente FNMT ha tomado, insistimos, 3167 días.

Otros asuntos en el tintero

Me quedo sin más tiempo para extenderme como quisiera verificando el estado de las siguientes cuestiones pendientes:

  • ¿Está reconfigurado por fin el servicio de renovación de los certificados FNMT para que pueda usar, por ejemplo, las versiones recientes de navegadores (observemos que la primera versión de Firefox que incorpora de serie el certificado es la 53.0a). Personalmente hace unos meses me encontré con la imposibilidad de poder renovar mi certificado usando una configuración que desactive cosas como el inseguro protocolo SSL3, práctica habitual en cualquier navegador moderno.
  • El servicio OCSP de Ceres, ¿está por fin públicamente accesible sin pagos?

Convocatoria

Pero alegremos los corazones. Desde mi modesta tribuna convoco a todos los españoles a celebrar este pequeño paso para la humanidad pero un paso de gigante para Ceres-FMNT brindando por tan feliz suceso:

¡Brindis por Ceres!

PS: Sergio de los Santos parece que profundizó mucho más en los progresos técnicos del proceso de aprobación en la increíble historia de Firefox y el certificado raíz de la FNMT.

24 de enero de 2017

SSH-Vault: Cifrar y descifrar un fichero usando la clave ssh

Suelo pedir a mis alumnos que generen un par de claves SSH para darles de alta en alguno de los servidores que usamos en la asignatura (añadiendo la parte pública en el fichero de claves autorizadas, authorized_keys). Lo siguiente suele ser crearles una base de datos y un usuario con acceso a la misma. Aquí, el usuario necesita una contraseña. Para pasarles esta contraseña y otros datos privados, solía pedirles a su vez que me enviaran su clave pública GPG. Realmente, este último paso no es necesario… si disponemos ya de una clave pública SSH podemos usarla para cifrar y descifrar ficheros, muy fácilmente. Una de las formas más sencillas es mediante una aplicación de la línea de comandos, ssh-vault.com.

Para cifrar, usaremos el siguiente comando:

echo -n "mensaje a cifrar" | ./ssh-vault -k /ruta/a/clave/publica/id_rsa.pub create vault

Para descifrar, el receptor usará este otro comando:

./ssh-vault -k /ruta/a/tu/fichero/.ssh/id_rsa view vault

También podríamos haber evitado el uso de una aplicación extra, usando los comando ssh-keygen y openssl que seguramente ya tengamos (la “pega” es que un usuario Windows no las tendrá…):

Convertimos la clave pública ssh a formato PEM:

ssh-keygen -f ~/.ssh/id_rsa.pub -e -m PKCS8 &gt; id_rsa.pem.pub

A continuación, ciframos el mensaje:

openssl rsautl -encrypt -pubin -inkey id_rsa.pem.pub -ssl -in myMessage.txt -out myEncryptedMessage.txt

El receptor usará también openssl para descifrar:

openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in myEncryptedMessage.txt -out myDecryptedMessage.txt

Fuente, cómo no, un hilo de discusión en SuperUser, una de las webs de la red StackExchange, la misma que alberga a StackOverflow.com

10 de enero de 2017

ngrok, o cómo resolver problemas a distancia

Llevaba unos cuantos días intentando resolver un problema de configuración de Apache a otra persona, por email. Me enviaba detalles del problema, pantallazos en algún caso y yo le respondía con posibles soluciones, comandos que debería ejecutar y ficheros de configuración que debería editar. Se trataba de una máquina local, detrás de un NAT. Tras muchas idas y venidas, no conseguíamos resolver y pensando en cómo solucionarlo, me encontré con una herramienta que me ha permitido hacerlo en 2 minutos, ngrok 🙂 Permite exponer puertos tras el NAT de forma muy sencilla, de tal forma que si expone por ejemplo el puerto 22, yo pueda conectarme de forma remota a administrar su máquina. Lógicamente debe haber confianza entre ambas partes, para evitar sustos de seguridad.

Para ello, la persona con el problema de configuración ha tenido que realizar los siguientes pasos:
Instalar openssh (si no lo tiene ya instalado):
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install openssh-server

Poner en marcha openssh:
$ sudo service ssh start

Instalar ngrok (la aplicación que expone puertos tras el NAT)
Tras instalar, debe darse de alta: https://ngrok.com/signup
Una vez realizado ese paso,  ngrok le devolverá el comando a ejecutar para identificarse en ngrok. Algo como:
./ngrok authtoken XXXXXXX

Abrir el puerto 22 (ssh) al exterior: (magia!)
$ ./ngrok tcp 22
(Este comando te dará como resultado una dirección ngrok, que es la que tiene que enviar a la persona que le ayuda. Algo como:  tcp://0.tcp.ngrok.io:13011 )
La persona que le ayuda, en este caso yo 🙂  podrá conectarse así:
$ ssh -l usuario 0.tcp.ngrok.io -p13011

Lógicamente, la persona con el problema antes debe haberle enviado al ayudante un nombre de usuario y contraseña para conectar por ssh.

Una vez conectado, el ayudante puede abrir otras sesiones para tunelizar más puertos. Por ejemplo:

$ ssh -l usuario 0.tcp.ngrok.io -p13011 -L 8080:localhost:80

Ese comando permite tunelizar el puerto 80 de la máquina remota para dejarlo accesible a través del puerto 8080 de la máquina local. Es decir, si el ayudante en su navegador teclea ahora: http://localhost:8080 en realidad se estará conectando a través del túnel ssh al puerto 80 de la máquina remota (tras el NAT). Muy, muy interesante para permitir la administración remota de equipos. Lo dicho, en dos minutos he podido resolver así un problema que se estaba estirando ya unos cuantos días por la incomodidad de analizar el problema vía email…

09 de enero de 2017

How to Re-enable One-Finger Tap and Drag, and Menu Buttons Selection by Keyboard In OS X

These tips were written for OSX Yosemite but they also work for macOS Sierra so I won’t rewrite them 🙂

08 de enero de 2017

What’s the default password of root user in mariadb?

If you have just installed mariadb, you should run this command in order to set a password for the root user and secure your installation:

$ sudo mysql_secure_installation

Besides asking you to provide the new root password, this utility will help you to remove anonymous user (created by default, intended for testing), disallow root login remotely (root should only be allowed to connect from ‘localhost’), remove test database and privileges ad reloading the privilege table. All of it just pressing the Enter key a couple of times 🙂 Not bad!

If that process doesn’t work, try this other one:

(using sudo, don’t specify any password)

$ sudo mysql -u root

Create a new database:

CREATE DATABASE yourdb;

Grant privileges to a new user:

GRANT ALL ON yourdb.* TO yournewuser@localhost IDENTIFIED BY 'yourpassword';
FLUSH privileges;

 

07 de enero de 2017

How to download snapshots from DigitalOcean into local machines

There isn’t any direct option to download a snapshot from DigitalOcean to your local machine, but there certainly is a workaround:

If your intent is to backup a remote computer’s HDD A via SSH to a single file that’s on your local computer’s HDD, run this from your local computer:

$ ssh user@remote "dd if=/dev/vda1 | gzip -1 -" | dd of=image.gz

Source: https://www.digitalocean.com/community/questions/downloading-snapshots-into-local-machines

You should double check that your disk /dev name is /dev/vda1 (like the one in my example) using the df -h command first.

21 de diciembre de 2016

Creando un servicio personal de OpenVPN

He decidido, por fin, crear mi propio servicio VPN. Los motivos principales son poder asegurar navegación privada y cercionarme que uso un servicio de confianza 100% auditado… por mi.

Requisitos

  • servicio OpenVPN
  • usando docker
  • servidor Centos 7
  • reutilizando alguna configuración existente
  • pero sin reutilizar imágenes publicadas en el Docker Hub, por celo en la seguridad
  • poder conectar desde máquinas Linux y teléfonos Android

La configuración elegida es una creada por Kyle Manna: https://github.com/kylemanna/docker-openvpn/ ¡Gracias Kyle!

Procedimiento de instalación y configuración del servidor

En este caso usamos CentOS 7, pero como no está disponible docker-compose he tenido que retro-portarlo y lo tenéis disponible en un repositorio específico.

Preparación:

cd /etc/yum.repos.d ; wget https://copr.fedorainfracloud.org/coprs/olea/docker-compose/repo/epel-7/olea-docker-compose-epel-7.repo
yum install -y docker docker-compose
yum install -y docker-lvm-plugin.x86_64 docker-latest.x86_64
yum upgrade -y
groupadd docker
usermod -G docker -a USUARIO
echo "VG=sys" > /etc/sysconfig/docker-storage-setup
docker-storage-setup
systemctl enable docker
systemctl start docker

Si docker ha podido arrancar entonces probablemente está listo para empezar a trabajar.

Obviamente también hay que configurar el DNS del servicio VPN.MISERVIDOR.COM en el servidor correspondiente.

Entrando en materia:

mkdir servicio-VPN.MISERVIDOR.COM
cd servicio-VPN.MISERVIDOR.COM
git clone https://github.com/kylemanna/docker-openvpn
cat <<EOF > docker-compose.yml
version: '2'
services:
    openvpn:
        build:
            context: docker-openvpn/
        cap_add:
            - NET_ADMIN
        image: Mi-ID/openvpn
        ports:
            - "1194:1194/udp"
        restart: always
        volumes:
            - ./openvpn/conf:/etc/openvpn
EOF

Y continuando con las instrucciones indicadas:

  • construimos localmente la imagen docker desde cero de una sola vez:
docker-compose run --rm openvpn ovpn_genconfig -u udp://VPN.MISERVIDOR.COM
  • iniciamos la AC local propia (se nos pedirá la contraseña de la clave privada):
docker-compose run --rm openvpn ovpn_initpki
  • finalmente lanzamos el contenedor:
docker-compose up -d openvpn

Procedimiento de altas de usuarios

  • Alta del usuario:
docker-compose run --rm openvpn easyrsa build-client-full USUARIO nopass
  • generación de la configuración local de OpenVPN para el mismo usuario:
docker-compose run --rm openvpn ovpn_getclient USUARIO > USUARIO.ovpn
  • Este fichero lo copiaremos a nuestra máquina porque es el que nos habilitará el acceso VPN.

Problema importando configuraciones de OpenVPN y NetworkManager

Personalmente me he encontrado el problema varias veces de que el GUI de configuración de NetworkManager no es capaz de importar los certificados criptográficos al configurar una conexión VPN importando ficheros ovpn. Tras investigarlo varias veces he concluido que se debe a un bug documentado que en mi caso no está resuelto en NetworkManager-openvpn-gnome-1.0.8-2.fc23 pero sí en NetworkManager-openvpn-gnome-1.2.4-2.fc24.

Si aún os encontráis con ese problema habría dos alternativas: o actualizar a una versión reciente de NM o conectarse manualmente desde el CLI:

sudo /usr/sbin/openvpn --config USUARIO.ovpn

Acabemos con los intersticiales

¡Interstitials!

Vaya palabro. “Interstitials”. Intersticiales en español. Anuncios intersticiales; que para la RAE serían aquellos que ocupan los intersticios, pero que, realmente, son anuncios que ocupan toda la pantalla y son especialmente molestos porque,

  • Impiden visualizar la página que queremos ver. Vamos, que molestan, y mucho más, que los pop-ups de toda la vida.
  • Incitan al click fraudulento: La mayor parte de las veces que pulsamos sobre el anuncio, no es para acceder al producto anunciado sino para cerrar el mismo. El botón para cancelarlo suele requerir de una especial destreza (o puntería) del usuario sobre su pantalla multitáctil… a menos que tengas los dedos del tamaño de la cabeza de un alfiler.

Anuncio Intersticial, imagen de Google

Pues bien, hace ahora más de 4 meses, Google anunció que iba a penalizar el uso de anuncios intersticiales en las búsquedas desde móvil a partir de enero de 2017, algo que ya está a la vuelta de la esquina.

Es bueno recordarlo porque, a día de hoy, la mayor parte de las páginas de actualidad en Internet siguen incorporando este tipo de anuncios como si nada, haciendo muy incómoda la lectura, sobre todo en móviles, donde deshacerse del anuncio resulta complicado y por lo que, muchas veces, un servidor decide abandonar el medio de comunicación elegido para irme a uno alternativo que me informe más y me moleste menos.

Aún me queda la esperanza de que esta penalización del buscador realmente consiga su efecto. Mientras tanto, seguiremos haciendo uso extensivo y abusivo de los bloqueadores de anuncios, pese a los avisos de determinados medios de que eso les hace daño.

06 de diciembre de 2016

Segurtasunarekin lotutako berriak (Abenduko bigarren astea)

Azken egun hauetan mugimendua egon da, betiko legez, segurtasun informatikoko munduan.

DailyMotion hackeatuta (85 miloi kontuen datuak agerian)
dailymotionhackeatutaDailyMotion bideoak online partekatzeko plataforma bat da, YouTube edo Vimeo bezalakoa. Astelehenean bertan jakinarazi zutenez urriaren 20an eraso bat jaso ostean DailyMotion-eko erabiltzaileen 85 miloi kontuen kredentzialak agerian utzi zituzten (hacker batek informazio hori lortu eta enpresatik atera zuen). Dirudienez datuen artean email helbidea, erabiltzailearen izena eta kasu batzuetan (18 miloi kontuetan) pasahitzen hashak (bcrypt hash funtzioaz lortutakoak, nahiko sendoak beraz, eta krakeatzeko latzak).

Erasoaren berri LeakedSource-k eman zuen. Webgune horretan zure email helbidea eta erabiltzailea sartu eta berehala jakin ahalko duzu ea hackeatutako datubaseren batean agertzen den edo ez. Horrelako beste webgune famatu bat (ospetsuena) Troy Hunt  ikerlariaren “Have I been pwned?” zerbitzua da. Oso gomendagarriak biak.

Visa txartelen datuak 6 segundo baino gutxiagotan hackeatu daitezke
captura-de-pantalla-2016-12-06-a-las-11-31-38New Castle Unibertsitateko ikerlari talde batek demostratu du VISA txartelen datuak lortzeko 6 segundu baino gehiago ez dituztela behar. Horretarako tresna berezi bat prestatu dute. Tresna horrek hainbat webgune ezberdinetan probatzen ditu txartel baten zenbakien konbinazioak eta txarto (edo ondo) daudenak apuntatzen ditu. Probak webgune ezberdinetan egiten dituenez, VISA enpresak ez du ezer arrarorik somatzen (normalean txartelearen datuak sartzerakoan akats batzuk jarraian egiten badituzu webgune bakar batean bankuetxeak alertak jasotzen ditu). Diruenez MASTERCAD-eko txartelak eraso mota honi aurre egiteko prestatuta daude (erasoak ez du eraginik bertan). Bideo bat ere argitaratu dute, tresna nola erabiltzen den erakutsiz.

Hacker-ek Errusiako Banku Zentrala erasotu eta 31 miloi dolar lapurtu dituzte

Ez dago informazio handirik baina Errusiako Banku Zentralak berak egiaztatu du pasa den ostiralean hackerrek 31 miloi dolar lapurtu zituztela bertan. Dirudienez hackerrek banku pribatuak ere erasotu zituztela baina bertan lapurtu zutenaren berri ez dago. Symantec enpresako ikerlarien arabera munduko bankuen sistemak eraso bortitzak jasaten ari da egun hauetan oso trebea den hacker talde baten eraginez (“Lazarus” izenarekin ezaguna omen da, batzuen ustez Ipar Korearekin lotutakoa). Baina oraingo honetan ez dago garbi zein dagoen erasoaren atzean.

01 de diciembre de 2016

Azken aste hauetan izandako segurtasun auziak

Twitter-eko @segurtasuna kontuan idazten dut askotan. Edo hobeto esanda, erabiltzaile horri aipuak egiten dizkiot. Batzuetan, informazio teknikoa banatzeko erabiltzen dut: tresna berri bat sortu dela, CTF baten berri, exploit berri bat… Beste batzuetan, ordea, segurtasun informatikoko erasoen berri emateko erabiltzen dut kontua. Azken hauek dira gehien kezkatzen nautena, gure eguneroko bizitzan duten edo izan dezaketen eragina sekulakoa baita.

Eta gauza da, eraso horiek gero eta gehiago eta gero eta larriagoak direla. Azter dezagun horietako batzuk.

Azpiegituren kontrako erasoak

Orain dela aste batzuk, La9deAnon taldeko kideek Nafarroako ubidearen kontrol sisteman sartzea lortu zuten. Gaizki inplementatutako segurtasun politikaz baliatuz (edo okerrago, segurtasun politika sendo baten gabezia aprobetxatuz). Nork daki… agian defektuzko eta aldatu gabeko  pasahitz baten bidez lortu zuten bertan sartzea. Tontakeri bat dirudi baina hori da azken finean Mirai botnetak erabili duen teknika erraza: Internet of Things (IoT) delako gailu-en sarean milloika bideo-zainketa kamarak (ikusteko -CCTV- eta grabatzeko -DVR-) kutsatu ditu defektuzko 60 inguruko erabiltzaile eta pasahitz bikoteak probatuz.

Deutsche Telekom-eko erabiltzaileen router-ak

DEUTSCHE TELEKOM -speedport-w-724v
CCTV eta DVR-en segurtasun arazoa ezaguna zen baina hara non eta router-ak ere Mirai botnet-aren biktimak bilakatu dira. Kasu honetan ez defekutzko pasahitzak dituztelako baizik eta Interneteko hornitzaileek router hauen urruneko konfigurazioa lortzeko erabiltzen duten protokoloaren segurtasun ahulezi bateaz baliatuz. Ez edozein router… batez ere Alemanian oso ezagunak diren Zyxel konpainiak sortutakoak (batez ere Deutsche Telekom honitzaileak erabiltzen dituen router-ak) . 900.000 router inguru kutsatu ditu jada soilik Alemanian baina dirudienez, kutsadura zabaltzen ari da Brasilen eta Erresuma Batuan.

DynDNS interneko DNS azpisistema

Arazo latza, larria eta sakona. Batez ere jakinda Mirai botnet-aren iturburu kodea orain dela gutxi ireki eta GitHub-en kaleratu zutela. Mirai botnet-ak Brian Krebs segurtasun informatikoan aditua den ikerlariaren webgunea botatzea lortu zuen (DDoS baten bidez, azken finean). 665gbps-eko traifikoko jario erraldoia sortu ondoren, Interneten inoiz ikusi ez den jarioa hain zuzen ere.

Horrelako ahalmena suntsitzailea duen jario batek OVH bezalako hornitzaileen kontra egin dezake. Eta irabazi. Edo soilik beraien babes-neurriak probatu. Hori da hain zuzen ere Bruce Schnneier adituak dioena, arerioaren ahalmenaren proba batzuk besterik ez direla. Jakin nahi baitute norainoko neurriak dituzten. Eta oraindik beldurra gorputzean ez bazaizu sartu, entzun hau: Mirai botnet-a alokatu daiteke. Bai, zuk-zeuk, edo beste edozeinek. Ez gara oso argiak izan behar asmatu ahal izateko zeinek eta zertarako erabili dezaketen botnet hau. Adibidez, DNS sistemaren parte den Dyn DNS enpresaren kontra egiteko. Enpresa horrek, halaber, hainbat enpresen DNS erregistroak kudeatzen ditu. DNS-a bertan behera uztea lortuz gero, erabiltzaileek ezingo dituzte enpresa webgune horiek atzitu (IP helbidea jakinez gero bai, baina orduan ez zara erabiltzaile arrunt bat izango 😉

Mirai-k DNS-ak erasotzeko erabiltzen dituen teknikak, aurreratuak dira. Ez dira etor-berri batzuk. Etorkizunean (hori da Mirai hitzaren esanahia, japonieraz) Mirai kode kaltegarriaren aldaerak sortuko dira eta erasotzen jarraituko dute, dudarik gabe.

San Francisco-ko trena (Muni-hack)

muni-hackDemagun Mugi/Lurraldebus online sistema norbaitek hackeatzen duela. Demagun ransomware baten bidez, sistema kutsatu egiten duela. Eta erreskatea ordaindu arte (edo babes-kopiak berreskuratu arte) sistema bertan behera geratzen dela. Zer gertatuko litzateke? Ba, ziur asko, San Francisco tren sisteman ( San Francisco Municipal Transportation Agency, SFMTA edo Muni izenarekin ezagutzen dena) gertatu zena: txartelak saltzeko makinetan “You Hacked, ALL data encrypted” mezua agertuko zela. Eta 73.000$ ordaindu arte, erasotzaileek ez zutela sistema berreskuratzeko gakoa bidaliko esan zuten. Egun horretan dohain bidaiatu zuten tren erabiltzaile guztiek (babes-kopietatik sistema berreskuratu arte).

Nolakoak diren gauzak… SFMTA hackeatu zuena, halaber, hackeatua izan zen egun gutxitara. Eta bere mail mezuetan agertu diren aztarnak aztertu ondoren, dirutza lortu zuen erreskateen bidez, beste enpresa handi batzuk kutsatu ondoren. Negozioa.

Bizpahiru adibide dira gaur honera ekarri ditudanak. Ez dira lehenengoak… tamalez, ezta azkenengoak izango ere.

23 de noviembre de 2016

Conferencia: HackLab Almería, un modelo de dinamización tecnológica hiperlocal

El 24 de noviembre he sido invitado a charlar para hablar de la experiencia de HackLab Almería en un evento en Antequera organizado por IBM. He aprovechado para seguir trabajando en el material retrospectiva del HackLab Almería que preparé para el GDG Spain Summit y lo he adaptado a formato de transparencias con mi agradecido Slidy.

Las transparencias están disponibles en https://olea.org/conferencias/doc-conf-20161124-Encuentro-IBM/

captura de pantalla de las transpas

Además voy a tener la oportunidad de volver a impartir la conferencia en un par más de ocasiones así que creo que refinaré más aún este material, que también me sirve para profundizar la retrospectiva de los dos años largos que he dedicado a «la movida HackLab Almería».

Gracias a Haroldo Díaz Armas por la invitación, a Elisa Martín Garijo por sugerir mi persona y a Javier Bentabol por su entusiasmo con nosotros.

10 de noviembre de 2016

Web Engines Hackfest 2016

From September 26th to 28th we celebrated at the Igalia HQ the 2016 edition of the Web Engines Hackfest. This year we broke all records and got participants from the three main companies behind the three biggest open source web engines, say Mozilla, Google and Apple. Or course, it was not only them, we had some other companies and ourselves. I was active part of the organization and I think we not only did not get any complain but people were comfortable and happy around.

We had several talks (I included the slides and YouTube links):

We had lots and lots of interesting hacking and we also had several breakout sessions:

  • WebKitGTK+ / Epiphany
  • Servo
  • WPE / WebKit for Wayland
  • Layout Models (Grid, Flexbox)
  • WebRTC
  • JavaScript Engines
  • MathML
  • Graphics in WebKit

What I did during the hackfest was working with Enrique and Žan to advance on reviewing our downstream implementation of our GStreamer based of Media Source Extensions (MSE) in order to land it as soon as possible and I can proudly say that we did already (we didn’t finish at the hackfest but managed to do it after it). We broke the bots and pissed off Michael and Carlos but we managed to deactivate it by default and continue working on it upstream.

So summing up, from my point of view and it is not only because I was part of the organization at Igalia, based also in other people’s opinions, I think the hackfest was a success and I think we will continue as we were or maybe growing a bit (no spoilers!).

Finally I would like to thank our gold sponsors Collabora and Igalia and our silver sponsor Mozilla.

05 de octubre de 2016

Frogr 1.2 released

Of course, just a few hours after releasing frogr 1.1, I’ve noticed that there was actually no good reason to depend on gettext 0.19.8 for the purposes of removing the intltool dependency only, since 0.19.7 would be enough.

So, as raising that requirement up to 0.19.8 was causing trouble to package frogr for some distros still in 0.19.7 (e.g. Ubuntu 16.04 LTS), I’ve decided to do a quick new release and frogr 1.2 is now out with that only change.

One direct consequence is that you can now install the packages for Ubuntu from my PPA if you have Ubuntu Xenial 16.04 LTS or newer, instead of having to wait for Ubuntu Yakkety Yak (yet to be released). Other than that 1.2 is exactly the same than 1.1, so you probably don’t want to package it for your distro if you already did it for 1.1 without trouble. Sorry for the noise.

 

Frogr 1.1 released

After almost one year, I’ve finally released another small iteration of frogr with a few updates and improvements.

Screenshot of frogr 1.1

Not many things, to be honest, bust just a few as I said:

  • Added support for flatpak: it’s now possible to authenticate frogr from inside the sandbox, as well as open pictures/videos in the appropriate viewer, thanks to the OpenURI portal.
  • Updated translations: as it was noted in the past when I released 1.0, several translations were left out incomplete back then. Hopefully the new version will be much better in that regard.
  • Dropped the build dependency on intltool (requires gettext >= 0.19.8).
  • A few bugfixes too and other maintenance tasks, as usual.

Besides, another significant difference compared to previous releases is related to the way I’m distributing it: in the past, if you used Ubuntu, you could configure my PPA and install it from there even in fairly old versions of the distro. However, this time that’s only possible if you have Ubuntu 16.10 “Yakkety Yak”, as that’s the one that ships gettext >= 0.19.8, which is required now that I removed all trace of intltool (more info in this post).

However, this is also the first time I’m using flatpak to distribute frogr so, regardless of which distribution you have, you can now install and run it as long as you have the org.gnome.Platform/x86_64/3.22 stable runtime installed locally. Not too bad! :-). See more detailed instructions in its web site.

That said, it’s interesting that you also have the portal frontend service and a backend implementation, so that you can authorize your flickr account using the browser outside the sandbox, via the OpenURI portal. If you don’t have that at hand, you can still used the sandboxed version of frogr, but you’d need to copy your configuration files from a non-sandboxed frogr (under ~/.config/frogr) first, right into ~/.var/app/org.gnome.Frogr/config, and then it should be usable again (opening files in external viewers would not work yet, though!).

So this is all, hope it works well and it’s helpful to you. I’ve just finished uploading a few hundreds of pictures a couple of days ago and it seemed to work fine, but you never know… devil is in the detail!

 

30 de septiembre de 2016

Cross-compiling WebKit2GTK+ for ARM

I haven’t blogged in a while -mostly due to lack of time, as usual- but I thought I’d write something today to let the world know about one of the things I’ve worked on a bit during this week, while remotely attending the Web Engines Hackfest from home:

Setting up an environment for cross-compiling WebKit2GTK+ for ARM

I know this is not new, nor ground-breaking news, but the truth is that I could not find any up-to-date documentation on the topic in a any public forum (the only one I found was this pretty old post from the time WebKitGTK+ used autotools), so I thought I would devote some time to it now, so that I could save more in the future.

Of course, I know for a fact that many people use local recipes to cross-compile WebKit2GTK+ for ARM (or simply build in the target machine, which usually takes a looong time), but those are usually ad-hoc things and hard to reproduce environments locally (or at least hard for me) and, even worse, often bound to downstream projects, so I thought it would be nice to try to have something tested with upstream WebKit2GTK+ and publish it on trac.webkit.org,

So I spent some time working on this with the idea of producing some step-by-step instructions including how to create a reproducible environment from scratch and, after some inefficient flirting with a VM-based approach (which turned out to be insanely slow), I finally settled on creating a chroot + provisioning it with a simple bootstrap script + using a simple CMake Toolchain file, and that worked quite well for me.

In my fast desktop machine I can now get a full build of WebKit2GTK+ 2.14 (or trunk) in less than 1 hour, which is pretty much a productivity bump if you compare it to the approximately 18h that takes if I build it natively in the target ARM device I have 🙂

Of course, I’ve referenced this documentation in trac.webkit.org, but if you want to skip that and go directly to it, I’m hosting it in a git repository here: github.com/mariospr/webkit2gtk-ARM.

Note that I’m not a CMake expert (nor even close) so the toolchain file is far from perfect, but it definitely does the job with both the 2.12.x and 2.14.x releases as well as with the trunk, so hopefully it will be useful as well for someone else out there.

Last, I want to thanks the organizers of this event for making it possible once again (and congrats to Igalia, which just turned 15 years old!) as well as to my employer for supporting me attending the hackfest, even if I could not make it in person this time.

Endless Logo

25 de septiembre de 2016

Retrospectiva HackLab Almería 2012-2015 y pico

Este fin de semana tuve el privilegio de ser invitado por GDG Spain y en particular por ALMO para presentar en el Spanish GDG Summit 2016 la experiencia de la actividad en el HackLab Almería:

Aunque llegué muy inseguro porque soy muy crítico con los que considero fracasos míos, al conocer las vicisitudes de los grupos locales del GDG comprobé que a nosotros no nos va tan mal y que tenemos experiencias muy interesantes para terceros.

De paso me ha servido para reconsiderar parte del trabajo hecho y para documentar más claramente nuestras cosas para nuestra propia gente: creo que es buena idea que todos le demos un repaso.

Es posible que haya algún error y alguna carencia. Todas las opiniones son absolutamente personales y no todo el mundo ha de compartirlas. No tengo tanto interés en discutir las afirmaciones como de corregir errores o inconsistencias. Tened presente de que no es una memoria completa de actividades porque eso sería enooorme, sólo una retrospectiva esquemática.

Está escrita en formato de mapa-mental usando Freemind 1.0.1. El formato tal vez os parezca engorroso, pero las restricciones de tiempo y de presentación de la información no me han permitido nada mejor. Lamento las molestias. Podéis descargar el fichero que incluye el mapa desde aquí: 201609-GDG-Experiencia_HackLabAl.zip

PS: esta misma entrada ha sido publicada en el foro del HackLab Almería.

20 de septiembre de 2016

WebKitGTK+ 2.14

These six months has gone so fast and here we are again excited about the new WebKitGTK+ stable release. This is a release with almost no new API, but with major internal changes that we hope will improve all the applications using WebKitGTK+.

The threaded compositor

This is the most important change introduced in WebKitGTK+ 2.14 and what kept us busy for most of this release cycle. The idea is simple, we still render everything in the web process, but the accelerated compositing (all the OpenGL calls) has been moved to a secondary thread, leaving the main thread free to run all other heavy tasks like layout, JavaScript, etc. The result is a smoother experience in general, since the main thread is no longer busy rendering frames, it can process the JavaScript faster improving the responsiveness significantly. For all the details about the threaded compositor, read Yoon’s post here.

So, the idea is indeed simple, but the implementation required a lot of important changes in the whole graphics stack of WebKitGTK+.

  • Accelerated compositing always enabled: first of all, with the threaded compositor the accelerated mode is always enabled, so we no longer enter/exit the accelerating compositing mode when visiting pages depending on whether the contents require acceleration or not. This was the first challenge because there were several bugs related to accelerating compositing being always enabled, and even missing features like the web view background colors that didn’t work in accelerated mode.
  • Coordinated Graphics: it was introduced in WebKit when other ports switched to do the compositing in the UI process. We are still doing the compositing in the web process, but being in a different thread also needs coordination between the main thread and the compositing thread. We switched to use coordinated graphics too, but with some modifications for the threaded compositor case. This is the major change in the graphics stack compared to the previous one.
  • Adaptation to the new model: finally we had to adapt to the threaded model, mainly due to the fact that some tasks that were expected to be synchronous before became asyncrhonous, like resizing the web view.

This is a big change that we expect will drastically improve the performance of WebKitGTK+, especially in embedded systems with limited resources, but like all big changes it can also introduce new bugs or issues. Please, file a bug report if you notice any regression in your application. If you have any problem running WebKitGTK+ in your system or with your GPU drivers, please let us know. It’s still possible to disable the threaded compositor in two different ways. You can use the environment variable WEBKIT_DISABLE_COMPOSITING_MODE at runtime, but this will disable accelerated compositing support, so websites requiring acceleration might not work. To disable the threaded compositor and bring back the previous model you have to recompile WebKitGTK+ with the option ENABLE_THREADED_COMPOSITOR=OFF.

Wayland

WebKitGTK+ 2.14 is the first release that we can consider feature complete in Wayland. While previous versions worked in Wayland there were two important features missing that made it quite annoying to use: accelerated compositing and clipboard support.

Accelerated compositing

More and more websites require acceleration to properly work and it’s now a requirement of the threaded compositor too. WebKitGTK+ has supported accelerated compositing for a long time, but the implementation was specific to X11. The main challenge is compositing in the web process and sending the results to the UI process to be rendered on the actual screen. In X11 we use an offscreen redirected XComposite window to render in the web process, sending the XPixmap ID to the UI process that renders the window offscreen contents in the web view and uses XDamage extension to track the repaints happening in the XWindow. In Wayland we use a nested compositor in the UI process that implements the Wayland surface interface and a private WebKitGTK+ protocol interface to associate surfaces in the UI process to the web pages in the web process. The web process connects to the nested Wayland compositor and creates a new surface for the web page that is used to render accelerated contents. On every swap buffers operation in the web process, the nested compositor in the UI process is automatically notified through the Wayland surface protocol, and  new contents are rendered in the web view. The main difference compared to the X11 model, is that Wayland uses EGL in both the web and UI processes, so what we have in the UI process in the end is not a bitmap but a GL texture that can be used to render the contents to the screen using the GPU directly. We use gdk_cairo_draw_from_gl() when available to do that, falling back to using glReadPixels() and a cairo image surface for older versions of GTK+. This can make a huge difference, especially on embedded devices, so we are considering to use the nested Wayland compositor even on X11 in the future if possible.

Clipboard

The WebKitGTK+ clipboard implementation relies on GTK+, and there’s nothing X11 specific in there, however clipboard was read/written directly by the web processes. That doesn’t work in Wayland, even though we use GtkClipboard, because Wayland only allows clipboard operations between compositor clients, and web processes are not Wayland clients. This required to move the clipboard handling from the web process to the UI process. Clipboard handling is now centralized in the UI process and clipboard contents to be read/written are sent to the different WebKit processes using the internal IPC.

Memory pressure handler

The WebKit memory pressure handler is a monitor that watches the system memory (not only the memory used by the web engine processes) and tries to release memory under low memory conditions. This is quite important feature in embedded devices with memory limitations. This has been supported in WebKitGTK+ for some time, but the implementation is based on cgroups and systemd, that is not available in all systems, and requires user configuration. So, in practice nobody was actually using the memory pressure handler. Watching system memory in Linux is a challenge, mainly because /proc/meminfo is not pollable, so you need manual polling. In WebKit, there’s a memory pressure handler on every secondary process (Web, Plugin and Network), so waking up every second to read /proc/meminfo from every web process would not be acceptable. This is not a problem when using cgroups, because the kernel interface provides a way to poll an EventFD to be notified when memory usage is critical.

WebKitGTK+ 2.14 has a new memory monitor, used only when cgroups/systemd is not available or configured, based on polling /proc/meminfo to ensure the memory pressure handler is always available. The monitor lives in the UI process, to ensure there’s only one process doing the polling, and uses a dynamic poll interval based on the last system memory usage to read and parse /proc/meminfo in a secondary thread. Once memory usage is critical all the secondary processes are notified using an EventFD. Using EventFD for this monitor too, not only is more efficient than using a pipe or sending an IPC message, but also allows us to keep almost the same implementation in the secondary processes that either monitor the cgroups EventFD or the UI process one.

Other improvements and bug fixes

Like in all other major releases there are a lot of other improvements, features and bug fixes. The most relevant ones in WebKitGTK+ 2.14 are:

  • The HTTP disk cache implements speculative revalidation of resources.
  • The media backend now supports video orientation.
  • Several bugs have been fixed in the media backend to prevent deadlocks when playing HLS videos.
  • The amount of file descriptors that are kept open has been drastically reduced.
  • Fix the poor performance with the modesetting intel driver and DRI3 enabled.

15 de septiembre de 2016

Acceso VPN a la red de CICA usando Fedora

Esta es una entrada de servicio público. Si eres usuario de la VPN de CICA y usas un linux moderno como Fedora (23 en este caso) puede serte de utilidad esta entrada.

CICA usa OpenVPN. Lo ideal sería poder configurar el acceso con NetworkManager, que dispone de la funcionalidad de openvpn, pero en ninguna de mis pruebas he conseguido una configuración operativa, creo que porque NM espera que el certificado de usuario sea emitido por la misma CA que la configuración de la red en cuestión, que no es el caso. El caso es que tras varias pruebas he conseguido conectar desde la CLI contando con la ayuda del CAU de Sistemas de CICA.

Básicamente necesitas:

client
dev tun
proto udp
remote vpn.cica.es 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca /home/usuario/cica-vpn/TERENASSL2_PATH.pem
pkcs12 /home/usuario/.X509/FNMTClase2CA.p12
auth-user-pass
verify-x509-name vpn.cica.es name
cipher AES-128-CBC
comp-lzo
verb 3

Para poder conectar basta lanzar algo parecido a:

sudo /usr/sbin/openvpn --config /home/usuario/cica-vpn/cica-config.ovpn

Entonces openvpn te solicitará tres datos:

  • usuario de la red CICA
  • contraseña asociada
  • contraseña de acceso a tu certificado X509 emitido por FNMT.

Por dejarlo completamente claro

  • /home/usuario/cica-vpn/TERENASSL2_PATH.pem es el certificado que descargas de http://www.rediris.es/scs/cacrt/TERENASSL_PATH.pem
  • /home/usuario/.X509/FNMTClase2CA.p12 es tu certificado de la FNMT-RCM exportado probablemente desde tu navegador y protegido por una contraseña.

Que ojalá os sirva.

Publicada la vieja web de TLDP-ES/LuCAS en Github

Desde hace unos buenos años CICA ha tenido la gentileza de alojar el servidor principal del viejo TLDP-ES que los linuxeros más fogueados recordarán como LuCAS.hispalinux.es. Fue imperativo migrar el servicio desde el momento en el que mantenimiento de los sistemas de Hispalinux empezó a colapsar y tuve suerte de que CICA nos ofreciera una VM pequeñita donde alojar lo que se pudo salvar de la web. Claro que ya no era una web importante, pero me dolía mucho dejar que desapareciera el testigo de toda una época y el fruto del trabajo de muchas personas durante muchísimas horas. Tampoco me gusta ir dejando enlaces rotos en la web si puedo evitarlo.

En este mismo proceso de «arqueología» hace ya tiempo que pensé en publicar otro repositorio que usábamos para el mantenimiento de TLDP-ES, el control de versiones con el que queríamos facilitar el trabajo de los voluntarios. Así creé este repo en Github: https://github.com/olea/LuCAS-cvs. Ahora, de la misma manera me he propuesto publicar igualmente el contenido de la web que ahora está disponible también en Github: https://github.com/olea/LuCAS-web.

Prácticamente no es más que un pequeño ejercicio de nostalgia, pero en fin, ahí queda.

Gracias a todos los que hicisteis posible ese gran servicio que fue TLDP-ES/LuCAS. Definitivamente creo que fue algo grande.

05 de septiembre de 2016

Probando el Subsistema Windows 10 para Linux (Beta)

El 30 de marzo saltaba la noticia: las llamadas al sistema de Linux  se podrán ejecutar en Windows 10 de forma “nativa” (se podrán traducir en tiempo real a llamadas al sistema de Windows, algo así como un WINE a la inversa):

Intenté probarlo en su día, pero no encontraba tiempo. Tampoco creo que estuviera disponible para todos los usuarios… Hoy he recordado la noticia y le he dedicado un rato porque necesito ejecutar algunas funcionalidades de Linux en una máquina Windows (y la opción de Cygwin me parece demasiado “heavy”… y problemática, la he sufrido en alguno de mis cursos, donde he recibido numerosas peticiones de auxilio 😉

Para probar el subsistema Windows para Linux (Windows Subsystem for Linux o WSL) hay que tener la actualización Windows 10 Anniversary Update (se publicó en Agosto de este año). La forma más sencilla es a través de este enlace oficial a la web de Microsoft. Tras la instalación/upgrade, hay que activar el modo programador entrando en Configuración / Para programadores

bash_win_0

A continuación, entramos en Panel de Control / Programas / Activar o desactivar las características de Windows . Activamos el Subsistema de Windows para Linux (beta) y reiniciamos las veces que haga falta 😛

subsistema_Linux

Ahora viene lo bueno. Ejecutamos bash desde el menú de inicio (tecleamos bash y pulsamos intro) y al ser la primera vez se lanzará la instalación:

bash_win_1

Le costará un rato descargar WSL (al final está descargando una especie de versión de Ubuntu Server) y activarlo. Cuando lo haga, nos pedirá crear un usuario (que por defecto estará en la lista de sudoers)bash2

Le asignamos un pass al nuevo user y tachán, ya estamos en Bash 🙂

bash3

Se hace raro poder ejecutar ls, id, pwd, cat, vi ! , apt (sí apt-get!) en Windows sin recibir mensajes de error…bash4

Realmente estamos en Bash dentro de un Ubuntu 14.04 ejecutándose sobre Windows 10. Buf… si me lo llegan a decir hace un tiempo hubiera puesto cara de incrédulo.bash5

Los archivos están donde deben (en un sistema que siga el LSB) y tienen el contenido esperado.

bash6

El sistema de archivos del anfitrión Windows está montado en /mnt . Tenemos los repos apt de Ubuntu a nuestra disposición para instalar las aplicaciones que necesitemos.

bash8

Otro puntazo a favor es que tenemos un intérprete python y un intéprete perl instalados de serie (los mismos que instala Ubuntu 14.04, claro)

bash9

También he visto que hay un servicio ssh lanzado en el puerto 22, pero por lo que he probado NO es openssh (se puede ver el fingerprint del servidor mediante un simple telnet – sí, telnet, para ver el banner del server – al puerto 22), sino un servidor SSH de Windows (yo diría que en alfa, porque aún no he conseguido autenticarme y creedme que he probado de todo). ¿Tal vez sea una implementación en desarrollo del port openssh de Microsoft ?

bash7

Leyendo algunos foros comentaban que openssh se puede configurar para que escuche en un puerto distinto al 22 (el 60022, por ejemplo), abrir una regla en el firewall de Windows para ese nuevo puerto y listo. Si no lo tenemos instalado por defecto (en mi caso sí lo estaba) siempre podremos instalarlo con sudo apt-get update && sudo apt-get install openssh 🙂

A continuación, modificamos /etc/ssh/sshd_config y lo dejamos así:

Port 60022
ListenAddress 0.0.0.0
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
UsePrivilegeSeparation no
KeyRegenerationInterval 3600
ServerKeyBits 1024
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin without-password
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication no
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

Si openssh ya estaba instalado, antes de reiniciar el server openssh lo reconfiguramos (si no lo hacemos, arrancará, pero no conseguiremos conectar porque no habrá generado los ficheros necesarios):

$ sudo dpkg-reconfigure openssh-server

Ahora sí, reiniciamos el server openssh:

sudo service ssh restart

Y conectamos desde localhost para probar:

bash_win_10

¡Funciona! 🙂

UPDATE (5/09/2016): si en algún momento la liamos parda con la configuración del WSL, siempre podremos desinstalar y volver a instalar con dos sencillos comandos:

C:\> lxrun.exe /uninstall /full
C:\> lxrun.exe /install

UPDATE (6/09/2016): es posible iniciar el servidor openssh de WSL al arrancar el equipo. Para ello, basta con parar el Server SSH de Microsoft (el que viene por defecto) y lanzar OpenSSH con la configuración indicada, salvo que ahora podremos lanzarlo en su puerto natural, el 22. Además, si queremos lanzar el servidor cada vez que iniciemos el equipo, podremos crear un script de arranque.

02 de septiembre de 2016

Cerber edo kode kaltegarriaren negozioa

malwaretech

Ransomware delako kode kaltegarri motakoa da Cerber. Horrelako beste hainbat izen ezagunak etortzen zaizkigu burura: Locky, CryptoWall, Crypt0L0cker, TeslaCrypt… Dakigun bezala, malware mota honek gure disko gogorraren edukia zifratu egingo du eta berreskuratzea ezinezkoa izango da ez badugu erreskate bat ordaintzen. Zifratzeko gako publikoko kriptografia + kriptografia simetrikoa erabiltzen omen dute (RSA+AES). Beste mezu batean hau nola egiten duten azalduko dut, baina Bromium enpresak argitaratutako txosten honetan informazio lagungarria aurkituko duzu gehiago sakondu nahi izanez gero.

Orain interesatzen zaidana da kontu azkar batzuk egitea hemen. Eta soilik ransomware bakar baten inguruan: Cerber. @malwaretechblog ikertzailearen arabera, egunero Cerber-ek 6000 biktima berri kutsatzen ditu. Ez da ausaz asmatutako zenbaki bat, baizik eta bere tracker-sareak egunero antzematen dituena.

Orain kalkulu azkar bat. Demagun 6000 infekzio horietatik soilik %3-ak ordaintzen duela erreskatea. Zenbateko erreskatea da hori? Nola ordaintzen da? Ba 500$ gutxi gorabehera… eta BitCoin-etan ordaintzen da. Lehenengo Tor sarea erabiltzeko nabigatzailea instalatu beharko duzu, gero BitCoin-ak erosi, ordaindu eta zifratzeko erabili zen gakoa berreskuratzearen zain pazientziarekin itxaron. Hainbat gauza daude hemen zehazteko… adibidez, zergatik esan dut gutxi gorabehera? Honegatik:

enc_cerber_website-1

Azkar ordainduz gero (7 egun baino gutxiagotan), 1.24 bitcoin (521$ gutxi gora behera) izango dira. Erreskatea beranduago ordainduz gero, bikoiztu egingo da isuna: 2.48 BTC = 1043$

Ordaindu ezean, nola berreskuratu? Ez dago modurik. Hasierako bertsioa gaizki programatuta bazegoen ere (beraz, ordaindu gabe bazegoen berreskuratzeko modu bat), gaur egun asko “hobetu” dute Cerber-en kodea eta ez dago ordaindu gabe berreskuratzeko  modurik. Hemen babes-kopien politikaren beharraz arituko nintzen, baina ez da une egokia 😉 Ordaindu edo ez, hori bakoitzaren eskuetan uzten dut.

Baina gatozen harira.  6.000 kutsadura * 0.03 ordainketa * 500$ = 90000$ , EGUNERO.

Nola banatzen da Cerber bezalako kode kaltegarria? Zein dago horren atzetik? Nola kutsatzen gara? Ezin da ezer egin honen aurka? Aztertzeko hainbat galdera interesgarri…

01 de septiembre de 2016

Migration to https

I’ve postponed this for eons but it has been the time to migrate the olea.org website to https

Concerned about the privacy, in 2009 the EFF launched the campaign Encrypt the Web aiming all the Web users to migrate to encrypted communications, concerning sysadmins, software programmers and users. Now I did the needed step for my main web server and since there are lots of better documentation on this I’ll just comment briefly some practical details.

First, the tools that helped me with the process:

You should try both if you didn’t yet. And thanks a lot to the Mozilla Foundation for creating them.

Second, the migration issues, because the auditing results are pretty bad: 🙈

results of scan summary

  • I’m not sure if my server changes would have some collateral effects in the other hosted webs. I’m not the best sysadmin. Let’s see.
  • One of the biggest problem of this migration is how old this server is: a CentOS 5 server which should have been migrated years ago. Still in my ToDo. I think the most negative points of the auditing are consequence of this.
  • The other one is the CA of my X509 certificates. For some years I’ve been a promoter of CACert and I’m using this certificates for other services in my server but at this moment the CACert hasn’t been able to get accepted their root certificate with the WebTrust Principles and Criteria for Certification Authorities and the internal crisis of the organization breaks all my hopes for a community driven certification authority X509 compatible. In practice this mean my current X509 certificate is not trustable for everybody who has not added the CACert root certificate by hand. Not a fun thing.

If you are reading these lines then is very probable you know about Letscencrypt which I really love too. This time I have two concerns with Letscrypt: the first this server is too old that should be migrated soon, the second is Letsencrypt is not designed to verify identities. The alternative seems to be to find a free (as beer) or paid CA providing hte verification service.

Well, I know this entry is not very useful for the most of the users, but I’m trying now to write more regularly and to document my routine technical progresses. And as the song says, «que ojalá os sirva».

PD: Finally I deactivated the apache redirection from http to https because using a CACert certificate broke my RPM repository and complicated the access to my web for some users. This is sad.

30 de agosto de 2016

Guía de Linux para el usuario en epub

Hoy mi amigo Eduardo me ha pedido bibliografía elemental en formato digitla para empezar en serio con Linux. Mi primera idea ha sido ir a revisar o que teníamos publicado en TLDP-ES/LuCAS y lo primero que he pensado es en hacerle llegar una copia de la vieja G.L.U.P. - Guía de Linux Para el Usuario que debería atender la mayor parte de las dudas básicas del recién llegado. Como la mejor forma de leer un documento, sea en tableta, teléfono o en un lector de ebook es ePub he pensado cómo apañarlo. He aprovechado para refrescar sobre las herramientas disponibles a partir de los formatos que publicamos en su momento que son básicamente PDF y HTML. Aunque El odioso PDF es manejable por estos dispositivos, no es tan acomodable a la pantalla como puedan serlo HTML y ePub.

Hoy mi amigo Eduardo me ha pedido bibliografía elemental para empezar en serio con Linux y he decidido hacerle llegar una copia manejable de la vieja G.L.U.P. - Guía de Linux Para el Usuario en formato ePub. Así he descargado una copia en HTML de la misma, y he cambiado el archivado tar.gz por uno zip y he creado el ebook con el conversor de Calibre:

ebook-convert glup_0.6-1.1-html-1.1.zip glup_0.6-1.1-html-1.1.epub

y listo: pantallazo de GLUP en ebook-viewer.

Después he aprovechado para hacer un poquito de control de calidad con otra utilidad de Calibre: ebook-edit.

Podéis descargar esta versión del libro desde este enlace glup_0.6-1.1-html-1.1.epub. Y como dice la canción: «que ojalá os sirva».

19 de agosto de 2016

Cambios en mi web

Después de postergarlo por mucho tiempo y tras haber adquirido algo de experiencia al crear con Jekyll las web de HackLab Almería y Club de Cacharreo me he animado a descartar al viejo Lameblog y ponerme manos a la obra. Si se nota alguna inconsistencia en mi web tened la seguridad de que es culpa mía. Y no me refiero al diseño, que es algo que ya doy por perdido.

Algo fantástico de Jekyll es que puedes migrar un blog al menos a través del fichero RSS del antiguo. Y por ahora parece funcionar divinamente.

Una inconsistencia a la que tristemente renuncio a corregir son las URI/permalinks originales, que además son las que usa Disqus para recuperar los comentarios. Como Lameblog se hacía algo de lío al generar las URIs con la localización ES pues se ha quedado todo un poco guarro y ahora me parece un lío arreglarlo. Por otro lado voy a procurar a no eliminar contenido de las URIs antiguas por los (pocos) enlaces externos que pudiera haber. Perderé los comentarios, sí, en las versiones nuevas de las entradas pero realmente no son demasiados y deberían seguir accesibles en las antiguas.

PD: Finalmente me he puesto a migrar los comentarios del blog alojados en Disqus. Afortunadamente parece que el proceso está bastante bien implementado Migration console y en mi caso, ya que no me he atrevido a especificar unas reglas que indiquen la transformación de las URIs antiguas a las modernas he seguido el procedimiento manual en el que descargas un fichero CSV con las entradas (URIs) que Disqus ha registrado en la columna A para añadir en la B la nueva. En mi caso han sido más de 500 pero, OjO, 500 URIs no significan 500 comentarios ni por asomo. De hecho una de las cosas que he verificado es el poco interés que despierta mi blog por los pocos comentarios o recomendaciones recibidos :_( En fin.

El caso es que he querido verificar cada una de las URIs si eran dignas de ser migradas y sólo se me ha ocurrido un procedimiento manual que básicamente he gestionado con esta línea de bash:

 for a in `cat olea-2016-08-21T20-27-31.368505-links.csv ` ; do chrome "$a" && read -p  "pulsa Enter" ;done

Donde olea-2016-08-21T20-27-31.368505-links.csv es el fichero CSV descargado. El porqué del read es para evitar que se abran 500 solapas en el navegador.

En la práctica han sido muy pocas las URIs que he indicado migrar (20 o 30 máximo) porque no había más comentarios ni recomendaciones. A continuación, siguiendo las instrucciones de Disqus he subido el fichero CSV revisado y he esperado a que fuera procesado. Y listo.

En realidad me ha costado un poquito más porque ha cambiado el código que Disqus proporciona para integración y al final he encontrado este precioso código jekyll de Joshua Cox que ha terminado por resolver toda esta parte.

Ale, a disfrutarlo con salud.

PS: Igual hasta hacemos otro tallercín en el HackLab Almería para compartir la experiencia con los compis.

PD: He implementado el servicio 404 de Archive.org en mi blog. Basta con incluir estas líneas en tu página 404:

<div id="wb404"/>
<script src="https://archive.org/web/wb404.js"> </script>

y añadir la configuración correspondiente en, mi caso, Apache dentro de la correspondiente sección Virtualhost:

ErrorDocument 404 /404/

Y funcionando es una gozada: http://www.olea.org/pipermail/gentecilla/.

Adoro http://Archive.org.

(Editado el 20161124)

11 de agosto de 2016

Going to GUADEC 2016

I am at the airport getting ready to board beginning my trip to Karlsruhe for GUADEC 2016. I’ll be there with my colleague Michael Catanzaro.Please talk to us if you are interested in browsers or Igalia.

22 de julio de 2016

Padding con Vim

Tenemos la siguiente imagen ASCII:

Captura de pantalla 2016-07-22 a las 20.06.50

Si nos fijamos, hay líneas de distintas longitudes (las más largas son de 80 caracteres). Queremos hacer padding (rellenar) con el carácter ‘#’ para que todas las líneas sean de la misma longitud (80). Podemos hacerlo con un pequeño script en cualquier lenguaje de programación, pero la idea es: ¿se puede hacer con una única línea que use inteligentemente expresiones regulares y funciones en Vim? Sí 🙂

:%s/\v^.*$/\= submatch(0) . repeat("#", 80 - len(submatch(0)))

\v : magia, literal (ver la ayuda). Todos los caracteres que aparezcan tras este patrón se tomarán como caracteres especiales (no es necesario escaparlos). Efectivamente, olvídate de poner \(.*\) para hacer agrupaciones, basta con \v(.*)

^.*$ : desde el comienzo hasta el final de línea

\=  : comienzo de función

submatch(0) : primer match de la expresión regular (es la línea completa)

.  : concatenar con lo siguiente

repeat(“#”, 80 – len(submatch(0)))  : repetir el carácter #  x veces, donde x = 80 – longitud de línea

Éste es el resultado:

Captura de pantalla 2016-07-22 a las 20.19.27

16 de julio de 2016

14 de julio de 2016

Advanced Natural Language Processing Tools for Bot Makers – LUIS, Wit.ai, Api.ai

12 de julio de 2016

Novedades en la equivalencia internacional de títulos superiores españoles

Para empezar reconoceré que no tengo bien estudiada la regulación de las titulaciones universitarias en España. El caso es que he recibido el aviso de que se han publicado por fin las equivalencias internacionales de los títulos españoles. Por algún motivo tradicional, la estructura de las titulaciones superiores en España ha tenido poco que ver con las del resto del mundo. Se supone que ya todos sabemos cuáles han sido las transformaciones obligadas por «el plan Bolonia», que entre otras cosas pretende la movilidad de estudiantes y trabajadores y la interoperabilidad automática de los títulos superiores entre los paises comunitarios (creo que estrictamente va más allá de la UE pero hoy no es mi objetivo ser exhaustivo). Al parecer esa transformación de los títulos no era suficiente para saber cómo equivalen en el extranjero nuestros títulos. Y peor aún, cuáles son las equivalencias de los títulos superiores pre-Bolonia, que con frecuencia siguen siendo un lío al cambiar de universidad sin salir del país. La novedad es que parece que esa información ya ha quedado resuelta.

Siendo muy esquemático: el sistema de interoperabilidad de las titulaciones superiores en España se establece en el Marco Español de Cualificaciones para la Educación Superior (MECES), que, si yo no lo entiendo mal, sirve para establecer las equivalencias con el Marco Europeo de Cualificaciones para el Aprendizaje Permanente (EQF en inglés), que es la piedra de Rosetta para todo este sistema.

Pues bien, desde el 1 de junio de 2016 ya están publicadas oficialmente las equivalencias, como indican en el original: «correspondence between the Spanish Qualifications Framework for Higher Education and the European Qualifications Framework».

Cuadro MECES / EQF de equivalencias de títulos superiores españoles

¿Cuáles son las consecuencias? Probablemente algunas más, pero entiendo que al menos a partir de ahora, por ejemplo, puedes matricularte en cualquier universidad que implemente el EQF sin tener que pasar por el desesperante proceso de convalidación de tus títulos.

Dejo esta entrada a modo de recordatorio personal y con la esperanza de que sea de utilidad. Si alguien detecta algún error que por favor lo indique en los comentarios.

Referencias:

11 de mayo de 2016

Algunos recursos de investigación sobre calidad del software aplicada a proyectos de software libre

Con la excusa de responder a una solicitud de información sobre este tema he preparado un repaso, informal e incompleto, OjO, de recursos relacionados que tenía en mente. Y ya puestos lo cuelgo en el blog. Aquí está.

04 de mayo de 2016

Plataformas MOOC comparadas (III)

Progreso del alumno

En MiríadaX no han dejado de lado esta característica fundamental, pero creo que puede mejorarse significativamente. Para ello, compararemos la zona de progreso de edX con la de MiríadaX.

En edX, el alumno puede ver de un sólo vistazo, sin necesidad de hacer scroll cuántas tareas ha completado hasta el momento, cuántas le quedan por completar, cuál es la nota de corte para dar por aprobado el curso y el porcentaje actual de completamiento del curso:

progreso_edx

De forma sucinta, se indica el resultado de cada prueba y la fecha en la que se realizó.

Para ver el progreso de un alumno en MiríadaX, debemos pulsar en “Notas”. ¿Notas? Inicialmente entendí que era una zona para anotaciones relacionadas con el curso. ¿Por qué no “Progreso”? O de forma alternativa, “Calificaciones”. En fin, esto puede ser un detalle sin importancia. Lo importante es otra cosa:

Captura de pantalla 2016-04-26 a las 22.52.18

Lo primero es la falta de claridad. Ya hablamos de este “pecado” en otras entradas de esta serie. Pero en este caso se hace otra vez evidente. ¿Cuántos puntos (porcentaje) llevo en total? ¿Cuántos debo alcanzar para “aprobar” (nota de corte)? ¿Cuál es la calificación (o nota, siguiendo con la nomenclatura de MiríadaX) del módulo 1? Este curso tiene 10 módulos… Para ver el resultado de cada módulo debo desplazarme hasta el infinito en vertical…

Más aún, en la última entrega obligatoria del módulo 3, vemos un “No aprobado”.

miriadax_no_aprobado

Sin embargo, estoy totalmente seguro de que entregué la tarea y la tengo bien calificada por mis compañeros/as del curso. ¿Qué ocurre? No es evidente, pero el problema es que yo aún no he evaluado el trabajo de 3 de mis colegas. El estado no debería ser “No aprobada”, sino “En progreso”. De hecho, tengo hasta el 30 de mayo para hacer esas evaluaciones. Por cierto, no puedo acceder directamente a esa tarea para ver la razón de ese “No aprobada”. De hecho, si pulso en “Detalle”, se abre una ventana modal:

Captura de pantalla 2016-04-26 a las 23.00.20

Pero no hay enlaces para ver el enunciado de la tarea o las tareas de mis compañeros que me quedan por evaluar.

Tengo que pulsar en “Inicio”, desplazarme al “Módulo 3”, pulsar en “Acceder”, buscar la entrega obligatoria, pulsar en ella y ahí, por fin, ver la causa de mis males:

corregir_edx

Evalúo los dos trabajos que me quedan y ¡premio! ¿Era intuitivo? Yo creo que no.

edx_aprobado

03 de mayo de 2016

Plataformas MOOC comparadas (II)

Enunciado de los ejercicios 

Lo primero que podemos decir es que el interfaz gráfico, diseño y presentación de la sección de presentación de los ejercicios es muy mejorable. Me limitaré a mostrar una captura de pantalla:

Captura de pantalla 2016-04-25 a las 22.55.36

Desde luego, es de todo menos atractiva. Enormes cantidades de texto, sin gráficos ni separaciones evidentes. Ojo, no creo que sea un error del creador (creadores) del curso. Creo que es un error de diseño de la plataforma. Definitivamente no está preparada para impartir cursos MOOC. Veamos algo similar para el caso de Coursera:

maxresdefault

En la parte superior hay 3 cajas que dividen claramente las fases de un Ejercicio evaluado entre pares. En la parte central hay espacio para el enunciado del ejercicio y para aceptar el código de conducta. En la parte inferior hay una caja de texto para editar la respuesta o indicar mediante un enlace dónde encontrar la solución detallada. También permite guardar borradores (Save Draft), aspecto éste que brilla por su ausencia en MiriadaX.

En Coursera, también se especifica mediante colores (gris, verde, rojo) en que estado nos encontramos dentro de cada fase:

coursera_p2p_colores

En MiriadaX no existe este tipo de indicadores. Tampoco podemos auto-evaluarnos:

Captura de pantalla 2016-04-25 a las 23.23.16

Rúbricas (o la ausencia de ellas)

En MiriadaX, el interfaz para evaluar el trabajo de un compañero/a no dispone de una rúbrica de ayuda. No hay criterios, se limita a mostrar una caja de texto y una única puntuación, de 0 a 100:

sin_rubrica_miriadax

Esto es tremendamente incómodo. Al final, lo que hacen los alumnos es limitarse a escribir “Muy bien” o “Sigue así”. Dos o tres palabras y una nota de 100. Algo rápido y sin críticas constructivas de ningún tipo. En Coursera, sin embargo, el interfaz es más rico, se dispone de rúbricas de evaluación y cada criterio puede ser evaluado de forma independiente. Además, existe también una caja de texto donde, en algún curso, se pide cumplimentar al menos 20 palabras:

rubric_webform

Además, el alumno siempre tiene disponibles los criterios de evaluación de la rúbrica cuando está respondiendo a las preguntas/trabajos, lo que facilita la labor de respuesta:

coursera-fail-2-1

02 de mayo de 2016

Plataformas MOOC comparadas (I)

Introducción

A lo largo de esta semana iré publicando mis impresiones sobre las plataformas MOOC que he ido probando como alumno. Compararé aspectos relacionados con la docencia: herramientas para la presentación de contenidos, para el seguimiento del alumno, para la evaluación (autoevaluación, co-evaluación, hetero-evaluación), usabilidad, gestión de certificados, interacción entre usuarios (foros, chats) y también aspectos relacionados con el propio software que sustenta las plataformas (cómo están desarrolladas internamente, qué subsistemas usan, política de licencias).

Las plataformas que traeré a colación son edX, Coursera y MiríadaX,  porque son en éstas donde he trabajado como alumno, y edX y Moodle como plataformas en las que puedo decir algo sobre los aspectos de software, gracias a su licencia abierta.

Antes de nada, quería presentarme, haciendo especial hincapié en los aspectos relacionados con la enseñanza online que he trabajado, bien como alumno o bien como profesor.

También quiero dejar claro que todas las plataformas MOOC que tienen como objetivo expandir el conocimiento y lo hacen de forma gratuita y con materiales de calidad me merecen el mayor de los respetos. Me quito el sombrero ante el trabajo que han realizado (y siguen realizando) edX, Coursera, MiríadaX, Udacity, FutureLearn, P2P University y demás entidades. Lo que viene a continuación son una serie de posts sobre mi experiencia como usuario, como alumno o como desarrollador en todas estas plataformas, indicando los puntos buenos y malos y sugiriendo mejoras mediante análisis comparados.

Empezaremos comparando el sistema de MiríadaX con los de edX y Coursera, dado que son las plataformas sobre la que he estado trabajando más recientemente. MiríadaX usa internamente el CMS Liferay. No es una plataforma preparada ad-hoc para impartir MOOCs  (como podría ser Open-edX o la plataforma de Coursera) y eso se nota en multitud de detalles.  Veamos algunos de ellos, aspectos que no se han cuidado lo suficiente, no se han tenido en cuenta o son mejorables.

Variables sin valores asignados

Si nos fijamos en el mensaje de entrega de una tarea, veremos lo siguiente:entrega1

“La asignación de tareas para evaluar se realizará a las {4} del día {5}, fecha de la zona horaria {6}, que es la establecida en tu perfil.” No es algo que ocurra una vez en una pantalla, ni siquiera algo que ocurrió una vez o dos. Ocurre siempre, desde hace meses.

Incoherencia en la forma de dirigirse al alumno

¿Cómo nos dirigimos al alumno? ¿Debemos usar el tratamiento de usted o el de tú? Entiendo el trato de usted y me parece correcto. Pero en mi caso, me resulta muy artificial. Agradecería una opción que permitiera elegir entre una forma u otra de dirigirse al alumno. No obstante, eso no sería un error: basta con elegir el tratamiento. Sin embargo, lo que sí es un error es “bailar” en el uso de usted y tú.  Si nos fijamos en la ventana anterior, veremos un tratamiento de tú: “Próximamente recibirás…”, “Recuerda realizar…”. Sin embargo, en otras pantallas, vemos el tratamiento de usted, como en la siguiente: “Piensen bien su evaluación…”, “El objetivo de este curso es sacar el máximo provecho al trabajo que están realizando…”

tu_usted

Imposibilidad de reintentar la entrega antes de que finalice el plazo

Una de las aportaciones interesantes de un MOOC es que el alumno puede trabajar por su cuenta, a su ritmo, e ir mejorando sus conocimientos mediante iteraciones: construye una solución y la guarda como posible envío. Esta primera solución seguramente no sea óptima. El alumno puede darse cuenta estudiando algo más, o comentando los problemas encontrados con sus compañeros en el foro. Esta retroalimentación le permitirá mejorar su solución y grabarla como una entrega mejorada. En cualquier caso, es muy conveniente que el sistema que da soporte al MOOC permita la grabación de soluciones. No digo que mantenga un histórico, bastaría con que nos deje guardar un único trabajo, pero que éste se pueda subir tantas veces como se quiera, siempre dentro del plazo de entrega. Cada vez que el alumno envíe, la nueva entrega sustituirá a la anterior (lo ideal, como digo, sería un histórico, pero esta solución parcial de “nos quedamos con la última”, valdría). Lo que no es de recibo es limitar a un único envío, tal y como hace MiríadaX. Avisan por activa y por pasiva que el envío, único, es final. No importa que aún queden días para el “deadline”. No podrás cambiar ni reenviar mejoras a tu trabajo, está prohibido mejorar 🙁 Este es un aspecto que ninguna plataforma MOOC (edX, Coursera, Udacity, FutureLearn, Google CourseBuilder) ha descuidado. Es un error de libro, sin embargo, ahí está.

entrega3

No entiendo esta restricción. Es muy probable que una vez entregada la tarea, y el alumno esté más relajado, se le ocurran mejoras a la entrega realizada. O simplemente, quiere enviar una versión preliminar – digna, pero no excelente – por si acaso no le da tiempo a completar la versión final, de mayor calidad. Tal cuál está planteada la entrega, esto no puede hacerse. Una entrega evaluada entre pares no es razón para este comportamiento. Puede alegarse que se hace para que los alumnos dispongan rápidamente de ejercicios para evaluar, pero no hay razón para hacerlo así. Se puede dejar un período de evaluación de una semana a partir del momento de la entrega. Por ejemplo,en edX y en Coursera, el alumno puede enviar tantas versiones de su tarea mientras no haya terminado el plazo de entrega.

Por otro lado, se recomienda adjuntar una versión del archivo html con la solución, pero si ya está online… no le veo mucho sentido. Entiendo que pueda ser una medida de seguridad (por si la versión online cae), pero implica nuevos problemas: si la versión online y el archivo (versión offline) varían, ¿cuál evaluar? si la versión offline no incluye referencias a gráficos o vídeos porque están enlazados, ¿qué hacer? y si las incluyen (¿un vídeo?), ¿para qué ofrecer dos versiones?.

13 de abril de 2016

Chromium Browser on xdg-app

Last week I had the chance to attend for 3 days the GNOME Software Hackfest, organized by Richard Hughes and hosted at the brand new Red Hat’s London office.

And besides meeting new people and some old friends (which I admit to be one of my favourite aspects about attending these kind of events), and discovering what it’s now my new favourite place for fast-food near London bridge, I happened to learn quite a few new things while working on my particular personal quest: getting Chromium browser to run as an xdg-app.

While this might not seem to be an immediate need for Endless right now (we currently ship a Chromium-based browser as part of our OSTree based system), this was definitely something worth exploring as we are now implementing the next version of our App Center (which will be based on GNOME Software and xdg-app). Chromium updates very frequently with fixes and new features, and so being able to update it separately and more quickly than the OS is very valuable.

Endless OS App Center
Screenshot of Endless OS’s current App Center

So, while Joaquim and Rob were working on the GNOME Software related bits and discussing aspects related to Continuous Integration with the rest of the crowd, I spent some time learning about xdg-app and trying to get Chromium to build that way which, unsurprisingly, was not an easy task.

Fortunately, the base documentation about xdg-app together with Alex Larsson’s blog post series about this topic (which I wholeheartedly recommend reading) and some experimentation from my side was enough to get started with the whole thing, and I was quickly on my way to fixing build issues, adding missing deps and the like.

Note that my goal at this time was not to get a fully featured Chromium browser running, but to get something running based on the version that we use use in Endless (Chromium 48.0.2564.82), with a couple of things disabled for now (e.g. chromium’s own sandbox, udev integration…) and putting, of course, some holes in the xdg-app configuration so that Chromium can access the system’s parts that are needed for it to function (e.g. network, X11, shared memory, pulseaudio…).

Of course, the long term goal is to close as many of those holes as possible using Portals instead, as well as not giving up on Chromium’s own sandbox right away (some work will be needed here, since `setuid` binaries are a no-go in xdg-app’s world), but for the time being I’m pretty satisfied (and kind of surprised, even) that I managed to get the whole beast built and running after 4 days of work since I started :-).

But, as Alberto usually says… “screencast or it didn’t happen!”, so I recorded a video yesterday to properly share my excitement with the world. Here you have it:


[VIDEO: Chromium Browser running as an xdg-app]

As mentioned above, this is work-in-progress stuff, so please hold your horses and manage your expectations wisely. It’s not quite there yet in terms of what I’d like to see, but definitely a step forward in the right direction, and something I hope will be useful not only for us, but for the entire Linux community as a whole. Should you were curious about the current status of the whole thing, feel free to check the relevant files at its git repository here.

Last, I would like to finish this blog post saying thanks specially to Richard Hughes for organizing this event, as well as the GNOME Foundation and Red Hat for their support in the development of GNOME Software and xdg-app. Finally, I’d also like to thank my employer Endless for supporting me to attend this hackfest. It’s been a terrific week indeed… thank you all!

Credit to Georges Stavracas

Credit to Georges Stavracas

04 de abril de 2016

Mala semana para la seguridad de las extensiones en Firefox y Chrome

Investigadores de seguridad presentaron la semana pasada, en la Black Hat Asia 2016, bajo la ponencia “Automated Detection of Firefox Extension-Reuse Vulnerabilities” una extensión que reutiliza código de otras ya instaladas con fines maliciosos. Es una técnica nueva (extension-reuse) interesante.

En febrero presentaron un artículo sobre la misma vulnerabilidad (CrossFire: An Analysis of Firefox Extension-Reuse Vulnerabilities) en el simposium “The Network and Distributed System Security Symposium 2016” organizado por la Internet Society.

Y siguiendo con los ataques de seguridad a las extensiones, hoy se publica una noticia sobre una empresa que en febrero compró una extensión bastante popular (Better History) para inyectarle código malicioso que hace que los navegadores de sus usuarios sean redirigidos, a través de un enlace lnkr.us, a páginas con banners -al parecer a la página que más pague a la empresa- cada vez que pinchan en un enlace (realmente el 50% de la veces y no es una redirección simple, sino que la página original a la que el usuario se dirigía también se abre). El comportamiento no es maligno únicamente por esto, sino porque la empresa de esta extensión está recogiendo datos privados sobre las URL que los usuarios visitan. Para más inri, el código fuente de Better History en GitHub no refleja los añadidos maliciosos que la compañía ha introducido.

Google ha eliminado la extensión de la Chrome Store, pero los usuarios han advertido de que este comportamiento se repite en otras extensiones populares como Chrome Currency Converter, Web Timer, User-Agent Switcher, Better History, 4chan Plus, and Hide My Adblocker.

Google ha eliminado también User-Agent Switcher, pero el resto sigue online.

25 de marzo de 2016

Instalando mod_wsgi en OSX El Capitan

Receta rápida:

$ git clone https://github.com/GrahamDumpleton/mod_wsgi.git
$ cd mod_wsgi
$ ./configure
$ make
$ sudo make install
$ sudo vim /etc/apache2/httpd.conf

Añadir las siguientes dos líneas:

LoadModule wsgi_module libexec/apache2/mod_wsgi.so
WSGIScriptAlias / /Library/WebServer/Documents/

Reiniciar Apache y comprobar:

$ sudo apachectl restart
$ apachectl -M | grep wsgi
 wsgi_module (shared)

Podemos probar con este Hello World (hello.py). Copiarlo en /Library/WebServer/Documents y abrirlo desde el navegador con http://localhost/hello.py :

import os, sys
sys.path.append('.')
def application(environ, start_response):
    status = '200 OK'
    output = 'Hello world!!\n'
    response_headers = [('Content-type', 'text/plain'),
        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
    return [output]

Done.

22 de marzo de 2016

WebKitGTK+ 2.12

We did it again, the Igalia WebKit team is pleased to announce a new stable release of WebKitGTK+, with a bunch of bugs fixed, some new API bits and many other improvements. I’m going to talk here about some of the most important changes, but as usual you have more information in the NEWS file.

FTL

FTL JIT is a JavaScriptCore optimizing compiler that was developed using LLVM to do low-level optimizations. It’s been used by the Mac port since 2014 but we hadn’t been able to use it because it required some patches for LLVM to work on x86-64 that were not included in any official LLVM release, and there were also some crashes that only happened in Linux. At the beginning of this release cycle we already had LLVM 3.7 with all the required patches and the crashes had been fixed as well, so we finally enabled FTL for the GTK+ port. But in the middle of the release cycle Apple surprised us announcing that they had the new FTL B3 backend ready. B3 replaces LLVM and it’s entirely developed inside WebKit, so it doesn’t require any external dependency. JavaScriptCore developers quickly managed to make B3 work on Linux based ports and we decided to switch to B3 as soon as possible to avoid making a new release with LLVM to remove it in the next one. I’m not going to enter into the technical details of FTL and B3, because they are very well documented and it’s probably too boring for most of the people, the key point is that it improves the overall JavaScript performance in terms of speed.

Persistent GLib main loop sources

Another performance improvement introduced in WebKitGTK+ 2.12 has to do with main loop sources. WebKitGTK+ makes an extensive use the GLib main loop, it has its own RunLoop abstraction on top of GLib main loop that is used by all secondary processes and most of the secondary threads as well, scheduling main loop sources to send tasks between threads. JavaScript timers, animations, multimedia, the garbage collector, and many other features are based on scheduling main loop sources. In most of the cases we are actually scheduling the same callback all the time, but creating and destroying the GSource each time. We realized that creating and destroying main loop sources caused an overhead with an important impact in the performance. In WebKitGTK+ 2.12 all main loop sources were replaced by persistent sources, which are normal GSources that are never destroyed (unless they are not going to be scheduled anymore). We simply use the GSource ready time to make them active/inactive when we want to schedule/stop them.

Overlay scrollbars

GNOME designers have requested us to implement overlay scrollbars since they were introduced in GTK+, because WebKitGTK+ based applications didn’t look consistent with all other GTK+ applications. Since WebKit2, the web view is no longer a GtkScrollable, but it’s scrollable by itself using native scrollbars appearance or the one defined in the CSS. This means we have our own scrollbars implementation that we try to render as close as possible to the native ones, and that’s why it took us so long to find the time to implement overlay scrollbars. But WebKitGTK+ 2.12 finally implements them and are, of course, enabled by default. There’s no API to disable them, but we honor the GTK_OVERLAY_SCROLLING environment variable, so they can be disabled at runtime.

But the appearance was not the only thing that made our scrollbars inconsistent with the rest of the GTK+ applications, we also had a different behavior regarding the actions performed for mouse buttons, and some other bugs that are all fixed in 2.12.

The NetworkProcess is now mandatory

The network process was introduced in WebKitGTK+ since version 2.4 to be able to use multiple web processes. We had two different paths for loading resources depending on the process model being used. When using the shared secondary process model, resources were loaded by the web process directly, while when using the multiple web process model, the web processes sent the requests to the network process for being loaded. The maintenance of this two different paths was not easy, with some bugs happening only when using one model or the other, and also the network process gained features like the disk cache that were not available in the web process. In WebKitGTK+ 2.12 the non network process path has been removed, and the shared single process model has become the multiple web process model with a limit of 1. In practice it means that a single web process is still used, but the network happens in the network process.

NPAPI plugins in Wayland

I read it in many bug reports and mailing lists that NPAPI plugins will not be supported in wayland, so things like http://extensions.gnome.org will not work. That’s not entirely true. NPAPI plugins can be windowed or windowless. Windowed plugins are those that use their own native window for rendering and handling events, implemented in X11 based systems using XEmbed protocol. Since Wayland doesn’t support XEmbed and doesn’t provide an alternative either, it’s true that windowed plugins will not be supported in Wayland. Windowless plugins don’t require any native window, they use the browser window for rendering and events are handled by the browser as well, using X11 drawable and X events in X11 based systems. So, it’s also true that windowless plugins having a UI will not be supported by Wayland either. However, not all windowless plugins have a UI, and there’s nothing X11 specific in the rest of the NPAPI plugins API, so there’s no reason why those can’t work in Wayland. And that’s exactly the case of http://extensions.gnome.org, for example. In WebKitGTK+ 2.12 the X11 implementation of NPAPI plugins has been factored out, leaving the rest of the API implementation common and available to any window system used. That made it possible to support windowless NPAPI plugins with no UI in Wayland, and any other non X11 system, of course.

New API

And as usual we have completed our API with some new additions:

 

19 de marzo de 2016

¡Cifremos la web!

Qué es Let’s Encrypt

Es bien sabido que conviene cifrar siempre que podamos, y la web no lo es menos. De hecho, hace tiempo que Google fomenta el uso de web cifrada amenazando con penalizar aquellas que no lo estén.

El caso es que, para tener una web cifrada, tenemos dos problemas: por un lado, comprar un certificado a una entidad certificadora reconocida, y por otro, renovarlo periódicamente (lo que suele tener un coste también). Desde hace tiempo, iniciativas como CaCert, intentaron crear una autoridad certificadora libre de costes para sus usuarios y gestionada por la comunidad, de la que, pese a ser yo mismo uno de sus notarios, tengo que decir que su éxito ha sido siempre escaso, entre otras razones porque lleva ya bastantes años con nosotros y aún no es reconocida por la mayoría de los navegadores.

Por otro lado, la renovación tiene otro problema: hay que estar pendiente de ello. Para resolver ambos problemas, ha surgido una iniciativa, llamada Let’s Encrypt.

Let's Encrypt

Lo primero que vemos es que la reconocen todos los navegadores. El coste de conseguir esto debe estar cubierto por la multitud de sponsors que tiene el proyecto.

En segundo lugar, utiliza un desafío, llamado ACME, para verificar que la web que queremos cifrar es la dueña del dominio a usar (por ejemplo, https://dramor.net/). Con esta verificación, se pueden emitir sin problemas, certificados sin coste (al ser generados automáticamente), siempre que no necesitemos otras características como la validación de identidad.

Veremos que con este proyecto, se pueden conseguir certificados de sitio web de forma bastante sencilla. Por ejemplo, veamos cómo se resuelve para Nginx.

Implementación en los sitios de DrAmor.net

Antes de nada, decir que no voy a dar la configuración completa de nginx, entendiendo que el lector sabrá de lo que hablo, o podrá ayudarse de los tutoriales mencionados en este artículo.

En general, lo que veremos nos vale en cualquier Linux o Unix que pueda ejecutar git, python y nginx. Lo primero que haremos es bajarnos el repositorio de Let’s Encrypt:

$ git clone https://github.com/letsencrypt/letsencrypt

Este repositorio trae plugins para varios servidores web, pero como Nginx no está aun bien soportado, debemos usar el plugin webroot.

Hemos seguido la documentación oficial y el tutorial de Digital Ocean para hacernos una idea, aunque los pasos seguidos fueron, en primer lugar crear un fichero de configuración llamado /etc/letsencrypt/letsencrypt-dramor.net.ini:

rsa-key-size = 4096

email = Direccion-email-valida@gmail.com

webroot-map = {"dramor.net,www.dramor.net":"/var/www/dramor.net", "blog.dramor.net,www.blog.dramor.net":"/var/www/dramor_blog", "home.dramor.net":"/var/www/dramor_home"}

Por supuesto, el e-mail debe ser correcto. Lo oculto con el ánimo de evitar un poco el spam, claro. Y el webroot-map no es más que un formato json donde especifica los dominios a firmar, junto con la carpeta raíz de cada sitio, que debe incluir una subcarpeta publicada por nginx, para poder ejecutar el desafío ACME.

La carpeta a publicar en nginx se debe llamar .well-known. Por ejemplo, la podemos publicar en los sitios virtuales nginx con:

location ~ /.well-known {
    allow all;
}

Una vez configurado nginx, ya podemos generar los certificados:

$ cd letsencrypt

$ sudo ./letsencrypt-auto certonly -a webroot --renew-by-default --config /etc/letsencrypt/letsencrypt-dramor.net.ini
Checking for new version...
Requesting root privileges to run letsencrypt...
   sudo /home/jjamor/.local/share/letsencrypt/bin/letsencrypt certonly -a webroot --renew-by-default --config /etc/letsencrypt/letsencrypt-dramor.net.ini

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/dramor.net/fullchain.pem. Your cert will
   expire on 2016-06-16. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.
 - If you like Let's Encrypt, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

La primera vez creará un virtualenv de la versión de Python requerida, y actualizará algunos paquetes. Una vez generados los certificados, se instalan en: /etc/letsencrypt/live/dramor.net. Si dio algún error, debemos revisar que esté accesible .well-known en los sitios virtuales de nginx, y que los DNS del dominio deseado apunten correctamente al servidor web, entre otras cosas. Los mensajes de error siempre son lo suficientemente descriptivos como para no requerir más explicación. Por ejemplo, nos puede avisar de que algún nombre DNS del dominio a asegurar no resuelve correctamente el registro A o CNAME, o no apunta a nuestro servidor.

Usar los certificados en Nginx ya es cosa de usar las líneas de configuración de nginx similares a:

ssl_certificate /etc/letsencrypt/live/dramor.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/dramor.net/privkey.pem;

Renovación automática

Los certificados así generados tienen una vigencia de solo tres meses. Pero renovarlos consiste simplemente en volver a ejecutar el desafío ACME.

Para ello, solo hay que llamar a letsencrypt-auto con otro parámetro:

$ ./letsencrypt-auto renew

Podemos hacer un script a ejecutar periódicamente (por ejemplo, un cron semanal), que realice esta acción y a continuación ejecute un reload de nginx. De este modo, podemos olvidarnos de las renovaciones: tendrán lugar cuando hagan falta.

Conviene probar todos los scripts antes de automatizarlo con el cron. Por ejemplo, si nada más generar los certificados intentamos renovarlos:

$ ./letsencrypt-auto renew
Checking for new version...
Requesting root privileges to run letsencrypt...
   sudo /home/jjamor/.local/share/letsencrypt/bin/letsencrypt renew
Processing /etc/letsencrypt/renewal/dramor.net.conf

The following certs are not due for renewal yet:
  /etc/letsencrypt/live/dramor.net/fullchain.pem (skipped)
No renewals were attempted.

Podemos forzar la renovación para verificar que funciona, con:

$ ./letsencrypt-auto renew --force-renewal

Por último, indicar que si vamos a hacer muchas pruebas, mejor generemos los certificados con la opción staging, para que que se generen certificados no válidos. Si hacemos muchas pruebas seguidas, alcanzaremos fácilmente el límite diario y no podremos generar más hasta el día siguiente.

Si hemos hecho todo correctamente, podremos navegar por el sitio web con cifrado; y si queremos, podemos comprobar la calidad del mismo aquí: SSLLabs. Conseguir una buena puntuación ya es cosa de seguir determinadas buenas prácticas con el servidor web, que no cubriré aquí.

07 de marzo de 2016

Transmission, torrents, OSX y malware KeRanger

Captura de pantalla 2016-03-07 a las 22.49.09 Cuando necesito descargar torrents, uso Transmission en Linux y uTorrent en OSX. No es que uTorrent esté libre de pecado (Spigot -PUP-,  EpicScale -mining de bitcoin no deseado, y demás basura), pero la semana pasada (4 de marzo) Transmission para OSX llevaba de regalo  KeRanger, ransomware. Sí, malware que cifra el contenido de tu disco duro y te pide un rescate – pagado en bitcoin, por supuesto- para obtener la clave que lo descifra. Parece ser el primer caso de ransomware dirigido específicamente a usuarios de OSX. Fue la gente de Palo Alto Networks fueron los primeros en dar el aviso, indicando que la web de Transmission había sido comprometida, dejando un fichero de instalación .dmg(la versión 2.90 de Transmission) infectado con KeRanger. Lo “bonito” del asunto es que esta versión de KeRanger había sido firmada con un certificado válido de desarrollador de aplicaciones para OSX, saltándose el control básico de Apple Gatekeeper que impide a un usuario básico instalar una aplicación que no venga firmada (se salta abriendo el binario con el menú contextual mientras pulsas Control, pero es una primera barrera de seguridad). Si el usuario instaló la versión infectada de Transmission, esta ejecutará una versión incrustada de KeRanger, esperará 3 días (suele ser habitual esperar a ejecutar el castigo, para ocultar al usuario el origen de la infección) y se comunicará con un servidor C&C (Command & Control) sobre la red Tor. A partir de ahí, cifrado del disco y petición de rescate (400 dólares).

Apple ha actuado rápido. Lo primero, invalidar el certificado con el que se firmó la aplicación en cuestión. Lo segundo, añadir una regla a XProtect, el sistema de lista negra que usa OSX por defecto. Puedes consultar los bichos que pululan por Internet en este fichero de tu OSX: /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist. ¿El primero de la lista? Nuestro amigo KeRanger:

Captura de pantalla 2016-03-07 a las 23.21.41

El análisis técnico del bicho en la página de Palo Alto Networks merece mucho la pena. Verás que el desarrollador está preparando funciones específicas para buscar y cifrar backups de Time Machine (qué angelito…). Verás también que usa tanto cifrado asimétrico (RSA) para cifrar un número elegido al azar junto a un IV dependiente del contenido del fichero, con lo que formará la clave que usará para cifrar el contenido del fichero usando cifrado simétrico (AES).

El 5 de marzo la gente de Transmission eliminó el ejecutable infectado de su web. Apple también ha hecho su trabajo. Pero el secuestro de webs para implantar malware parece que está de moda. Hace un par de semanas fue el turno de Linux Mint. Esta semana ha caído Transmission. ¿Quién será el siguiente?

Formateo y validación de objetos JSON

En esta ocasión, aprovechando que esta semana se estudia el formato JSON en una de mis clases, os quería recomendar un par de utilidades que utilizo a menudo: la herramienta jq y el plugin JSONView.

jq es una utilidad de la línea de comandos disponible para Linux, OS X y Windows que permite validar y visualizar de forma muy agradable objetos JSON. La mejor forma de apreciar el uso de jq es por medio de un ejemplo. En la siguiente figura, muestro un objeto JSON en la terminal sin usar jq. A continuación lo vuelvo a mostrar, esta vez filtrándolo con jq. Mucho mejor, ¿no?

Captura de pantalla 2016-03-07 a las 21.29.34

 

jq también detecta objetos JSON inválidos, marcando dónde se encuentra el error:

Captura de pantalla 2016-03-07 a las 22.00.40

JSONView es similar a jq, pero funciona como plugin o extensión, tanto de Google Chrome como de Mozilla Firefox. Veamos un ejemplo con el resultado de una llamada al API de OpenWeatherMap.

Sin usar JSONView:

Captura de pantalla 2016-03-07 a las 21.44.06

Con la extensión JSONView instalada:

Captura de pantalla 2016-03-07 a las 21.43.51

Sí, representan exactamente el mismo resultado. Pero uno es legible por humanos y el otro no 🙂

¿Conocíais estas utilidades? ¿Qué extensiones usáis en vuestros desarrollos? (HTML5, JS, PHP, whatever…)

05 de marzo de 2016

Demasiadas conexiones a MySQL desde R

Estoy desarrollando una nueva aplicación en R+Shiny. Entre otras cosas, el servidor Shiny necesita acceder a los datos de una BBDD en MySQL. Tengo código en R que accede a MySQL sin problemas, abre y cierra las conexiones bien, sin leaks  por dejar conexiones abiertas. Bueno, eso es lo que creía… cuando por alguna razón la aplicación fallaba, podían darse casos en los que alguna conexión se quedaba abierta. Por una o dos, no pasaba “nada”. Pero probando y probando, llegué a este error:

“cannot allocate a new connection — maximum of 16 connections  already opened”

Vaya… el primer problema es: ¿cómo desconecto las conexiones abiertas? La respuesta a esto en la lista de distribución de R:

cons <- dbListConnections(MySQL()) 
 for(con in cons) 
  dbDisconnect(con)

Y ahora, ¿cómo evitar el error? Lo ideal sería establecer una especie de conexión singleton que se reutilizara desde todo el código. La respuesta a esto, en StackOverflow (cómo no ;-))

library(RMySQL)
getConnection <- function(group) {
  if (!exists('.connection', where=.GlobalEnv)) {
    .connection <<- dbConnect(MySQL(), group=group)
  } else if (class(try(dbGetQuery(.connection, "SELECT 1"))) == "try-error") {
    dbDisconnect(.connection)
    .connection <<- dbConnect(MySQL(), group=group)
  }
  return(.connection)
}

Este código comprueba si existe una conexión en el entorno global. Si no existe, la crea y la devuelve.
Si existe, comprueba que se pueda usar. Si no se puede usar, desconecta y vuelve a crear la conexión, para devolverla.
Es decir, funciona como una caché (o puede verse también como un objeto singleton de tipo connection).
Podríamos ignorar el parámetro group de la función getConnection y en su lugar, usar:

dbConnect(MySQL(), user=login, password=pass, db=database, host=host)

allí donde fuera necesario.

Configuración de WordPress

Después de varios días por fin saco tiempo para continuar la entrada del otro día donde os comentaba las bondades de WordPress. Hoy voy a daros algunos consejos sobre como configurarlo:

1. Estructura Permalink

Lo primero que debes cambiar es la estructura de enlaces permanentes. Se encuentran en Configuración → Enlaces permanentes. El enlace permanente por defecto es <postid>, pero yo prefiero utilizar el nombre de la entrada:

/%postname%/

Permalinks

2. ¿SSL o no SSL?

En 2014 Google anunció que las webs corriendo bajo https tendrían mejor valoración de cara al posicionamiento por este motivo muchas web han cambiado a SSL. Todo depende de nuestro presupuesto, los SSL cuestan $$$.

3. ¿WWW vs no-WWW?

Aquí es cuestión de gustos, si quieres que tu blog aparezca en el navegador como como www.example.com o simplemente example.com. Asegúrate de que en Configuración → General, la versión que deseas aparece correctamente.

4. Optimiza las descripciones

Los webmaster suelen centrarse en los títulos pero nunca hay que dejar de lado las descripciones. La descripción muestra una parte de información muy importante en los resultados de búsqueda y podemos incluir en ella las palabras clave (keywords) que queremos resaltar.

5. Limpiar el código

Reduce al mínimo posible los Javascript y CSS que pueda tener tu plantilla. Google valora la rapidez de carga de tu web, de hecho hay un test específico para ello que mide tanto la versión normal como la móvil (responsive):

Test de velocidad de carga de Google

6. SEO y contenido duplicado

Debes huir siempre del contenido duplicado ya que es una de las cosas que más penalizan a la hora de posicionar tu blog. Google tiene avanzados algoritmos que analizan el texto (densidad keywords, frases, párrafos, incluso el conjunto!) para ver si son copiados de otros existentes.

7. Encabezamientos (headers)

Aunque cada vez tienen menor peso en el SEO aún sigue siendo una buena idea poner algunos textos con encabezamientos, por ejemplo el de mayor tamaño <h1> para el nombre de la entrada. Puedes poner también algún <h2> y <h3> para slogan o títulos secundarios.

 

02 de marzo de 2016

De DiarioLinux.com a Ikasten.io

Llevo mucho tiempo intentando escribir este post. Incluso creo que lo llegué a hacer, pero perdí el fichero donde lo guardaba. No recuerdo si lo hice en un documento de Google Drive, en Keep, en un fichero de texto plano, en un borrador de post, en un mensaje de correo a mí mismo… o si lo soñé, que también puede ser. El mero hecho de perderlo o de no saber a ciencia cierta si lo llegué a crear, me da que pensar. Vivimos una época en la que las conversaciones se llevan a cabo en redes sociales (Facebook, Twitter) y programas de mensajería instantánea (WhatsApp, Telegram). Todo es rápido, al momento, todo se consume de manera inmediata. No queda tiempo para sentarse a reflexionar y menos para escribir posts largos.

Antes no era así. Recuerdo una época en la que escribía largos mensajes varias veces a la semana. Eran posts con enjundia, donde compartía conocimiento práctico que había probado con calma. Eran posts sobre temas relacionados con Linux y el software libre. Era lo que me movía. Era un bonito “trabajo”, que me llevó de 2001 a 2014. En los últimos dos años (2014-2015) dejé de escribir en el blog. Sucumbí a las redes sociales. En especial, a Twitter. Sucumbí al software privativo, en especial al sistema OSX.

Abandoné DiarioLinux, pero no abandoné Linux. Sigo usándolo, pero no en el escritorio. Me cansé de pelear con drivers, configuraciones, aplicaciones y entornos. Quería seguir trabajando con un sistema Unix. Pero también quería las últimas aplicaciones. Y sucumbí a la manzana. Es curioso, esa historia de la manzana ya ocurrió hace miles de años 😉

La cuestión es que tengo ganas de tomarme las cosas con más calma. Y de escribir de forma más pausada y pensada de lo  que escribo en Twitter. ¿Quiere esto decir que dejaré de tuitear? No, seguiré haciéndolo, aunque probablemente bajando la frecuencia. Sigo creyendo que Twitter aporta mucha información de calidad (aparte de montañas de ruido). Gran parte de esta información la tengo marcada con un “favorito” (ahora, con un corazón, cursi, rojo). Hasta ahora, marcaba así los tuits en los que me interesaba profundizar. “Cuando tenga tiempo”. “Este enlace quiero leerlo con calma”. Autoengaños. Ahí siguen, marcados pero sin leer. Como los cientos de libros técnicos en formato digital que acumulo (casi 300, y subiendo) para leer algún día (será imposible hacerlo).

Así que toca simplificar. No preocuparse tanto por acumular, sino por soltar lastre. No preocuparse tanto por las novedades, sino por profundizar en alguna de ellas o en alguna de las que, en su día, fue novedad marcada como “favorita” e interesante, pero de la que nunca más supe. Eso es lo que pretendo hacer, pararme a inspeccionar con más detalle aquellos temas que piquen mi curiosidad. Temas técnicos en su mayor parte, pero también sobre docencia, idiomas, running, series, cine o libros. Como veis, temas que no estarán ceñidos sólo a Linux o al Software Libre. Temas, en general, sobre los que querría aprender más. De ahí el cierre de DiarioLinux y el comienzo de este nuevo blog, Ikasten.io /Aprendiendo/.

Espero que estas reflexiones no se queden sólo en eso o que, al menos, pasen a formar parte de una buena colección de posts al respecto 🙂

PD: DiarioLinux.com cerrará, pero no se perderá el contenido. Todos los posts, comentarios e imágenes adjuntas han sido copiadas a ikasten.io dentro del subdominio diariolinux.ikasten.io. Por el momento, diariolinux.com estará unos meses redirigiendo el tráfico (con cabeceras 301 Redirect). En 2017 cerrará definitivamente.

26 de febrero de 2016

Über latest Media Source Extensions improvements in WebKit with GStreamer

In this post I am going to talk about the implementation of the Media Source Extensions (known as MSE) in the WebKit ports that use GStreamer. These ports are WebKitGTK+, WebKitEFL and WebKitForWayland, though only the latter has the latest work-in-progress implementation. Of course we hope to upstream WebKitForWayland soon and with it, this backend for MSE and the one for EME.

My colleague Enrique at Igalia wrote a post about this about a week ago. I recommend you read it before continuing with mine to understand the general picture and the some of the issues that I managed to fix on that implementation. Come on, go and read it, I’ll wait.

One of the challenges here is something a bit unnatural in the GStreamer world. We have to process the stream information and then make some metadata available to the JavaScript app before playing instead of just pushing everything to a playing pipeline and being happy. For this we created the AppendPipeline, which processes the data and extracts that information and keeps it under control for the playback later.

The idea of the our AppendPipeline is to put a data stream into it and get it processed at the other side. It has an appsrc, a demuxer (qtdemux currently

) and an appsink to pick up the processed data. Something tricky of the spec is that when you append data into the SourceBuffer, that operation has to block it and prevent with errors any other append operation while the current is ongoing, and when it finishes, signal it. Our main issue with this is that the the appends can contain any amount of data from headers and buffers to only headers or just partial headers. Basically, the information can be partial.

First I’ll present again Enrique’s AppendPipeline internal state diagram:

First let me explain the easiest case, which is headers and buffers being appended. As soon as the process is triggered, we move from Not started to Ongoing, then as the headers are processed we get the pads at the demuxer and begin to receive buffers, which makes us move to Sampling. Then we have to detect that the operation has ended and move to Last sample and then again to Not started. If we have received only headers we will not move to Sampling cause we will not receive any buffers but we still have to detect this situation and be able to move to Data starve and then again to Not started.

Our first approach was using two different timeouts, one to detect that we should move from Ongoing to Data starve if we did not receive any buffer and another to move from Sampling to Last sample if we stopped receiving buffers. This solution worked but it was a bit racy and we tried to find a less error prone solution.

We tried then to use custom downstream events injected from the source and at the moment they were received at the sink we could move from Sampling to Last sample or if only headers were injected, the pads were created and we could move from Ongoing to Data starve. It took some time and several iterations to fine tune this but we managed to solve almost all cases but one, which was receiving only partial headers and no buffers.

If the demuxer received partial headers and no buffers it stalled and we were not receiving any pads or any event at the output so we could not tell when the append operation had ended. Tim-Philipp gave me the idea of using the need-data signal on the source that would be fired when the demuxer ran out of useful data. I realized then that the events were not needed anymore and that we could handle all with that signal.

The need-signal is fired sometimes when the pipeline is linked and also when the the demuxer finishes processing data, regardless the stream contains partial headers, complete headers or headers and buffers. It works perfectly once we are able to disregard that first signal we receive sometimes. To solve that we just ensure that at least one buffer left the appsrc with a pad probe so if we receive the signal before any buffer was detected at the probe, it shall be disregarded to consider that the append has finished. Otherwise, if we have seen already a buffer at the probe we can consider already than any need-data signal means that the processing has ended and we can tell the JavaScript app that the append process has ended.

Both need-data signal and probe information come in GStreamer internal threads so we could use mutexes to overcome any race conditions. We thought though that deferring the operations to the main thread through the pipeline bus was a better idea that would create less issues with race conditions or deadlocks.

To finish I prefer to give some good news about performance. We use mainly the YouTube conformance tests to ensure our implementation works and I can proudly say that these changes reduced the time of execution in half!

That’s all folks!

08 de febrero de 2016

WordPress SEO

Con la invención de Internet y el marketing digital el alcance de la optimización de motores de búsqueda (SEO) se ha convertido en uno de los métodos preferidos de promoción web. Por este motivo en la entrada de hoy quiero hablaros de como utilizar el software de blogs más conocido del mundo (WordPress) para mejorar el SEO de vuestras webs.

SEO, en términos generales se denomina como la optimización de motores de búsqueda. A diario millones de personas utilizan los buscadores para acceder a la información que necesitan. Aparecer en las primeras posiciones de las palabras clave (keywords) es imprescindible para el éxito de nuestro proyecto en Internet. Por este motivo la mayoría de los webmasters han optado por la promoción basada en SEO para poder llegar a su público objetivo.

Con el paso de los años (incluso meses) las técnicas de optimización en buscadores se actualizan por lo que hay que estar atentos y en constante evolución ante los cambios del algoritmo de Google.

Recientemente la empresa donde alojo ACS (podeis ver su banner al pie del blog) ha lanzado un VPS específico para el SEO basado en WordPress.

¿Y por qué han elegido WordPress?

WordPress es uno de los mejores sistemas de gestión de contenido cuando se trata de SEO, teniendo en cuenta que casi una cuarta parte de las webs de internet están hechas con este CMS tantos webmasters no han podido equivocarse!.

Ahora al grano, lo que proponen con este VPS SEO es poder levantar en pocos minutos hasta 4 hosting WordPress cada uno con una dirección IP clase C propia (IPs españolas).

WordPress es un software muy bien optimizado y permite que cada página sea indexada rapidamente por los buscadores, por este motivo es muy sencillo crear un blog, añadir buen contenido y enlazar a nuestras webs para mejorar sus rankings.

04 de febrero de 2016

Puente Johnson de noche

Puente Johnson Puente Johnson de noche. Victoria, British Columbia, Canadá.

01 de febrero de 2016

Web Engines Hackfest according to me

And once again, in December we celebrated the hackfest. This year happened between Dec 7-9 at the Igalia premises and the scope was much broader than WebKitGTK+, that’s why it was renamed as Web Engines Hackfest. We wanted to gather people working on all open source web engines and we succeeded as we had people working on WebKit, Chromium/Blink and Servo.

The edition before this I was working with Youenn Fablet (from Canon) on the Streams API implementation in WebKit and we spent our time on the same thing again. We have to say that things are much more mature now. During the hackfest we spent our time in fixing the JavaScriptCore built-ins inside WebCore and we advanced on the automatic importation of the specification web platform tests, which are based on our prior test implementation. Since now they are managed there, it does not make sense to maintain them inside WebKit too, we just import them. I must say that our implementation is fairly complete since we support the current version of the spec and have almost all tests passing, including ReadableStream, WritableStream and the built-in strategy classes. What is missing now is making Streams work together with other APIs, such as Media Source Extensions, Fetch or XMLHttpRequest.

There were some talks during the hackfest and we did not want to be less, so we had our own about Streams. You can enjoy it here:

You can see all hackfest talks in this YouTube playlist. The ones I liked most were the ones by Michael Catanzaro about HTTP security, which is always interesting given the current clumsy political movements against cryptography and the one by Dominik Röttsches about font rendering. It is really amazing what a browser has to do just to get some letters painted on the screen (and look good).

As usual, the environment was amazing and we had a great time, including the traditional Street Fighter‘s match, where Gustavo found a worthy challenger in Changseok 🙂

Of course, I would like to thank Collabora and Igalia for sponsoring the event!

And by the way, quite shortly after that, I became a WebKit reviewer!