[Nix-dev] I want nice things (apache compression)

Mon Sep 14 12:44:50 CEST 2015

Hi,

this is also one of the big issues I’ve been trying to get my head around. One of the wiki pages mentions a great thing that I’m interested in:
https://nixos.org/wiki/The_Many_Cooks_Method <https://nixos.org/wiki/The_Many_Cooks_Method>

This touches managing multiple channels and their interdependencies cleanly, which I haven’t figured out yet and which isn’t documented in detail.

We’re preparing to run NixOS on our platform which will require figuring out how to manage upstream modules, our modules (and providing them to upstream for consideration) as well as customer-specific configuration.

Thinking about this and experimenting with current options is my main topic for the upcoming Sprint in Halle, but I’d absolutely love input from others who are more experienced than me. :)

Christian

> On 14 Sep 2015, at 11:31, Thomas Strobel <ts468 at cam.ac.uk> wrote:
> 
> It always somehow hurts me when contributions to NixOS are refused or
> just left abandoned somewhere in the mailing list or on github. The
> great power of NixOS is that it can be fully programmed and so NixOS
> should be able to handle almost all contributions by design. While one
> has to write blog posts or wiki articles when trying to share knowledge
> about how to set up software systems on other Linux distributions, for
> NixOS one can write a module that contains all that information in
> potentially one option flag. I don't see anything like that in any other
> Linux distribution or any other Linux software management system, and I
> could imagine that it will help the NixOS user base to grow rapidly.
> 
> But maybe we could improve the way how to organize all the contributions.
> 
> What I would like to discuss is whether it makes sense to divide the
> whole set of modules into a NixOS core set that only contains essential
> modules like, e.g. network and hardware management as well as user and
> service management modules, and into a NixOS lib (nixlib) set that
> contains modules for the actual services. Furthermore, one could maybe
> subdivide nixlib into a stable, testing and unstable section where
> modules are grouped according to their maturity and their generality. So
> for example, a general Nginx configuration that defines the systemd
> service and exposes hooks into the Nginx configuration file would go
> into the stable section, and a more specific module like, e.g., to use
> Nginx as reverse proxy could start in unstable and then move up if there
> is enough interest.
> 
> The advantage could be to have a central repository where modules are
> collected and to maybe take load off the core developers at the same
> time. They are doing an amazing job in growing and improving NixOS, but
> it's probably asking for too much when wanting them to discuss all
> their decisions.
> 
> Maybe it would help if the most demanded developers were only
> responsible for managing NixOS core and for maybe guiding the
> development of nixlib?
> 
> For nixlib unstable I think nothing replaces the willingness of an
> author to take on responsibility for the changes and to just merge the
> contributions. Personally, I'd rather prefer a good portion of broken
> and rapidly changing modules in unstable over a constantly growing
> number of open pull requests. I find it almost always easier to have a
> broken module that I can adapt then having to start from scratch.
> 
> Maybe that's something worth trying once the new release is out? What
> do you think?
> 
> 
> Thomas
> 
> 
> On 09/12/2015 12:53 PM, Domen Kožar wrote:
>> Reverting controversial commits is how we've been dealing with such
>> disagreements and you're encouraged to open a PR for discussion.
>> 
>> I think there should be a line where options are too specific based on
>> particular usage.
>> 
>> That said, NixOS has the unique opportunity to take a big step forward
>> providing sane defaults while giving a simple flag switch to, for
>> example, best TLS configuration settings.
>> 
>> The main problem going that path is, there will be a lot of bikeshedding
>> as these configuration options are never perfect (again, due to
>> different applications).
>> 
>> I think there are good arguments on both sides and we have to figure out
>> which policy works best for everyone.
>> 
>> Given the flexability NixOS modules provide, it should be possible to
>> separate basic settings from advanced usage.
>> 
>> PS: Similar change for nginx: https://github.com/NixOS/nixpkgs/pull/9693
>> 
>> Domen
>> 
>> On Sat, Sep 12, 2015 at 11:39 AM, Joachim Schiele <js at lastlog.de
>> <mailto:js at lastlog.de <mailto:js at lastlog.de>>> wrote:
>> 
>>    compression is really important and i would like to have this as a nix
>>    option as well! but eelco might be right as this should be a per vhost
>>    option but i'm not sure about that.
>> 
>>    +1
>> 
>>    On 12.09.2015 11:05, Wout Mertens wrote:
>>> Hi all,
>>> 
>>> see https://github.com/NixOS/nixpkgs/commit/9d82f7e53e66e5594b0c8b82f6c415a0a386b580 <https://github.com/NixOS/nixpkgs/commit/9d82f7e53e66e5594b0c8b82f6c415a0a386b580>
>>    which
>>> reverts a site-wide optional compression feature I added. The discussion
>>> and lack of answering can be found
>>> at https://github..com/NixOS/nixpkgs/pull/9407#issuecomment-134523359 <https://github..com/NixOS/nixpkgs/pull/9407#issuecomment-134523359>
>>> <https://github.com/NixOS/nixpkgs/pull/9407#issuecomment-134523359 <https://github.com/NixOS/nixpkgs/pull/9407#issuecomment-134523359>>.
>>> 
>>> IMHO, configuring Apache is annoying and not easy to get right, so I
>>> would love to have an enableCompression flag. Data point: nixos.org <http://nixos.org/> <http://nixos.org <http://nixos.org/>>
>>> <http://nixos.org <http://nixos.org/>> doesn't use compression, for no good reason.
>>> 
>>> I'm not happy that the commit got reverted without answering my
>>> question, but that's what happens in a benevolent dictatorship I guess.
>>> 
>>> So I would like to know what would be an acceptable configuration. I'm
>>> guessing:
>>> 
>>>  * Configurable site-wide and per virtualhost
>>>  * Only compress known-compressible files: html, css, json, svg,
>>    txt, md
>>> 
>>> Right?
>>> 
>>> Wout.
>>> 
>>> PS: Alternatively, there could be a sort of plugin system for
>>> configurations which allows implementing this sort of configuration
>>> sugar without going into nixpkgs and with minimal end-user effort to
>>> keep up-to-date. I don't know what such a system would look like.
>>> 
>>> --
>>> 
>>> Wout.
>>> (typed on mobile, excuse terseness)
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> nix-dev mailing list
>>> nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl> <mailto:nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl>>
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev <http://lists.science.uu.nl/mailman/listinfo/nix-dev>
>>> 
>> 
>> 
>>    _______________________________________________
>>    nix-dev mailing list
>>    nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl> <mailto:nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl>>
>>    http://lists.science.uu.nl/mailman/listinfo/nix-dev <http://lists.science.uu.nl/mailman/listinfo/nix-dev>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl>
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev <http://lists.science.uu.nl/mailman/listinfo/nix-dev>
>> 
> 
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl>
> http://lists.science.uu.nl/mailman/listinfo/nix-dev <http://lists.science.uu.nl/mailman/listinfo/nix-dev>
—
Christian Theune · ct at flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150914/7c0c48b7/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150914/7c0c48b7/attachment-0001.bin 