berenger.morel@neutralite.org wrote: > >Wow. 1-4 times a day? > Usually: > 1: when I am moving from train to work > 2: when I am leaving work to train > 3: when I am moving from train to home > 4: when I am leaving computer for bed > :) Ah, I see. It isn't because the machine is unstable or needs it but simply as a natural progression of Real Life. > >Why is it necessary to reboot? I would like to understand this use > >case better. > > I am using testing/unstable/experimental + external tools, and have > some troubles with few actions, which I did not had enough time to > try to solve. Some of those problems are related to hibernate, an > example is a freeze when I change wifi state will booting from an > hibernation, I have seen various wifi drivers not be happy across a suspend/hibernate resume. I have needed to unload them on the way down and reload them on the way up. Or unload and reload them after the resume. > and another one is that sometimes, pm-hibernate just > does nothing. I have never been completely happy with the pm tools. They just have not been as reliable and didn't support as much hardware. It works for me now that I have ThinkPads and so I use it. But previously when I had HP/Compaq laptops it didn't work and I needed to patch into the kernel the suspend2 now known as TuxOnIce system by Nigel Cunningham. That always worked flawlessly and very fast. I wish that code had been gated into the kernel. It always worked better for me. > For first example, I know how to reproduce, but lacks > time to fix it, for the latest, I have no clue about when and why it > happens. It is a black box and some things are not observable without considerable effort. > Hardware/kernel/driver things are still mysterious for me. > I also have some troubles because of mechanical/electrical problems > inside of my computer, which also makes safer for my data to > shutdown. Have you tried suspend to ram? I pretty much only ever suspend to ram. Because my Thinkpad will stay suspended to ram for about seven days without charging and I never leave it unused for that long. So I never use hibernate to disk these days. The other thing is that I have a fully encrypted disk. If I suspend to ram then I don't need to descript the disk, just my screen locker. If I hibernate to disk and power off then I must enter my disk encryption key. That is much longer. > Another reason is that it's "harder" to hibernate than to shutdown: > I have no DE, I don't run a DE either. I realize that many people grab the mouse for everything but I am not one of them. (So as not to mislead people I do usually run X11 with either fvwm or awesome for my window manager. But that is as far as it goes.) > and I do not really like the idea behind using daemons > to do things as simple as controlling the power management. I would need to dig to see what is actually doing it but I did not install any daemon in particular (I am running tpb think pad buttons) but the Fn+sleep button works for me after an installation without doing anything special to enable it. I assume it is simply triggering a suspend through the /proc/acpi/sleep and so is probably an acpi function. I do have acpid installed and it is probably involved. I don't consider that too heavy of a daemon process. But you could always write a shell script to trigger sleep by echo'ing into /proc/acpi/sleep and then wiring it to whatever you wished. > I do not like too to have a constant root console opened. Suggestion: Add yourself to the sudo group and then simply use 'sudo whatever' to sleep. For sleeping I would add the NOPASSWD to sudo for that command. It is your machine in your physical possession. Allowing it to sleep without a password seems reasonable to me. > And what make things easier is that using the power switch of my > computer is actually faster than using > "su\n<password>\npm-hibernate\n" I just hit the sleep button and it works. Same thing. Different button. There is also a hibernate to disk button. It works for me. But I almost never use it. > That's things I could fix, by example by understanding how acpi can > be configured, but I did not had enough time for that for now. > I really would like to understand how to configure acpi, since some > of keys on my eeepc are just doing nothing. I suggest trying acpid and seeing what it gives you without customization. You might be pleasantly surprised. Works for me without doing any customization. > There is those problems, but I also have a strong (wrong) habit to > use #poweroff instead of #pm-hibernate. Well... another thing is > that's actually easier to write poweroff :D Next time try pm-suspend. If it works then you might become a convert over to it. :-) > This habit is not so bad, since my computer's boot speed is really > small. Less than a minute to have it fully working... It is about 30 seconds for me on an Atom machine like your Eee Pc Atom. > I am also thinking to configure my computer to make it "modal" (with > runlevels): I do not always have the use for all stuff which is > loaded in default situation, and selecting the mode at boot is > easier than using a root access to change runlevel when things are > running. Sure. That is what runlevels are there for. I don't think it would be easier for me. Press TAB at the grub boot screen and then edit the much more complex grub2 config. (Grub1 was much simpler.) But conceptually starting into different modes is exactly what runlevels were designed to do. > By example, I have no use for ssh when I am not at home or at work, > since I do not have access to more than one computer in those > situations. But it doesn't hurt to let it run. Might speed a second off the boot time. If the ram is needed and it isn't being used it will be pushed into swap space and so won't be a memory issue. Since you need enough memory to run it on the times that you run it there isn't any downside. > At work and in train, I do not need the wifi, Do you have a hardware switch? I simply switch it off to save battery power of having the radio off. > and I am using different networks settings in different buildings > (wpa-ssid and keys) and so I could use runlevels to change > parameters. Runlevels could be a convenient way to manage that, but > they can be changed by root or at boot. Root is not a convenient > way, from an ease of use point of view. (Currently, I am starting > things at hand when I need them...) $ sudo telinit 3 But I would rather write a script that shuts down processes I don't need and starts up others that I do need. I have actually done this. #!/bin/sh killall irssi sudo service openvpn stop sudo service bind9 stop sudo service ntp stop sudo service postfix stop ... And the reverse to bring them back online later. I personally would prefer the scripted approach with suspend-to-ram over the runlevel approach. > And about the portability problem, I did not thought about it > immediately, but IIRC I mentioned the fact that there could be > scripts not working perfectly in a first time, did not I? But it is the other way around. Bash is more permissive and has more features. So for someone switching from dash to bash they won't see any problem. It is the reverse of switching from bash to dash that removes features where they might see a problem. One of the original purposes for dash was that it was strictly POSIX. So the theory went that if you developed on it then it would work on any other POSIX compatible shell. It has always been easier to develop on a more strict system and then port to the more slack one than the other way around. > You are true, little slow down are not a problem, and even less > nowadays when people sounds like to love to use bloatwares and big > DE. > I should have said immediate consequence, because I was really > meaning the first difference noticeable. Because I have some data now I wanted to drift back to the original topic for a moment. I tried the experiment of timing the boot time differences between bash and dash. I used an Atom D525 for this purpose. It takes 5 seconds for the BIOS to continue to the boot loader. Grub is configured for a 5 second delay to give me time to interact with it. I could remove that delay but I like having the ability to interact with it. It took 19 seconds for the system to boot to a login prompt. That is 29 seconds total from power up to login prompt. I did this three times with the same result each time. I timed this with a stopwatch and my thumb. I switched the symlink from dash to bash and rebooted. Same thing. It took 19 seconds for the operating system from boot to login prompt. For the same total time of 29 seconds from power up to login prompt. There may be a performance difference but I couldn't measure it with my thumb and a stopwatch. This is a Squeeze 6.0.6 system with a spinning hard drive. It would be faster with an SSD. Those times are relatively short. But there were measured on slow but modern hardware. For a real test I dropped back to an old Pentium II Coppermine 866MHz 256M ram machine. Make no mistake this is a very slow machine by modern standards! It took 11 seconds for the BIOS plus 5 seconds for the grub delay and then with dash took 97 seconds to boot to the login prompt for a total of 113 seconds total. Now we should see some real differences. I switched it to bash and it took 98 seconds to get to the login prompt. So same thing. That is within the measurement error of my thumb. There might be a performance difference but I couldn't measure it with my thumb. I also tried a VM but that isn't really fair since it is on a faster host. But in any case the VM booted from the end of the grub delay screen to login prompt in 12 seconds. Same thing with either shell. Just no difference to measure. When I read this thread it sounds like I am much too picky. Sorry. I just believe that sharing knowledge and communicating is good. I have written much here because I have enjoyed the conversation so much. I hope you read it in the spirit it is intended and enjoy it too. Bob
Attachment:
signature.asc
Description: Digital signature