-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-27 a las 17:52 +0200, Camaleón escribió:
El 2009-05-27 a las 17:17 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 08:50 +0200, Camaleón escribió:
Bueno, relamente se quejó porque pensaba que el equipo se apagaba "solo" y no sabía qué pasaba.
Además que tener problemas para poder restaurar.
No recuerdo que fuera un equipo gestionado en remoto o un servidor :-?
Eran "blades".
Hum... sí, era un blade (HS21XM) pero por lo que se lee estaba en local no en remoto :-P
Claro, pero porque lo estaban probando con la nueva suse y se dieron de bruces con el problemón.
Casos distintos sí, pero con la misma necesidad de ahorrar y agilizar el inicio del sistema ¿por qué no?
Sí, vale, un león y una oveja tienen ambos necesidades de comer; pero distintas.
¿Por qué no se van a poder suspender o hibernar los servidores? :-?
Pues porque: * En hibernación no /sirven/ ninguna petición de nadie. * En suspensión, en general, tampoco sirven peticiones (1). (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.
¿Qué le pasa a la automática?
¿Y tu me lo preguntas, después de aquel bugzilón?
A ver, por donde empiezo... porque no atiende a daemons que están trabajando (ni poco ni mucho), porque corta las conexiones de red establecidas (ftp, http, nfs, samba... smtp...)
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. 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
La hibernación está pensada para equipos de un fabricante que lo ha prodado en fábrica y que te dice que con "x" sistema operativo está certificado para hibernar. Porque da la causalidad que de que ese sistema operativo "x" tiene controladores certificados por el fabricante de los componentes (como las tarjetas gráficas) y está cubierto.
Ahora intenta reportar en bugzilla sobre un fallo del driver de nvidia, ya sabes que no dura ni 10 minutos: wontfix :-(
Te recuerdo que NADA en los linux que usamos tu y yo está certificado. NADA en absoluto.
Pues por eso no funciona ;-)
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.
Narices, serían unos 10 o 12, yo no puedo teclear más rápido las contraseñas ni navegar los menús ni cambiar de worksheet más rápido, son operaciones manuales.
Automatiza los inicios de sesión en el navegador :-)
¿De que me sirve eso? El navegador es de lo ultimo que arranco, puedo tardar un dia en hacerlo.
¿Y no hay forma de iniciar automáticamente la aplicación? :-?
Algunas cosas. No puedo abrir cada terminal con los comandos que esté usando, sesiones de mc, de correo, de manual, de lo que sea que tenga abierto en cada caso. Sin contar de que mantener los terminales y programas abiertos me sirve para saber qué es lo que estaba haciendo y por donde iba. Mira, por ejemplo, ronda de traduciones. En ese periodo tengo un workspace del gnome con, creo que eran, 5 xterms: tres están en los directorios yast/po, lcn/po, packages/po (para hacer svn xxx). Dos tienen mc: un mc con el directorio de descarga de lo que recibo del verbum por correo, y a la derecha el directorio de destino del targz, y el otro mc abora mismo no recuerdo (tengo un script que me abre los cinco xterms). En otro workspace tengo el firefox en el verbum, y quizás con tabs en otros sitios relacionados; un xterm que me arranca el kbabel con los parámetros de linea de comandos adecuados, en el directorio adecuado; y por ultimo el kbabel, y a veces el catalog. Son unos... 6 xterms, y otros tres programas, mínimo. Otro ejemplo, del workspace donde estoy ahora mismo. Un xterm con alpine. El gkrellm. Mi contador de correo, hecho en pascal. Un xterm con links (Bug 402513, en este momento). Un xterm en latin1 con Golded+ Un xterm de root con mc Un gnome-terminal con 15 tabs (que no conté el otro dia, pero que se abren automáticamente). La mayoría son tailf de logs. Dirás: guarda sesión, y la recuperas al empezar. Vale, y lo hago: pero no todo se recupera, es un bug del gnome. Y aún no siendolo, el interior de los xterms no se recupera. Y en la 11.1 guardar sesión no guarda absolutamente nada, por cierto. ¡Ah! El propio gnome tarda un rato en recuperar sesión, que es trabajo de disco mayormente. Mira, cada vez que arranco, ir al menú del gnome supone esperar varios segundos a que el disco lea todo el arbol del menú, con todos sus iconos, tiempo durante el cual el menú no responde en absoluto, y todos los applets del panel se paran (incluso el reloj). No son dos o tres segundos, es más bien unos diez. La segunda vez, la operación de ver el menú es instantánea, debe tener una caché.
Si no lo haces es porque no quieres, no porque no se pueda hacer, es decir, que si vas "lento" es por una decisión tuya.
Narices.
Un dia te vienes por aquí con un portatil y abres todo lo que yo tengo abierto, a ver lo que tardas.
¿No me puedo llevar algún servidorcito? O:-)
Si cabe... X'-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkodl7MACgkQtTMYHG2NR9XR8ACeNiyZeVMVEo0GbIWlV4wcYv0b XqUAnj1Z6b8n2ihDs3deF9T9NAarst8u =l9PK -----END PGP SIGNATURE-----