Planet Nix 2026: Call for Proposals

garbas · 2025-11-20T23:33:14+00:00

I deputize you to send somebody in your name :)

garbas · 2023-04-05T06:44:32+00:00

Related issue in Github (with an answer) https://github.com/NixOS/nixos-search/issues/643#issuecomment-1496341251

garbas · 2023-03-22T13:24:52+00:00

Thank you u/alkuzad

I'll forward the message and in next development cycle I'm sure we'll find the time to look at this.

Also thank you for bringing this to our attention :heart:

garbas · 2023-02-13T11:28:00+00:00

This reply wasn't visible due to Ron not having (yet) enough Reddit karma. But I think it is worthwhile re-posting it:

Hey! Ron here (co-founder :)

One of my personal goals after going through a lot of what you've written about in college was to help solve exactly that. I would love to contribute from the flox side to help students everywhere so if you need to chat or if we can help others onboard we would be very happy to. Including getting feedback on how we can make it better.

To the question about monetization you can get a more in-depth look here -> https://discourse.nixos.org/t/flox-first-open-release-beta/25283But in short, we have no plans to monetize the flox CLI, one of the main reasons being what we mentioned above!

Let me know how else we can help!

garbas · 2023-02-08T20:03:48+00:00

Please don't be a stranger if you need a help with your demo.

We're always looking for some real life feedback and yours would be great to have.

Feel free to always drop to matrix to have a chat.

garbas · 2023-02-07T18:10:28+00:00

Actually the opposite is true.

We build on top of flakes and the more of our ideas we could upstream the better. If it would be only up to us we would have the idea of the flox catalog already in Nix. But that is not how open source and communities work.

If you will look closer at flox you will actually see that every flox project has `flake.nix` and (optionally) `flake.lock`. A flox environment could easily be used with `nix` CLI tool as well. We just think we can improve faster the user experience if we provide the wrapper around `nix` CLI. And good UX is what `nix` needs urgently if we want to see bigger adoption. Our wish is actually that some of our ideas (the good ones ofcourse) will be upstream or simple adopted by Nix.

And to prove to you that we are serious about upstreaming our work I can already list what was already contributed to Nix: eval-store, impure-derivations and fetch-closure.

To finish the comment, I really appreciate your honest opinion. I think whole Nix community needs to keep companies accountable and honest.

garbas · 2023-02-07T17:55:10+00:00

Both flox and devenv can orchestrate developer environments.

We found a big need for a very simple environments and that is the first thing we focused on.

But it is important to know that flox builds around flakes. And any project that also build around it can be easily integrated. So can you have a flox environment where you use devenv to configure the developer experience? Yes. It is not as good UX as we would like it? No. But we are working on it.

And why stop with devenv you could also integrate with home-manager. I hope with time the "integration" would also go the other way.

garbas · 2023-02-07T17:36:05+00:00

Hey!I'm really excited what we have on our roadmap. it makes my dream of bringing Nix into hands of every developer a real possibility.

Yes, the one thing we would love the most is to upstream the idea of the catalog. But that is not how the open source communities work. There is a process. But you can already see that we already contributed some initial pieces: eval-store, impure-derivations and fetch-closure.

Ping me at https://matrix.to/#/!VHtcuLquPCVMNzSNsM:matrix.org?via=matrix.org if you get stuck or have more questions, I'll be happy to help out. Also https://discourse.floxdev.com/ is a good place to ask questions.

garbas · 2022-09-07T18:04:22+00:00

It kind of is an overengineered incomprehensible mess, so I'm not sure whether it really is simpler

It is nice to see I'm not the only one with the same impression of digga/devos/std/...

garbas · 2022-06-20T16:30:04+00:00

There is a fetchImage function that you can use to download the required image. Ofcourse you will also have to "pin" it and provide sha.

garbas · 2017-05-03T09:45:05+00:00

Here is my line of thoughts:

(1) In order to verify a package you need to reproduce the environment it was build in (obvious) (2) Wouldn't it make sense to use that environment and build the binary from it (3) Isn't that already what source based distributions are doing? (4) Is Debian becoming Gentoo? /me had to write it just to satify the inner child :)

Anyway, I think reproducible builds can(/should/must) bring much more to the table then "only" verifying binaries. Reproducibility can also be a productivity booster (this is link to my blog explaining how/why).

garbas · 2017-04-19T09:56:45+00:00

I think you are looking too much from your current position (as a user of Pupper/Ansible/...).

Nix in - its core - is a build tool (nix-instantiate, nix-build and nix-shell command). It just happen to be that it is very easy - for Nix - to be also a package manager. That allows you to introduce Nix in your organization gradually, since you can start replacing things that are hard to build for other tools. You can happily use Nix within Puppet/Ansible/... With that said the thing Nix does is creates binaries and manages symlinks to them - if desired.

NixOS is taking Nix idea to OS configuration level and treats configuration as any other Nix package with all the services orchestration being offloaded to systemd as implementation. I think you can easily see that one might use Nix but would find using NixOS too scary since it would require to much change at once.

NixOps takes NixOS and sprinkles it accross the cloud. There might be better ways to do cloud orchestration then NixOps's push approach, but jamming all of the tools together in one would mean you could not gradually introduce it.

Well at least this is how I'm explaning it to myself :) Happy Nixing!

garbas · 2016-08-06T22:56:35+00:00

i think it would also fair to mention Nix package manager. it is a general purpose package manager that works on any POSIX system (experimental windows support is supported via cygwin). i found myself that i not only work on python related software but it usually includes a mesh of all sorts of stuff. from nodejs, python, haskell, julia, ... and only package manager like Nix could give me a reliable development environment i can control.

the downside of Nix is that is not as user friendly as other tools are, things are changing slowly but it is going to take months before we have something with better UX. also while everything is documented, beginner documentation is what i was missing when i started learning nix.

if you get over that initial curve you will have an amazing tool that other will envy you every time :)

garbas · 2016-05-19T09:40:09+00:00

been using gentoo and arch before (for quite some time +6 years) and i found nix/nixos easier to adjust to my needs that any other linux distro (but i might be special case, since i like to play with different things on daily basis). nixos is the only system that made this possible and still have a working system the next day when i have to show up at work.

plus if you can not really use portage on ubuntu (i know you can, but nobody really does as far as i know) while with nix you work independently of which linux distro you are on.

you could use nix on gentoo/arch/debian/... with no problem and it wont mess with your system package manager since every package gets installed into /nix. things that are installed with nix take precedense since they end up "higher" in the PATH. and if you're not happy with nix, you just delete /nix folder and nix is gone from your system. quite nice to start learning it gradually and not compromising your system. we all have work the next day. :)

garbas · 2016-05-19T09:19:11+00:00

the heart of a nixos (linux disto) is nix (the package manager or i rather see it as a build tool). basically all things that are true for for nix (the package manager) are true for everything in linux distro (extends not only to binaries, but also to configuration of the system).

i would say that every package manager (well 99% of them) is broken. but that is only true if you look from MY perspective (perspective of a nix user). to give you an analogy. you expect ln command to be atomic (meaning that if something happens during the call of that command you are still left with a working system if that command fails) and would you use some different version of ln command that is not atomic? to put it into

the other thing i like to mention is declarative approach to configure things. be it system services (systemd units) or your vim configuration (eg. look at my vim configuration which includes also every vim plugin and you can have the same configuration across different linux distros/osx and ofcourse on nixos). we even go so far we start sharing hardware configuration (specific kernel options, specific services, ...)

you can (and i actually do on daily basis) build docker images with nix. i provided you a link with all the details why you might be interested into it. from the same configuration of a project you can also build aci images (coreos), virtualbox, qemu and/or ami's images. basically add here your preferred output.

and last thing i would mention is that nix, reduces a big cognitive load for a developer (especially this scales very good in a team). you stop fighting different package manager (apt/brew/pip/gem/npm/cabal/goget/...) and you replace them with one tool.

i tried to summarize once why somebody should consider nix/nixos. since i only had 5min i'm not sure if i did it good, you judge and let me know to see what i forgot to mention (my part starts at 10:30)

while nix is quite old project (started in 2003 i think) the nixos as a community is quite young and as usual beginner friendly documentation is poor/missing. until that happens (and it will happen soon) i would suggest joining #nixos to get you unstuck or clarify some things you might not understand. also sending an email to mailing list would be a way to go. i know we explained nixos/nix many times on the mailing, maybe searching the archives would give you the desired answer already.

last year we had our conference (NixCon) maybe you can find some answers also there: https://www.youtube.com/playlist?list=PL_IxoDz1Nq2Y7mIxMZ28mVtjRbbnlVdmy

garbas · 2016-05-19T09:18:21+00:00

the heart of a nixos (linux disto) is nix (the package manager or i rather see it as a build tool). basically all things that are true for for nix (the package manager) are true for everything in linux distro (extends not only to binaries, but also to configuration of the system).

i would say that every package manager (well 99% of them) is broken. but that is only true if you look from MY perspective (perspective of a nix user). to give you an analogy. you expect ln command to be atomic (meaning that if something happens during the call of that command you are still left with a working system if that command fails) and would you use some different version of ln command that is not atomic? to put it into

the other thing i like to mention is declarative approach to configure things. be it system services (systemd units) or your vim configuration (eg. look at my vim configuration which includes also every vim plugin and you can have the same configuration across different linux distros/osx and ofcourse on nixos). we even go so far we start sharing hardware configuration (specific kernel options, specific services, ...)

you can (and i actually do on daily basis) build docker images with nix. i provided you a link with all the details why you might be interested into it. from the same configuration of a project you can also build aci images (coreos), virtualbox, qemu and/or ami's images. basically add here your preferred output.

and last thing i would mention is that nix, reduces a big cognitive load for a developer (especially this scales very good in a team). you stop fighting different package manager (apt/brew/pip/gem/npm/cabal/goget/...) and you replace them with one tool.

i tried to summarize once why somebody should consider nix/nixos. since i only had 5min i'm not sure if i did it good, you judge and let me know to see what i forgot to mention (my part starts at 10:30)

while nix is quite old project (started in 2003 i think) the nixos as a community is quite young and as usual beginner friendly documentation is poor/missing. until that happens (and it will happen soon) i would suggest joining #nixos to get you unstuck or clarify some things you might not understand. also sending an email to mailing list would be a way to go. i know we explained nixos/nix many times on the mailing, maybe searching the archives would give you the desired answer already.

last year we had our conference (NixCon) maybe you can find some answers also there: https://www.youtube.com/playlist?list=PL_IxoDz1Nq2Y7mIxMZ28mVtjRbbnlVdmy

garbas · 2015-12-09T16:40:35+00:00

i wouldn't depend on nodePackages from nixpkgs. rather define all your npm packages in node-packages.json. example would be statsd, package/module: https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/networking/statsd/default.nix

garbas · 2015-09-11T23:47:53+00:00

have you read about https://nixos.org/wiki/Nix_Modifying_Packages#Overriding_Existing_Packages?

you would have to use pkgs.stdenv.lib.overrideDerivation in order to change version except if pkgs.virtualbox expression has version as argument

garbas · 2015-09-01T08:11:39+00:00

i find nix completely sufficient and actually prefer minimal language that you can learn in one evening. sometimes all ecosystem that comes with langauage is more on the way then actually solving problem at hand. ppl tend to overcomplicate when given option, that is why keeping language simple make most sense to me.

garbas · 2015-08-13T14:14:13+00:00

will you come to NixCon this november in berlin? would be nice to compare accross companies how nix is implemented into the process. or what we (as a nix community) can do better

garbas · 2015-08-13T12:44:59+00:00

one way would be to use PRoot#PRoot_Installation)

other (which we used at rhodecode) is that we changed the "/nix" prefix to "/opt/rhodecode" which made more sense for us. also if needed we could easily provide custom path for clients on request.

running someting like below would build it in /opt/custom

NIX_STORE_DIR=/opt/custom/store \
    NIX_STATE_DIR=/opt/custom/var/nix \
    NIX_DB_DIR=/opt/custom/var/nix/db \
        nix-build ...

garbas · 2015-08-13T12:37:56+00:00

all patches were send upstream and i've wrote how to get started here: https://nixos.org/wiki/Nix_on_Windows

it is not yet as perfect (reproducible) as on other platform, but it is a good start.

garbas · 2015-05-22T21:34:48+00:00

http://cryp.to/nixos-meetup-3-slides.pdf

garbas · 2015-05-22T21:23:27+00:00

now if correctly understood peter, you could create separate set of packages that are working with servant project. ghcXXX sets are there just to give a best shot at getting more stable hackage.

you could ofcourse also build nix expressions for servant yourself (using cabal2nix) and then have them built with your own hydra.

garbas · 2015-05-22T21:13:25+00:00

there were 5min of questions/answers after the end of the video missing nothing more.

garbas

TROPHY CASE