-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2009-07-17 a las 15:27 -0500, Shinji Ikari escribió:

...

...

Estas son evaluaciones y comparaciones de las cuatro distribuciones más conocidas, en sus versiones en desarrollo. Por tanto pueden cambiar en el corto plazo.

Pues no sé si resulta conveniente hacer las pruebas con las versiones de desarrollo. Cambian los paquetes cada pocas horas :-P

O.O? es algo en lo que no me fije. El estado de las distros, es diferente un alfa, beta y un RC. =/ Algo a tomar en cuenta. Creo que el benchmark tiene más interés para los desarrolladores. Ya saben la tendencia de cual está mejor o a algún MBA que quiere mover intereses para alguna distro. =/

Como han comentado en Factory, la fase de desarrollo de cada distro es distinta, y es difícilmente comparable (unos están empezando y otros terminando). Fedora, por ejemplo, activa "debug=y" en todas las partes del kernel, lo cual lo hace más lento (se quita en la versión final, claro). En /. ya comentaron que estos estudios de phoronix son realmente poco fiables. No se fían porque no se conoce realmente su metodología. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpg/rIACgkQtTMYHG2NR9VV+gCfT1WacgheCk7rVNKGOXGLx4Nx DJ8AoIG7K+WmRifiaL9tlHsw/PQYCgiv =kYKC -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-18 a las 11:04 +0200, Camaleón escribió:

El 2009-07-18 a las 00:43 +0200, Carlos E. R. escribió:

(...)

...

En /. ya comentaron que estos estudios de phoronix son realmente poco fiables. No se fían porque no se conoce realmente su metodología.

Bueno, la metodología parece clara: usan su Phoronix Test Suite (*) e indican el tipo de componentes sobre los que han hechos las pruebas.

En slashdot no se fian de phoronix. http://linux.slashdot.org/story/09/06/30/1543246/EXT4-Btrfs-NILFS2-Performan... Someone did file a ticket [sqlite.org] at SQLite but from the comments in there you can see that what Phoronix did is not reproducible. ... Here's a post [slashdot.org] linking to some other posts discussing some problems with the Phoronix benchmarking methodology. The same issues seem to be pointed out every time they get a benchmark article published on Slashdot. http://slashdot.org/comments.pl?sid=1068299&cid=26173779 Java Performance On Ubuntu Vs. Windows Vista Various problems with the Phoronix test methodology have been noted before [slashdot.org] and before that [slashdot.org]. Without going over the same stuff, here are some potential questions about this benchmarking: * Where is the statistical analysis of these results - ok, you ran a test once and it was 30% slower. Is this reproducible? What is the variance? Is there any statistical difference between openjdk/sun java? * Why is the Java minor version different? Do you see the same results if the same minor version is used? * As mentioned in the previous discussions, exactly why is Windows slower on the file encryption task - it should be either limited by disk throughput, or by CPU throughput, so observing a 40% drop in performance attributed to the underlying I/O handling of the operating system is somewhat surprising; are you sure the test methodology is sound here, and if so, how do you explain the results? * Are these results applicable to both 32 and 64 bit distributions and JDKs? * How do you know that the 2D benchmark performance on Linux is attributable to poor graphics drivers? Why not run the test on another PC and then swap out graphics cards (hence eliminating all other factors) and report on the results? There are a lot of questions that this benchmarking should have answered, and a lot of assumptions made that could potentially be invalid. http://apple.slashdot.org/article.pl?sid=08/11/06/1315243&from=rss Ubuntu 8.10 vs. Mac OS X 10.5.5 Benchmarks Also worth mentioning are the collection of posts from the last thread that convincingly argued various problems with the Phoronix Benchmarks. Example 1 [slashdot.org] Example 2 [slashdot.org] Example 3 [slashdot.org] Speed tests are good, let's make sure we're doing them right http://apple.slashdot.org/article.pl?sid=08/11/06/1315243&from=rss Is Ubuntu Getting Slower? I can see several problems with the testing methodology as is: * The test suite itself: The Phoronix test suite runs on PHP. That in itself is a problem-- the slowdowns measured could most likely be *because* of differences in the distributed PHP runtimes. You can't just say "hey, version Y of distro X is slower than version Z! LOLZ" because, WTF. You're pretty much also running different versions of the *test suite* itself (since you have to consider the runtime as part of the test suite). Unless you remove that dependency, then sorry, you can't measure things reliably. Which brings me to my second point... * What exactly are they testing? The whole distro? The compiler (since most of the whole of each distro version is compiled with different versions of GCC)? The kernel? If they're testing the released kernel, then they should run static binaries that *test* the above, comparing kernel differences. If they're testing the compiler, then they should build the *same* compiled code on each version and run said compiled code (which is pretty much what I gather they're doing). If they're testing the utilities and apps that came with the distro, then they should have shell scripts and other tools (which run on a single runtime, not depending on the runtime(s) that came with the distro version). Because if you don't, you have no fucking clue what you're testing. Honestly, I was unimpressed by the benchmarks. I happen to do performance benchmarking as part of my job, and I can tell you, you have to eliminate all the variables first -- isolate things to be able to say "X is slow". If you rely on a PHP runtime, use *exactly* the same PHP runtime for all your testing; otherwise, you'll get misleading results.

Lo que yo creo que es de dudosa utilidad es el resultado de probar las versiones de desarrollo, sea el producto que sea, y menos a modo de comparativa.

Pues no, claro.

Supongo que los de Phoronix querían "hincarle el diente" a los kernels de la rama 2.6.3x.

Me parece que esa gente vive de hacer comparativas. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkphnhIACgkQtTMYHG2NR9XVFACdFSswSKEoO+2mlcvZSucG4Faj iroAniAom1oWea508lFfNhwfZScyTnpF =V04b -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-18 a las 12:16 +0200, Camaleón escribió:

...

En slashdot no se fian de phoronix.

http://linux.slashdot.org/story/09/06/30/1543246/EXT4-Btrfs-NILFS2-Performan...

Huy, ya estás cogiendo la parte por el todo :-P

Querrás decir que hay "algunos usuarios" que "no se fían" de "una de las pruebas concretas" que realizaron sobre los sistemas de archivos >:-)

No, varios usuarios, en varias comparativas distintas. Y los argumentos que dan me parecen, en fin, al menos dignos de considerar.

La metodología de la prueba que comentamos en este hilo es bastante clara.

Todavía no he visto la discusión en slashdot respecto a esta prueba. Cuando salga y la pongan a caldo, pues ya veremos. :-P

...

Me parece que esa gente vive de hacer comparativas.

De comparativas veraces.

Pues varios de los que escriben en /. dicen que no, y algunos dicen ser profesionales de eso. Claro que el propio /. es discutible. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkphp7IACgkQtTMYHG2NR9WUCwCfa2O7l3CIDF0/rbG0hbKmjxS5 +VAAn0k66TembmGhD3/tZJ4mJKRUcytw =EN2q -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-18 a las 13:01 +0200, Camaleón escribió:

...

No, varios usuarios, en varias comparativas distintas. Y los argumentos que dan me parecen, en fin, al menos dignos de considerar.

Eso es hablar en abstracto. El enlace que has puesto de slashdot hace referencia a una prueba determinada y a unos datos concretos. Y las pruebas de rendimiento de sistemas de archivos no son precisamente baladíes.

He puesto varios enlaces. Uno era respecto a la velocidad de Ubuntu y otro de la de Java.

La utilidad de los resultados puede ser discutible, pero la metodología no. Es abierta, los tests son abiertos y los resultados que ponen son los que han obtenido. Gusten o no, los resultados son resultados. Luego hay que interpretarlos.

Pues discuten los resultados precisamente, porque no se fían del método.

Mira, en la wikipedía no ponen nada mal a esa batería de tests que tienen:

http://en.wikipedia.org/wiki/Phoronix_Test_Suite

Jo, jo, otros también discuten la validez de la wikipedia >:-P

Como dice el refranero: "Por un perro que maté, mataperros me llamaron"

Yo no lo se, sólo digo que algunos lo discuten. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkphsGoACgkQtTMYHG2NR9VNswCeKxYhoOan4viOQsDuUZUWKB1/ 2VIAnAthR9YwjyNWGMvGSzdFqbuApsfv =CzCI -----END PGP SIGNATURE-----

El 18 de julio de 2009 08:46, Camaleón escribió:

El 2009-07-18 a las 13:22 +0200, Carlos E. R. escribió:

...

El 2009-07-18 a las 13:01 +0200, Camaleón escribió:

...

...

No, varios usuarios, en varias comparativas distintas. Y los argumentos que dan me parecen, en fin, al menos dignos de considerar.

Eso es hablar en abstracto. El enlace que has puesto de slashdot hace referencia a una prueba determinada y a unos datos concretos. Y las pruebas de rendimiento de sistemas de archivos no son precisamente baladíes.

He puesto varios enlaces. Uno era respecto a la velocidad de Ubuntu y otro de la de Java.

Donde se puede ver que se ponen a discutir entre ellos mismos:

http://developers.slashdot.org/article.pl?sid=08/12/19/151229

Es decir, no saben qué es mejor o qué es peor. Son sólo comentarios sobre los resultados.

...

...

La utilidad de los resultados puede ser discutible, pero la metodología no. Es abierta, los tests son abiertos y los resultados que ponen son los que han obtenido. Gusten o no, los resultados son resultados. Luego hay que interpretarlos.

Pues discuten los resultados precisamente, porque no se fían del método.

Pues que propongan ellos alguno mejor, que hablar y comentar es muy sencillo pero hacer las cosas es muy distinto >:-)

...

...

Mira, en la wikipedía no ponen nada mal a esa batería de tests que tienen:

http://en.wikipedia.org/wiki/Phoronix_Test_Suite

Jo, jo, otros también discuten la validez de la wikipedia >:-P

Pues los comentarios de "/." creo que ni siquiera entran en la categoría necesaria para ser "susceptibles de evaluación de calidad" >;-)

Nadie dice que los tests de Phoronix sean perfectos y fiables al 100%. Vamos, que son como todos, hay que cogerlos con pinzas.

Acaso hay algun becnchmark que sea perfecto y fiable al 100%? Una curiosidad: For OpenSuSE some of the key packages included the Linux 2.6.30 kernel, GNOME 2.26.2, X Server 1.6.1, xf86-video-radeon 6.12.2, Mesa 7.4.4, GCC 4.4, and used an EXT4 file-system. Se me dio por googlear con xf86-video-radeon 6.12.2, para ver de que se trata, y me encuentro con esto (relacionado con un hilo anterior): http://www.x.org/wiki/radeon Donde puede llerse que han unificado el "viejo" Radeon con el nuevo HD en el mismo driver: radeon Driver for ATI/AMD Radeon based video chips, everything from Radeon 7000 to Radeon HD 4890 series. Part of xf86-video-ati, ie. also known as the ”ati” driver. License: MIT Latest News * 17 Apr 2009: AMD releases initial code branches for 3D support on R6xx/R7xx (see more below) Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Esto nos lleva al Principio de Incertidumbre de Heisenberg, teoría del caos,

Yo diría que el principio de Incertidumbre se aleja de lo que en física llamamos caos.... :P -- Nicolás Guarín Zapata Ingeniería Física Medellín Colombia -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 20 de julio de 2009 02:36, Rafa Griman escribió:

Hola :)

On Sunday 19 July 2009 21:45:42 Nicolas Guarin wrote:

...

...

Esto nos lleva al Principio de Incertidumbre de Heisenberg, teor�a del caos,

Yo dir�a que el principio de Incertidumbre se aleja de lo que en f�sica llamamos caos....  :P

Puede que me haya explicado mal 0:) No quería decir que el Principio de Incertidumbre y la teoría del caos estuviesen relacionadas o fuesen cercanos. Lo que quería decir es que ese tipo de teorías, principios, ... que nos dicen que no podemos realmente demostrar las cosas debido a su complejidad, a la interferencia que hacemos al medir las cosas, ... se deben tener en cuenta para darnos cuenta que, por mucho que nos empeñemos, los datos no tienen porqué ser "la verdad absoluta".

Un benchmark no es más que un estudio científico del comportamiento de un sistema (en este caso un ordenador/computador). Este estudio, igual que muchos otros estudios científicos se basa en la observación, repetición y estudio (estadístico) de los resultados. Para luego interpretarlo/entenderlo.

Digo esto porque muchas veces sale un benchmark y a la gente (en general) le gusta usarlo para "demostrar" algo y no necesariamente tiene porqué ser así.

Por eso digo que hay que tener en cuenta ciertas teorías o principios, para poder ver que no se repiten los resultados, por qué no se repiten, lo complejo que es un benchmark, ...

Espero haberme explicado.

Pero no veo diferencia en un benchmark y cualquier otra actividad humana, el principio de incertidumbre es algo inherente de la naturaleza no humano, por ende todo lo que hagamos pa a estar empapado de eso, sea benchmark de núcleos Linux o experimentos en un acelerador de partículas... -- Nicolás Guarín Zapata Ingeniería Física Medellín Colombia -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) On Monday 20 July 2009 19:16:22 Camaleón wrote:

El 2009-07-20 a las 10:39 -0500, Nicolas Guarin escribió:

...

El 20 de julio de 2009 02:36, Rafa Griman escribió:

...

...

...

Esto nos lleva al Principio de Incertidumbre de Heisenberg, teor�a del caos,

Yo dir�a que el principio de Incertidumbre se aleja de lo que en f�sica llamamos caos.... :P

Puede que me haya explicado mal 0:) No quería decir que el Principio de Incertidumbre y la teoría del caos estuviesen relacionadas o fuesen cercanos. Lo que quería decir es que ese tipo de teorías, principios, ... que nos dicen que no podemos realmente demostrar las cosas debido a su complejidad, a la interferencia que hacemos al medir las cosas, ... se deben tener en cuenta para darnos cuenta que, por mucho que nos empeñemos, los datos no tienen porqué ser "la verdad absoluta".

Un benchmark no es más que un estudio científico del comportamiento de un sistema (en este caso un ordenador/computador). Este estudio, igual que muchos otros estudios científicos se basa en la observación, repetición y estudio (estadístico) de los resultados. Para luego interpretarlo/entenderlo.

Digo esto porque muchas veces sale un benchmark y a la gente (en general) le gusta usarlo para "demostrar" algo y no necesariamente tiene porqué ser así.

Por eso digo que hay que tener en cuenta ciertas teorías o principios, para poder ver que no se repiten los resultados, por qué no se repiten, lo complejo que es un benchmark, ...

Espero haberme explicado.

Pero no veo diferencia en un benchmark y cualquier otra actividad humana, el principio de incertidumbre es algo inherente de la naturaleza no humano, por ende todo lo que hagamos pa a estar empapado de eso, sea benchmark de núcleos Linux o experimentos en un acelerador de partículas...

¿Acaso el Principio de Incertidumbre y la Teoría del Caos no forman parte de los sistemas complejos? Supongo que es a eso a lo que se refiere Rafa: termodinámica, sistemas dinámicos no lineales, entropía... todo eso que pone en la wikipedia cuando buscas por "Complejidad" y que viene a decir "grosso modo" que aún ejecutando una misma acción en las mismas condiciones se obtienen distintos resultados :-)

Básicamente sí. Un benchmark es un sistema muy complejo que no vale con ver que tal benchmark da 1.7 y otro da 100000000000000000000. Hay que entenderlo y no es fácil. ¿Que esto es inherente a cualquier sistema (complejo o no)? Sí. Nadie lo ha negado. Lo que pasa es que hago hincapié porque hay gente que parece no ver esto y se cree los benchmarks al pie de la letra, lo veo todos los días en mi trabajo y en Internet cuando sale un benchmark. Igual que veía a gente creerse al pie de la letra cualquier "paper" científico que salía (cuando me dedicaba al mundo del laboratorio), sin pararse a leerlo, estudiarlo y comprenderlo. A lo mejor para los que son (o han/hemos sido científicos) esto es de cajón/es lógico, pero tengamos en cuenta que no todo el mundo piensa así (incluso hay gente que sigue perteneciendo al mundo de la ciencia y se cree al pie de la letra todo). Con esto tampoco digo que los benchmarks son mentira o que los "papers" científicos son mentira. lo que digo es que hay que leerlos, estudiarlos y entenderlos. Esto significa que a lo mejor dicho benchmark o "paper" a nosotros nos trae sin cuidado (o no nos afecta) porque no es algo que usemos. Por poner un ejemplo, a efectos prácticos del uso informático que se hace en mi casa, un benchmark de Apache me trae sin cuidado porque no tengo Apache corriendo. Un benchmark de cifrado con pgp me trae sin cuidado. ¿Qué benchmarks me interesan a nivel casero? Ninguno. A otros sí les puede interesar porque les gusta mucho jugar o porque programan o porque se dedican a romper códigos o cualquier otra cosa. A estos interesados es a quien diría que tuvieran en cuenta el Ppio. de Incertidumbre, la Teoría del Caos, ... y que estudiasen el benchmark entendiendo lo qu eestán leyendo y teniendo en cuenta todo lo que rodea al benchmark. Otra cosa es si lo comparo con algo relacionado con mi trabajo. Me pueden interesar benchmarks de CPU (enteros y flotantes), rendimiento RAM<->CPU, benhcmarks de sistemas de almacenamiento, ... ¿Me interesan todos? Pues no. Por ejemplo, no me interesan benchmarks ext4 vs xfs en discos de 1 TB (típico benchmark que se ve en Internet) porque mis clientes tienen mucho más almacenamiento que eso. "Pero es extrapolable" estaréis diciendo. La verdad es que no ;) Igual que no es extrapolable el comportamiento de un aplicación corriendo sobre un quad-core y la misma aplicación corriendo sobre 128 cores. Si fuera filósofo habría dicho: "No te puedes bañar dos veces en el mismo río" (Heráclito de Efeso, si mal no recuerdo) Pero como no lo soy, hecho mano de teorías y ppios que he estudiado ;)

¿Cuál es (brevemente) esa diferencia a la que aludes, desde el punto de vista de la física, entre la incertidumbre y el caos?

Saludos,

Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

¿Acaso el Principio de Incertidumbre y la Teoría del Caos no forman parte de los sistemas complejos? Supongo que es a eso a lo que se refiere Rafa: termodinámica, sistemas dinámicos no lineales, entropía... todo eso que pone en la wikipedia cuando buscas por "Complejidad" y que viene a decir "grosso modo" que aún ejecutando una misma acción en las mismas condiciones se obtienen distintos resultados :-)

¿Cuál es (brevemente) esa diferencia a la que aludes, desde el punto de vista de la física, entre la incertidumbre y el caos?

No tiene nada que ver uno con otro. O no tienen nada que ver estrictamente hablando. A grosso modo: - el ppio de incertidumbre se refiere a que es imposible conocer con _absoluta_ precisión la posición y la velocidad (en realidad, es el producto de la velocidad y la masa- 'momento' ó 'momentum', no la velocidad por si misma) de un partícula en el mismo instante de tiempo. El producto de la precisión de ambas mediciones es un múltiplo estrictamente mayor de cero de la constante de Planck. No es una limitación de nuestro experimento, es una limitación que nos pone la Naturaleza encima de la mesa: Da igual cómo de bien diseñes un experimento para medir la posición y la velocidad de una partícula dada en el mismo instante de tiempo, la máxima precisión que vas a tener no va a ser menor que un número dado. El problema es que esta incertidumbre inherente a cualquier medida de estas magnitudes depende de la masa de lo que estemos observando; así, una partícula con una masa pequeña (átomos, electrones, cosas así de pequeñas) tiene una incertidumbre enorme para la precisión que requerimos. Sin embargo, algo de la masa de cualquier objeto macroscópico, tiene una incertidumbre muy muy muy pequeña. Realmente podemos saber la posición y la velocidad de la moneda de 1 € que tengo encima de la mesa con una precisión realmente fantástica (estricamente hablando no podemos conocerlo con una precisión absoluta, pero sí más allá de la precisión del aparato con el que realizo la medida). Así, a efectos prácticos, el principio de incertidumbre sólo afecta a objetos en la escala atómica y no tiene efectos reales en lo que podemos 'ver', cuerpos macroscópicos. Estas cosas del caos, dinámica no lineal, indeterminismo se refiere en cambio a otra cosa. Hay 'problemas' que se dicen que son lineales y queremos decir con esto que conocidas su posición y momento podemos conocer su posición y momento en cualquier instante del tiempo posterior (... y despreciando, para simplificar la compresión de las cosas, las fuerzas externas). Más aún: pequeñas variaciones en los valores de posición y momento de esa partícula producen sólo pequeñas desviaciones de su trayectoria y momento. En esto, es irrelevante si el problema aplica a cuerpos micro o macroscópicos. Sin embargo, hay problemas que llamamos 'no lineales', porque pequeñísimas variaciones en su poción o momento producen variaciones enormes en su posición o momento en cualquier instante del tiempo posterior a la medida. Son sistemas que decimos caóticos porque no somos capaces de predecir el comportamiento posterior de la partícula dadas unas condiciones iniciales conocidas. Ejemplos de estos sistemas hay muuuuuchos, muchísmos más de los que pensamos: - uno bonito que se puede buscar fácilmente por internet: Atractor de Lorentz. Googleando se puede ver lo que es: http://images.google.es/images?q=lorenz%20atractor&oe=utf-8&rls=org.mozilla:es-ES:official&client=firefox-a&um=1&ie=UTF-8&sa=N&hl=es&tab=wi Creo que así se puede entender bien. - la atmósfera: Hay una leyenda, desconozco si apócrifa o no, que dice que cuando se iniciaron las primeras predicciones computerizadas del tiempo, se tomaron una cantidad de medidas enormes, se metieron y un super ordenador y sacaron las cifras. Obviamente, como no se conocen todas las condiciones atmosféricas, sabían que el resultado no sería exacto, pero que algo se aproximarían. Así funcionaron un tiempo hasta que un día, alguien sacó la predicción del día siguiente, luego el super computador se apagó por algún motivo, reiniciaron, y retomaron los cálculos quedándose sólo con los _70_ primeros decimales. El resultado? La predicción resultó completamente distinta en este caso. ¿Cual es el efecto que tenían los decimales más allá de la posición 70? A la vista de los resultados... enorme. Hay quien comparó (tampoco sé si es apócrifo o no) los decimales eliminados con el efecto causado por el batir - o no batir - las alas de una mariposa. Inquieta pensar que nos gastamos una cantidad enorme de dinero en predecir el tiempo y una simple mariposa podría cambiar la predicción metereológica... no? (probablemente, la analogía de la mariposa sí sea apócrifa, los modelos metereológicos funcionan relativemente bien. Por cierto, esto me recuerda que hace años teníamos en la lsita un físico-metereólogo, alguien se acuerda??). - movimiento planetario: Nuestras matemáticas, aunque a algunos nos haya costado mucho aprobar, resultan bastante ineficaces para algunos problemas. En particular, sabemos resolver el movimiento de dos cuerpos unidos por la gravedad en el espacio (un objeto orbitando alrededor del otro). Esto significa que somos capaces de sacar ecuaciones de movimiento para las dos partículas. También somos capaces de resolver el problema de tres cuerpos, pero siempre que éstos se muevan en un mismo plano (si tienen movimientos 3D ya no sabemos resolverlo, hasta ahí llegan nuestras matemáticas). Y entonces, ¿somos capaces de calcular el movimiento de los planetas del sistema solar? Pues no, ni de casualidad. Tenemos un Sol, 8 ó 9 planetas (según si contamos a Plutón o no), algunos planetas tienen satélites, cinturones de asteroides, la nube de Oort... Y ni si quiera se mueven en el mismo plano (Plutón está inclinado con respecto al plano del resto de planetas). El caso es que por aproximaciones, se obtiene que el movimiento es caótico en el sentido físico de la palabra. En realidad, no hay nada que nos de la seguirdad de que la Tierra va a seguir orbitando alrededor del sol el resto de nuestras vidas. En realidad, cualquier perturbación, podría sacarla de su órbita y o bien hacernos caer al sol o hacernos desaparecer en la inmensidad del Universo para siempre. La perturbación que podría sacarnos de órbita es el típico ejemplo de que pequeñas variaciones en la posición o momento de un cuerpo, pueden producir variaciones enormes es posiciones futuras... he ahí el caos en su máxima expresión. A ver quien puede dormir esta noche sabiendo eso, je je XD Y en cuanto a los ordenadores: Son un caso curioso. Lo cierto es qeu están llenos de ejemplos de incertidumbre (no en vano son pura electrónica, que se refiere al comportamiento de los electrones y como partículas pequeñísimas que son están sujetos al principio de incertidumbre). Por ejemplo, no es posible calcular con total exactitud el movimiento y velocidad que va a tener cada electrón que se mueve en el procesardor, pero sin embargo, debido a la enorme cantidad de ellos que hay, somos capaces de calcular de forma muy determinista, el comportamiento macroscópico de estos con una precisión bastante buena. Así, somos capaces de usando algo muy indeterminista por definición, crear algo que se comporta de manera totalmente predecible en circunstancias conocidas. El problema de los computadores no es el principio de incertidumbre o la dinámica del caos. El problema son los programadores, estos seres que sí que son caóticos, no están bien gestionados, etc etc... Son ellos, y no la física, quienes introducen esas fantásticas variaciones del comportamiento dispar que presentan los programas... Dos puntos para el que se haya leído toda esta chapa. -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-20 a las 23:28 +0200, miguel gmail escribió: ...

Estas cosas del caos, dinámica no lineal, indeterminismo se refiere en cambio a otra cosa. Hay 'problemas' que se dicen que son lineales y queremos decir con esto que conocidas su posición y momento podemos conocer su posición y momento en cualquier instante del tiempo posterior (... y despreciando, para simplificar la compresión de las cosas, las fuerzas externas). Más aún: pequeñas variaciones en los valores de posición y momento de esa partícula producen sólo pequeñas desviaciones de su trayectoria y momento. En esto, es irrelevante si el problema aplica a cuerpos micro o macroscópicos. Sin embargo, hay problemas que llamamos 'no lineales', porque pequeñísimas variaciones en su poción o momento producen variaciones enormes en su posición o momento en cualquier instante del tiempo posterior a la medida. Son sistemas que decimos caóticos porque no somos capaces de predecir el comportamiento posterior de la partícula dadas unas condiciones iniciales conocidas.

En realidad, lo que ocurre al cambiar ligeramente las condiciones iniciales, es que la función de salida es similar al principio, durante un tiempo, y de repente cambia tremendamente, y de manera impredecible para el pequeño cambio de las condiciones iniciales. Se supone que si las condiciones iniciales son más parecidas (más decimales de precisión), la función sacara unos resultados parecidos durante más tiempo... Y eso es lo que explica que el tiempo se pueda predecir algo durante un tiempo pequeño, y luego resulta caótico. Pero ojo, que el caos se estudia en funciones matemáticas no lineales... no sólo en simulaciones de la realidad compleja. Hay funciones matemáticas aparentemente simples con resultados caóticos. Y eso resulta alucinante. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpk9pQACgkQtTMYHG2NR9VRCQCfTiqMieaEMbX4++XaLfMZbeMH ZgMAoJMmGqLwsioZoFDxZE5asQ4G78Px =GS8d -----END PGP SIGNATURE-----

El 2009-07-20 a las 22:08 -0500, Nicolas Guarin escribió:

...

Estas cosas del caos, dinámica no lineal, indeterminismo se refiere en

...

cambio a otra cosa. Hay 'problemas' que se dicen que son lineales y queremos decir con esto que conocidas su posición y momento podemos conocer su posición y momento en cualquier instante del tiempo posterior (... y despreciando, para simplificar la compresión de las cosas, las fuerzas externas). Más aún: pequeñas variaciones en los valores de posición y momento de esa partícula producen sólo pequeñas desviaciones de su trayectoria y momento. En esto, es irrelevante si el problema aplica a cuerpos micro o macroscópicos. Sin embargo, hay problemas que llamamos 'no lineales', porque pequeñísimas variaciones en su poción o momento producen variaciones enormes en su posición o momento en cualquier instante del tiempo posterior a la medida. Son sistemas que decimos caóticos porque no somos capaces de predecir el comportamiento posterior de la partícula dadas unas condiciones iniciales conocidas.

En realidad, lo que ocurre al cambiar ligeramente las condiciones iniciales, es que la función de salida es similar al principio, durante un tiempo, y de repente cambia tremendamente, y de manera impredecible para el pequeño cambio de las condiciones iniciales. Se supone que si las condiciones iniciales son más parecidas (más decimales de precisión), la función sacara unos resultados parecidos durante más tiempo...

Y eso es lo que explica que el tiempo se pueda predecir algo durante un tiempo pequeño, y luego resulta caótico.

Pero ojo, que el caos se estudia en funciones matemáticas no lineales... no sólo en simulaciones de la realidad compleja. Hay funciones matemáticas aparentemente simples con resultados caóticos. Y eso resulta alucinante.

Jajajajajja, a lo que llegaron. Lo que sí me atreco a decir es que un PC, desde el punto de vista que lo abordamos, está bien distante de un sistema caótico :P...

¿A los componentes del PC les afecta las leyes del mundo físico, no? Pues también son partícipes y suspeptibles del caos :-P Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Pues no tanto, porque cuando metes un sistema operativo multitarea ya tienes un ordenador impredecible.

Pues no. No es así. Los ordenadores están programados. Y siguen ese programa. Y no hay nada más allá del programa. Las cosas no aparecen de la nada, hay en algún lado una línea de código que explica por qué el programa ha fallado, o ha ido por otro lado.

Lo que hace un ordenador se considera predecible, metes unas entradas y tienes unas salidas, siempre las mismas, invariables. Pero ya no tanto... primero tienes la interrupción de reloj, que interrumpe tu programa y hace cosas por en medio: ya tienes un factor irregular, porque rompe la cadena de tiempo de tu programa, que no está demostrado que no le afecte, de momento; y porque toma el procesador y lo deja en un estado distinto del que lo tomó, a lo mejor se le olvida restaurar algún registro o flag. Como al diseñar tu programa no sabes cuantas interrupciones de reloj vas a tener, y exactamente en que puntos del programa, pues ya tienes un sistema impredecible.

Luego añade que tu programa va a ser interrumpido por otros programas... pues más de lo mismo. Además, esos programas pueden alterar el estado del disco, de la memoria, externamente a lo que hace tu programa... más imprevistos. Incluso podrían alterar el contenido de memoria de tu programa. O el sistema puede alterar la posición de la memoria en la que se guarda tu programa o sus datos (alterando los punteros para compensar).

No es cierto, no es así. A ver, los ordenadores son sistemas, desde un punto de vista puramente físico, unos sistemas enormemente complejos. Pero obedecen a unas leyes muy muy sencillas; tanto, que han sido los seres humanos quienes las han inventado. Y estas normas se han inventado intentando que fuesen lo más simples posibles. Puede que a ti el problema de resolver qué va a hacer un ordenador bajo ciertas circunstancias te parezca complejísimo (y en verdad lo es): Qué ocurre cuando el ordenador está ejecutando tales programas, con tales usuarios y éstos hacen tales cosas. Sin embargo, todo se reduce a conocer perfectamente el código fuente de lo que se está ejecutando y qué acciones se toman. El resto es una consecuencia de estos parámetros y es calculable (imagínate un super-debugger). Todo es predecible porque todo es programable. Sin embargo, hay problemas físicos que directamente _sabemos_ que _no_ podemos resolver. Sabemos, hemos demostrado, que con nuestras matemáticas no podemos alcanzar una solución. No es cuestión de conocer perfectamente las condiciones iniciales (que sí podríamos conocer) sino de las leyes que gobiernan ese movimiento: Simplemente, no sabemos resolver el problema. Más aún, sabemos que no se puede resolver.

Con lo que conviertes un sistema predecible en uno impredecible.

Son problemas distintos, insisto. En uno, puede que conozcas o no todas las variables y así obtengas o no una solución incorrecta (es un problema de conocer las condiciones iniciales). En el otro, aún conociendo perfectamente las condiciones iniciales de forma exaustiva, sabemos que no podemos alcanzar la solución.

¿Caótico? Pues depende de como lo definas. Díselo a los que hacen la función random(), les encantaría que fuese realmente caótica.

Aquí el problema es que intentan obtener una cifra aleatoria en función de algo que no lo es. Intentan, partiendo de algo en principio aleatorio pero muy ciclico intentan añadir complejidad mediante... un programa.

Ah, y no hemos hablado de las motas de polvo que conducen a veces si y a veces no tanto situadas entre los contactos produciendo cuelgues...

Eso es otro problema. No cuenta :D -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

...

...

Pues no tanto, porque cuando metes un sistema operativo multitarea ya tienes un ordenador impredecible.

Pues no. No es así. Los ordenadores están programados. Y siguen ese programa. Y no hay nada más allá del programa. Las cosas no aparecen de la nada, hay en algún lado una línea de código que explica por qué el programa ha fallado, o ha ido por otro lado.

Si estudiaras informática verías como te dicen lo mismo que yo he dicho, que un ordenador multitarea o con interrupciones se considera impredecible. No es estudiable en su totalidad, por la sencilla razón de que hay sucesos externos al flujo del programa bajo estudio que lo hacen no lineal.

Es rizar el rizo, pero es cierto. Es una consideración distinta de la que se hace en física.

Lo que pasa es que se hacen ciertas suposiciones, y bajo esas suposiciones el sistema es predecible... hasta que de repente hace algo no previsto.

...

Sin embargo, todo se reduce a conocer perfectamente el código fuente de lo que se está ejecutando y qué acciones se toman.

No, no te vale, porque otros programas interrumpen al tuyo en momentos que no puedes saber a priori.

Podrías estudiar tu programa y qué le sucede si es interrumpido en cada una de sus millones de instrucciones por cada uno de los miles de procesos existentes en el mismo ordenador, cada uno de esos procesos en cada uno de sus millones de estados posibles, y con cada una de las millones de entradas posibles por parte del usuario (el ratón en cada pixel distinto es una acción distinta), etc. Además están las temperaturas de cada uno de los componentes, los posibles rayos cósmicos...

El problema es intratable. Ni con un superdebugger. Se trata porque se hacen suposiciones que lo reducen drásticamente, pero de vez en cuando nos topamos con eso... como los miles de bugs irreproducibles atestiguan.

Es un concepto distinto del caos como concepto físico o matemático.

...

...

¿Caótico? Pues depende de como lo definas. Díselo a los que hacen la función random(), les encantaría que fuese realmente caótica.

Aquí el problema es que intentan obtener una cifra aleatoria en función de algo que no lo es. Intentan, partiendo de algo en principio aleatorio pero muy ciclico intentan añadir complejidad mediante... un programa.

Un amigo mio me enseñó un prototipo de circuito electrónico digital de su invención con salida realmente aleatoria, caótica. Hace ya años, y no he oído de él, ni sé si lo ha intentado comercializar. Me sospecho que no :-(

Pero es que en física no consideramos caótico y aleatorio como sinónimos, consideremos un ejemplo sencillo un oscilador armónico simple con fase desconocida. En ese sistema no conocemos la posición en cada momento pero podemos analizar su energía, hallar el espacio de configuración, el espacio de fase, valor esperado... por ende no caótico. -- Nicolás Guarín Zapata Ingeniería Física Medellín Colombia -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-21 a las 19:25 +0200, Lluis escribió:

On Tuesday 21 July 2009 17:14:51 Carlos E. R. wrote:

...

Un amigo mio me enseñó un prototipo de circuito electrónico digital de su invención con salida realmente aleatoria, caótica. Hace ya años, y no he oído de él, ni sé si lo ha intentado comercializar. Me sospecho que no :-(

Hace muchos, muchos años que se utiliza un generador de ruido blanco, por ejemplo el que produce un diodo zener y un contador como generador aleatorio.

Hay muchos mas, basadosen el ruido termico de los componentes.

Cierto. Pero el suyo era más alucinante, no usaba generadores de ruido. La salida era un valor analógico estable durante un ciclo de reloj (que se podía digitalizar). Al siguiente ciclo, cambiaba. Fué antes del 90, ya no me acuerdo del circuitillo. Era muy simple. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpmDjMACgkQtTMYHG2NR9X7/gCdFhIul1u2cpZB+g9DBtzFh8lw +iAAnjzw3bdfH4N0TmK/KXL1Gb2By9r9 =BHtQ -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-21 a las 21:40 +0200, Lluis escribió:

...

Fué antes del 90, ya no me acuerdo del circuitillo. Era muy simple.

El problema, no esta en la forma física de la salida, sino en la verdadera aleatoriedad del valor en cualquiera de sus expresiones.

Según me dijo era verdaderamente aleatorio, pero lento.

Los fabricantes de tragaperras nos podrían asesorar en eso. Es uno de sus problemas.

Creo que usaron tablas grabadas... pero si los usuarios se las aprenden, adiós. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpmTcEACgkQtTMYHG2NR9VGGQCeKUJFjR6gbA8sWRYs7q6dDmZL /UcAnjAz4IvzHX5sYOy+QsehEvTzxMPm =fUzg -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-22 a las 20:53 +0200, Rafa Griman escribió:

Hola :)

Vaya, no pensaba que se iba a liar tanto ;)

:-)

Creo que lo que quiere decir Carlos es lo siguiente (pong un ejemplo). Cuando se hace un estudio de CFD (dinámica de fluidos) para diseñar un camión o un autobús, se utilizan modelos muy grandes por lo que hacen falta equipos muy grandes. Bien pues nosotros hemos hecho benchmarks con el MISMO modelo en la misma máquina, lo único que ha cambiado es el número de CPUs. OJO!! _NO_ se hizo con cluster sino con una única máquina. Empezamos con 32 procesadores. Pasamos a 64, a 128, 256, 512, 1024, +1024 BOOOOOM. El benchmark cae por debajo de cuando la misma máquina tenía 256 procesadores. Vaya, teóricamente, tendría que haber mejorado el rendimiento, hasta los 1024 procesadores escalaba linealmente. Esto no se esperaba. ¿Qué le pasa? ¿Será la aplicación que no es capaz de trabajar con más de 1024 procesadores? ¿Será la coherencia de cachés? ¿La cantidad de memoria?

Os dejo que le déis unas vueltas al por qué de la repentina pérdida de rendimiento tan bestial >;) Cuando empecéis a formular preguntas y/o conjeturas, veréis que hay muchas más variables de las que pensáis y que un sistema informático no es tan predecible o sencillo como creeis.

¡je!

Creo que es a eso a lo que se refiere Carlos: que no es completamente predecible el funcionamiento de una misma aplicación o de un mismo sistema informático.

Pues no pensaba en eso, yo pensaba en una sóla cpu... pero sí, en efecto, puede ser un ejemplo práctico. ... ...

...

Lo que pasa es que se hacen ciertas suposiciones, y bajo esas suposiciones el sistema es predecible... hasta que de repente hace algo no previsto.

Espero que mis ejemplos hayan sido válidos 0:)

...

...

Sin embargo, todo se reduce a conocer perfectamente el código fuente de lo que se está ejecutando y qué acciones se toman.

No, no te vale, porque otros programas interrumpen al tuyo en momentos que no puedes saber a priori.

En estos el caso del camión que pongo como ejemplo no era problema de código fuente >;) Ooops, os estoy dando muchas pistas ...

Esperaré a que lo cuentes :-)

...

Podrías estudiar tu programa y qué le sucede si es interrumpido en cada una de sus millones de instrucciones por cada uno de los miles de procesos existentes en el mismo ordenador, cada uno de esos procesos en cada uno de sus millones de estados posibles, y con cada una de las millones de entradas posibles por parte del usuario (el ratón en cada pixel distinto es una acción distinta), etc. Además están las temperaturas de cada uno de los componentes, los posibles rayos cósmicos...

El problema es intratable. Ni con un superdebugger. Se trata porque se hacen suposiciones que lo reducen drásticamente, pero de vez en cuando nos topamos con eso... como los miles de bugs irreproducibles atestiguan.

Hablando de debuggers. Si alguien programa, que nos cuente lo agradable (y predecible) que es depurar (debug) o hacer un profiling de un sw multihilo en sistemas multiprocesador (que cuente sus experiencias en entornos SMP, NUMA y cluster). Sabéis que yo no programo, pero hablando con gente que sí programa (esta gente programa en entornos de más de 512 procesadores NUMA y cluster) y creedme que tienen muy poco sentido del humor cuando les sacas el tema 0;)

No he programado con esos bichos de múltiples cabezas, pero tengo la suficiente idea como para que me dé verdadero pánico.

La programación paralela es mucho más compleja de lo que nos imaginamos y eso de tener el código fuente no es suficiente :( En estos casos influye el código fuente de: - firmwares de CPU y otros chips - debugger - compiladores - profilers - kernel - librerías

Pero es que en casos mucho más simples, como un par de procesadores, puedes toparte con algo tan mundano como que uno de los núcleos atiende la interrupción de reloj, o atiende a otro proceso de los muchos que corren en un Linux continuamente, retrasando uno de los dos procesos principales y haciendo que tenga tarde unos datos que el otro proceso espera a tiempo, y no los tiene. Al no tenerlos, para no estar parado procesa otra cosa mientras espera, es decir, sigue otra rama del código... luego ya tenemos una ruta de ejecución distinta de la que se pensó que iba a seguir inicialmente. Puede que el resultado final sea el mismo o no... depende. Hacemos la suposición de que todo será igual, pero si no lo es... alucinas para descubrir porqué. U otro caso con un simple procesador. No ejecuta sólo nuestro programa, sino varios, pseudo-concurrentemente. Uno de los procesos, pongamos el driver de ratón, que no está bajo estudio (o sea, no es el nuestro) está mal y escribe en alguna posición de memoria que no le corresponde, o altera el estado de algún dispositivo, o simplemente, a veces se le olvida restaurar uno sólo de los registros del procesador... y eso altera el comportamiento de nuestro programa de una manera no prevista. Ya tienes un comportamiento aleatorio. O tienes un proceso de simulación en tiempo real, como puede ser un simulador de vuelo (un juego). Otros procesos que se ejecutan al mismo tiempo le "roban" tiempo de cpu al simulador, que tiene que ceder ciclos de calculo: esto es, en vez de calcular el estado del avión 20 veces por segundo lo hace 15, o peor, 5. Esa mayor granularidad del cálculo hace que el cálculo no sea tan exacto, e incluso el usuario puede notar que el avión no va fino, da saltitos... estamos alterando el comportamiento (y los valores numéricos) que tiene nuestro programa. Probablemente puede compensarlo, pero es algo que no se puede calcular con exactitud a priori cual va a ser la salida exacta de cada bucle del simulador. Puede ocurrir que como consecuencia el usuario estrelle el avión... y no me lo invento, me ha pasado. Todo esto con un sólo núcleo... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpnbhQACgkQtTMYHG2NR9WETQCgknrFrv+iVFqQZbuKc+SSGD+3 XJsAmgIxR0vzpuBkTRNl2OpYtt0mtPB6 =ftmb -----END PGP SIGNATURE-----

Hola :) On Monday 20 July 2009 17:39:53 Nicolas Guarin wrote:

El 20 de julio de 2009 02:36, Rafa Griman escribió:

...

Hola :)

On Sunday 19 July 2009 21:45:42 Nicolas Guarin wrote:

...

...

Esto nos lleva al Principio de Incertidumbre de Heisenberg, teor�a del caos,

Yo dir�a que el principio de Incertidumbre se aleja de lo que en f�sica llamamos caos.... :P

Puede que me haya explicado mal 0:) No quería decir que el Principio de Incertidumbre y la teoría del caos estuviesen relacionadas o fuesen cercanos. Lo que quería decir es que ese tipo de teorías, principios, ... que nos dicen que no podemos realmente demostrar las cosas debido a su complejidad, a la interferencia que hacemos al medir las cosas, ... se deben tener en cuenta para darnos cuenta que, por mucho que nos empeñemos, los datos no tienen porqué ser "la verdad absoluta".

Un benchmark no es más que un estudio científico del comportamiento de un sistema (en este caso un ordenador/computador). Este estudio, igual que muchos otros estudios científicos se basa en la observación, repetición y estudio (estadístico) de los resultados. Para luego interpretarlo/entenderlo.

Digo esto porque muchas veces sale un benchmark y a la gente (en general) le gusta usarlo para "demostrar" algo y no necesariamente tiene porqué ser así.

Por eso digo que hay que tener en cuenta ciertas teorías o principios, para poder ver que no se repiten los resultados, por qué no se repiten, lo complejo que es un benchmark, ...

Espero haberme explicado.

Pero no veo diferencia en un benchmark y cualquier otra actividad humana, el principio de incertidumbre es algo inherente de la naturaleza no humano, por ende todo lo que hagamos pa a estar empapado de eso, sea benchmark de núcleos Linux o experimentos en un acelerador de partículas...

No he dicho lo contrario, lo que digo, copio y pego: "Digo esto porque muchas veces sale un benchmark y a la gente (en general) le gusta usarlo para "demostrar" algo y no necesariamente tiene porqué ser así." Es decir, toman un benchmark como "la verdad absoluta", como que eso es inamovible y el que dice lo contrario miente. Efectivamente, las teorías, principios, teoremas, ... son inherentes al Ser Humano (y a cualquier otro sistema), nadie lo ha negado (yo por lo menos no). Lo que estoy diciendo es que no debemos tomarnos los benchmarks como "la verdad absoluta". He hecho referencia al Principio de Incertidumbre y a la teoría del caos como ejemplos, igual que podría haber dicho que hay: "Hay mentiras, malditas mentiras y estadísticas. Siendo las peores las estadísticas" Lo cual tampoco dice nada en contra ni a favor del Ser Humano. Lo que digo es que no nos creamos los benchmarks como única verdad. Las referencias que he hecho son para que la gente entienda que es una ciencia más y que no es perfecto. A lo que me estoy refiriendo es que hay gente (muchos) que se creen los benchmarks como si fuera algo inamovible: "la verdad divina y absoluta". ¡Claro que un benchmark y un experimento con/en un acelerador de partículas están "empapados", como dices, del Ppio. de Incertidumbre, por eso mismo lo digo! No lo he negado ni lo he puesto en duda, todo lo contrario. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) On Monday 20 July 2009 19:38:39 Shinji Ikari wrote:

Creo que últimamente todos los temas que he iniciado han terminado en controversias y discusiones OT. -_- ¿Tanto así me presto a crear problemas? =P

Por mi no hay problemas y encantado de leer tus correos :) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) On Monday 20 July 2009 20:42:42 Camaleón wrote:

El 2009-07-20 a las 12:38 -0500, Shinji Ikari escribió:

[...]

...

Si alguien conoce algún benchmark y condiciones mejores en las cuales evaluar distribuciones de Linux, que lance la primera piedra. Algo nuevo vamos a aprender de la pedrada. =)

Yo también creo que esas pruebas de rendimiento tienen su utilidad. De otra forma no se podrían comparar las cosas ni establecer valores y al fin y al cabo, en el universo ¿no era todo relativo? >>:-)

El benchmark que ejecutes depende de lo que vayas a hacer con tu equipo y el conocimiento que tengas de dicho benchmark. Por ejemplo, se puede usar dd y xdd para medir el ancho de banda de un disco, sea local o sea montado por NFS o Samba, pero ... Os dejo que investiguéis los problemas que pueden surgir y el porqué de ellos al usar dd y xdd ;) ¿Eso significa que no se puede usar dd o xdd? No, sólo digo que si lo usáis, podéis encontraros con cosas curiosas que tienen su explicación y que no significan que un equipo (o disco o servidor NAS) sea mejor o peor que otro. Todo esto lo digo porque sé que hay gente en esta lista que en su trabajo tienen que decidir qué equipos comprar para la empresa en la que trabaja y que otros se preocupan en el hw que compran para su casa. Lo que no quiero es que esa gente crea que se les está engañando o timando porque en tal revista o blog o web dicen que el benchmark da 27 y a ellos les da 12. Es como si algiuen se compra un coche que el fabricante dice que consume 4.5 litros a los 100Km y cuando lo usa él, resulta que consume 5.1 y piensa que le han estafado. No, las pruebas del fabricante se han hecho en unas condiciones determinadas y el cliente tiene otras. El cliente, por ejemplo, lleva a su suegra, las maletas, a los niños, al perro, a la mujer, ... y el fabricante tenía a un ingeniero japonés flaco de metro y medio metido en el coche, cuesta abajo y con el viento a favor ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) On Wednesday 22 July 2009 21:34:47 RŌNIN wrote:

Hola a tod@s:

Para contrastar (Rafael Grim�n, no te lo pierdas):

http://oswatershed.org/

Curioso !! Pensaba que Arch estaría más atrás porque ahora en verano se ha ido un montón de gente de vacaciones y las listas están llenas de: "Me piro de vacaciones, si alguien puede mantener esta semana los paquetes ... Se lo agradecería". Lo que me ha parecido curioso es que no incluyan a openSUSE 11.2 y sí han incluido Fedora 12. Corregidme, pero creo que Fedora 12 no ha salido aún, vamos que está un poco más verde que openSUSE 11.2. También me ha llamado la atención que pongan a Gentoo en "Future" como la más "up to date" ya que no suelen incluir las últimas versiones. Les cuesta mucho pasar versiones nuevas a "Stable", les pasa como a Debian, aunque no tan radical. Gracias por el link. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

...

http://oswatershed.org/

Interesante sitio e interesantes datos.

Si no lo he entendido mal, lo que mide la "ciencia de la distrología" es el grado de paquetes novedosos que se incluyen en las distribuciones que están monitorizando ¿no?

Entonces es normal que la suse 11.1 esté en el último lugar, es una distro estable y segura. Y no se puede ser estable y segura con tanto paquete base "renovao" a los pocos días >:-)

En realidad lo que mide es que tan actualizados están los paquetes que integran la distro con respecto a la versión estable del proyecto original, por ejemplo compara si la versión de nmap de openSuse es la misma que la ultima versión estable del proyecto nmap. Y es un punto en contra muy importante para OpenSuse, no se evalua a la SLED 11 que si deberia ser la estable, madura, segura y todo lo que se quiera. Vaya que hasta Debian esta mejor parado... muy muy mal para openSuse. Saludos! -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola a tod@s: El 23 de julio de 2009 13:38, Camaleón escribió:

El 2009-07-22 a las 14:34 -0500, RŌNIN escribió:

...

Para contrastar (Rafael Grimán, no te lo pierdas):

http://oswatershed.org/

Interesante sitio e interesantes datos.

Si no lo he entendido mal, lo que mide la "ciencia de la distrología" es el grado de paquetes novedosos que se incluyen en las distribuciones que están monitorizando ¿no?

Entonces es normal que la suse 11.1 esté en el último lugar, es una distro estable y segura. Y no se puede ser estable y segura con tanto paquete base "renovao" a los pocos días >:-)

Difiero de tu apreciación, veamos: Estable: he usado Arch Linux desde hace más de 6 meses en diferentes áreas empresariales (Servidores de bases de datos, servidores de archivos, servidores de impresión, estaciones de trabajo para diseño gráfico, estaciones de trabajo para desarrollo en diferentes lenguajes, estaciones de trabajo para usuarios comunes ... y en mi hogar, por supuesto), actualizo los sistemas (de mi hogar y de la empresa) una vez por semana y nadie se ha quejado de que una actualización le ha roto algo. Seguridad: Acabo de ver ésta noticia: http://barrapunto.com/articles/09/07/18/1635220.shtml y justo me ha salido hace pocos días una actualización para Arch Linux referente a kernel26-2.6.30.2-1 y ni te relato las versiones de los demás paquetes que tengo instalados en casa y en la empresa; a esto le llamo seguridad: en cuanto aparece algún posible fallo, está disponible la actualización que te lo soluciona. Y no te hablo de las demás ventajas ... te invito a comprobarlo por tí misma (Y quedo a la espera de las declaraciones de otro gran Archero declarado: Rafael Grimán). Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Ya que me tiras de la lengua ... Yo también tengo a Arch "al día" y no tengo problemas de estabilidad alguno.

En cambio a mi arch no me quiere.. bujujuju despues de arracar la t de red .. se muere. bujuju porrrrr queeeeee???? (reclamo sonoro) buaaaaaa Jaime V -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-07-23 a las 20:37 -0500, RŌNIN escribió:

El 23 de julio de 2009 13:38, Camaleón escribió:

...

El 2009-07-22 a las 14:34 -0500, RŌNIN escribió:

...

Para contrastar (Rafael Grimán, no te lo pierdas):

http://oswatershed.org/

Interesante sitio e interesantes datos.

Si no lo he entendido mal, lo que mide la "ciencia de la distrología" es el grado de paquetes novedosos que se incluyen en las distribuciones que están monitorizando ¿no?

Entonces es normal que la suse 11.1 esté en el último lugar, es una distro estable y segura. Y no se puede ser estable y segura con tanto paquete base "renovao" a los pocos días >:-)

Difiero de tu apreciación, veamos:

Estable: he usado Arch Linux desde hace más de 6 meses en diferentes áreas empresariales (Servidores de bases de datos, servidores de archivos, servidores de impresión, estaciones de trabajo para diseño gráfico, estaciones de trabajo para desarrollo en diferentes lenguajes, estaciones de trabajo para usuarios comunes ... y en mi hogar, por supuesto), actualizo los sistemas (de mi hogar y de la empresa) una vez por semana y nadie se ha quejado de que una actualización le ha roto algo.

Seguridad: Acabo de ver ésta noticia: http://barrapunto.com/articles/09/07/18/1635220.shtml y justo me ha salido hace pocos días una actualización para Arch Linux referente a kernel26-2.6.30.2-1 y ni te relato las versiones de los demás paquetes que tengo instalados en casa y en la empresa; a esto le llamo seguridad: en cuanto aparece algún posible fallo, está disponible la actualización que te lo soluciona.

¿6 meses? Cuado lleves 6 años con Arch, hablamos :-P Estaba haciendo un comentario genérico, no digo que una u otra distribución en concreto sean inseguras o inestables. Pero ya sabemos que las actualizaciones no siempre van lo bien que deberían ir y lo contario es la excepción, no la norma :-)

Y no te hablo de las demás ventajas ... te invito a comprobarlo por tí misma (Y quedo a la espera de las declaraciones de otro gran Archero declarado: Rafael Grimán).

Intenté probar una versión LiveCD que vi disponible, pero no me cargaban las X :-(. Tendré que volver a probarlo en otro momento, es algo que tengo pendiente. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-07-24 a las 09:24 -0500, RŌNIN escribió:

El 24 de julio de 2009 01:28, Camaleón escribió:

...

¿6 meses? Cuado lleves 6 años con Arch, hablamos :-P

Lo digo porque Arch Linux no ha caído en ese lapso de tiempo como sí lo han hecho otras muchas distros que he probado en entornos idénticos ;-)

La continuidad es importante (o al menos yo lo creo así) en el software. Más aún en el SL, donde en poco tiempo las distribuciones pueden perder toda una base completa de usuarios y desaparecer... Y te quedas a dos velas. Según Distrowatch suse ha sacado versiones desde 1998 (yo la empecé a usar en el año 2003) y en el 2009 aún sigue en pie. Para mí es un factor clave a tener en cuenta para poder usar linux en los servidores. ¿Y porqué elegí suse en el 2003 y no Arch? Pues además de proque no conocía Arch en aquella época, suse ya tenía una trayectoria cuando Arch estaba iniciando.

...

Estaba haciendo un comentario genérico, no digo que una u otra distribución en concreto sean inseguras o inestables.

Pero ya sabemos que las actualizaciones no siempre van lo bien que deberían ir y lo contario es la excepción, no la norma :-)

Así las cosas ... Arch Linux se me hace excepcional :-)

Estoy segura de que así es :-)

...

Intenté probar una versión LiveCD que vi disponible, pero no me cargaban las X :-(. Tendré que volver a probarlo en otro momento, es algo que tengo pendiente.

Recuerdo que uno de los esloganes de Arch Linux da la idea de lo que nos espera: "Arch Linux es lo que tú haces". Por tal razón, Arch Linux no te arranca no te instala las X (ni nada relacionado) en modo automático, si requieres ayuda, estaré atento.

La versión LiveCD que probé (no recuerdo si la que me dio el error fue Arch-Live o Chakra, creo que la primera) tenía entorno gráfico (KDE), pero el xorg cascó nada más iniciar. No, no funcionaba, ya hice las pruebas pertinentes. El error era del tipo "cannot open display". Obviamente no le echo la culpa al Arch, era una versión LiveCD que además no es "oficial" (creo que Arch no tiene una versión LiveCD oficial, y las que hay las desarrollan externamente). Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-07-24 a las 10:51 -0500, RŌNIN escribió:

El 24 de julio de 2009 09:49, Camaleón escribió:

...

La continuidad es importante (o al menos yo lo creo así) en el software. Más aún en el SL, donde en poco tiempo las distribuciones pueden perder toda una base completa de usuarios y desaparecer...

Y te quedas a dos velas.

Según Distrowatch suse ha sacado versiones desde 1998 (yo la empecé a usar en el año 2003) y en el 2009 aún sigue en pie. Para mí es un factor clave a tener en cuenta para poder usar linux en los servidores.

¿Y porqué elegí suse en el 2003 y no Arch? Pues además de proque no conocía Arch en aquella época, suse ya tenía una trayectoria cuando Arch estaba iniciando.

Creo que no me hice entender: cuando hablaba de caer, no es de perder continuidad del lado del proveedor (para éste caso, la comunidad de desarrolladores y mantenedores de Arch Linux), sino de que el sistema me falle en su desempeño (bloqueos, fallos después de actualización, baja disponibilidad de paquetes, etc).

Ah, no, no lo entendí entonces O:-)

Pero ya que tocas el tema, tienes razón en el tema de la trayectoria, pues Arch Linux nació en marzo del 2002 (cuando SuSE le llevaba 8 años de delantera); pero me atrevería a decir que la antigüedad no es un parámetro determinante, porque en tal caso, diríamos que la edad de piedra es mejor que la edad de los metales, por cuanto la edad de piedra es más antigua y la piedra es un elemento de uso actual. Ni hablemos de Micro$oft y GNU/Linux ;-)

La antigüedad por sí sola, no. El hecho de que continúe en vigor durante tantos años, sí es importante. Indica: - Calidad (si fuera una patata, la gente habría dejado de usarla hace mucho tiempo) - Grupo de usuarios y matenedores elevado (si no hubiera desarrolladores, la distro sería muy mala y volveríamos al punto de arriba)

...

La versión LiveCD que probé (no recuerdo si la que me dio el error fue Arch-Live o Chakra, creo que la primera) tenía entorno gráfico (KDE), pero el xorg cascó nada más iniciar.

No, no funcionaba, ya hice las pruebas pertinentes. El error era del tipo "cannot open display".

Obviamente no le echo la culpa al Arch, era una versión LiveCD que además no es "oficial" (creo que Arch no tiene una versión LiveCD oficial, y las que hay las desarrollan externamente).

Lamento que tu primer acercamiento a Arch Linux haya tenido esos resultados tan frustrantes; hay varias distros basadas en Arch Linux (ver http://wiki.archlinux.org/index.php/Arch-based_Distros).

Y Arch Linux sí tiene una versión LiveCD oficial (que se usa para instalar el sistema en tu disco duro, pero no cuenta con nada relacionado con las X), el cual puedes descargar de aquí: http://www.archlinux.org/download/

Pero ¿se puede usar a lo LiveCD, es decir, poder iniciar el sistema sin tener que instarlo? Aunque si esa versión no lleva las X no me sirve para probarla :-(

Ya que ví un hilo donde hablan de los controladores y las tarjetas de video, aprovecho y comento una experiencia curiosa: recién instalé el W7 RC en mi computadora, cuento con una tarjeta Ati 4850 X2, instalé los controladores de la página de Ati y sólo me reconoce uno de los núcleos de la tarjeta (y por ende, la mitad de la VRAM); sin los dos núcleos activos, me es imposible activar el CrossFire. GGGRRRRR !!!

¿W7 = Windows 7?

En mi Arch Linux instalé la versión 9.7 de los controladores de Ati y pude activar el CrossFire sin mayores inconvenientes ... ahora, que los respetables colisteros saquen sus conclusiones.

La conclusión es obvia: los controladores de Ati tienen algún problema con el Windows 7 RC, quizá porque aún no ha salido de manera oficial y Ati no se ha puesto las pilas con los drivers... :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) On Friday 24 July 2009 19:07:24 RŌNIN wrote:

Hola a tod@s:

El 24 de julio de 2009 11:22, Camale�n escribi�:

...

La antig�edad por s� sola, no. El hecho de que contin�e en vigor durante tantos a�os, s� es importante. Indica:

- Calidad (si fuera una patata, la gente habr�a dejado de usarla hace mucho tiempo) - Grupo de usuarios y matenedores elevado (si no hubiera desarrolladores, la distro ser�a muy mala y volver�amos al punto de arriba)

Bueno, fu� uno de los primeros puntos que revis� cuando estaba optando por Arch Linux; hemos comenzado con el pie derecho: se ha mantenido durante cerca de 7 a�os (Y espero que contribuyamos a que siga vigente por mucho m�s tiempo ... verdad, Rafael Grim�n? ... je je je je je).

Hasta el infinito y más allá !!!!! Je, je, je, ... Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola a tod@s: El 24 de julio de 2009 13:03, Camaleón escribió:

La tendré en el punto de mira y estaré pendiente de su evolución :-)

Te mantendremos informada ... ;-)

Sí, la idea era instalarla en la VM. A ver si tengo un tiempito y me animo.

Puedes comenzar por aquí: http://wiki.archlinux.org/index.php/Beginners_Guide; si te surge alguna dificultad, estamos por aquí. :-)

Aún no ha salido ¿no? :-?

Aquí me perdí ... ¿ A qué te refieres con ésta pregunta ?. :-S

Claro, porque W7 es muy reciente. Ya sacarán los nuevos drivers certificados y funcionará como debe. Dale tiempo :-)

Amanecerá y veremos ... dijo el ciego.

Pues eso ya lo tienes, digo, que funcione en Linux.

¿A qué gran engaño te refieres?

Me refiero a los que viven engañados creyendo que su sistema operativo (por el que han pagado una gran cantidad de dinero o lo han adquirido en Sparrow's Software Store; en cualquiera de los casos, han perdido su independencia tecnológica) de veras es el Non Plus Ultra de las creaciones informáticas y por ende, hay que comprar la siguiente versión que aparecerá en las tiendas ... y la cadena continúa. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola a tod@s: El 24 de julio de 2009 14:38, Camaleón escribió:

Okis :-)

Espero que aun estéis por la lista de suse :-P

Pero si ésta Lista de Correo es parte de lo que relaciono con lo mejor de mis avances en Informática, Tecnología y Comunicaciones ... además de mis mejoras como persona. :-)

Tomo nota. Las instalacions son siempre complicadas.

Haz lo que yo: ensaya en las máquinas virtuales hasta la saciedad, ya luego sigues el consejo de Rafael Grimán y lo pones al "Bare Metal" ;-)

Lo comento porque es lo que siempre pasa. Cuando sale nunca hay drivers, no van todo lo finos que deberían o no son los certificados para la versión gold master y te encuentras con paradas del sistema, bloqueos o pantallazos de la muerte... ¿ahora son rojos? :-?

Mal hecho, porque si mi hardware no funciona como quiero en las versiones pre, me surgen muchas dudas sobre la versión final.

Je, pero si el que ha instalado Windows 7 RC ¡has sido tú! X-)

Sip, pero no creas que lo he instalado para usarlo (como la mayoría de M$-seguidores), es sólo por seguir aquel adagio militar: "Si quieres protegerte del enemigo, primero debes conocerlo". Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) On Friday 24 July 2009 17:51:55 RŌNIN wrote:

Hola a tod@s:

El 24 de julio de 2009 09:49, Camale�n escribi�:

[...]

...

La versi�n LiveCD que prob� (no recuerdo si la que me dio el error fue Arch-Live o Chakra, creo que la primera) ten�a entorno gr�fico (KDE), pero el xorg casc� nada m�s iniciar.

No, no funcionaba, ya hice las pruebas pertinentes. El error era del tipo "cannot open display".

Obviamente no le echo la culpa al Arch, era una versi�n LiveCD que adem�s no es "oficial" (creo que Arch no tiene una versi�n LiveCD oficial, y las que hay las desarrollan externamente).

Lamento que tu primer acercamiento a Arch Linux haya tenido esos resultados tan frustrantes; hay varias distros basadas en Arch Linux (ver http://wiki.archlinux.org/index.php/Arch-based_Distros).

Y Arch Linux s� tiene una versi�n LiveCD oficial (que se usa para instalar el sistema en tu disco duro, pero no cuenta con nada relacionado con las X), el cual puedes descargar de aqu�: http://www.archlinux.org/download/

IIRC, Camaleón probó el LiveCD en una máquina virtual. Por lo que he leído en los foros, el LiveCD no funciona correctamente en VMs y no parece haber mucho interés por arreglar el tema, vamos que no lo ven como una prioridad. Prueba en "bare metal" a ver qué tal.

Ya que v� un hilo donde hablan de los controladores y las tarjetas de video, aprovecho y comento una experiencia curiosa: reci�n instal� el W7 RC en mi computadora, cuento con una tarjeta Ati 4850 X2, instal� los controladores de la p�gina de Ati y s�lo me reconoce uno de los n�cleos de la tarjeta (y por ende, la mitad de la VRAM); sin los dos n�cleos activos, me es imposible activar el CrossFire. GGGRRRRR !!!

¡¡¡Peyacho de máquina que tienes!!! :D" Hombre, eso no se comenta públicamente que luego los que tenemos máquinas pequeñas nos pasamos el día soñando ... :(

En mi Arch Linux instal� la versi�n 9.7 de los controladores de Ati y pude activar el CrossFire sin mayores inconvenientes ... ahora, que los respetables colisteros saquen sus conclusiones.

Hmmmmm ... Que le has "lavado el cerebro" a tu máquina para sólo aceptar Linux ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola a tod@s: El 24 de julio de 2009 11:23, Rafa Griman escribió:

IIRC, Camaleón probó el LiveCD en una máquina virtual. Por lo que he leído en los foros, el LiveCD no funciona correctamente en VMs y no parece haber mucho interés por arreglar el tema, vamos que no lo ven como una prioridad.

Prueba en "bare metal" a ver qué tal.

Tal vez sea la versión que haya ensayado, porque la 2009.02 me ha fucnionado perfecto en mi VirtualBox 3.0.2 en las versiones para 32 y 64 bits :-)

¡¡¡Peyacho de máquina que tienes!!! :D" Hombre, eso no se comenta públicamente que luego los que tenemos máquinas pequeñas nos pasamos el día soñando ... :(

Si describo el resto de los componentes de mi computadora ... alucinas. Je je je je je.

Hmmmmm ... Que le has "lavado el cerebro" a tu máquina para sólo aceptar Linux ;)

Ja ja ja ja ja. Es posible, es posible ... sí señor. Mi tessssooorrrrrooo ...:-) Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola a tod@s: El 24 de julio de 2009 15:25, Rafa Griman escribió:

Puede ser. La verdad es que creo que sólo he probado una LiveCD (Sabayon) en toda mi vida ... bueno, no, una de SUSE también. Y nunca en VM. De hecho, las VMs las he usado poco, he probado KVM, Xen, VirtualBox y VMWare, pero sólo probado: instalas una VM, toquiteas un poco y no lo vuelves a usar.

Esto responde parte de la siguiente pregunta: tengo la VirtualBox con varias distribuciones (y versiones de las mismas) de GNU/Linux, Solaris y otros sistemas operativos. Ya luego ensayaré el XEN.

No nos dejes así !!! Quiero saaaaaaaaabeeeeeeeer ;) ¿Para qué la usas? No me lo digas:

       http://games.kde.org/game.php?game=kpat

x"D ¿He acertado?

Ahora en serio, ¿CAD/CAM/CAE? ¿Visualización de datos científicos? ¿Exploración de gas y/o petróleo? ¿Animación? ¿NLE? ¿Postproducción?

Que conste que te lo advertí ... Casi le aciertas, por lo general uso un LiveDVD que contiene lo más importante (ver listado: http://live.linux-gamers.net/?s=games) X'-D Mi computadora cuenta con una mainboard marca ASUS, generación Maximus Formula, un procesador Quadcore @ 3.7 GHz, 8 GB de RAM, 2 TB para almacenamiento (dividido en 4 discos Hitachi), tarjeta de video Ati 4850 X2 de 2 GB de VRAM, la energía es proveída por una fuente CoolerMaster de 800W ... todo ello resguardado por una caja marca Aerocool y acompañado por un par de pantallas de 22" y un poderoso sistema de audio marca Sony. Y como no podía ser menos, mi sistema base es ArchLinux 2009.02 para plataforma de 64 bits. Las tareas en las que uso mi humilde máquina son diversas: simulación de entornos de red (servidores con diferentes servicios y estaciones de trabajo interactuando con los mismos), pruebas de sistemas operativos y programas, edición de audio y video (2D y 3D), servicio de hosting (cuando requiero mostrar el funcionamiento de algún programa o herramienta web a clientes), entre otras. ;-) Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-07-22 a las 21:03 +0200, Rafa Grimán escribió:

On Monday 20 July 2009 20:42:42 Camaleón wrote:

...

El 2009-07-20 a las 12:38 -0500, Shinji Ikari escribió:

[...]

...

...

Si alguien conoce algún benchmark y condiciones mejores en las cuales evaluar distribuciones de Linux, que lance la primera piedra. Algo nuevo vamos a aprender de la pedrada. =)

Yo también creo que esas pruebas de rendimiento tienen su utilidad. De otra forma no se podrían comparar las cosas ni establecer valores y al fin y al cabo, en el universo ¿no era todo relativo? >>:-)

El benchmark que ejecutes depende de lo que vayas a hacer con tu equipo y el conocimiento que tengas de dicho benchmark. Por ejemplo, se puede usar dd y xdd para medir el ancho de banda de un disco, sea local o sea montado por NFS o Samba, pero ... Os dejo que investiguéis los problemas que pueden surgir y el porqué de ellos al usar dd y xdd ;)

¿Eso significa que no se puede usar dd o xdd? No, sólo digo que si lo usáis, podéis encontraros con cosas curiosas que tienen su explicación y que no significan que un equipo (o disco o servidor NAS) sea mejor o peor que otro.

Todo esto lo digo porque sé que hay gente en esta lista que en su trabajo tienen que decidir qué equipos comprar para la empresa en la que trabaja y que otros se preocupan en el hw que compran para su casa. Lo que no quiero es que esa gente crea que se les está engañando o timando porque en tal revista o blog o web dicen que el benchmark da 27 y a ellos les da 12.

Es como si algiuen se compra un coche que el fabricante dice que consume 4.5 litros a los 100Km y cuando lo usa él, resulta que consume 5.1 y piensa que le han estafado. No, las pruebas del fabricante se han hecho en unas condiciones determinadas y el cliente tiene otras. El cliente, por ejemplo, lleva a su suegra, las maletas, a los niños, al perro, a la mujer, ... y el fabricante tenía a un ingeniero japonés flaco de metro y medio metido en el coche, cuesta abajo y con el viento a favor ;)

Correcto. Pero los resultados de esas baterías de pruebas siempre te dan información que si bien puede no decirte nada para valorar algo de manera precisa, sí puede ser útil para otras cosas... Por ejemplo, para saber que los drivers de la tarjeta gráfica que tienes instalados son una pena O:-) ¿Cómo se mide el rendimiento de un producto si no haces pruebas y lo comparas? (me refiero si no tienes un laboratorio en casa :-P) Pues esos test de Phoronix, por poner un ejemplo, te van dando una ligera idea de si lo que tienes es lo que pensabas o si por el contrario estás más perdido que un pulpo en un garaje :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-07-22 a las 22:05 +0200, Rafa Grimán escribió:

On Wednesday 22 July 2009 21:54:19 Camaleón wrote:

...

Pero los resultados de esas baterías de pruebas siempre te dan información que si bien puede no decirte nada para valorar algo de manera precisa, sí puede ser útil para otras cosas... Por ejemplo, para saber que los drivers de la tarjeta gráfica que tienes instalados son una pena O:-)

Hmmmm, ¿por qué habrá puesto Camaleón la t. gráfica como ejemplo? No se me ocurre ... ;)

No importa, el porqué del ejemplo, estoy de acuerdo contigo en eso ;)

Es que eso duele. Tarjeta nvidia Quadro FX1500 y unos resultados en tests de rendering de 3D pírricos. Dita sea, dan ganas de volver a la Matrox Millenium G450 >>:-)

...

¿Cómo se mide el rendimiento de un producto si no haces pruebas y lo comparas? (me refiero si no tienes un laboratorio en casa :-P) Pues esos test de Phoronix, por poner un ejemplo, te van dando una ligera idea de si lo que tienes es lo que pensabas o si por el contrario estás más perdido que un pulpo en un garaje :-)

Completamente de acuerdo contigo. De hecho, algunas de las herramientas que forman los tests de Phoronix son herramientas de benchmark usadas habitualmente muchísimo (iozone, por ejemplo) y algunas han sido diseñadas por matemáticos/físicos/biólogos/... Y totalmente de acuerdo a que lo que te permiten es hacerte una idea de "por dónde van los tiros". 100% de acuerdo contigo.

Pero eso no significa que tu, con ese mismo hardware vayas a obtener los mismos resultados ;) Pero estoy de acuerdo contigo en que te puede orientar a la hora de comprar, pero es eso, una orientación. OJO, a lo mejor ejecutas esos mismos benchmarks en el mismo equipo ... y tienes mejores resultados :D

¡Y qué razón tienes! En windows, el mismo harwdare en un equipo igualico... vuela >>>;-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 2009-07-23 a las 11:01 +0200, Luis Esteban de Dios Núñez escribió:

Un amigo mío tiene una laptop, de su empresa, a la cual ni los espcialistas de su institución han podido descifrar cómo quitar la clave del setup para actualizar la BIOS con el objetivo de que pueda conectarse en red para usar el sistema de su empresa.

Hay varios tipos de clave: de bios y de acceso a disco (cifrado). - Si se trata de la clave de la bios y no la sabe, que quite la pila unos segundo para hacer un reset general. Aunque no sé si funcionaría... *** Power On The Power On password is set in the System BIOS options. It prevents unwanted users from accessing the computer. By default, HP does not set the Power On password. If you set the Power On password in the System BIOS options you will be prompted for it immediately after you power on the Notebook PC. If this password is forgotten, a repair at an HP certified repair center is required to reset the computer. Please contact HP to schedule a repair. This service is not covered by the warranty. *** - Si es la clave de cifrado de disco, mal asunto :-( *** Drive Lock The Drive Lock password protects the data on your hard drive through encryption. If your computer is stolen, the data on the hard drive is inaccessible without the Drive Lock password. This password cannot be reset. If it is lost or forgotten, the hard drive must be replaced. Please contact HP to order a new hard drive. This service is not covered by the warranty. *** Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-23 a las 11:01 +0200, Luis Esteban de Dios Núñez escribió:

Hola familia :)

Les llamo así porque lo sois, ja ja ja, una parte importante de mi tiempo lo paso leyéndolos.

Hola Luis. Oye, cuando quieras poner un correo en una lista, hazlo creando un correo nuevo, no respondiendo a uno antiguo y borrando el asunto, porque se nota, queda registrado y canta. Tanto que tiene nombre: secuestrar hilos.

Un amigo mío tiene una laptop, de su empresa, a la cual ni los espcialistas de su institución han podido descifrar cómo quitar la clave del setup para actualizar la BIOS con el objetivo de que pueda conectarse en red para usar el sistema de su empresa.

Supongo que quitando la pila de la cmos, y la batería principal, un buen rato. ¿Pero igual ya lo habéis probado? - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpo8o4ACgkQtTMYHG2NR9VHYACeO9Tzw9eTarx3dMuJlOPw5xJe U3QAoJcxgsqqLnl59xvqLoaGrpiXVm14 =//7J -----END PGP SIGNATURE-----

Hola :) On Friday 17 July 2009 22:27:25 Shinji Ikari wrote:

On Friday 17 July 2009 10:01:19 Camaleón wrote:

...

El 2009-07-17 a las 08:23 -0500, Shinji Ikari escribió:

[...]

...

Me llama la atención los resultados de Fedora. Además, la mitad de las aplicaciones que han usado no las conozco.

No he leído en que consisten cada una de las pruebas. Acceso a disco, distribución de tareas. =/ Creo que estas cosas deben estar especificadas en alguna parte... aunque abusando de la confianza y exponiendo la flojera, se puede solicitar ayuda al Sr. Pingüino alienígeno melenudo. =P~

Phoronix lo que ha hecho es juntar un montón de benchmarks en un paquete descargable de su web. Algunas son conocidas (bonnie, iozone, ...) y otras no, algunas veces realmente no son aplicaciones para benchmark sino aplicaciones "normales" como bzip2 (en este ejemplo usan parallel bzip, si mal no recuerdo) y miden el tiempo que se tarda en ejecutar. En su paquete de aplicaciones tienen de todo: disco, RAM, CPU, t. gráfica, ... Me parece interesante porque tienes en un único paquete un montón de aplicaciones que te pueden servir para estudiar tu equipo y no tienes que andar buscando por ahí. Como siempre, lo malo de los benchmarks es entender lo que hace la aplicación y cómo está construido tu sistema (tanto a nivel hw como sw). Hay que saber de estadística (recordemos que hay que repetir las pruebas varias veces, sacar desviaciones, ...), ... vamos que es un proceso complicado y los resultados son difíciles de comparar. MHO Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org