Archivo

Archive for the ‘UIB’ Category

Software libre y GNU/Linux en la UIB

febrero 13, 2015 7 comentarios

1993

Me encargan que de la asignatura de sistemas operativas en la UIB. No teníamos ningún Unix accesible a los usuarios, tampoco teníamos PCs para instalar el novedoso GNU/Linux, todo era Macintosh. Encuentro MacMinix, un port de Minix a Mac mínimo, se ejecutaba como programa normal de Mac que abría tres consolas de shell.

Lo pruebo en los Macs del aula informática (unos 70 ordenadores) de nuestro edificio. No funcionaba el teclado español y se colgaba cada pocos segundos. Desesperación, la asignatura comenzaba en febrero de 1994, me quedaban pocos meses y no tenía una plataforma “seria” para darla.

Decido que no hay otra solución que intentar arreglar esos problemas. Pido un portátil Mac prestado al Dept. (un MacBook, me tomaba 45 minutos compilar el kernel) y me pasé unos tres meses modificando el núcleo del Minix. Descubro que el problema del teclado estaba ocasionado porque las tablas de E/S de caracteres del  Minix eran de 7 bits y se necesitaban 8 para el teclado español. Modifico todas esas funciones para trabajar con 8 bits, logro que funcione correctamente. Luego detecto que el culpable de los cuelgues era por la pila de red de Apple Talk, los ordenadores estaban conectados a una que cubría toda la universidad y claramente tenía muchas race conditions no solucionadas. Deshabilito todas esas funciones, el problema se soluciona, no tendríamos red pero tampoco era necesaria.

Así doy dos cursos, 93-94 y 94-95.

Leer más…

Categorías:UIB Etiquetas: , ,

La incapacidad de solucionar errores de nuestros estudiantes de informática

junio 6, 2013 47 comentarios

Uno de las asignaturas que enseño en la UIB es “Sistemas Operativos 2″, del segundo semestre del segundo curso de la ingeniería en informática. En esta asignatura enseñamos fundamentalmente gestión de memoria, de E/S y sistemas de ficheros.

La práctica consiste en el desarrollo en C desde cero de un sistema de ficheros basado en i-nodos. Quizás es la práctica más difícil y extensa (aunque son poco más de 2.000 líneas de código en C) que se hayan encontrado, pero tampoco es tan complicada. De hecho uno de los objetivos de la práctica es desmitificar la complejidad (de los conceptos fundamentales, el demonio está en los detalles) de los sistemas de ficheros. Pero nos encontramos con muchos problemas:

  • No saben relacionar lo aprendido en estructuras de datos. Por ejemplo, a esta alturas ya han visto árboles y el recorrido iterativo y recursivo en ellos, sin embargo les cuesta mucho hacerlo para la traducción de bloques lógicos a físicos (que es básicamente recorrer árboles de uno, dos o tres niveles).
  • Falta de práctica de programación. No están acostumbrados a desarrollar programas que sean mayores a un par de cientos de líneas, cuesta mucho que muestren código que “huela” bien, ni siquiera son capaces de sangrarlo correctamente, son incapaces de hacer el diseño del programa.
  • Desconocimiento de C, del compilador, y de su relación con la arquitectura de los ordenadores.

Para que estos problemas no bloqueen todo el desarrollo, el diseño se lo pasamos hecho al nivel de funciones con un programa semanal de qué funciones deben implementar y cómo probarlas. Además les pasamos el código de las funciones de recorrido de las estructuras más complejas.

Aún minimizando los problemas anteriores, el otro gran problema que tienen -y creo que el peor- es la incapacidad para analizar y corregir los errores del código. Aún en las partes más sencillas y obvias, es típico el diálogo:

– Profesor, el programa me falla.

– ¿Dónde está el fallo?

– No lo sé, da un segmentation fault.

– Pero ¿en qué función?.

– No lo sé, lo hace apenas lo ejecutamos.

– Pero ¿no has puesto ni print-efes para saber por donde se cuelga?

– ¿Dónde los pongo?

Es muy fustrante, les pego unos rapapolvos importantes. El ejemplo que doy a continuación es un caso real, del lunes pasado.

Como parte de las pruebas del sistema de fichero, tienen que desarrollar unos programas concurrentes que escriban una estructura de datos en posiciones aleatorias de un fichero. Luego otro programa tiene que recorrer secuencialmente ese fichero y detectar las escrituras, la forma fundamental es verificar que uno de los campos de la estructura sea igual al PID del proceso que escribió en ese fichero.

Un par de alumnos tenían problemas, después un un diálogo muy similar al anterior les indiqué que antes que les mire el código debían indicarme exactamente el sitio donde les daba problemas. Me mostraron el siguiente código:

struct record rec, rec2;
char pathname[256];
...
my_read(pathname, &rec, position, sizeof(rec));
while (rec.pid != pid) {
    position += sizeof(rec);
    my_read(pathname, &rec, position, sizeof(rec));
}
printf("Final del bucle\n");

Me dijeron:

– El problema es que nunca sale del bucle.

Es decir, según ellos, que nunca se cumplía la condición de que rec.pid sea igual a pid. Les indiqué el primer problema, el código no verificaba que se haya llegado al fin del fichero (es decir, que el resultado de my_read() sea mayor que cero). Si no salía de ese bucle, el my_read() debería estar generando errores y muy raro que no salga ningún error. En un momento de la conversación, y después de varios minutos verificando que el fichero estaba bien (el my_read() funciona correctamente), les digo:

– Esto no puede ser, debe haber otro error ¿habéis verificado que el nombre del fichero en pathname sea correcto?

– Ahora que lo dices, en una de las pruebas cuando habilitamos la impresión de errores nos dio “la ruta no existe”.

– ¡¡¡¡#$@!!!

Les pedí que impriman el valor de la variable pathname, y en vez de un /dir1/dir2/datos.dat salía /dir1dir2/datos.dat, todo por olvidare de una “/” en el sprintf() para el pathname.

Es decir, el problema no estaba ni el bucle, sino unas cuantas líneas más arriba de él, pero no fueron capaces de darse cuenta de ello. A los pocos minutos los mismos alumnos me dicen:

– Ahora nos da segmentation fault después del bucle, en estas instrucciones, y no sabemos por qué.

Voy a mirar esas líneas:

rec2.pid = rec.pid;
rec2.x = rec.x;
rec2.y = rec.y;
rec2.z = rec.z
...
/* más código complejo */

Era obvio que esas instrucciones, asignación de estructuras idénticas (y sin punteros involucrados) no podían generar un segmentation fault (además de la optimización es obvia y con menos código: memcpy(&rec2, &rec, sizeof(rec)).

– El error no está allí, ¿por qué decís que son esas líneas?

– Porque lo último que imprime es la salida del bucle.

– Pero ¿estáis seguro que es allí y no en el código de más abajo? ¿habéis puesto un printf para verificar?

– No.

:facepalm: (y rapapolvos varios)

Estos casos son los que nos encontramos cada día en el laboratorio y tutorías, ayer mismo me pasó otro. Un grupo me dice:

– Profesor, el programa nos falla, ¿lo puede mirar?

– Pero ¿cuál es el fallo?

– No sabemos, nos da stack smashing detected

– Eso es porque trabajáis con algún puntero local y os estáis saliendo de los límites, por eso el error en la pila. ¿En qué función dónde da eso?

– Hummmm… creemos que en esta, pero aquí no hay nada raro.

Miro la función y detecto el error inmediatamente, les indico que es el “sprintf”.

char pathname[11];
sprintf(pathname, "%s/%s/pruebas.dat", dir1, dir2);

– Pero ¿por qué el error? si está bien.

– Porque la longitud del string generado es superior a 11.

– Pero si “pruebas.dat” es menor que 11.

:facepalm: (y enésima explicación de strings, array de caracteres, y rapapolvos varios).

Este segundo ejemplo muestra el desinterés por aprender bien las herramientas que usan (el lenguaje C es muy sencillo), pero también hay una incapacidad de asumir que se cometen errores y de interpretar y analizar el código. Aunque es una técnica muy habitual en programación, son incapaces de reducir el espacio del problema para analizar el código (tan fácil como poner print-efes donde toca). A pesar de las horas que llevan de programación en más de un año y medio de carrera, no tienen siquiera la iniciativa de poner mensajes para así poder llegar exactamente a la instrucción que les está provocando el error. En pocas palabras, carecen de las habilidades básicas para hacer debugs de programas, que a su vez es una habilidad básica de los programadores.

No sé qué estamos haciendo mal en la universidad para que no tengan un dominio básico de debugging. O si el problema lo arrastran de instituto, por ejemplo, no tener iniciativa para resolver por sí solos los problemas, esperan -y casi exigen- que el profesor tenga capacidad adivinatorias superiores que les evite pensar a ellos. O que no hayan tomado conciencia que cualquier profesional necesita conocer las herramientas con las que trabaja.

Después de dos años de una carrera de ingeniería informática no podemos permitir que tengan esas carencias fundamentales, en temas tan básicos. Tenemos problemas de calado en la forma en que los formamos. O quizás deberíamos empezar a tomar no tan en serio lo del “seguimiento personal a los alumnos” del Plan Bolonia y dejar que se apañen solos, que parece que lo seguimos tratando como a niños desvalidos intelectualmente.

En cualquier caso, ya me desahogué, es frustrante. Y perdón a mis alumnos por los rapapolvos, pero es que es muy frustrante (y mejor que se los dé yo, antes que su primer jefecillo ;) ).

Relacionado (gracias): Why I never give straight answers.

Categorías:ciencia, desarrollo, UIB Etiquetas: ,

“Lo que demanda el mercado”, y el conservadurismo en la universidad

marzo 27, 2013 29 comentarios

El lunes fui a Dublín para unas entrevistas en Google. Apenas llegué al hotel abrí el siguiente email, Amazon buscando desesperadamente (ya lo hacen en grupos abiertos, no sólo por recruiters) ingenieros expertos en GNU/Linux para Dublín. Sumado a que justamente estaba por ir a Google, que también exige (o da mucha importancia) a los conocimientos de Linux, inmediatamente me acordé los años de luchas y problemas en la universidad para poder enseñar sobre GNU/Linux.

Empecé a dar las asignaturas de sistemas operativos en el curso 1993-1994, los primeros dos con Minix (sólo teníamos Macs Performa, y adapté el kernel MacMinix para que funcione en ellas). Luego quitaron los Mac, pusieron PCs con Windows NT y no me dejaron instalar Linux. Tuve que dar un curso con las prácticas con Cygwin sobre esos Windows, o vía telnet al VAX VMS con los alumnos. El primero pasable -aunque doloroso-, el segundo infumable. El C del VMS era muy poco compatible en temas de llamadas de sistemas, y cada clase de viernes a la tarde se colgaba, o fallaba con tantos usuarios.

Leer más…

Categorías:UIB, universidad Etiquetas:

Universidades, presupuestos, crisis y rankings

agosto 14, 2012 13 comentarios

Hace un momento leí el artículo de The Economist sobre los recortes presupuestarios en las universidades públicas californianas: One state, two systems. As public universities struggle, some private ones thrive. Comentan que la Universidad de Stanford (privada, sin fines de lucro) consiguió donaciones de más de 5.000 millones de euros (estoy pasando de dólares a euros, aproximados) en cinco años. Eso da una media de 1.000 millones al año (aunque en la Wikipedia dan números algo más bajos). La matrícula anual de alumnos tiempo completo es de 30.000 euros ( $35.000). Son 15.000 alumnos en total (en licenciaturas y posgrados), lo que suma unos 450 millones al año.

Leer más…

Categorías:UIB, universidad Etiquetas: , , ,

Boloña, integridad de la academia y las fuerzas del mercado

octubre 26, 2008 21 comentarios

Cuando se inició el proceso de Bologna yo era muy optimista –y así lo expresé muchas veces en mi blog, sobre todo discutiendo con alumnos que estaban radicalmente en contra– ya que pensaba serviría de catalizador para la revisión y mejora de los planes actuales que en general son un batiburrilo bastante difuso de ciencias de la computación, sistemas e ingeniría del software (algunas veces con mayor influencia de tecnologías de la información).

Pero con el tiempo –los programas básicos se están acabando–, y la experiencia personal propia veo que en muchos casos no es así y se están haciendo verdaderos “atentados académicos”.

Resulta que todo este proceso ya estaba descripto con bastante certeza por un documento de la ACM del 2005. Aunque en este caso no se trata de definir una carrera totalmente nueva que exija facultades o escuelas independientes, muchos de los vicios están igualmente presentes.

Vale la pena echarle una lectura cuidadosa y “apasionada” a la sección Academic Integrity and Market Forces (en la página 44, 50 del documento PDF) del Computing Curricula 2005: The Overview Report.

Las fuerzas del mercado impactan en los programas académicos de diferentes formas […] Por ejemplo, en los últimos años se han hecho populares varias formas de certificación. El término certificación se aplica a un amplio espectro de ofertas que varían significativamente. Algunas certificaciones son específicas de algunos proveedores (Microsoft, Cisco, etc.). Otras certificaciones están disponibles a través de organizaciones profesionales (IEEE-CS, BCS [1]), y otras organizaciones (ICCP). En algunas de sus formas las certificaciones compiten con los programas académicas. Está claro que la certificación es una tendencia importante. Como con cualquier cosa, algunas certificaciones son respetadas, otras son controvertidas. Cuando instituciones que otorgan títulos oficiales se asocian con programas de proveedores, la integridad académica se convierte en un tema importante a tener en cuenta. El lector debería ser consciente que tales asociaciones son una invitación a la controversia acerca de la ética e integridad académica [2]. […]

El hecho que aprezcan nuevas titulaciones para solucionar necesidades sociales muestra que el dinamismo de nuestra sociedad no se diluye en la academia. Las nuevas disciplinas informáticas dan la “prueba por ejemplo” que la academia puede y evolucionará y dará respuestas a las necesidades sociales. Lastimosamente la misma emergencia de nuevos programas de grado también son fuente de ejemplos de lo que se puede hacer mal cuando las iniciativas académicas están dirigidas por intereses políticos, imperativos de la administración y la propaganda exagerada de los medios más que por el reconocimiento que hace falta innovaciones sustantivas para dar respuestas a las preocupaciones sociales.

Afortunadamente es fácil distinguir entre esos dos fenómenos. Cuando analizamos la emergencia de nuevos títulos de grados vemos ejemplo de programas de alta y baja calidad.

  • Cuando observamos a programas de calidad vemos programas que fueron dirigidos y desarrollados desde dentro. Las facultades y administradores locales contribuyen porque han mirado más allá de las fronteras de las áreas convencionales de las áreas asignaturas-temas, han reconocido que sus estudiantes y comunidad necesitan algo diferente, y han innovado para resolver lo que ellos ven como un problema legítimo y sustantivo. La facultad de esos programas tienden a indenficarse como la facultad de una nueva disciplina, a pesar del hecho que su origen reside invariablemente en una disciplina diferente. Los miembros de la facultad valoran a sus estudiantes, reconoce como legítimas las necesidades de los estudiantes y la comunidad, y hacen un gran esfuerzo para mantener a sus alumnos en los altos estándares apropiado para  la disciplina.
  • Cuando observamos a los programas de baja calidad vemos programas dirigidos desde afuera. Un escenario involucra un proceso desde arriba hacia abajo donde alguien con poder decreta que deben ser creados, tal vez en un tiempo arbitrario. La facultad y los administradores contribuyen porque se les ha dicho que lo hagan. No ven un valor positivo intrínseco en la iniciativa, no cren que resuelva necesidades legítimas de los estudiantes o la comunidad. Así, sólo innovan para proveer una apariencia superficial de innovación, a menudo creando nuevos programas que no son nada más que una colección de cursos existentes en otros departamentos. Los miembros de facultades en estos programas tienden a identificarse como miembros de la anterior, la disciplina más establecida de donde vinieron.

La lección importante aquí es que los buenos programas no emergen sólo sobre la base de directivas desde arriba. Mientras que este tipo de directivas pueden ser un catalizador necesario, los buenos programas requieren cuidados y ayudas de la facultad que puede y ve oportunidades de realizar un trabajo potencialmente importante y de legitimidad inherente. Mientras que las presiones administrativas pueden hacer que la creación de programas que cubran las demandas sean una opción atractiva, la integridad académica requiere más que sólo respuestas superficiales a las fuerzas del mercado. Es crítico que la creación de nuevos programas de informática sean tratado como un esfuerzo de desarrollo sustantivo, llevado a cabo por personas preocupadas y apoyadas con los recursos suficientes para permitir el desarrolo de programas sustanciales y coherentes.

[1] Aunque algunos –por ignorancia, engañados o por intereses corporativistas– confunden una y otra vez la acreditación BCS (especialmente la Chartered IT Professional) con “regulación” aunque se les haya aclarado el tema (varias veces): La BSC es una asociacion no gubernamental sin fines de lucro (charity) como ATI, ACM o IEEE, que tiene programas de examinaciones y acreditaciones.

[2] El dilema ético es aún mayor cuando se trata de universidades públicas. Como ha pasado con las certificaciones de Cisco en mi universidad, muy pocos profesores de los que he hablado siquiera se habían planteado el tema ético-académico, tampoco es que salían muy convencidos cuando les planteaba el tema. Lo sospecho por las caras de pasmados de “¿qué dice ahora este coñazo de tío?” :-)

Disclaimer y mea-culpa: Desde el principio me mantuve al márgen de toda discusión formal y pertenencia a comisiones. No sólo que no soporto las comisiones, comités y largas reuniones improductivas, desde mi [erróneo] punto de vista pensaba que el sentido común se impondría finalmente sin necesidad de largas y duras discusiones –que suelen acabar con descalificaciones personales–. Además pensaba que en algunas asignaturas nucleares maduras –como las de sistemas operativos– era tan simple como respetar y adaptar el curriculum específico de la ACM que es el ya está incorporado en mis programas de la UIB (OS/1 a OS/8 para dos cuatrimestrales), que no es un gran esfuerzo porque éstas ya están incluidas en cualquier libro de texto razonablemente bueno. Ahora contra reloj estoy acabando de elaborar el documento de propuestas para modificar los descriptores de unas pocas asignaturas. Era también mi responsabilidad hacer que la presión “desde abajo” –profesores y alumnos– contrarreste a la “desde arriba” –administración española y europea, fuerzas del mercado–, como así también dedicarle tiempo y cuidados al parto del nuevo programa.

Categorías:ética, ciencia, UIB Etiquetas: ,

Demo en clase de Google App Engine

mayo 27, 2008 22 comentarios

Mañana en clase de AdmSO (optativa) haré una demonstración de cómo se desarrolla para Google App Engine (GAE). Es una especie de “cierre” de la clase anterior, hice una demo de Django. En esta demo desarrollaremos exactamente lo mismo, pero para ejecutarlo sobre GAE

Preparar la demo de Django me tomó más de 5 horas. La de GAE bastante menos, pero es que los templates son los mismos y el modelo de datos casi igual, salvo el tipo de la “propiedades”.

No sé si hago bien.

Aunque técnicamente está muy bien, el lenguaje y el SDK son libres, al fin y al cabo es dedicar 45 min – 1 hora de clase en universidad pública para mostrar la tecnología de una empresa. Ya, todos los hacen, algunos peor –como esas clases con software privativo obligatorio, o los mata neuronas-ingenieriles como el Dreamweaver y similares–, pero tampoco me consuela.

PS: Es a las 15:30 en el A5. No hace falta que nadie me pida permiso para entrar si quiere verlo, claro que se puede.

Categorías:ética, UIB, universidad Etiquetas: , ,

“Blue suites” en la UIB

marzo 31, 2008 55 comentarios

informáticos de traje

La foto de arriba (otras mejores)  es de estudiantes de ingeniería de sistemas poniéndose el traje para entrar a clase. La profesora de esa asignatura les había “provocado” diciendo que no tienen la imagen para ir a una entrevista de trabajo. La respuesta muy adecuada además de cachonda.

De todas formas sigo sin creerme del todo que a estas alturas todavía haya empresas que busquen buenos ingenieros y que el traje o la vestimenta sea algo que tenga la mínima consideración (supongo que sólo se refería a la ropa, porque el aula no olía mal :-) ). Pero debe ser que sí.

Es más. Lo leí hace unos días en algún blogperdón, no lo recuerdo… sigo buscando entre mis RSS gracias #4–, pero decía algo que estaba completamente de acuerdo, era más o menos así:

Si eres bueno no necesitas entrevistas ni preparar tu curriculum vitae. Muchas empresas ignoran los CVs –casi lo consideran spam–, pero si eres bueno tus trabajos y experiencia ya son conocidos.

Creo que sí, que no hay mejor carta de presentación para un informático que tener un proyecto “en línea”, o código liberado. Como les dije a los chicos de EyeOS hace unos meses:

eyeos

Independiente de que podáis o no ganar dinero con el EyeOS, tampoco debéis preocuparos, sóis demasiados jóvenes y gracias al proyecto –y si seguís en la misma línea– no tendréis problemas para conseguir buenos trabajos durante el resto de vuestras vidas [*].

[*] Ninguno de ellos tiene título de ingeniero en informática –al menos todavía no–, el mayor programador ni siquiera estudia informática y en temas de seguridad informática me puede dar una paliza del copón, a pesar de tener menos de la mitad de mi edad y menor experiencia. Otro que nos puede dar una clase de cómo dar conferencias informativas pero muy divertida. Y un tercero puede dar una paliza a muchos diseñadores con título. ¿Estaré haciendo daño a la profesión o a la humanidad danto ánimos a tantos “intrusos”? :roll:

PD: Saqué la foto rápidamente con mi teléfono sin baterías y a punto de apagarse. Había otra gente con buenas cámaras, si alguien sabe dónde la subieron, que por favor nos las indiquen.

Categorías:pijadas, UIB Etiquetas: ,
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 552 seguidores