Re: Temario del curso de Novatos

Buenas,

El Sun, Mar 21, 2004 at 10:22:05AM -0600, Marcelo E. Magallon escribió:
> Hola,
> 
>  luego de haber leído las tres respuestas que me han enviado, tengo más
>  dudas.  Iván dice que 'el curso va a ser orientado a personas con
>  "cierta experiencia" en computadoras (mínimo que sepan instalar
>  winbugs' y que se habló que se quiere enseñar a la gente la filosofía
>  de Unix.  Vale.  Pero no entiendo como eso lleva a tenerle fobia a un
>  ambiente gráfico.

Bueno, yo leí tus tres respuestas, espero poder aclarar la mayor parte
(si no es que toda) la confusión.

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.

> On Sat, Mar 20, 2004 at 12:00:11PM -0600, Jeffrey Esquivel wrote:

[...]

>  A mi en realidad me vale un rábano si la gente usa o no usa pico.  En
>  tanto no se metan conmigo, los masoquistas pueden seguir flagelándose
>  todo lo que quieran.

No veo a que viene este comentario.

>  El punto es otro, en realidad dos cosas ortogonales:
> 
>     * pico no es libre.  Me _molesta_ que el grupo promueva activamente
>       el uso de software que no es libre cuando existen alternativas
>       libres que son mejores

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, como con la del FS;
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).

Con respecto a lo de alternativas mejores, tendrías que definir bien
porqué es mejor _para el curso_ otro editor, pues yo sigo sin verlo
claramente (y ya te dije cuales son los parámetros que se toman en
cuenta: fácilidad de enseñanza, que se pueda utilizar para las
labores básicas del curso y que parcialize lo menos posible a los
estudiantes hacia una determinada forma de editar texto.

>     * pico es "raro", en sentido de abundancia

Claro, pero nosotros nos encargaríamos de que durante el curso pico esté
disponible para los estudiantes. Es bueno recalcar que el curso no trata
sobre editores de texto o sobre un editor de texto, se enseña a utilizar
uno de manera muy "tenue" solo porque es necesario para llevar a cabo
otras actividades que si son parte del curso; o sea, el editor de texto
es solo una herramienta para el curso, y no es el fin.

>  Si pico es inflexible o no, en realidad me vale, pero me disgusta un
>  poco que me estés diciendo que se enseña algo que luego la gente
>  descarte.

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. No me parece a mí que
sea algo malo que la gente luego descarte pico por una alternativa mejor,
pero aprender una alternativa mejor es algo que ellos tendran que hacer
por si mísmos, nosotros solo damos las bases.

>  Editores libres y que se encuentran en una instalación normal de Unix
>  son ed, vi y emacs.  A ed lo descartamos con el argumento de masoquismo
>  innecesario.  A emacs lo descartamos con "no es lo que uno usa paRa
>  editar un archivo de dos líneas".  Queda vi.  El problema con vi es que
>  es modal y eso por algún motivo asusta a la gente.  Durás dos minutos
>  explicando los modos (insert, command, visual, y el resto los ignorás),
>  pero por alguna razón eso asusta.

El problema es que a vos no te asusta, pero a los novatos si (no estoy
discutiendo si está bien que eso pase o no, simplemente es lo que
sucede), y como este curso es para ellos, pues hay que tomar los
factores que los afectan a ellos en cuenta.

>  Entonces de pronto tenemos cosas como gedit y kedit que son la cosa más
>  parecida a lo que la gente ya conoce (que es el argumento que vos estás
>  usando).  Y yo me atrevo a decir que entre las dos cosas, gedit gana.
>  Es suficientemente simple como para que no sea neceasario explicarlo,
>  pero suficientemente extensible, configurable y flexible como para que
>  la gente que lo aprende tenga algo útil en sus manos para después.

En esto estoy de acuerdo con vos, sin embargo, siguen existiendo dos
limitantes:

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.

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.

>  > Para ese momento en el curso todavía no se ha llegado a utilizar X.
> 
>  ¿Cuál es el sentido de eso?  No, en serio, ¿por qué?

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. Si vos crees que una cronología distinta sería más
beneficiosa, por favor hacénoslo saber (o mejor aún, ayudanos con el
planeamiento del curso :-).

>  > Este es otro punto a favor de pico, nano es (IIRC), una copia
>  > idéntica de pico, entonces si se les enseña pico, igual van a poder
>  > utilizar nano.
> 
>  No, ese es un punto a favor de nano.  Si alguien quiere ir a meterse en
>  una máquina donde no está nano, puede usar pico si es que está.  Y no,
>  nano no es una copia idéntica de pico.

Bueno, acá es el "después" que había comentado hace un rato. Acabo de
revisar y me di cuenta que pico nisiquiera entra en la categoría de OSS,
por lo que si es mala idea utilizarlo en un curso oficial del grupo. Por
lo tanto, creo que lo conveniente sería utilizar nano en vez de pico.
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).

>  > Nunca lo he oído mencionar. ¿Qué ventajas ofrece sobre pico/nano,
>  > desde la perspectiva del curso?
> 
>  Que es un editor gráfico, con iconitos y menús, modeless, y se comporta
>  en general como notepad.  Y está instalado donde esté instaldo vim, que
>  en una distribución moderna de Linux es casi en cualquier parte.

Supongo que "gráfico" se refiere a que corre sobre un sistema gráfico,
por lo que tiene el mismo problema que los demás editores gráficos. Si
en serio crees que un editor gráfico es lo mejor, la solución sería
reordenar el temario del curso.

>  > 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.

>  > B) El efecto de "uso lo que uso porque eso me enseñaron". La idea con
>  > pico/nano es que la gente luego pueda "migrar" hacia un editor con el
>  > que se sientan más a gusto, y de esa manera, influenciar lo menos
>  > posible su opinión hacia un editor dado.
> 
>  O sea, se van a quedar con pico... si les vas a dar algo con lo cual
>  quedarse, dales algo con lo que valga la pena quedarse.

¿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? ¿Y en caso de que fuera así, no sería algo bueno que utilizen
algo con lo que se sienten cómodos? Por último, no creo que sea nuestra
tarea decidir qué es lo que vale la pena para ellos (y este párrafo va
escrito con muchísimo menos agrevisidad que con la que se lee :-).

>  > Acá, igual, todavía no se ha entrado a lo que es el sistema gráfico.
> 
>  Otra vez, ¿cuál es la fobia?  Enseñá conceptos, no comandos.  Es

No lo había pensado así, pero definitivamente eso es lo que hay que
hacer. Ahora bien, Junto con los conceptos es necesario enseñar un poco
de práctica (puesto que no solo queremos que los alumnos sepan como
suceden las cosas, sino que también sepan llevarlas a cabo :-).

Ahora, ¿por qué enseñar las heramientas de consola y no las
herramientas gráficas? Pues porque, como vos dijiste en otro correo, se
deben enseñar las herramientas estándar, y en la mayoría de (si no es
que en todos) los casos, las utilidades de la línea de comandos son las
más estándar.

>  > Se cree que es más importante que los estudiantes del curso aprendan
>  > como se hacen las cosas de la manera más genérica posible;
> 
>  Decime que se quiere que los estudiantes aprendan a trabajar con una
>  línea de comandos, pero ahorrate los eufemismos.

No veo eufemismos, es más, me parece que estoy diciendo lo mismo que
vos, que se deben enseñar las herramientas estándar (yo dije genéricas).
El hecho de que las herramientas estándar sean las herramientas de la
línea de comandos es una casualidad y no algo premeditado :-).

>  Yo realmente pienso que con el estado actual de los ambientes de
>  escritorio en Linux la dirección correcta es de GUI a CLI y no a la
>  inversa.

¿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.

>  Si lo que estás tratando de evitar es la discusión GNOME vs KDE,
>  entonces decí eso.  Sin usar ni lo uno ni lo otro, yo admito que desde
>  un punto de vista de _usabilidad_ GNOME es la mejor opción.

No estoy tratando de evitar esa discución, en todo caso, también como
opinión personal prefiero GNOME (pero eso tiene más que ver con el hecho
de que QT me da pesadillas en las noches que con otra cosa).

>  > si luego desean utilizar alguna otra herramienta que les facilite las
>  > tareas
> 
>  "facilite".  Por qué partís del supuesto que un GUI es más fácil de
>  usar.

Yo no me refería en específico a un GUI, sino a cualquier herramiente
que facilite las tareas y que no sea la herramienta estándar para hacer
las cosas (y digo "facilitar" porque dudo que alguien quiere utilizar
una herramienta que le dificulte las cosas).

>  Es más _accesible_ a la mayoría de usuarios.  Pero tratá de
>  hacer cosas "complicadas" con un GUI.  _Podés_ diseñar una interfase
>  para que eso sea _posible_, pero no quiere decir que sea fácil.

De acuerdo.

>  > pues no hay problema, pero igual tendrán la capacidad de entender el
>  > cómo y (esperemos) el porqué.
> 
>  Claro, y eso no excluye para nada usar un GUI.

No, pero de nuevo, lo más probable es que el GUI no sea la forma
estándar de hacer las cosas.

>  ¿Metacity "standalone"?  ¿Qué querés decir?  ¿Sin GNOME?  Eso no
>  existe.  Metacity ni siquiera tiene un menú.  Metacity tiene ventanas y
>  desktops, y ese es el fin de la historia.

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.

>  Metacity se puede usar con KDE (o para el caso, con cualquier cosa que
>  hable EWMH).

Mismo razonamiento que el párrafo anterior.

>  > La decisión de usar windowmaker se basó en que tiene una interfaz
>  > suficientemente bonita, no tiene un look tipo Windows, y comparte
>  > muchas características con los demás WMs populares.
> 
>  ¿Me estás hablando de las decoraciones de las ventanas?

En realidad ahí estaba hablando un poco de paja, desde mi opinión
personal, window maker se ve horrible, pero las otras personas presentes
en la reunión dijeron que a ellos les parecía bonito, y eso fue lo que
yo repetí.

>  Window Maker implementa un ambiente de escritorio en alguna medida, y
>  si bien desde un punto de visa de usabilidad es un buen ambiente, es un
>  ambiente poco usual.  Y lamentablemente el desarrollo de Window Maker
>  está estancado.

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.

-- 
Jeffrey Esquivel

"All your questions can be answered, if that is what you want. But once
you learn your answers you can never unlearn them."
                                     --Neil Gaiman, "American Gods"

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