Hello everybody out there ...
I'm doing a (free) operating system
(just a hobby, won't be anything big and professional like gnu) ...
it probably will never support anything other than AT-hard disks, as that's all I have ...."
viernes, 8 de abril de 2011
miércoles, 22 de diciembre de 2010
Cerebro
"El cerebro es un órgano maravilloso. Comienza a trabajar apenas nos levantamos y no deja de funcionar hasta entrar en la oficina" (gracias Robert Frost)
domingo, 23 de mayo de 2010
Facebook chat a través de Pidgin
Facebook actualmente tiene soporte para el protocolo XMPP de chat, así que no es necesario agregar plugins ni nada por el estilo en Pidgin para conectarse a ese servicio de mensajería.
Los pasos pueden seguirse desde este link:
http://www.howtogeek.com/howto/12527/easily-add-facebook-chat-to-pidgin/
Tener en cuenta dos cosas:
1) Está en inglés
2) Tuve que deshabilitarle el requerimiento de SSL/TLS (al revés de como indica en los pasos) ya que el servidor responde que no admite cifrado (tener en cuenta por lo tanto que el intercambio de datos es sin cifrar).
Si no se desea seguir los pasos, simplemente basta tener en cuenta que se configura como una cuenta clásica XMPP y que el servidor es chat.facebook.com
Los pasos pueden seguirse desde este link:
http://www.howtogeek.com/howto/12527/easily-add-facebook-chat-to-pidgin/
Tener en cuenta dos cosas:
1) Está en inglés
2) Tuve que deshabilitarle el requerimiento de SSL/TLS (al revés de como indica en los pasos) ya que el servidor responde que no admite cifrado (tener en cuenta por lo tanto que el intercambio de datos es sin cifrar).
Si no se desea seguir los pasos, simplemente basta tener en cuenta que se configura como una cuenta clásica XMPP y que el servidor es chat.facebook.com
miércoles, 30 de diciembre de 2009
Backup
La gestión de backups o copias de seguridad es una actividad a planificarse a medida de la organización que la requiere a fin de obtener el objetivo esperado con el mínimo costo.
Estas son algunas pautas a tener en cuenta:
Seguridad de la información digital.
Cuando se habla de "seguridad de los datos", hay que tener en cuenta que la misma abarca dos aspectos:
* Por un lado, la confidencialidad. Esto es: cuáles son las medidas de seguridad o políticas para asegurar una libre disponibilidad de la información pero sólo a los niveles de recursos humanos indicados. Por ejemplo que ciertos datos no puedan estar disponibles fuera de la organización, o que aún dentro de la organización ciertos recursos estén disponibles sólo para un grupo de personas.
* Por otro lado, la integridad. Esto abarca todas las políticas para evitar pérdida de datos o pérdida de valor de los datos (datos corruptos).
Este documento sólo se ocupa de este último aspecto.
Velando por la integridad de la información digital.
Políticas para asegurar la integridad de la información.
Si las políticas de backup no se planifican formalmente, resultan en una pérdida de tiempo y dinero. A continuación algunos ejemplos:
Casos típicos de informalidades que llevan al fracaso de la política de backup:
. El encargado de sistemas de una organización deja una tarea programada que diariamente copia los datos originales a un repositorio de backup (pc con disco rígido con espacio suficiente para recibir la copia). Esos datos pueden ser: documentos, bases de datos, etc.
. Problemas:
. un empleado quiere un dato que había hace tres días porque le hizo cambios y ahora los quiere volver atrás: pero sólo se tiene una copia del último día.
. Ocurre un robo en el edificio y no sólo que se llevan las computadoras con las copias originales, sino que también se roban la pc con el backup.
. Ocurre un error en un disco y se recurre al backup pero en ese momento se dan cuenta que en el horario de la tarea programada de backup la pc repositoria se encontraba apagada (hace 1 mes que no se deja más prendida esa pc).
. Ocurre un borrado accidental de un documento y se recurre al backup pero hace un mes que la pc repositoria ha cambiado de nombre por lo tanto la tarea programada se ejecuta con errores.
. Se rompe el servidor principal y hay que cambiarlo. Se dispone del backup y se puede hacer una reconstrucción del mismo: comprar un nuevo servidor, instalarle el software de base, las aplicaciones y restaurarle los datos demora al menos 72 horas: pero la organización necesita que dentro de quince minutos esté disponible el servidor nuevamente.
. Se rompe un equipo y hay que restaurar su información. Se recurre al backup y el mismo existe, pero al momento de restaurar la información por alguna razón el backup no puede ser restaurado: el proceso de restauración da errores o algunos documentos no se encuentran en el backup.
. Ocurre un borrado accidental, se recurre al backup pero los datos borrados son de un proyecto nuevo que comenzó luego de haber planificado el backup y por lo tanto el proceso de copia no contemplaba esos nuevos datos.
Pautas a tener en cuenta para evitar lo anterior:
. Normalmente no es suficiente mantener una "foto" de la información al último día. Puede ocurrir que se necesite un dato que estuvo disponible hace diez días. Para eso se debe resguardar el estado de los datos de los últimos n días. Cuanto más días se resguarden, más complejo será el proceso (de backup y de recuperación) pero se dispondrá de más chances de recrear el estado perdido. Afortunadamente para hacer más eficiente ese proceso, minimizando recursos necesarios, desde hace muchos años que hay modelos, procedimientos y herramientas disponibles como por ejemplo los modelos incrementales (ver http://es.wikipedia.org/wiki/Copia_de_seguridad).
. La copia de seguridad debe encontrarse geográficamente distante: si ocurre un fenómeno natural o un robo, probablemente se pierdan tanto los datos originales como los de respaldo (es decir que se deben tener en cuenta los imponderables naturales y sociales además de los técnicos). Debe considerarse un procedimiento que automática o manualmente asegure que los datos se encuentren fuera del edificio en otra área confiable. Pueden ser procesos de copia remota o que una persona responsable reciba recordatorios periódicos para trasladar la información.
. Auditoría!! Las copias de seguridad pueden no encontrarse como se sospecha. Es muy importante que la política incluya un responsable que reciba un recordatorio para que a intevalos regulares busque el backup, lo restaure y se asegure de que ante un imponderable en ese backup se van a poder obtener los datos necesarios sin inconvenientes.
. Tolerancia a fallos / recuperación ante desastres: muchas veces no es suficiente con disponer del backup sino que es necesario asegurar una recuperación en un tiempo máximo. Por ejemplo cuando se trata de un servidor de misión crítica, como puede ser una base de datos para facturación a clientes, habrá que asegurar que si ocurre un desastre con el servidor, en una hora el problema esté resuelto. Para ello se recurre a diferentes modelos:
. la tolerancia a fallos asegura, normalmente con redundancia de recursos, directamente evitar el inconveniente, que el mismo no ocurra (por ejemplo que un equipo cuente con dos fuentes de alimentación, con dos discos rígidos con la misma información, etc).
. la alta recuperación ante desastres normalmente hace uso de servidores idénticos disponibles en todo momento y ante la falla de uno se continúa con el otro que venía siendo impactado con las mismas novedades que el servidor original de manera simultánea.
Planificando la seguridad
En defintiva, con mínimas pautas es posible mejorar notablemente la confiabilidad del backup. En la mayoría de los casos no es necesario invertir más dinero: los recursos para copia de seguridad se encuentran y a menudo en exceso. Lo que normalmente falta es organizar esos recursos para poder aprovechar su utilización de manera eficiente y a largo plazo.
Estas son algunas pautas a tener en cuenta:
Seguridad de la información digital.
Cuando se habla de "seguridad de los datos", hay que tener en cuenta que la misma abarca dos aspectos:
* Por un lado, la confidencialidad. Esto es: cuáles son las medidas de seguridad o políticas para asegurar una libre disponibilidad de la información pero sólo a los niveles de recursos humanos indicados. Por ejemplo que ciertos datos no puedan estar disponibles fuera de la organización, o que aún dentro de la organización ciertos recursos estén disponibles sólo para un grupo de personas.
* Por otro lado, la integridad. Esto abarca todas las políticas para evitar pérdida de datos o pérdida de valor de los datos (datos corruptos).
Este documento sólo se ocupa de este último aspecto.
Velando por la integridad de la información digital.
Políticas para asegurar la integridad de la información.
Si las políticas de backup no se planifican formalmente, resultan en una pérdida de tiempo y dinero. A continuación algunos ejemplos:
Casos típicos de informalidades que llevan al fracaso de la política de backup:
. El encargado de sistemas de una organización deja una tarea programada que diariamente copia los datos originales a un repositorio de backup (pc con disco rígido con espacio suficiente para recibir la copia). Esos datos pueden ser: documentos, bases de datos, etc.
. Problemas:
. un empleado quiere un dato que había hace tres días porque le hizo cambios y ahora los quiere volver atrás: pero sólo se tiene una copia del último día.
. Ocurre un robo en el edificio y no sólo que se llevan las computadoras con las copias originales, sino que también se roban la pc con el backup.
. Ocurre un error en un disco y se recurre al backup pero en ese momento se dan cuenta que en el horario de la tarea programada de backup la pc repositoria se encontraba apagada (hace 1 mes que no se deja más prendida esa pc).
. Ocurre un borrado accidental de un documento y se recurre al backup pero hace un mes que la pc repositoria ha cambiado de nombre por lo tanto la tarea programada se ejecuta con errores.
. Se rompe el servidor principal y hay que cambiarlo. Se dispone del backup y se puede hacer una reconstrucción del mismo: comprar un nuevo servidor, instalarle el software de base, las aplicaciones y restaurarle los datos demora al menos 72 horas: pero la organización necesita que dentro de quince minutos esté disponible el servidor nuevamente.
. Se rompe un equipo y hay que restaurar su información. Se recurre al backup y el mismo existe, pero al momento de restaurar la información por alguna razón el backup no puede ser restaurado: el proceso de restauración da errores o algunos documentos no se encuentran en el backup.
. Ocurre un borrado accidental, se recurre al backup pero los datos borrados son de un proyecto nuevo que comenzó luego de haber planificado el backup y por lo tanto el proceso de copia no contemplaba esos nuevos datos.
Pautas a tener en cuenta para evitar lo anterior:
. Normalmente no es suficiente mantener una "foto" de la información al último día. Puede ocurrir que se necesite un dato que estuvo disponible hace diez días. Para eso se debe resguardar el estado de los datos de los últimos n días. Cuanto más días se resguarden, más complejo será el proceso (de backup y de recuperación) pero se dispondrá de más chances de recrear el estado perdido. Afortunadamente para hacer más eficiente ese proceso, minimizando recursos necesarios, desde hace muchos años que hay modelos, procedimientos y herramientas disponibles como por ejemplo los modelos incrementales (ver http://es.wikipedia.org/wiki/Copia_de_seguridad).
. La copia de seguridad debe encontrarse geográficamente distante: si ocurre un fenómeno natural o un robo, probablemente se pierdan tanto los datos originales como los de respaldo (es decir que se deben tener en cuenta los imponderables naturales y sociales además de los técnicos). Debe considerarse un procedimiento que automática o manualmente asegure que los datos se encuentren fuera del edificio en otra área confiable. Pueden ser procesos de copia remota o que una persona responsable reciba recordatorios periódicos para trasladar la información.
. Auditoría!! Las copias de seguridad pueden no encontrarse como se sospecha. Es muy importante que la política incluya un responsable que reciba un recordatorio para que a intevalos regulares busque el backup, lo restaure y se asegure de que ante un imponderable en ese backup se van a poder obtener los datos necesarios sin inconvenientes.
. Tolerancia a fallos / recuperación ante desastres: muchas veces no es suficiente con disponer del backup sino que es necesario asegurar una recuperación en un tiempo máximo. Por ejemplo cuando se trata de un servidor de misión crítica, como puede ser una base de datos para facturación a clientes, habrá que asegurar que si ocurre un desastre con el servidor, en una hora el problema esté resuelto. Para ello se recurre a diferentes modelos:
. la tolerancia a fallos asegura, normalmente con redundancia de recursos, directamente evitar el inconveniente, que el mismo no ocurra (por ejemplo que un equipo cuente con dos fuentes de alimentación, con dos discos rígidos con la misma información, etc).
. la alta recuperación ante desastres normalmente hace uso de servidores idénticos disponibles en todo momento y ante la falla de uno se continúa con el otro que venía siendo impactado con las mismas novedades que el servidor original de manera simultánea.
Planificando la seguridad
En defintiva, con mínimas pautas es posible mejorar notablemente la confiabilidad del backup. En la mayoría de los casos no es necesario invertir más dinero: los recursos para copia de seguridad se encuentran y a menudo en exceso. Lo que normalmente falta es organizar esos recursos para poder aprovechar su utilización de manera eficiente y a largo plazo.
lunes, 19 de octubre de 2009
NO Cambio de hora en Argentina - Servidores Ubuntu
Gracias: http://www.vivalinux.com.ar/distros/parche-tzdata-argentina
Gracias: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/453165
Gracias Margarita Manterola.
Para ajustar en un servidor Ubuntu la configuración de daylight savings y "acate" :-) la última decisión en Argentina (17/10/09: NO hacer ajuste de hora para ahorro de energía) (me reservo los comentarios sobre "planificación cero").
El siguiente es un script que ajusta la configuración sin necesidad de actualizar paquetes (útil para el caso de una instalación estática de server, homologada como tal y cuyos binarios no pueden ser modificados bajo ningún concepto porque perdería la homologación): (asume caso timezone Buenos Aires)
1) wget http://www.bircherasociados.com.ar/soft/ArgentinaSinCambioHora
2) cp /usr/share/zoneinfo/America/Argentina/Buenos_Aires /usr/share/zoneinfo/America/Argentina/backup_Buenos_Aires
3) cp ArgentinaSinCambioHora /usr/share/zoneinfo/America/Argentina/Buenos_Aires
4) cp ArgentinaSinCambioHora /etc/localtime
Gracias: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/453165
Gracias Margarita Manterola.
Para ajustar en un servidor Ubuntu la configuración de daylight savings y "acate" :-) la última decisión en Argentina (17/10/09: NO hacer ajuste de hora para ahorro de energía) (me reservo los comentarios sobre "planificación cero").
El siguiente es un script que ajusta la configuración sin necesidad de actualizar paquetes (útil para el caso de una instalación estática de server, homologada como tal y cuyos binarios no pueden ser modificados bajo ningún concepto porque perdería la homologación): (asume caso timezone Buenos Aires)
1) wget http://www.bircherasociados.com.ar/soft/ArgentinaSinCambioHora
2) cp /usr/share/zoneinfo/America/Argentina/Buenos_Aires /usr/share/zoneinfo/America/Argentina/backup_Buenos_Aires
3) cp ArgentinaSinCambioHora /usr/share/zoneinfo/America/Argentina/Buenos_Aires
4) cp ArgentinaSinCambioHora /etc/localtime
miércoles, 16 de septiembre de 2009
Software Libre en las Empresas
¿Qué es el software libre?
Un software libre (SL) es una pieza de software cuyo autor lo transfiere para su uso a otra persona, otorgando una licencia que le da a este último la libertad de ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software.
Para más detalles ver por ejemplo: http://es.wikipedia.org/wiki/Software_libre
En inglés, software libre se dice "free software". Lamentablemente, "free" significa tanto "libre" como "gratuito", cuestión que origina una serie de confusiones con respecto a qué es y qué no es el SL.
Respecto a lo anterior, hay que tener bien en claro que el hecho de que se denomine libre, tiene que ver con el concepto de libertad y no con el concepto de gratuidad.
En el sitio de uno de los productos de software libre muy utilizados (GNU: http://www.gnu.org/philosophy/free-sw.es.html) pueden leerse estos detalles sobre el SL:
Los usuarios de programas tienen las cuatro libertades esenciales:
. La libertad de ejecutar el programa para cualquier propósito.
. La libertad de estudiar cómo trabaja el programa y cambiarlo para que haga lo que usted quiera. El acceso al código fuente es una condición necesaria.
. La libertad de redistribuir copias.
. La libertad de mejorar el programa y publicar sus mejoras y versiones modificadas en general, para que se beneficie toda la comunidad. El acceso al código fuente es una condición necesaria.
Más allá de estar de acuerdo o no con estos términos, lo cierto es que existen muchos tipos de licencia que otorgan estas libertades (y también agregan otros términos restrictivos o de más libertades). Los tipos de licencia más conocidos son: BSD (http://es.wikipedia.org/wiki/BSD_license), GPL (http://www.gnu.org/copyleft/gpl.html), Copyleft (http://www.gnu.org/copyleft) y Apache (http://www.apache.org/licenses/LICENSE-2.0)
Virtudes del SL
. Generalmente se utilizan estándares abiertos (imprescindible por ejemplo para que los datos sean propiedad del usuario del sistema y no del desarrollador del sistema). Por ejemplo, si en una empresa los datos están almacenados en un motor de base de datos propietario, con clave, encriptación y accesos no estándar, seguramente que la única manera de acceder a esos datos y a su plano de diseño es a través del desarrollador del software.
. Colaborativo: al hacer disponible una pieza de software a la comunidad, a la vez que alguien puede verse beneficiado por el producto, la misma comunidad puede detectar y generar mejoras, detectar y solucionar problemas, etc.
. Sujeto a auditoría: está permanentemente sujeto a auditorías imparciales, heterogéneas y multidisciplinarias.
. Seguro (no puede haber huecos de seguridad no documentados porque todo está documentado, en última instancia con el código fuente).
Empresas y SL. Derribando mitos
Una manera breve e introductoria para presentar el uso de software libre en empresas es analizando estos diez mitos del SL (con orientación a las Pymes):
1) El SL es gratuito: normalmente falso. Salvo que su autor lo haya otorgado como de dominio público, el SL no es gratuito. Es necesario muchos recursos, incluido dinero, para producirlo, mantenerlo y acompañarlo en todo su ciclo de vida. ¿Quién lo paga entonces? Quizá ciertos principales interesados, quizá algún paradigma comercial no basado en compraventa (inmensa escala de voluntarios aportantes, publicidad, etc).
El modelo de SL también traslada el enfoque económico desde un producto con un origen y con una licencia propietaria hacia un modelo de servicio orientado a la solución de problemas concretos.
La inversión en software que hace una pyme ahora no se paga a una empresa importante, centralizada y alejada de la realidad regional, sino que se paga a consultores regionales que utilizan piezas de SL genérico y la personalizan para cada necesidad (y es más barato).
Que no sea gratuito no impide que eventualmente una organización utilice de manera gratuita una pieza de software. De hecho, hay muchos casos en los que ocurre algo así:
Por ejemplo, sea un SL consistente en un sistema de base de datos. Una empresa multinacional hace un aporte importante de dinero efectivo, permitiendo financiar el proyecto de esa base de datos. El interés de esta empresa es que va a utilizar esa base de datos para integrarla con otros productos o servicios de su propiedad (hacer un sistema de base de datos desde cero de características similares le costaría exponencialmente más).
Como es una característica del SL, ese proyecto es publicado. Desarrolladores de software regionales (independientes, consultores o empleados de pymes) lo toman e instalan (quizá con ningún cambio) en sus clientes. Esos clientes son organizaciones pequeñas (de 1 a 50 empleados) que no pagan nada por ese producto, salvo a los desarrolladores regionales (por la solución completa).
Eventualmente los desarrolladores regionales pueden retroalimentar el proyecto de base de datos que fue publicado reportando su experiencia de uso o instalación, publicando mejoras o informando errores. Este último aspecto hace que en última instancia la empresa grande que hizo el aporte principal se ve beneficiada por muchos voluntarios que aportan a una mejora continua del producto.
2) El SL es amateur: falso. En muchos casos (y en la mayoría para los SL conocidos) hay un equipo profesional y multidisciplinario en el desarrollo y en el ciclo de vida del producto.
3) Se necesita Linux para usar SL: falso. Hay infinidad de piezas de SL independientes del sistema operativo o para plataformas específicas como Windows.
4) No pueden mezclarse en una pyme SL y software propietario: falso. Comenzar a utilizar SL no implica hacer un "salto" (normalmente al vacío :-) ) descartando todo lo que se utiliza hasta ahora y tomando todo software nuevo. Más bien es una decisión que debe tomarse con una planificación a mediano plazo y un plan gradual, incluso con objetivos que pueden no ser el reemplazo total del software existente. Gracias a que el SL siempre se encuentra sometido a estándares, es posible por ejemplo tener varios puestos de trabajo con un procesador de textos propietario y otros puestos con un procesador de textos basado en software libre.
5) Los "peces gordos" de la tecnología no hacen SL, sólo lo hacen comunidades independientes: falso. Actualmente quienes promueven más activamente al SL son las empresas más exitosas en los últimos años en su rubro (como IBM, Google, Sun, etc).
6) El SL no tiene soporte: falso. Sí tiene soporte: se puede contratar mesa de ayuda, soporte con asistencia remota. Se puede estar suscripto a bases de conocimiento o preguntas frecuentes (suscripciones que pueden ser gratuitas para el consumidor).
Hay que comprender que estamos presenciando el nacimiento de un nuevo paradigma en ciclo de vida del software, que no viene a reemplazar otro sino que viene a ocupar otro lugar:
Antes las empresas grandes cobraban su producido en software con licencias. Los usuarios debían adaptar sus procedimientos de trabajo a los dictados por ese software ya que los ciclos de vida con realimentación normalmente no tenían la agilidad esperada. No se está haciendo un juicio de valor sobre esta forma de trabajo. Simplemente se la presenta.
Ahora hay una alternativa: el desarrollo es más personalizado, se orienta más al servicio y a la solución de los problemas concretos. Las grandes empresas crean plataformas, marcos de trabajo (frameworks) o estándares de desarrollo sobre los que los regionales arman la solución.
7) El SL no puede tener un uso comercial: falso. Puede ser utilizado con cualquier propósito, principalmente como asistente a actividades comerciales, productivas, de investigación y entretenimiento. Incluso hay muchísimo SL cuyo ámbito principal de aplicación es el comercial.
8) Freeware y Shareware son lo mismo que SL: falso. Freeware significa gratis, y shareware con período de prueba gratis. SL (free software) es software libre.
9) SL es de menor calidad. falso. Cualquier software (libre o propietario) tiene la calidad que le da su equipo de trabajo y la que certifican los auditores expertos. Todo lo que hay que hacer es buscar la opinión de un grupo especialista en que se confíe: si ese grupo dice que un determinado SL es de la calidad esperada: adelante, a utilizarlo.
Habitualmente quien da la garantía a una pyme sobre un software es el consultor/desarrollador regional que se contrata.
Por ejemplo, si una pyme compra un servidor con sistema operativo Windows Server, la garantía de que va a funcionar correctamente va a estar brindada por el fabricante del software. Si en lugar de eso compra un servidor sin sistema operativo, su responsable de sistemas instalará un sistema operativo SL y será él mismo quien garantizará el correcto funcionamiento.
10) SL es de dominio público: falso. Dominio público pertenece a toda la humanidad, no tiene licencia. En última instancia el software de dominio público puede considerarse una variante dentro del software libre . El SL siempre tiene licencia, la cual hay que conocer y aceptar (y, de tener dificultades para entenderla, buscar soporte en alguien de confianza -personas, grupos, organizaciones- para recibir ayuda a interpretarla).
Los nombres mencionados son marcas registradas de sus respectivos propietarios.
Un software libre (SL) es una pieza de software cuyo autor lo transfiere para su uso a otra persona, otorgando una licencia que le da a este último la libertad de ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software.
Para más detalles ver por ejemplo: http://es.wikipedia.org/wiki/Software_libre
En inglés, software libre se dice "free software". Lamentablemente, "free" significa tanto "libre" como "gratuito", cuestión que origina una serie de confusiones con respecto a qué es y qué no es el SL.
Respecto a lo anterior, hay que tener bien en claro que el hecho de que se denomine libre, tiene que ver con el concepto de libertad y no con el concepto de gratuidad.
En el sitio de uno de los productos de software libre muy utilizados (GNU: http://www.gnu.org/philosophy/free-sw.es.html) pueden leerse estos detalles sobre el SL:
Los usuarios de programas tienen las cuatro libertades esenciales:
. La libertad de ejecutar el programa para cualquier propósito.
. La libertad de estudiar cómo trabaja el programa y cambiarlo para que haga lo que usted quiera. El acceso al código fuente es una condición necesaria.
. La libertad de redistribuir copias.
. La libertad de mejorar el programa y publicar sus mejoras y versiones modificadas en general, para que se beneficie toda la comunidad. El acceso al código fuente es una condición necesaria.
Más allá de estar de acuerdo o no con estos términos, lo cierto es que existen muchos tipos de licencia que otorgan estas libertades (y también agregan otros términos restrictivos o de más libertades). Los tipos de licencia más conocidos son: BSD (http://es.wikipedia.org/wiki/BSD_license), GPL (http://www.gnu.org/copyleft/gpl.html), Copyleft (http://www.gnu.org/copyleft) y Apache (http://www.apache.org/licenses/LICENSE-2.0)
Virtudes del SL
. Generalmente se utilizan estándares abiertos (imprescindible por ejemplo para que los datos sean propiedad del usuario del sistema y no del desarrollador del sistema). Por ejemplo, si en una empresa los datos están almacenados en un motor de base de datos propietario, con clave, encriptación y accesos no estándar, seguramente que la única manera de acceder a esos datos y a su plano de diseño es a través del desarrollador del software.
. Colaborativo: al hacer disponible una pieza de software a la comunidad, a la vez que alguien puede verse beneficiado por el producto, la misma comunidad puede detectar y generar mejoras, detectar y solucionar problemas, etc.
. Sujeto a auditoría: está permanentemente sujeto a auditorías imparciales, heterogéneas y multidisciplinarias.
. Seguro (no puede haber huecos de seguridad no documentados porque todo está documentado, en última instancia con el código fuente).
Empresas y SL. Derribando mitos
Una manera breve e introductoria para presentar el uso de software libre en empresas es analizando estos diez mitos del SL (con orientación a las Pymes):
1) El SL es gratuito: normalmente falso. Salvo que su autor lo haya otorgado como de dominio público, el SL no es gratuito. Es necesario muchos recursos, incluido dinero, para producirlo, mantenerlo y acompañarlo en todo su ciclo de vida. ¿Quién lo paga entonces? Quizá ciertos principales interesados, quizá algún paradigma comercial no basado en compraventa (inmensa escala de voluntarios aportantes, publicidad, etc).
El modelo de SL también traslada el enfoque económico desde un producto con un origen y con una licencia propietaria hacia un modelo de servicio orientado a la solución de problemas concretos.
La inversión en software que hace una pyme ahora no se paga a una empresa importante, centralizada y alejada de la realidad regional, sino que se paga a consultores regionales que utilizan piezas de SL genérico y la personalizan para cada necesidad (y es más barato).
Que no sea gratuito no impide que eventualmente una organización utilice de manera gratuita una pieza de software. De hecho, hay muchos casos en los que ocurre algo así:
Por ejemplo, sea un SL consistente en un sistema de base de datos. Una empresa multinacional hace un aporte importante de dinero efectivo, permitiendo financiar el proyecto de esa base de datos. El interés de esta empresa es que va a utilizar esa base de datos para integrarla con otros productos o servicios de su propiedad (hacer un sistema de base de datos desde cero de características similares le costaría exponencialmente más).
Como es una característica del SL, ese proyecto es publicado. Desarrolladores de software regionales (independientes, consultores o empleados de pymes) lo toman e instalan (quizá con ningún cambio) en sus clientes. Esos clientes son organizaciones pequeñas (de 1 a 50 empleados) que no pagan nada por ese producto, salvo a los desarrolladores regionales (por la solución completa).
Eventualmente los desarrolladores regionales pueden retroalimentar el proyecto de base de datos que fue publicado reportando su experiencia de uso o instalación, publicando mejoras o informando errores. Este último aspecto hace que en última instancia la empresa grande que hizo el aporte principal se ve beneficiada por muchos voluntarios que aportan a una mejora continua del producto.
2) El SL es amateur: falso. En muchos casos (y en la mayoría para los SL conocidos) hay un equipo profesional y multidisciplinario en el desarrollo y en el ciclo de vida del producto.
3) Se necesita Linux para usar SL: falso. Hay infinidad de piezas de SL independientes del sistema operativo o para plataformas específicas como Windows.
4) No pueden mezclarse en una pyme SL y software propietario: falso. Comenzar a utilizar SL no implica hacer un "salto" (normalmente al vacío :-) ) descartando todo lo que se utiliza hasta ahora y tomando todo software nuevo. Más bien es una decisión que debe tomarse con una planificación a mediano plazo y un plan gradual, incluso con objetivos que pueden no ser el reemplazo total del software existente. Gracias a que el SL siempre se encuentra sometido a estándares, es posible por ejemplo tener varios puestos de trabajo con un procesador de textos propietario y otros puestos con un procesador de textos basado en software libre.
5) Los "peces gordos" de la tecnología no hacen SL, sólo lo hacen comunidades independientes: falso. Actualmente quienes promueven más activamente al SL son las empresas más exitosas en los últimos años en su rubro (como IBM, Google, Sun, etc).
6) El SL no tiene soporte: falso. Sí tiene soporte: se puede contratar mesa de ayuda, soporte con asistencia remota. Se puede estar suscripto a bases de conocimiento o preguntas frecuentes (suscripciones que pueden ser gratuitas para el consumidor).
Hay que comprender que estamos presenciando el nacimiento de un nuevo paradigma en ciclo de vida del software, que no viene a reemplazar otro sino que viene a ocupar otro lugar:
Antes las empresas grandes cobraban su producido en software con licencias. Los usuarios debían adaptar sus procedimientos de trabajo a los dictados por ese software ya que los ciclos de vida con realimentación normalmente no tenían la agilidad esperada. No se está haciendo un juicio de valor sobre esta forma de trabajo. Simplemente se la presenta.
Ahora hay una alternativa: el desarrollo es más personalizado, se orienta más al servicio y a la solución de los problemas concretos. Las grandes empresas crean plataformas, marcos de trabajo (frameworks) o estándares de desarrollo sobre los que los regionales arman la solución.
7) El SL no puede tener un uso comercial: falso. Puede ser utilizado con cualquier propósito, principalmente como asistente a actividades comerciales, productivas, de investigación y entretenimiento. Incluso hay muchísimo SL cuyo ámbito principal de aplicación es el comercial.
8) Freeware y Shareware son lo mismo que SL: falso. Freeware significa gratis, y shareware con período de prueba gratis. SL (free software) es software libre.
9) SL es de menor calidad. falso. Cualquier software (libre o propietario) tiene la calidad que le da su equipo de trabajo y la que certifican los auditores expertos. Todo lo que hay que hacer es buscar la opinión de un grupo especialista en que se confíe: si ese grupo dice que un determinado SL es de la calidad esperada: adelante, a utilizarlo.
Habitualmente quien da la garantía a una pyme sobre un software es el consultor/desarrollador regional que se contrata.
Por ejemplo, si una pyme compra un servidor con sistema operativo Windows Server, la garantía de que va a funcionar correctamente va a estar brindada por el fabricante del software. Si en lugar de eso compra un servidor sin sistema operativo, su responsable de sistemas instalará un sistema operativo SL y será él mismo quien garantizará el correcto funcionamiento.
10) SL es de dominio público: falso. Dominio público pertenece a toda la humanidad, no tiene licencia. En última instancia el software de dominio público puede considerarse una variante dentro del software libre . El SL siempre tiene licencia, la cual hay que conocer y aceptar (y, de tener dificultades para entenderla, buscar soporte en alguien de confianza -personas, grupos, organizaciones- para recibir ayuda a interpretarla).
Los nombres mencionados son marcas registradas de sus respectivos propietarios.
Suscribirse a:
Entradas (Atom)