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

[Thomas Strobel]

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>> 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
>     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>.
>     >
>     > 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> 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>
>     > 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
> 
> 
> 
> 
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>