Librebits - jordila_@i-ching:~/

Bits aleatorios de Software Libre / Libre Software ...

De Desarrollo Drupal Colaborativo, Git, PaaS .. Y Otros

En los inicios de mis desarrollos con Drupal CMS , mi flujo de trabajo (Workflow) era bien rudimentario. Se basaba en, de forma iterativa, ir ensayando las diferentes funcionalidades requeridas, generando así múltiples maquetas que se iban acumulando en mi disco duro.

El hecho de que Drupal tiene el defecto de no hacer una distinción práctica de código, configuración y datos (estos últimos comparten la base de datos) complica más las cosas. La buena noticia es que esto parece cambiar con la nueva versión 8, que sería liberada en unos meses.

Todo ello resultaba en un galimatías monumental, en el que, por no mezclar configuraciones…acaba teniendo decenas de maquetas, en las que se contenía UNA funcionalidad específica… Para colmo, a veces las distintas funcionalidades acaban implentadas en módulos con versiones que difieren entre las maquetas.

Decidido a poner fin a semejante disparate: conocí el módulo Features , que te permite encapsular una determinada funcionalidad… en otro módulo. De ahí te lo puedes llevar en el bolsillo a donde quieras, reutilizarlo… y más. Por otro lado, ya venía practicando las bondades de un sistema de versionado como Git (en el que se fundamenta el desarrolla el Linux Kernel ). A reorganizar la forma de trabajo se ha dicho. En fin, para lo específico a Drupal, os dejo sin más con el revelador video de Ramón Vilar, que un encuentro-charla reveló los entresijos y la arquitectura del workflow de un potente equipo de desarrollo Drupal como el suyo. Imprescindible.

Por otro lado, ya puestos, podemos investigar un poco sobre algunas herramientas en la tan cacareada nube que también van en esa misma línea, facilitar la tarea al desarrollador(¿ a qué precio?). Vaya por delante, que pienso que el abuso del concepto Cloud creo que nos retrotrae a la época medieval de Internet : en la que grandes supercomputadoras (en lo general en manos de bancos y alguna universidad) abastecen de servicios a terminales tontos (ligeros) remotos. La verticalidad autoritaria, en detrimento de la horizontalidad autogestiva avanza. ¿Es esa la red de redes que queremos? Pero, en fin, eso da para un debate en sí… (Atención acá al punto de vista de RMS sobre los peligros en particular de SaaS en relación a las libertades del software) . Con las precauciones necesarias… veamos que se esconde tras las nubes_ cibernéticas.

Pantheon

Volviendo a lo que nos ocupa, comentar que la comunidad Drupal ha sabido dotarse de una herramienta como Pantheon, adaptada las necesidades de workflow Drupal. En esencia facilita el control de versiones de código y base datos; desarrollándose en tres escenarios ( test , dev y live ).

Estoy haciendo algunas pruebas… Parece prometedor . Lo único que me inquieta es que, por ahora, no se ha licenciado como software libre, siendo una caja negra .

OpenShift

Esto último no ocurre con la plataforma OpenShift de Red Hat. La verdad es que impresiona la potencia de la orquestación de todos una gama de servicios puestos a disposición del desarrollador, con un interfaz Web sencillo y elegante a la vez. Hasta puedes instalar en local un paquete de herramientas para gestionar todo ello desde tu línea de comandos (CLI).

Cubre las principales herramientas y frameworks de desarrollo actuales.Por ejemplo, instalar una nuevas instancia Drupal, gestionable con Git en unos pocos clicks… obteniendo gratuitamente tu dominio

1
http://miDrupal-rhcloud.com

… además, actualmente permite disponer de 3 instancias de aplicaciones cloud libre y gratuitamente, además de las opciones premium de pago. Parece que se están orientado claramente a la comunidad… con su canal chat IRC , etc…

[ Aunque suene paradójico… ¿Bienvenidos al Cloud computing libre ? ]

No termina acá. Si quieres, y puedes puedes instalar y gestionar tu RHCloud en tus propios servidores de software libre . El software está disponible en Github.com .

Gandi.net

Ah! … y sin darme cuenta, más allá de los acrónimos, vengo usando otra plataforma PaaS… donde alojo mis proyectos últimamente.Gandi.net. Hasta ahora me ha dado más satisfacciones que problemas de servicio en el servidor privado virtual (VPS) que tengo contratado. Me gustan especialmente varios aspectos de este tradicional proveedor Hosting :

  • disponen de canal propio IRC para soporte… (me encanta recibir Soporte chat amigablemente )

  • usan Debian GNU/Linux: dan apoyo y financiación al proyecto como tal…así como a Wikimedia (Wikipedia)

… con un poco de paciencia, y con la línea de comandos, tú también puedes crearte tu propia plataforma de servicios.

Bonus : atención en el futuro a tecnologías como LXC , y servicios relacionados como Docker me dicen en Gandi

Drupal Drush : Instalar Una Instancia Con Una Línea De Comando

… convengamos que el proceso de instalación de una instancia Drupal es tedioso. Hay que crear la base de datos, descargar e instalar código, configurarlo…etc.

La potencia de drush nos facilita el proceso enormemente.

1
2
3
$ drush dl drupal --drupal-project-rename=example
$ cd example
$ drush site-install standard --db-url=mysql://[db_user]:[db_pass]@localhost/[db_name] --site-name=Example

Listo.

Lo bueno, si breve, dos veces bueno

Fuente:‘Quick install for developers’

BONUS : agregando

1
... --account-name=admin --account-pass=[contraseña]

a la línea de comandos anterior dejamos configurado admin / contraseña para el acceso .

Git : Diff Y Deshacer Cambios Recientes Fácilmente

De forma sencilla puedo visualizar de forma coloreada, los últimos cambios introducidos, línea por línea… (atención a los signos + y – qye las preceden)

1
$ git diff

En la práctica. Pongamos que modifico el epígrafe/‘caption’ de una de las imágenes…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
jordi@i-ching:~/Git/www.p-i_a$ emacs -nw carousel-blueimp.html //introduzco los cambios desde Emacs
jordi@i-ching:~/Git/www.p-i_a$ git diff
diff --git a/carousel-blueimp.html b/carousel-blueimp.html
index 29ec038..d10e219 100644
--- a/carousel-blueimp.html
+++ b/carousel-blueimp.html
@@ -117,7 +117,7 @@
             </div>
           </div>
           <div class="item">
-            <img src="img/El Campo de Hielo Sur desde el Marconi_1200x800px.JPG" alt="El Campo de Hielo Sur desde el Marconi" />
+            <img src="img/El Campo de Hielo Sur desde el Marconi_1200x800px.JPG" alt="El Campo de Hielo Sur desde el Marconi. Vista Aérea" 
             <div class="carousel-caption">
                 <p>El Campo de Hielo Sur desde el Marconi</p>
             </div>
(END)

Y luego, por lo que sea, quiero volver a la versión anterior al cambio. La forma más sencilla :

1
$git checkout -- carousel-blueimp.php

NOTA : la opción — indica la permanencia en la rama (‘branch’) actual de trabajo.

Si lo que ocurre es que ya había posicionado el fichero en cuestión en el área de ‘stage’ (el limbo git) tras un commit … y todo y con eso quiero deshacer los últimos cambios realizados : que no cunda el pánico!

Secuencia anterior con ‘staging’ .

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
jordi@i-ching:~/Git/www.p-i_a$ emacs -nw carousel-blueimp.html //introduzco los cambios desde Emacs
jordi@i-ching:~/Git/www.p-i_a$ git diff
diff --git a/carousel-blueimp.html b/carousel-blueimp.html
index 29ec038..d10e219 100644
--- a/carousel-blueimp.html
+++ b/carousel-blueimp.html
@@ -117,7 +117,7 @@
             </div>
           </div>
           <div class="item">
-            <img src="img/El Campo de Hielo Sur desde el Marconi_1200x800px.JPG" alt="El Campo de Hielo Sur desde el Marconi" />
+            <img src="img/El Campo de Hielo Sur desde el Marconi_1200x800px.JPG" alt="El Campo de Hielo Sur desde el Marconi. Vista Aérea" 
             <div class="carousel-caption">
                 <p>El Campo de Hielo Sur desde el Marconi</p>
             </div>
(END)

jordi@i-ching:~/Git/www.p-i_a$ git commit -am carousel-blueimp.html "introduzco los cambios en el área 'staging'"

jordi@i-ching:~/Git/www.p-i_a$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

Si leemos atentamente, cosa que no suele ocurrir con frecuencia en la línea de comandos, nos percataremos de que Git se anticipa a la siguiente acción :

  • para extraer el fichero modificado del área de ‘staging’, usar _git reset

Se puede desandar lo andado faćilmente, como nos indican :

1
jordi@i-ching:~/Git/www.p-i_a$ git reset HEAD -- carousel-blueimp.html 

Voilà! Volvimos a la situación anterior: recordemos que los cambios desaparecieron del área ‘staging’ de Git, pero siguen presentes en el área de trabajo. Si queremos deshacer por completo el cambio, volviendo el fichero a su estado original: no tenemos más que ejecutar la operativa mencionada al principio de este post.

KISS ‘Keep-It-Simple-Stupid’

Video: A Vueltas Con El Estado Del Arte en HTML5 - Formatos …

Recientemente estoy haciendo unas pruebas con nuestro propio servidor de video en Internet… Comparto algunas reflexiones acá.

Previa

Tras barajar varias opciones

  • Drupal 7 CMS
  • MediaGoblin ( tu ‘Twitter + Instagram + Youtube’ auspiciado por la Free Software Foundation, muy atractivo )

la facilidad que proporciona HTML5 para el manejo de video me hace decantar por el concepto KISS ( Hazlo Sencillo Éstupido !)

Estas son mis conclusiones (nunca definitivas), en cuanto a como degustar la sopa de letras de formatos habidos y por haber :

Video HTML5: Estado del Arte

Los códecs comprendidos por HTML5, y de futuro son, por este orden

  • WebM (formato abierto ‘open’,apoyado por Google) , lo cual es definitivo
  • OGV (format libre), de hecho, emparentado técnicamente con el anterior. Mi preferido .
  • MP4 – H.264 , apoyado por Apple, a respetar por cuestiones históricas

Hay que tener en cuenta que ninguno de ellos es soportado por la mayoría de los principales navegadores web en todos los casos (Firefox, Opera, Chrome… y el decadente y propietario IExplorer de WinBugs)

Creo que estos son los formatos a tener en cuenta EN adelante, preferiblemente WebM, que es la ‘inversión’ técnica pragmática. Habrá que promover OGV como estándar alineado con la filosofía del software libre : por motivos obvios… ( y sí “Evil” Google un día le da por apropiarse y cerrar el tan cacareado WebM ? Mmmhh… :–/ )

Así pues, después de investigar un poco, y (re)aprender la potencia (una vez más) de GNU/Linux desde la línea de comandos, en este caso para procesos de transcodificación de formatos video. Por no aburrir… bla,bla…los detalles acá.

Balbuceos de nuestro Video Streaming

Los archivos de video originales que vamos a transmitir, de divulgación de la maravillos riqueza natural de la Patagonia, están codificados en formato .MOV 720p (via Apple, codec H.264), es decir en HD (alta definición). Hemos transcodificado a los (más arriba) mencionados formatos. Las apreciaciones y diferencias en cuanto a calidad son muy sutiles… y subjetivas. Pero en lo objetivo y práctico, podemos deducir.En cualquiera de los tres formatos, en cuanto al tamaño del (‘frame’ – marco) del v

  • 720p : ofrece la mejor experiencia de visionado, Exige un potente hardware (actualizado) en el que correr el navegador web y buena velocidad de conexión (estable y superior a 1Mbps, de forma óptima)

  • 480p : ofrece menos calidad,pero responde a un abanico más amplio de dispositivo receptor, prestaciones y ancho de banda. Más ‘universal’

  • parece que entorno 360p sería el más adecuado para Smartphones y/o conexiones lentas… si bien no he podido probar mucho aún.

NOTA: hay que tener en cuanta que, por ejemplo 720p hace realmente referencia a 1280p x 720p (HD). 640 x 480p (VGA) etc…

Feliz transcodificación y streaming

Beso

KISS –Keep It Simple Stupid !

Git: Un Sencillo Flujo De Trabajo (Workflow) II

Hace un tiempo, compartíamos un sencillo flujo de trabajo Git, para pequeños proyectos. Bien retomando el hilo…

Parecía que ya empezamos a manejar el sistema de control de versiones Git , en sus tres comandos básicos…

1
2
3
4
5
$ git  add .
  
$ git commit -m "blabla"

$ git push  ...

y ahora empezamos a tratar de ordenar un poco nuestra forma de desarrollo con git

Es fundamental, para sacar el máximo provecho a Git organizar el flujo de trabajo (‘workflow’), adaptándolo a nuestras necesidades.

  • mediante el uso ramas (‘branch’)

  • desarrollando estructura de árbol de desarrollo simple y flexible a la vez

  • uso de Tags o etiquetas para versionado…

  • … y mucho más

En mi caso, decía, es bien sencillo, uso dos ramas :

  • master // que contiene el código ‘estable’ , se actualiza con menos frecuencia

  • developement // código en desarrollo, actualizándola con mayor frecuencia

y eventualmente una tercera :

  • myfeature // que deriva de developement, donde transcurre el (micro)desarrollo

que aparece y desaparece… según la necesidad. La borro con frecuencia de una vez, tras hacer merge a ‘developement’. Veamos :

  • terminé el microdesarrollo en la rama myfeature actual y lo incorporo ( merge ) a master

  • la idea-microdesarrollo resultó que no era acertada… , marchá atrás.

Este simple paso de deshacer lo andado … nos facilita saltar con red y una libertad absoluta en las ideas a desarrollar. Sabemos que en el rama developement de vuelta, por muchos ensayos y errores que cometamos, nos espera el último estado del código funcionando exactamente como lo dejamos. Siempre y cuando respetemos el flujo de trabajo. Obviamente.

Así pues, por ejemplo, quiero desarrollar la cabecera (Header de mi página web). Partiendo de la rama master actual, recién iniciado el repositorio Git.

1
2
3
4
\\inicio el repositorio , con la rama master por defecto
$ git init
\\creo la rama developement -b , a la cual cambio : 'checkout'
$ git checkout -b developement

…en este punto, decido aventurarme a crear una cabecera de página más innovadora , pero no quiero perder lo hecho hasta ahora. Ello transcurrirá en una nueva rama, derivada de la desarrollo :

1
2
\\creo la rama que deriva de la de _developement_ _-b_ , a la cual cambio : _checkout_
$ git checkout -b micabecera

Acá realizó, con red todas la pruebas que quiera ! Una vez satisfecho con los resultados, si decido fundirlos con mi estado actual de desarrollo, tan sencillo como :

1
2
3
4
5
6
7
8
\\de vuelta a la rama 'developement' , a la cual cambio con  'checkout'
$ git checkout developement
\\ 'merge' sin fast-forward:  'fundo' los cambios hechos en la rama 'micabecera' de la que provengo, conservando el 'histórico'
$ git merge --no-ff micabecera
\\ elimino la rama que acabo de fundir en la rama 'developement', pues ya no la necesito más...
$ git branch -d micabecera
\\ en caso de tener configurado el repositorio remoto, en Github por ejemplo
$ git push origin developement

Así hemos incorporado los cambios que realizamos en micabecera a la rama de desarrollo. En local y en remoto.

En un futuro post hablaremos de incluir la rama master en el proceso, y de una forma sencilla de publicar mediante ella el desarrollo actual en nuestro servidor web.

KISS : Keep-it-simple-stupid

Fuentes :

Thanks nvie y DrupalCamp ES

Bonus:

// para hacer ‘push’ de todo el árbol (y sus ramas) de trabajo, sin distinción

1
$ git push --all -u

en un workflow sencillo como este,y así no hay que precuparse de concretar la rama, ni de saber en la que estamos, bla…

GNU: ‘Como Escoger Una Licencia Para Tu Propia Obra ?’ V2

Traducción para el Proyecto GNU

original : https://gnu.org/licenses/license-recommendations.html

Como escoger una licencia para tu propia obra?

El Free Software Foundation’s Licensing and Compliance Lab. mantiene esta página. Puedes dar apoyo a nuestro esfuerzo mediante una donación a la FSF. ¿Quedó acá alguna pregunta si responder al respecto? Comprueba algunos de nuestros recursos sobre licencias o contacta al Compliance Lab en licensing@fsf.org

Introducción

A menudo nos preguntan que licencia recomendamos para usar en un determinado proyecto. Hemos escrito públicamente sobre esta cuestión con anterioridad, pero la información está diseminada en varios documentos, FAQ y comentarios sobre licencias. Este artículo recolecta toda esa información en única fuente, para simplicar el acceso a ella y facilitar su referenciado a la comunidad. Estas recomendaciones se orientan a obras diseñadas para la realización de tareas prácticas. Incluyendo software, documentación y más. Obras artísticas, o que promuevan un punto de vista son cuestiones de diferente ámbito; el Proyecto GNU no tiente una postura general de como deberían publicarse más allá de que deberían ser todas utilizables sin software que no sea libre (particularmente libre de DRM). Sin embargo, puede resultar útil seguir estas recomendaciones para obras artísticas que acompañen a un determinado programa.

Las recomendaciones aplican a la licenciamiento de una obra creada por tí—tanto si es una modificación de una obra existente, o una nueva obra original. No cubren el caso en que se combina material existente bajo diferentes licencias. Si buscas ayuda en este aspecto, por favor consulta nuestra GPL FAQ. Después de ver nuestras recomendaciones, si quieres asesoramiento, puedes escribir a licensing@gnu.org. Resaltar que probablemente tome varias semanas la respuesta por parte del equipo de licenciamiento; si en un mes no recibiste respuesta, por favor, escríbenos de nuevo.

Contribuyendo a un nuevo proyecto Al contribuir a un proyecto existente, deberías habitualmente publicar las modificaciones realizadas bajo la misma licencia que la obra original. Es positivo cooperar con los que mantienen el proyecto, y usar una licencia diferente para tus modificaciones a menudo convierte la cooperación en algo muy dificultoso. Deberías hacer eso únicamente por motivos de fuerza mayor. Un caso en el que puede justificarse el uso de una licencia diferente es cuando realizas cambios en una obra que no es copyleft. Si la versión creada es considerablemente más útil que la original, entonces merece la pena hacer tu obra copyleft. Si te encuentras en esta situación, por favor sigue las recomendaciones más abajo para el licenciamiento de un nuevo proyecto. Si eliges licenciar tus contribuciones bajo una licencia diferente, por el motivo que sea, debes comprobar antes que la licencia original permite el uso de material bajo tu licencia de elección. Para minimizar el posible impacto en otros, muestra explicitamente que partes de la obra están bajo que licencia.

Software

Recomendamos diferentes licencias para diferentes proyectos, dependiendo principalmente en el propósito del software. Generalmente, recomendamos usar la licencia más restrictiva que no interfiera con dicho propósito. Nuestro ensayo “Qué es el copyleft?” explica el concepto de copyleft en más detalle, y porque es de forma general la mejor estrategia de publicación. Hay sólo un par de tipos de proyectos en los que pensamos sería mejor no usar copyleft de ningún tipo. El primero es en proyectos muy pequeños. Usamos 300 líneas como umbral: cuando el código fuente es menor que esto, los beneficios generados por el copyleft son usualmente inapreciables para justificar la inconveniencia de asegurarse de que una copia de la licencia siempre acompañe al software. El segundo caso es en proyectos que implementan estándares que están en confrontación con estándares propietarios, como Ogg Vorbis (que compite con el audio MP3) y WebM (que compite frente a video MPEG-4). Para estos proyectos, extender el uso del código es vital para avanzar en la causa del software libre, y en si mismo hace mucho más que el copyleft del código del proyecto pudiera hacer. En estas situaciones especiales en las que el copyleft es inapropiado, recomendamos usar la Apache License 2.0 . Está es una licencia software no copyleft que incluye términos para prevenir denuncias de infracción de patentes por parte de distribuidores y contribuyentes. Ello no inmuniza al software de las amenazas de las patentes, pero impide que los que ostentan las patentes establezcan la dinámica de publicar ese software en términos libres para luego requerir a los receptores un acuerdo en términos no libres en una licencia de patente (licencia laxa,“bait and switch”).

En todos los otros casos, recomendamos alguna forma de copyleft. Si tu proyecto es una librería, y los desarrolladores ya están usando un librería alternativa establecida publicada bajo una licencia no libre o una licencia laxa como la mencionada anteriormente, entonces recomendamos usar la GNU Lesser General Public License (LGPL). Al contrario que en el caso discutido anteriormente, en el que el proyecto implementa un estándar, acá la adopción por si misma no alcanza ningún objetivo particular, por lo que no hay motivo para evitar el copyleft por completo, Sin embargo, si requieres a los desarrolladores que usan tu librería para publicar su obra bajo una licencia enteramente copyleft, simplemente usarán una de las alternativas disponibles, y ello no permitirá avanzar tampoco en nuestra causa. La Lesser GPL fue diseñada para cubrir el término medio entre ambos casos, permitiendo a los desarrolladores de software propietario usar la librería cubierta, pero proporcionando cierto beneficio copyleft que revierta en los usuarios en su caso. Para saber más sobre el razonamiento subyacente en estos casos, lee “ “Why you shouldn’t use the Lesser GPL for your next library” Si tu proyecto pudiera ser ejecutado en un servidor después de haber sido mejorado por otros, interactuando con sus usuarios a través de una red, y te preocupa que se reduzca el número de desarrolladores contribuyendo a las versiones publicadas como resultado, recomendamos la GNU Affero General Public License (AGPL). Los términos de la AGPL son prácticamente idénticos a los de la GPL; la única diferencia sustancial es que se agrega una condición extra para asegurar que aquellos que usen el software en red tendrán la facilidad de obtener su código fuente. Esta condición no resuelve todos los problemas que pueden derivar cuando los usuarios realizan su computación en un servidor—no evitará que los usuarios se vean afectados por el Software como Servicio—por cumple con todo aquello que puede cumplir una licencia. Para saber más sobre estas cuestiones, lee “Why the Affero GPL”. En cualquier otro caso, recomendamos que uses la versión más reciente de la GNU General Public License (GPL) para tu proyecto. Su restrictivo copyleft es apropiado para cualquier tipo de software, incluyendo numerosas protecciones para la libertad de los usuarios.

Documentación

Recomendamos la GNU Free Documentation License (GFDL) para tutoriales, manuales de referencia y otros complejas obras de documentación. Es una restrictiva licencia copyleft para obras educativas, inicialmente escritas como manuales de software, incluyendo términos que espefícamente resuelven cuestiones típicas que derivan de la distribución y modificación de estas obras. En pocas palabras, en obras de documentación derivadas, como tarjetas de referencia, es mejor el uso de una licencia GNU permisiva, ya que la copua de GFDL difícilmente podría abarcar una tarjeta de referencia. No uses CC-BY, puesto que es incompatible con la GFDL. Para páginas de manual, recomendamos la GFDL si la página es larga, y la licencia GNU permisiva si es una página corta. Cierta documentación incluye código fuente. Por ejemplo, un manual para un lenguaje de programación podría incluir ejemplos para seguir por parte de los lectores. Deberías incluir estos en el manual bajo términos FDL, y publicarlos bajo otra licencia apropiada para el software. Al hacerlo, se facilita el uso del código en otros proyectos. Recomendamos que dediques pequeñas piezas de software al dominio público usando CC0, y distribuir piezas más amplias bajo la misma licencia que usa el proyecto software asociado.

Otros datos para programas

Esta sección trata el resto de obras para uso práctico que pudieras incluir con el software. Para darte algunos ejemplos, ello incluiría iconos y otros gráficos, fuentes, y datos geográficos funcionales o útiles. También se podría aplicar a artes, a pesar de que no se criticaría el hecho de no hacerlo. Si estás creando estas obras específicamente para usar en un proyecto software, generalmente recomendamos que publiques tu obra bajo la misma licencia que el software. No hay problema ninguno en hacerlo con las licencias recomendadas : GPLv3, LGLPv3, AGPLv3, y GPLv2 pueden ser aplicadas a cualquier tipo de obra—no únicamente software—susceptible de copyright y que denote claramente la predisposición a la modificación. Al usar la misma licencia que el software facilitará el cumplimiento por parte de los distribuidores, y evita cualquier duda sobre potenciales cuestiones de compatibilidad. El uso de una licencia libre diferente podría ser apropiado si provee de algún beneficio práctico específico, como una mejor cooperación con otros proyectos libres. Si tu obra no se crea para el uso en un proyecto software específico, o si pudiera ser inapropiado usar la misma licencia que el proyecto, entonces únicamente recomendamos la elección de una licencia copyleft apropiada para tu obra. Algunas de ellas se muestran en nuestra lista de licencias. Si ninguna licencia parece especialmente apropiada, la licencia Creative Commons Atribution-ShareAlike es una licencia copyleft que puede ser usada para una variedad de obras.

#license:CC-by-nd-3.0

Debian GNU/Linux: Reflexiones en Cuanto a (Re)instalación Y Mantenimiento…

Recientemente incurrí en un garrafal error en mi Debian GNU/Linux … que me llevó a ‘pisar’ con otros archivos, ni más ni menos que el directorio raíz : sí, sí… / .

En fin, de todo se aprende… como via rapida de solución decidí optar por hacer backup y reinstalar la partición de sistema. Estoy en el curso de un desarrollo que no puede demorar… Acá van mis reflexiones tras casi dos día de vaivenes en mis sistemas. Vaya, en mis herramientas de trabajo.

Nunca hagas en el sistema nada crítico en un estado anímico/físico bajo…

Un amigo una vez me comentó en una ocasión…

– Nunca discutas con tu pareja bajo situación de cansancio, falta de sueño….El resultado puede ser explosivo!

Efectivamente, con el tiempo uno aprende que es mejor una retirada que una victoria pírrica en esos instantes. Nuestro estado en ese momento no puede más que derivar en un círculo vicioso de irritabilidad, que nos llevá a una mayor irascibilidad, que nos llevá a los gritos… y vuelta a empezar.

En síntesis, eso me ocurrió ayer… no con mi pareja, sino con mi compañera de trabajo : mi computadora. [me ahorro los detalles]

El caso es que en 48h fui capaza de tumbar yo solito las 2 computadoras que usamos en casa… Voilà!

Operación Ave Fénix

Tras los momentos de desesperación… es importante revertir la situación. Recuperar el estado de ánimo es crucial para ser capaz de levantar los sistemas en la mayor brevedad de tiempo. Y sobre todo, dejar de autoinculparse. Eso nos meterría en otro circulo vicioso. Resiliencia es la palabra.

En adelante, más que dar los detalles, simplemente haré un par de consideraciones que a mí me sirvieron para que el proceso fuera lo más ágil y menos traumático posible.

  • crucial: tener copia de las credenciales de seguridad / encriptación : llaves SSH y GPG . Lo contrario es jugar con fuego. Digo una obviedad…
  • el hecho de tener diferenciadas las partciones de sistema y datos (pongamos / y home … hay quén añade otras… /var ) ayudó mucho, como se verá …
  • lo anterior me permitió que, sin necesidad de backup en el momento, al reinstalar el sistema de nuevo en /, y re-ubicando /home en el lugar correspondiente, avisando al instalador ( mantener datos, no borrar), las aplicaciones volvieran a funcionar como antes sin esfuerzo.

La explicación del último punto: para volver a sentirse uno de nuevo como en su “ciber-casa” cuanto antes es que por ejemplo el navegador Firefox guarda los parámetros particulares en una carpeta oculta , precedida con un . como corresponde a su condiciçon oculta :

1
jordi@i-ching:~/.mozilla$ 

y así sucesivamente la mayoría de las aplicaciones. Ello permite que, tras la reinstalación, se retomen por parte de la aplicación determinada su correspondiente carpeta de parámetros del usuario en esa apliación particular (en este caso marcadores, plugins, etc… )

Para acabar, sistemas operativos como Arch Linux o su alternativa Parábola Linux-Libre usan una filosofía que difiere de la de Ubuntu o su padre, Debian . En vez de publicar releases cada determinado tiempo (LTS, etc…), basta con actualizar regularmente los paquetes… y rara vez vas a tener necesidad de re-instalar por completo el sistema. Siempre y cuando no seas tan bruto y torpe a la vez, como conté al principio… !

KISS : Keep It Simple

Bonus : en mis sistema aproveché la ocasión para volver al entorno de escritorio (desktop) Xfce… tras un tiempo con Lxde. Si bien este último es el más liviano que nunca he probado, por un inapreciable mayor consumo de capacidad del procesador tienes un entorno mucho más versátil. Con el tiempo se ha convertido en mi preferido. … Que le pregunten a Linus Torvalds .

Git: Comparar Cambios Con Diff

¿cómo veo el detalle de los últimos cambios introducidos, de forma comparativa?

… gracias al comando diff , de la familia Unix, aplicado a Git .

Veamos la secuencia de cambios, en el fichero primero.txt , en el que acabo de añadir la línea de texto ‘ viene antes que los otros ’ :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
jordi@i-ching:~/Git/test$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified:   primero.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
jordi@i-ching:~/Git/test$ git diff
diff --git a/primero.txt b/primero.txt
index b5e2b8f..49e8234 100644
--- a/primero.txt
+++ b/primero.txt
@@ -1,3 +1,5 @@
 hola
 
 este es primero
+viene antes que los otros
+

Si en cambio uso el comando con el parámetro …

1
jordi@i-ching:~/Git/test$ git diff --staged

… me mostraría las diferencias en los archivos en los que se hizo commit . Es decir, a los que se les aplicó el comando git add

Como habrás visto, git status nos da el ‘estado de situación’, avisándonos de cambios en el flujo de trabajo git , y proponiendo los siguientes pasos…

Bonus : si usas la opción colorear

1
$ git diff --color-words 

…podrás tener una visualización de los cambios más inmediata y atractiva. Prueba :–)

KISS : Keep It Simple

GNU/Linux: A Vueltas Con El Espacio en Disco, Y Su Liberación

Mmhhh…

¿qué cuanto espacio en disco me queda?

1
2
3
$ df

$ df -h

Salida de ejemplo

1
2
3
4
5
6
7
8
9
10
jordi@i-ching:~$ df -h
Filesystem                                              Size  Used Avail Use% Mounted on
rootfs                                                  8.9G  8.2G  193M  98% /
udev                                                     10M     0   10M   0% /dev
tmpfs                                                   201M  900K  200M   1% /run
/dev/disk/by-uuid/1e7fdf9f-7123-43f4-8ec9-32c4b19057c5  8.9G  8.2G  193M  98% /
tmpfs                                                   5.0M     0  5.0M   0% /run/lock
tmpfs                                                   811M     0  811M   0% /run/shm
/dev/sda5                                                12G   11G  543M  96% /home
/dev/sda3                                                88G   80G  4.0G  96% /media/DATA

:–/ estoy agotando el espacio en la partición de sistema…(!)

1
2
3
4
5
6
7
8
9
$ sudo apt-get autoclean

$ sudo apt-get clean

// comandos que eliminan paquetes sin usar o en caché..., con varios matices

$ sudo apt-get autoremove

// eliminando  paquetes de dependencias que quedaron sin usar

Ecología : el espacio en disco duro es un bien escaso…

Bonus: más elaborada es la eliminación de paquetes huérfanos en caso de Debian mediante deborphan y un script

Git: Sacando Partido Al Archivo Log

Mmmh…¿qué es lo que diablos hice?¿como llegué a esta situación?

Veamos… para hacer una autopsia de lo sucedido, el archivo log es tu amigo. Más allá veremos la potencia de de git en sinergia con GNU/Linux , gracias al comando de este último para buscar expresiones en archivos ( grep )

1
2
3
$ git log

//muestra el archivo log de los _commits_ realizados, en sentido cronológico...

¿Y si quiero ser más concreto en mi búsqueda en el log ?

1
2
3
$ git log -n 4

//muestra la información relativa a los 4 (n) últimos _commits_

¿y si lo que quiero es buscar commits relacionados con la expresión ‘index.php’

1
$ git log --grep="index.php"

sencillo y elegante a la vez.

KISS : Keep it simple