On Tue, Jan 1, 2013 at 2:24 AM, Maxim Kammerer <m...@dee.su> wrote:
> On Tue, Jan 1, 2013 at 10:49 AM, Doug Goldstein <car...@gentoo.org> wrote:
>> You realize that files are cached in RAM right?
>
> Yes, I know how operating systems work.
>
>> More than likely those pages are always in cache.
>
> Did you read my reply at all? You are assuming ideal conditions
> (enough free RAM), for a specific kind of desktop (low seek time for
> root filesystem is one assumption), where the solution you are relying
> upon is a generic one, and will fail under high load. I prefer
> removing potential problems instead of relying on optimal behavior and
> having to figure what went wrong down the road.

There are tons of built-in assumptions regarding system state on this
thread. I believe the argument being offered is that for the vast
majority of desktop users, the default upstream approach of flatfiles
serves the common use case fine. If you think the majority of desktop
users are using more than one machine, or NIS+ or anything
complicated, then we already disagree on the base case ;)

>
>> The time required to parse
>> the average GNOME single user desktop machine (I've got 44 users and
>> 69 groups on that box) is likely smaller than the overhead of a DB.
>
> No, since the DB can have frequent pages locked into memory. Should I
> also ask: “you realize that not all DBs are MySQL and Oracle, right”?
>
> I think this branch of discussion became pretty off-topic, so I
> suggest stopping it. I just wanted people to know about the optional
> glibc database functionality, which is a nice alternative for those of
> us that are used to nscd with NIS+, and which doesn't work at the
> moment (so maybe someone feels like figuring it out on the glibc bug
> opened by vapier). I certainly have no desire to read condescending
> replies. If I wanted a flamewar, I would have probably mentioned that
> glibc uses /var/db for the database, which is not FHS-compliant.

There are a ton of nss modules users can enable if they so choose.

>
> --
> Maxim Kammerer
> Liberté Linux: http://dee.su/liberte
>

Reply via email to