3 ms·
I'm intrigued by Guix but right now I'm invested in NixOS. Finally I've learned most of the Nix language, which is elegant and quite clever, but it was a little
by mbrock 11y ago
I'm intrigued by Guix but right now I'm invested in NixOS. Finally I've learned most of the Nix language, which is elegant and quite clever, but it was a little bit of a hurdle. Scheme is more familiar and easy to learn, I think, and I can easily see macros as being extremely useful for system configuration. I'm fully convinced that the Nix/Guix style of package management and system configuration is Teh Future. Anyone who isn't drinking koolaid on that bandwagon yet should hop on and check it out.
- nextos 11y agoI also love Nix/Guix, but I have the feeling the future will sadly be giving us container-ized apps systemd-style. Much worse security and sysadmin-wise.
- civodul 11y agoThe future is what we make it. :-)
- a3n 11y agoOr is the future what we made it?
- mbrock 11y agoI launch containers from systemd in NixOS. My future is a mixed bag.
- nextos 11y agoContainers are cool for big things. But imagine every single program stuck inside a container without proper management tools to track dependencies. Now imagine a heartbleed-like scenario where you need to patch a big security hole ASAP. With containers you'd have a hard time.
- tolle 11y agoDepends on how stuff is implemented no? You change a library, you do a rebuild of all packages that uses that library, the user downloads package deltas and the filesystem does deduplication so the same file is used in all the containers. Would only cause a problem with packages from third party sources. But thats a possible problem now already?
- kefka 11y agoDepends how those "containers" interact with the system at large. In the Windows world, it's common to have the libraries you need stored in ~/Program Files/Program_name/ . Now, each program dumps in its program home the library, only because it cannot guarantee the library would be in the system. In Linux, we deal with having different major versions of said library. nd minor versions are clobbered by major. So when someone who wrote stuff using python 2.7.2 and 2.7.3(bugfixes) comes out, there is invariably something that is broken. A container that encompasses "Python", and holds all the versions would be a great deal. Same with other programs. They could interact, but their install and environment would be encompassed as a complete "Python", regardless of version or bugfix.
- JupiterMoon 11y agoYou are describing NixOS/Guix rather than containers.
- mbrock 11y agoYeah, I don't want to run every single program in a container... and I don't plan to. That said, containers have their advantages even in that security scenario. For example, once I was running into obscure segfaults that seemed related to some interaction between Sidekiq a particular Ruby version. Once I figured out the fix, I just changed the top line of a couple of Dockerfiles to change their Ruby versions. Generally also containers are built on existing Linux distributions and use their packages. I still haven't figured out exactly what I want to do but my vague future plan involves containers bootstrapped from Nix expressions. That's just to get a level of indirection to abstract away NixOS so I can run app services on whatever distribution.
- 11y ago
- zeckalpha 11y agoYou can combine the two: https://wingolog.org/archives/2015/08/04/developing-v8-with-guix https://wingolog.org/archives/2015/08/04/developing-v8-with-...
- Ankaios 11y agoI'm intrigued, too, but I'm planning on drinking the Kool-Aid only after someone figures out how to sanely include support for late binding of dependencies. If that happens—allowing security updates without explicit action for every package—I think I'll be in.