| |||||||||||||
|
| |||||||||||||
Poettering: Rethinking PID 1Poettering: Rethinking PID 1Posted May 7, 2010 7:57 UTC (Fri) by pabs (subscriber, #43278)In reply to: Poettering: Rethinking PID 1 by cmccabe Parent article: Poettering: Rethinking PID 1
It was less of a troll and more of a "surely we can and should be doing better than updatedb in this day and age?".
(Log in to post comments)
Poettering: Rethinking PID 1 Posted May 16, 2010 23:53 UTC (Sun) by cmccabe (subscriber, #60281) [Link]
> It was less of a troll and more of a "surely we can and should be doing
> better than updatedb in this day and age?".
Oh, ok.
I always forget where things are, so I end up using slocate all the time.
It seems like are some tradeoffs here. Having a daemon that listens to inotify makes things slower while you're using the machine. It's more complicated and more likely to lose track of files. The updatedb / slocate scheme probably uses more power in total because it does a treewalk while you're asleep. But it is simple and always works. Of course, information may be slightly out-of-date.
Maybe people who are really concerned about the power issues should do updatedb once a week instead of daily? Would that be an acceptable tradeoff?
I suspect that, like vi/emacs, this debate will not be resolved any time soon.
Poettering: Rethinking PID 1 Posted May 17, 2010 5:51 UTC (Mon) by avik (subscriber, #704) [Link]
updatedb doesn't work while I'm asleep since the machine is configured to fall asleep when I do. Nor does it always work: removable disks won't work; with selinux there may be files accessible to the user but not accessible to root. Multi-user machines are rare these days, but a shared machine might take the updatedb hit just when someone in .au wakes up and connects to it.
In short, it's a static solution that doesn't fit the dynamic environment of the last 15 years.
Poettering: Rethinking PID 1 Posted May 17, 2010 6:31 UTC (Mon) by nix (subscriber, #2304) [Link] files accessible to the user but not accessible to rootThey must be easy to back up, with properties like that.
Poettering: Rethinking PID 1 Posted May 17, 2010 9:57 UTC (Mon) by nye (guest, #51576) [Link]
>>files accessible to the user but not accessible to root
>They must be easy to back up, with properties like that.
Arg. This is how user files work in Windows by default. So annoying. Windows makes a chore out of things that should be so simple.
Anyway the solution is probably to have backups done individually by the user if there is only one and it's the same person as root (ie. yourself), or to have a user whose dedicated role is to be able to read every non-special file for backup purposes, without any of the other permissions root would have which could potentially be dangerous. Then again, you could just run updatedb as that user, so...
Poettering: Rethinking PID 1 Posted May 17, 2010 6:49 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
you are making the exact mistake you are accusing others of, assuming that everyone uses systems like yours.
Poettering: Rethinking PID 1 Posted May 17, 2010 7:56 UTC (Mon) by avik (subscriber, #704) [Link]
I haven't accused anyone of anything. You're confusing me with somebody else.
(nor am I assuming everyone uses systems like mine; it's sufficient that a substantial fraction of users suspend or turn off their machines at night, or use detachable storage, to show that updatedb is outdated)
Poettering: Rethinking PID 1 Posted May 17, 2010 10:25 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
no, that only means it's not appropriate for those users
Poettering: Rethinking PID 1 Posted May 17, 2010 11:04 UTC (Mon) by avik (subscriber, #704) [Link]
That's why a more general solution is proposed.
|
|
||||||||||||