Category Archives: Opinión

Los sabores de Windows

18 Enero 2010

Las liberaciones de Windows, de Microsoft, suelen realizarse siempre por triplicado, es decir, de cada línea interesante que saca la compañía, hay tres versiones, después es abandonada por los motivos que se verán obvios.

La triada de Microsoft consiste en sacar una versión primera, una versión más elaborada gráficamente y mejor recibida por el público en general, y una última versión que termina siendo un fiasco, que dura poco en el tiempo y en la memoria de muchos usuarios, afortunadamente para Microsoft.

La línea light

Cuando los equipos no eran tan potentes como para soportar todas las características que tenía incluídas Windows NT, la empresa tuvo que realizar un sistema operativo mezclado con el sistema DOS que ya tenía, para obtener un sistema mixto llamado, en un principio, Windows 95.

Después llegó la versión bonita, que fue Windows 98, la cual era una versión gráficamente superior de Windows 95 y mejor preparada para Internet.

El punto final a esta línea lo puso Windows ME (Millenium Edition), del cual, pocos se acuerdan, salvo los que lo sufrieron y la mayoría coincide en que tenía multitud de fallos y las mejoras gráficas y de incorporación de elementos multimedia no compensaba esos fallos.

La línea NT para particulares

Cuando la potencia de las máquinas de uso cotidiano alcanzó a poder ejecutar sistemas NT, la compañía recuperó su sistema base, sin recortes, y aprovechó el cambio de siglo para sacar su primera versión, la cual tuvo una expansión hacia los sistemas servidores y un gran lanzamiento en lo que respecta a la empresa (que era la que podía hacer el mayor desembolso). Esta versión fue Windows 2000.

Dos años después, esta versión ya era posible en su incorporación al mercado residencial y se potenció su interfaz gráfica, así como sus elementos multimedia, liberándose como Windows XP. Esta versión supuso un cambio drástico a aquellos que cambiaban directamente desde Windows 98 (un sistema basado en el kernel de DOS) a este (con un kernel NT que no permitía ya la ejecución de aplicaciones de 16 bytes de DOS).

Al igual que en la línea anterior, se intentó potenciar la línea multimedia y de interacción gráfica para el sistema pero, parece que la historia se repitió y la tercera entrega, al igual que Windows ME, fue otro fiasco. Esta liberación tuvo el nombre de Windows Vista.

Re-escritura y nueva vida

Después de topar con la imposibilidad de seguir con la infraestructura NT tal y como estaba, la compañía necesitaba un nuevo lavado de cara y comenzó el desarrollo de Windows 7, el cual ha sido una reescritura completa, desde cero, así como lo fue Windows 95 y Windows 2000. Con lo que conforma el principio de otra línea, en la que la siguiente versión será, o eso se espera, muy buena, llegando una tercer que marcará el final de la línea… con otro fiasco.

Alternativas

Microsoft no es la única compañía que, después de 15 años, ha realizado un sistema basado en el kernel de NT para la ejecución de programas. Estos sistemas, desde simuladores para otros sistemas operativos a sistemas operativos en sí mismos, han hecho que el uso de sistemas tipo Windows no sea monopolio de Microsoft.

Entre otros, los emuladores más conocidos, desde el mundo GNU/Linux, son Wine, Cedega y CrossOver (basados en wine).

Uno de los sistemas operativos, que trabaja junto con wine en el desarrollo y emulación del kernel NT bajo sistemas Unix, es ReactOS. El desarrollo de este sistema es muy activo desde que comenzó y ya tienen un LiveCD en el que se pueden probar aplicaciones para Windows. Una alternativa muy a tener en cuenta, y sobre todo porque es GPL, es decir, software libre.

0 Comments

¿”Ingeniería” del software?

30 Julio 2009

El creador de menéame, Ricardo Gallí, escribió hace unos días un artículo en su blog bastante interesante sobre lo que respecta a la llamada Ingeniería del Software. Ricardo sostiene en el mismo que el título de “ingeniería” ha sido dado de forma errónea al desarrollo de software y, en muchos aspectos, tiene razón.

Rescato la lista que él mismo recopiló de Tom DeMarco, sobre un artículo de opinión publicado bajo el título Software Engineering: An Idea Whose Time Has Come and Gone? (Ingeniería del Software: ¿Una idea cuyo tiempo pasó?):

  • Hoy en día todos comprendemos que las métricas de software cuestan dinero y tiempo, y que deben ser usadas con moderación.
  • El desarrollo de software es inherentemente diferente de las ciencias naturales tales como las física, por lo que sus métricas son muchas menos precisas para capturar lo que deben describir.
  • La frase más citada del libre es No puedes controlar lo que no puedes medir. Esta frase contiene una verdad real, pero cada vez me sentía más incómodo con el uso que hice de ella. Está implícita en la frase (y en título del libro) que el control es un aspecto importante, quizás el más importante, de cualquier proyecto de software. Pero no lo es.
  • Muchos proyectos se han realizado sin demasiado control pero han generado productos maravillosos tales como Google Earth o la Wikipedia.
  • Esto nos lleva a la desagradable conclusión que el control estricto es algo que importa mucho en proyectos relativamente inútiles y mucho menos en proyectos útiles. Sugiere que mientras más te enfoques en el control aumenta la probabilidad de que estás trabajando en un proyecto que se esfuerza por generar algo de valor relativamente menor.
  • ¿Estoy diciendo que está bien ejecutar proyecto sin control o con un control relativamente menor? Casi. Estoy sugiriendo que deberíamos seleccionar primero a los proyectos cuyo control preciso no importe demasiado.
  • Estoy llegando gradualmente a la conclusión que el momento de la ingeniería del software vino y se fue.
  • En los últimos 40 años nos hemos torturado por nuestra ineptitud en acabar proyectos a tiempo y con el presupuesto previsto. Pero como sugerí antes, no debería haber sido el objetivo supremo.
  • El objetivo más importante es la transformación, crear software que cambie el mundo, o que transforme una empresa, o la forma en que hace negocios.
  • El desarrollo de software es y será siempre algo experimental. Lo construcción real de software no es necesariamente experimental, pero sí lo es su concepción. Allí deberíamos enfocar nuestros esfuerzos. Allí es donde deberíamos haberlo hecho siempre.

Esto nos indica que el software debe de realizarse con un fin concreto, con una utilidad en mente y, el hecho de prefijar, fijar o realizar unos requisitos sobre él, no son más que el ejercicio de la práctica y las necesidades reales que quieran cubrirse de forma eficiente. Cambiando algo significativamente.

Otro aspecto que se enfatiza es el tema del control. ¿El control excesivo es perjudicial para un proyecto de “ingeniería” del software?

Lo que es casi obvio para la mayoría de profesionales, es que el desarrollo de proyectos en cadena es bueno emplear metodologías tradicionales, puesto que son cosas que se han podido medir durante mucho tiempo, no suelen cambiar mucho y se realizan siempre de la misma forma. E igualmente, el equipo humano, su creatividad y destreza no son tan importantes como el procedimiento marcado para realizar el programa en el tiempo estimado.

Por otro lado, los proyectos a medida, que se realizan con una especificación de requisitos variable y que pueden ir modificándose en el tiempo con la necesidad del cliente, requieren de otro tipo de metodologías que den otro tipo de control a los desarrolladores y mayor libertad a los programadores. En este caso sí es muy importante que los desarrolladores (analistas) sepan programar, y sepan lo que cuesta realizar el trabajo y, sobre todo, que sean los programadores los que digan lo que van a tardar en cada tarea. Aproximadamente.

El segundo grupo es el que más proyectos genera para la industria de creación de software y, dado que la llamada ingeniería es tan liviana en este caso, quizás sí, quizás el nombre no sea todo lo acertado que debiera… o quizás necesitemos otro nombre para nombrar lo que hacemos.

0 Comments

El Principio de Peter

20 Abril 2009

Hace tiempo ya escribí algo relacionado con esto, en el artículo despide a tu jefe. Hoy, después de haber leído la definición del principio de Peter en la wikipedia, se le puede dar más forma, precisión y color :-P

El caso es que en la mayoría de empresas, lo normal, es promocionar, es decir que, siendo bueno en lo que se hace, se sube de puesto por méritos y se toma mayor responsabilidad, mayor sueldo… pero también, algo poco evaluado, es que se cambia de trabajo.

El principio de Peter viene a decir que cada persona es ascendida hasta su nivel de incompetencia.

Esto quiere decir que, si somos buenos haciendo lo que hacemos, al ascender, haciendo otra cosa distinta, podemos no ser tan buenos, e incluso podríamos ser un desastre haciendo ese trabajo. Ahí es donde se centra el principio de Peter, ya que, siendo ya no tan buenos en el nuevo trabajo, es más difícil ascender.

Esto no es así en el 100% de los casos. Hay gente que cuando sube de puesto se recicla y comienza a hacerse valer en el nuevo puesto… pero son los menos.

La pregunta que debemos de hacernos cada uno, entonces, es… ¿has llegado a tu nivel de incompetencia o te sigues reciclando?

2 comentarios

Debate sobre la Ingeniería Informática

10 Noviembre 2008

Reconociendo al sector informático como la cuarta parte de los estudiantes de las ingenierías que se estudian en las universidades españolas, la regulación de las titulaciones y el asegurar que dichas titulaciones son de calidad y corresponden a la calidad de nuestros vecinos europeos, se cierne sobre Estado y Universidades el debate de la responsabilidad de que esto sea así.

El Partido Popular, en el debate para votación de la Propuesta de No Ley (PNL) sobre la Ingeniería Informática, presentada por este mismo partido, hacía presentación y propuesta de querer defender las titulaciones informáticas por los motivos:

  • Creación de Fichas de Grado y Máster donde se reflejen las Competencias de los Titulados de Ingenierías Informáticas.
  • Dichas Fichas se crearon en el Libro Blanco, el cual fue anulado y retirado.
  • No se han tenido en cuenta las Ingenierías Técnicas y las Ingenierías de Informática para la asignación de títulos que habilitan para el ejercicio de las diferentes profesiones de Ingenieros Informáticos.

Entre líneas, se puede entrever que el portavoz del Partido Popular, intenta dar voz a los Colegios de Informática para vencer el intrusismo que se origina en nuestro sector.

Por otro lado, el portavoz del PSOE, da los siguientes puntos en contra de la PNL, que son a tener muy en cuenta:

  • En el contexto europeo, las titulaciones informáticas con relación a másteres, grado y doctorado son muy ágiles y no pueden estar sujetos a regulaciones.
  • En este contexto que se tiene, es en el que operan las mejores universidades del mundo y que han demandado decanos españoles.
  • Por ley, las fichas que se demanda hacer no pueden realizarse mediante la PNL, puesto que las titulaciones no están reguladas para funciones laborales concretas.
  • Los estudiantes y titulados no pierden derecho ni valor de sus estudios y títulos, respectivamente.

Escuchando el audio completo, el portavoz del PSOE rebate el argumento de trasfondo de la PNL, que es establecer unos cortes y asignaciones laborales concretas en el campo de las Ingenierías e Ingenierías Técnicas Informáticas y, establece que, el medio expuesto es el equivocado, que se ha recubierto de algo llamativo, que se establezca como un FUD para la comunidad de estudiantes y profesionales para demandar algo que ya tienen otros Ingenieros como los Arquitectos, por ejemplo.

La votación se produjo, quedando 19 votos en contra, 17 a favor y 2 abstenciones. Con lo que, se deja libertad a las Universidades para el establecimiento de grados, másteres y doctorados.

Por otro lado, queda el tema del intrusismo que, si la educación de las universidades preparase para el trabajo real, yo mismo defendería, pero teniendo en cuenta de que se enseña a ingenieros para desarrollar el trabajo de técnicos… y que mucha gente sin titulación resulta, en muchos casos, más profesional y efectiva que gente con titulación, lo que se debería es de defender más que la PNL no haya salido y que las universidades, con la flexibilidad que les ha sido otorgada, se encarguen de hacer competente su plan de estudios para hacer que los universitarios sean trabajadores e ingenieros competentes.

A día de hoy, si se busca a, por ejemplo, un Arquitecto Java, que es una persona que establece el análisis de un productos software, la solución arquitectónica en base a un diseño general y su seccionado para el trabajo de grupos más pequeños… algo básico y rudimentario para un ingeniero, ¿cuántos titulados serían capaces de realizar este trabajo?, ¿cuántos de ellos no se pondrían directamente a desarrollar todo lo que pide el cliente directamente en Visual Basic?

Quizás, lo que debería de haber es más control de calidad en los estudios y enseñanzas de las universidades a través de exámenes y certificaciones a sus alumnos, para asegurar que salen ingenieros e ingenieros técnicos competentes.

3 comentarios

Documentación de Proyectos Libres

6 Noviembre 2008

Se ha hablado mucho sobre la escasez de documentación en proyectos libres, tanto de manuales técnicos o de administración, que expliquen como instalar y administrar el software, como manuales de usuario, que expliquen cómo realizar las actividades que propone el software realizar.

Es claro que, cuando una persona aprende a desarrollar, a programar, se sienta frente al ordenador y comienza esa frenética batida de golpes contra el teclado, una pausa para ver los resultados, un momento de pensar en el siguiente paso, y otra vez a teclear… en esos momentos, la documentación, si se piensa hacer, es algo que se estima para un futuro… para cuando se dé a conocer.

Es lógico que un proyecto grande, creado con una línea en mente, a veces por una empresa o una entidad como puede ser una fundación o una universidad, suele ser otra cosa (casos como MySQL, PHP, PostgreSQL, Firefox, OpenOffice, Apache, …).

La documentación es como la lluvia, nunca cae a gusto de todos, por lo que es muy complicado realizar un documento sobre un programa que cumpla con las expectativas de todos los posibles usuarios que vaya a tener el programa.

Los tipos de documentación que se han identificado a lo largo de los años pueden englobarse dentro de los siguientes grupos:

  • Receta (o How-To): es un documento para gente que quiere hacer algo funcionar de forma rápida y no se quiere parar en detalles. Suelen ser documentos cortos, concisos y estructurados en pasos.
  • Getting Started: algo así como los primeros pasos. Es para gente que quiere ver algo funcionar de forma rápida, para después centrarse en los detalles. Es básicamente en lo que se fundamenta Linux, Unix y demás sistemas parecidos… la filosofía Unix.
  • Manual: suele ser un libro extenso donde se explican, por capítulos, cada parte específica del programa. Este tipo de documento suele venir bien para quien tiene interés en aprender a usar bien el programa y, depende del enfoque, el modo en que se use: usuario, administrador, instalación…
  • Tutorial: parecido al anterior, pero más pedagógico, intenta adentrar de una forma más suave al usuario a lo que es el uso del programa.
  • White Paper: algo así como la filosofía en la que se basa el programa. Explica la ideología, en lo que se basa, pero no cómo se usa. Muy útil para quien tiene interés en saber el trasfondo de la creación del programa.
  • Guía de Referencia: suelen ser los comandos o atajos que se pueden usar en cada parte del programa, ya sean comandos, teclas rápidas, combinaciones, menús de acceso… depende de cómo se presente el programa.

Hay proyectos, comerciales y libres, que reúnen toda esta variedad de documentos, lo cual es muy útil y, aún así, sigue habiendo problemas entre los usuarios, puesto que la calidad u orientación de los mismos, puede no ser muy precisa o atinada. En este aspecto, los manuales, en su mayoría, suelen tener un baremo en el que presentan el público a quien va dirigido el documento y lo que trata en sí, encontrándose así libros para gente nueva en el tema, de nivel bajo, intermedio o avanzado.

En proyectos de gran tamaño, como puede ser Apache, la documentación que se reúne, puede sobrepasar, perfectamente, las mil páginas. Más en concreto, el manual de usuario con guía de referencia de PHP (de su página web) tiene un tamaño de aproximadamente 2000 páginas.

Por lo tanto, no es que los programadores o desarrolladores no hagan documentación… es que escribir documentación es una tarea ardua, larga y conlleva más tiempo que en escribir el código del programa que se documenta para, después, encima, ver que la documentación escrita no es suficiente, o no se entiende bien… ya que, además, si la escribo en castellano, no es lo mismo que si la escribo en inglés, por supuesto.

Comentarios desactivados

Desmitificando: software y su mantenimiento

13 Octubre 2008

Desde siempre, cuando una empresa apuesta por software privativo frente a software libre o de fuente abierta, lo hace por tener cubiertas las espaldas, por tener garantías y saber que hay una empresa que responde por ese software, tanto en mantenimiento, como en incidencias graves, que pueden llegar a pagar indemnizaciones.

Este es el principal motivo de que se abogue por software propietario, simple y llanamente. Cualquier otro motivo es un mito, como cualquiera de los siguientes:

  • Una empresa te dará más y mejor soporte: normalmente suele… o solía ser así. Las empresas de software contratan programadores, analistas y una serie de personal que son capaces de desarrollar un software más o menos eficiente y después mantenerlo… pero, existen muchos casos en los que este soporte y mantenimiento, no se ha pensado, no se da o es ineficiente. Por:
    • El software se ha desarrollado contra-reloj, sin fuerte planteamiento flexible a cambios y falto de documentación sobre la filosofía que sustenta que todo esté “ensamblado” de la forma en la que lo está.
    • La programación ha sido realizada “sobre la marcha” haciendo el software inconsistente, con gran cantidad de fallos y las soluciones no terminan de llegar. Con cada incidencia reportada aparecen nuevas.
    • El equipo de desarrollo cambia íntegramente o parcialmente, haciendo que el nuevo equipo programe el hard-coding de una forma distinta al anterior grupo, con lo que el software va mutando y distnaciándose del planteamiento original, que fue informado únicamente al primer grupo.
    • Una empresa tiene los recursos humanos limitados y, en caso de tener mucho trabajo, puede que incluso esos recursos humanos ya no respondan de la misma forma que al principio.
  • Una empresa te garantiza el software: hay cláusulas que limitan ese tipo de garantía y, en muchos casos, incluso las incumplen con lo que tienen que tirar de un seguro que les pague la indemnización. Tener una garantía no te asegura que funcione y, sobre todo, si quien te da la garantía tiene una veracidad y credibilidad dudosa.
  • El software propietario está mejor hecho: no se sabe, puesto que no se puede ver. Lo que sí se sabe es que no debe de estar tan bien hecho cuando necesita ser reescrito entre versiones, muchas veces. De igual forma, sería mejor no fiarse de una empresa que no tenga departamento de calidad, que certifique que el proceso de desarrollo ha sido llevado usando un cierto proceso lógico y se han llegado a cumplir una serie de espectativas de forma satisfactoria.
  • Es mejor tener el producto que no un servicio: ciertamente, y por eso se debería de preferir tener un software con una licencia que te permite ciertas libertades sobre él, y no un producto del que solo se ha comprado una licencia que te permite usarlo con muchas limitaciones. Muchas veces incluso limitaciones en el tiempo. Adquirir una licencia es como adquirir el servicio de uso sobre un producto, a modo de alquiler, pero sin la ventaja de poder reemplazarlo sin coste adicional en caso de deterioro, el servicio de mantenimiento se suele contratar aparte.
  • Software a medida es caro, difícil de hacer y no suele cubrir las espectativas: si se piensa esto es que no se ha pedido su desarrollo a una empresa seria. El desarrollo de software es un proceso que se debe de seguir, desde una especificación hasta obtener el producto que el cliente quiere usar. Cuando se desarrolla sin seguir un protocolo, con limitaciones o simplemente saltándose pasos… esto deriva en un software “mal acabado”, que no cumple con los requisitos iniciales y que deja la sensación de que, cualquier “chapuza” sobre un software ya hecho (como Office o similar) hubiese sido mejor.

Bueno, la verdad es que podría extenderme mucho más, porque las chapuzas en el campo de la informática están a la orden del día, pero con tener presentes estos puntos, creo que es suficiente para tener una visión un poco más amplia de lo que hay y lo que realmente se debería de buscar en cada caso.

Recordar también que, el software libre es una gran librería de programas que sirven para probar, seleccionar algo que guste usar y solicitar modificaciones y/o ampliaciones sobre ese software en caso de necesitarlas.

Comentarios desactivados

¿Está mi empresa organizada?

7 Octubre 2008

Cuando una empresa se forma, se intenta organizar el trabajo entre las pocas personas que la inician y si su estructura es buena y sus productos/servicios asequibles para el mercado, la empresa crece y con ella su personal. Es el inicio de los problemas.

Cuando una empresa crece, se contrata a más gente y estas personas comienzan a ocupar cargos que antes desempeñaba una persona en un porcentaje pequeño de su actividad laboral. El ritmo vertiginoso hace que las reuniones con esta nueva persona, para explicarle su cometido sean breves y escasas, así que terminan por hacer el trabajo a su manera.

Después de pasar por varias personas, varias formas de hacer las cosas y distintas formas de organizar las cosas, cuando un grupo de personas deja la empresa y retoman otro grupo, suele ser un caos y, el reactivar el proceso de producción en esa parte, muy lento y costoso.

El problema se debe a la falta de método y documentación.

Cuando una persona entra a trabajar en una empresa madura, suele entrar en un engranaje del que tiene que formar parte. Sus conocimientos básicos son los que se le solicitaban al entrar al puesto de trabajo, como pueden ser saber programar, una cierta metodología, idioma o titulación. Pero a partir de ahí, la formación debe de ponerla la empresa y, es en este punto, donde la mayoría de empresas, no tienen forma de explicarles a sus nuevos empleados lo que hay, lo que tienen que hacer o cómo hacer su trabajo.

El funcionamiento de una empresa, sus procesos y su burocracia, debería de estar recogida y revisada en un documento de Modelo de Negocio. En este documento se especifica cómo funciona cada departamento, los cometidos de cada uno de los subdepartamentos y las políticas de trabajo, comunicación y otros aspectos o típicos como seguridad laboral.

Así mismo, cada departamento y/o subdepartamento, debe tener claro su cometido y esclarecer una forma en la que realizar su trabajo, tener sus tareas bien definidas y documentadas para, en caso de enfermedad, vacaciones, cese o fallecimiento, el trabajo pueda ser cubierto por cualquier otra persona.

Estos tipos de documentos no son solo una gran utilidad para el propio empleado, sino también para las consultoras y asesorías externas, puesto que pueden optimizar dichos procesos, e incluso diseñar software que ayude y dé soporte a estos procesos.

¿Sería capaz de diseñar un modelo que optimice el rendimiento de su empresa?, un modelo de negocio podría desvelarle qué puntos podrían optimizarse y mejorarse, así como qué recursos tiene más explotados y cuáles están más libres.

Also posted in Empresa – Comentarios desactivados

Filosofía Unix

22 Septiembre 2008

Desde que comencé en GNU/Linux, sobre el 2002, siempre se ha resaltado la filosofía con la que se fundamentó el sistema al que “copia”, que es Unix.

La filosofía Unix se basa en algunos apartados básicos que todo buen informático debería de emplear en sus desarrollos, ya sea a nivel de sistemas o gestión. El uso de estas directivas, asegura que el trabajo, cuanto más pase el tiempo, más llevadero será.

Las directivas son, básicamente:

  • Escribe programas que hagan una sola cosa y la hagan bien: esto quiere decir que los programas deben de ser lo más atómicos posible y que se compruebe mucho su rendimiento y funcionamiento para hacerlo lo mejor posible.
  • Escribe programas que trabajen juntos: de nada sirve escribir programas que sirvan para una tarea específica y que, después, cuando esa tarea se modifique de cierta forma, haya que reescribir todo el programa. Es mejor dividir el problema en varios programas y después desechar o reescribir solo uno de esos pequeños programas, cuando se necesite, o incluso hacer nuevos.
  • Escribe programas que manejen flujos de texto, pues esa es la interfaz universal: todo lo que se hace con entrada y salida en formato textual es más fácil de enlazar con otros programas, así como reutilizarla en el pasado, presente y futuro.

En estos conceptos se basa la mayoría de software libre que existe, por lo que servidores como sendmail o postfix, se basan en pequeños servidores y/o programas que hacen partes de todo un proceso y, mediante sus ficheros de configuración, se pueden enlazar de una u otra forma, así como usar otros programas y/o servidores en lugar de los que vienen por defecto y, así, extender su funcionalidad.

Sobre filosofía Unix, de una forma más extensa, Mike Gancarz, escribe las siguientes líneas:

  • Lo pequeño es hermoso.
  • Haz que cada programa haga una sola cosa, pero que la haga bien.
  • Construye un prototipo lo antes posible.
  • Elige portabilidad sobre eficiencia.
  • Guarda los datos en archivos de texto plano.
  • Aprovecha funcionalidades del software.
  • Usa scripts de shell para aumentar la funcionalidad y portabilidad.
  • Evita interfaces de usuario captivas.
  • Haz de cada programa un filtro.

Esto no quiere decir que lo realizado sobre interfaces gráficas sea malo, o no respete estas premisas, puesto que muchas de estas interfaces hacen uso de programas que sí respetan al máximo estas premisas y que, favoreciendo la penúltima directiva escrita por Mike, permiten ver los comandos que ejecutan, junto con todos los argumentos.

Concluyendo, pensemos que el trabajo que se realiza día a día, no solo ese software que programamos por amor al arte, debe de sernos de utilidad, no solo en el momento en que nos lo piden para solucionar un problema dado, sino como “caja de herramientas” para la solución de miles de problemas que se deban de resolver en un futuro, quizás no muy lejano :-)

Vía: La filosofía UNIX

Comentarios desactivados

HP quiere su propio S.O.

15 Septiembre 2008

se ve que tanto tiempo vendiendo licencias de Microsoft en sus equipos, le ha hecho a este gigante de la venta de hardware, replantearse si vender sus equipos con Windows, y sobre todo con Vista, es buena idea.

La idea que tienen es desarrollar algo simple para el usuario, basado en GNU/Linux, por lo que supongo que será algo así como Ubuntu, solo que mucho mejor soporte de hardware para los equipos HP con los que se venda.

Nada dura eternamente y, se ve que, la hegemonía en ventas del sistema operativo más criticado, tanto positivamente como negativamente, del mercado, llega a su fin. Ya veremos si consiguen o no levantar el vuelo con Windows Seven, o se convierte en otro fiasco.

Vía: TechTear y en inglés BusinessWeek.

Also posted in Noticias – Comentarios desactivados

Microsoft no es ingeniería, sino comercio

11 Septiembre 2008

Uno de los grandes avances que ha conseguido Bill Gates no ha sido como informático, como muchos creen, sino como comercial.

Microsoft ha sido, quizás, una de las más grandes empresas de software que más se han basado, para sus grandes proyectos, en software adquirido a otras empresas. Con lo que los desarrollos propios, son pocos.

En la wikipedia se puede ver la lista de empresas que ha adquirido Microsoft a lo largo de su historia, y en la que se pueden ver dónde comenzaron ciertos productos.

Esto da una idea del porqué los productos de Microsoft, en el momento de salir, son frescos, parecen buenos, pero parece como si se fuesen marchitando e, igualmente, el porqué de la necesidad de reescribir Windows desde cero varias veces.

Comentarios desactivados
« Older posts