Re: Temario del curso de Novatos

Hola,

On Sun, Mar 21, 2004 at 09:58:37PM -0600, Jeffrey Esquivel wrote:

 > Primero, no exista tal fobia por el ambiente gráfico, es simplemente
 > que se debe empezar por algún lado, y se decidió que ese lado es la
 > línea de comandos, si te fijás en el orden del temario, eventualmente
 > se llega a lo que es el ambiente gráfico. Pero al final, la idea es
 > que alguien que ha llevado el curso pueda trabajar ya sea en la CLI o
 > en un GUI.

 Y yo sostengo que con el estado actual de los ambientes de escritorio
 en Linux, esa no es la mejor forma de hacer las cosas.  Pongámolo de
 otra forma: a) ¿cuál es el fin del curso? b) ¿cuál es el fin de enseñar
 a moverse en CLI?

 Yo digo que las repuestas son:

    a) Introducir a la gente a Linux, de forma que puedan _ser
       productivos_ en ese ambiente

    b) Tener a alguien que sea capaz de resolver problemas y realizar
       labores de administración eficientemente (e.g., con el mínimo de
       herramientas que con seguridad están disponibles en un Linux
       arbitrario)

 Esas respuestas no están en conflicto la una con la otra, pero tampoco
 implican la una a la otra, y en particular a) no implica b).  Dado que
 la respuesta que interesa es la de a), no veo la necesidad de b).

 > Bueno, espero que esto no se convierta en una guerra de licencias
 > (para la cual no tengo interés ni tiempo). En el grupo hay personas
 > que se identifican tanto con la filosofía del OSS

 Pico no califica ni siquiera para OSS.  El código fuente de pico está
 disponible y se puede ver, y pará de contar.

 > partiendo de esto, sería igual de válida entonces el comentario de
 > alguien que diga que le molesta que el grupo no promueva activamente
 > el uso de software que es de código abierto, pero no es código libre
 > (aún cuando este no sea el caso, más sobre esto después).

 Ta'bien.  Eso también me molesta.  ¿Contento?

 (el tema ya lo habíamos discutido una vez y nunca llegamos a nada más
 claro que "alguna gente prefiere estar en paz con tanta otra gente como
 sea posible")

 > Con respecto a lo de alternativas mejores, tendrías que definir bien
 > porqué es mejor _para el curso_ otro editor

 Porque:

    a) Hay cosas que se parecen más a lo que la gente ya conoce

    b) Hay cosas que es probable encontrar en una máquina arbitraria y
       pico no es una de esas

 Desde mi punto de vista, b) pesa más que a), pero escogé lo que más te
 guste.

 > (y ya te dije cuales son los parámetros que se toman en cuenta:
 > fácilidad de enseñanza

 Definí entonces que es fácil de enseñar y que no.  Yo creo que "vi" es
 fácil de enseñar:

    Hay dos "modos": insertado y comandos

    En el modo de insertado se puede insertar texto.  Con variantes
    modernas de "vi" se pueden usar las teclas "backspace" y "delete"
    como uno está acostumbrado.

    En el modo de comandos se pueden digitar comandos, por ejemplo ":w"
    para escribir el archivo actual al disco duro.

    Al comenzar a editar un archivo se entra en modo de comandos.  Para
    entrar al modo de insertado se puede presionar "i".  Para volver al
    modo de comandos, se presiona "Esc".

    En el modo de comandos se puede mover el cursor por el archivo
    utilizando las flechas del cursor, o con h (izquierda), j (abajo), k
    (arriba), l (derecha).

    Para grabar un archivo se usa ":w" y se puede indicar el nombre del
    archivo que se desea escribir ":w archivo"

    Para abrir un archivo nuevo se puede usar ":e archivo"

    Para salir se usa ":q".  Si no se quiere grabar el archivo se puede
    uasr ":q!"

 Y ya.  Usaste 10 minutos.  Usá "vim" y te ahorrás las cosas que
 confunden a la mayoría de la gente cuando comienzan a usar "vi".

 > que se pueda utilizar para las labores básicas del curso

 vi

 El problema con "gedit", por ejemplo, es:

 $ sudo gedit /etc/X11/XF86Config-4

 vs.

 $ sudo -s
 $ vim /etc/X11/XF86Config-4

 "sudo comando" vs. "sudo -s" puede ser confuso para más de uno.

 > y que parcialize lo menos posible a los estudiantes hacia una
 > determinada forma de editar texto.

 ¡Bah!  Sin importar lo que usés vas a a) emitir una opinión y b)
 realizar una recomendación (o te enfrentás a la pregunta: ¿por qué me
 enseñan esto si no me lo están recomendando?)

 > Claro, pero nosotros nos encargaríamos de que durante el curso pico
 > esté disponible para los estudiantes.

 En tanto que vi está disponible en todas partes sin hacer nada.  De
 hecho, ¿cómo hacés para atornillar pico encima de knoppix?

 > Hmm, yo lo veo más bien como un proceso. Algo así como que a un bebé
 > se le enseña a caminar y luego él aprende a correr.

 GUI -> CLI

 > El problema es que a vos no te asusta, pero a los novatos si

 ¿Es eso tu opinión o una exposición de los hechos?  ¿Por qué los ha de
 asustar algo que no conocen?  vi asusta a la gente que ha tenido algo
 que ver con vi, pero que no ha tenido a nadie al lado para preguntar
 (algunas cosas tienen la tendencia de tirarte a vi sin avisarte)

 > A) En la forma como está estructurado cronologicamente el curso, es
 > necesario aprender a utilizar un editor de texto antes de que se vea
 > como utilizar el sistema gráfico.

 El ambiente gráfico ya va a estar corriendo.  Lo _simple_ en ese caso
 es top-down.  Comenzás por el nivel de abstración mayor, y caminás
 hacia los niveles menores conforme el curso lo demande.

 > B) Si el estudiante aprende a usar un editor de consola, puede usarlo
 > aún en un sistema gráfico, el caso contrario no se cumple.

 Enseñá vim y te ahorrás ese problema.

 > El sentido es que simplemente se tenía que empezar el curso en algún
 > lado, y lo que nos pareció más conveniente era iniciar en la línea de
 > comandos.

 ¿Por qué?

 > Si vos crees que una cronología distinta sería más beneficiosa, por
 > favor hacénoslo saber

 Ver arriba.

 > (o mejor aún, ayudanos con el planeamiento del curso :-).

 Todavía estoy tratando de entender cuánto tiempo "libre" tengo y para
 qué lo tengo que usar, pero no descarto que ese sea el caso.

 > Ahora, me parece que todo lo dicho en este hilo aplica igual de bien
 > a nano que a pico (aún cuando no sean copias idénticas).

 Con nano puedo considerarme contento.  Sigo pensando que otra cosa con
 una "sección transversal" más grande es mejor, pero eso es otro cuento.

 > Supongo que "gráfico" se refiere a que corre sobre un sistema
 > gráfico

 Si, que tiene iconitos y usa el mouse y esas cosas...

 > Si en serio crees que un editor gráfico es lo mejor, la solución
 > sería reordenar el temario del curso.

 Es más simple para la gente, a menos que me digás que alguno de los
 objetivos del curso hace que CLI -> GUI tenga más sentido.

 > >  > A) Gastar más tiempo del necesario en la enseñanza del editor de
 > >  > texto (debería ser parecido a lo que la gente está acostumbrada
 > >  > a utilizar, para evitar trabas durante el curso debido a que la
 > >  > gente no se logra movilizar con el editor).
 > > 
 > >  ¿Vos querés decir un editor con File -> Open, File -> Save, File ->
 > >  Print?
 > 
 > Quiero decir un editor que pueda abrir (o crear) un archivo, editarlo
 > y luego guardarlo, sin que eso implique dedicar dos horas a explicar
 > cómo y por qué el editor hace esas tareas como las hace.

 o sea, algo como que la gente ya conoce, con File -> Open, File ->
 Save, File -> Print

 > ¿En serio vos crees que ellos se van a sentir tan cómodos con pico
 > (de ahora en adelante, me referiré a nano en vez de pico) como para
 > quedarse con él?

 conozco a más de una persona que todavía usa "editor" porque eso fue lo
 que aprendieron hace años.  Y me levantaron una bronca cuando "editor"
 pasó de ser "ae" a "joe".

 > ¿Y en caso de que fuera así, no sería algo bueno que utilizen algo
 > con lo que se sienten cómodos?

 Yo me siento mal mandando a la gente a la calle con una mano atada a la
 espalda y la otra también.  Tenés un _montón_ de cosas que le pueden
 hacer la vida más simple a la gente: hasta el primitivo syntax
 highlight de gedit es mejor que nada.  Hasta xedit tiene eso por
 default.  (si, si, yo sé que luego de veinte vueltas con el archivo de
 configuración nano también tiene)

 > ¿Podrías elaborar un poco más acá? Tal vez estoy siendo muy
 > tradicionalista, pero el modelo que me resulta más lógico es el que
 > se ve en el temario actual, sin embargo me gustaría entender el
 > modelo inverso.

 Porque es lo más pacido a lo que ya conocen, por lo cual es lo más
 simple de aprender.  Ok, ok, probablemente tienen que desaprender
 cosas, pero los asusta menos y por lo tanto los motiva más.

 > En ese caso, si consideramos Metacity + GNOME, la razón por la que no
 > se decidió utilizarlo es porque un manejador de ventanas tiene más
 > cosas en común con otros manejadores de ventanas que un ambiente de
 > escritorio.  Por lo que si se enseñan los conceptos generales de un
 > WM, ya los estudiantes se pueden adaptar a los demás, y un ambiente
 > de escritorio es lo mismo, pero con unas cuantas utilidades extra
 > encima.

 ¿Cuáles serían esos?

 Los manejadores de ventanas como vos y yo los conocemos son
 degeneraciones del concepto original.  Window Maker es más que un
 manejador de ventanas (Window Maker tiene código para cambiar el fondo
 del escritorio, y para arrancar programas y otras cosas que no tienen
 nada que ver con manejar ventanas).  "twm" es una manejador de
 ventanas.  Y realmente no hace mucho más de lo que metacity hace.

 > La idea no es los alumnos se queden con Window Maker, sino que
 > aprendan los conceptos básicos sobre el funcionamiento de un
 > manejador de ventanas y sus componentes más comunes, para que puedan
 > usar esa información con el WM, o DE que prefieran.

 Ve... los conceptos "nuevos" (con respecto a Windows) son los
 escritorios virtuales.  Y tal vez "focus follows mouse" y esas cosas.
 Y monadas como "enrollar" las ventanas.  Y esas con básicamente las
 cosas que los WM "comparten".  Y eso es Metacity.

-- 
Marcelo

-- 
Desuscripción: escriba a [email protected], tema
'unsubscribe' 
Problemas a: [email protected]. http://www.linux.or.cr/listas