[opensuse-es] ¿Cuando se habilita la suspensión automática?
Hola lista Tengo una curiosidad, y es la del encabezado. Esto es debido a que estaba realizando un DVD y le pedí a DVDStyler que le pusiera la corrección de error por redundancia, dado que sobro espacio en lo que había realizado. Como este trabajo tarda un poco me fui y al volver me encuentro que la máquina se había apagado, pensé que había terminado y como no la use se apago, que sería lo lógico. Pero al encenderla nuevamente me encuentro que no termino el trabajo y continúo con él. Si esta trabajando y unos de los procesadores esta al 100% aunque los otros solo al 10% ¿no tendría que apagarse cuando se termine lo que esta haciendo?. Además el disco rígido esta trabajando también dado que no tengo tanta memoria en la PC como para cargar el contenido de un DVD y sus temporales. Gracias por vuestras respuestas, Alfredo -- 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-05-19 a las 21:57 -0300, Alfredo J. Delaiti escribió:
Tengo una curiosidad, y es la del encabezado.
(...)
Si esta trabajando y unos de los procesadores esta al 100% aunque los otros solo al 10% ¿no tendría que apagarse cuando se termine lo que esta haciendo?. Además el disco rígido esta trabajando también dado que no tengo tanta memoria en la PC como para cargar el contenido de un DVD y sus temporales.
Creo que tanto la suspensión como la hibernación se activan por dos eventos: a) Temporizado: definiendo un tiempo "x" tras el cual si no hay actividad por parte del usuario (del usaurio, es decir, ratón o teclado sin actividad) pasa a suspensión o hibernación. b) Manual: el usuario ejecuta la acción de forma interesada, bien tecleando el comando directamente o bien definiendo eventos como pulsar el botón de apagado, bajar la tapa del portátil, batería baja... que activan la suspensión o hibernación. Es decir, que la suspensión o hibernación es independiente de la actividad del equipo. Si estás jugando al Quake y fuerzas la hibernación, pues debería almacenar los procesos que tenga en ejecución y apagarse O:-) 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 Me llama la atención porque cuando ejecuto cron para que corra mencoder para grabar algún programa de TV, no entra en suspensión hasta que > El 2009-05-19 a las 21:57 -0300, Alfredo J. Delaiti escribió:
Tengo una curiosidad, y es la del encabezado.
(...)
Si esta trabajando y unos de los procesadores esta al 100% aunque los otros solo al 10% ¿no tendría que apagarse cuando se termine lo que esta haciendo?. Además el disco rígido esta trabajando también dado que no tengo tanta memoria en la PC como para cargar el contenido de un DVD y sus temporales.termina mencoder
Como dado OpenSuSE 11.0 de 64bit y KDE3 Gracias, Alfredo Camaleón escribió:
Creo que tanto la suspensión como la hibernación se activan por dos eventos:
a) Temporizado: definiendo un tiempo "x" tras el cual si no hay actividad por parte del usuario (del usaurio, es decir, ratón o teclado sin actividad) pasa a suspensión o hibernación.
b) Manual: el usuario ejecuta la acción de forma interesada, bien tecleando el comando directamente o bien definiendo eventos como pulsar el botón de apagado, bajar la tapa del portátil, batería baja... que activan la suspensión o hibernación.
Es decir, que la suspensión o hibernación es independiente de la actividad del equipo. Si estás jugando al Quake y fuerzas la hibernación, pues debería almacenar los procesos que tenga en ejecución y apagarse O:-)
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-21 a las 00:50 -0300, Alfredo J. Delaiti escribió:
hola
Me llama la atención porque cuando ejecuto cron para que corra mencoder para grabar algún programa de TV, no entra en suspensión hasta que > El 2009-05-19 a las 21:57 -0300, Alfredo J. Delaiti escribió:
¿hasta que...? - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoU4GgACgkQtTMYHG2NR9WQvgCggpyYUHR1yfd9Ec5Vi4XDQ6p8 nLQAoIRNLFkNR++DswvDMKw7/t62irqT =h1Bu -----END PGP SIGNATURE-----
Hola Ooops, se ha roto el mensaje, que raro! Lo que escribía y se perdió es que no entra en suspernsión hasta que mencoder termina. Tener en cuenta que no estoy usando la pc, en este caso la estoy utilizando como videograbadora. gracias, Alfredo Carlos E. R. escribió:
El 2009-05-21 a las 00:50 -0300, Alfredo J. Delaiti escribió:
hola
Me llama la atención porque cuando ejecuto cron para que corra mencoder para grabar algún programa de TV, no entra en suspensión hasta que > El 2009-05-19 a las 21:57 -0300, Alfredo J. Delaiti escribió:
¿hasta que...?
-- Saludos Carlos E. R.
-- 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-05-22 a las 00:44 -0300, Alfredo J. Delaiti escribió:
Lo que escribía y se perdió es que no entra en suspernsión hasta que mencoder termina. Tener en cuenta que no estoy usando la pc, en este caso la estoy utilizando como videograbadora.
Haz una prueba "manual": lanza la rutina del mencoder y manda al equipo a hibernar, para ver qué es lo que hace. Luego revisas el registro de actividad en /var/log/pm-suspend.log P.S. Por cierto, ya funciona la hibernación de suse en VirtualBox :-) 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-05-22 a las 21:26 +0200, Camaleón escribió:
El 2009-05-22 a las 00:44 -0300, Alfredo J. Delaiti escribió:
Lo que escribía y se perdió es que no entra en suspernsión hasta que mencoder termina. Tener en cuenta que no estoy usando la pc, en este caso la estoy utilizando como videograbadora.
Haz una prueba "manual": lanza la rutina del mencoder y manda al equipo a hibernar, para ver qué es lo que hace.
Hibernará.
P.S. Por cierto, ya funciona la hibernación de suse en VirtualBox :-)
Reporté un bug similar con vmware, lo resolvieron. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoXJf4ACgkQtTMYHG2NR9V9SwCfcMGcN5cO0YbEhzdMGqaU7Ead 9nMAn30RaO8E7ZQCnEIVTo97EdJbk3zz =4Rhu -----END PGP SIGNATURE-----
Hola Camaleón escribió:
Haz una prueba "manual": lanza la rutina del mencoder y manda al equipo a hibernar, para ver qué es lo que hace.
Se "duerme"
Luego revisas el registro de actividad en /var/log/pm-suspend.log
No veo nada raro, ni línea alguna relativa a mencoder, solo veo los módulos cargados del kernel, control si se puede suspender, espacio de memoria swap disponible y comandos de inicio para grub. No se para que deseas que mire el registro. La pregunta la hice porque me parece bien que si no se esta haciendo nada se "duerma" el equipo, pero si le dí una tarea específica que hacer y encima consume mucha cpu, no tendría que suspender hasta que el nivel de actividad baje hasta un cierto nivel y se mantenga por debajo de ese umbral durante un cierto tiempo o la tarea finalice. Imaginemos que estamos trabajando con algún CAD, edición de video, compilando el kernel o cualquier proceso que lleve tiempo y una carga considerable para la cpu, lo lógico es que no voy a estar moviendo el ratón o tipeando para que no se suspenda, me parece que tampoco es el ideal ir cada vez que le damos a nuestra máquina un trabajo que lleve mucho tiempo tener que desactivar la suspensión para que la labor se lleve acabo. Al menos esa es mi idea de como tendría que funcionar. Es probable que se pueda configurar algo de esto que planteo, pero como lo desconozco es que hice la pregunta. Aunque una de las respuesta de Carlos es que no se pude. Saludos, Alfredo -- 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-05-23 a las 01:17 -0300, Alfredo J. Delaiti escribió:
Camaleón escribió:
Haz una prueba "manual": lanza la rutina del mencoder y manda al equipo a hibernar, para ver qué es lo que hace.
Se "duerme"
Lo que dije que pasaría.
Luego revisas el registro de actividad en /var/log/pm-suspend.log
No veo nada raro, ni línea alguna relativa a mencoder, solo veo los módulos cargados del kernel, control si se puede suspender, espacio de memoria swap disponible y comandos de inicio para grub. No se para que deseas que mire el registro.
Porque cuando rehúsa dormirse dice el porqué.
La pregunta la hice porque me parece bien que si no se esta haciendo nada se "duerma" el equipo, pero si le dí una tarea específica que hacer y encima consume mucha cpu, no tendría que suspender hasta que el nivel de actividad baje hasta un cierto nivel y se mantenga por debajo de ese umbral durante un cierto tiempo o la tarea finalice.
Ya dije que la suspensión automática se dispara por inactividad del usuario (teclado y ratón), no por inactividad del sistema. Aunque tengas un millar de usuarios activos por telnet y cientos de conexiones http, ftp, nfs, y samba, activas, suspenderá igual si no hay nadie usándolo activamente localmente. Eso es uno de los problemas que reportamos en el bugzilla cuando pusieron la suspensión automática por defecto, y no nos hicieron ni caso - hasta que vino IBM y protestó, y entonces aceptaron los argumentos de ellos que eran iguales que los nuestros. Instructivo incidente >:-|
Imaginemos que estamos trabajando con algún CAD, edición de video, compilando el kernel o cualquier proceso que lleve tiempo y una carga considerable para la cpu, lo lógico es que no voy a estar moviendo el ratón o tipeando para que no se suspenda, me parece que tampoco es el ideal ir cada vez que le damos a nuestra máquina un trabajo que lleve mucho tiempo tener que desactivar la suspensión para que la labor se lleve acabo. Al menos esa es mi idea de como tendría que funcionar.
Claro.
Es probable que se pueda configurar algo de esto que planteo, pero como lo desconozco es que hice la pregunta. Aunque una de las respuesta de Carlos es que no se pude.
No, no se puede configurar. Tienen que definir un protocolo adecuado para que el root pueda definir bajo que condiciones se permite la hibernación automática del sistema: carga local, usuarios remotos, tareas en ejecución, usuarios que pueden dispararla, tareas que deben impedir la hibernación, programar el despertar automático para ejecutar tareas programadas; sin olvidar el tipo de equipo (sobremesa / portatil / servidor)... Está todo eso muy verde, no existe nada de lo que digo. Y no obstante, se empeñaron en activar la suspensión automática por defecto para todos los usuarios en openSUSE. Afortunadamente para todos nosotros, los de IBM les convencieron de que la quitaran. Si me equivoco en algún detalle del relato, testigos hay aquí que lo pueden contar... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoYm4kACgkQtTMYHG2NR9UiiQCfe7m2NMl/BKvtYKL1uddsFf5q k0wAnjQOkwU5ItR9EiLKZbphSGn/sUm+ =mGzz -----END PGP SIGNATURE-----
El 23/05/09, Alfredo J. Delaiti escribió:
Haz una prueba "manual": lanza la rutina del mencoder y manda al equipo a hibernar, para ver qué es lo que hace.
Se "duerme"
O.k.
Luego revisas el registro de actividad en /var/log/pm-suspend.log
No veo nada raro, ni línea alguna relativa a mencoder, solo veo los módulos cargados del kernel, control si se puede suspender, espacio de memoria swap disponible y comandos de inicio para grub. No se para que deseas que mire el registro.
Porque decías que el equipo no hibernaba cuando debería hacerlo y es ahí donde puedes comprobar lo que está haciendo: si se duerme, si lo intenta y falla o si ni siquiera se llega a activar la rutina de hibernación... y en qué momento lo hace.
La pregunta la hice porque me parece bien que si no se esta haciendo nada se "duerma" el equipo, pero si le dí una tarea específica que hacer y encima consume mucha cpu, no tendría que suspender hasta que el nivel de actividad baje hasta un cierto nivel y se mantenga por debajo de ese umbral durante un cierto tiempo o la tarea finalice. Imaginemos que estamos trabajando con algún CAD, edición de video, compilando el kernel o cualquier proceso que lleve tiempo y una carga considerable para la cpu, lo lógico es que no voy a estar moviendo el ratón o tipeando para que no se suspenda, me parece que tampoco es el ideal ir cada vez que le damos a nuestra máquina un trabajo que lleve mucho tiempo tener que desactivar la suspensión para que la labor se lleve acabo. Al menos esa es mi idea de como tendría que funcionar. Es probable que se pueda configurar algo de esto que planteo, pero como lo desconozco es que hice la pregunta. Aunque una de las respuesta de Carlos es que no se pude.
No es tan sencillo. Para empezar, hay que definir qué es "no estar haciendo nada" ;-) El sistema siempre está haciendo "algo", tiene procesos que gestionar. Aunque lo lógico (desde nuestro punto de vista) es esperar que el equipo no hiberne mientras esté desarrollando una actividad "x", el sistema (al menos de momento) no distingue entre: a) estar pilotando un avión b) estar viendo un vídeo en Youtube Y si le toca activar la suspensión... pues la activa, y ahí nos quedamos, con el avión en pleno vuelo y con el vídeo a medias >:-) Hombre, lo lógico sería que se pudiera configurar un poco más esto de la suspensión. Y supongo que así será... en breve. Por ejemplo, que el usuario pueda definir un nivel de carga de procesos, de cpu o de uso de memoria en la que se cancele la suspensión si está al "n %", y qué hacer en ese caso: volver a intentar suspender a los tantos minutos, esperar hasta que tenga una actividad baja o no volver a intentarlo. Y dentro de unos años, estoy segura de que el sistema podrá tomar esa decisión sin contar con el usuario. La suspensión será completamente automática y transparente (y espero que siga siendo opcional :-P): el sistema decidirá por sí mismo cuándo es el mejor momento para hacerlo . Por el momento, yo me conformaría con que sencillamente funcione y se vuelva a reanimar el equipo :-}. La verdad es que no la utilizo, no me fío, no le veo mucha utilidad, aún está poco madura y no hay certificación de por medio, así que es una ruleta rusa: el equipo puede suspender hoy pero tras la actualización del hal de mañana o del controlador de la tarjeta gráfica (por poner un ejemplo) puede dejar de hacerlo. 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
On Sunday 24 May 2009 10:32:32 Camaleón wrote:
Por ejemplo, que el usuario pueda definir un nivel de carga de procesos, de cpu o de uso de memoria en la que se cancele la suspensión si está al "n %", y qué hacer en ese caso: volver a intentar suspender a los tantos minutos, esperar hasta que tenga una actividad baja o no volver a intentarlo.
Por carga no creo que sea una buena solución, la misma situación daría comportamientos distintos en maquinas distintas. Supongo que se puede intentar con algo que relacione la carga y la velocidad equivalente de la maquina. Esto deberla ser mas o menos constante para una situación concreta. La velocidad debería ser equivalente, no la del reloj, para evitar efectos de cache, marca de procesador, etc. -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-24 a las 10:46 +0200, Lluis escribió:
Por ejemplo, que el usuario pueda definir un nivel de carga de procesos, de cpu o de uso de memoria en la que se cancele la suspensión si está al "n %", y qué hacer en ese caso: volver a intentar suspender a los tantos minutos, esperar hasta que tenga una actividad baja o no volver a intentarlo.
Por carga no creo que sea una buena solución, la misma situación daría comportamientos distintos en maquinas distintas.
No se puede hacer por carga de sistema, hay que considerar varios parámetros distintos, tanto carga como tipo de uso del sistema. Un servidor de ficheros podría hibernar si en ese momento no tiene ficheros abiertos ni conexiones _activas_, es decir, conexiones que estén haciendo algo. Una conexión de red inteligente podría despertarlo en el momento en que haya actividad de red dirigida a él específicamente - si tuvieramos una técnica fiable de suspensión instantánea, y si tuvieramos esa tarjeta de red tan inteligente (que no despierte por un simple ing). Ese tipo de técnicas ahorarría un montón de energía en una sala de servidores, y eso es dinero. Hay máquinas con procesador que están diseñadas para eso de forma extrema... procesan algo, se duermen, y un tick de reloj las despierta para que procesen algo y se vuelvan a dormir (o ralentizan mucho el reloj dela cpu). Se usa cuando se alimentan a pilas. El procesador tiene pines para mandar a dormir o despertar: congela toda la actividad hasta que llegue una interrupción. Logicamente también la memoria y los periféricos tienen que ser ahorradores de energía. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoZKIsACgkQtTMYHG2NR9WxrgCgmLVFJq0Gj6EJEtE7/ycVXH8i LMcAn1roEv8S7PVw9W+IwS8NuY1VRTgm =OHoD -----END PGP SIGNATURE-----
El 2009-05-24 a las 12:59 +0200, Carlos E. R. escribió:
El 2009-05-24 a las 10:46 +0200, Lluis escribió:
Por ejemplo, que el usuario pueda definir un nivel de carga de procesos, de cpu o de uso de memoria en la que se cancele la suspensión si está al "n %", y qué hacer en ese caso: volver a intentar suspender a los tantos minutos, esperar hasta que tenga una actividad baja o no volver a intentarlo.
Por carga no creo que sea una buena solución, la misma situación daría comportamientos distintos en maquinas distintas.
No se puede hacer por carga de sistema, hay que considerar varios parámetros distintos, tanto carga como tipo de uso del sistema.
Pero es configurable, según el sistema y el uso. A ver, la idea es que si un servidor de vídeo o de aplicaciones 3D se encuentra en un proceso de codificación o renderizado y la cpu está al 70% de uso, y se ha configurado un margen de >50% como condición para no hibernar, pues que no se ejecute la rutina de hibernación "en ese momento". Otra opción podría ser el uso de una "lista blanca" de procesos o programas. Si se encuentran en ejecución, que se aborte la hibernación. En fin, que opciones para flexibilizar si se debe lanzar el proceso de hibernación, haylas :-) 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-05-24 a las 13:36 +0200, Camaleón escribió:
Por carga no creo que sea una buena solución, la misma situación daría comportamientos distintos en maquinas distintas.
No se puede hacer por carga de sistema, hay que considerar varios parámetros distintos, tanto carga como tipo de uso del sistema.
Pero es configurable, según el sistema y el uso.
"Sería" configurable. Actualmente no lo es en absoluto.
A ver, la idea es que si un servidor de vídeo o de aplicaciones 3D se encuentra en un proceso de codificación o renderizado y la cpu está al 70% de uso, y se ha configurado un margen de >50% como condición para no hibernar, pues que no se ejecute la rutina de hibernación "en ese momento".
En realidad no debe hibernar hasta que termine ese proceso; y posiblemente sólo ese proceso sabe cual es ese momento. Si te fijas, el avidemux tiene un "click-box" para apagar el ordenador al terminar, pero no han puesto uno para hibernar, o para ejecutar un proceso cualquiera. Y no se puede facilmente trasladar la decisión a otro programa, porque ese tipo de procesos multimedia a veces trabajan en equipo varios ordenadores, y uno sólo no puede decidir apagarse: suponte que es el proceso director de los demás, o que está esperando a que otro termine de procesar otro cacho para continuar su propio trabajo, y mientras tanto está a la espera, sin uso de cpu. Sólo con un uso bajo de CPU no puedes decidir hibernar como norma general.
Otra opción podría ser el uso de una "lista blanca" de procesos o programas. Si se encuentran en ejecución, que se aborte la hibernación.
En fin, que opciones para flexibilizar si se debe lanzar el proceso de hibernación, haylas :-)
Pero no han hecho nada. Haría falta un programa controlador para decidir cuando si y cuando no, basandose en una lista compleja de "decisionables". Y hace falta un API para que cada proceso indique si es un buen momento para hibernar o no, e incluso para decirle a cada proceso que acaba de deshibernar, por si tienen que hacer tareas adecuadas. Por ejemplo, un proceso puede ser hibernado y despertar a las 20 horas; sus calculos de tiempo se van al traste y muestran resultados erróneos, pero serían correctos si el kernel le avisa que ha estado durmiendo 20 horas y que ajuste lo que haya menester. Un caso más grave es un proceso que colabora con otros en red: al despertar debe indagar el estado de los demás, teniendo en cuenta su "siesta". No es tan fácil; y no hay nada hecho, o por lo menos, conocido. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoZa54ACgkQtTMYHG2NR9WNDwCfZcvfa5/XWvreobbEw0j2IWyn I1sAniF40YP0XH59HI29lNDkxZj8cxch =9wZC -----END PGP SIGNATURE-----
El 24/05/09, Carlos E. R. escribió:
El 2009-05-24 a las 13:36 +0200, Camaleón escribió:
Pero es configurable, según el sistema y el uso.
"Sería" configurable. Actualmente no lo es en absoluto.
No claro, ya lo he dicho en el mensaje anterior. Estamos hablando de "cómo debería ser" o de lo que el usuario espera que haga. A día de hoy la hibernación y la suspensión están en pañales, por eso no la uso en los equipos: son poco configurables y dan más problemas de los que solucionan. Al fin y al cabo, sólo el argumento de "ahorro energético" por sí mismo no me convence, necesitaría ver otros beneficios, para el equipo, por ejemplo. ¿En qué mejora la "hibernación" el estado de "apagado" de un equipo? ¿rapidez en el inicio, menos consumo energético? No es suficiente >:-)
A ver, la idea es que si un servidor de vídeo o de aplicaciones 3D se encuentra en un proceso de codificación o renderizado y la cpu está al 70% de uso, y se ha configurado un margen de >50% como condición para no hibernar, pues que no se ejecute la rutina de hibernación "en ese momento".
En realidad no debe hibernar hasta que termine ese proceso; y posiblemente sólo ese proceso sabe cual es ese momento.
Si te fijas, el avidemux tiene un "click-box" para apagar el ordenador al terminar, pero no han puesto uno para hibernar, o para ejecutar un proceso cualquiera.
Y no se puede facilmente trasladar la decisión a otro programa, porque ese tipo de procesos multimedia a veces trabajan en equipo varios ordenadores, y uno sólo no puede decidir apagarse: suponte que es el proceso director de los demás, o que está esperando a que otro termine de procesar otro cacho para continuar su propio trabajo, y mientras tanto está a la espera, sin uso de cpu.
Pero eso ya depende de cada configuración individual y de cada sistema. Para usos sencillos, una personalización básica sería suficiente. Obviamente, si tienes una configuración compleja y tienes ciertas necesidades, la hibernación no te hace ningún papel y no la activas.
Sólo con un uso bajo de CPU no puedes decidir hibernar como norma general.
Bajo, no, alto. Un uso bajo de CPU no te dice nada, claro.
Otra opción podría ser el uso de una "lista blanca" de procesos o programas. Si se encuentran en ejecución, que se aborte la hibernación.
En fin, que opciones para flexibilizar si se debe lanzar el proceso de hibernación, haylas :-)
Pero no han hecho nada.
Nada, ninguna opción. Al menos de momento.
Haría falta un programa controlador para decidir cuando si y cuando no, basandose en una lista compleja de "decisionables". Y hace falta un API para que cada proceso indique si es un buen momento para hibernar o no, e incluso para decirle a cada proceso que acaba de deshibernar, por si tienen que hacer tareas adecuadas.
Por ejemplo, un proceso puede ser hibernado y despertar a las 20 horas; sus calculos de tiempo se van al traste y muestran resultados erróneos, pero serían correctos si el kernel le avisa que ha estado durmiendo 20 horas y que ajuste lo que haya menester. Un caso más grave es un proceso que colabora con otros en red: al despertar debe indagar el estado de los demás, teniendo en cuenta su "siesta".
No es tan fácil; y no hay nada hecho, o por lo menos, conocido.
Yo no lo veo tan complejo de implementar... y espero que dentro de poco vayan ampliando las opciones, porque si no permiten al usuario tener un control total del proceso, terminarán por no activarla, o a usarla sólo en casos muy concretos y definidos, lo cual no tiene sentido. Ten en cuenta que hibernar es el sustituto de "apagar", no de "suspender". La suspensión debería utilizarse mucho más que la hibernación pero ¿qué sucede? pues que funciona peor que la hibernación (cuando funciona, claro, que en algunos casos ni eso) y la gente termina por usar un proceso que realmente no sería el más indicado para el caso. 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 Camaleón escribió:
No claro, ya lo he dicho en el mensaje anterior. Estamos hablando de "cómo debería ser" o de lo que el usuario espera que haga.
A día de hoy la hibernación y la suspensión están en pañales, por eso no la uso en los equipos: son poco configurables y dan más problemas de los que solucionan. Al fin y al cabo, sólo el argumento de "ahorro energético" por sí mismo no me convence, necesitaría ver otros beneficios, para el equipo, por ejemplo.
¿En qué mejora la "hibernación" el estado de "apagado" de un equipo? ¿rapidez en el inicio, menos consumo energético? No es suficiente >:-)
Este es un ejemplo real donde se ve su beneficio. En unas oficinas construidas hace unos 25 años hay cerca de una docena de pc donde sus operadores están constantemente saliendo para hacer trámites por lo que la pc esta normalmente sin usar, dado el tipo de actividad que realizan no comparten las pc. El problema que tienen es el dimensionamiento del sistema eléctrico fue hecho para hace 25 años (donde no había computadoras o era algo muy raro) y ahora con tanta cantidad de pc y aires acondicionados están al límite, de hecho cada vez que intentan conectar algún equipo extra los sistemas de protección eléctrica se accionan dejándoles a oscuras y sin poder trabajar por unos minutos. Puesto que reemplazar el sistema eléctrico tiene un costo que por ahora no desean invertir y tampoco pueden parar 1 o 2 días para su reemplazo la solución que les propuse y lleve a cabo fue activar el sistema de ahorro de energía de las pc, con lo que se bajo un poco el consumo porque en promedio solo la mitad de las máquinas están funcionando simultáneamente. Otro caso, es el que me vendría, por ejemplo, en mi caso, es el de indicar que si tal programa se esta ejecutando entonces no se inicie la suspensión automática. Creo que esto último tiene que ser algo simple de implementar. Saludos Alfredo. -- 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-05-24 a las 18:41 -0300, Alfredo J. Delaiti escribió:
Camaleón escribió:
No claro, ya lo he dicho en el mensaje anterior. Estamos hablando de "cómo debería ser" o de lo que el usuario espera que haga.
A día de hoy la hibernación y la suspensión están en pañales, por eso no la uso en los equipos: son poco configurables y dan más problemas de los que solucionan. Al fin y al cabo, sólo el argumento de "ahorro energético" por sí mismo no me convence, necesitaría ver otros beneficios, para el equipo, por ejemplo.
¿En qué mejora la "hibernación" el estado de "apagado" de un equipo? ¿rapidez en el inicio, menos consumo energético? No es suficiente >:-)
Este es un ejemplo real donde se ve su beneficio.
En unas oficinas construidas hace unos 25 años hay cerca de una docena de pc donde sus operadores están constantemente saliendo para hacer trámites por lo que la pc esta normalmente sin usar, dado el tipo de actividad que realizan no comparten las pc. El problema que tienen es el dimensionamiento del sistema eléctrico fue hecho para hace 25 años (donde no había computadoras o era algo muy raro) y ahora con tanta cantidad de pc y aires acondicionados están al límite, de hecho cada vez que intentan conectar algún equipo extra los sistemas de protección eléctrica se accionan dejándoles a oscuras y sin poder trabajar por unos minutos. Puesto que reemplazar el sistema eléctrico tiene un costo que por ahora no desean invertir y tampoco pueden parar 1 o 2 días para su reemplazo la solución que les propuse y lleve a cabo fue activar el sistema de ahorro de energía de las pc, con lo que se bajo un poco el consumo porque en promedio solo la mitad de las máquinas están funcionando simultáneamente.
Llegará un momento en el que tengan que acometer una ampliación de la instalación de red y ampliar la potencia, eso es inevitable. Sería interesante conocer el consumo anterior y posterior de los equipos para conocer las cifras reales porque desde luego una docena de PC de oficina no debería tener un consumo desorbitado (algo superior a los 150W/h por equipo). Y si el equipo no hace nada, apagado está mejor :-P
Otro caso, es el que me vendría, por ejemplo, en mi caso, es el de indicar que si tal programa se esta ejecutando entonces no se inicie la suspensión automática. Creo que esto último tiene que ser algo simple de implementar.
Pues en tu caso no lo veo tan claro. Si necesitas que el equipo esté "trabajando" con el mencoder, entonces ¿para qué "hibernarlo"? Hiberbar es sinónimo de "no necesito el equipo, lo voy a apagar". 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-05-25 a las 00:34 +0200, Camaleón escribió:
Este es un ejemplo real donde se ve su beneficio.
En unas oficinas construidas hace unos 25 años hay cerca de una docena de pc donde sus operadores están constantemente saliendo para hacer trámites por lo que la pc esta normalmente sin usar, dado el tipo de actividad que realizan no comparten las pc. El problema que tienen es el dimensionamiento del sistema eléctrico fue hecho para hace 25 años (donde no había computadoras o era algo muy raro) y ahora con tanta cantidad de pc y aires acondicionados están al límite, de hecho cada vez que intentan conectar algún equipo extra los sistemas de protección eléctrica se accionan dejándoles a oscuras y sin poder trabajar por unos minutos. Puesto que reemplazar el sistema eléctrico tiene un costo que por ahora no desean invertir y tampoco pueden parar 1 o 2 días para su reemplazo la solución que les propuse y lleve a cabo fue activar el sistema de ahorro de energía de las pc, con lo que se bajo un poco el consumo porque en promedio solo la mitad de las máquinas están funcionando simultáneamente.
Llegará un momento en el que tengan que acometer una ampliación de la instalación de red y ampliar la potencia, eso es inevitable.
Sería interesante conocer el consumo anterior y posterior de los equipos para conocer las cifras reales porque desde luego una docena de PC de oficina no debería tener un consumo desorbitado (algo superior a los 150W/h por equipo).
Y si el equipo no hace nada, apagado está mejor :-P
Pues eso, hibernado está apagado. La gente no apaga el ordenador al irse porque al volver tienen que encenderlo y arrancar todos los programas que estaban usando. En mi caso, eso supone casi el cuarto de hora... con lo que arrancar se vuelve tedioso, mientras que hibernar me lo soluciona: arranco en 1 minuto con todas las tareas en ejecución, incluso los ficheros abiertos por donde iba.
Otro caso, es el que me vendría, por ejemplo, en mi caso, es el de indicar que si tal programa se esta ejecutando entonces no se inicie la suspensión automática. Creo que esto último tiene que ser algo simple de implementar.
Pues en tu caso no lo veo tan claro.
Si necesitas que el equipo esté "trabajando" con el mencoder, entonces ¿para qué "hibernarlo"? Hiberbar es sinónimo de "no necesito el equipo, lo voy a apagar".
No, no lo necesito ahora mismo. Yo puedo hibernarlo si me voy aunque esté ejecutando una tarea pesada como mencoder; ya seguirá por donde estaba cuando vuelva. No tengo que dejar una máquina encendida, que siempre es un peligro si no hay nadie en la sala. Si no pudiera hibernarla no podría irme, porque no puedo apagarla y perder el trabajo en curso. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoZ6KkACgkQtTMYHG2NR9VQYQCfa39IjnfV9hiBDASQU9ezNMJm ZdUAnj3LJrFatizJvzL8hMDCUiHFAysR =k9n1 -----END PGP SIGNATURE-----
El 2009-05-25 a las 02:38 +0200, Carlos E. R. escribió:
El 2009-05-25 a las 00:34 +0200, Camaleón escribió:
Y si el equipo no hace nada, apagado está mejor :-P
Pues eso, hibernado está apagado.
Pero como he dicho antes, sólo tienes la ventaja del tiempo de reinicio (bueno, y la del consumo) que en muchos casos es nula. Y en otros casos resulta inviable porque la hibernación no funciona, da problemas o no restaura correctamente. Y si estás gestionando en remoto, sin entorno X, sin teclado ni ratón, la cosa se complica más. Habría que tirar de alguna tarjeta ipmi.
La gente no apaga el ordenador al irse porque al volver tienen que encenderlo y arrancar todos los programas que estaban usando. En mi caso, eso supone casi el cuarto de hora... con lo que arrancar se vuelve tedioso, mientras que hibernar me lo soluciona: arranco en 1 minuto con todas las tareas en ejecución, incluso los ficheros abiertos por donde iba.
Sólo digo que no siempre es ventajoso.
Otro caso, es el que me vendría, por ejemplo, en mi caso, es el de indicar que si tal programa se esta ejecutando entonces no se inicie la suspensión automática. Creo que esto último tiene que ser algo simple de implementar.
Pues en tu caso no lo veo tan claro.
Si necesitas que el equipo esté "trabajando" con el mencoder, entonces ¿para qué "hibernarlo"? Hiberbar es sinónimo de "no necesito el equipo, lo voy a apagar".
No, no lo necesito ahora mismo.
Pues como esté programado para grabar alguna película y se vaya a "dormir" ya me dirás la gracia que te da >:-)
Yo puedo hibernarlo si me voy aunque esté ejecutando una tarea pesada como mencoder; ya seguirá por donde estaba cuando vuelva. No tengo que dejar una máquina encendida, que siempre es un peligro si no hay nadie en la sala.
Puedes dejar la sesión bloqueada y configurar la hibernación para que salte si se va la luz y no hay un SAI detrás.
Si no pudiera hibernarla no podría irme, porque no puedo apagarla y perder el trabajo en curso.
Si tu equipo tarda 15 minutos en arrancar, en tu caso es comprensible. Pero no todos los equipos son tan lentos >:-) 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-05-25 a las 08:41 +0200, Camaleón escribió:
El 2009-05-25 a las 02:38 +0200, Carlos E. R. escribió:
El 2009-05-25 a las 00:34 +0200, Camaleón escribió:
Y si el equipo no hace nada, apagado está mejor :-P
Pues eso, hibernado está apagado.
Pero como he dicho antes, sólo tienes la ventaja del tiempo de reinicio (bueno, y la del consumo) que en muchos casos es nula. Y en otros casos resulta inviable porque la hibernación no funciona, da problemas o no restaura correctamente.
Yo de ti, si un equipo actual no hiberna, lo devolvía.
Y si estás gestionando en remoto, sin entorno X, sin teclado ni ratón, la cosa se complica más. Habría que tirar de alguna tarjeta ipmi.
¡En modo remoto no puedes hibernar! No, porque no lo puedes despertar como no sea desde otro equipo "cruzado".
La gente no apaga el ordenador al irse porque al volver tienen que encenderlo y arrancar todos los programas que estaban usando. En mi caso, eso supone casi el cuarto de hora... con lo que arrancar se vuelve tedioso, mientras que hibernar me lo soluciona: arranco en 1 minuto con todas las tareas en ejecución, incluso los ficheros abiertos por donde iba.
Sólo digo que no siempre es ventajoso.
Puede. Para mí, es una bendición poder hacerlo.
Si necesitas que el equipo esté "trabajando" con el mencoder, entonces ¿para qué "hibernarlo"? Hiberbar es sinónimo de "no necesito el equipo, lo voy a apagar".
No, no lo necesito ahora mismo.
Pues como esté programado para grabar alguna película y se vaya a "dormir" ya me dirás la gracia que te da >:-)
Bueno, la gracia es que no habrá terminado el trabajo, pero continúa haciéndolo en cuanto lo despierte. Ah, espera, yo hablo de tener el mencoder o avidemux para procesar una película ya grabada. Tu dices de tener el PC para grabar algo de la tele: vale, eso no sería gracioso. Pero llevo diciendo que la hibernación automática está verdísima desde que a alguien se le ocurrió activarla por defecto en la SUSE, y lo sabes perfectamente ;-) - para poder hacerlo, al programar una tarea para determinada hora el equipo tendría que programar el reloj de la CMOS para despertar el ordenador a la hora adecuada. No es tan difícil, es lo que hace mi cacharrín de la tele, se despierta sólo y arranca (este no hiberna, arranca), y cuando llego me encuentro la serie del CSI grabada.
Yo puedo hibernarlo si me voy aunque esté ejecutando una tarea pesada como mencoder; ya seguirá por donde estaba cuando vuelva. No tengo que dejar una máquina encendida, que siempre es un peligro si no hay nadie en la sala.
Puedes dejar la sesión bloqueada y configurar la hibernación para que salte si se va la luz y no hay un SAI detrás.
Si no hay SAI no hay hibernación posible: se va la luz y a freír monas >:-P Yo tengo mi SAI configurada de esa forma precisamente: hay un daemon escuchando en el puerto USB (tipo 1, por cierto), y cuando falla la luz, en dos minutos dispara la hibernación, y no pierdo ningún dato ni tarea.
Si no pudiera hibernarla no podría irme, porque no puedo apagarla y perder el trabajo en curso.
Si tu equipo tarda 15 minutos en arrancar, en tu caso es comprensible. Pero no todos los equipos son tan lentos >:-)
No es que el equipo sea lento. El arranque es normal, son la cantidad de tareas y ventanas que arranco manualmente lo que tarda. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkocP2sACgkQtTMYHG2NR9XY6gCdGCAz3zDxGAwMWpZ+/Wf+cwA1 NQYAniTUqi9ENPALBZvtNSzz/haXaQ1Q =Gm0k -----END PGP SIGNATURE-----
El 2009-05-26 a las 21:13 +0200, Carlos E. R. escribió:
El 2009-05-25 a las 08:41 +0200, Camaleón escribió:
Pero como he dicho antes, sólo tienes la ventaja del tiempo de reinicio (bueno, y la del consumo) que en muchos casos es nula. Y en otros casos resulta inviable porque la hibernación no funciona, da problemas o no restaura correctamente.
Yo de ti, si un equipo actual no hiberna, lo devolvía.
Sí, claro. Y cuando le diga al que me suministra los equipos que la nueva versión del driver de nvidia para linux en su versión "no legacy" de la rama 177.xx no es compatible con la nueva versión del hal que han sacado hace poco por un parche de seguridad que corrige no-sé-qué problema de un bugzilla reportado hace 2 años y que hace que mi equipo tenga problemas para volver a reanimarse... ¿sabes lo que me van a decir? :-)
Y si estás gestionando en remoto, sin entorno X, sin teclado ni ratón, la cosa se complica más. Habría que tirar de alguna tarjeta ipmi.
¡En modo remoto no puedes hibernar! No, porque no lo puedes despertar como no sea desde otro equipo "cruzado".
Pues peor lo pones >:-) ¿Sabes cuántos equipos se gestionan de forma remota? ¿O acaso el ahorro energético es sólo para usuarios caseros y oficinistas? Además, para eso precisamente están los adaptadores IPMI ;-)
Pues como esté programado para grabar alguna película y se vaya a "dormir" ya me dirás la gracia que te da >:-)
Bueno, la gracia es que no habrá terminado el trabajo, pero continúa haciéndolo en cuanto lo despierte.
Ah, espera, yo hablo de tener el mencoder o avidemux para procesar una película ya grabada. Tu dices de tener el PC para grabar algo de la tele: vale, eso no sería gracioso. Pero llevo diciendo que la hibernación automática está verdísima desde que a alguien se le ocurrió activarla por defecto en la SUSE, y lo sabes perfectamente ;-) - para poder hacerlo, al programar una tarea para determinada hora el equipo tendría que programar el reloj de la CMOS para despertar el ordenador a la hora adecuada.
No es tan difícil, es lo que hace mi cacharrín de la tele, se despierta sólo y arranca (este no hiberna, arranca), y cuando llego me encuentro la serie del CSI grabada.
¡La automática y la manual! Ambas están más verdes que un tomate verde. Si el cron tiene una tarea que se ejecuta a "x" hora y vas a suspender o hibernar el equipo en ese momento, ¡qué menos que un aviso por parte del sistema! >:-) Mira, yo los equipos que funcionan bien con el stand-by, lo dejo activado. La copiadora de la oficina, por ejemplo, que lleva fax, está en stand-by y cuando recibe una llamada, responde, almacena el fax, y se vuelve a quedar en stand-by. Eso es una gozada. Y es una gozada porque "funciona bien" y porque necesito que esté respondiendo las 24 horas. Y porque al día siguiente, al primero que va a hacer una fotocopia, se le activa la fotocopiadora en un plis-plas y en un minuto de reloj tiene su fotocopia. Eso es una buena implementación del ahorro energético por parte del fabricante del equipo.
Si tu equipo tarda 15 minutos en arrancar, en tu caso es comprensible. Pero no todos los equipos son tan lentos >:-)
No es que el equipo sea lento. El arranque es normal, son la cantidad de tareas y ventanas que arranco manualmente lo que tarda.
Pse... un equipo más potente tardaría 5 minutos en lugar de 15 ;-) 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-05-27 a las 00:33 +0200, Camaleón escribió:
El 2009-05-26 a las 21:13 +0200, Carlos E. R. escribió:
Yo de ti, si un equipo actual no hiberna, lo devolvía.
Sí, claro.
Y cuando le diga al que me suministra los equipos que la nueva versión del driver de nvidia para linux en su versión "no legacy" de la rama 177.xx no es compatible con la nueva versión del hal que han sacado hace poco por un parche de seguridad que corrige no-sé-qué problema de un bugzilla reportado hace 2 años y que hace que mi equipo tenga problemas para volver a reanimarse... ¿sabes lo que me van a decir?
:-)
Que te lo comas con patatas >:-P
Y si estás gestionando en remoto, sin entorno X, sin teclado ni ratón, la cosa se complica más. Habría que tirar de alguna tarjeta ipmi.
¡En modo remoto no puedes hibernar! No, porque no lo puedes despertar como no sea desde otro equipo "cruzado".
Pues peor lo pones >:-)
¿Porque te crees que los de IBM se subieron a los cerros de Úbeda? >>>;-) Pues porque la hibernación automática es horrible en servidores o sistemas gestionado por red...
¿Sabes cuántos equipos se gestionan de forma remota? ¿O acaso el ahorro energético es sólo para usuarios caseros y oficinistas?
No pueden ser las mismas técnicas de ahorro, son casos distintos.
Además, para eso precisamente están los adaptadores IPMI ;-)
Ni idea de lo que son esas cosas.
¡La automática y la manual! Ambas están más verdes que un tomate verde.
No, porque la manual la uso yo a diario sin problemas. Que pudiera tener más "features", pues claro. Pero se puede usar. La automática, no.
Mira, yo los equipos que funcionan bien con el stand-by, lo dejo activado. La copiadora de la oficina, por ejemplo, que lleva fax, está en stand-by y cuando recibe una llamada, responde, almacena el fax, y se vuelve a quedar en stand-by. Eso es una gozada. Y es una gozada porque "funciona bien" y porque necesito que esté respondiendo las 24 horas.
Que sí, ya lo se.
Si tu equipo tarda 15 minutos en arrancar, en tu caso es comprensible. Pero no todos los equipos son tan lentos >:-)
No es que el equipo sea lento. El arranque es normal, son la cantidad de tareas y ventanas que arranco manualmente lo que tarda.
Pse... un equipo más potente tardaría 5 minutos en lugar de 15 ;-)
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. Además, no es cuestión de potencia, hay dos puntos de lentitud más importantes que la propia CPU: las lecturas de disco, y las esperas por temporización. Por ejemplo, el daemon que maneja la SAI tarda un minuto de reloj en iniciarse, por culpa de la lentitud de la propia SAI en responder. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkocc4MACgkQtTMYHG2NR9XkOgCdF1gVVCzBSj5oAt0HM1nU4T1k kZsAmwcuPQdgb1gTltD0oJE5ZRGA6dOf =y8KG -----END PGP SIGNATURE-----
El 2009-05-27 a las 00:56 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 00:33 +0200, Camaleón escribió:
Y cuando le diga al que me suministra los equipos que la nueva versión del driver de nvidia para linux en su versión "no legacy" de la rama 177.xx no es compatible con la nueva versión del hal que han sacado hace poco por un parche de seguridad que corrige no-sé-qué problema de un bugzilla reportado hace 2 años y que hace que mi equipo tenga problemas para volver a reanimarse... ¿sabes lo que me van a decir?
:-)
Que te lo comas con patatas >:-P
Pues eso... inviable ;-)
Pues peor lo pones >:-)
¿Porque te crees que los de IBM se subieron a los cerros de Úbeda? >>>;-)
Pues porque la hibernación automática es horrible en servidores o sistemas gestionado por red...
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 :-?
¿Sabes cuántos equipos se gestionan de forma remota? ¿O acaso el ahorro energético es sólo para usuarios caseros y oficinistas?
No pueden ser las mismas técnicas de ahorro, son casos distintos.
Casos distintos sí, pero con la misma necesidad de ahorrar y agilizar el inicio del sistema ¿por qué no?
Además, para eso precisamente están los adaptadores IPMI ;-)
Ni idea de lo que son esas cosas.
http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface
¡La automática y la manual! Ambas están más verdes que un tomate verde.
No, porque la manual la uso yo a diario sin problemas. Que pudiera tener más "features", pues claro. Pero se puede usar. La automática, no.
¿Qué le pasa a la automática?
Mira, yo los equipos que funcionan bien con el stand-by, lo dejo activado. La copiadora de la oficina, por ejemplo, que lleva fax, está en stand-by y cuando recibe una llamada, responde, almacena el fax, y se vuelve a quedar en stand-by. Eso es una gozada. Y es una gozada porque "funciona bien" y porque necesito que esté respondiendo las 24 horas.
Que sí, ya lo se.
Pues eso. 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 :-(
No es que el equipo sea lento. El arranque es normal, son la cantidad de tareas y ventanas que arranco manualmente lo que tarda.
Pse... un equipo más potente tardaría 5 minutos en lugar de 15 ;-)
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 :-) 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.
Además, no es cuestión de potencia, hay dos puntos de lentitud más importantes que la propia CPU: las lecturas de disco, y las esperas por temporización. Por ejemplo, el daemon que maneja la SAI tarda un minuto de reloj en iniciarse, por culpa de la lentitud de la propia SAI en responder.
Pues ya sabes, abres un bugzilla para que lo corrijan: que aborte a los pocos segundos si no logra comunicar y que siga intentando comunicarse con el SAI en segundo plano... >:-) 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-05-27 a las 08:50 +0200, Camaleón escribió:
Pues peor lo pones >:-)
¿Porque te crees que los de IBM se subieron a los cerros de Úbeda? >>>;-)
Pues porque la hibernación automática es horrible en servidores o sistemas gestionado por red...
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".
¿Sabes cuántos equipos se gestionan de forma remota? ¿O acaso el ahorro energético es sólo para usuarios caseros y oficinistas?
No pueden ser las mismas técnicas de ahorro, son casos distintos.
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.
Además, para eso precisamente están los adaptadores IPMI ;-)
Ni idea de lo que son esas cosas.
http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface
Después de la siesta miraré.
¡La automática y la manual! Ambas están más verdes que un tomate verde.
No, porque la manual la uso yo a diario sin problemas. Que pudiera tener más "features", pues claro. Pero se puede usar. La automática, no.
¿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...)
Mira, yo los equipos que funcionan bien con el stand-by, lo dejo activado. La copiadora de la oficina, por ejemplo, que lleva fax, está en stand-by y cuando recibe una llamada, responde, almacena el fax, y se vuelve a quedar en stand-by. Eso es una gozada. Y es una gozada porque "funciona bien" y porque necesito que esté respondiendo las 24 horas.
Que sí, ya lo se.
Pues eso.
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.
No es que el equipo sea lento. El arranque es normal, son la cantidad de tareas y ventanas que arranco manualmente lo que tarda.
Pse... un equipo más potente tardaría 5 minutos en lugar de 15 ;-)
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.
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.
Además, no es cuestión de potencia, hay dos puntos de lentitud más importantes que la propia CPU: las lecturas de disco, y las esperas por temporización. Por ejemplo, el daemon que maneja la SAI tarda un minuto de reloj en iniciarse, por culpa de la lentitud de la propia SAI en responder.
Pues ya sabes, abres un bugzilla para que lo corrijan: que aborte a los pocos segundos si no logra comunicar y que siga intentando comunicarse con el SAI en segundo plano... >:-)
Lo tengo en mi cola de cosas por hacer un año de estos. De hecho, durante el despertar de la hibernación yo lo tengo programado para que ocurra en segundo plano sin afectar al resto de procesos. Durante el arranque no sé como hacerlo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkodWY0ACgkQtTMYHG2NR9UFtQCffbmWdtBYvwPK42qsri9vl5H5 9nIAoInRI4mOmMOwqqA6yuPy9YFulDga =pEN6 -----END PGP SIGNATURE-----
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
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? :-?
¿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 >:-)
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.
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? :-?
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:-) 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-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-----
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.
* En suspensión, en general, tampoco sirven peticiones (1).
¡Si que sirven! :-)
(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.
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.
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. P.S. Saludos desde Pernambuco.
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.
¿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.
(...)
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.
¡Yaaggh! La vida es un bug :-)
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é.
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. 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-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-----
Hola Camaleón escribió:
Llegará un momento en el que tengan que acometer una ampliación de la instalación de red y ampliar la potencia, eso es inevitable.
Esto es una posibilidad, pero si los nuevos equipos informáticos bajan de manera considerable el consumo no haría falta, dado que son ellos los que llevan el mayor consumo, no de manera individual sino por la cantidad que hay.
Sería interesante conocer el consumo anterior y posterior de los equipos para conocer las cifras reales porque desde luego una docena de PC de oficina no debería tener un consumo desorbitado (algo superior a los 150W/h por equipo).
Es simple una llave térmica de 32A (32 ampéres) esta trabajando al limite (31A a 32A) si la tensión de trabajo es 220V y aceptando un consumo de 150W que has puesto puedes ver que encender una máquina mas hará que el sistema de protección actúe, si gracias a un sistema de hibernación hay supongamos 6 máquinas apagadas nos da una corriente de 4A menos con lo cual el encendido de otra PC no afectará el suministro de energía. Para el ejemplo que expuse hay que tener en cuenta que es un caso real, la gente no le gusta estar apagando las máquinas y quieren que cuando vuelvan a sentarse frente a ellas este todo como lo han dejados, es una cuestión cultural y yo no puedo cambiarlo, solo debo tenerlo en cuenta al dar una solución, ya que el de apagar, que sería lo que sería lo correcto, o al menos lo que yo hago, no lo aceptan.
Y si el equipo no hace nada, apagado está mejor :-P
Otro caso, es el que me vendría, por ejemplo, en mi caso, es el de indicar que si tal programa se esta ejecutando entonces no se inicie la suspensión automática. Creo que esto último tiene que ser algo simple de implementar.
Pues en tu caso no lo veo tan claro.
Si necesitas que el equipo esté "trabajando" con el mencoder, entonces ¿para qué "hibernarlo"? Hiberbar es sinónimo de "no necesito el equipo, lo voy a apagar".
Saludos,
La idea es que se apague cuando termine de trabajar, el problema es que no se sabe cuanto tardará en hacer lo que se le ha pedido, se tiene una estimación, pero es solo eso, una estimación. La idea sería: termina el trabajo (deja de ejecutarse tal o cual tarea) y se suspende a disco, por ejemplo, sin que tenga que haber alguien presionando teclas como tonto solo para que no se apague. El operador del PC puede ir tranquilo a otro lugar del planeta ha realizar otra cosa. Ejemplo: supongamos que podemos dar en una sola instrucción que se compile el kernel y se instale. Cuanto tardará en realizarlo, no sé, depende principalmente de lo que se haya configurado y del poder de cálculo del CPU, bueno cuando se termine de hacer podría apagarse hasta que el operador vuelva a estar frente al ordenador. Esto que esto planteo sirve para algunos y para otros no. Alfredo -- 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-05-25 a las 15:59 -0300, Alfredo J. Delaiti escribió:
Camaleón escribió:
Llegará un momento en el que tengan que acometer una ampliación de la instalación de red y ampliar la potencia, eso es inevitable.
Esto es una posibilidad, pero si los nuevos equipos informáticos bajan de manera considerable el consumo no haría falta, dado que son ellos los que llevan el mayor consumo, no de manera individual sino por la cantidad que hay.
Pero estáis en un rango peligroso. Si dices que sólo activando la hibernación de 12 equipos se baja el consumo de manera considerable, imagina qué pasaría si viene un cliente y os pide conectar el portátil a una toma eléctrica y al mismo tiempo el hijo del jefe conecta la PlayStation: se os cae la red eléctrica nada más enchufar la máquina de café o cualquier aparato >:-)
Sería interesante conocer el consumo anterior y posterior de los equipos para conocer las cifras reales porque desde luego una docena de PC de oficina no debería tener un consumo desorbitado (algo superior a los 150W/h por equipo).
Es simple una llave térmica de 32A (32 ampéres) esta trabajando al limite (31A a 32A) si la tensión de trabajo es 220V y aceptando un consumo de 150W que has puesto puedes ver que encender una máquina mas hará que el sistema de protección actúe, si gracias a un sistema de hibernación hay supongamos 6 máquinas apagadas nos da una corriente de 4A menos con lo cual el encendido de otra PC no afectará el suministro
Sí, pero lo interesante es conocer: - Consumo de los equipos actuales (sin suspensión) - Consumo de los equipos con hibernación Porque quizá "la fuga" la tengáis en otros aparatos (AA.CC.) o incluso en la distribución (balanceo de cargas) del cuadro eléctrico y no en los equipos de sobremesa :-?
de energía. Para el ejemplo que expuse hay que tener en cuenta que es un caso real, la gente no le gusta estar apagando las máquinas y quieren que cuando vuelvan a sentarse frente a ellas este todo como lo han dejados, es una cuestión cultural y yo no puedo cambiarlo, solo debo tenerlo en cuenta al dar una solución, ya que el de apagar, que sería lo que sería lo correcto, o al menos lo que yo hago, no lo aceptan.
Bueno, un efecto similar son las "sesiones guardadas". Se abren las aplicaciones y los documentos que se tenían abiertos al cerrar el equipo. No es lo mismo pero da el pego :-P
Si necesitas que el equipo esté "trabajando" con el mencoder, entonces ¿para qué "hibernarlo"? Hiberbar es sinónimo de "no necesito el equipo, lo voy a apagar".
La idea es que se apague cuando termine de trabajar, el problema es que no se sabe cuanto tardará en hacer lo que se le ha pedido, se tiene una estimación, pero es solo eso, una estimación. La idea sería: termina el trabajo (deja de ejecutarse tal o cual tarea) y se suspende a disco, por ejemplo, sin que tenga que haber alguien presionando teclas como tonto solo para que no se apague. El operador del PC puede ir tranquilo a otro lugar del planeta ha realizar otra cosa. Ejemplo: supongamos que podemos dar en una sola instrucción que se compile el kernel y se instale. Cuanto tardará en realizarlo, no sé, depende principalmente de lo que se haya configurado y del poder de cálculo del CPU, bueno cuando se termine de hacer podría apagarse hasta que el operador vuelva a estar frente al ordenador. Esto que esto planteo sirve para algunos y para otros no.
Y así es como debería ser para que realmente fuera un proceso útil. Que el equipo hiberne sin ninguna lógica (sólo mediante un temporizador que es inflexible y que no admite excepciones o activándolo de manera presencial) carece de sentido hoy en día. Y otra cosa que estamos dejando a un lado es la "suspensión". La suspensión también permite un ahorro energético considerable y le encuentro más sentido para un equipo que está "en jornada laboral" es decir, que está trabajando (o que se necesita que esté alerta porque tiene tareas programadas que ejecutar) y es más rápida en restaurar que la hibernación. Pero también falla mucho :-/ 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-05-25 a las 22:15 +0200, Camaleón escribió:
El 2009-05-25 a las 15:59 -0300, Alfredo J. Delaiti escribió:
Pero estáis en un rango peligroso.
Si dices que sólo activando la hibernación de 12 equipos se baja el consumo de manera considerable, imagina qué pasaría si viene un cliente y os pide conectar el portátil a una toma eléctrica y al mismo tiempo el hijo del jefe conecta la PlayStation: se os cae la red eléctrica nada más enchufar la máquina de café o cualquier aparato >:-)
Para eso se pone un controlador inteligente: cuando el consumo está cercano al límite, no permite encender nuevos aparatos.
tenerlo en cuenta al dar una solución, ya que el de apagar, que sería lo que sería lo correcto, o al menos lo que yo hago, no lo aceptan.
Bueno, un efecto similar son las "sesiones guardadas". Se abren las aplicaciones y los documentos que se tenían abiertos al cerrar el equipo. No es lo mismo pero da el pego :-P
Siempre que guardes los documentos.
Y otra cosa que estamos dejando a un lado es la "suspensión". La suspensión también permite un ahorro energético considerable y le encuentro más sentido para un equipo que está "en jornada laboral" es decir, que está trabajando (o que se necesita que esté alerta porque tiene tareas programadas que ejecutar) y es más rápida en restaurar que la hibernación.
Pero también falla mucho :-/
Pues mira, yo no me atrevo a usar la suspensión en equipos de sobremesa, porque una falla de corriente te corrompe el sistema de ficheros, para empezar. Aunque tengas una UPS/SAI, sólo estás protegido el tiempo que dure su batería, no puedes comandar la SAI para apagar el ordenador. No es un estadio seguro, sólo es eficaz en portátiles con batería. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkobE5QACgkQtTMYHG2NR9XFVQCeIHi8TLWqq3LHyxpjnxGHiEoT fEQAn0AYrxtQQKKKMv9wVd/4IS1pIQLc =Ha/v -----END PGP SIGNATURE-----
El 2009-05-25 a las 23:54 +0200, Carlos E. R. escribió:
El 2009-05-25 a las 22:15 +0200, Camaleón escribió:
Y otra cosa que estamos dejando a un lado es la "suspensión". La suspensión también permite un ahorro energético considerable y le encuentro más sentido para un equipo que está "en jornada laboral" es decir, que está trabajando (o que se necesita que esté alerta porque tiene tareas programadas que ejecutar) y es más rápida en restaurar que la hibernación.
Pero también falla mucho :-/
Pues mira, yo no me atrevo a usar la suspensión en equipos de sobremesa, porque una falla de corriente te corrompe el sistema de ficheros, para empezar.
Corres el mismo riesgo que si está encendido y trabajando. No olvides que la relación es como sigue: SISTEMA ACTUAL <--> SISTEMA AHORRO <--> ACTIVIDAD Encendido Suspendido Trabajando Apagado Hibernado Inactivo La pregunta es "cómo se quiere dejar al equipo": si se quiere que procese datos o que no haga nada.
Aunque tengas una UPS/SAI, sólo estás protegido el tiempo que dure su batería, no puedes comandar la SAI para apagar el ordenador.
No es un estadio seguro, sólo es eficaz en portátiles con batería.
Eso no es así. En primer lugar, si se corta la corriente y hay un SAI, el equipo puede hacer varias cosas (entre otras): a) Apagarse o hibernarse inmediatamente b) Mantenerse encendido hasta que se agote la batería c) No hacer nada Si está configurado para b), antes de que se agote la batería, el SAI vuelve a aplicar la misma lógica: a), b) o c). Modelos más complejos pueden trabajar con otras variables (como la carga de los SAI, la temperatura, etc...) a la hora de tomar decisiones de apagado, pero hoy día, cualquier SAI medianamente decente admite al menos las 3 primeras opciones. 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-05-26 a las 08:29 +0200, Camaleón escribió:
El 2009-05-25 a las 23:54 +0200, Carlos E. R. escribió:
Pero también falla mucho :-/
Pues mira, yo no me atrevo a usar la suspensión en equipos de sobremesa, porque una falla de corriente te corrompe el sistema de ficheros, para empezar.
Corres el mismo riesgo que si está encendido y trabajando.
No olvides que la relación es como sigue:
SISTEMA ACTUAL <--> SISTEMA AHORRO <--> ACTIVIDAD Encendido Suspendido Trabajando Apagado Hibernado Inactivo
La pregunta es "cómo se quiere dejar al equipo": si se quiere que procese datos o que no haga nada.
Bueno, vale, es el mismo peligro que si está en marcha; pero sí y no, porque el equipo "aparenta" estar apagado, aunque no lo está. Psicologicamente se piensa que está asegurado, cuando está inestable.
Aunque tengas una UPS/SAI, sólo estás protegido el tiempo que dure su batería, no puedes comandar la SAI para apagar el ordenador.
No es un estadio seguro, sólo es eficaz en portátiles con batería.
Eso no es así.
En primer lugar, si se corta la corriente y hay un SAI, el equipo puede hacer varias cosas (entre otras):
a) Apagarse o hibernarse inmediatamente b) Mantenerse encendido hasta que se agote la batería c) No hacer nada
Si está suspendido y tiene SAI no puede hacer nada: la SAI informará por USB o eth o COM, pero el ordenador no se enterará, no atiende. Bueno, por puerto serie sí podrías poner que la IRQ generada despertase al ordenador y atendiese la alarma, pero los otros dos sistemas no se enteraría y no haría nada.
Si está configurado para b), antes de que se agote la batería, el SAI vuelve a aplicar la misma lógica: a), b) o c).
Modelos más complejos pueden trabajar con otras variables (como la carga de los SAI, la temperatura, etc...) a la hora de tomar decisiones de apagado, pero hoy día, cualquier SAI medianamente decente admite al menos las 3 primeras opciones.
La decisión la toma el software que corre en el ordenador... y al estar suspendido, las decisiones están en suspenso. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkocQIEACgkQtTMYHG2NR9WKPgCfaDTgnuBDMjbsrABR1NrRkX/B K0EAnRYPF7WDuM8ji/IVeiRb9N8Ttbkb =GSxV -----END PGP SIGNATURE-----
On Tuesday 26 May 2009 21:18:23 Carlos E. R. wrote:
Si está suspendido y tiene SAI no puede hacer nada: la SAI informará por USB o eth o COM, pero el ordenador no se enterará, no atiende. Bueno, por puerto serie sí podrías poner que la IRQ generada despertase al ordenador y atendiese la alarma, pero los otros dos sistemas no se enteraría y no haría nada.
Que hoy no exista, no quiere decir que no sea posible. Son tan IRQs los de unos como los de otros. -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-26 a las 21:25 +0200, Lluis escribió:
On Tuesday 26 May 2009 21:18:23 Carlos E. R. wrote:
Si está suspendido y tiene SAI no puede hacer nada: la SAI informará por USB o eth o COM, pero el ordenador no se enterará, no atiende. Bueno, por puerto serie sí podrías poner que la IRQ generada despertase al ordenador y atendiese la alarma, pero los otros dos sistemas no se enteraría y no haría nada.
Que hoy no exista, no quiere decir que no sea posible. Son tan IRQs los de unos como los de otros.
Sí, pero no. El puerto serie suele tener pinchado un cable en el pin "ring" conectado directamente a una interrupción, que la bios reconoce en la lista de "despertar". Puede usarse. Que yo sepa, no hay algo equivalente en el bus USB, no está previsto despertar al ordenador si hay actividad en el bus USB, o al menos yo no lo he visto. Es más, las SAIS con USB suelen funcionar en modo "polling". En cuanto a la ethernet sí, existe lo de "wake on lan". Habría que configurar la SAI para que lo hiciese... y ojo, que es peligroso un evento WOL sí el ordenador está apagado, porque provocas un encendido inútil (igual con el caso del puerto serie). - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkocZc4ACgkQtTMYHG2NR9XRNwCcDe+OjGyBCKmI5q3u+uOSae0j 84kAnixX5Eh6IhI0YRhHStOJcji5EZ0N =RcMh -----END PGP SIGNATURE-----
On Tuesday 26 May 2009 23:57:31 Carlos E. R. wrote:
Sí, pero no.
El puerto serie suele tener pinchado un cable en el pin "ring" conectado directamente a una interrupción, que la bios reconoce en la lista de "despertar". Puede usarse.
Que yo sepa, no hay algo equivalente en el bus USB, no está previsto despertar al ordenador si hay actividad en el bus USB, o al menos yo no lo he visto. Es más, las SAIS con USB suelen funcionar en modo "polling".
En cuanto a la ethernet sí, existe lo de "wake on lan". Habría que configurar la SAI para que lo hiciese... y ojo, que es peligroso un evento WOL sí el ordenador está apagado, porque provocas un encendido inútil (igual con el caso del puerto serie).
No hay que empastelar los conceptos. USB, en la trasferencia de datos funciona con interrupciones. En Linux y en cualquier SO decente incluido Ruindows. La red, Con mucha mas razón, en función de la velocidad. Que eso se aproveche para funciones de despertador o no, es otra historia. Una cosa son las capacidades del Hardware, y otra son las que aprovecha el software. En todo esto, lo de la BIOS, es casi anectotico. -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-27 a las 00:27 +0200, Lluis escribió:
No hay que empastelar los conceptos. USB, en la trasferencia de datos funciona con interrupciones.
No hablamos de eso, sino de la capacidad de despertar al ordenador suspendido mediante actividad en el bus, por mucho que los datos se recojan mediante irq. El puerto serie tiene eso previsto, y el ethernet también, de diferentes modos. El USB, que yo sepa, no, y es el más usado por las SAIS. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoccD4ACgkQtTMYHG2NR9WRRwCgkp81uOnH4M8pGzEGjQUDY0dk ghwAn0xcaS6l0qDz31f05+P5snTPoHgr =LKJ9 -----END PGP SIGNATURE-----
El 2009-05-27 a las 00:42 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 00:27 +0200, Lluis escribió:
No hay que empastelar los conceptos. USB, en la trasferencia de datos funciona con interrupciones.
No hablamos de eso, sino de la capacidad de despertar al ordenador suspendido mediante actividad en el bus, por mucho que los datos se recojan mediante irq.
El puerto serie tiene eso previsto, y el ethernet también, de diferentes modos. El USB, que yo sepa, no, y es el más usado por las SAIS.
Y el USB también. hpc02@stthpc:~> cat /proc/acpi/wakeup Device S-state Status Sysfs node PEG S5 disabled pci:0000:00:01.0 PEX S5 disabled LAN S5 disabled pci:0000:00:19.0 USB4 S5 disabled pci:0000:00:1a.0 USB5 S5 disabled pci:0000:00:1a.1 USB7 S5 disabled pci:0000:00:1a.2 ESB2 S5 disabled pci:0000:00:1a.7 EXP1 S4 disabled pci:0000:00:1c.0 PXHA S5 disabled pci:0000:05:00.0 EXP5 S5 disabled USB1 S5 disabled pci:0000:00:1d.0 USB2 S5 disabled pci:0000:00:1d.1 USB3 S5 disabled pci:0000:00:1d.2 USB6 S5 disabled ESB1 S5 disabled pci:0000:00:1d.7 PCIB S5 disabled pci:0000:00:1e.0 KBC0 S1 disabled pnp:00:07 MSE0 S1 disabled pnp:00:08 COM1 S5 disabled pnp:00:09 COM2 S5 disabled pnp:00:0a PWRB S3 *enabled pci:0000:00:00.0 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-05-27 a las 09:11 +0200, Camaleón escribió:
No hay que empastelar los conceptos. USB, en la trasferencia de datos funciona con interrupciones.
No hablamos de eso, sino de la capacidad de despertar al ordenador suspendido mediante actividad en el bus, por mucho que los datos se recojan mediante irq.
El puerto serie tiene eso previsto, y el ethernet también, de diferentes modos. El USB, que yo sepa, no, y es el más usado por las SAIS.
Y el USB también.
hpc02@stthpc:~> cat /proc/acpi/wakeup
Device S-state Status Sysfs node PEG S5 disabled pci:0000:00:01.0 PEX S5 disabled LAN S5 disabled pci:0000:00:19.0 USB4 S5 disabled pci:0000:00:1a.0 USB5 S5 disabled pci:0000:00:1a.1 USB7 S5 disabled pci:0000:00:1a.2 ESB2 S5 disabled pci:0000:00:1a.7 EXP1 S4 disabled pci:0000:00:1c.0 PXHA S5 disabled pci:0000:05:00.0 EXP5 S5 disabled USB1 S5 disabled pci:0000:00:1d.0 USB2 S5 disabled pci:0000:00:1d.1 USB3 S5 disabled pci:0000:00:1d.2 USB6 S5 disabled ESB1 S5 disabled pci:0000:00:1d.7 PCIB S5 disabled pci:0000:00:1e.0 KBC0 S1 disabled pnp:00:07 MSE0 S1 disabled pnp:00:08 COM1 S5 disabled pnp:00:09 COM2 S5 disabled pnp:00:0a PWRB S3 *enabled pci:0000:00:00.0
No se como traducir eso. El mio tiene menos, por cierto: cer@nimrodel:~> cat /proc/acpi/wakeup Device S-state Status Sysfs node SLPB S5 *enabled PCI0 S5 disabled no-bus:pci0000:00 HUB0 S5 disabled pci:0000:00:1e.0 USB0 S1 disabled pci:0000:00:1f.2 USB1 S1 disabled pci:0000:00:1f.4 UAR1 S5 disabled pnp:00:08 UAR2 S5 disabled pnp:00:09 Pero en fin, suponiendo que se pueda, ahora dime como hacer para que mi SAI despierte a mi PC y el daemon se entere. Con detalles, SVP, que estoy espeso >:-P O mejor ni lo intentes, la mia funciona en "polling mode". Traducido: el daemon le pregunta a la SAI cada 10 segundos por su estado, no es la SAI la que llama a la puerta y da la alarma. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkodWtAACgkQtTMYHG2NR9V4VgCfe02QWHtGcC1NC+/48eQEPk2C /gIAn0HCt9JdSaMyl7OV+UEHEmBVYehQ =Ecia -----END PGP SIGNATURE-----
El 2009-05-27 a las 17:22 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 09:11 +0200, Camaleón escribió:
Y el USB también.
hpc02@stthpc:~> cat /proc/acpi/wakeup
(...)
No se como traducir eso. El mio tiene menos, por cierto:
Qué sorpresa (ña, ña...) >:-)
cer@nimrodel:~> cat /proc/acpi/wakeup Device S-state Status Sysfs node SLPB S5 *enabled PCI0 S5 disabled no-bus:pci0000:00 HUB0 S5 disabled pci:0000:00:1e.0 USB0 S1 disabled pci:0000:00:1f.2 USB1 S1 disabled pci:0000:00:1f.4 UAR1 S5 disabled pnp:00:08 UAR2 S5 disabled pnp:00:09
Pero en fin, suponiendo que se pueda, ahora dime como hacer para que mi SAI despierte a mi PC y el daemon se entere. Con detalles, SVP, que estoy espeso >:-P
Bueno, pues te pasas por la IEEE y preguntas por la sección del ACPI, para que te informen y te den todas las especificaciones. Luego le decimos a Lluis que nos haga "un apaño" y listo :-P A ver, ahora en serio, que sólo digo que está contemplado. No sé si tooodos los fabricantes de SAI del mundo mundial lo impelmentarán en sus equipos (supongo que no, por eso algunos SAI cuestan 45€ y otros 4.500€) *** http://en.wikipedia.org/wiki/Acpi#System_states G2 (S5) Soft Off-- G2, S5, and Soft Off are synonyms. G2 is almost the same as G3 Mechanical Off, but some components remain powered so the computer can "wake" from input from the keyboard, clock, modem, LAN, or USB device.[6] ***
O mejor ni lo intentes, la mia funciona en "polling mode". Traducido: el daemon le pregunta a la SAI cada 10 segundos por su estado, no es la SAI la que llama a la puerta y da la alarma.
Vale, tu SAI de Belkin por usb 1.1 no, venga, aceptado >:-). 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
Content-ID:
El 2009-05-27 a las 17:22 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 09:11 +0200, Camaleón escribió:
Y el USB también.
hpc02@stthpc:~> cat /proc/acpi/wakeup
(...)
No se como traducir eso. El mio tiene menos, por cierto:
Qué sorpresa (ña, ña...) >:-)
cer@nimrodel:~> cat /proc/acpi/wakeup Device S-state Status Sysfs node SLPB S5 *enabled PCI0 S5 disabled no-bus:pci0000:00 HUB0 S5 disabled pci:0000:00:1e.0 USB0 S1 disabled pci:0000:00:1f.2 USB1 S1 disabled pci:0000:00:1f.4 UAR1 S5 disabled pnp:00:08 UAR2 S5 disabled pnp:00:09
Pero en fin, suponiendo que se pueda, ahora dime como hacer para que mi SAI despierte a mi PC y el daemon se entere. Con detalles, SVP, que estoy espeso >:-P
Bueno, pues te pasas por la IEEE y preguntas por la sección del ACPI, para que te informen y te den todas las especificaciones. Luego le decimos a Lluis que nos haga "un apaño" y listo :-P
Te recuerdo, que aunque sea socio del IEEE, esta gente cobra por todo >:-)
A ver, ahora en serio, que sólo digo que está contemplado. No sé si tooodos los fabricantes de SAI del mundo mundial lo impelmentarán en sus equipos (supongo que no, por eso algunos SAI cuestan 45€ y otros 4.500€)
*** http://en.wikipedia.org/wiki/Acpi#System_states
G2 (S5) Soft Off-- G2, S5, and Soft Off are synonyms. G2 is almost the same as G3 Mechanical Off, but some components remain powered so the computer can "wake" from input from the keyboard, clock, modem, LAN, or USB device.[6] ***
Ah, la wikipedia al rescate. Una completa descripción de esas abreviaturas dichosas. Bueno, pues S3 es el estado de suspensión. No veo en la tabla tuya o mia dispositivos listados en S3, salvo PWRB, que supongo entonces es el único capaz de sacar de ese estado :-?
O mejor ni lo intentes, la mia funciona en "polling mode". Traducido: el daemon le pregunta a la SAI cada 10 segundos por su estado, no es la SAI la que llama a la puerta y da la alarma.
Vale, tu SAI de Belkin por usb 1.1 no, venga, aceptado >:-).
Pues eso. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkodj+oACgkQtTMYHG2NR9XRQACfQeLkPSj4un8UAVmgw3R2SKu8 oZ4Anjx68QZQJKDZ3Ye1jNJv0Hy5SvNx =0h6y -----END PGP SIGNATURE-----
On Wednesday 27 May 2009 21:09:27 Carlos E. R. wrote:
Ah, la wikipedia al rescate. Una completa descripción de esas abreviaturas dichosas. Bueno, pues S3 es el estado de suspensión. No veo en la tabla tuya o mia dispositivos listados en S3, salvo PWRB, que supongo entonces es el único capaz de sacar de ese estado :-?
Yo tengo USBs en S3 Device S-state Status Sysfs node HUB0 S5 disabled pci:0000:00:08.0 XVR0 S5 disabled pci:0000:00:10.0 XVR1 S5 disabled XVR2 S5 disabled pci:0000:00:12.0 XVR3 S5 disabled pci:0000:00:13.0 XVR4 S5 disabled pci:0000:00:14.0 XVR5 S5 disabled XVR6 S5 disabled XVR7 S5 disabled USB0 S4 disabled pci:0000:00:02.0 USB1 S4 disabled pci:0000:00:04.0 USBB S3 disabled pci:0000:00:04.1 USB2 S3 disabled pci:0000:00:02.1 AZAD S5 disabled pci:0000:00:07.0 MMAC S5 disabled -- Saludos Lluis
El 2009-05-27 a las 21:09 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 18:02 +0200, Camaleón escribió:
A ver, ahora en serio, que sólo digo que está contemplado. No sé si tooodos los fabricantes de SAI del mundo mundial lo impelmentarán en sus equipos (supongo que no, por eso algunos SAI cuestan 45€ y otros 4.500€)
*** http://en.wikipedia.org/wiki/Acpi#System_states
G2 (S5) Soft Off-- G2, S5, and Soft Off are synonyms. G2 is almost the same as G3 Mechanical Off, but some components remain powered so the computer can "wake" from input from the keyboard, clock, modem, LAN, or USB device.[6] ***
Ah, la wikipedia al rescate. Una completa descripción de esas abreviaturas dichosas. Bueno, pues S3 es el estado de suspensión. No veo en la tabla tuya o mia dispositivos listados en S3, salvo PWRB, que supongo entonces es el único capaz de sacar de ese estado :-?
Pues no lo sé. Se supone que ese es el botón de encendido (power button) y se usa también para la hibernación (S4). Yo sólo te digo que los dos programitas que tenemos por aquí (no, no son el NUT :-P) para la gestión de los SAI, ambos admiten: a) Activar la hibernación b) Reanimar al equipo tras detectar que el sumistro de energía ha vuelto Concretamente, el programa "powerchute" del SAI de APC, permite: - Seleccionar el tipo de apagado: shutdown, hibernate, shutdown and off - Configurar las opciones de retorno: activar el retorno automático, definir la cantidad de carga de batería que consideras segura para que retorne, y el tiempo de retardo que quieres esperar a que inicie el equipo una vez que ha alcanzado la carga que has definido Es decir, la biblia en verso :-) Y no, este SAI no es de gama alta. Y sí, está conectado por USB. Es decir, que es posible hacerlo y que actualmente se hace. Mira, la hibernación bajo windows funciona muy bien: es mucho más configurable y con equipos modernos (bios modernas) realmente da pocos problemas para restaurar. Sean portátiles o sobremesas. Ya harás tus pruebas particulares en el equipo de la oficina y lo comprobarás por ti mismo >:-) 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-05-27 a las 21:46 +0200, Camaleón escribió:
El 2009-05-27 a las 21:09 +0200, Carlos E. R. escribió:
...
Ah, la wikipedia al rescate. Una completa descripción de esas abreviaturas dichosas. Bueno, pues S3 es el estado de suspensión. No veo en la tabla tuya o mia dispositivos listados en S3, salvo PWRB, que supongo entonces es el único capaz de sacar de ese estado :-?
Pues no lo sé. Se supone que ese es el botón de encendido (power button) y se usa también para la hibernación (S4).
Yo sólo te digo que los dos programitas que tenemos por aquí (no, no son el NUT :-P) para la gestión de los SAI, ambos admiten:
a) Activar la hibernación b) Reanimar al equipo tras detectar que el sumistro de energía ha vuelto
Concretamente, el programa "powerchute" del SAI de APC, permite:
- Seleccionar el tipo de apagado: shutdown, hibernate, shutdown and off
- Configurar las opciones de retorno: activar el retorno automático, definir la cantidad de carga de batería que consideras segura para que retorne, y el tiempo de retardo que quieres esperar a que inicie el equipo una vez que ha alcanzado la carga que has definido
Es decir, la biblia en verso :-)
Ya... haber cosas háylas. ¿Linux o windows?
Y no, este SAI no es de gama alta. Y sí, está conectado por USB.
Pero es de oficina, al menos. El mio debe ser gama alta de los caseros, o sea, de lo mejorcito que ofrecía el media mark, que sólo lo del bus usb me costó sus pelas.
Es decir, que es posible hacerlo y que actualmente se hace.
¿Has probado si, con el ordenador suspendido (ram), es capaz de despertar el equipo si falla la red para pasar a hibernación o apagado? Porque eso es el quid de la cuestión que llevamos discutiendo. Aunque encender el ordenador cuando vuelve la corriente también tiene su miga, si lo hace por USB (y sí, eso lo hace la bios, estado G2).
Mira, la hibernación bajo windows funciona muy bien: es mucho más configurable y con equipos modernos (bios modernas) realmente da pocos problemas para restaurar. Sean portátiles o sobremesas.
Ya harás tus pruebas particulares en el equipo de la oficina y lo comprobarás por ti mismo >:-)
Mi equipo de la oficina es un PIII (sí, pentium tres, no me he equivocado), recientemente ampliado a 512 megas de ram, y con nueve gigas de disco duro. ¿SAI? ¿Pero tú para quien te crees que trabajo, que me vayan a poner una SAI? Quita, quita. :-P Pero sí, el XP hiberna y recupera bien, no así la aplicación de base de datos en red (creo que basada en sybase). Me vale, puedo cerrarla, aún así tengo el pc disponible en 5 o 10 minutos: salgo ganando frente a un encendido completo de media hora. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkodphwACgkQtTMYHG2NR9V6DgCcC6pcELNgHzsK3zyfE/UKRgBN tRUAnj5WeINmYLXt1CatwvL/Y9oklKlm =/5hA -----END PGP SIGNATURE-----
El 2009-05-27 a las 22:44 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 21:46 +0200, Camaleón escribió:
Yo sólo te digo que los dos programitas que tenemos por aquí (no, no son el NUT :-P) para la gestión de los SAI, ambos admiten:
a) Activar la hibernación b) Reanimar al equipo tras detectar que el sumistro de energía ha vuelto
(...)
Es decir, la biblia en verso :-)
Ya... haber cosas háylas. ¿Linux o windows?
Ambos. El programa para el SAI de APC (powerchute) está disponible para win/mac/linux. Y funcionaba bien en suse (y eso que lo probé con la 9.2, es decir, hace unos cuantos años). Ahora lo monto en un windows. El otro programa del SAI que llevan los servidores también está para Windows y Linux. Este sí lo tengo instalado en SuSE.
Y no, este SAI no es de gama alta. Y sí, está conectado por USB.
Pero es de oficina, al menos. El mio debe ser gama alta de los caseros, o sea, de lo mejorcito que ofrecía el media mark, que sólo lo del bus usb me costó sus pelas.
Las prestaciones van con el precio, eso está claro :-} Pero lo que estamos debatiendo es la posibilidad de utilizar esa funcionalidad de "despertar" a través del puerto usb. Y lo que te digo es que si la bios lo admite, el hardware lo admite y el SO lo admite, pues es posible hacerlo :-P Si en linux no funciona (o lo hace mal) será porque uno de estos 3 elementos (bios / driver / so) falla en algún punto.
Es decir, que es posible hacerlo y que actualmente se hace.
¿Has probado si, con el ordenador suspendido (ram), es capaz de despertar el equipo si falla la red para pasar a hibernación o apagado? Porque eso es el quid de la cuestión que llevamos discutiendo.
No, no lo he probado porque nunca suspendo ni hiberno ¿recuerdas? >:-) Ya lo probaré, cuando tenga un hueco y pueda simular un apagado. Lo que sí te puedo confirmar (porque eso lo acabo de probar) es que tras dejar al equipo de sobremesa suspendido, sólo con hacerle un "ping" desde cualquier ordenador de la red local, lo levanta. 19:49 -> Probado y funciona (bajo windows, of course). He dejado el equipo suspendido, y cuando desconecto la fuerza del SAI, el equipo se ha restaurado. Al minuto se ha activado la rutina para la secuencia de apagado, y el equipo... ¡tacháaaan! Pues se ha apagado :-P Y no me extraña porque el ordenata en cuestión no es un clónico, es un HP de esos para empresas, así que viene preparado hasta el tuétano para cumplir con la normativa Energy Star... y claro, funciona perfectamente. En cambio, si suspendo el portátil (que tiene 3 años más que el sobremesa) sólo puedo reanimarlo pulsando el botón de encendido. Ni moviendo el touchpad logro restaurarlo. Es decir, que las BIOS modernas, independientemente de que sean de equipos portátiles o no, están preparadas para trabajar con la suspensión y la hibernación y responder a eventos de la red, usb, ratón / teclado y puerto serie, indistintamente. 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
On Thursday 28 May 2009 20:01:20 Camaleón wrote:
Es decir, que las BIOS modernas, independientemente de que sean de equipos portátiles o no, están preparadas para trabajar con la suspensión y la hibernación y responder a eventos de la red, usb, ratón / teclado y puerto serie, indistintamente.
Ya se que es un anatema. Has probado a actualizar la BIOS? -- Saludos Lluis
El 2009-05-28 a las 21:36 +0200, Lluis Martínez escribió:
On Thursday 28 May 2009 20:01:20 Camaleón wrote:
Es decir, que las BIOS modernas, independientemente de que sean de equipos portátiles o no, están preparadas para trabajar con la suspensión y la hibernación y responder a eventos de la red, usb, ratón / teclado y puerto serie, indistintamente.
Ya se que es un anatema.
Has probado a actualizar la BIOS?
:-) No pretendía configurar la administración de energía en el portátil. Sólo era un ejemplo para rebatir el argumento de que los portátiles están mejor preparados para la hibernación y suspensión que los equipos de sobremesa sólo porque integran la batería. Además, actualizando la BIOS se pueden corregir problemas relacionados con la gestión energética, pero de lo que no estoy segura es de que se pueda actualizar a una nueva revisión del ACPI, es decir que si la placa cumple con el ACPI 1.0/2.0 que al actualizar la BIOS admita la rev. 3.0, por ejemplo :-? 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-05-26 a las 21:18 +0200, Carlos E. R. escribió:
En primer lugar, si se corta la corriente y hay un SAI, el equipo puede hacer varias cosas (entre otras):
a) Apagarse o hibernarse inmediatamente b) Mantenerse encendido hasta que se agote la batería c) No hacer nada
Si está suspendido y tiene SAI no puede hacer nada:
¿Ves? por eso mismo no hay que suspenderlo si no es necesario :-)
la SAI informará por USB o eth o COM, pero el ordenador no se enterará, no atiende. Bueno, por puerto serie sí podrías poner que la IRQ generada despertase al ordenador y atendiese la alarma, pero los otros dos sistemas no se enteraría y no haría nada.
- Si está hibernado y se va la luz, no hay problema. - Si está suspendido y se va la luz, debería poder reaccionar. Por ejemplo, indicando al componente de comunicación con el sai (tarjeta de red, puerto serie o usb) que NO se suspenda.
Si está configurado para b), antes de que se agote la batería, el SAI vuelve a aplicar la misma lógica: a), b) o c).
Modelos más complejos pueden trabajar con otras variables (como la carga de los SAI, la temperatura, etc...) a la hora de tomar decisiones de apagado, pero hoy día, cualquier SAI medianamente decente admite al menos las 3 primeras opciones.
La decisión la toma el software que corre en el ordenador... y al estar suspendido, las decisiones están en suspenso.
¿Acaso un equipo suspedido no se puede reanimar por un evento de la misma forma que lo puedes iniciar con el "wake-on-lan", el "wake-on-ring" o un adaptador de gestión dedicado? :-) 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-05-27 a las 00:14 +0200, Camaleón escribió:
El 2009-05-26 a las 21:18 +0200, Carlos E. R. escribió:
En primer lugar, si se corta la corriente y hay un SAI, el equipo puede hacer varias cosas (entre otras):
a) Apagarse o hibernarse inmediatamente b) Mantenerse encendido hasta que se agote la batería c) No hacer nada
Si está suspendido y tiene SAI no puede hacer nada:
¿Ves? por eso mismo no hay que suspenderlo si no es necesario :-)
Pero es que yo no suspendo, hiberno. No he recomendado a nadie que use la suspensión - y por cierto, realmente, los de Novell intentaron activar la suspensión automática al no usar el teclado, que cuando falla, hiberna en cambio.
la SAI informará por USB o eth o COM, pero el ordenador no se enterará, no atiende. Bueno, por puerto serie sí podrías poner que la IRQ generada despertase al ordenador y atendiese la alarma, pero los otros dos sistemas no se enteraría y no haría nada.
- Si está hibernado y se va la luz, no hay problema.
Claro, por eso la uso.
- Si está suspendido y se va la luz, debería poder reaccionar. Por ejemplo, indicando al componente de comunicación con el sai (tarjeta de red, puerto serie o usb) que NO se suspenda.
El problema es si estando suspendido se va la luz, teniendo SAI. El software que controla la SAI no está activo para poder reaccionar, y no está claro que la SAI pueda despertar al equipo para reaccionar. En los portátiles, esto está previsto, y cuando está suspendido varios dias y la batería se está agotando, se despierta un instante para hibernar y apagar definitivamente.
Si está configurado para b), antes de que se agote la batería, el SAI vuelve a aplicar la misma lógica: a), b) o c).
Modelos más complejos pueden trabajar con otras variables (como la carga de los SAI, la temperatura, etc...) a la hora de tomar decisiones de apagado, pero hoy día, cualquier SAI medianamente decente admite al menos las 3 primeras opciones.
La decisión la toma el software que corre en el ordenador... y al estar suspendido, las decisiones están en suspenso.
¿Acaso un equipo suspedido no se puede reanimar por un evento de la misma forma que lo puedes iniciar con el "wake-on-lan", el "wake-on-ring" o un adaptador de gestión dedicado? :-)
Quizás, si lo han previsto (por USB creo que no se puede). La mía, no. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEUEARECAAYFAkocb5EACgkQtTMYHG2NR9Wo7QCfZJcIE5Mezdj91H/Ya752bfk4 9nsAmP3W7fBw/oppgEQNmthJ1JH+/iI= =8ARq -----END PGP SIGNATURE-----
El 2009-05-27 a las 00:39 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 00:14 +0200, Camaleón escribió:
El 2009-05-26 a las 21:18 +0200, Carlos E. R. escribió:
Si está suspendido y tiene SAI no puede hacer nada:
¿Ves? por eso mismo no hay que suspenderlo si no es necesario :-)
Pero es que yo no suspendo, hiberno.
Pero has dicho "suspendido".
No he recomendado a nadie que use la suspensión - y por cierto, realmente, los de Novell intentaron activar la suspensión automática al no usar el teclado, que cuando falla, hiberna en cambio.
No se trata de recomendaciones. Se trata de si funciona o no y de las necesidades de cada uno. Hay equipos de control que tienen que estar atentos a eventos: recepción de faxes, gestión del sai, alertas, etc... no pueden estar apagados o hibernados, luego o los dejas encendidos o los suspendes. Si la suspesión no funciona, no te queda más que una opción >:-)
- Si está suspendido y se va la luz, debería poder reaccionar. Por ejemplo, indicando al componente de comunicación con el sai (tarjeta de red, puerto serie o usb) que NO se suspenda.
El problema es si estando suspendido se va la luz, teniendo SAI. El software que controla la SAI no está activo para poder reaccionar, y no está claro que la SAI pueda despertar al equipo para reaccionar.
En los portátiles, esto está previsto, y cuando está suspendido varios dias y la batería se está agotando, se despierta un instante para hibernar y apagar definitivamente.
No hay mucha diferencia entre un portátil y cualquier otro equipo. Si el portátil lo puede hacer, en un equipos de sobremesa o una estación de trabajo no debería tener problemas, técnicamente hablando.
¿Acaso un equipo suspedido no se puede reanimar por un evento de la misma forma que lo puedes iniciar con el "wake-on-lan", el "wake-on-ring" o un adaptador de gestión dedicado? :-)
Quizás, si lo han previsto (por USB creo que no se puede). La mía, no.
No sólo depende del SAI. El sistema operativo también tiene que poder gestionarlo. 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-05-27 a las 08:27 +0200, Camaleón escribió:
El 2009-05-27 a las 00:39 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 00:14 +0200, Camaleón escribió:
El 2009-05-26 a las 21:18 +0200, Carlos E. R. escribió:
Si está suspendido y tiene SAI no puede hacer nada:
¿Ves? por eso mismo no hay que suspenderlo si no es necesario :-)
Pero es que yo no suspendo, hiberno.
Pero has dicho "suspendido".
Porque estoy explicando el problema que hay con suspender.
No he recomendado a nadie que use la suspensión - y por cierto, realmente, los de Novell intentaron activar la suspensión automática al no usar el teclado, que cuando falla, hiberna en cambio.
No se trata de recomendaciones. Se trata de si funciona o no y de las necesidades de cada uno.
Funciona, para algunas cosas concretas. La suspensión automática está muy, pero que muy, verde.
Hay equipos de control que tienen que estar atentos a eventos: recepción de faxes, gestión del sai, alertas, etc... no pueden estar apagados o hibernados, luego o los dejas encendidos o los suspendes.
Yo no te puedo garantizar que un servidor con hylafax suspendido atienda a los faxes entrantes, y menos a los salientes.
Si la suspesión no funciona, no te queda más que una opción >:-)
Pues eso es lo que estoy diciendo. Eso que tu dices sería ideal, pero dudo muchísimo que funcione.
- Si está suspendido y se va la luz, debería poder reaccionar. Por ejemplo, indicando al componente de comunicación con el sai (tarjeta de red, puerto serie o usb) que NO se suspenda.
El problema es si estando suspendido se va la luz, teniendo SAI. El software que controla la SAI no está activo para poder reaccionar, y no está claro que la SAI pueda despertar al equipo para reaccionar.
En los portátiles, esto está previsto, y cuando está suspendido varios dias y la batería se está agotando, se despierta un instante para hibernar y apagar definitivamente.
No hay mucha diferencia entre un portátil y cualquier otro equipo. Si el portátil lo puede hacer, en un equipos de sobremesa o una estación de trabajo no debería tener problemas, técnicamente hablando.
Hay una diferencia crucial entre los portátiles y los sobremesa a estos efectos: que en los portátiles hay una interfaz bastante definida y conocida para controlar e interrogar a la batería y a la fuente de alimentación, cosa que no existe en los fijos con las SAIS. En estos ultimos la conexión es a través de un bus de "alto nivel", como ethernet o USB, que no está diseñado específicamente para esto, y lo que es peor para este uso, que no puede ser gestionado de forma alguna por la BIOS. La BIOS no puede saber si la SAI dice que no hay corriente, mientras que en un portátil sí. Esa diferencia es crucial para esto del control de la suspensión. Los portátiles han sido diseñados para poder ser suspendidos o hibernados, es parte de las pruebas y de su diseño (al menos con Windows). En los sobremesa es secundario (el mio, por ejemplo, si lo suspendo se puede quemar).
¿Acaso un equipo suspedido no se puede reanimar por un evento de la misma forma que lo puedes iniciar con el "wake-on-lan", el "wake-on-ring" o un adaptador de gestión dedicado? :-)
Quizás, si lo han previsto (por USB creo que no se puede). La mía, no.
No sólo depende del SAI. El sistema operativo también tiene que poder gestionarlo.
El sistema operativo está suspendido y no tiene nada que decir ni hacer, no puede aunque quiera. Necesitas una gestión por parte de la BIOS para que empiece a actuar, despierte al sistema, y entonces le pase el control, y sea el sistema operativo el que decida como continuar. Pero el primer paso es exclusivo del hardware, y el segundo de la BIOS. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkodV34ACgkQtTMYHG2NR9X8rACeNrIZt8XfdELHSRADpO3JU/uB VLEAn19IrQtU4DZKS89PXa0w7K8FbXeP =irdo -----END PGP SIGNATURE-----
El 2009-05-27 a las 17:08 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 08:27 +0200, Camaleón escribió:
No se trata de recomendaciones. Se trata de si funciona o no y de las necesidades de cada uno.
Funciona, para algunas cosas concretas. La suspensión automática está muy, pero que muy, verde.
¿Hablas de suspensión o hibernación? Me lías :-)
Hay equipos de control que tienen que estar atentos a eventos: recepción de faxes, gestión del sai, alertas, etc... no pueden estar apagados o hibernados, luego o los dejas encendidos o los suspendes.
Yo no te puedo garantizar que un servidor con hylafax suspendido atienda a los faxes entrantes, y menos a los salientes.
Pues eso estoy diciendo: que un equipo hibernado tiene la misma funcionalidad que un equipo apagado (no pueden procesar trabajos) y que eso no es lo que mucha gente necesita.
Si la suspesión no funciona, no te queda más que una opción >:-)
Pues eso es lo que estoy diciendo. Eso que tu dices sería ideal, pero dudo muchísimo que funcione.
Claro, es como debería ser, esa es la idea. Pero como no funciona, la gente hiberna el equipo para ahorrar y espera obtener la misma funcionalidad que con una suspensión cuando en realidad el equipo hibernado es inútil (en el sentido de que no puede hacer nada, salvo esperar restaurar la sesión).
No hay mucha diferencia entre un portátil y cualquier otro equipo. Si el portátil lo puede hacer, en un equipos de sobremesa o una estación de trabajo no debería tener problemas, técnicamente hablando.
Hay una diferencia crucial entre los portátiles y los sobremesa a estos efectos: que en los portátiles hay una interfaz bastante definida y conocida para controlar e interrogar a la batería y a la fuente de alimentación, cosa que no existe en los fijos con las SAIS. En estos ultimos la conexión es a través de un bus de "alto nivel", como ethernet o USB, que no está diseñado específicamente para esto, y lo que es peor para este uso, que no puede ser gestionado de forma alguna por la BIOS. La BIOS no puede saber si la SAI dice que no hay corriente, mientras que en un portátil sí.
Esa diferencia es crucial para esto del control de la suspensión.
Los portátiles han sido diseñados para poder ser suspendidos o hibernados, es parte de las pruebas y de su diseño (al menos con Windows). En los sobremesa es secundario (el mio, por ejemplo, si lo suspendo se puede quemar).
La interfaz es la misma y la especificación que cumplen también (ACPI versión "x" es la misma para portátiles que servidores o sobremesas) pero las pruebas posteriores a los que los someten, no. Salvo los equipos de empresas de marca (HP, Dell, etc...) que esos sí vienen perfectamente preparados para hibernar y suspender (o aplicar una combinación de ambas) pero claro, bajo Windows.
No sólo depende del SAI. El sistema operativo también tiene que poder gestionarlo.
El sistema operativo está suspendido y no tiene nada que decir ni hacer, no puede aunque quiera. Necesitas una gestión por parte de la BIOS para que empiece a actuar, despierte al sistema, y entonces le pase el control, y sea el sistema operativo el que decida como continuar. Pero el primer paso es exclusivo del hardware, y el segundo de la BIOS.
Bueno, el SO tendrá que interpretar los eventos que recibe de la BIOS para poder volver a la vida en algún momento ¿no? O:-) 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-05-27 a las 17:32 +0200, Camaleón escribió:
El 2009-05-27 a las 17:08 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 08:27 +0200, Camaleón escribió:
No se trata de recomendaciones. Se trata de si funciona o no y de las necesidades de cada uno.
Funciona, para algunas cosas concretas. La suspensión automática está muy, pero que muy, verde.
¿Hablas de suspensión o hibernación? Me lías :-)
Hablo de ambas cosas procurando usar la palabra adecuada en cada caso >:-) Ahí arriba hablo de "suspensión".
Hay equipos de control que tienen que estar atentos a eventos: recepción de faxes, gestión del sai, alertas, etc... no pueden estar apagados o hibernados, luego o los dejas encendidos o los suspendes.
Yo no te puedo garantizar que un servidor con hylafax suspendido atienda a los faxes entrantes, y menos a los salientes.
Pues eso estoy diciendo: que un equipo hibernado tiene la misma funcionalidad que un equipo apagado (no pueden procesar trabajos) y que eso no es lo que mucha gente necesita.
Pero ahí arriba hablo de suspensión, que es el único estado, que yo sepa, que tiene alguna posibilidad de parecerse al de un hardware dedicado con estado de ahorro energético. Y digo que no es capaz, que yo sepa, de imitar eso que cuentas que sí puede hacer un fax en hardware, entrar en estado de "suspensión" y despertarse para recibir un fax. Pero debería, el puerto serie tiene previsto despertar al ordenador. Si yo pudiera lo probaría.
Si la suspesión no funciona, no te queda más que una opción >:-)
Pues eso es lo que estoy diciendo. Eso que tu dices sería ideal, pero dudo muchísimo que funcione.
Claro, es como debería ser, esa es la idea.
Pero como no funciona, la gente hiberna el equipo para ahorrar y espera obtener la misma funcionalidad que con una suspensión cuando en realidad el equipo hibernado es inútil (en el sentido de que no puede hacer nada, salvo esperar restaurar la sesión).
Pero yo no he hablado de hibernar y tratar de conseguir la misma funcionalidad que suspendido. Yo no tengo esa confusión. Lo que sí ocurre, en linux, con la suspensión automática, es que si el equipo quiere suspender y no puede, en su lugar hiberna, que es lo que les pasó a la gente de IBM, y a mí antes que a ellos (y a mi reporte no le hicieron caso en Novell, y al de IBM sí).
No hay mucha diferencia entre un portátil y cualquier otro equipo. Si el portátil lo puede hacer, en un equipos de sobremesa o una estación de trabajo no debería tener problemas, técnicamente hablando.
Hay una diferencia crucial entre los portátiles y los sobremesa a estos efectos: que en los portátiles hay una interfaz bastante definida y conocida para controlar e interrogar a la batería y a la fuente de alimentación, cosa que no existe en los fijos con las SAIS. En estos ultimos la conexión es a través de un bus de "alto nivel", como ethernet o USB, que no está diseñado específicamente para esto, y lo que es peor para este uso, que no puede ser gestionado de forma alguna por la BIOS. La BIOS no puede saber si la SAI dice que no hay corriente, mientras que en un portátil sí.
Esa diferencia es crucial para esto del control de la suspensión.
Los portátiles han sido diseñados para poder ser suspendidos o hibernados, es parte de las pruebas y de su diseño (al menos con Windows). En los sobremesa es secundario (el mio, por ejemplo, si lo suspendo se puede quemar).
La interfaz es la misma y la especificación que cumplen también (ACPI versión "x" es la misma para portátiles que servidores o sobremesas) pero las pruebas posteriores a los que los someten, no.
Salvo los equipos de empresas de marca (HP, Dell, etc...) que esos sí vienen perfectamente preparados para hibernar y suspender (o aplicar una combinación de ambas) pero claro, bajo Windows.
No, la interfaz no es en absoluto la misma, porque en un portatil ese ACPI engloba la batería, mientras que en un fijo no engloba la SAI.
No sólo depende del SAI. El sistema operativo también tiene que poder gestionarlo.
El sistema operativo está suspendido y no tiene nada que decir ni hacer, no puede aunque quiera. Necesitas una gestión por parte de la BIOS para que empiece a actuar, despierte al sistema, y entonces le pase el control, y sea el sistema operativo el que decida como continuar. Pero el primer paso es exclusivo del hardware, y el segundo de la BIOS.
Bueno, el SO tendrá que interpretar los eventos que recibe de la BIOS para poder volver a la vida en algún momento ¿no? O:-)
Está muy verde. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkodjakACgkQtTMYHG2NR9VwzgCeKvPRufkWDm0a33H32nELIwuh ui8An1pkvUzMTuT9CmnwHcVvrCsx5oiO =8Ihc -----END PGP SIGNATURE-----
El 2009-05-27 a las 20:59 +0200, Carlos E. R. escribió:
El 2009-05-27 a las 17:32 +0200, Camaleón escribió:
Pues eso estoy diciendo: que un equipo hibernado tiene la misma funcionalidad que un equipo apagado (no pueden procesar trabajos) y que eso no es lo que mucha gente necesita.
Pero ahí arriba hablo de suspensión, que es el único estado, que yo sepa, que tiene alguna posibilidad de parecerse al de un hardware dedicado con estado de ahorro energético. Y digo que no es capaz, que yo sepa, de imitar eso que cuentas que sí puede hacer un fax en hardware, entrar en estado de "suspensión" y despertarse para recibir un fax.
Pero debería, el puerto serie tiene previsto despertar al ordenador. Si yo pudiera lo probaría.
Oye, la suspensión funciona de maravilla en windows :-O
La interfaz es la misma y la especificación que cumplen también (ACPI versión "x" es la misma para portátiles que servidores o sobremesas) pero las pruebas posteriores a los que los someten, no.
Salvo los equipos de empresas de marca (HP, Dell, etc...) que esos sí vienen perfectamente preparados para hibernar y suspender (o aplicar una combinación de ambas) pero claro, bajo Windows.
No, la interfaz no es en absoluto la misma, porque en un portatil ese ACPI engloba la batería, mientras que en un fijo no engloba la SAI.
Bueno, deja que te comente una cosa. Al estar haciendo las pruebas de la suspensión y el SAI, he visto que en el administrador de dispositivos del windows aparece el mismo elemento que aparece listado en los portátiles: Batería. Bien, entrando en las opciones de la batería, se puede activar la opción de "Permitir a este componente reactivar el equipo" que es la misma opción que tienen tanto la tarjeta de red como el módem. Esa opción está activada en la tarjeta de red (por eso al hacer ping al equipo suspendido se restauraba) y es por eso por lo que funciona la reanimación del equipo suspendido cuando se corta el suministro de luz. Vamos, que "chapó" para los de Redmon.
Bueno, el SO tendrá que interpretar los eventos que recibe de la BIOS para poder volver a la vida en algún momento ¿no? O:-)
Está muy verde.
En Linux... sí :-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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-28 a las 20:09 +0200, Camaleón escribió:
El 2009-05-27 a las 20:59 +0200, Carlos E. R. escribió:
con estado de ahorro energético. Y digo que no es capaz, que yo sepa, de imitar eso que cuentas que sí puede hacer un fax en hardware, entrar en estado de "suspensión" y despertarse para recibir un fax.
Pero debería, el puerto serie tiene previsto despertar al ordenador. Si yo pudiera lo probaría.
Oye, la suspensión funciona de maravilla en windows :-O
Ya...
Bueno, deja que te comente una cosa.
Al estar haciendo las pruebas de la suspensión y el SAI, he visto que en el administrador de dispositivos del windows aparece el mismo elemento que aparece listado en los portátiles: Batería.
Bien, entrando en las opciones de la batería, se puede activar la opción de "Permitir a este componente reactivar el equipo" que es la misma opción que tienen tanto la tarjeta de red como el módem.
Ah.
Esa opción está activada en la tarjeta de red (por eso al hacer ping al equipo suspendido se restauraba) y es por eso por lo que funciona la reanimación del equipo suspendido cuando se corta el suministro de luz.
Se entiende.
Vamos, que "chapó" para los de Redmon.
Por mucho que nos fastidie, la verdad es que saben hacer cosas, aunque tengan bugs. Jo, estos dias estoy editando un fichero grande en Word, y luego lo miro en casa con oowriter - y curiosamente el Word es mucho más rápido en cosas como grabar el fichero.
Bueno, el SO tendrá que interpretar los eventos que recibe de la BIOS para poder volver a la vida en algún momento ¿no? O:-)
Está muy verde.
En Linux... sí :-P
Pero de eso se trata. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEUEARECAAYFAkoe5twACgkQtTMYHG2NR9X0nQCXfJ961+R3UvJSRGVF3Jc61JK5 ZwCeLfI/JDcnqnZkrUoa2PcuNiVYc3E= =r/kQ -----END PGP SIGNATURE-----
On Thursday 28 May 2009 21:32:43 Carlos E. R. wrote:
Por mucho que nos fastidie, la verdad es que saben hacer cosas, aunque tengan bugs. Jo, estos dias estoy editando un fichero grande en Word, y luego lo miro en casa con oowriter - y curiosamente el Word es mucho más rápido en cosas como grabar el fichero.
OpenOffice es java. Como muy bien dijiste hace algún tiempo la ingeniería es un problema de compromisos. Lo que se gana por un lado se pierde por otro. Todos los lenguajes transportables son menos eficientes que los dedicados a una estructura de CPU en concreto. -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-28 a las 21:44 +0200, Lluis escribió:
Por mucho que nos fastidie, la verdad es que saben hacer cosas, aunque tengan bugs. Jo, estos dias estoy editando un fichero grande en Word, y luego lo miro en casa con oowriter - y curiosamente el Word es mucho más rápido en cosas como grabar el fichero.
OpenOffice es java.
¡Y unas narices! Es C o C++. Lo que va con java son los wizzard y las macros. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkofAlgACgkQtTMYHG2NR9WwBQCeIXc9t5jCZ+pQnEEABtSKgUCS WHMAn3jilZODIsMhlR5QDsgEKTOM/aZn =57om -----END PGP SIGNATURE-----
On Wednesday 27 May 2009 17:08:38 Carlos E. R. wrote:
El sistema operativo está suspendido y no tiene nada que decir ni hacer, no puede aunque quiera. Necesitas una gestión por parte de la BIOS para que empiece a actuar, despierte al sistema, y entonces le pase el control, y sea el sistema operativo el que decida como continuar. Pero el primer paso es exclusivo del hardware, y el segundo de la BIOS.
La BIOS es una memoria de programa. Habitualmente una memoria de tecnología Flash. No ejecuta ni gestiona nada. Lo que trabaja es la o las CPUs. Cuando el sistema esta suspendido, la información en RAM se mantiene, por lo que hay que suponer que la circuitería de refresco de RAM sigue viva. Por tanto no tendría que haber ningún problema en dejar algo de código en dicha RAM para uso y disfrute del SAI Lo que pasa es que la mayoría de fabricantes de SAI son un mundo aparte. Poco o nada estandarizados. Inmersos en el soft privativo y en general malo y caro. Quizás es que el mundo de las baterías( su mayor problema) esta muy alejado del mundo del soft y la microinformatica. -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-27 a las 19:15 +0200, Lluis escribió:
On Wednesday 27 May 2009 17:08:38 Carlos E. R. wrote:
El sistema operativo está suspendido y no tiene nada que decir ni hacer, no puede aunque quiera. Necesitas una gestión por parte de la BIOS para que empiece a actuar, despierte al sistema, y entonces le pase el control, y sea el sistema operativo el que decida como continuar. Pero el primer paso es exclusivo del hardware, y el segundo de la BIOS.
La BIOS es una memoria de programa. Habitualmente una memoria de tecnología Flash.
No ejecuta ni gestiona nada.
Lo que trabaja es la o las CPUs.
No me seas tiquismiquis! :-) Es una memoria (x)ROM que contiene software, que se ejecuta directamente desde esa memoria, o desde su copia en RAM. Y algunos circuitos que hacen cosillas y que, en principio, sólo el software de la BIOS conoce, hasta que alguien lo despieza y entonces Linux también los conoce.
Cuando el sistema esta suspendido, la información en RAM se mantiene, por lo que hay que suponer que la circuitería de refresco de RAM sigue viva.
Por tanto no tendría que haber ningún problema en dejar algo de código en dicha RAM para uso y disfrute del SAI
Sí, la RAM sigue plenamente "activa", porque si no se borra. Pero la CPU, y esto no lo tengo seguro, puede estar apagada, si se activa es como en un encendido normal. Podría despertar y ejecutar código de la ram, o despertar y ejecutar código de un puntero programado en fábrica, de la bios. Esto no lo sé cierto, no hay un libro que publique todas esas especificaciones actuales, o no es fácilmente asequible.
Lo que pasa es que la mayoría de fabricantes de SAI son un mundo aparte. Poco o nada estandarizados.
Cierto.
Inmersos en el soft privativo y en general malo y caro.
El soft que controla mi SAI en linux es plenamente abierto, no uso el de la SAI. No he leído que diga nada de controlar estados de suspensión, pero sí que se que el driver funciona en modo "polling", por lo que no hay nada que hacer.
Quizás es que el mundo de las baterías( su mayor problema) esta muy alejado del mundo del soft y la microinformatica.
Es simplemente que no hay un estandard definido, y cada uno lo ha hecho como ha podido. Y eso es diferente del mundo de los portátiles a este respecto, es un comportamiento definido en la BIOS. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkodiMgACgkQtTMYHG2NR9UsyQCdGyOxv2M4qWg0QiA3/WxVD6bO 6lYAoIEX6QiAAv6vXbuFsSI3P3+xGdbY =CyvX -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-25 a las 15:59 -0300, Alfredo J. Delaiti escribió:
de energía. Para el ejemplo que expuse hay que tener en cuenta que es un caso real, la gente no le gusta estar apagando las máquinas y quieren que cuando vuelvan a sentarse frente a ellas este todo como lo han dejados, es una cuestión cultural y yo no puedo cambiarlo,
Es que lo lógico es trabajar lo justo. Apagar y encender es una pérdida de tiempo intolerable, cuando hibernar y despertar supone un minuto o dos, con todos los programas encendidos en el mismo punto.
La idea es que se apague cuando termine de trabajar, el problema es que no se sabe cuanto tardará en hacer lo que se le ha pedido, se tiene una estimación, pero es solo eso, una estimación.
man batch.
Ejemplo: supongamos que podemos dar en una sola instrucción que se compile el kernel y se instale. Cuanto tardará en realizarlo, no sé, depende principalmente de lo que se haya configurado y del poder de cálculo del CPU, bueno cuando se termine de hacer podría apagarse hasta que el operador vuelva a estar frente al ordenador.
En esa situación ni se me ocurre hibernar. Que compile, e instale si tiene éxito, y que se espere a que yo vaya a comprobarlo personalmente. No me fío un pelo. Es más, en esa situación no puedes hibernar: tienes que rebotar para activar el nuevo kernel, y entonces hibernar. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkobEZsACgkQtTMYHG2NR9WCpQCZARkElGJDBUUlo6FTOzrJXfs1 6VMAn13hY4J6DnOgXW0fPxXsgBNlUYw9 =/dRg -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-24 a las 18:41 -0300, Alfredo J. Delaiti escribió: ...
Otro caso, es el que me vendría, por ejemplo, en mi caso, es el de indicar que si tal programa se esta ejecutando entonces no se inicie la suspensión automática. Creo que esto último tiene que ser algo simple de implementar.
No sólo no es simple sino que es imposible, porque no existe ninguna manera de configurar eso. Nadie ha hecho una herramienta (en openSUSE, al menos) para hacer tal cosa. Lo que existe unicamente es, que si no estás tecleando o moviendo el rató durante unos minutos, o suspende a memoria, o se hiberna entero. Punto. Si quieres una decisión más meditada, pues como no la pintes tu mismo, no existe. Abrid un FATE... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoZ6UQACgkQtTMYHG2NR9X7iQCfR75XN74n4Fxqe7o5P3vDF3LZ 718An1NEyZeZ1yEvy7VXtb+rzOP3pXvJ =tH0O -----END PGP SIGNATURE-----
El 2009-05-25 a las 02:41 +0200, Carlos E. R. escribió:
El 2009-05-24 a las 18:41 -0300, Alfredo J. Delaiti escribió:
...
Otro caso, es el que me vendría, por ejemplo, en mi caso, es el de indicar que si tal programa se esta ejecutando entonces no se inicie la suspensión automática. Creo que esto último tiene que ser algo simple de implementar.
No sólo no es simple sino que es imposible, porque no existe ninguna manera de configurar eso. Nadie ha hecho una herramienta (en openSUSE, al menos) para hacer tal cosa.
Lo que existe unicamente es, que si no estás tecleando o moviendo el rató durante unos minutos, o suspende a memoria, o se hiberna entero. Punto.
Si quieres una decisión más meditada, pues como no la pintes tu mismo, no existe.
Abrid un FATE...
Los del TuxOnIce* tienen buenas ideas. Si en lugar de discutir con los desarrolladores del kernel sobre quién debe llevar las riendas de la hibernación (user space o kernel) se fusionaran ambos proyectos, el proceso sería mucho más completo y con más opciones de configuración. ¿Abrimos un "fate" para que dejen de discutir? >:-) * http://www.tuxonice.net 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
On Sunday 24 May 2009 23:41:39 Alfredo J. Delaiti wrote:
Hola
Este es un ejemplo real donde se ve su beneficio.
En unas oficinas construidas hace unos 25 años hay cerca de una docena de pc donde sus operadores están constantemente saliendo para hacer trámites por lo que la pc esta normalmente sin usar, dado el tipo de actividad que realizan no comparten las pc. El problema que tienen es el dimensionamiento del sistema eléctrico fue hecho para hace 25 años (donde no había computadoras o era algo muy raro) y ahora con tanta cantidad de pc y aires acondicionados están al límite, de hecho cada vez que intentan conectar algún equipo extra los sistemas de protección eléctrica se accionan dejándoles a oscuras y sin poder trabajar por unos minutos. Puesto que reemplazar el sistema eléctrico tiene un costo que por ahora no desean invertir y tampoco pueden parar 1 o 2 días para su reemplazo la solución que les propuse y lleve a cabo fue activar el sistema de ahorro de energía de las pc, con lo que se bajo un poco el consumo porque en promedio solo la mitad de las máquinas están funcionando simultáneamente.
¿Y no seria mejor mentalizar al personal para que apague cuando se va? También podría servir algo ligado al control de presencia. -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-25 a las 16:36 +0200, Lluis escribió:
¿Y no seria mejor mentalizar al personal para que apague cuando se va? También podría servir algo ligado al control de presencia.
Eso no sirve, porque nadie apaga a mitad de la jornada: vas a volver, tienes que encenderlo otra vez y arrancar todo: demasiado lento. Pero sí pueden hibernar, porque se vuelve a encender con todo puesto en un minuto. Mira, donde estoy ahora dejamos los ordenadores prendidos toda la noche, incluso el fin de semana, porque tardamos 20 minutos en enceder cada uno (de reloj). A la porra el ahorro de energía. Y no hibernamos porque son XP con 9 gigas de disco duro, y no pueden, que yo sepa. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkobD30ACgkQtTMYHG2NR9VXKgCfYu6x/ToevAR0Mk8ew1JgqiZL REoAnRtnr3uPFsZ5jdtWT1EPSIg1C+Az =Xnz3 -----END PGP SIGNATURE-----
El 2009-05-25 a las 23:36 +0200, Carlos E. R. escribió:
El 2009-05-25 a las 16:36 +0200, Lluis escribió:
¿Y no seria mejor mentalizar al personal para que apague cuando se va? También podría servir algo ligado al control de presencia.
Eso no sirve, porque nadie apaga a mitad de la jornada: vas a volver, tienes que encenderlo otra vez y arrancar todo: demasiado lento. Pero sí pueden hibernar, porque se vuelve a encender con todo puesto en un minuto.
Eso es una posible opción. Otra opción es dejarlos encendidos. Sin actividad el consumo es mínimo. Y otra opción es apagarlos (que sí, que hay equipos que se inician en 3 minutos y hay usuarios que sólo necesitan tener abiertas sólo 4 aplicaciones :-P)
Mira, donde estoy ahora dejamos los ordenadores prendidos toda la noche, incluso el fin de semana, porque tardamos 20 minutos en enceder cada uno (de reloj). A la porra el ahorro de energía. Y no hibernamos porque son XP con 9 gigas de disco duro, y no pueden, que yo sepa.
¿Por qué no van a poder? :-? Para hibernar en windows xp se necesita el mismo espacio libre en el disco o partición del sistema que cantidad de ram. Ahora bien, yo no dejaba un equipo de oficina "ni encendido ni hibernado ni suspendido" toda la noche si no va a tener actividad. Eso sí es peligroso porque ni los equipos suelen estar preparados para eso (las fuentes de alimentación son sencillas) ni el entorno está preparado para eso (polvo, calor, cables, papeles y material inflamable...). 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-05-26 a las 08:49 +0200, Camaleón escribió:
El 2009-05-25 a las 23:36 +0200, Carlos E. R. escribió:
El 2009-05-25 a las 16:36 +0200, Lluis escribió:
¿Y no seria mejor mentalizar al personal para que apague cuando se va? También podría servir algo ligado al control de presencia.
Eso no sirve, porque nadie apaga a mitad de la jornada: vas a volver, tienes que encenderlo otra vez y arrancar todo: demasiado lento. Pero sí pueden hibernar, porque se vuelve a encender con todo puesto en un minuto.
Eso es una posible opción.
Otra opción es dejarlos encendidos. Sin actividad el consumo es mínimo.
Menor sí es, pero no tanto: yo creo, a ojo, que es más de la mitad.
Y otra opción es apagarlos (que sí, que hay equipos que se inician en 3 minutos y hay usuarios que sólo necesitan tener abiertas sólo 4 aplicaciones :-P)
El mío no arranca en tres minutos. Vale, sí arranca, en modo texto en tres minutos, creo. Falta entrar en modo texto para dar las contraseñas de las particiones encriptadas, arrancar algún daemon manual, entrar en modo gráfico, loguearme... y esta fase tarda un minuto o dos, sin contar con abrir todas las aplicaciones que uso, que en este instante son... 1, 2, 3,... 10,...20,... 34. Sí, tengo 34 aplicaciones arrancadas, y una de ellas es el vmware con otras tantas, según, y otra es el firefox con nosecuantos tabs abiertos... ah, sin contar que algun xterm son sesiones ssh contra el virtual. No es una cosa que me encante hacer todos los dias. Ahora mismo lleva 35 dias abierto.
Mira, donde estoy ahora dejamos los ordenadores prendidos toda la noche, incluso el fin de semana, porque tardamos 20 minutos en enceder cada uno (de reloj). A la porra el ahorro de energía. Y no hibernamos porque son XP con 9 gigas de disco duro, y no pueden, que yo sepa.
¿Por qué no van a poder? :-?
Para hibernar en windows xp se necesita el mismo espacio libre en el disco o partición del sistema que cantidad de ram.
Mmm, medio giga... pues lo he probado esta mañana (te he leido por web; no puedo entrar en gmail, está restringido, pero no han bloqueado la web de opensuse, así que he visto tu respuesta), y sí, tienes razón, funciona perfectamente. Mañana veré si la base de datos en red ha resistido tanto tiempo en "off". Y suspende y arranca muy rápido. Es que mi experiencia hibernando con el Me fué bastante penosa, fallaba mucho: con el XP va muy bien, basado en mi experiencia de una vez. Ahora que recuerdo, con el NT del año 2000 también me iba bien con el portatil que tenía entonces, cosa que el linux de entonces no podía presumir ni de lejos.
Ahora bien, yo no dejaba un equipo de oficina "ni encendido ni hibernado ni suspendido" toda la noche si no va a tener actividad. Eso sí es peligroso porque ni los equipos suelen estar preparados para eso (las fuentes de alimentación son sencillas) ni el entorno está preparado para eso (polvo, calor, cables, papeles y material inflamable...).
Tienes toda la razón, estoy totalmente de acuerdo. Pero ya pueden los grandes jefes marcar la política general de apagar y ahorrar energía, que los curritos, incluyendo los jefes, los dejan prendidos toda la noche, incluso el fin de semana, por no estar media hora por la mañana arrancando (por culpa de las comprobaciones de seguridad e inicializaciones via red) mientras tienes prisa con un pedido. Media hora es mucho esperar. Ahora, que no son equipos tan "sencillos" si aguantan ese maltrato durante un par de lustros (el mio es un PIII, te puedes imaginar la antiguedad...). Alucino. Pero en fin, yo soy un grumete, y no estoy como informático. Al menos ahora, si mi experimento hibernando funciona, intentaré convencer a los de mi alrededor. Gracias por la idea :-) Ah, ¿dices que no lo dejabas hibernado toda la noche? Pues yo llevo años haciendolo en linux todos los dias, es muy fiable. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkocPOwACgkQtTMYHG2NR9UNLACgjQvDF+Zp9UNB18MrW58JMMGH SocAnRNwJfCUNpv0TDL72yCLRfPZrVVf =RHx9 -----END PGP SIGNATURE-----
On Tuesday 26 May 2009 21:03:00 Carlos E. R. wrote:
El mío no arranca en tres minutos. Vale, sí arranca, en modo texto en tres minutos, creo. Falta entrar en modo texto para dar las contraseñas de las particiones encriptadas, arrancar algún daemon manual, entrar en modo gráfico, loguearme... y esta fase tarda un minuto o dos, sin contar con abrir todas las aplicaciones que uso, que en este instante son... 1, 2, 3,... 10,...20,... 34. Sí, tengo 34 aplicaciones arrancadas, y una de ellas es el vmware con otras tantas, según, y otra es el firefox con nosecuantos tabs abiertos... ah, sin contar que algun xterm son sesiones ssh contra el virtual.
Y todo eso te hace falta a la vez???
Es que mi experiencia hibernando con el Me fué bastante penosa, fallaba mucho: con el XP va muy bien, basado en mi experiencia de una vez. Ahora que recuerdo, con el NT del año 2000 también me iba bien con el portatil que tenía entonces, cosa que el linux de entonces no podía presumir ni de lejos.
Bueno, NT era un SO y Me un apaño.
Ahora bien, yo no dejaba un equipo de oficina "ni encendido ni hibernado ni suspendido" toda la noche si no va a tener actividad. Eso sí es peligroso porque ni los equipos suelen estar preparados para eso (las fuentes de alimentación son sencillas) ni el entorno está preparado para eso (polvo, calor, cables, papeles y material inflamable...).
Tampoco hay para tanto, hay diferenciales y magnetotermicos por ahi. Si no los cambias por tornillos y no dejaslospapeles encima de la FA no hay problema.
Tienes toda la razón, estoy totalmente de acuerdo. Pero ya pueden los grandes jefes marcar la política general de apagar y ahorrar energía, que los curritos, incluyendo los jefes, los dejan prendidos toda la noche,
Eso tiene arreglo fácil, a las doce, corte de luz. El que no haya apagado tendrá algo incompleto al día siguiente. Además, en algunos trabajos, no se hace lo que uno quiere, sino lo que quiere la empresa.
incluso el fin de semana, por no estar media hora por la mañana arrancando (por culpa de las comprobaciones de seguridad e inicializaciones via red) mientras tienes prisa con un pedido. Media hora es mucho esperar.
Que alguien ponga algo para que arranquen a las 6 de la mañana.
Pero en fin, yo soy un grumete, y no estoy como informático.
Mejor, vives mas tranquilo.
Al menos ahora, si mi experimento hibernando funciona, intentaré convencer a los de mi alrededor. Gracias por la idea :-)
Piensatelo dos veces -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-26 a las 21:21 +0200, Lluis escribió:
On Tuesday 26 May 2009 21:03:00 Carlos E. R. wrote:
El mío no arranca en tres minutos. Vale, sí arranca, en modo texto en tres minutos, creo. Falta entrar en modo texto para dar las contraseñas de las particiones encriptadas, arrancar algún daemon manual, entrar en modo gráfico, loguearme... y esta fase tarda un minuto o dos, sin contar con abrir todas las aplicaciones que uso, que en este instante son... 1, 2, 3,... 10,...20,... 34. Sí, tengo 34 aplicaciones arrancadas, y una de ellas es el vmware con otras tantas, según, y otra es el firefox con nosecuantos tabs abiertos... ah, sin contar que algun xterm son sesiones ssh contra el virtual.
Y todo eso te hace falta a la vez???
Pues no, pero cuando cambio de tarea no me gusta perder el tiempo arrancandolo de nuevo. Puedo dejarlo en cualquier punto, pasar a otra cosa, y volver cuando me apetece, con la aplicación abierta.
Ahora bien, yo no dejaba un equipo de oficina "ni encendido ni hibernado ni suspendido" toda la noche si no va a tener actividad. Eso sí es peligroso porque ni los equipos suelen estar preparados para eso (las fuentes de alimentación son sencillas) ni el entorno está preparado para eso (polvo, calor, cables, papeles y material inflamable...).
Tampoco hay para tanto, hay diferenciales y magnetotermicos por ahi. Si no los cambias por tornillos y no dejaslospapeles encima de la FA no hay problema.
Siempre hay papeles cerca, aunque no sea exactamente encima. Los incendios ocurren.
Tienes toda la razón, estoy totalmente de acuerdo. Pero ya pueden los grandes jefes marcar la política general de apagar y ahorrar energía, que los curritos, incluyendo los jefes, los dejan prendidos toda la noche,
Eso tiene arreglo fácil, a las doce, corte de luz. El que no haya apagado tendrá algo incompleto al día siguiente. Además, en algunos trabajos, no se hace lo que uno quiere, sino lo que quiere la empresa.
Bueno, las responsabilidades están distribuidas, los de informática no tienen control de los plomos, y menos en todas las dependencias.
incluso el fin de semana, por no estar media hora por la mañana arrancando (por culpa de las comprobaciones de seguridad e inicializaciones via red) mientras tienes prisa con un pedido. Media hora es mucho esperar.
Que alguien ponga algo para que arranquen a las 6 de la mañana.
No es mala idea, la cmos suele poder hacer eso - si es que no la han bloqueado, no he mirado (están bastante capados por seguridad). Pero no sirve, porque hay que entrar contraseñas para la segunda parte del arranque, hay tres (arranque, login, 2ndo login). Cada una de las fases son de cinco a diez minutos.
Pero en fin, yo soy un grumete, y no estoy como informático.
Mejor, vives mas tranquilo.
Respecto a eso si, tengo otras responsabilidades :-)
Al menos ahora, si mi experimento hibernando funciona, intentaré convencer a los de mi alrededor. Gracias por la idea :-)
Piensatelo dos veces
No pasa nada, si no quisieran que lo usáramos lo habrían bloqueado los de informática. Si mi ordenador falla mañana, pues hay otro que se ha quedado encendido. Lo más normal es que falle una aplicación que usamos y que va en red; en ese caso, pues la cierro antes de hibernar, y luego la arranco, que es la tercera fase del arranque. Y si funciona, serán los jefes los que sugieran esa táctica y lo propongan, poniendose la respectiva medallita por ahorrar unos puntos del programa anual de ahorro energético >:-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkocY/EACgkQtTMYHG2NR9XLIACfc9doSaOapL/uK7xl52oIyHqo U/wAn2F30mn3uY2mg32qT+OOnk31To/q =OSEA -----END PGP SIGNATURE-----
On Tuesday 26 May 2009 23:49:29 Carlos E. R. wrote:
Y todo eso te hace falta a la vez???
Pues no, pero cuando cambio de tarea no me gusta perder el tiempo arrancandolo de nuevo. Puedo dejarlo en cualquier punto, pasar a otra cosa, y volver cuando me apetece, con la aplicación abierta.
Bueno, sobre gustos.... Has medido lo que te ralentiza tener todo eso en marcha en el cacharro. A lo mejor es mas rapido iniciar lo que quieres. !!Lo siento, soy delmundo del microprocesador, mas de dos tareas aparcadas, me parece aberrante.
Siempre hay papeles cerca, aunque no sea exactamente encima. Los incendios ocurren.
Bueno, cada uno tiene la experiencia profesional que tiene. Yo, mas o menos te la he descrito. Cambiaron los fusibles por tornillos, y dejaron la documentación encima de la FA
Bueno, las responsabilidades están distribuidas, los de informática no tienen control de los plomos, y menos en todas las dependencias.
Pues nada, no problem... Ya apañara con el muerto el que pueda cortar la luz. Deben estar dtstribuidas las irresponsabilidades, mas bien.
Que alguien ponga algo para que arranquen a las 6 de la mañana.
No es mala idea, la cmos suele poder hacer eso - si es que no la han bloqueado, no he mirado (están bastante capados por seguridad). Pero no sirve, porque hay que entrar contraseñas para la segunda parte del arranque, hay tres (arranque, login, 2ndo login). Cada una de las fases son de cinco a diez minutos.
Algo muy seguro, que se pasa media vida conectado sin hacer nada???? No es mi concepto de seguridad Un cacharro seguro es un cacharro apagado El resto.... farfolla
Y si funciona, serán los jefes los que sugieran esa táctica y lo propongan, poniendose la respectiva medallita por ahorrar unos puntos del programa anual de ahorro energético >:-)
Desgraciadamente sin comentarios -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-27 a las 00:19 +0200, Lluis escribió:
Pues no, pero cuando cambio de tarea no me gusta perder el tiempo arrancandolo de nuevo. Puedo dejarlo en cualquier punto, pasar a otra cosa, y volver cuando me apetece, con la aplicación abierta.
Bueno, sobre gustos.... Has medido lo que te ralentiza tener todo eso en marcha en el cacharro. A lo mejor es mas rapido iniciar lo que quieres.
Un poco. Para eso tengo previsto comprarme un chisme más potente cuando pueda. Pero no creo que afecte mucho, mientras no sean aplicaciones como el firefox que ocupa medio giga a los dos o tres dias. La mayoría de las cosas son terminales con texto (incluido varios mc).
!!Lo siento, soy delmundo del microprocesador, mas de dos tareas aparcadas, me parece aberrante.
Lo entiendo, pero los ordenadores estos son multitarea, multiusuario, etc, etc... pues que trabajen.
Siempre hay papeles cerca, aunque no sea exactamente encima. Los incendios ocurren.
Bueno, cada uno tiene la experiencia profesional que tiene. Yo, mas o menos te la he descrito. Cambiaron los fusibles por tornillos, y dejaron la documentación encima de la FA
Si, he visto lo de "forzar" los fusibles otras veces :-(
Bueno, las responsabilidades están distribuidas, los de informática no tienen control de los plomos, y menos en todas las dependencias.
Pues nada, no problem... Ya apañara con el muerto el que pueda cortar la luz. Deben estar dtstribuidas las irresponsabilidades, mas bien.
En una organización compleja las cosas no tienen el mismo tipo de control que en una pequeña.
Que alguien ponga algo para que arranquen a las 6 de la mañana.
No es mala idea, la cmos suele poder hacer eso - si es que no la han bloqueado, no he mirado (están bastante capados por seguridad). Pero no sirve, porque hay que entrar contraseñas para la segunda parte del arranque, hay tres (arranque, login, 2ndo login). Cada una de las fases son de cinco a diez minutos.
Algo muy seguro, que se pasa media vida conectado sin hacer nada???? No es mi concepto de seguridad Un cacharro seguro es un cacharro apagado El resto.... farfolla
Son diferentes conceptos de seguridad. Yo hablo de la del NT, que está capado para que por ejemplo, no pueda instalar OOo o flash, o navegar por gmail o hotmail. O tener diferentes contraseñas para diferentes cosas. Se supone que si te vas el ordenador lo apagas o bloqueas; de todas formas, gente de fuera no hay, es un entorno muy controlado. El problema es que una cosa es lo que diseñen unos, y otra es lo que los medios físicos empleados permitan en la realidad. Está muy bien poner contraseñas, pero está muy mal que el sistema tarde media hora en ponerse en marcha, obligando a los usuarios a no apagar. No te voy a decir de qué entorno se trata, pero estoy seguro de que muchos hay por acá que han trabajado o trabajan en entornos similares. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkocduEACgkQtTMYHG2NR9WjFwCdGfQhhOxeWX1QEl/vfYAK5gR4 SgQAn15wnxUxG7nDrmjZqOn5ncWIVAER =XQTg -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-05-22 a las 00:44 -0300, Alfredo J. Delaiti escribió:
Lo que escribía y se perdió es que no entra en suspernsión hasta que mencoder termina. Tener en cuenta que no estoy usando la pc, en este caso la estoy utilizando como videograbadora.
Los programas de vídeo suelen inhibir el salvapantallas, y la hibernación se dispara con el mismo mecanismo que el salvapantallas. Es una excepción. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoXJRMACgkQtTMYHG2NR9X7sgCfVM3D/DpcO12mUOaLHdbJbNjq SYoAoI4CByrJXx6wzyK9vKbcIblN36mc =gpq6 -----END PGP SIGNATURE-----
El día 22 de mayo de 2009 0:44, Alfredo J. Delaiti
Hola
Ooops, se ha roto el mensaje, que raro!
Lo que escribía y se perdió es que no entra en suspernsión hasta que mencoder termina. Tener en cuenta que no estoy usando la pc, en este caso la estoy utilizando como videograbadora.
Nos puedes contar algo más de como utilizas mencoder? Lo usas desde consola? Como haces para pausar la grabación en los espcios publicitarios? Yo tengo una tarjeta ATI HDTV Wonder, pero no encontrado una aplicación decente para grabar desde Linux, creo que la ultima vez que probé, no me entraba el sonido, conectada a traves de la entrada de video compuesto. http://ati.amd.com/products/hdtvwonder/specs.html El lspci me da: 03:00.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) 03:00.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05) 03:00.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) Grabando desde windows, graba perfectamente desde la salida del decodificador de directv, y la calidad, es como si estuviera viendo un dvd. Desde opensuse, aparece en el listado de tarjetas soportadas, volvi a verificar la configuración, y allí pude ver algo, en una ventana de configuracion donde pregunta a que tarjeta de sonido está conectada la tarjeta, cuando en realidad, no trae ninguna conexion externa de audio, como puede verse en la foto del link, y debo seleccionar "No conectada" (en el mezcaldor de sonido aparece la solapa "Conexant CX8801"): http://www.mythtv.org/wiki/ATI_HDTV_Wonder El firmware estaba instalado, y lo volvi a reinstalar. Lo rarto, es que en el howto para opensuse 10.2, dice que debe estar instalado el paquete dvb, pero sin embargo, en la 11.1, ese paquete no aparece. 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
El 24/05/09, Juan Erbes escribió: (...)
El firmware estaba instalado, y lo volvi a reinstalar. Lo rarto, es que en el howto para opensuse 10.2, dice que debe estar instalado el paquete dvb, pero sin embargo, en la 11.1, ese paquete no aparece.
Sólo un apunte. El paquete lo tienes en los repos: *** http://software.opensuse.org/search?baseproject=openSUSE%3A11.1&p=1&q=dvb dvb - Tools for Digital (DVB) TV Cards Version: 1.1.0_CVS20080331-1.48 This package contains tools to be used with the driver for DVB cards. You can find further information in /usr/share/doc/packages/dvb/README.SuSE. *** 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
Content-ID:
Tengo una curiosidad, y es la del encabezado. Esto es debido a que estaba realizando un DVD y le pedí a DVDStyler que le pusiera la corrección de error por redundancia, dado que sobro espacio en lo que había realizado. Como este trabajo tarda un poco me fui y al volver me encuentro que la máquina se había apagado, pensé que había terminado y como no la use se apago, que sería lo lógico. Pero al encenderla nuevamente me encuentro que no termino el trabajo y continúo con él. Si esta trabajando y unos de los procesadores esta al 100% aunque los otros solo al 10% ¿no tendría que apagarse cuando se termine lo que esta haciendo?. Además el disco rígido esta trabajando también dado que no tengo tanta memoria en la PC como para cargar el contenido de un DVD y sus temporales.
La suspensión automática se activa por inactividad del usuario, no del sistema. Y no existe un sistema para no entrar en hibernación si la cpu está muy ocupada, o hay conexiones de red, nada: si no mueves el ratón o no tecleas en cierto tiempo, se duerme. Si todo va bien, al despertar debería retomar el mismo punto en que estuviera; pero el proceso de quemado se habría inutilizado, me temo - y si no es así, me quedaría muy sorprendido. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoUIF0ACgkQtTMYHG2NR9X8xgCfeTrtxzZq24msDtFLcjyCYLDI rGEAn3Htpg/CYf8XilNY9cixV9X6g0Bb =RYPn -----END PGP SIGNATURE-----
participants (6)
-
Alfredo J. Delaiti -
Camaleón -
Carlos E. R. -
Carlos E. R. -
Juan Erbes -
Lluis