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

[Christian Theune]

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 


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  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 > >> 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 
>>> 

Re: [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  > 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
> > .
> >
> > IMHO, configuring Apache is annoying and not easy to get right, so I
> > would love to have an enableCompression flag. Data point: 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.
> >
> > 

[Nix-dev] Byobu session-selector broken, referencing /usr/bin/pythong

[Yasu]

Hi,

I'm a newbie nixos user and trying byobu version 5.87.

I noticed that if I open a byobu session (using tmux as the backend, the 
default configuration) , abruptly disconnect the SSH session, log back in and 
type tmux again, I get the following error.

/home/yasu/.nix-profile/bin/byobu-select-session: 
/nix/store/0xcd1mkrjzpc2d215q8bi20zral1c05n-byobu-5.87/lib/byobu/include/select-session.py:
 /usr/bin/python: bad interpreter: No such file or directory

What shoud I do to fix this?

Reards,
Yasu
Tokyo



___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Byobu session-selector broken, referencing /usr/bin/pythong

[Eric Sagnes]

Hi,

Static executables paths in scripts have to be fixed in nix.

Fortunately, there is an easy way to do it by using the substituteInPlace[1] 
helper
during the fixup phase[2].

issue: https://github.com/NixOS/nixpkgs/issues/9865
PR:https://github.com/NixOS/nixpkgs/pull/9866

Cheers,

[1] http://nixos.org/nixpkgs/manual/#ssec-stdenv-functions
[2] http://nixos.org/nixpkgs/manual/#ssec-fixup-phase

On Tue, Sep 15, 2015 at 08:56:28AM +0900, Yasu wrote:
> Hi,
> 
> I'm a newbie nixos user and trying byobu version 5.87.
> 
> I noticed that if I open a byobu session (using tmux as the backend, the 
> default configuration) , abruptly disconnect the SSH session, log back in and 
> type tmux again, I get the following error.
> 
> /home/yasu/.nix-profile/bin/byobu-select-session: 
> /nix/store/0xcd1mkrjzpc2d215q8bi20zral1c05n-byobu-5.87/lib/byobu/include/select-session.py:
>  /usr/bin/python: bad interpreter: No such file or directory
> 
> What shoud I do to fix this?
> 
> Reards,
> Yasu
> Tokyo
> 
> 
> 

> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev


-- 
Eric Sagnes
サニエ エリック
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [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  > 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
> > .
> >
> > IMHO, configuring Apache is annoying and not easy to get right, so I
> > would love to have an enableCompression flag. Data point: 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.
> >
> > 

Re: [Nix-dev] Pkgs with unstable links

[Thomas Strobel]

time :)

On 09/12/2015 01:00 PM, Domen Kožar wrote:
> I've opened an issue two years ago on
> nixpkgs: https://github.com/NixOS/nixpkgs/issues/970
>
> Those packages should be mirrored to tarballs.nixos.org
> .
>
> What's missing for that to happen?
>
> On Sat, Sep 12, 2015 at 11:27 AM, Thomas Strobel  > wrote:
>
>
> On 09/12/2015 12:42 AM, Peter Simons wrote:
> > Hi,
> >
> >  > I would like to ask if we can create repo on github
> (nixos/foobar)
> >  > and upload there such pkgs? Or even are there some free
> fileservers
> >  > where we can store such things? That's a pretty tedious
> problem and
> >  > indeed we need to solve it.
> >
> > And while we're at it, we should also mirror all of rPackages
> somewhere,
> > because these people frequently modify their release archives
> in-place,
> > breaking hundreds of our builds in the process. :-(
> >
> > Peter
>
> I'm looking into ways how to extend the mirroring that is already done
> at tarballs.nixos.org . The plan is to
> mirror everything that any nixpkgs
> package references. Maybe that solves those problems as well. In the
> long run I could imagine to place the mirrored files into something
> like, e.g., IPFS (nixos.go14Packages.ipfs). As far as I know IPFS
> might
> get a S3 back-end with its next release, so maybe the nix cache
> could be
> provided over IPFS as well. Just sharing my thoughts here...
>
> Thomas
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl 
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] ati_unfree drivers, HD 5650 mobility radeon - slow font rendering ?

[Vladimír Čunát]

On 09/13/2015 04:14 PM, Marc Weber wrote:
> After some time (maybe 10min up to 2 hours) font rendering gets that
> slow that a vim instance (gvim/vim/xterm/emacs) takes about 3 seconds
> to render the fonts. I've not found a solution yet.
> 
> Does anybody have an idea what could try?

I would think the combination of catalyst and kernel versions has most
impact on such problems. Catalyst in particular isn't often updated in
nixpkgs, last time in 1d3207b27b.

Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev