Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Danylo Hlynskyi]

I'm interested for this project to succeed, in case it will be NixOS
extension like nixsap[1], and not a fork like triton[2] or microgram[3].
Currently NixOS is very customizable:

- module system
- disabling modules [4]
- nixpkgs overlays

Because of these ways, it is possible to belong to The Church more
granularly (for example, use it's overlay, but not drop systemd) and
leverage NixOS as OS builder library

[1] https://github.com/zalora/nixsap
[2] https://github.com/triton/triton
[3] https://github.com/zalora/microgram
[4] https://github.com/NixOS/nixpkgs/pull/22764


2017-03-23 14:05 GMT+02:00 Jan Malakhovski :

> > However, all major Linux distributions without exceptions enable
> > "moderate" hardening by default for very good reasons, and all of them
> > can run on eeePC without issues.
> >
> > If your aim is not to run NixOS on arduino, or little embedded MIPS or
> > RISC-V machines, it does not matter at all. If you want to run on this
> ... or Intel Atom ...
> > can of machine, you know what you are doing and you know how to tune
> > your code anyway.
>
> At least for Atoms hardening does produce a qualitative difference. I'm
> not sure why. I assume that things that fit into cache without hardening
> stop fitting into it with hardening.
>
> Cheers,
>   Jan
> ___
> 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] The Church of Suckless NixOS is looking for followers

[Jan Malakhovski]

> However, all major Linux distributions without exceptions enable
> "moderate" hardening by default for very good reasons, and all of them
> can run on eeePC without issues.
>
> If your aim is not to run NixOS on arduino, or little embedded MIPS or
> RISC-V machines, it does not matter at all. If you want to run on this
... or Intel Atom ...
> can of machine, you know what you are doing and you know how to tune
> your code anyway.

At least for Atoms hardening does produce a qualitative difference. I'm
not sure why. I assume that things that fit into cache without hardening
stop fitting into it with hardening.

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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Nikolay Amiantov]

On 03/21/2017 08:15 PM, Bjørn Forsman wrote:
> I wonder if it's possible to use "prelink". I think someone mentioned
> it on the ML some years back.
Sadly prelink conflicts with ASLR which is an important security
feature. There is an option to statically randomize addresses but it's
then as good as none because randomization would happen on Hydra (so
everyone binaries will be same)[1].
> - Bjørn
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

1: https://en.wikipedia.org/wiki/Prelink#prelink_randomization

-- 
Nikolay.

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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Wout Mertens]

Yes I tried to convince the ML that prelinking /nix/store is sort of
deterministic, but could not get traction. IIRC there is a decent startup
improvement.

OS X does it well, there the dyld automatically does prelinking on the fly,
storing the metadata elsewhere.

On Tue, Mar 21, 2017, 7:36 PM Vladimír Čunát  wrote:

> On 03/21/2017 06:15 PM, Bjørn Forsman wrote:
> > I wonder if it's possible to use "prelink". I think someone mentioned
> > it on the ML some years back.
>
> I suspect prelink addresses a different part of overhead that isn't
> enlarged in nixpkgs.
>
>
> ___
> 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] The Church of Suckless NixOS is looking for followers

[Vladimír Čunát]

On 03/21/2017 06:15 PM, Bjørn Forsman wrote:
> I wonder if it's possible to use "prelink". I think someone mentioned
> it on the ML some years back.

I suspect prelink addresses a different part of overhead that isn't
enlarged in nixpkgs.




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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Bjørn Forsman]

On 21 March 2017 at 17:39, Adrien Devresse  wrote:
> NixOS, contrary to arch and the other Linux distributions, does not use
> ld cache, and consequently do significantly more "stat()" stress on the
> file system each time it charges an executable with dynamic libraries.

I wonder if it's possible to use "prelink". I think someone mentioned
it on the ML some years back.

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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Adrien Devresse]

Le 21. 03. 17 à 16:56, William Casarin a écrit :
> Eelco Dolstra  writes:
>> On 03/19/2017 12:10 PM, Jan Malakhovski wrote:
>>> For eeePC try disabling hardening. Seriously. 
>> Hm, I wasn't aware hardening has a significant performance impact. Do you 
>> have
>> more info on that?
> I have a feeling in my case the performance issues are due to the fact
> there are simply more IO operations happening, and I was running off an
> SD card D:
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

Yep I wanted to say that too :D

NixOS, contrary to arch and the other Linux distributions, does not use
ld cache, and consequently do significantly more "stat()" stress on the
file system each time it charges an executable with dynamic libraries.

In case of something like a python software, which load hundred shared
objects for its module resolution, and on machine with low-RAM / low-IO
, that can be very significant.


Adev





signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[William Casarin]

Eelco Dolstra  writes:
> On 03/19/2017 12:10 PM, Jan Malakhovski wrote:
>> 
>> For eeePC try disabling hardening. Seriously. 
>
> Hm, I wasn't aware hardening has a significant performance impact. Do you have
> more info on that?

I have a feeling in my case the performance issues are due to the fact
there are simply more IO operations happening, and I was running off an
SD card D:
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Adrien Devresse]

Le 21. 03. 17 à 11:52, Alexey Shmalko a écrit :
> Eelco Dolstra  writes:
>
>> Hi,
>>
>> On 03/19/2017 12:10 PM, Jan Malakhovski wrote:
>>
>>> William Casarin  writes:
>>>
 I tried to run NixOS on my eeepc, it feels a lot more sluggish than when
 I used to run arch on it. I would love to see how this plays out, if
 only to have
 a smaller, lightweight version of NixOS to run on my pi's and eeepc.
>>> For eeePC try disabling hardening. Seriously. 
>> Hm, I wasn't aware hardening has a significant performance impact. Do you 
>> have
>> more info on that?
> Basically, most of hardening is inserting runtime checks into
> application. (e.g., inserting buffer overflow checks.) So it takes some
> additional CPU cycles to check.
>
> Some hardenings also insert additional values on stack (e.g., canaries),
> so application consumes more memory.
>
> I could say, on modern desktop computers the performance penalty is
> neglectable, but there are old hardware (where software is sluggish
> already), embedde devices, and various cases when "performance matters."

That also depend of the kind of hardening :

- _FORTIFY_SOURCE=2 is static and has, we can say, no impact.

- -fstrack-protector-strong has almost not impact on any modern machine
from Raspberry PI to modern laptop

- PIE can have an impact on some specific code ( with performance
critical sections with bad inlining )


However, all major Linux distributions without exceptions enable
"moderate" hardening by default for very good reasons, and all of them
can run on eeePC without issues.

If your aim is not to run NixOS on arduino, or little embedded MIPS or
RISC-V machines, it does not matter at all. If you want to run on this
can of machine, you know what you are doing and you know how to tune
your code anyway.


Regards,
Adev



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Alexey Shmalko]

Eelco Dolstra  writes:

> Hi,
>
> On 03/19/2017 12:10 PM, Jan Malakhovski wrote:
>
>> William Casarin  writes:
>> 
>>> I tried to run NixOS on my eeepc, it feels a lot more sluggish than when
>>> I used to run arch on it. I would love to see how this plays out, if
>>> only to have
>>> a smaller, lightweight version of NixOS to run on my pi's and eeepc.
>> 
>> For eeePC try disabling hardening. Seriously. 
>
> Hm, I wasn't aware hardening has a significant performance impact. Do you have
> more info on that?

Basically, most of hardening is inserting runtime checks into
application. (e.g., inserting buffer overflow checks.) So it takes some
additional CPU cycles to check.

Some hardenings also insert additional values on stack (e.g., canaries),
so application consumes more memory.

I could say, on modern desktop computers the performance penalty is
neglectable, but there are old hardware (where software is sluggish
already), embedde devices, and various cases when "performance matters."


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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Eelco Dolstra]

Hi,

On 03/19/2017 12:10 PM, Jan Malakhovski wrote:

> William Casarin  writes:
> 
>> I tried to run NixOS on my eeepc, it feels a lot more sluggish than when
>> I used to run arch on it. I would love to see how this plays out, if
>> only to have
>> a smaller, lightweight version of NixOS to run on my pi's and eeepc.
> 
> For eeePC try disabling hardening. Seriously. 

Hm, I wasn't aware hardening has a significant performance impact. Do you have
more info on that?

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Profpatsch]

On 17-03-19 05:55pm, Alexander V. Nikolaev wrote:
> I think we can re-use pre-serialised `systemd.services` attrset, using
> it for emitting plain sysvinit scripts, or runit scripts. And may be
> later introduce new intermediate layer here.

Since (say what you want) systemd service attributes
are mostly quite semantic in their function,
the may already be a fine choice of interface,
even for other init systems/supervisors.

Compare how it is possible to map the kernelmodule
arguments to networkd options:
https://github.com/NixOS/nixpkgs/pull/22388/files#diff-c89412e680a245d4d20968580b84f47dR121

-- 
Proudly written in Mutt with Vim on NixOS.
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
May take up to five days to read your message. If it’s urgent, call me.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Jan Malakhovski]

Lluís Batlle i Rossell  writes:

> I didn't read the long post, but based on the title it may be of your
> interest what I wrote years ago: nanonixos.
>
> http://viric.name/cgi-bin/nanonixos/doc/trunk/doc/home.wiki
>
> It's very outdated. Pick nixpkgs commits from those dates to make it work.
>
> It is a cross-built nixos for the Ben Nanonote. There is very little
> amount of code. It worked well enough for me.
>
> That may be way more "suckless" than you may be used to use. :)

Your nanonixos was a part of an early inspiration for that long post :)
(I also cite you directly in some other long post here.)

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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Alexander V. Nikolaev]

On Sat, Mar 18, 2017 at 06:42:37PM +0100, Lukas Epple wrote:

> > - Don't PR our changes to nixos subtree (a waste of time)
> 
> I think this is childish, or even dangerous.
> 

+1

> Instead of wasting your time on a NixOS fork, just build an abstraction
> over *any* init/daemon management system (so atm systemd, openrc, runit,
> sinit, …) and get it into NixOS upstream for great good. Just looking at
> the wonderful abstraction NixOS has already given us, I am sure, that it
> is indeed possible to incorporate two very different approaches to Linx
> distribution architecture into NixOS.

I am ok with systemd myself, but I upvote init abstraction layer here,
and would like to contribute to, if it will be part of main
nixpkgs/nixos.

I think we can re-use pre-serialised `systemd.services` attrset, using
it for emitting plain sysvinit scripts, or runit scripts. And may be
later introduce new intermediate layer here.


With best regards,
Alex.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Lluís Batlle i Rossell]

Hello,

I didn't read the long post, but based on the title it may be of your
interest what I wrote years ago: nanonixos.

http://viric.name/cgi-bin/nanonixos/doc/trunk/doc/home.wiki

It's very outdated. Pick nixpkgs commits from those dates to make it work.

It is a cross-built nixos for the Ben Nanonote. There is very little
amount of code. It worked well enough for me.

That may be way more "suckless" than you may be used to use. :)

Regards,
Lluís.

On Fri, Mar 17, 2017 at 02:00:00PM +, Jan Malakhovski wrote:
> 
> Brothers and Sisters!
> 
> I think I reached the point of no-return w.r.t. not being able to
> tolerate systemd on my machines any longer after systemd devs dropped
> utmp. I don't want to replace finely matured portable UNIX utils
> produced by The Old Gods for the sake of making a bunch of crazy people
> into The New Gods. And, as it turns out, I'm not alone.
> 
> And so we (I and a couple of anonymous friends) are pleased to announce
> the establishment of The Church of Suckless NixOS ("SLNOS" for short).
> 
> * Our common goal is to have fun (see below) and to get a NixOS system
>   that can run using only suckless tools [1].
> 
> * Some of us want to drop GRUB in favor of running on top of minimal
>   Xen payload on Coreboot firmware and isolate everything like in
>   QubesOS, but we are not united on that point at this point. (Yes, we
>   are aware of Heads:ROM, thank you, we are discussing all of this.)
> 
> * We like LISP, but we don't think package expressions should be written
>   in LISP just for the sake of LISP. Nor do we like the bloated GNU
>   tools. GuixSD is out of question.
> 
> For now we have a couple of proposals for the general NixOS community.
> 
> # The Systemd part
> 
> In short, we propose:
> 
> (1) to reimplement full dependency tracking in nix (should replace
> `strings-with-deps.nix`) with `toposort`,
> 
> (2) return the old `system.jobs` under another name (for backwards
> compatibility), but with most of that `system.systemd` now provides,
> 
> (3) reimplement all the services we use with "system.jobs",
> 
> (4) implement
> 
> 
> {
>   # use OpenRC instead of systemd
>   system.initd = "openrc";
> }
> 
> 
> and
> 
> 
> {
>   # toposort `system.jobs` and render static
>   # init script for suckless.org initd
>   # (a page of nix code and a page of C code
>   # instead of systemd, yay!)
>   system.initd = "static";
> }
> 
> 
> The (1) can then be used to get dependency tracking in `initrd` for free
> too.
> 
> As we see it, implementing the infrastructure (1)-(2) is a couple of
> days of work, but reimplementing services (3) will need lots of effort
> for very systemd specific, highly cgrouped and socket-activated
> services, and (4) requires writing an alternative activation script.
> 
> SLNOS will reimplement that for the services we use whenever you like it
> or not (in fact, we already implemented a part of (1) because we wanted
> encryption on networking `fileSystems` (LUKS over nbd) in initrd, but
> never even proposed those changes to upstream because merging simple
> `toposort` for `fileSystems` took a year).
> 
> But we want to know how many people here are like-minded and would like
> to join our SLNOS effort.
> 
> The following template answers were proposed by our current members for
> your convenience:
> 
> * Poettering is my New God! PulseAudio! Avahi! Systemd! PulseAudio!
>   Avahi! Systemd! DBus for the Kernel! utmp is for old people! All
>   computers are laptops! All initds should include Udev, DBus, and do
>   DHCP and DNS-resolver, this is what initds are for! Merging this
>   upstream would be blasphemy! Burn it! Burn it with fire!
> 
> * I don't care, but am willing to break UNIX-like part of GNU/Linux for
>   posterity. [2]
> 
> If one of these templates covers your feelings you can reply-to-only-me
> not to spam the list.
> 
> If there are enough interested people we will organize a public SLNOS
> repo thing as soon as we produce something substantial that can be read
> by other people.
> 
> General thoughts and pointers to anything in current or nearly-current
> NixOS that might become a general snag for this effort are very welcome.
> 
> If you have an idea for a simpler solution to the no-systemd problem you
> are very welcome too.
> 
> Bikeshedding of "`toposort` is too slow, not gonna work" and
> "toposorting should be done at runtime" kinds are not welcome. Just go
> and measure first. And it should not. Works fine for us. If it's slow on
> your graphs, then just implement builtin `toposort` into nix.
> 
> # The Nix part
> 
> Or even better: generalize closure generation by splitting it into
> `toposort` and `depends-on` relation on paths, expose both via builtins,
> reimplement closure generation in lib.
> 
> Then proceed to implementing half of `nix-store` commands on top of that
> infrastructure instead, which would allow to customize `nix-store` with
> nix code. For instance, want to GC as usual, but 

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Bjørn Forsman]

On 19 March 2017 at 12:00, Jan Malakhovski  wrote:
> [...] we want smaller Linux
> systems for routers, RPis and BBones.

+1.

Also +1 to many of the other goals you listed earlier. I'll be sad if
most of the features you plan to work on does not eventually get
merged to NixOS. I think NixOS/nixpkgs should be very configurable
(different libcs, init managers), even though the main build server
(hydra.nixos.org) would have to build only a subset, like
glibc+systemd.

Best regards,
Bjørn Forsman
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Jan Malakhovski]

William Casarin  writes:

> I tried to run NixOS on my eeepc, it feels a lot more sluggish than when
> I used to run arch on it. I would love to see how this plays out, if
> only to have
> a smaller, lightweight version of NixOS to run on my pi's and eeepc.

For eeePC try disabling hardening. Seriously. You'll have to patch
gcc-wrapper by hand ATM and then rebuild for a while (hope you have
something other than eeePC and RPi for that), but it should be less
sluggish with hardening disabled.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Jan Malakhovski]

Tuomas Tynkkynen  writes:

> How is moving away from glibc going to help with (say) FreeBSD
> support? Based on (admittedly quite short) googling, I couldn't

It wouldn't help much. But moving away from systemd would.

> find any libc that supports both Linux and FreeBSD except...
> *drumroll*... glibc that is being used by Debian/kFreeBSD!

FreeBSD has their own libc too, which is used by every other FreeBSD
distro except Debian.

Anyway, currently we don't aim to support *BSD, we want smaller Linux
systems for routers, RPis and BBones.

> And if you're going to be using different libcs on different
> kernels, well... nixpkgs already does that today, by supporting
> Darwin.

But does nixpkgs support different libcs on the same kernel?

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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[William Casarin]

On Sat, Mar 18, 2017 at 5:00 PM, Jan Malakhovski  wrote:
> Adrien Devresse  writes:
>>
>> Just for the troll : Do you also plan to redo also Nix entirely in C,
>> like everything else, just for fun ?
>
> [..]
>
> Meanwhile, 22Mb glibc and 19Mb systemd (disregarding some major crazy
> design decisions there even, did you try to read the source?) are a huge
> drag for a system that, when build using other tools, normally fits into
> 16Mb of flash.

I tried to run NixOS on my eeepc, it feels a lot more sluggish than when
I used to run arch on it. I would love to see how this plays out, if
only to have
a smaller, lightweight version of NixOS to run on my pi's and eeepc.

The extra security stuff sounds cool but is a bit of a specific use
case. I would
probably just run tails/qubes if I cared about that. Otherwise looks cool!

Cheers,

-- 
William Casarin
PGP 0x6D3E2004415AF4A3
https://jb55.com
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Matthias Beyer]

On 19-03-2017 08:01:39, Wout Mertens wrote:
> * Agreed that we should make github issues available in another 
> format for
> posterity. Perhaps just copy the text of merged PRs into /docs? (with some
> tool)

I'll leave this here as a side-note:

I'm working on a tool which would make this possible [0].

It is a git-based issue tracker, the proof of concept worked fine for 
us (a small team of two students developing this in our semesters 
project last semester) - currently we're re-writing it to be more 
stable and usable.

Crawling github issues and pushing them into the repo is one of our 
goals. We're not there yet, but we'll get there eventually.

For more information, see "doc" or open an issue, please. Don't want 
to hijack this thread.

[0]: https://github.com/neithernut/git-dit/

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Consider switching to free software.
It adds value to your life.
https://www.gnu.org/


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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Wout Mertens]

My $0.02:

* The bikeshedding in NixOS is indeed terrible; in nixpkgs a bit less

* It is hard to abstract over systemd, it has a huge scope. Simply using
runit means also adding a bunch of other services. This impacts all of
NixOS but nothing in nixpkgs.

* Agreed that we should make github issues available in another format for
posterity. Perhaps just copy the text of merged PRs into /docs? (with some
tool)

* I think you can achieve your fork as a nixpkgs layer. Would be nice to
have some tooling around that so many things would be separate layers.

So, I wish you luck, and I hope that you implement your fork in a way that
we can all benefit and cooperate in nixpkgs.

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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Tuomas Tynkkynen]

2017-03-18 18:46 GMT+02:00 Jan Malakhovski :
> Mayeu  writes:
>
>> I would love to see that in upstream, independence from systemd will open 
>> the door to have some kind of NixBSD and other fun stuff like that. (No 
>> longer than 3 days ago there was a discussion for GSOC to have a project to 
>> make NixOS + freebsd).
>
> Note that NixOS FreeBSD/NetBSD is just SLNOS with a different kernel,
> because we are gonna to be free from glibc and GNU tools.
>

How is moving away from glibc going to help with (say) FreeBSD
support? Based on (admittedly quite short) googling, I couldn't
find any libc that supports both Linux and FreeBSD except...
*drumroll*... glibc that is being used by Debian/kFreeBSD!
And if you're going to be using different libcs on different
kernels, well... nixpkgs already does that today, by supporting
Darwin.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Jan Malakhovski]

Lukas Epple  writes:

> On Sat, Mar 18, 2017 at 11:20:00AM +, Jan Malakhovski wrote:
>> - Don't PR our changes to nixos subtree (a waste of time)
>
> I think this is childish, or even dangerous.
>
> What I see in this, is the following: A lot of “we know things better
> and nobody can appreciate or realize that”. You got to recognize though,
> that, if you actually know thing better, chances are, that you are wrong.
> Most likely you are just not communicating properly to others.
>
> Instead of wasting your time on a NixOS fork, just build an abstraction
> over *any* init/daemon management system (so atm systemd, openrc, runit,
> sinit, …) and get it into NixOS upstream for great good. Just looking at
> the wonderful abstraction NixOS has already given us, I am sure, that it
> is indeed possible to incorporate two very different approaches to Linx
> distribution architecture into NixOS.

Firstly, most of us have already maintained our own NixOS forks for
years, essentially. Oldest commit in my branch that was rejected by
NixOS but is still in use recently celebrated its third birthday.

Then we exchanged our patches for a while. And now our group got tired
of duplicating all that work and decided to cleanup and merge our forks
together and then just implement all the things we wanted, but
self-censored ourselves for various reasons ("won't get merged anyway,
why bother", "will publishing this get me on a list of bad children?").

Secondly, I think the problem with NixOS is that there's no explicit
goal and no (or not enough) actual maintainers that push towards that
goal. If the implicit goal is to freeze everything as is, then the fork
with other goals is due. But if the goal is to have a general
declaratively configurable privacy-respecting secure by default UNIX
system that targets different use cases and hardware, then something is
broken in the current system.

Because most changes that are too far from "leave it as is" approach get
bikeshedded, rejected and then, sometimes, reintroduced piece-by-piece
(with inferior implementations, usually) several years later when core
developers with direct commit access finally get the same itch. Just
read some old unmerged PRs yourself. I wanted a nice netboot three years
ago. Sorry, too complicated, initrd must not have any networking. Two
and a half years later we now have `initrd.network`, sshd in initrd, and
netboot installer profile that gets patched towards my old general
declarative thing a little by little (currently at ~30%). Monoidal
services? Nope, too complicated for hypothetical grandmas. Any other way
to get multi-instance services? Nope. Use flags? Bikeshedding x 3, lets
just leave it as is, close. Declarative networking? No interest.
Declarative firewall? Three or four PRs of bikeshedding and no actual
results. Just browse the old PRs and GitHub network graph for nixpkgs.
There's a lot of interesting stuff there that just bitrots. A pity.

As Vladimír Čunát writes above:

> .. and additionally it won't be easy to push it through the
> community(+Eelco) to upstream nixos.

Which is exactly our point. If NixOS reorganizes itself we will
eventually silently dissolve. But I can remember at least two other
attempts at forking that then dissolved after similar feedback and
general hopeful words from core devs. And then business as usual.
Nothing changed.

Anybody else remembers free-nix? I remember because those guys invited
me to be a maintainer, which I formally was for a week, didn't actually
do anything, before it dissolved. Let me cite something from that age

On Tue, 26 Jun 2012 14:54:17 +0200 Lluís Batlle i Rossell  
writes:

> ... That meant for me an amount of work much bigger than a simple svn
> commit, and I decided to stop requesting pulls.
>
> I keep my own fork, and I merge regularly from niksnut's nixpkgs. I've not 
> taken
> a look at free-nix repositories, but I imagine I could sync with them too; my
> "master" of nixpkgs has only commits I'd desire in a public nixpkgs; it's not
> that I abuse it considering it's mine.

We announced here because everyone else announced here, and announcing
elsewhere would be like talking behind NixOS's back.

Our message is simple: We are not happy. We have our goals and we are
willing to do sacrifices for them.

Next time you PR gets rejected remember this, remember us, check out our
agenda and consider contributing.

Cheers,
  Jan and Co
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Jan Malakhovski]

Adrien Devresse  writes:

>> Note that NixOS FreeBSD/NetBSD is just SLNOS with a different kernel,
>> because we are gonna to be free from glibc and GNU tools.
>
> I am sorry in advance for this comment.
>
> But I can only get amused of seeing some GNU, Linux and systemD-haters 
> spitting on C++ and software complexity on their main website 
> (http://suckless.org/sucks/) and on the other side using Nix, the most 
> complex package manager up to date, coded in C++, for their main 
> packaging system.
>
>
> Just for the troll : Do you also plan to redo also Nix entirely in C, 
> like everything else, just for fun ?

Firstly, we have no formal relationship with suckless.org. We like their
tools. But we also like other tools. I can't live without GHC on my
laptop, but it takes like 1.5Gb, but I get a lot of use out of those
1.5Gb. (I would love for it to me smaller, though.)

Meanwhile, 22Mb glibc and 19Mb systemd (disregarding some major crazy
design decisions there even, did you try to read the source?) are a huge
drag for a system that, when build using other tools, normally fits into
16Mb of flash.

Of course we have some strong religious feelings, and we are having fun,
but, in all seriousness, having an option to use saner tools in NixOS
produces more goodies for everyone. Think "NixBSD", "NixWRT" or "NixSensor",
you can't have any of those with systemd and GNU tools, and having a separate
distributions for those is anticlimactic.

Secondly,

$ du -csh $(nix-store -qR 
/nix/store/ci3asdl0my2s85ifi8790lpimk8rm47s-nix-1.11.7) | sort --reverse -h
102Mtotal
47M /nix/store/pbs5sfnp9bfv27vz9m7h64w3zgkavfqd-perl-5.22.2
22M /nix/store/68sa3m89shpfaqq1b9xp5p1360vqhwx6-glibc-2.25
11M /nix/store/5lfwsx1nkrcqp7p24qr8z4wiwfxx5idv-coreutils-8.26
4.7M/nix/store/baidkxp1dsb5varjq06b5jsjf2a33hc1-gcc-5.4.0-lib
3.4M/nix/store/a0lxvniz27b5gn86qnn4n1riwhwfs3q1-openssl-1.0.2k
3.0M/nix/store/ci3asdl0my2s85ifi8790lpimk8rm47s-nix-1.11.7
2.5M/nix/store/gda77bzdgyp6ifd0wvbb95k8kr0vbhvi-gnutar-1.29
1.8M/nix/store/9cd2qfysx5yg5yzb3fc6sslz2k0c07aw-perl-DBI-1.636
1.2M/nix/store/010yd8jls8w4vcnql4zhjbnyp2yay5pl-bash-4.4-p5
1.1M/nix/store/d34xiny1zqd2igm6rflfsc9z0ph5nmrl-sqlite-3.17.0
772K/nix/store/7cnbgg33i3ajvfgnv3iyya17am9qifmw-libatomic_ops-7.4.4
624K/nix/store/lm3c0zxszwj844j48sxmx28lx5x042i0-openssl-1.0.2k-bin
...

Dropping perl from there would be nice (and nix repo seems to move in
that direction anyway), but the rest is exactly our point.

Cheers,
  Jan and Co
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Alexey Shmalko]

Lukas Epple  writes:

> On Sat, Mar 18, 2017 at 11:20:00AM +, Jan Malakhovski wrote:
> Instead of wasting your time on a NixOS fork, just build an abstraction
> over *any* init/daemon management system (so atm systemd, openrc, runit,
> sinit, …) and get it into NixOS upstream for great good. Just looking at
> the wonderful abstraction NixOS has already given us, I am sure, that it
> is indeed possible to incorporate two very different approaches to Linx
> distribution architecture into NixOS.

I, too, would like to see that as an abstraction layer over any init
system, rather than a fork. This is pretty much achievable (Gentoo
supports many intialization systems) and needed (there was a discussion
of the bsd port already).

> PS: Also, if you indeed want to fork NixOS, it seems kinda inappropiate to
> advertise your fork 

Don't agree with that. It is perfectly OK to advertise the fork in the
main nixos channel. Otherwise, how would you receive any feedback or
support?


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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Adrien Devresse]

Note that NixOS FreeBSD/NetBSD is just SLNOS with a different kernel,
because we are gonna to be free from glibc and GNU tools.


I am sorry in advance for this comment.

But I can only get amused of seeing some GNU, Linux and systemD-haters 
spitting on C++ and software complexity on their main website 
(http://suckless.org/sucks/) and on the other side using Nix, the most 
complex package manager up to date, coded in C++, for their main 
packaging system.



Just for the troll : Do you also plan to redo also Nix entirely in C, 
like everything else, just for fun ?



Cheers,

Adev





Le 18/03/17 à 17:46, Jan Malakhovski a écrit :

Mayeu  writes:


I would love to see that in upstream, independence from systemd will open the 
door to have some kind of NixBSD and other fun stuff like that. (No longer than 
3 days ago there was a discussion for GSOC to have a project to make NixOS + 
freebsd).

Note that NixOS FreeBSD/NetBSD is just SLNOS with a different kernel,
because we are gonna to be free from glibc and GNU tools.


And besides, since I am following NixOS I have always heard that one of the 
long-term goal would be to abstract away from systemd.

Apparently not.


* Some of us want to drop GRUB in favor of running on top of minimal
  Xen payload on Coreboot firmware and isolate everything like in
  QubesOS, but we are not united on that point at this point. (Yes, we
  are aware of Heads:ROM, thank you, we are discussing all of this.)

Again, there are regular discussions in multiple space to have some kind of 
Qubes OS + Nix merge (or related) [1][2][3][4]. Note that Qubes uses SaltStack 
[5] to have some kind of declarative VM management. Nix would be a really nice 
improvement over that.

[1] Qubes OS ML: https://groups.google.com/forum/#!topic/qubes-devel/QDM2YNdWdXI 

[2] Harden(ed) NixOS issue reference Qubes multiple time: 
https://github.com/NixOS/nixpkgs/issues/7220 

[3] Package MirageOS for NixOS: https://github.com/NixOS/nixpkgs/issues/23955 

[4] Trying to run NixOS in a Qubes VM: https://github.com/NixOS/nixpkgs/issues/21402 

[5] Qubes OS SaltSack doc: https://www.qubes-os.org/doc/salt/ 


All of that would be awesome for NixOS :)

Yep, but someone needs to do all that work first :)

Cheers,
   Jan
___
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] The Church of Suckless NixOS is looking for followers

[Lukas Epple]

On Sat, Mar 18, 2017 at 11:20:00AM +, Jan Malakhovski wrote:
> - Don't PR our changes to nixos subtree (a waste of time)

I think this is childish, or even dangerous.

What I see in this, is the following: A lot of “we know things better
and nobody can appreciate or realize that”. You got to recognize though,
that, if you actually know thing better, chances are, that you are wrong.
Most likely you are just not communicating properly to others.

Instead of wasting your time on a NixOS fork, just build an abstraction
over *any* init/daemon management system (so atm systemd, openrc, runit,
sinit, …) and get it into NixOS upstream for great good. Just looking at
the wonderful abstraction NixOS has already given us, I am sure, that it
is indeed possible to incorporate two very different approaches to Linx
distribution architecture into NixOS.

Cheers, sternenseemann

PS: Also, if you indeed want to fork NixOS, it seems kinda inappropiate to
advertise your fork here.


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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Jan Malakhovski]

Mayeu  writes:

> I would love to see that in upstream, independence from systemd will open the 
> door to have some kind of NixBSD and other fun stuff like that. (No longer 
> than 3 days ago there was a discussion for GSOC to have a project to make 
> NixOS + freebsd).

Note that NixOS FreeBSD/NetBSD is just SLNOS with a different kernel,
because we are gonna to be free from glibc and GNU tools.

> And besides, since I am following NixOS I have always heard that one of the 
> long-term goal would be to abstract away from systemd.

Apparently not.

>> * Some of us want to drop GRUB in favor of running on top of minimal
>>  Xen payload on Coreboot firmware and isolate everything like in
>>  QubesOS, but we are not united on that point at this point. (Yes, we
>>  are aware of Heads:ROM, thank you, we are discussing all of this.)
>
> Again, there are regular discussions in multiple space to have some kind of 
> Qubes OS + Nix merge (or related) [1][2][3][4]. Note that Qubes uses 
> SaltStack [5] to have some kind of declarative VM management. Nix would be a 
> really nice improvement over that.
>
> [1] Qubes OS ML: 
> https://groups.google.com/forum/#!topic/qubes-devel/QDM2YNdWdXI 
> 
> [2] Harden(ed) NixOS issue reference Qubes multiple time: 
> https://github.com/NixOS/nixpkgs/issues/7220 
> 
> [3] Package MirageOS for NixOS: https://github.com/NixOS/nixpkgs/issues/23955 
> 
> [4] Trying to run NixOS in a Qubes VM: 
> https://github.com/NixOS/nixpkgs/issues/21402 
> 
> [5] Qubes OS SaltSack doc: https://www.qubes-os.org/doc/salt/ 
> 
>
> All of that would be awesome for NixOS :)

Yep, but someone needs to do all that work first :)

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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Jookia]

On Sat, Mar 18, 2017 at 12:56:14PM +0100, Matthias Beyer wrote:
> Never thought about what you wrote there. Thanks for the new 
> perspective!
> 
> -- 
> Mit freundlichen Grüßen,
> Kind regards,
> Matthias Beyer
> 
> Consider switching to free software.
> It adds value to your life.
> https://www.gnu.org/

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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Matthias Beyer]

On 18-03-2017 22:25:18, Jookia wrote:
> On Sat, Mar 18, 2017 at 11:32:18AM +0100, Matthias Beyer wrote:
> > But then you have to think about why these people are doing it.  
> > Clearly because they think they can do something better - which is 
> > fine IMO.
> > 
> > But if a fork is necessary this also means their voices were not heard 
> > when they announced that things are not optimal for them - which means 
> > bad community management. If they did not tell the community what they 
> > dislike, though, I fully agree with you.
> 
> The thing that bothered me a little about your email is the assumption that a
> fork is what happens when there's trouble. I don't think that's always the 
> case,
> and now might be a good example. Without working relationships to hold our
> projects together, we get forks. This isn't a good or bad thing, it just is:
> Often it's how projects start before pull requests happen. The *why* is what 
> we
> need to focus on. Sometimes there's fights and drama that destroy 
> relationships
> and leave a fork in the road, or sometimes there's new contributors who have a
> fork but want to get it mainlined.
> 
> In this case, there's two important things to note here:
> 
> - There's no reason why we're not working together, so we might as well try to
>   build a relationship and lessen the fork of what we don't share in common.
> 
> - We need both parties to want to work together. NixOS can have the best
>   community management in the universe, but if the other half of the
>   relationship doesn't want this then a fork will be there.
> 
> This is the first I've heard of this Suckless NixOS project, and to me since I
> don't see a reason why there's a fork it means opportunity.

Never thought about what you wrote there. Thanks for the new 
perspective!

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Consider switching to free software.
It adds value to your life.
https://www.gnu.org/


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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Jan Malakhovski]

Jookia <166...@gmail.com> writes:

> This probably won't be of practical use to me since I have other issues with
> NixOS, but I'd like to show my support for this: Having enough interest to get
> forked is certainly a good thing. Who knows, maybe NixOS will join the ranks 
> of
> other distros with spin-offs.

Post your issues! We'll discuss and add to Wishlist.
Document, discuss, code.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Jookia]

On Sat, Mar 18, 2017 at 11:32:18AM +0100, Matthias Beyer wrote:
> But then you have to think about why these people are doing it.  
> Clearly because they think they can do something better - which is 
> fine IMO.
> 
> But if a fork is necessary this also means their voices were not heard 
> when they announced that things are not optimal for them - which means 
> bad community management. If they did not tell the community what they 
> dislike, though, I fully agree with you.

The thing that bothered me a little about your email is the assumption that a
fork is what happens when there's trouble. I don't think that's always the case,
and now might be a good example. Without working relationships to hold our
projects together, we get forks. This isn't a good or bad thing, it just is:
Often it's how projects start before pull requests happen. The *why* is what we
need to focus on. Sometimes there's fights and drama that destroy relationships
and leave a fork in the road, or sometimes there's new contributors who have a
fork but want to get it mainlined.

In this case, there's two important things to note here:

- There's no reason why we're not working together, so we might as well try to
  build a relationship and lessen the fork of what we don't share in common.

- We need both parties to want to work together. NixOS can have the best
  community management in the universe, but if the other half of the
  relationship doesn't want this then a fork will be there.

This is the first I've heard of this Suckless NixOS project, and to me since I
don't see a reason why there's a fork it means opportunity.

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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Jan Malakhovski]

Hi.

Hope this clarifies our view of Sucklessness.

# Mission Statement

- We agree on SLNOS Wishlist by consensus
- We agree to (eventually) merge any patchset that implements an item from 
SLNOS Wishlist
- We agree to (eventually) merge any patchset that reduces boilerplate (and 
docstrings don't count)
- We agree to (eventually) merge any other patchset that makes SLNOS suck less

# Workflow

- We plaintext and docstring everything
  Everything of value should be in the tree and commit messages, not
  chat logs, issues and wikis. Migrating from one chan to the other
  should be painless. Getting censored on GitHub should mean nothing
- We review and exchange patchsets via P2P protocols. We use centralized
  services (like GitHub) for publicity only

# Review Rules

- No authority (anonymous peer review only)
- No bikeshedding
- No hypothetical discussions
- :-1:s must propose a working alternative solution, or this gets merged
- No discussions when fixing problems is faster
- We don't care about authorship. Grab, fix, publish

# Relation to NixOS

- We steal everything we like from nixpkgs
- PR our changes to pkgs subtree
- Don't PR our changes to nixos subtree (a waste of time)

# SLNOS Wishlist proposal (2017-03-18 00:00 UTC)

(numbers in parentheses are logarithmic expected effort)

- (2) Show new Changelog entries on configuration build and switch/boot
- (3) Rewrite all source docs into a plain text format (no docbook xml), 
generate docs into man and info files (no HTML by default)
- (2) Toposort everything
- (5) Replace systemd with sane initd:
- (3) Rip systemd out
- (2) Sysvinit + toposorted scripts
- (2) OpenRC
- (2) runit
- (4) Replace GNU tools with Suckless base
- (2) Implement Gentoo-like use flags (#12877 in nixpkgs)
- (3) Disallow null buildInputs, use use flags instead
- (1) Set `unfree` meta flag for all unfree packages, including firmwares and 
blobs
- (2) Interactive GCC shouldn't do any hardening (#18995 in nixpkgs)
- (3) Either sanitize everything by default or drop hardening completely by 
default
- (2) Replace configuration.nix with centralized machine profiles
- (2) Implement our own nixos-install script
- (2) Implement a pretty wrapper around nix-env, nix-instantiate and nix-store
- (3) Implement multi-instance for nixos services
- (1) Fetch sources via Tor by default
- (2) Build torbrowser and all its extensions from source with our own patches 
(and no JS by default)
- (2) Add expression for all P2P packages we know about, including the ones you 
can't get in clearnet
- (1) DNSCrypt (over Tor/I2P?) by default
- (1) Setup Tor, I2P and our torbrowser by default (must fail closed)
- (2) Implement plugable VPN configs (must fail closed)
- (3) Implement better firewall (atomic, declarative, must fail closed)
- (3) Isolate network like in Tails
- (3) Port memory scrubbing from Tails
- (3) Port QubesOS utils to nixos
- (4) Implement Qubes netvm on top of NixOS
- (3) Implement booting with Coreboot
- (3) Port Heads:ROM to nixos
- (3) Support kexec reboot
- (3) Implement kexec chaining (for testing new Heads:ROM payloads before 
flashing)
- (3) Implement initrd chaining (for encrypted initrds)
- (2) Implement toposort in nix

# SLNOS No Consensus Wishlist proposal (2017-03-18 00:00 UTC)

- (1) Implement `sucksless` meta flag with `allowSucks`
- (0) Disable binary caches by default
- (3) Patch everything for stronger crypto defaults, low-power devices can wait
- (3) Nix closure generation via toposort
- (3) Implement safe storage of private files in /nix/store
- (3) Drop UEFI and BIOS in favor of Coreboot

Cheers,
  Jan and The Pope
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Mayeu]

> (4) implement
> 
> 
> {
>  # use OpenRC instead of systemd
>  system.initd = "openrc";
> }
> 

I would love to see that in upstream, independence from systemd will open the 
door to have some kind of NixBSD and other fun stuff like that. (No longer than 
3 days ago there was a discussion for GSOC to have a project to make NixOS + 
freebsd).

And besides, since I am following NixOS I have always heard that one of the 
long-term goal would be to abstract away from systemd.

> * Some of us want to drop GRUB in favor of running on top of minimal
>  Xen payload on Coreboot firmware and isolate everything like in
>  QubesOS, but we are not united on that point at this point. (Yes, we
>  are aware of Heads:ROM, thank you, we are discussing all of this.)

Again, there are regular discussions in multiple space to have some kind of 
Qubes OS + Nix merge (or related) [1][2][3][4]. Note that Qubes uses SaltStack 
[5] to have some kind of declarative VM management. Nix would be a really nice 
improvement over that.

[1] Qubes OS ML: 
https://groups.google.com/forum/#!topic/qubes-devel/QDM2YNdWdXI 

[2] Harden(ed) NixOS issue reference Qubes multiple time: 
https://github.com/NixOS/nixpkgs/issues/7220 

[3] Package MirageOS for NixOS: https://github.com/NixOS/nixpkgs/issues/23955 

[4] Trying to run NixOS in a Qubes VM: 
https://github.com/NixOS/nixpkgs/issues/21402 

[5] Qubes OS SaltSack doc: https://www.qubes-os.org/doc/salt/ 


All of that would be awesome for NixOS :)

--
Mayeu a.k.a Matthieu
http://mayeu.me 
GPG: A016 F2D8 0472 1186 1B33  A419 22B1 0496 B00D A693



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Matthias Beyer]

On 18-03-2017 21:23:36, Jookia wrote:
> On Sat, Mar 18, 2017 at 11:10:51AM +0100, Matthias Beyer wrote:
> > On 18-03-2017 11:39:15, Jookia wrote:
> > > Having enough interest to get forked is certainly a good thing. Who 
> > > knows, maybe NixOS will join the ranks of other distros with 
> > > spin-offs.
> > 
> > Oh please no!
> > 
> > Whether it is a good thing what is proposed here or not - we really
> > should try to hear all voices and try to get the best of all worlds
> > Having many spinoffs won't help anyone and result in a _lot_ of work
> > duplicated. That is _never_ a good thing.
> 
> That's one way to look at it. Another way to look at it is that duplicated 
> work
> is a cost of doing a fork, and if you're okay with it then it's not so much a
> big deal as long as the people doing the duplicated work are ok with it.
> 
> In the end, people would use what they want to use. :)

But then you have to think about why these people are doing it.  
Clearly because they think they can do something better - which is 
fine IMO.

But if a fork is necessary this also means their voices were not heard 
when they announced that things are not optimal for them - which means 
bad community management. If they did not tell the community what they 
dislike, though, I fully agree with you.

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Consider switching to free software.
It adds value to your life.
https://www.gnu.org/


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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Jookia]

On Sat, Mar 18, 2017 at 11:10:51AM +0100, Matthias Beyer wrote:
> On 18-03-2017 11:39:15, Jookia wrote:
> > Having enough interest to get forked is certainly a good thing. Who 
> > knows, maybe NixOS will join the ranks of other distros with 
> > spin-offs.
> 
> Oh please no!
> 
> Whether it is a good thing what is proposed here or not - we really
> should try to hear all voices and try to get the best of all worlds
> Having many spinoffs won't help anyone and result in a _lot_ of work
> duplicated. That is _never_ a good thing.

That's one way to look at it. Another way to look at it is that duplicated work
is a cost of doing a fork, and if you're okay with it then it's not so much a
big deal as long as the people doing the duplicated work are ok with it.

In the end, people would use what they want to use. :)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Matthias Beyer]

On 18-03-2017 11:39:15, Jookia wrote:
> Having enough interest to get forked is certainly a good thing. Who 
> knows, maybe NixOS will join the ranks of other distros with 
> spin-offs.

Oh please no!

Whether it is a good thing what is proposed here or not - we really
should try to hear all voices and try to get the best of all worlds
Having many spinoffs won't help anyone and result in a _lot_ of work
duplicated. That is _never_ a good thing.

I'm not stating whether I like the proposed effort or not.

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Consider switching to free software.
It adds value to your life.
https://www.gnu.org/


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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Bardur Arantsson]

On 2017-03-17 20:15, Jan Malakhovski wrote:
> Stefan Huchler  writes:
> 
>>> * Our common goal is to have fun (see below) and to get a NixOS system
>>>   that can run using only suckless tools [1].
>>
>> which is a subject oppinion, which tools does suck and which not.
>>

@Stefan: Don't feed the... thing.

> 
> We won't argue. You are free to like and use whatever you want. We
> collectively hate systemd, pulseaudio and dbus and want
> 
>   du -csh $(nix-store -qR /run/current-system)
> 
> for a usable (for our definition of usable) system to be megabytes, not
> gigabytes. Putting LISP on top of Nix goes against that goal.

Uhm, you'd pay for the "bloat" of a LISP/Scheme exactly once -- much
like libc, except a lot more powerful.

> 
>> Blooted GNU tools? So you like the horrible inferior tools that come
>> with android? its always good if software has less features?
> 
> Yes. No, Android uses Toolbox, not even Busybox, and certainly not
> Suckless. No, but Suckless provide 90% of the features with 1-10% of the
> code.

Please define 'bloated' in any objective manner. While you're at it,
define the objective criteria necessary to deserve your "hate" (as you
mentioned above).

Anyway, it's your choice what to do with your time -- I just hope that
it won't result in any time waste for the NixOS project itself.

Regards,

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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Jan Malakhovski]

Profpatsch  writes:

> On 17-03-17 02:00pm, Jan Malakhovski wrote:
>> 
>> Brothers and Sisters!
>> 
>> * Our common goal is to have fun (see below) and to get a NixOS system
>>   that can run using only suckless tools [1].
>
> I, for one, applaud our new anonymous suckless leaders!
> On an offhand note, be advised that suckleast.org is already taken.

We don't plan to register any domains, AFAIK.

>> * We like LISP, but we don't think package expressions should be written
>>   in LISP just for the sake of LISP. Nor do we like the bloated GNU
>>   tools. GuixSD is out of question.
>
> rolf
>
>> We want suckless tools instead of GNU. Sh instead of Bash. Coreboot
>> instead of GRUB and BIOS and so on.
>
> gl hf

thx

> T. systemd fanboi

:(

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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Stefan Huchler]

Jan Malakhovski (The ephemeral self-proclaimed Pope of SLNOS)
 writes:


> * Our common goal is to have fun (see below) and to get a NixOS system
>   that can run using only suckless tools [1].

which is a subject oppinion, which tools does suck and which not.

> * Some of us want to drop GRUB in favor of running on top of minimal
>   Xen payload on Coreboot firmware and isolate everything like in
>   QubesOS,

So you want to have a distro not only for the 2% linux users but only
for the 1% pc that run with coreboot, I am very optimistic that you will
get much contribution and feedback :)

> * We like LISP, but we don't think package expressions should be written
>   in LISP just for the sake of LISP. Nor do we like the bloated GNU
>   tools. GuixSD is out of question.

And why is it for the sake of lisp? Have you proof that guixsd chose
lisp just because of lisp despite some disadvantages? What are the
disadvantages of lisp package expressions?

Blooted GNU tools? So you like the horrible inferior tools that come
with android? its always good if software has less features?


But thanks for the post, made me laugh.

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

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Profpatsch]

On 17-03-17 02:00pm, Jan Malakhovski wrote:
> 
> Brothers and Sisters!
> 
> * Our common goal is to have fun (see below) and to get a NixOS system
>   that can run using only suckless tools [1].

I, for one, applaud our new anonymous suckless leaders!
On an offhand note, be advised that suckleast.org is already taken.

> * We like LISP, but we don't think package expressions should be written
>   in LISP just for the sake of LISP. Nor do we like the bloated GNU
>   tools. GuixSD is out of question.

rolf

> We want suckless tools instead of GNU. Sh instead of Bash. Coreboot
> instead of GRUB and BIOS and so on.

gl hf


T. systemd fanboi

-- 
Proudly written in Mutt with Vim on NixOS.
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
May take up to five days to read your message. If it’s urgent, call me.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] The Church of Suckless NixOS is looking for followers

[The ephemeral self-proclaimed Pope of SLNOS]

Brothers and Sisters!

I think I reached the point of no-return w.r.t. not being able to
tolerate systemd on my machines any longer after systemd devs dropped
utmp. I don't want to replace finely matured portable UNIX utils
produced by The Old Gods for the sake of making a bunch of crazy people
into The New Gods. And, as it turns out, I'm not alone.

And so we (I and a couple of anonymous friends) are pleased to announce
the establishment of The Church of Suckless NixOS ("SLNOS" for short).

* Our common goal is to have fun (see below) and to get a NixOS system
  that can run using only suckless tools [1].

* Some of us want to drop GRUB in favor of running on top of minimal
  Xen payload on Coreboot firmware and isolate everything like in
  QubesOS, but we are not united on that point at this point. (Yes, we
  are aware of Heads:ROM, thank you, we are discussing all of this.)

* We like LISP, but we don't think package expressions should be written
  in LISP just for the sake of LISP. Nor do we like the bloated GNU
  tools. GuixSD is out of question.

For now we have a couple of proposals for the general NixOS community.

# The Systemd part

In short, we propose:

(1) to reimplement full dependency tracking in nix (should replace
`strings-with-deps.nix`) with `toposort`,

(2) return the old `system.jobs` under another name (for backwards
compatibility), but with most of that `system.systemd` now provides,

(3) reimplement all the services we use with "system.jobs",

(4) implement


{
  # use OpenRC instead of systemd
  system.initd = "openrc";
}


and


{
  # toposort `system.jobs` and render static
  # init script for suckless.org initd
  # (a page of nix code and a page of C code
  # instead of systemd, yay!)
  system.initd = "static";
}


The (1) can then be used to get dependency tracking in `initrd` for free
too.

As we see it, implementing the infrastructure (1)-(2) is a couple of
days of work, but reimplementing services (3) will need lots of effort
for very systemd specific, highly cgrouped and socket-activated
services, and (4) requires writing an alternative activation script.

SLNOS will reimplement that for the services we use whenever you like it
or not (in fact, we already implemented a part of (1) because we wanted
encryption on networking `fileSystems` (LUKS over nbd) in initrd, but
never even proposed those changes to upstream because merging simple
`toposort` for `fileSystems` took a year).

But we want to know how many people here are like-minded and would like
to join our SLNOS effort.

The following template answers were proposed by our current members for
your convenience:

* Poettering is my New God! PulseAudio! Avahi! Systemd! PulseAudio!
  Avahi! Systemd! DBus for the Kernel! utmp is for old people! All
  computers are laptops! All initds should include Udev, DBus, and do
  DHCP and DNS-resolver, this is what initds are for! Merging this
  upstream would be blasphemy! Burn it! Burn it with fire!

* I don't care, but am willing to break UNIX-like part of GNU/Linux for
  posterity. [2]

If one of these templates covers your feelings you can reply-to-only-me
not to spam the list.

If there are enough interested people we will organize a public SLNOS
repo thing as soon as we produce something substantial that can be read
by other people.

General thoughts and pointers to anything in current or nearly-current
NixOS that might become a general snag for this effort are very welcome.

If you have an idea for a simpler solution to the no-systemd problem you
are very welcome too.

Bikeshedding of "`toposort` is too slow, not gonna work" and
"toposorting should be done at runtime" kinds are not welcome. Just go
and measure first. And it should not. Works fine for us. If it's slow on
your graphs, then just implement builtin `toposort` into nix.

# The Nix part

Or even better: generalize closure generation by splitting it into
`toposort` and `depends-on` relation on paths, expose both via builtins,
reimplement closure generation in lib.

Then proceed to implementing half of `nix-store` commands on top of that
infrastructure instead, which would allow to customize `nix-store` with
nix code. For instance, want to GC as usual, but always leave source
tarballs intact (some of us do exactly that with hacks)? Easy. Want
custom queries? Trivial. Just imagine:

* `nix-store --gc -A gc-no-src` (`--gc` gives gc roots to `gc-no-src`
  and checks `gc-no-src` doesn't leave any orphans with its returned
  list of to-be-removed paths, then cleans them up as usual),

* `nix-store --gc -A gc-no-src $derivations` (as before, but start
  collecting from `$derivations`)

* `nix-store --realize -A list-all-sources $derivation` (run
  `list-all-sources` on `$derivation` and realize all those paths. yes,
  this can be done with a crazy shell command already, but this is much
  more generic)

* now the blasphemous idea trivially follows from above: `nix-store
  --realize -A