snearch + nixos   13

Propellor : new devops configuration management system configured in haskell : haskell
I thought nixos was more trending among haskellers than writing another configuration tool for mutable systems :-) See https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansible-arent-good-enough-and-we-can-do-better/ Still interesting work, thanks.
...
[–]joeyh 4 points 3 years ago
I totally agree! And if this makes it a little bit easier for someone else, and maybe gives them an easy first or second program to write in haskell, like ~/.xmonad/xmonad.hs was for me, it's a total win.

btw, http://hackage.haskell.org/package/propellor

Re nixos, its nixops is quite interesting for managing multiple systems. I would rather nix used a more capable language though (the scheme fork of nix, guix, has a monad..) If you squint at docker the right way, it's kind of nixos without a single package manager (but still immutable hashed data underneath). It solves most of the same problems as does nixos in a less elegant but less constraining way. I am thinking about using propellor to provision docker images, configuring the system both inside and outside of the container.

...
[–]goliatskipson 2 points 3 years ago
I btw recommend Gabriels tutorial on free monads: http://www.haskellforall.com/2012/06/you-could-have-invented-free-monads.html

It's a real eye opener and I guess everyone will be able to use the free package after reading it.

permalink
Propellor  Nix  Haskell  y2018  m03  d12  Ansible  NixOS  Monad  automate_server_setup 
march 2018 by snearch
Deploying a Haskell Web Service with Nix | Hacker News
cwp 31 minutes ago

I use nix in production, and I love it. It's just as good in practice as it is in theory.

I think the problem is that really using nix involves learning a new language. And it's a weird lazy functional language at that. So yeah, the Haskell folk adopt it readily enough, but everyone else has a high barrier to get over. The only people that do it are the ones that have really wrestled with the problem of dependencies and can see how well nix solves it.
...

danharaj 42 minutes ago

I'm a Haskell contractor who currently works with a tech stack that looks like PostgreSQL, Haskell (backend), Haskell (frontend), and Nix. Stuff gets deployed to AWS.

things i hate about nix:

1. The nix language isn't haskell. It's a very spartan functional programming language. errors can be unhelpful and it is difficult to find thorough documentation. There's not much sugar and it has few abstraction facilities beyond higher order functions (like ML modules or Haskell type classes). In order to grok nix, I recommend reading the nix manual[1] thoroughly and this series of blog posts [2]. Honestly though nix would be much more powerful if it were embedded in a full fledged functional language instead of trying to focus on just package description. i am many orders of magnitude less efficient at writing nix as i am haskell. guix looks interesting but i haven't tried it seriously: check it out too.

2. the caching system is a little boned. if a cache goes down, the builder will wait forever to get the metadata from the server instead of ignoring it. there is a timeout setting but it only applies to downloading the actual binaries, not the .narinfo files. the workaround is to disable binary caches for that invocation. it is an annoyance since i often work on projects with flaky cache servers.

things i like about nix:

1. i haven't fucked up my computer with NixOS yet. upgrading everything Just Works. If it doesn't Just Work, reverting Just Works. You have to go rather far out of your way to put a NixOS system in an inconsistent state. I might be a somewhat reckless user, but i used to put my Ubuntu installations in inconsistent states regularly.

2. i can create a good sandboxed environment for any project with relatively little effort. it doesn't matter how many languages or arcane dependencies there are. there are no subtle bugs caused by interfering components: if there's interference it's a build error; if there isn't, you're good.

3. if you've used a build system in anger and you can only come up with two complaints and neither of them are "it has trouble building the thing", then you've found a good build system. i've never had to worry about dependencies, reproducible builds, sharing binaries with colleagues or anything. in spite of all the warts of the language and the byzantine user experience, by god it works.

[1] http://nixos.org/nix/manual/ [2] http://lethalman.blogspot.com/2014/07/nix-pill-1-why-you-sho...

AMA
Webdevelopment  deployment  Haskell  Nix  NixOS  Website  Webserver  y2018  m05  d26 
february 2016 by snearch
Erlang and distributed systems expert, gives his views on BEAM languages, Hindley–Milner… — This is not a Monad tutorial — Medium
I haven’t seen any new languages pop up recently that have grabbed my interest. On technologies, I think that microkernels are very, very interesting. Things like OSv for the JVM based languages, Mirage for OCaml and BSD Rump Kernels for the rest. I think those are going to become the fundamental building block of system orchestration in the very near future. The other thing to keep an eye on is the Nix Package manager, NixOS, and technologies like Atlas from Hashicorp. It’s not going to be too much longer before we declaratively describe out systems as well as our code. I am looking forward to that.
Prognose  Profession  Professional_Software_Development  Trend  Zukunftsmärkte  Microkernel  OSv  JVM  Mirage  OCaml  BSD  BSD_Rump_Kernel  system_orchestration  declarative  NixOS  Nix_Package_Manager  technology  Merritt  Erlang 
august 2015 by snearch
NixOS Linux | Hacker News
anonbanker 2 hours ago

I was great with Arch on USB, until I started trying to boot to a full UI from the image, and I'd start getting I/O errors from the ramdisk halfway through a 'pacman -Sy plasma-meta' (last three iso releases). That was a dealbreaker for me.

I switched to KaOS (because they used pacman), but their install image fails to install before creating users and installing grub, so I'm back to a Gentoo LiveUSB, which doesn't fail.

Every time I leave gentoo, I'm eventually forced back. maybe Nix will be better.

reply



agumonkey 3 hours ago

I do have a rescue USB like you. We should write something for arch to get rollbackable system.

ps: while googling for it, I discovered https://wiki.archlinux.org/index.php/Arch_Rollback_Machine
functional  Linux  NixOS  distribution  PROs  CONs  Gentoo  Arch_Linux 
june 2015 by snearch
My experience with NixOS : programming
[–]passwordisNORTHKOREA 12 points 14 hours ago

Thanks for the post. I've been using NixOS in virtualized environments for a year or two and love it. Generally my setup is running OS X and then running NixOS on Virtual Box instances which are created via nixops (kind of vagrant for Nix).

This post focused mainly on Haskell but Nix has some great features in general. One can easily build packages from source, Hydra is really populating a binary cache for you. You can also build packages on a single instance of Nix, and as long as target machines have the same specs you can copy the closure across machines easily. Infact, this is how NixOps works.

One thing that I believe makes NixOS hard to adopt for people, but I personally like, is that it owns your entire machine environment. Unlike something like Ansible or Chef where you can slowly migrate to a more Ansibled or Cheffed environment, NixOS wants to own everything. This is really great for me because it means I never I always know my configuration.nix is what my system actually looks like. A great example is in turning off a service, like nginx. In Chef, unless you manually handle this they just forget it exists and do not turn it off or uninstall it. In NixOS, if you delete it from your configuration.nix or disable it, NixOS ensures it is turned off and uninstalled. At the cost of handing yourself over to NixOS completely you get more confidence in your setup.

It's not for everyone, but from a headless server perspective I have been really satisfied with it.

...

[–]aseipp 11 points 11 hours ago*

NixOS is far, far more than just clever dependency management. I think you need to actually spend time with it if you think it's similar to Leiningen. The OP is particularly concerned with Haskell packages, but NixOS is far, far more than that.

It also gives you things like sane transactional package management, user-level software installs, actual reproducible builds with precise dependency management, Nix is actually a language that can be abstracted over (so you can write higher level abstractions for configurations trivially). It has powerful cloud-deployment tools (including e.g. EC2 resources). Management of an entire machine or cloud network is consolidated in a single declarative file. Soon it will also have even better things, like binary determinism for the base system tools, as a security measure to ensure reproducibility. And of course things like distributed builds and multi-platform builds are built in by default.

There are also a host of other things; for example, NixOS has powerful declarative test mechanisms. For example, I can take any changes to my configuration and boot them in a VM to test them before booting them up. Or I can write multi-machine tests using QEMU to test services, like database services, or services I write myself. I've done this in production, and continuous integration for NixOS services and tests in particular is extremely powerful and I don't know of such an easy automation path for other systems.

Yes, it subsumes the functionality of tools like Leiningen, but it gives you way more than that. Global transactional package management, and the reproducibility of configurations thanks to the design (leading to easy tests, cloud deployment, etc) alone is unmatched by other systems.

Also yes, there are many downsides to NixOS; the post above articulates a good set of them. It's certainly not for everyone. But the pain/power ratio is so far in NixOS's favor I think it's completely worth it.
NixOS  nix  PROs  functional  programming 
june 2014 by snearch

Copy this bookmark:



description:


tags: