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
:)
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, and
another one is that sometimes, pm-hibernate just does nothing. 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.
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.
Another reason is that it's "harder" to hibernate than to shutdown:
I have no DE, and I do not really like the idea behind using daemons to
do things as simple as controlling the power management.
I do not like too to have a constant root console opened.
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"
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.
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
This habit is not so bad, since my computer's boot speed is really
small. Less than a minute to have it fully working...
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.
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.
At work and in train, I do not need the wifi, 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...)
And that is because they are not old computers. I have a dinosaur
which takes ages, hibernate or not, and seeing how the hardware is
old, I prefer the regular checks made on disk by boot process.
I do not need computer as fast as light, but I'm pleased hen things
does not takes ages while keeping some security checks.
I am still using a Pentium 133MHz machine with 112M ram and a 1G hard
drive. It has the best power envelope for the task it is doing. I
reboot it every time a new linux kernel security upgrade is
installed.
It is a pretty slow machine and takes a minute or two to reboot. I
feel the reboot speed every time I reboot it. But that only happens
every other month or so when Linux upgrades are released.
That's because I kept the use of shutdown instead of hibernate,
except if I have something I want to keep alive from a session to
another.
But, of course, if boot speed is not an issue for you, you are free
to make it slower :)
I will say that turnabout this-for-that applies here. :-) It is your
choice to shutdown your eee pc completely. Instead you could suspend
it and have fast resume performance. It is your choice to use a full
shutdown and have slow performance. :-)
Every user have his own requirement for a computer, especially for
people using a linux distribution I think.
I definitely believe that there is never one size fits all. I try to
support people doing a variety of things that I would never
personally
do. But that does not mean that simply because someone can do
something that it is a good thing to do it.
I too. But I also know that I have got some wrong uses, and that I
should forget them :D
But let's not get too from from the topic point under discussion.
The
point I was refuting was this one:
> berenger.mo...@neutralite.org wrote:
> > The immediate problem to change the symlink to bash instead of
dash
> > is that it will slow down his system boot sequence, ...
I strongly believe that it is not an "immediate problem".
Classifying
it as a problem is much too strong. That is where I objected. Yes
there is a measurable difference in boot speed. But it isn't more
than a few seconds. (I would love it if someone would remind us of
the boot timings with a reference to benchmark data.)
But I disagree that changing a symlink from dash to bash causes an
"immediate problem". Nor even a minor problem. It is the way Debian
systems were released and shipped for years and years. The change is
an improvement. But the reversion of that change is not a bug.
The biggest improvement in my mind is not even the performance
difference. It is the portability gained. By writing scripts
suitable for POSIX /bin/sh those scripts are much more likely to run
unchanged on every system and not just the one it is written on.
Having worked on many systems over many years I value clean
portability more than performance.
Bob
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.
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?
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1c43595ea563afdaf093795442c1c...@neutralite.org