On Sun, Dec 06, 2009 at 01:19:47AM -0300, Dan Zajdband wrote: > Buenas. Entré a la facultad este cuatrimestre y estoy para la carrera de > Ciencias de la Computación. Estoy interesado en el proyecto de FCENIX pero > propongo un cambio radical en el asunto.
¡Apa! Bienvenido entonces. :) > > Hablando del asunto con un amigo (Guillermo Rauch, su blog es > http://devthought.com es desarrollador oficial de MooTools > http://mootools.net/developers entre otras cosas ) Creimos más apropiado > crear un repositorio en vez de una distribución. Hay que adaptarse a las > necesidades del usuario, no crear nuevas. Sí, lo del repositorio lo pensamos. La idea de crear una distribución (que, casi seguramente, va a terminar siendo la suma de una distribución conocida más un número de paquetes instalados) es la de poder entregarle a la gente un sistema ya andando y con todo lo que necesita, facilitándole las cosas al usuario novato, y siendo útil aún en ambientes en los que no hay Internet. Si la distribución no se crea, y se crea solamente un repositorio, entonces tendríamos que repartir CDs de alguna distribución conocida (o señalar cómo conseguirlos, grabarlos y demás), enseñar cómo hacer que su distribución reconozca nuestro repositorio y cómo instalar los programas, y además agregar como requerimiento que la persona cuente con Internet en su entorno. A mí me parece que lo del repositorio se queda corto para los objetivos (que aún no están del todo definidos, pero que venimos charlando) iniciales que teníamos. No me parecería una mala idea que la distribución no sea más que una distribución conocida (a la que se le pueden quitar algunos paquetes no tan útiles) con nuestro repositorio agregado, y con los paquetes de este repositorio instalado. En otras palabras, lo del repositorio es una buena idea, pero sirve sólo para una parte de lo que queremos lograr. > > Utilizando software como HUDSON ( > http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson), se pueden automatizar > las tareas de generado de paquetes para las distintas distribuciones > existenes mas populares. > A partir de un repositorio (que podrá ser SVN, GIT, Mercury), se puede tomar > el codigo fuente, probarlo y generar paquetes automáticamente. > Para debian/ubuntu esto significara generar un .deb que luego se sirva a > traves de un servidor web (cosa que los usuarios puedan agregar el > repositorio oficial de la UBA a su /etc/apt/sources.list) > Para OS X, se puede generar un port compatible con MacPorts o un .dmg y > para sistemas BSD (port) o Gentoo (portage) que trabajan compilando de > acuerdo a instrucciones, la tarea es aun mas sencilla. > De esta forma podemos podemos soportar de forma sencilla la distribucion de > nuestro software (y el de toda la UBA) a todas las plataformas *nix. La verdad, no tenía idea de la existencia de Hudson. Voy a tener que darle una mirada :) > > Por otra parte si lo que queremos es difundir el software libre, creo que el > mejor modo es hacerlo entre las facultades donde menos se conoce. La > concientización dentro de nuestra facultad es clara. En cambio, si queremos > que este proyecto tome reelevancia real, podríamos comprometernos a realizar > un trabajo en conjunto con otras facultades para conocer el tipo de software > que se necesita y los problemas que trae el uso de software privativo en el > ámbito académico. Como te respondieron antes, a varios de nosotros nos parece que la concientización en nuestra facultad es un trabajo que está lejos de estar terminado. En cuanto al trabajo en conjunto, creo que está bueno compartir información con gente de otras facultades/universidades (como, ahora mismo, la gente de la UTN de Córdoba) que está ocupándose de lo mismo. De hecho, me parece que cada cosa que hagamos con respecto a este proyecto debería estar documentada y publicada para facilitarle el trabajo a otros con intenciones similares. Sin embargo, la realidad es que facultades distintas tienen necesidades distintas. Es probable que las carreras de cada facultad sean diferentes, como también sus materias y los programas de estas. En otras palabras, nuestro meta-paquete "software-para-fceyn" no se ajustaría muy bien a las necesidades de la UTN, por ejemplo. Sin embargo, seguro que nuestro trabajo y su documentación pueden servirles de mucho. [snip] > > Saludos! Saludos, y muchas gracias por aportar tu opinión. No dejes de hacerlo. -- Pablo Antonio (AKA crazy2k) http://www.pablo-a.com.ar/ _______________________________________________ Glug mailing list [email protected] http://glugcen.dc.uba.ar/cgi-bin/mailman/listinfo/glug
