Tirate un correo por vara! Deber�as ponerlo en una p�gina. Pienso agregarle un poco de varas al correo.
El software en desarrollo. Como todos sabemos, el software que usamos es desarrollado en su mayor parte por grupos de voluntarios, unos trabajn en el kernel, otros trabajan en X, otros en mplayer, etc. Normalmente, los desarrolladores de estos programas, son personas que usan el software, y le van agregando cosas y arreglando pulgas. Ellos son los que prueba si todo sirve y si algo no sirve, pues lo tratan de arreglar. El problema con esto es que ellos no pueden probar el software en diferentes situaciones y por lo tanto existen grupos de usuarios que hacen el beta testing, bajan el c�digo en desarrollo y lo usan, a ver como se comporta. Para que un programa sea estable, tiene que haber sido probado bastante, y normalmente, como el p�blico en general se espera a las versiones estables para probarlo, se crea un c�rculo vicioso. Se ocupa una version "estable" para que la gente lo pruebe, pero el software no va a ser estable hasta que la gente lo pruebe. Esto es lo que lleva a que muchas veces las versiones ".0" no sean completamente estables. La gente que "sabe el truquillo", se espera porlomenos a un par de versiones m�s. Parte de lo que Alvaro est� diciendo es que por que no prueban el kernel, que ahora esta en etapa de desarrollo, para que cuando salga en version "estable", de verdad sea estable. Me parece una sugerencia buena, sin embargo, no es algo que todos pueden hacer. Primero que nada, _no_ prueben kernels en desarrollo en servidores o m�quinas "de producci�n". Tampoco lo hagan en alguna m�quian que de fijo van a necesitar en las pr�ximas horas. Por ejemplo, en sus PCs dos d�as antes de que tengan que entregar la copia final de la tesis. El problema principal con probar el kernel, es que un kernel "beta" puede borrar _todo_ lo que tienen en la compu, _todo_. Yo he corrido el kernel en desarrollo y nunca he tenido problemas mayores. Si, si me he volado uno que otro filesystem en alg�n momento, pero la verada eso fue culpa m�a porque estaba corriendo c�digo mio, pero bueno. Si uno lee de vez en cuando la lista del kernel o se da una vuelta por #kernelnewbie en irc.freenode.net todo normalmente va bien. Otra razon por la cual no es necesario correr el kernel nuevo, es porque a veces las partes internas del kernel no nos afectan tanto y no notaremos mucha diferencia, otras si. En este caso, el kernel 2.5 parece tener bastantes ventajas sobre el 2.4, aunque tampoco van a ser cosas supermaravillosas. Supongo que depende de los casos individuales. Bueno, ya dije lo que ten�a que decir del kernel, ahora me toca apoyar la idea en general. Creo que la gente en general deber�a tenerle menos miedo a probar el software beta. Ok, me podr�n decir que acabo de decir que no todos deber�an hacerlo, pero me estaba refiriendo al kernel. El kernel tiene el problema de poderse volar todo. En cuanto a otro software, eso normalmente no sucede. Ejemplos: el cvs de winex, corre muchos juegos de windows, el cvs/pre de mplayer toca DVDs, ripea DVDs, permite ver canal 6,7 (en .asx), pronto podr� tocar quicktime, etc. Y eso que ni mencionar de los betas de los programas que les gustan las varillas gr�ficas, como los que usan gtk2, o qt3, transparencias y alpha blending. Todas esas varas gr�ficas tuanis pasan siempre primero en los betas, y normalmente no son de mucho riesgo. Les recomiendo que si les gusta un software, que usen el beta de vez en cuando. No tienen que saber programar, muchas veces con solo el reporte o el dump es suficiente. Un ejemplo es mozilla, donde pueden bajar el beta o el nightly build directamente del site y el solito manda los reportes de pulgas/crashes. Adem�s, casi todos los programas as� pueden coexistir de alguna manera u otra con otras versiones, por lo que no hay que desacerse de mozilla 1.1 para probar mozilla-nov-21-2002. Otro punto que quiero tocar, si es que todav�a siguen leyendo este correo, es el de hacer documentaci�n. Linux/Software libre/Open source como un todo es una gr�n comunidad y es el sentido de comunidad que nos ha sacado adelante muchas veces. Es el hecho de que construimos del conocimiento y trabajo de los demas. Es eso que decimos muchas veces, RTFM, LHPM, o busc� en google. Eso es porque alguien tuvo un problema, escribi� como resolverlo o sus experiencias, y despu�s google vino y lo indexo. Yo quiero sugerir es que si tiene alg�n problema que resuleven, o algo que les parece que podr�a serle �til a otra gente, por favor escribanlo en alg�na p�gina. Si no tienen donde escribirlo, estoy seguro que alguien de la lista lo podr� poner el alg�n lado. Si no saben HTML, pues en texto, etc. Muchas veces lo mejor no es reescribir un documento ya existente, aunque si es una buena traducci�n, nunca cae mal (si mal no me acuerdo, mplayer ocupa traduccir la documentaci�n al espa�ol). Me parece que muchas veces lo mejor es hacer documentos que se relacionan al grupo. En el caso de este grupo, podr�a ser documentaci�n de Linux en Costa Rica, por ejemplo, donde comprar Linux en CR si uno quiere, los servidores/mirrors en CR, como se configura los cablemodems, como se hace si se tiene uno de esos cablemodem + modem normal, etc. Tal vez como se configura Evolution para racsa o ese tipo de cosas. Bueno creo que me di a entender de alguna manera u otra y ya los entretuve por mucho rato, adem�s tengo hambre y voy a ir a comer algo. Buenas noches/tardes/d�as. Nacho P.S. A veces se me olvida que no todos pueden estar enterados, pero muchos de nosotros pasamos en irc chateando. Si se les antoja, #gulcr en irc.freenode.net. Ven un howto de como connectarse a ese canal ser�a bueno, y que incluya instrucciones para windows/mIRC adem�s, por eso de que tengan preguntas pero est�n en una m�quina windows. -- In theory, practice and theory are the same, but in practice they are different EEE8 08C9 FBAE B471 9691 CE7A 1CC8 D3DE B31E 10AB GPG Public Key: http://www.igso.net/isolis.gpg
msg11637/pgp00000.pgp
Description: PGP signature
