Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Dec 2013 20:51:07 +0000
From: Raphael Cohn <>
Subject: Re: _PATH_LASTLOG

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
+44 7590 675 756

UK Office:
Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United
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

On 3 December 2013 20:44, Laurent Bercot <> 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

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.