-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-27 a las 22:06 +0200, Camaleón escribió:
El 2009-05-27 a las 21:42 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 17:52 +0200, Camaleón escribió:
¿Por qué no se van a poder suspender o hibernar los servidores? :-?
Pues porque:
* En hibernación no /sirven/ ninguna petición de nadie.
¡Los servidores también se apagan! :-)
Por ejemplo, los que gestionan las copias de seguridad: inician la copia a las 00:00, terminan a las 2:00 e hibernan hasta la mañana siguiente que les despierta el administardor.
Fale... Pero si lo has hibernado, hoy en día, no atenderá ninguna petición remota, esto es, ninguna petición de servicio al servidor, que es lo que he dicho.
* En suspensión, en general, tampoco sirven peticiones (1).
¡Si que sirven! :-)
¡Narices! Deberían, pero no me creo que lo hagan.
(1) Podrían quizás servir peticiones de fax entrantes por el puerto serie, un caso concreto que quizás funcionase. Me gustaría comprobarlo, pero no tengo hardware para ello. Pero no podrían atender peticiones por red, por la sencilla razón de que la tarjeta de red no creo que sea capaz de discriminar si está recibiendo una petición que debe sacar al ordenador de la suspensión para atenderla o no (y si tienes que despertarlo por todos los paquetes, has perdido la utilidad).
Es decir, para poder suspender un servidor y que siga /sirviendo/, debes asegurar que siga cumpliendo su misión, la que sea, via red.
Claro, y eso es precisamente lo que "debería" hacer la suspensión: apaga todo, pero no la tarjeta de red. O no el módem. Y espera, paciente, a que le llegue alguna petición: si no tiene nada que hacer, sigue suspendido, si suena el módem o un usuario inicia una sesión imap, se despierta.
¡Debería! Deja de soñar, eso no existe - que yo sepa. El módem, lo veo factible, porque es una cosa que ya pensaron hace lustros: el ordenador se puede encender con una llamada telefónica. Pero el equivalente para una tarjeta de red es encender el ordenador en cuanto llega un paquete con la dirección MAC de la tarjeta, que es distinto de lo de WOL. Que se yo, a lo mejor se puede hacer para una suspensión (RAM). No lo se. Yo no me lo creo.
Pero vamos a ver, eso le hubiera pasado igual si lo hubiera activado de forma manual: el problema era que no le funcionaba (de ninguna forma) y punto >:-)
Pero vamos a ver, si suspendes manualmente tú lo haces cuando sabes que puedes hacerlo y conociendo las consecuencias de lo que puede dejar de atender o no el servidor.
Ese no era su bug ¡ese era tu bug! X-)
El pobre usuario de IBM se quedó más fresco que una lechuga cuando le dijeron que podía ir al módulo de gestión de energía y desactivar la hibernación. Su bug estaba resuelto: su equipo ya no se apagaba solo.
Tu queja era que la hibernación se activaba de manera predeterminada.
Su queja estaba mal puesta porque no se dieron cuenta de lo que pasaba. ¡Tardaron meses en darse cuenta de que sus reportes privados salían fuera de la empresa! Lo de ir al módulo de gestión de energía es una "solución temporal" para evitar el bug antes de resolverlo, porque no lo reconocían. La solución al bug fué quitar la suspensión automática por defecto, que lo hicieron, gracias a las quejas de IBM.
Pero si se te suspende automáticamente ya no es decisión tuya, y el sistema operativo debiera ser capaz de seguir gestionando todas las tareas que se le haya encomendado... y no hace ninguna, se ha dormido.
La suspensión automática, recuerda, se dispara por inactividad del teclado del usuario que está en sesión local. Le importan un bledo los usuarios remotos o cualquier tipo de conexión en red, o programa que esté procesando algo, aunque sea que el hylafax está enviando las ordenes de las nóminas del mes al banco: se suspende, y todo a freir monas, ese mes no cobrais. ¿La culpa? Mira, esa nube de polvo es Camaleón yendose a Pernambuco >:-P
Esa era tu queja, Carlos, tu queja, tu bug particular. No era el problema del usuario :-D.
Sí lo era, lo que pasa es que no se dieron cuenta al principio.
P.S. Saludos desde Pernambuco.
je, je.
Pero ojo, que hay equipos que SÍ están certificados (para sled o sles) y fallan igual.
Bueno, según una directiva europea en preparación, los distribuidores de linux pudieran ser responsables de lo que haga o deje de hacer el linux que distribuyen. Lo estaban discutiendo no se si era en slashdot hace poco.
Estaba claro que se le podían exigir responsabilidades a los fabricantes de software de pago, como microsoft, por los fallos de su software. Estaban pensando si las mismas responsabilidades se les podía exigir al software abierto/colaborativo, como el Linux, o si esa responsabilidad se trasladaba en ese caso al distribuidor, como RedHat o Novell.
Sí, algo leí... pero creo que la propuesta era si los programadores (en general) debían responsabilizarse de sus programas. No me hagas mucho caso, no lo recuerdo bien.
En efecto. Pero decían que, si bien los programadores de soft. abierto no lo serían, sí lo serían los distribuidores comerciales.
La segunda vez, la operación de ver el menú es instantánea, debe tener una caché.
Hablando de cachés y de aplicaciones lentas.
En la lista de factory me ha parecido leer un truco para acelerar a un Firefox que lleva abierto bastante tiempo (algo de limpiar la base de datos sqlite)... a quien le interese que eche un vistazo a los últimos mensajes.
Hace un tiempo que ví algo de eso. Esta vez no me he fijado. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkodquQACgkQtTMYHG2NR9VE4wCeL8IGalfmZ00aNgVL7AvD4mtS /ucAnRbgYZF/QpwPb8/3oIl9w9i0xlnL =uDSm -----END PGP SIGNATURE-----