Eskerrik asko Unai hainbeste info zabaltzeagatik!

Sobré cuál es la estrategia que estamos siguiendo para obtener la
información.
Estamos diseñando un formulario para enviárselo en una primera fase a todo
el profesorado de la Facultad de BBAA preguntando. Vamos a preguntar
principalmente por software de edición y postproducción de vídeo y audio,
diseño y manipulación de imagen. No entraremos en software de oficina que
viene presintalado con los ordenadores corporativos.

- Cuestionario
1.- Qué software usan (Docencia, preparación, investigación, obra personal)
2.- Si es ordenador de aula, Aula con ordenadores, ordenador personal
3.- Qué software tienen instalado
4.- Qué licencias necesitan para 2018
5.- Docencia en euskera

En una segunda fase, dependiendo del feedback recibido, queremos valorar el
uso real y necesidad de cada software. Seguramente lo haremos por medio de
entrevistas con un muestro de gente. También hablaremos con los
directores/as de dpto.
Y por último, tenemos datos, a nivel Facultad, de pago de licencias,
últimamente prácticamente se compra todo a  través de la convocatoria de
Laboratorios docentes, y del nº de equipos totales que hay en la Facultad.

La última fase consistiría en echar números de gasto anual y proponer
alternativas (+ formación y asistencia) en la línea de los informes de
irontec.

ntx

2017-06-15 4:05 GMT+02:00 Unai Martinez <[email protected]>:

> > @natxo:
>> > Quería contaros que en la Facultad, en colaboración con la gente de
>> Reciclanet, vamos a hacer una especie de inventario del software que se
>> solicita, se paga y luego relamente se utiliza. Para después poder plantear
>> alternativas libres si es que es posible. Mayoritariamente en temas de
>> edición de vídeo, audio, maquetación y manipulación de imágenes.
>>
>
> Son de 2009, dos informes hechos por irontec para la UPV/EHU que merecen
> una lectura:
>
> http://ehux.ehu.es/Estudio_comparativo_UPV-EHU_aplicaciones_educativas_
> GNULinux.pdf
> http://ehux.ehu.es/Estudio_comparativo_UPV-EHU_aplicaciones_corporativas_
> GNULinux.pdf
>
> En las áreas que comentas, aparecen gimp, krita, scribus, blender...
> aunque falta la edición de audio.
>
> No sé si el grupo de trabajo que colaboró con el Gobierno Vasco en 2009
> tendrá algún otro documento similar que pueda ser de utilidad:
>
> http://softwarelibre.deusto.es/patxi-lopez-me-defrauda/
> http://softwarelibre.deusto.es/patxi-lopez-me-asombra/
>
> > @joserra:
>> > Hace casi un año solicité por escrito a la Vicegerente del Área de
>> Tecnologías de la Información y Comunicaciones la información sobre el
>> gasto en programas informáticos a nivel de toda la EHU-UPV.
>> > Me la facilitaron amablemente y es la que tenéis en la tabla siguiente
>> y en el archivo adjunto.
>>
>
> Sin dudar de la veracidad de los datos aportados, la tabla es, al menos,
> incompleta. Concretamente, entre Jul14 y Ene15 se intercambiaron varios
> mensajes en esta lista a propósito de un gasto indicado en la documentación
> del Consejo de Gobierno del 5 de junio de 2014:
>
> P.N. 49 Lote \2014 Contratación de la Licencia Corporativa de ORACLE en la
>> UPV/EHU 24/04/2014 323.966,94
>> Adjudicatario: OFICINA DE COOPERACIÓN UNIVERSITARIA, S.A.
>>
>
> http://list.ehu.eus/pipermail/itsas/2014-July/thread.html
> http://list.ehu.eus/pipermail/itsas/2015-January/thread.html
>
> Nótese que el gasto total indicado en la tabla que te remitieron es de
> 269k, por lo que aparentemente se refleja menos de la mitad del gaso real.
>
> Por otro lado, hay software que se utiliza para docencia en mi centro y no
> está reflejado. Podría estar incluido en 'diverso software', pero me
> sorprende que se refleje Labview explícitamente y no Matlab.
>
> No quiero que se malinterprete el tono. Estoy muy de acuerdo con tu
> mensaje. Sólo pongo sobre la mesa información complementaria.
>
> > @Pablo:
>> > Por mi parte he hecho todo lo posible para pedir la reducción en la
>> dependencia de Matlab y dar la docencia con SciLab y Octave en el nuevo
>> grado de Automoción en Ingeniería de Vitoria-Gasteiz, pero la respuesta es
>> "Es lo que usan y piden las empresas" por lo que incluso en Primero vamos a
>> gastar licencias de Matlab pagadas con Infraestructura Docente.
>>
>
> Como mencionas SciLab entiendo que necesitais un alternativa (Xcos) a
> Simulink y no sólo a Matlab, ¿es así? Lo digo porque yo utilizo mucho
> Matlab, y por lo general puedo utilizar los mismos scripts en octave sin
> mayor problema. Salvo, claro está, toolboxes específicas.
>
> Quiero decir, si queremos que el alumnado aprenda los fundamentos teóricos
> sobre los que estamos trabajando, es 'gratis' que conozcan dos frontend. Si
> tienen que conocer la estética de Mathworks, que lo hagan en clase, y que
> en casa puedan utilizar octave. En principio dedicarán tanto tiempo al tema
> en clase como en casa, por lo que en el peor de los casos serán 'bilingües'.
>
> Por supuesto, no es la solución ideal. Pero sirve para que el primer
> impulso no sea que el docente 'se olvide' un DVD con 9GB de instalador y un
> crack, que casualmente vaya pasando de mano en mano. Al margen de la
> licencia, desde un prisma pragmático, quisiera hacer hincapié en el tamaño.
> Sólo el runtime de matlab son 2GB. Una instalación completa supera los
> 10GB. Octave son 380MB.
>
> Adicionalmente, si algo 'bueno' tiene Windows 10, es que docker funciona
> de forma 'nativa'. Por lo tanto, con octave puedes crear una imagen a
> medida para tu asignatura. Esto quiere decir que cualquier alumno con
> GNU/Linux o Windows 10 puede ejecutar el entorno de trabajo que tú quieras
> con 'docker run -it pabloehu/octave bash'. Por entorno de trabajo me
> refiero a un sistema base (debian, fedora o alpine), octave, los
> plugins/toolbox/paquetes que quieras, las variables de entorno que
> consideres adecuadas, y cualquier contenido adicional (ejercicios?). Si
> todo es libre, puedes colgarlo en el hub de docker.
>
> Con esto, la perspectiva del alumno o alumna es diferente: instala un
> programa gratuito y ejecuta un solo comando que descarga menos de medio
> giga; o consigue de alguna manera 10 gigas de instalador, y el crack, y lo
> instalas lo crackea, lo configura, descarga los ejercicios, cambia la path
> y otras variables... No sólo eso, sino que en el primer caso estará
> utilizando exactamente el mismo entorno que tú, por lo que los
> errores/resultados serán reproducibles.
>
> Igual 'lo que usan y piden las empresas' ahora, no es lo que usarán y
> pedirán cuando estos alumnos acaben la carrera dentro de cinco años.
>
> He asumido que conoces docker porque has mencionado la charla sobre
> traefik. Sino es así, son 'máquinas virtuales' con un tamaño mínimo de 4MB.
> En esos 4MB hay un GNU/Linux 'completo'. Siendo así, en lugar de instalar
> muchos programas en una sola 'máquina', cada aplicación tiene la suya
> propia. Esto no es una 'forma de hablar': RancherOS es un sistema en el que
> todo son contenedores docker. Yo no llego a tanto, pero desde hace un año
> no instalo ninguna aplicación de más de 100MB, utilizo contenedores. Así,
> me da igual el host (Win10, Arch, Fedora, Ubuntu...) mi entorno siempre es
> el mismo (preferiblemente alpine, sino debian). Nótese que 'mi entorno'
> incluye los temas, iconos y demás personalizaciones. La diferencia
> principal con respecto a una máquina virtual real (además del rendimiento),
> es que el servidor de las X está en el host, por lo que en caso de arrancar
> varias aplicaciones gráficas, estas ventanas aparecen en el mismo
> escritorio.
>
> Realmente me parece transgresora la posibilidad de tener un repositorio de
> contenedores docker por asignatura, para que el alumnado pueda 'cambiar' de
> un entorno a otro sin tener que 'ensuciar' su sistema. No obstante, no he
> oído a ningún profesor hablar de docker. Os agradecería vuestra opinión.
> Entiendo que puede ser por que es una tecnología nueva todavía, porque en
> Windows 7 y en macOS depende de VirtualBox, porque no es 'seguro' para
> producción... pero me gustaría tener impresiones de primera mano.
>
> > @juanan:
> > Es una idea muy buena. Realmente creo que esta iniciativa debería
> extenderse no sólo a la facultad de BBAA sino a todas las posibles dentro
> de la EHU.
>
> A cuenta de unos presupuestos, en 2013 desde el Consejo de Estudiantes de
> la EUITI-BI se solicitó la inclusión de un punto en la junta de escuela
> para tratar el tema. La 'excusa' era que el alumnado no puede utilizar
> parte del software ni en casa ni en las salas de ordenadores del centro. La
> reclamación del alumnado era, en principio, tener acceso al mismo de forma
> legal. La lógica era: no hay dinero para comprar licencias para todo el
> mundo, luego hay que plantearse alternativas más asequibles, y por lo tanto
> se valorará el software libre. Evidentemente es un contexto artificial,
> porque en la práctica impera el anticopyright (aunque requiera mayor
> esfuerzo).
>
> El tiro por la culata. El resultado del 'debate' fue que 'no se sabe' cómo
> se pagan las licencias. Por lo visto algunas son de la uni, otras del
> centro, otras las pagan los departamentos... Y claro, algunos departamentos
> no quieren que las licencias que '''han pagado ellos''' las utilicen en
> asignaturas de otros departamentos, or lo que 'no lo cuentan'. Y los
> departamentos no son departamentos, sino secciones. Y además las versiones.
> Y los ordenadores, que no son iguales, entonces las imágenes de disco no
> son compatibles... Mucho ruido, ninguna conclusión. Finalmente, derivó en
> la posibilidad de abrir algunos laboratorios durante ciertas horas fuera
> del horario lectivo para que el alumnado que quisiera pudiera hacer uso de
> los mismos. Notése que es la solución que menos esfuerzo requiere por todas
> las partes, salvo el alumnado que está obligado a acudir a la escuela en
> los horarios estipulados (muy de este siglo).
>
> Se realizó una reunión con los técnicos de laboratorio y los del centro,
> ya que se consideró la forma más eficiente de conocer el software utilizado
> en realidad, y analizar a partir de ahí qué laboratorios abrir. A esa
> reunión no recuerdo si alguien llevó algún listado, pero nunca llego a
> hacerse acta de la misma, ni tuvo continuidad alguna.
>
> Sinceramente, creo que es desidia, y pocas ganas de cambiar. Un ejemplo
> estúpido pero ilustrativo es que estuve cinco años sugiriendo que se
> mencione (y a poder ser se utilice) Code::Blocks (multiplataforma) en lugar
> de devcpp (sólo Win) en introducción a la programación. No sé si en los
> grados ha cambiado el contenido, pero todavía los estudiantes no saben qué
> es codeblocks cuando les hablo de ello (buscar codeblocks arduino).
>
> Por contra, cuando he impartido cursos (Medicina Leioa, la FISS y en el
> aulario de Gasteiz) mi experiencia ha sido muy positiva y la sensación ha
> sido que los servicios informáticos, el volcado de imágenes, etc. estaba
> muy procedimentado y automatizado. Choca frontalmente con la sensación al
> 'pedir cuentas'. ¿Sucede sólo con el software de pago? Me gustaría saber si
> todo este caos es sólo aparente y en realidad está registrado, al menos a
> nivel contable. O si en las cuentas también hay posibilidad de
> fragmentación.
>
> Natxo, ¿cuál es la estrategia que estáis siguiendo para obtener la
> información?
>
> En general, tengo la misma percepción que Pablo, y creo que hasta que no
> haya órdenes directas habrá centros en los que será imposible obtener la
> información. Ya no hablo de reticencias al SL. Sino reticencias a 'auditar'
> el gasto real en software que se hace en la uni.
>
> Otra cuestión 'curiosa' es que tengo varias IPs de la uni con servidores
> de licencias flexlm. A través del cliente lmutil, se ve la disponibilidad
> de decenas de instancias. Nunca he visto que se utilicen más de las dos o
> tres que yo estaba ocupando. Lo curioso es que a través de la VPN puedo
> utilizar esos servidores desde cualquier equipo. Lo que me lleva a pensar
> que cualquiera en la comunidad universitaria puede utilizarlos conociendo
> la IP, ¿es así?
>
> _______________________________________________
> ITSAS mailing list
> [email protected]
> http://list.ehu.eus/mailman/listinfo/itsas
>
>
_______________________________________________
ITSAS mailing list
[email protected]
http://list.ehu.eus/mailman/listinfo/itsas

Responder a