Átomos y Bits en redes sociales
|
Por Leonard, publicado el 02.02.12. ¡Buenas tardes, queridos lectores!
Hoy, para darles un toque polícromo a vuestras vidas, os traemos un tema muy amplio, curioso, y que observamos a diario sin darnos cuenta de ello muchas veces: el maravilloso mundo del color.
Hay que decir que este tema surge a raíz de mi última adquisición tecnológica, un monitor Samsung LED de 27 pulgadas (concretamente el modelo S27A550H, cuya información podéis encontrar en este enlace). Buscaba un monitor grande, no de gama alta, pero lo suficientemente bueno para poder jugar en condiciones a mis amados videojuegos. Partiendo de la base de que no soy ningún entendido en la materia, sí que he querido realizar una correcta configuración del color de mi pantalla para obtener los mejores resultados posibles y, así, he aprendido un poco más sobre todo lo relativo al color. Por tanto lo que aquí os presentamos es sólo un resumen en el que comentaré una serie de términos muy utilizados cuando trabajamos con colores, que conviene que conozcáis si queréis comprender mejor aspectos más avanzados del tema. Os recomiendo que, para obtener una información más profunda y detallada sobre el tema, visitéis el blog dZoom, del que hemos sacado la mayor parte de información para realizar este artículo.
Así, para empezar, si os encontráis en mi situación y queréis configurar correctamente vuestra pantalla, lo primero que tendréis que aprender es qué es la calibración de color, y qué es perfilar el color. El motivo de toda esta complejidad a la hora de “simplemente mostrar imágenes por pantalla” es que los monitores no pueden ofrecer toda la gama de colores que nuestro ojo puede ver, sino que sus posibilidades están acotadas a un determinado espacio de color fruto de su propia tecnología. Lo que nosotros entendemos por rojo, verde, azul y blanco, no es entendido del mismo modo por todos los monitores. Cada uno tiene su propia respuesta, con sus matices particulares, por lo que si queremos asegurarnos de que estamos viendo (por ejemplo) una fotografía con los mismos colores con que el fotógrafo la captó en su día y decidió guardarla, tendremos que preparar nuestro monitor para ello.
 Ejemplo típico de pantalla de calibración Por tanto, para comenzar a tener buenos resultados, nuestra primera misión será calibrar el monitor. Esto es, ajustar correctamente la luminancia del blanco (su intensidad), el tono del blanco (su temperatura, que trataremos más adelante), el nivel del negro (su profundidad) y la compensación gamma (una curva que trata de neutralizar el efecto del monitor compensando algunos factores, también la trataremos con más detalle posteriormente). Una vez calibrados los valores, podremos comenzar a perfilar el monitor, o sea, configurar la gama de colores que mostrará el monitor, y cómo compondrá dichos colores a partir de los básicos. Al proceso de calibrado y perfilado se le conoce como ajuste del monitor, y es lo que os desglosamos en los siguientes párrafos, mediante la definición de sus principales factores.
Como comentamos, el monitor no puede trabajar con todos los posibles colores existentes en la naturaleza, al igual que nuestro ojo no puede apreciar todas las posibles longitudes de onda de la luz (no podemos ver en ultravioleta e infrarrojos, sólo en el llamado espectro visible). Su abanico de posibilidades está limitado a un conjunto más o menos extenso de colores, conocido como espacio de color, que no es más que una región de un mapa de color… ¿queda más claro así? No hasta que expliquemos qué es un mapa de color, pero no os preocupéis, porque este extraño término hace referencia simplemente a una representación gráfica en forma de ejes en la que podemos ubicar todos los colores (en teoría), y definir un color a través de sus coordenadas en los citados ejes. El mapa de color más conocido es el CIE XYZ (que cumple algunas características curiosas, como que el color blanco se encuentra en las coordenadas 0.333, 0.333, o que los colores complementarios están unidos por una línea imaginaria que atraviesa el blanco). Pues bien, si de este mapa de color nos quedamos con una región específica, estaremos trabajando con un espacio de color. Los espacios de color pueden ser dependientes del dispositivo (o sea, son los que el monitor o impresora o escáner o chisme en general puede manejar, interpretar, ofrecer…) o independientes del dispositivo (que son los estándares fijados por la industria de una u otra forma, para poder tomarlos como referencia a la hora de caracterizar dispositivos). Los espacios de color independientes más conocidos son el sRGB, el Adobe RGB y el ProPhoto RGB (RGB deriva de las iniciales de red, green y blue, o rojo, verde y azul en inglés). Los espacios de color dependientes del dispositivo son los que configuran su gama de colores posibles, y se les suele conocer como “gamut”. Normalmente el espacio de color dependiente se suele expresar como un porcentaje de un espacio de color independiente, por ejemplo podemos decir que un monitor cuyo espacio de color represente el 95% del espacio Adobe RGB es un monitor de gama alta, y bastante caro (en torno a los 1.000 €). Si conocemos el espacio de color que utiliza nuestro monitor, podremos conocer los colores primarios (rojo, verde y azul) que maneja, que vendrán dados por su tono, brillo y saturación, cambiando de una pantalla a otra.
 Espacios de color Conocidos los posibles colores que puede representar nuestra pantalla, ¿cómo le indicamos qué color es cual? O sea, necesitamos saber qué valor enviar al monitor para que pinte el color del mapa que ocupe las coordenadas X, Y que queramos (que no tiene por qué ser lo que observaremos por pantalla, ya que eso vendrá a su vez afectado por otros factores que veremos, sino que simplemente es lo que nos gustaría que el monitor entienda que queremos que muestre). Pues bien, para ello se suelen usar los perfiles de color, que son ficheros .icc o .icm con información para describir la respuesta de color de un dispositivo, traduciendo para un programa los valores que él entiende a los valores que entiende el monitor.
Otro factor (nombrado anteriormente) con el que jugamos a la hora de establecer los colores lo más cercanos a la realidad posible con nuestro monitor (o con nuestra cámara de fotos) es la temperatura de color. Esta característica nos sirve para definir correctamente el blanco, o lo que nuestro dispositivo debe interpretar como blanco, y se mide en grados Kelvin, como si de una temperatura se tratase. Su importancia radica en que, a lo largo del día, la luz que observamos va cambiando. Determinadas tonalidades del espectro de luz predominan sobre las demás, tiñendo los rayos a su alrededor y afectando a la imagen percibida. Esta alteración se traduce en un desplazamiento en el espectro de color hacia el rojo o hacia el azul. La luz perfecta diurna se sitúa en 5.500 K, y su valor va cambiando según las condiciones atmosféricas, la hora del día, o dependiendo de la existencia de otras fuentes de luz.
 Temperatura color Las cámaras de fotos digitales suelen incorporar una función llamada “balance de blancos”, que compensa la forma en que la cámara capta la luz, ajustando los niveles de los colores básicos para obtener resultados lo más parecidos al original posibles. El funcionamiento de las cámaras permite seleccionar unas condiciones predefinidas (día nublado, luz de bombilla, fluorescente, soleado, etc.), o bien utilizar un modo de balance automático, que suele ser menos preciso que los modos predefinidos. Dicho modo automático funciona tomando como blanco la zona más brillante de la imagen, y como negro la zona más oscura, de forma que calibra el resto de colores en función a esos valores, tratando de compensar los efectos indeseados de la iluminación. También podemos realizar un balance manual de blancos, sin más que enfocar con nuestra cámara a un objeto de color blanco como un folio, de forma que lo que para nosotros (porque sabemos que es blanco) será un objeto blanco, lo será también para la cámara, con lo que el resto de colores se parecerán más a lo que deberían ser si no existiesen efectos de iluminación añadidos. Hay otros métodos que muchos aficionados a la fotografía utilizan para realizar un balance de blancos manual, como el Expodisc (un accesorio para la cámara fotográfica que puede resultar algo caro si sólo estamos iniciándonos) o la cartulina de tonos de grises. Pero también hay otros métodos caseros más rudimentarios y que a menudo dan buen resultado, como utilizar una tapa de un bote de Pringles de las antiguas (que eran menos transparentes que las de hoy en día), o bien un filtro de café. Si enfocamos a través de estos objetos, la lente recibirá una información lumínica que le permitirá compensar correctamente los diferentes colores, para que después al realizar la fotografía sin el objeto delante podamos obtener resultados de mayor calidad.
 Diferentes balances de blancos para distintas temperaturas Continuando con los parámetros más importantes a tratar, y sin que el orden tenga que ver con su importancia, hablaremos sobre la gamma, que ya hemos nombrado anteriormente. La gamma es un factor de compensación que forma parte de una ecuación cuya curva trata de neutralizar la respuesta no lineal que el monitor introduce a la imagen que queremos mostrar en él, en lo que a luminosidad se refiere. Y es que en las pantallas la luminosidad no depende linealmente del voltaje, sino que sirve una curva exponencial. Ello hace que cuando queremos mostrar un valor de luminosidad media por pantalla, no tengamos que enviar un voltaje medio a la misma, sino más alto. De no corregir este comportamiento, tendríamos que las imágenes que observamos son más oscuras de lo que en realidad deberían ser. Al contrarrestar este comportamiento con la curva de compensación gamma, logramos una relación más lineal entre la entrada y la salida. Los fabricantes incorporan su propia curva gamma a los dispositivos, cuya ecuación exponencial puede resumirse como:
Luminosidad=voltajeG
con un valor G=2.2 habitualmente. Hay quien dice que no debería ser necesario utilizar compensación con los nuevos monitores con conexiones digitales, ya que la información permanece incorrupta desde el ordenador a la pantalla, pero lo cierto es que ajustar el gamma puede producir muy diferentes efectos en lo que observamos, y de hecho suele usarse a menudo en juegos para conseguir una ambientación adecuada al género del que se trate. La compensación de la gamma suele dejar el valor final (o sea, el resultante de la gamma original del monitor y la gamma de corrección) en aproximadamente G=1.14, pero esto no siempre es así, ya que para una determinada entrada, la salida no siempre puede definirse linealmente (y no hablamos ya sólo de luminosidad, sino de todos los factores que afectan a cómo se ve un pixel en pantalla). La respuesta del monitor presenta irregularidades que hacen que sea necesario aplicar una nueva curva de corrección para obtener una graduación más fina de los colores. A esta curva se le denomina curva de ajuste, y su información se almacena bien en una tabla LUT (Look-Up Table) en la tarjeta gráfica o bien en el monitor (si dispone de LUT). La tabla LUT presenta una serie de equivalencias entre los valores que se desean mostrar y los que hay que enviar al monitor para que los muestre. Cuantos más bits tenga la tabla LUT, más precisión permitirá mostrar en los resultados (no es raro encontrar tablas de 8 ó 10 bits).
 Cuadro correspondencias de Gamma. El cuadro que mejor se confunda con el fondo nos da una aproximación del gamma de nuestro monitor. Siguiendo la línea de lo comentado hasta ahora a la hora de realizar la calibración del monitor, hay otros dos aspectos que requerirán nuestra atención: el ajuste del punto blanco y el ajuste del punto negro. Para comprenderlos, debemos definir algunos términos:
- Por una parte, hay que conocer qué es la luminosidad o luminancia del blanco. Se mide en cd/m2 (donde cd es la abreviatura de candelas), y nos informa de la intensidad que toma el monitor para representar el color blanco. Nos interesará que sea un valor lo más bajo posible (en monitores de buena calidad, estará entre 60 y 90 cd/m2, y en pantallas de portátiles de calidad puede superar 115 cd/m2).
- Por otra parte, también aquí influye la temperatura de color. Normalmente resulta que para obtener un blanco lo más neutro posible, tendremos que elegir temperaturas tirando a frías. Se suele utilizar a menudo el valor de 6.500 K para obtener buenos resultados.
- Además, también es muy importante la luminosidad del negro, que se mide en las mismas unidades que la del blanco, y que de nuevo nos interesa que sea el menor valor posible (menores de 0’5 cd/m2 si es posible). Esta magnitud cambia enormemente dependiendo de la tecnología con que esté hecho nuestro monitor (CRT, TFT, LED…).
Asociado a estos conceptos de luminosidad, está el archiconocido contraste. El contraste se define como la relación entre la luminosidad del blanco y la del negro. Nos interesa un monitor que tenga un gran contraste, pero no a costa de conseguir una gran luminosidad del blanco (que puede llegar a dañor nuestros ojos tras un uso prolongado), sino gracias a tener negros muy poco luminosos y blancos lo suficientemente bajos para obtener buenos resultados. Volviendo al ejemplo del monitor que he adquirido, presenta un brillo según sus especificaciones de 300 cd/m2, lo cual le deja totalmente fuera de la gama de monitores profesionales, porque utiliza demasiada luminosidad del blanco para obtener una buena relación de contraste.
Merece la pena comentar que, más allá de usar nuestro “ojo clínico” para tratar de encontrar los mejores valores de los parámetros que hemos comentado hasta ahora, hay una serie de ayudas técnicas y determinados dispositivos que facilitan esta tarea (y que sin duda tendremos que usar si queremos lograr resultados cuasi-profesionales, por ejemplo si nos dedicamos a la fotografía). Se trata de los colorímetros, que son herramientas capaces de identificar el color y el matiz para realizar mediciones objetivas de los mismos y así poder configurar nuestro monitor de manera óptima. Normalmente consisten en un pequeño dispositivo (del tamaño del ratón) que se sitúa pegado a la pantalla para captar el color que ésta emite, y en ocasiones también cuentan con una especie de chasis que se coloca en torno al monitor para aislarlo lumínicamente del entorno. Así, realizando diferentes pruebas, el colorímetro y su software asociado pueden saber, para un determinado estímulo, qué salida está ofreciendo el monitor, de forma que caracteriza con gran precisión sus parámetros. Sería algo así como: “Dime lo que muestras cuando te digo que muestres esto, y te diré cómo eres”.
 Colorimetro Si calibramos y perfilamos nuestro monitor, identificamos su espacio de color, conseguimos un perfil de color adecuado para el programa que estemos usando, ajustamos correctamente su temperatura de color, configuramos adecuadamente su gamma, su curva de ajuste, su punto blanco y su punto negro, ajustamos su luminosidad y su contraste (quizá con la ayuda de un colorímetro), y trabajamos con imágenes con un balance de blancos adecuado, podremos disfrutar de una imagen que no podrá compararse con las que nos ofrecen las pantallas que no han pasado por este proceso. Puede resultar complicado, largo o engorroso, pero en realidad cuando nos familiarizamos con estos conceptos veremos que todo está relacionado, y que un poco de tiempo invertido en dichos ajustes nos proporcionará una experiencia de usuario mucho más rica y, lo más importante, ¡nos permitirá poder ver Átomos y Bits en todo su esplendor! :)
¡Hasta pronto!
Por Leonard, publicado el 08.11.11. ¡Buenas tardes, estimados lectores!
Es probable que entre vosotros (dada la temática de nuestro blog) se encuentren lectores a los que les gustaría programar aplicaciones iOS para iPhone, iPod o iPad que tengan hecho el Jailbreak. Si es así, en este post os ofreceremos las ideas básicas para que sepáis al menos por dónde empezar, y qué podéis esperar encontraros.
Si decidís embarcaros en este complicado viaje, hay varias nociones que sería interesante que conozcáis antes de comenzar con el desarrollo de aplicaciones de este tipo. En primer lugar, es altamente recomendable tener algunas nociones básicas de los lenguajes C / Objective-C. Además, conviene tener un ordenador con MacOS (si bien no es imprescindible) con la versión del SDK (el kit de desarrollo) para la que queramos programar, y si queremos usarlo, necesitaremos tener Xcode instalado. Con estos elementos y algunos manuales, podemos empezar a intentar programar algo con sentido. El problema es precisamente que existen pocos repositorios de información donde vayamos a poder encontrar ayuda sobre el tema.
Para aquellos con menos conocimientos sobre el tema, Xcode es el programa proporcionado por Apple para desarrollar aplicaciones para iOS. Este software nos ofrece un entorno de programación “amigable”, muy gráfico, y con multitud de ayudas visuales que facilitan la edición del código. También incluye el Interface Builder (que hasta la versión 4 de Xcode era un programa aparte, pero ahora ambos elementos están integrados en una sola interfaz) que permite, gráficamente, diseñar el aspecto de nuestra aplicación mediante vistas, botones, sliders, menús de selección, textos, etc. El hecho de contar con Interface Builder nos ahorrara muchas horas de trabajo, más cuanto más vistosa sea nuestra interfaz de usuario. Si queremos desarrollar aplicaciones para AppStore, tendremos que usar Xcode y necesitaremos un Mac, o bien podremos instalar una máquina virtual de Mac en nuestro PC mediante herramientas como VMWare o utilizar otros métodos más peregrinos (como el hackintosh). Si tenéis un ordenador medianamente potente, la opción de la máquina virtual suele funcionar bien. El problema es que a menudo la máquina se queda congelada si no la usáis durante unos minutos (es decir, si cambiáis al sistema operativo anfitrión, Windows por ejemplo, al volver a la máquina virtual pasados unos minutos es probable que encontréis que no responde). Si esto ocurre, basta con reiniciar la máquina virtual, aunque perderéis todo el trabajo que no tengáis guardado.
 Pantalla de Xcode Si somos curiosos, es probable que nos preguntemos por qué surge la necesidad de utilizar otras técnicas diferentes para desarrollar aplicaciones para iOS con jailbreak. ¿Por qué no pueden ser todas aplicaciones normales como las que encontramos en AppStore? Pues bien, la respuesta se encuentra en la propia filosofía de Apple: para la compañía de la manzana, lo principal y más importante, el motivo vital de toda su obra, es la optimización de la experiencia de usuario. Esto quiere decir que no nos van a permitir programar aplicaciones de cualquier tipo, sino que “limitan” sus funcionalidades evitando ciertos comportamientos que pudieran hacer empeorar la experiencia de uso, o comprometer en cualquier aspecto la integridad de los datos, la privacidad del usuario, información delicada del terminal, etc. Bien, aclarado esto, ¿cómo decide Apple qué aplicaciones pueden ser aptas para el App Store y cuáles no? Comprobando qué API‘s y qué métodos utiliza: hay determinadas clases que son privadas y otras son públicas. E incluso dentro de las públicas, hay determinados métodos que son privados. Cuando Apple detecta que estamos utilizando alguno de éstos métodos, rechaza nuestra aplicación y no nos permite subirla a AppStore.
En este punto, si queremos distribuir nuestra aplicación tendremos que buscar mercados alternativos para ella, como puede ser Cydia. Ahora bien, ¿cómo podemos acceder a métodos y clases privados de Apple, si no los conocemos? Mediante una técnica que se conoce como “dump“. Esta idea consiste en volcar los frameworks que tenemos embebidos en nuestro SDK de forma que podamos entrar a ellos y navegar para estudiar sus clases, sus controladores, qué parámetros recogen y qué parámetros pasan, etc. Para profundizar en este tema, recomendamos que leáis el artículo Dump Public and Private iOS Frameworks de Conor Burgess. En él, se explica cómo utilizar un script que el propio Conor ha desarrollado, y que con ayuda de la herramienta class-dump nos permite tener accesible todos los frameworks del SDK. Además necesitaremos otros dos ficheros (substrate.h y libsubstrate.dylib) que el script utiliza para el parcheo de los frameworks. Una vez seguidos los pasos que el script de volcado requiere (simplemente un par de líneas de comandos), todos los archivos de cabeceras para el SDK habrán quedado volcados, parcheados y unidos. Es importante señalar que esto no interferirá en absoluto con el correcto funcionamiento de nuestro Xcode, aclaración imporante en el supuesto de que queramos desarrollar posteriormente otras aplicaciones válidas para AppStore, en cuyo caso no tendremos ningún problema.
De acuerdo, en este punto ya tenemos disponibles todos los métodos, incluidos aquellos que Apple no quiere que veamos. Ahora, el siguiente paso lógico será comenzar a desarrollar nuestra aplicación. Ésta evidentemente es la parte más complicada, no sólo porque tendremos que pelearnos con el código, sino porque para muchas de las cosas que querremos hacer, no podremos utilizar Xcode e Interface Builder de la manera clásica. En su lugar, necesitaremos otro “entorno de desarrollo”, más adaptado a aplicaciones para jailbreak: el conocido Theos y Logos. Una vez instalado Theos, ejecutaremos el NIC (New Instance Creator), que nos preguntará qué tipo de programa queremos comenzar a desarrollar: podremos elegir entre una aplicación, una librería, un grupo de preferencias, una herramienta o un tweak.
 Pantalla de Theos Después de seleccionar el tipo de programa, y tras asignarle un nombre, un autor, etc., obtendremos todas las plantillas necesarias creadas sobre las que podremos comenzar a programar. A modo de referencia y para que os sirva de ejemplo, programas como LockInfo, Activator, SBSettings, etc., son todos librerías dinámicas (dylib), en vez de aplicaciones como tal. Por su parte, Logos nos ayudará cuando compilemos nuestro desarrollo, al convertir la sintaxis simple de Theos en el complejo lenguaje de Mobile Substrate, del que hablaremos a continuación.
Para finalizar esta mini-guía, es imperativo comentar brevemente una de las características fundamentales en las aplicaciones para terminales con jailbreak: la inyección de código. Una vez que tenemos nuestros frameworks disponibles, nuestro Theos instalado, y creada nuestra plantilla sobre la que trabajar, necesitaremos de alguna forma (y sobre todo si estamos programando alguna librería dinámica o algún tweak) poder interferir en la ejecución normal del código de Apple en el dispositivo. Para ello, tendremos que conocer el funcionamiento de Mobile Substrate. Esta capa es un componente requerido por multitud de programas (como SBSettings, Winterboard, Five Icon Dock…) , y fue desarrollada por Saurik. Su forma de actuar es montar librerías cuando carga el Springboard, de forma que pueda inyectar su código en las aplicaciones que lo ejecutan. Esto es lo que se conoce como “hook“, o sea, situar anzuelos en el código en los que nosotros podremos insertar el nuestro propio para engancharlo. Por otra parte, Mobile Substrate nos protege de posibles cuelgues del terminal, poniéndolo en una especie de modo “a prueba de fallos” en caso de que haya algún error en el Springboard.
Resumiendo, como veis, el proceso para comenzar a desarrollar aplicaciones de este tipo requiere una cierta preparación, unas buenas dosis de paciencia y una visión general del proceso que estamos siguiendo. A pesar de que no hay mucha información (especialmente en castellano) al respecto, en el servidor de IRC irc.saurik.com, canal #theos, podréis recibir más ayuda especializada y concreta para cada aspecto en particular. Lo que aquí os presentamos son sólo unos primeros pasos, que esperamos os resulten útiles para saber dónde podéis buscar más información, y qué información podéis buscar.
Si alguno de vosotros se anima, y esta breve introducción le ayuda a desarrollar alguna aplicación, hacédnoslo saber. ¡Estaremos encantados de hablar de ella en Átomos y Bits! 
Por Sheldon, publicado el 17.10.11. Buenas de nuevo amigos,
Hoy quisiera hablaros de Eureka, y no me refiero a la mítica frase atribuida al matemático griego Arquímedes, del que ya hemos hablado en otra ocasión. En realidad me refiero a la serie de Syfy (personalmente prefería Sci-Fi) con el mismo nombre.
Antes de comenzar me gustaría aclarar que aunque la idea básica de la serie me parece curiosa y entretenida, la realidad es que, desde el punto de vista científico, los argumentos que en ella se dan no son más que una sarta de barbaridades y patadas a la ciencia que sólo podrían tener lugar en un universo paralelo ideado para guionistas perezosos que buscan soluciones fáciles. A su lado, la serie Fringe (que también me gusta bastante) parece ciencia empírica.
 Eureka A pesar de ello la veo, sí lo sé, no me juzguéis. Recordad que una serie científicamente incoherente no tiene por qué ser sinónimo de aburrida, aunque la verdad es que creo que darle un marco de realidad sólo podría mejorarla. Es el eterno debate, la ciencia-ficción por definición incluye cosas que no son reales (sino ficción) pero no debemos olvidarnos de la ciencia, señores. Sin un marco de referencia adecuado el contexto de la historia se pierde. En las series, por lo general y si nadie nos dice lo contrario, damos por hecho que la naturaleza es la misma que en nuestro universo y por lo tanto las leyes físicas son las mismas. Para justificar la parte de ficción se pueden utilizar varios métodos, incluyendo tomarse ciertas licencias que dejan colgando con pinzas algunos argumentos. Pero, como en todas las cosas, debe saberse dónde poner los límites. Desde mi punto de vista, tanto mejor será el argumento cuanto mejor se represente la realidad y más ingeniosa sea la “excusa” para explicar la ficción.
Pero bueno, no era en este punto dónde quería centrar el artículo que nos ocupa, que puede ser algo controvertido, centrémonos.
Recientemente he visto el capítulo 7 de la 3 temporada en el que una niña prodigio (como todos en Eureka) de 9 años, y para un trabajo del instituto, crea un segundo sol en el cielo sobre la ciudad (a unos 300 metros de altura, si no recuerdo mal). A lo largo del capítulo se dicen bastantes barbaridades relacionadas con este tema y otras que no lo están directamente. Voy a intentar ver algunas de ellas, aunque espero que eso no haga este artículo demasiado extenso.
Podría hablar de lo que ellos llaman “radiación variogénica” (¿mande?), o de la “hidratación por nanotecnología”, o de “esculpir nubes hidrogénicamente”, o incluso de que, a pesar de que tienen la más alta tecnología jamás concebida, incluyendo hologramas, tan sólo disponen de las simples y actuales (ya casi anticuadas hasta para nosotros) ecografías en 2D. Sin embargo, me voy a intentar centrar en el tema del sol, que ya sabéis que es un tema que me gusta bastante (ya hemos hablado de las estrellas en algún artículo anterior, hablando de la miniserie Impact).
En el capítulo se comenta que el nuevo sol tiene las propiedades de una estrella enana principal y no se sabe cuál es su fuente de energía. Mmm… A ver, a ver… Las estrellas enanas sí que existen, aunque el tema del tamaño es bastante relativo (tan tan pequeña nunca podría llegar a formarse), pero eso de “principal” imagino que hace referencia a que es una estrella perteneciente a la denominada “secuencia principal”, que es una región del diagrama de Hertzsprung-Russell. Éste es una catalogación de las estrellas en función de su magnitud absoluta y su temperatura superficial, y la secuencia principal representa la región de este diagrama en la que se encuentran la mayor parte de las estrellas. Esto también debería darnos bastantes más datos, pues las estrellas más pequeñas de la secuencia principal son las de tipo espectral M5, que tienen una masa de 0,12 veces la de nuestro sol y una temperatura de 3.200 K. Es decir, que para que fuese una de ellas debería tener un radio de 83.500 km, con lo que nos engulliría y abrasaría, claro. Pero bueno, también puede ser que ese “principal” se refiera a otra cosa que no se me haya ocurrido.
 Diagrama de Hertzsprung-Russell También se dice de la estrella que no se sabe cuál es su fuente de alimentación. En fin, una estrella no es como una tostadora que puedes enchufar a tu antojo. Una estrella no necesita fuente de alimentación pues, por definición, si ya es una estrella ya se han iniciado los procesos de fusión que generarán su energía. Otra cuestión aparte sería cómo se las ingenió la niña para conseguir que comenzase ese proceso. Pues también hay respuesta para ello, según la propia niña el proceso “es muy sencillo, tan sólo se necesita un generador gravitacional rodeado por plasma reactivo”, lo que quiera que eso signifique. Lo que sucedió para que se les fuera de las manos fue que hubo un error en el cálculo de la densidad del plasma… Ehhh…. (si alguno no lo habéis leído aún y queréis saber qué es eso del plasma, podéis leer un poco más acerca de ello en el artículo agregando estados a los estados agregados de la materia). Vaaale, vaaaale, ya sé que sólo es ficción, así que continuemos.
Tampoco puedo dejar de comentar lo poco exagerados que son los guionistas de la serie cuando en un momento determinado uno de los personajes utiliza un portátil para desbloquear una cerradura (típico), con una capacidad de procesamiento de, nada más y nada menos, que 20 zettahercios. A algunos puede que esto no les diga nada, así que analicémoslo brevemente. Nuestros ordenadores actuales tienen una capacidad de procesamiento de varios gigahercios, y aunque probablemente dentro de algunos años si releo esto me ría de mí mismo, creo que son bastante potentes (aunque en realidad la potencia siempre será relativa a lo que se quiere conseguir). Esos hercios (Hz) nos indican la capacidad de procesamiento de nuestros microprocesadores o, dicho de otra manera, la frecuencia de su reloj. Mi ordenador actual es de 3,5 Ghz, que son 3,5×109 o unos 3.500.000.000 ciclos por segundo. El portátil de nuestro protagonista dispone de 20 Zhz, es decir 20×1021, o lo que es lo mismo 20.000.000.000.000.000.000.000 Hz, apenas nada. No digo que no sea posible, sólo que quizás hayan exagerado un poquito.
Volviendo al tema de la estrella, más adelante vemos como “evoluciona a supergigante”. Según dicen esto provocará una explosión muy grande, “habrá una supernova, una explosión más grande que la de Hiroshima y Eureka se convertirá en un cráter muy grande”. Pues bien, es cierto que uno de los posibles finales de una estrella es una supernova, pero la comparativa de las explosiones quizá no sea la más adecuada.
La bomba atómica lanzada sobre Hiroshima, bautizada como Little Boy, tenía un potencia explosiva de unos 13 kilotones, es decir 5,5×1013 J. La bomba atómica más potente jamás detonada por el hombre, fue la denominada Bomba del Zar, con una potencia de unos 50 Megatones, o lo que es lo mismo, 2,1×1017 J, unas 4.000 veces más potente que Little Boy. La potencia de una supernova dependerá de cada caso, pero se puede hacer una estimación sobre los 1044 J, es decir, 1027 veces más potente que la Bomba del Zar, 1031 veces más potente que Little Boy. Eso es 10 quintillones de veces más potente que la de Hiroshima!!!
Como decía, creo que no han tenido muy en cuenta la escala, pero bueno, también es cierto que tan sólo comentan que sería una explosión mayor que la de Hiroshima, en ningún momento hablan de proporciones ni magnitudes. En realidad no importa el tamaño de la estrella, si realmente pudiera ser posible que se convirtiera en una supernova, no creo que Eureka se convirtiera en un cráter pues dudo mucho que se mantuviera en pie algún trozo de La Tierra sobre el que formar ese cráter.
 Bomba del Zar Cambiando un poco de tema, hablemos sobre cómo pretenden destruir la estrella: “si pudiéramos acercarnos y lanzar un módulo con una concentración de átomos de hierro al núcleo el sol implosionaría”. No se me ocurre ninguna explicación razonable para la relación entre la concentración de átomos de hierro y la destrucción de la estrella, y mucho menos por qué produciría una implosión, pero se me ocurre que no han tenido en cuenta las implicaciones que eso tendría. Una implosión real se consigue detonando explosivos en la superficie de un objeto de manera que la onda expansiva se mueva hacia adentro, comprimiéndolo. Pero esta compresión no es ilimitada, finalmente se alcanza un estado de alta densidad. La estrella no desaparecería, el problema seguiría allí, o aún peor, porque si todo esto fuera posible comprimir en exceso la estrella podría aumentar su densidad hasta formar una singularidad, un agujero negro.
Incluso teniendo en cuenta que toda la masa de la estrella pudiera desaparecer por la implosión, desintegrándose de alguna manera, su equivalente de energía debería distribuirse por la atmósfera en su lugar, por aquello de que la energía no se crea ni se destruye (Principio de conservación de la energía), lo que a su vez originaría graves problemas climáticos y medioambientales.
Y ya, por último, también me gustaría comentar otro pequeño detalle que me llamó la atención. En los minutos finales, estando a punto de convertirse en una supernova, la estrella emite tanto calor que las ruedas del coche en el que se desplazan el sheriff Carter y Zane Donovan se derriten y deben continuar el camino a pie. Bueno, lo primero es que en realidad las estrellas cuando se convierten en gigantes rojas se enfrían, no se calientan más, por lo que esto no sería posible. Y por otra parte, me resulta curioso que los neumáticos de un vehículo se derritiesen en dicha situación. Los neumáticos, al estar formados por distintos compuestos, no tienen un punto de fusión como tal, sino que se considera la temperatura a partir de la cual se vuelve maleable, que está en torno a los 160 o 170 ºC. Me cuesta pensar que se alcanzase dicha temperatura para que se derritieran los neumáticos del coche patrulla, sobre todo porque es lo único que parece estar afectado. Bueno, eso y que las superficies metálicas están calientes (¡pero es que eso ya ocurre en mi terraza durante el verano sin necesidad de un segundo sol!).
En fin, la verdad es que cada capítulo de la serie es un completo desafío a la realidad. Refiriéndonos a Eureka sí que podemos decir sin temor a equivocarnos: “cualquier parecido con la realidad es pura coincidencia”.
Por Leonard, publicado el 27.06.11. Buenos días estimados lectores.
En esta calurosa tarde de verano, os traigo un post que quizá no aporte muchas novedades a algunos de vosotros, pero que probablemente resultará al menos curioso para muchos otros.
A menudo, estamos tan acostumbrados a las tecnologías que utilizamos a diario, que no reparamos en la ingeniería y los avances que subyacen y que nos han permitido poder disfrutar de dichas tecnologías.
El caso concreto del ADSL es muy interesante ya que, por ejemplo, en la carrera de Ingeniería de Telecomunicación puede verse desde multitud de puntos de vista (tantos como especialidades tiene la carrera), esto es, desde la perspectiva de la electrónica base que lo soporta, desde la de las comunicaciones, teoría de la señal, modulaciones, cifrados, compresión, etc, y desde el punto de vista de la telemática que hace uso del enlace ADSL. Por tanto, aunque aquí os contaremos solo las bases del funcionamiento de esta tecnología, podéis profundizar en ella tanto como queráis, porque podría escribirse todo un libro sobre ella (de hecho, se escriben libros sólo sobre ella…). Entremos en materia.
El ADSL debe sus siglas a las palabras Asymmetric Digital Suscriber Line (línea de abonado digital asimétrica, para que nos entendamos). Y su propio nombre ya nos da algunas pistas de su funcionamiento. Se trata de una tecnología de acceso a Internet, que se da sobre los hilos convencionales de cobre que todos tenemos en casa. Estos hilos de cobre, conocidos habitualmente como el “par de cobre“, unen nuestra casa desde el PTR (punto de terminación de red, que sería el punto a partir del cual la instalación deja de depender del operador como tal, o sea, de este punto hacia dentro de nuestra casa, la instalación es cosa nuestra, en teoría) con la central local de nuestra área. Este cable consiste en dos hilos de cobre aislados, trenzados entre sí (para evitar acoplamientos indeseados y no funcionar como una antena, básicamente), muy extendido hace unos años dado su bajo coste, y su buena respuesta en frecuencias entre los 300Hz y 3’4KHz, y por tanto, muy convenientes para la comunicación vocal (humana), cuyo rango de inteligibilidad se encuentra entre frecuencias de 1 KHz a 4 KHz. Posteriormente, como se ha podido ir comprobando, hemos aprovechado dicho par para frecuencias incluso superiores a 1MHz (el cable de cobre debería funcionar bien hasta los 6 MHz aproximadamente).
 Red básica de ADSL (Fuente: http://www.ayuda-internet.net/) Sobre el par de cobre, vamos pues a transmitir información digital mediante señales eléctricas analógicas, y para ello vamos a necesitar un módem (modulador/demodulador). Pero, ¿en qué se diferencia un módem ADSL de los módems de 9600 bps que usábamos hace unos años? Pues fundamentalmente, en que dichos módems trabajaban en la banda de frecuencias vocales, y por tanto la velocidad disponible estaba muy limitada por trabajarse con anchos de banda tan pequeños. Además, conectarse a Internet impedía poder usar simultáneamente la línea para llamar por teléfono, con lo que en casa nos quedábamos incomunicados, o eso decían nuestros padres. El ADSL, por su parte, aplica una modulación en una banda de frecuencia superior a la que utilizan las comunicaciones vocales, reservando además un rango para el enlace ascendente y otro para el descendente, además de dejar libre la zona de frecuencias vocales (si bien para garantizar el mejor funcionamiento posible y las mínimas interferencias, se nos suelen proporcionar microfiltros paso-bajo que conectamos al teléfono para asegurarnos que no interferimos en otros rangos de frecuencia, y viceversa). Los rangos reservados para el enlace ascendente y descendente son diferentes, porque se concibió la red de forma que los usuarios tuvieran mayor capacidad de descarga que de subida de información. De ahí el apellido de asimétrica que tiene nuestra conexión a Internet. A continuación, podéis observar una gráfica del rango de frecuencias que se manejan en el ADSL tradicional:
 Bandas de frecuencia en el ADSL tradicional (Fuente: Wikipedia) En la imagen, en rojo vemos la banda de frecuencias vocales, en verde el canal de subida y en azul el canal de bajada.
Sin embargo, insaciables de nosotros, estos anchos de banda y sus velocidades de transferencias asociadas, pronto se nos quedaron pequeños. Así nació el ADSL2/2+, que duplica el ancho de banda máximo utilizable hasta la frecuencia de 2’2MHz. Esto nos ofrece teóricamente unas velocidades de descarga en torno a 24Mbps, frente a los 8Mbps que nos ofrecía el ADSL normal. Para realizar esta proeza tecnológica (los padres del par de cobre nunca habrían imaginado que podría enviarse tal cantidad de información sobre dicho medio… fijaos si no en Imagenio), el ADSL2+ se sirve de una mayor eficiencia de modulación/codificación (utiliza modulazión de amplitud en cuadratura QAM con constelaciones de 1 bit, y codificación Trellis), además de unos algoritmos de tratamiento de señal mejorados con respecto al ADSL tradicional. Como os comenté en la introducción, el tema del ADSL es todo un mundo, así que os invito a que leáis algunos artículos sobre tratamiento digital de señales, teoría de la señal, codificación y modulación, para conocer un poco más en qué consisten todos estos extraños términos.
Otra mejora introducida desde el ADSL2 fue la posibilidad de cambiar dinámicamente la tasa de transferencia de datos entre el usuario y la central. Esto era un problema en el ADSL 1, ya que la alta diafonía que se registraba en el canal causaba muchos errores de transmisión y limitaba la calidad de la comunicación. ADSL 2 por su parte puede ajustar la velocidad, y reaccionar a la relación señal/ruido que observa en el medio.
En cuanto al funcionamiento en sí del ADSL, debemos saber que nuestro módem ADSL está conectado con un equipo en la central de nuestro proveedor, llamado DSLAM, que consiste en una serie de nodos ATU-C a los que se conectan (nos conectamos) los usuarios. El DSLAM agrega multitud de conexiones y las gestiona, sincronizándose con nuestro módem ADSL, entre otras cosas para establecer una tasa de transferencia adecuada y otros parámetros de la conexión. Además, el DSLAM envía el tráfico de voz a la central de conmutación para su tratamiento. Desde el DSLAM hacía “arriba” en la red, podemos considerar que se sigue una política jerárquica, que va agrupando conexiones de usuarios en enlaces cada vez de mayor capacidad, llegando a grandes enlaces troncales internacionales. Al ser una red de conmutación de paquetes, se obtiene una gran eficiencia, ya que generalmente (al menos ha sido así hasta los últimos años, en los que las descargas de grandes ficheros desde Internet se han hecho más habituales entre los usuarios) el tráfico generado/enviado por/hacia los usuarios tiene un comportamiento de ráfagas, por lo que no es habitual que un usuario esté utilizando la conexión permanentemente, mientras que los paquetes de otros usuarios sí lo hacen; así se comparte el canal más eficientemente (al contrario de lo que ocurre con una llamada telefónica tradicional sobre una red de conmutación de circuitos, en la que cuando marcamos el número de teléfono de otra persona, aunque no hablemos, tenemos reservado el canal hasta que uno de los dos interlocutores finalice la conexión).
 Ejemplo de DSLAM en una central (Fuente: http://dougonipcomm.com/) Pero toda esta tecnología y avance tiene sus inconvenientes. Y es que, aunque el ADSL2 nos permita trabajar con canales de peores características, y aunque intenten minimizarse los errores producidos en la transmisión sin sacrificar en la medida de lo posible velocidad y prestaciones, las conexiones tienen unos límites más allá de los cuáles se hace inviable manejar esas tasas binarias. Para empezar, es necesario que el par de cobre tenga una cierta calidad, tanto en lo que respecta al ruido como a la atenuación debida a la distancia hasta la central. A partir de los 5 kilómetros aproximadamente, ya tendremos un servicio de bastante mala calidad. Y viceversa: entre los 500 metros y 1 kilómetro de la central, obtendremos la máxima velocidad porque la atenuación será prácticamente inexistente. Podéis ver una gráfica resumen a continuación:
 Distancia/Velocidad de las conexiones ADSL (Fuente: http://www.supernerd.com.au/) Bueno, queridos lectores, esto ha sido una brevísima introducción a la tecnología ADSL. De aquí podríamos derivar a hablar sobre TCP/IP , UDP, puertos, LAN’s, backbones y multitud de temas que de una u otra forma están relacionados con el ADSL. ¡Pero tenemos que dejar asuntos para otros días!
Hasta entonces, ¡podéis seguir usando (muchos de vosotros) vuestra conexión ADSL para acceder a páginas tan interesantes como Átomos y Bits!
¡Hasta pronto!
Por Sheldon, publicado el 24.01.11. Hola a todos y bienvenidos de nuevo a Átomos y bits. Parece que estamos en la racha de los scripts, y es que, tras el MataProcesos 1.0 hoy quisiera mostraros otro script, al que he llamado AppInstaller 1.0, que podéis usar todos aquellos que uséis Android (del que ya hemos hablado en una entrada anterior), y que podéis descargar aquí.
No quiero entrar en detalles, pero para aquellos que no lo conozcáis Android es un Sistema Operativo para móviles (en realidad smartphones). En estos móviles podemos instalar infinidad de aplicaciones, por ejemplo desde el Market. Pero claro, todos aquellos a los que nos gusta enredar bastante con nuestros terminales, modificar cosas, probar nuevas configuraciones, nuevas roms… nos encontramos con que el sistema puede volverse inestable y nos toca restaurarlo a sus valores iniciales (lo que comúnmente se denomina hacer un “wipe”). Esto puede resultarnos muy pesado, porque muchas veces el número de aplicaciones que tenemos instaladas es muy elevado y, sobre todo, no queremos perder sus datos ni sus configuraciones. Para ello hay algunas opciones en el Market, como por ejemplo Titanium Backup, una gran aplicación que nos hace copias de seguridad tanto de las aplicaciones como de sus datos.
Sin embargo, puede que a alguno de vosotros os haya pasado, como a mí, que no siempre funciona correctamente. Los backups los crea correctamente, pero a la hora de restaurarlos últimamente no me encuentra ningún backup que restaurar, lo que es curioso, pues he comprobado que las copias se han hecho y están donde deben estar. Me planteé la posibilidad de volver a descargarlas e instalarlas todas una a una, pero enseguida deseché la idea dado su elevado número. Después intenté simplemente instalarlas manualmente, extrayendo las aplicaciones del backup de Titanium Backup, pero tampoco me agradó la idea. Seguía siendo demasiado pesado. Finalmente, como me gusta automatizar cosas, decidí hacer un proceso automático que cogiese todas las aplicaciones de una carpeta concreta definida por mí y las instalase una a una él solito. Además, si en esa misma carpeta hubiese una subcarpeta con el mismo nombre que la aplicación (su configuración y datos) debería restaurarlos también.
También es conveniente saber que Titanium Backup tiene dos versiones, una gratis y otra de pago. Las dos realizan los backups correctamente. La diferencia está a la hora de restaurar las aplicaciones, pues, mientras que en la de pago el proceso es completamente automático, en la versión gratis debemos ir aceptando manualmente una a una todas las aplicaciones a restaurar, y bueno, ya sabemos lo aburrido y cansado que eso puede llegar a ser…
Por todo ello, he tenido esto en cuenta para que AppInstaller 1.0 sea compatible con los backups resultantes de Titanium Backup, o al menos en parte. Hablaremos de ello más tarde. Posiblemente no sea el proceso de backup más completo, pero a mí me funciona perfectamente y me automatiza todo el proceso. Con una ROM limpita, como recién salida de fábrica, lo ejecuto y… Voilà! Vuelvo a tener todas mis aplicaciones y mis datos (Como he hecho esta misma mañana).
Quiero repetir de nuevo, que esto también lo hace Titanium Backup (la versión de pago), y hasta hace un tiempo a mí me funcionaba correctamente, así que puede que a vosotros no os sirva en absoluto. También quiero aclarar que para que este script funcione se necesita hacer uso de las herramientas “adb” del kit de desarrollo de Android (Android SDK), que es la manera en la que el ordenador puede conectarse al móvil y ejecutar comandos sobre su sistema. Si no sabéis como instalarlo, echadle un ojo a la era del androide 2.0.
Es posible que esta no sea la versión definitiva, ya que una vez puestos intenté, además, que el propio script tuviera la capacidad de realizar él mismo los backups. Y en principio, también lo hace (la versión 2.0), pero no funciona bien en algunos casos y debo dedicarle algo más de atención, por lo que sólo publico la parte que realiza la restauración.
El programa consta principalmente de tres partes, un fichero de líneas de comandos (AppInstaller1.0.cmd), un script en Visual Basic Script (..\bin\AppInstaller.vbs) y la carpeta “Apps” donde pondremos las aplicaciones a restaurar. Adicionalmente se crea un fichero de texto (“..\bin\resultados.txt”) en el que se introducen datos auxiliares intermedios. Este fichero se borra automáticamente al finalizar la ejecución del programa.
Para que todo funcione correctamente, en el fichero “..\bin\AppInstaller.vbs” deberemos configurar algunos parámetros.
DIR=”Apps”
SDK=”C:\SDK\platform-tools”
VISIBLE=”NO”
Estos parámetros son:
DIR: es la ruta de la carpeta “Apps” relativa a la carpeta donde se encuentra “AppInstaller1.0.cmd”.
SDK: es la ruta dónde hemos instalado el SDK de Android, en concreto la ruta donde se encuentra el ejecutable “adb.exe”.
VISIBLE: esta opción permite configurar si queremos que se vean o no, los procesos que el programa lleva a cabo en cada caso. Personalmente, recomiendo la opción “NO” , pues en caso contrario se abrirá una ventana por cada proceso de cada aplicación, que, aunque se cerrará también por sí sola, nos impedirá seguir haciendo otras tareas en nuestro ordenador con tranquilidad. En cualquier caso está disponible por si queremos observar con más detalle lo que la aplicación está realizando en cada momento.
Con todo esto, ya podremos ejecutar AppInstaller1.0.cmd. Si lo hacemos veremos la siguiente pantalla:
 Pantalla principal de AppInstaller 1.0 Como podemos observar el funcionamiento es bastante simple. Tan sólo deberemos introducir el número correspondiente a la opción deseada. Con la primera opción tan sólo se intentarán instalar las aplicaciones encontradas en “Apps”. Con la segunda opción tan sólo se intentarán restaurar sus datos. Sobra decir que esta opción es útil únicamente si las aplicaciones estaban instaladas con anterioridad. La tercera opción nos permitirá instalar las aplicaciones a la vez que se restauran sus datos, en el caso de que los tenga.
Es importante destacar que para que todas las aplicaciones de las que se han restaurado datos funcionen correctamente el script necesita restaurar sus permisos necesarios. Para ello se ayuda de un script conocido como “fix_permissions”, que algunos ya conoceréis. En mi caso tengo instalada una rom de Cyanogen (CM 6.1) que lleva incorporado dicho script. Si vuestra rom no lo lleva incluido de serie, supongo que no hay ningún problema en modificar AppInstaller 1.0 para indicarle manualmente dónde se encuentra “fix_permissions” (deberíais incluir dicho script a mano en vuestro terminal).
Al finalizar, el programa nos mostrará un resumen de las acciones realizadas.
 Resumen de las acciones realizadas por AppInstaller 1.0 Por último, dado que se necesitan restaurar los permisos (mediante “fix_permissions”) será necesario reiniciar el terminal. Una vez hecho esto ya dispondremos de nuestras aplicaciones tal y como estaban cuando realizamos el último backup.
Como he dicho anteriormente, mi idea fue hacerlo compatible con Titanium Backup, de manera que se pudieran restaurar cómodamente los backups hechos con esta aplicación. Pero para poder restaurarlos necesitaremos reorganizar un poco estos backups. Veamos cómo.
Lo primero que haremos será copiar en la carpeta Apps de nuestro ordenador el contenido de la carpeta “TitaniumBackup” que encontraremos en la SD de nuestro terminal. A continuación borraremos los ficheros *.properties, que no necesitaremos. Seguidamente seleccionaremos todos los ficheros *.apk.gz (Organizar -> Seleccionar todo) y (con winrar instalado) mediante botón derecho del ratón seleccionaremos “Extraer aquí”.
 Selección de ficheros APK
Por último, y de la misma forma, seleccionaremos todos los ficheros *.tar.gz y mediante botón derecho del ratón seleccionaremos “Extraer cada archivo en carpetas separadas”. De esta manera tendremos, dentro de la carpeta Apps, todos los ficheros *.apk (instaladores de los programas) y una subcarpeta por cada aplicación con su mismo nombre (datos de los programas).
 Selección de los datos de las aplicaciones.
Como último apunte os diré que también es posible utilizarlo para instalar aplicaciones sin que provengan de Titanium Backup, tan sólo necesitamos tener sus correspondientes .apks y seguir el mismo procedimiento (sin tener en cuenta sus datos, por supuesto).
Al comienzo lo utilizaba creando “lotes” de carpetas categorizando por contenido. En concreto, la idea principal era hacer una carpeta de aplicaciones básicas o indispensables que pudiera ejecutar tras hacer wipe. Puede seguir siendo buena idea, tan sólo habría que ir modificando los nombres de las carpetas.
Pues nada, ahí lo tenéis, quizá nadie lo use nunca (yo ya lo he usado unas cuantas veces) pero si puede serle de alguna utilidad a alguien en algún momento habrá merecido la pena publicarlo. Por supuesto está a vuestra libre disposición, podéis descargarlo e incluso modificarlo según vuestros intereses, pero si que me gustaría pediros que siempre nos hagáis referencia, citando al autor original y la web o bien con un enlace para que otros lo puedan descargar desde aquí.
¡Hasta pronto!
|
¿Nos echas una mano? Aceptamos donaciones de cualquier importe a través de PayPal, para ayudar a mantener el dominio y alojamiento de Átomos y Bits.
Suscríbete con FeedBurner
|
Twitter de Leonard
Encuéntranos en Facebook
