Re: _PATH_LASTLOG

[Raphael Cohn <raphael.cohn@stormmq.com>]

[-- Attachment #1: Type: text/plain, Size: 3529 bytes --]

I've always believed that the filesystem itself should be used as a
packaging system...

This is EXACTLY what I want to do. Each package is its own FHS...

Raphael Cohn
Chief Architect, stormmq
Co-Chair, OASIS MQTT Standard
Secretary, OASIS AMQP Standard
raphael.cohn@stormmq.com
+44 7590 675 756

UK Office:
Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United
Kingdom
Telephone: +44 845 3712 567

Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number
07175657
StormMQ.com


On 3 December 2013 20:44, Laurent Bercot <ska-dietlibc@skarnet.org> wrote:

>
>  One problem I'd like to solve is making a way for users to override
>> the system resolv.conf;
>>
>
>  The s6-dns client library uses the DNSCACHEIP environment variable for
> this: if it contains a list of DNS caches, this list will override the
> /etc/resolv.conf-provided one. (The idea comes from djbdns, but has been
> extended to a full list instead of a single cache address.)
>  Same thing with the DNSQUALIFY environment variable, which can have
> a list of suffixes that overrides resolv.conf. (djbdns had a complex
> rules-rewriting-based qualification mechanism that nobody ever used,
> so the simpler approach was easier and better.)
>
>  Maybe musl could use the same approach: environment variables are a
> reasonable place for hardcoded-path overrides. But it has to be balanced
> against namespace pollution.
>
>
>
>  This seems like a good foundation for a package system. I've looked
>> into Nixos before but never really tried it out, and got the
>> impression that the concept was very good but it might not be the best
>> implementation. So something similar to Nixos sounds interesting. :-)
>>
>
>  I've always believed that the filesystem itself should be used as a
> packaging system: every package should have its own system user and reside
> in its own directory, and /usr/bin and friends should only contain
> symlinks. Native isolation via Unix permissions, atomic package
> replacement,
> easy package management. But for some reason, people seem absolutely
> reluctant to do this.
>
>
>
>  The philosophy used in musl, which is somewhat different from the sort
>> of philosophy you might have when designing a new distribution, is not
>> to invent new policy but to avoid policy and build on existing,
>> already-widely-accepteed policy when it's unavoidable.
>>
>
>  I don't agree with all decisions in musl, but this one I can definitely
> stand for.
>
>
>
>  There are LOTS of ways one could extend hostname lookups, ranging from
>>  NSS modules to
>> hosts.d and resolv.d, but rather than trying to support everything
>> imaginable (result: bloat and serious security considerations) in
>> libc, the musl approach to hostname lookup is that libc contains the
>> basics that are suitable for most/all simple systems, and anything
>> more advances can be provided by an external daemon running on
>> localhost that speaks DNS protocol and provides whatever lookup
>> semantics you desire.
>>
>
>  In the DNS case, the flexible - and best, IMNSHO - approach is to run a
> small local DNS cache on localhost indeed; but the problem is that there's
> an existing codebase that sometimes insists on clobbering /etc/resolv.conf,
> which adds to the packaging burden when your purpose is to create or
> maintain
> a distribution. Having extension mechanisms at the libc level can help in
> that situation.
>
> --
>  Laurent
>
>

[-- Attachment #2: Type: text/html, Size: 4898 bytes --]