El jue, 26-08-2010 a las 15:58 -0300, Lucas Nogueron escribió: > El día 26 de agosto de 2010 15:30, Cristian Perez <[email protected]> escribió: > > 2010/8/26 blitux <[email protected]>: > >> El 26 de agosto de 2010 15:11, Carlos H. Matons Cesco > >> <[email protected]> escribió: > >>> > >>> El día 26 de agosto de 2010 03:41, Alejandro Vargas > >>> <[email protected]> escribió: > >>> > El día 24 de agosto de 2010 19:23, Carlos H. Matons Cesco > >>> > <[email protected]> escribió: > >>> > > >>> >> Juan Pablo, primero que nada tenés que definir qué tipo de software va > >>> >> a desarrollar esa empresa. No es lo mismo un sistema de gestión > >>> >> comercial standard (facturación, stock, contabilidad) a un sistema > >>> >> específico para hoteles, hospitales o alguna dependencia del estado o > >>> >> a cualquier otro que se te ocurra. Todos tienen sus particularidades. > >>> > > >>> > Podría ser instalación, mantenimiento, personalización y extensión de > >>> > software libre. Eso da un campo muy grande para especular sobre > >>> > posibles clientes: el software libre encaja en casi cualquier > >>> > actividad, desde una casa hasta una central nuclear. > >>> > > >>> > >>> Totalmente de acuerdo en que encaja en el ámbito que se te ocurra. > >>> Ahora salí a la calle y pregunta en las empresas, casas y centrales > >>> nucleares cuántas estarían dispuestas a utilizar sistemas GNU/Linux. > >>> Vas a ver como tu gran mercado se reduce considerablemente. > >> > >> Creo que un miembro del lugmen (Tango) estaba trabajando en un > >> programa de extensión de vida util de alguna Atucha. Habría que > >> preguntarle a él que usan. > >> > >> -- > >> Pablo Daniel Quiroga Figueroa | @blitux > >> http://blitux.tumblr.com > >> > > > > Algo de info: > > http://www.laflecha.net/canales/ciencia/noticias/desarrollan-un-simulador-3d-aplicado-al-diagnostico-y-seguridad-de-las-centrales-nucleares > > > Ey profe, la Atucha y Embalse RIO III estan con QNX y se hace > desarrollo en C y en Fortran, y unas maquinas Variant viejas que ya no > deben existir, date una idea que tienen muchos años y estan antes que > el codigo abierto existiera, y que internet misma, supongo que algo > habrán mejorado, pero no sabría decirte. En la Atucha 2 no sé que van > a usar, pero sigue siendo un reactor con uranio levemente enriquecido > y agua pesada, asi que las medidades de seguridad deben ser las mismas > que las otras; justamente al ser levemente enriquecido generan menos > potencia (desventaja), y menos daño en caso de que se derrita el > nucleo u otro accidente o vengan los yanquis a decirte que estas > enriqueciendo el uraniio para hacer una bomba y quitarte esa > tecnologia(ventajas) . Muy bueno el enlace. Por cierto laburo en la > CNEA por sino se acuerda. Desde mi humilde lugar apuesto al codigo > abierto y el soft libre en el estado. > > Saludos. > >
Coincido con Lucas. Trabajo en el Proyecto para el Segundo Ciclo Operativo de la Central Nuclear Embalse. Estoy a cargo de las bases de datos y aplicaciones necesarias para el proyecto. En la primera fase, desarrollamos 4 bases de datos y 3 aplicaciones. Tuve que lidiar con lo que ya había en planta, ASP.NET y SQL Server. Sin embargo, instalé mi ubuntu server 8.04 (hoy 10.04) y con VMWare Workstation (hoy con KVM) corro una "ventanita" en uno de los 6 escritorios virtuales donde está el equispe, el ide y dbms de desarrolo. Esto no impidió que en mi mismo ubuntu pusiera Apache con PHP y MySQL, SVN, Flyspray, Drupal, etc. Todos los fuentes que hicimos están guardados en mi repo SVN. Para accederlo desde la MV de desarollo uso el Turtle SVN. En Drupal 6 está mi portal del Proyecto, donde publico noticias, algunos tienen su blog y tengo un agregador de RSS. Si me preguntan porque no hice las aplicaciones con alguna otra opción de servidor de aplicaciones y/o base de datos, la respuesta es simple: tuve que usar los "oficiales", los que estan en el centro de cómputos y tienen administradores que se las tienen que arreglar para que estén disponibles. Yo solo me ocupo de desarrollar y que funcione. Sin embargo, esa situación no impidió que utilice SL para las otras tareas y/o funciones: Portal Intranet del Proyecto: Drupal 6 Servidor de Fotos Usuarios Locales: Gallery 2.3 Servidor FTP: proftpd Tareas de Desarrollo: Flyspray Gestión de Codigo Fuente: SVN Servidor Mensajería Instantánea: ejabberd Robot de noticias: gozerbot Las estaciones de trabajo de mis compañeros tienen Pidgin o PSI como cliente de mensajería instantánea. Muchos están usando OpenOffice, porque el "otro" se moría cuando llegaban los informes de provedores extranjeros con más de 500 páginas. El OOo se demora unos segundos en cargar y luego se puede usar decentemente, el otro se queda eternamente "repaginando" y estás 10 minutos para avanzar 5 páginas, todo con el mismo HW (CPU, RAM, disco) y SO de la ventanita. En mi caso, uso el pdftk para procesar los PDFs de más de 1000 páginas que llegan de estos proveedores, así los puedo manipular a mi antojo y los puedo fraccionar para que los vean las máquinas con el "otro" SO y el lector de pdf propietario. Cierro con una anécdota: Tuve un caso dónde, un viernes, quisieron copiar varios GB de un fileserver propietario a otro. La operación, con una red de 100 Mbps estaba estimada en 12 hs. No recuerdo el volumen a copiar, pero si que la tasa de transferencia que conseguían eran de, escasos, 2 MB/s. Desactivando los dos antivirus, se lograban casi 4 MB/s. Como el tiempo era excesivo y mis datos estaban en uno de esos servidores, solicité autorización al jefe de cómputos para probar yo. Arranqué con Ubuntu 9.04. Las máquinas tenía dos placas de red, una para trabajo normal y otra para backup. Después de 5 minutos, arrancando de CD y luego actualizar los orígenes de software e instalar smbclient y smbfs ya estaba listo para copiar. Usando la placa de red de trabajo me autentiqué con el controlador de dominio pero forcé a montar el recurso remoto donde copiar para ir por la otra placa, que ahora tenía un patch cruzado con el otro server. Una vez que inicié la operación, la tasa de transferencia eran 12 MB/s. En lugar de tener que venir sábado y domingo para terminar de copiar, podía terminarse de copiar el mismo viernes antes de las 18:00 que era el horario de salida. Transcurridos 5 minutos, falló la operación. La placa de red que tenía el patch cruzado, se rompió (maldito Murphy). ¿Que hice? Usando el gestor de conexiones de red de ubuntu, intercambie las direcciones MAC de las interfaces de red, y cuando puse reintentar, la operación continuó si problemas. El jefe que estaba viendo todo se impresionó por la rapidez y facilidad para realizar dicha operación, y sobre todo, que se salvaría de venir el sábado. La operación se ejecutó con una tasa, promedio, de 10 MB/s. El sábado a la mañana, se acercó hasta la ventana del datacenter para ver que había terminado, y se fue. La semana siguiente, hubo que realizar otras operaciones de copia masivas... adivinen que usaron? ;) Como Lucas, desde mi humilde lugar apuesto al código abierto y software libre en el estado. Mi idea es, como dijo alguien más, mostrar lo que el SL puede hacer y de a poco ir introduciéndolo. salu2 -- TaNgO Río III - Cba.
